The Domain-Specific Approach to High Assurance Development

Transcription

1 The Domain-Specific Approach to High Assurance Development Andrew Adams-Moran W. Brad Martin 2006 Systems and Software Technology Conference

2 Overview What is a domain-specific approach? Case studies: High Assurance ASN.1 Workbench Cryptol

3 High Assurance Development GIG needs high assurance components High assurance development How do we produce software that Has high assurance of security? Can be shown to have same? And how do we do so repeatedly? This talk is about a language-based technique The Domain-Specific Approach

4 Hang on: Yet Another New Language? Isn t this a bit drastic? What s wrong with my favorite language? Two words: The GIG Billions of lines of code LANGUAGES? WE DON T NEED NO STEENKIN LANGUAGES! Tens of thousands of interoperating, highly complex, net-centric systems How do we assure that? TAP, TAP, TAP...

5 Programming Languages General purpose: Can be used to tackle any problem Examples C C++ Java C# Ada

6 Domain-Specific Languages General purpose languages tend to be good at certain specialized problem areas Would you use C to write a web app? Or Java to write a device driver or operating system kernel? Domain-specific languages take this idea to its logical conclusion

7 Domain-Specific Languages Excel Every formula is a program SQL Every query is a program XML Specifying documents ASN.1 Specifying protocol message formats

8 Getting Domain-Specific! Focus our attention on a single problem space Exploit expert knowledge wherever possible Design the language and/or tools with high assurance in mind... Bake it in!

9 Trade-off: Functionality vs. Assurance Assurance Domain-Specific Approach Functionality

10 Case Studies High Assurance ASN.1 Workbench Cryptol

11 Case Study: High Assurance ASN.1 ASN.1 is a data-description language E.g. for communication protocols Goal Platform-independent data descriptions Given the same semantics by all parties Mutually intelligible and interoperable PDU Content Exchange Format Data Object Authentication / Confidentiality ASN.1 DER PER XER CMS ASN.1 used to specify Structure of packet content Format for data exchange Session Security HTTP, FTP SMTP, X.400 Interoperability and standards: Crucial for the GIG! Transport TCP / IP IP / PPP

12 From ASN.1 to Executable Code X.509 CMIS CMIP MHEG SSL SET X.400 X.500 SNMP ASN.1 specifications are ubiquitous ASN.1 specifications need to be turned into executable code By hand, or By a compiler Compiler Input: ASN.1 description Output: Program code to run application, e.g. on ECU X.509 ASN.1 Compiler ECU code

13 The Challenge of ASN.1 State of practice is to either: Use COTS compiler Write encode/decode routines by hand Neither treats ASN.1 as programming language No link between ASN.1 spec and encode/decode routines Nowhere to stand to build an assurance case If we treat ASN.1 as a programming language, new possibilities come to mind

14 High Assurance ASN.1 Workbench Platform-Independent Protocol Messages Assured Implementation Design Validate ASN.1 Interpreter Test cases/ harnesses Validate ASN.1 implementations X.509, SET, SSL, Specify ASN.1 Tools Model checking C or Java Generate ASN.1 implementations Verify ASN.1 implementations

15 Compiler Structure: Correctness Parser grammar Almost identical to published ASN.1 definition (X.680 grammar) Direct comparison feasible V1 Code generation Multiple intermediate forms (V1, V2, EnDeC) Mathematically motivated transformations between intermediate forms Generated testing confirms correctness V2 EnDe C

16 Compiler Structure: Robustness Mapping to C for each EnDe C construct considered in isolation Each mapping designed with robustness properties in mind: Use ADT-style API for all types The generated code handles all allocation The user handles freeing Encode calculates the buffer size required before encoding; allocates accordingly All buffers have associated lengths All mallocs are guarded All pointer dereferences are guarded Run-time library designed from same principles

17 Using the Workbench Interoperability: ASN.1 standard ASN.1 treated like a language Coherent set of tools, multiple uses High assurance baked-in to the generated code

18 Case Study: Crypto-specification and Formal Tools Cryptol The Language of Cryptography Cryptol: Declarative specification language Language tailored to the crypto domain Designed with feedback from NSA cryptographers Execution and Validation Tools Tool suite for different implementation and verification applications In use by crypto-implementers

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

20 Key Ideas in Cryptol Domain-specific data and control abstractions Sequences Recurrence relations First order No recursion Flexible sizes Data may be viewed in many ways Algorithms parameterized on size Size constraints are explicit in many specs Number of iterations may depend on size A Size-Type system captures and maintains size constraints Choosing what to leave out is critical

21 Usage: Testing Models and test cases Verify crypto implementations Cryptol Tools Cryptol Reference Spec Hand coded Implementation Generates known good tests Reference Test Cases Interpret and Validate Validated Implementation Capture of intermediate vectors simplifies debugging Easy to generate new intermediate vectors as needed

22 Usage: H/W Generation A single correct, executable Cryptol specification can be deployed to a variety of target platforms Cryptol Tools C or Java Target HW FPGA(s) Cryptol Reference Spec C FPGA Java Special purpose processor Special purpose processors One specification to get right Many targets for use

23 AES Performance Results AES performance is comparable to hand optimized VHDL Hodjat & Verbauwhede, FCCM `04, XC2VP Gbps, 4.2 Mbps/slices FPGA Compiler s results on XC2V (a slightly slower chip) Backends Gbps Mbps/slices Cycles per round XST Synplify Pro

24 Usage: Verification Models and test cases Verify crypto implementations Cryptol Tools Cryptol Reference Spec Hand-coded Implementation Symbolic ACL2 Model of Reference Model of Implementation Model checking and theorem proving now in development Enables formal verification between reference and implementation Much higher assurance of correctness

25 Verification Architecture Cryptol Symbolic module Execute and compare Implementation language Symbolic module T a b? = T a b T F T F

26 Conclusions Domain-specific approach: Focuses on the problem at hand Builds high assurance in from the beginning Makes high assurance development tractable without: Sacrificing functionality Lowering our standards

27 Contact Dr. Andrew Adams-Moran SW Millikan Way, Suite 290 Beaverton, OR