Abstract

1. Abstract This talk focuses on the strategy and research agenda developed and being implemented by the High Confidence Software and Systems group at the National Security Agency. As background this talk will highlight several interrelated trends in technology, system requirements, and economics that are creating a new environment that challenges the limits of traditional engineering approaches. Following this introduction our three research components, which outline a continuum of research and development from theory to tool development to experimental evaluation and validation on real-world problems, will be presented. During the course of this discussion, each of these three research components will be motivated through an examination of a specific research project that is being pursued.

2. High Confidence Software and Systems:An NSA Perspective Brad Martin National Security Agency 7th Workshop on Elliptic Curve Cryptography

3. Discussion Points • Introduction & Motivation • U.S. National (& NSA) Needs • NSA HCSS Research Threads & Initiatives (with a cryptographic flavor) • Vision & Summary

4. Introduction & Motivation

5. High Confidence System A system that behaves in a well-understood and predictable fashion. One that must withstand malicious attacks as well as naturally occurring hazards, and must not cause or contribute to accidents or unacceptable losses.

6. Why HCSS? • 1999 PITAC Report to the U.S. President • #1 Technical Research Priority – SW Research • Technologies to build reliable software are inadequate • Complexity of software systems are growing rapidly • The Nation depends on fragile software • Major Recommendation: Make software research an absolute priority!

7. Why (continue) HCSS? • FY2003 Supplement to the President’s Budget (Blue Book) • U.S. Priorities • New hardware and software assurance technologies • … • Major Research Challenges • High-assurance software design for critical systems. • … • U.S. NITRD HCSS Program Component Area • Rapidly expanding size • Rapidly expanding complexity “Twin horns of a difficult dilemma for contemporary software and systems.”

8. Interrelated Software Trends • Technology Trends • Increasing reliance on software • Increasing reliance on a commodity technology base • Increasing interconnectivity • Requirements Trends • Increasing scale and complexity • Increasing stress due to performance demands • Increasing exposure to compromise • Economic Trends • Accelerating development cycles • Expanding developer base

9. Unique Challenges of Software-based Systems • Software lacks a true engineering tradition • Software products are essentially invisible • Software is readily modified

10. U.S. National Needs

11. National HCSS Needs2 NSA • Foundations of assurance and composition • Includes modeling and reasoning about high confidence properties, composition and decomposition, specification, and safety and security foundations • Fault prevention, detection, analysis, & recovery • Includes monitoring, detection, and adaptive response

12. National HCSS Needs2 NSA • Correct-by-construction software technology • Includes languages, tools, and environments • Evidence technologies for V&V • Experimentation and reference implementations • Forensic and diagnostic tools

13. NSA HCSS Research Threads & Initiatives

14. Capability Threads • Secure by Design Capability focused on helping software engineers to achieve assured designs, and to reduce the burdensome cost of certifying the security of complex information systems. • Trusted by Analysis Capability encompassing activities contributing to an assessment of the confidence one can have in a system whose construction is out of our control and whose assurance is a mystery. • Containment Capability focused on the containment challenge of balancing granularity of protection against ease of use and cost

15. NSA HCSS Roadmap • Foundations Developing the supporting theory and scientific basis for HCSS • Tools and Technology Provide a means to build high confidence systems of the future through the development of a technology capability that can apply the theoretical foundations of high confidence • Engineering and Experimentation Vehicle for the technology capability being built to be shown to work effectively and efficiently

16. FoundationsStatus/Issues Previous National research investments in this area have not been adequately focused on creating a science. Software development still lacks a semantic basis and technology support for reasoning about central engineering issues (design, implementations, cross-cutting properties, and the effects they produce on the systems they control).

17. Foundations Initiative • Certification Study • Foundations of Validation and Evidence • Automated Theorem Proving • Foundations of Modeling and Reasoning • Protocol Specification/Synthesis/Analysis • Foundations of Specification, Composition, and Reasoning • Intrusion Aware Design • Foundations of Modeling, Abstraction, and Reasoning • Secure Agent Architecures • Foundations of Reasoning, Modeling, and Composition • Specware • Foundations of Composition, Modeling, and Reasoning . . .

18. ProtocolSpecification/Synthesis/Analysis

19. game theory e v o l v i n g s p e c s Directions p r o t o c o l s

20. Especs of protocols • Develop security structures by • composition (bottom-up) • refinement (top-down) • Transformation • Programming and synthesis

21. building blocks • message component actor • rewriter of protocol steps Especs of protocols • Protocol derivation system • Components • Refinements • transformations

22. Game theory of security • Secure communication is a team game • played between • the System and • the Environment (possibly malicious) • protocol is a strategy for the System • attack is a strategy for the Environment

23. as payoffs Game theory of security • Necessary to capture dynamics of • information/entropy • strength of cryptographic operations • computational cost • to assess DoS threats • redundancy • to detect covert channels • sweet spot in tradeoffs • e.g. PKI vs authentication

24. Derivation Framework • Protocols are constructed from: • Components (e.g. Diffie-Hellman key exchange) by applying a series of operations: • Composition (e.g. putting two protocols together) • Refinement (e.g. replacing a plaintext nonce with an encrypted nonce), and • Transformation (e.g. movement of data from one protocol message to another earlier message) • Properties accumulate as a derivation proceeds.

25. Derivation Framework • Protocol Derivation System: • Systematizes the practice of building protocols from standard sub-protocols. Useful for: • protocol analysis and understanding. • organizing related protocols in taxonomies. • protocol synthesis. • Protocol Logic: • Correctness proofs follow derivation steps. • Rigorous treatment of protocol composition.

26. Tools and TechnologyStatus/Issues The kinds of systems we want to build are beyond the complexity manageable by sheer human effort. As in other scientific and engineering disciplines, computer aided design and analysis tools serve as enablers and multipliers of human capabilities to design, analyze, and reason about complex systems. Main stream general purpose programming languages, design tools, and verification systems are not expressive enough to enable or enforce complex system properties.

27. Tools and Technologies Initiative • Formal Analysis and Annotation Toolkit • HW/SW Verification and Validation • Cryptol • Domain Specific Programming Languages, Validation, Evidence • Vulnerability Discovery • Detection, Evidence • Program Verification Condition Generation • Validation, Detection, Evidence • Lightweight Tools Evaluation • Pathfinder Model Checker (NASA Ames), Extended Static Checking (HP), PolySpace (PolySpace Inc.) . . .

28. CryptolCryptographic Programming Language

29. tension Programming Language Concepts Application Concepts Domain-specific languages • Domain-specific languages (DSLs) attempt to bridge a semantic gap • Programs are written in domain-specific terms • Programs “execute” as if a regular program had been written

30. Challenges in Implementation of Cryptography Variety of targetarchitectures Requires skills in mathand programming Variety of requirements Validation is tedious

31. Cryptol - Declarative Language of Cryptography • Developed over the last three years • Designed with feedback from expert cryptographers • In use at NSA and General Dynamics • Currently partnering with Rockwell Collins, Xilinx, Certicom

32. One Specification - Many Uses Assured Implementation Domain-Specific Design Capture Validate Design Models and test cases Verify crypto implementations Cryptol Interpreter w0=u-I*I modp + u-I*wl mod p s=f*(w0 +pw2) (mod q) Cryptol Tools Build Target HW code FPGA(s) C or Java Special purpose processor

33. Model crypto algorithm Clear and unambiguous Structure and guide implementation Validate Design Cryptol Interpreter w0=u-I*I modp + u-I*wl mod p s=f*(w0 +pw2) (mod q) Build Domain-Specific Design Capture rc6ks : {a} (w >= width a) => [a][8] -> [r+2][2][w]; rc6ks key = split (rs >>> (v - 3 * nk)) where { c = max (1, (width key + 3) / (w / 8)); v = 3 * max (c, nk); initS = [pw (pw+qw) ..] @@ [0 .. (nk-1)]; padKey : [4*c][8]; padKey = key # zero; initL : [c][w]; initL = split (join padKey); ss = [| (s+a+b) <<< 3 || s <- initS # ss || a <- [0] # ss || b <- [0] # ls |]; ls = [| (l+a+b) <<< (a+b) || l <- initL # ls || a <- ss || b <- [0] # ls |]; rs = ss @@ [(v-nk) .. (v-1)]; }; Cryptol> :trace rc6ks.ss

34. Cryptol Well-Suited for Reference Specification • Executable • Run tests and debug for correctness • Generate test cases • Domain Specific • Naturally understandable to crypto-mathematicians • Simplifies expression, inspection, reuse • Declarative • No particular implementation is assumed • Useful for multiple purposes – test, generation, model building, etc. • Retargetable to a wide variety of architectures • Concise • Unambiguous • Precise syntax and semantics • Independent of underlying machine models

35. Always use “known good tests” Built in capture of intermediate vectors simplifies debugging and validation Test cases Cryptol Tools Implementation:Testing Cryptol Reference Spec Hand coded Implementation Reference Test Cases Verify Validated Implementation

36. BDD generator now in development Will enable formal verification between Reference and Implementation Much higher assurance of correctness Models Cryptol Tools Implementation:Verification Cryptol Reference Spec Hand-coded Implementation Model ofImplementation Model of Reference BDDs ACL2

37. One specification to ‘get right’ Many targets for use Cryptol Tools Target HW code FPGA(s) C or Java Special purpose processor Implementation:Code Generation A single correct, executable Cryptol specification can be deployed to a variety of target platforms… C Java Cryptol Reference Spec FPGA future Special purpose processor

38. Engineering and ExperimentationStatus/Issues Tools and techniques must be shown to work efficiently and effectively at appropriate scales for a healthy transition to take place. In the past experimentation at appropriate scales has not taken place, and therefore technology transition has been considerably hamstrung.

39. Engineering & Experimentation Initiative • Pauli Kernel • Programming Languages, Modeling, Abstraction, Reasoning, Evidence, and Validation • BioSpark • Reliability Engineering, Languages, Evidence, and Metrics • Smart Card Applet Generator • Modeling, Composition, Reasoning, Programming Languages, Validation, and Evidence • Haskell on Bare Metal • Programming Languages, Validation, and Evidence • Microprocessor Development Environment • Reasoning, Modeling, Programming Languages, Simulation, Validation, and Evidence . . .

40. AAMP7 Development Environment

41. AAMP7 Background • AAMP family of microprocessor have been used in applications ranging from wireless communications products to avionics • AAMP7 latest member of the AAMP family • Distinguishing architectural feature: intrinsic partitioning – allows the integration of multiple applications in a way that allows for their assured separation (implemented directly in the micro-architecture)

42. Cryptol Spec ACL2 Spec Theorems Generate Cryptol -> ACL2 Development of a translator from Cryptol to ACL2, providing support for the development of formal proofs about Cryptol programs

43. Cryptol Spec ACL2 Spec Theorems Generate Generate AAMP7 Code AAMP7 Code Generation Architecture provides a proof that Cryptol has generated a correct AAMP7 implementation

44. Cryptol Spec ACL2 Spec Theorems Generate Generate Proof AAMP7 Code Code Proof Infrastructure Infrastructure supports proofs that the code operates properly

45. Cryptol Spec ACL2 Spec Theorems Generate Generate Proof Handwritten AAMP7 Code AAMP7 Code AAMP7 ISA model Configuration Backplane ROM image FACADE (simulator interface) AAMP7 Development Environment The partitioning development environment will make it possible to develop AAMP7 MILS applications by managing information flow between partitions without regard to the specifics of the AAMP7 intrinsic partitioning mechanism.

46. Vision

47. Important Elements • People • Process • Technology • and when it applies….

48. A Vision Near Term • Be a technology enabler – allowing others to reach beyond their grasp (both researchers and developers) • Develop a true science for HCSS Eng. Long Term • Motivate the general use of HCSS Eng. beyond domains requiring HCSS

49. NSA’s HCSS focus is on: • Contributing to a science for HCSS • Developing tools that can act as enablers and multipliers of human capabilities to design, analyze, and reason about complex systems • Real World Problems / Technology Transfer “Skate to where the puck is going” - Wayne Gretzky

50. References • PITAC Report to the President. Information Technology Research: Investing in our Future. February 1999. • National Science and Technology Council Interagency Working Group on ITR&D. Strengthening National, Homeland, and Economic Security, NITR&D Supplement to the President’s Budget. July 2002.