Anti-Tamper in an Open Architecture Context

1. Anti-Tamper in an Open Architecture Context John Stein, NAVSEA Crane

2. Topics • Introduction • OA Fundamental Concepts • Impacts of OA Requirements on AT • AT Implementation in an Open Architecture • Conclusion

3. Introduction • Background • From AT perspective, the concept of Open Architecture seems to be in conflict with AT • Is the conflict real or imagined? • If real, how do we handle the two? • Need guidance for programs (Addition to Navy AT Desk Reference)

4. Introduction • Objective: To provide guidance for Navy programs for implementing Anti-Tamper (AT) measures in an Open Architecture (OA) context • Reviewed Navy OA policy and guidance; “what is OA?” • Investigated impacts from a requirements perspective • Offered 4 approach vectors • Reviewed by Navy OA and AT community

5. OA Fundamental Concepts What is OA? “the confluence of business and technical practices yielding modular, interoperable systems that adhere to open standards with published interfaces”(Naval OA Strategy, 2008)

6. OA Fundamental Concepts 5 Principles • Competition & collaboration • Modular designs & disclosure of data • Interoperable joint warfighting & secure information exchange • Reusable application software • Lifecycle affordability

7. OA Fundamental Concepts Non-functional requirements (NFR) • Open standards • Modularity • Interoperability • Extensibility • Reusability • Composability • Maintainability

8. OA Fundamental Concepts • Open Architecture Assessment Tool (OAAT) • Results provide starting point for Business Case Analysis (BCA)

9. OA Fundamental Concepts • Outputs and deliverables • OAAT Total Score • Detailed reports for programmatic and technical questions • Modular Open Systems Approach (MOSA) Program Assessment & Rating Tool (PART) Detailed Report • MOSA PART results required at milestones and major program reviews • https://acc.dau.mil/oa

10. Impacts of OA Requirements on AT • AT = functional requirements (system shall deter, prevent, detect, respond) • OA = non functional requirements (system shall be modular, interoperable, …) • Goal of SE: successfully perform the AT functions that does not preclude the system from being “open”

11. Impacts of OA Requirements on AT • Open Standards: widely used, consensus based, and published and maintained by recognized industry standards organizations • Impacts: • Predictable behavior systems/components • Publicly available documentation/tools • Mitigations: • Encryption • Key protection • Authentication

12. Impacts of OA Requirements on AT • Modularity: properties that support independence of operations • Partitioning into self-contained, discreet, scalable, functional units • Impacts: • Easier to remove modules from system for bench/lab testing • Enables attacker to concentrate on “bite-size chunks” • Mitigations: • Environmental verification • Encryption • Key protection • Authentication

13. Impacts of OA Requirements on AT • Interoperability: ability of systems to provide and accept data and information and use that data and information to operate effectively together • Impacts: • Relies heavily on trusted communications and equipment • High traffic makes target for spoofing and man-in-the-middle attacks • Mitigations: • Encryption • Key protection • Authentication

14. Impacts of OA Requirements on AT • Extensibility: ability of system to accept new capability, components, subsystems • Impacts: • More points of entry for attacker (ports, unused memory, card slots, …) • Mitigations: • Physically remove/disable unneeded features • Principle of least privilege

15. Impacts of OA Requirements on AT • Reusability: property that allows items to be used by multiple systems, in different contexts, providing same or similar capability • Impacts: • Increased exposure of CT means greater consequence if compromised • Increased exposure of AT means potentially more samples for attacker(s) • Mitigations: • Implement personalized or unique measures where possible • If proliferation increases, so must robustness

16. Impacts of OA Requirements on AT • Composability: various components can be combined in multiple ways to customize the system for a specific mission or need • Impacts: • Implies high modularity and extensibility • No direct impact to AT

17. Impacts of OA Requirements on AT • Maintainability: the ease with which maintenance can be performed on the system • Impacts: • Allows for isolation of faults; extraction, replacement, and testing; debugging/diagnostic tools & literature • Designer must distinguish allowable changes vs. unallowable changes • Mitigations: • Define allowable vs. unallowable operations • Implement AT at CI level • Avoid the use of back doors

18. AT Implementation in an OA • Approach 1: Co-location of CT • Reduce number of components needing AT protection • “Eggs in a basket” approach drives more robust AT protection for CT enclaves • Encrypted and authenticated communication between enclaves • Robust protection of keys

19. AT Implementation in an OA • Approach 2: Appropriate integration of AT techniques • Qualities of good AT protection: • Robust (strong, depth) • Layered (breadth) • Interdependent (defeat of one trips another; staged response) • Multi-dimensional (electronic, physical, chemical, cryptologic, software, …) • No single product/technique is sufficient

20. AT Implementation in an OA • Approach 2: Appropriate integration of AT techniques • As early as possible! • Take advantage of custom design opportunities (ASICs, PCBs, hardware) • Modified COTS • Minor modifications often introduce little/no real risk • Leverage commercial technology, interfaces, etc. • Form, fit, function reduces obsolescence issues • Keep the attacker guessing

21. AT Implementation in an OA • Approach 3: Controlled foreign participation • Many programs’ CT is SW only, so hardware is benign – NO! • Be careful of allowing foreign customers to control HW in which CT will reside, preventing: • Covert modifications • Hardware trust • Hardware ‘serialization’

22. AT Implementation in an OA • Approach 4: Program-unique solutions • AT techniques should leverage system architecture • Learn to perceive risks as opportunities • Use what you know about how the system functions to detect and protect against attacks (hidden features, nuances, CONOPS, …)

23. Conclusion • 7 NFRs:

24. Conclusion • 7 NFRs:

25. Conclusion • 4 approach vectors: • Co-location of CT, robust protection • Appropriate integration of AT techniques, earlier is better, modified COTS • Controlled foreign participation, don’t cripple your AT during negotiations • Program-unique solutions, leverage the system architecture, risks as opportunities

26. Conclusion • Higher OA compliance doesn’t always mean ‘better’– use BCA process to determine the right balance between OA, AT, and others • AT should not be sacrificed or degraded for the sake of OA

27. References • Anti-Tamper and Software Protection Initiative (AT/SPI) Technology Office, AFRL/RYT. (2009). DoD Anti-Tamper Home Page. Retrieved June 17, 2009 from http://www.at.hpc.mil/index.htm • Chairman of the Joint Chiefs of Staff. (2008). CJCSI 6212.01E – Interoperability and Supportability of Information Technology and National Security Systems. Retrieved November 9, 2009 from Defense Acquisition University at http://www.dtic.mil/cjcs_directives/cdata/unlimit/6212_01.pdf • Dept. of Defense (DoD) Anti-Tamper Executive Agent (ATEA), Secretary of the Air Force for Acquisition and Logistics (SAF/AQL). (2008). Anti-Tamper Guidelines Version 1.3. Washington, DC: U.S. GPO. • Dept. of Navy (DON) Anti-Tamper (AT) Office. (2008). Department of the Navy Anti-Tamper Desk Reference. Washington, DC: U.S. GPO. • Naval Open Architecture: General information. (2008). Naval Open Architecture Strategy. Retrieved June 8, 2009 from Defense Acquisition University at https://acc.dau.mil/GetAttachment.aspx?id=129676&pname=file&aid=40342&lang=en-US • Naval Open Architecture Enterprise Team. (2009). Open Architecture Assessment Tool (Version 2.0) [Computer software]. Available from Defense Acquisition University: https://acc.dau.mil/CommunityBrowser.aspx?id=121180&lang=en-US • Nelson, Eric M. (2008). Open Architecture Technical Principles and Guidelines 1.5.8. Retrieved June 8, 2009 from Defense Acquisition University at https://acc.dau.mil/GetAttachment.aspx?id=170302&pname=file&aid=38742&lang=en-US • Office of the Under Secretary of Defense for Acquisition, Technology, and Logistics. (2000). DoDI 4120-24M - DoD Standardization Program (DSP) Policies and Procedures. Retrieved November 9, 2009 from Defense Technical Information Center at http://www.dtic.mil/whs/directives/corres/html/412024m.htm • Wynne, Michael W. (2004). Amplifying DoDD 5000.1 Guidance Regarding Modular Open Systems Approach (MOSA) Implementation. Retrieved August 13, 2009 from Defense Acquisition University at http://www.acq.osd.mil/osjtf/pdf/wynn_memo_04.pdf

28. Special Thanks • Navy AT Technical Authority Board • Huong Pham, NAVSEA OA TWH • Gerry Walles, NAVAIR OA TWH • Mike Stewart, SPAWAR OA TWH • Maj. David Manka, MARCOR OA SME • John Schofield, NAVSEA Crane OA SME

29. Contact Information John Stein, NAVSEA Crane Anti-Tamper Certificate Holder (812) 854-8335 John.d.stein@navy.mil John.stein@crane.navy.smil.mil