1 / 26

Formal Verification of Block Ciphers A Case Study: The Advanced ...

Gabriel
Download Presentation

Formal Verification of Block Ciphers A Case Study: The Advanced ...

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. Formal Verification of Block Ciphers A Case Study: The Advanced Encryption Standard (AES) Eric Smith and David Dill Stanford University ewsmith@stanford.edu dill@cs.stanford.edu

    3. Motivation Cryptography is everywhere Voting, banking, e-commerce, military Cryptography is crucial Errors or weaknesses can undermine a whole system. Cryptography is worth getting right Should be formally verified... ...if we can make it easy enough! Our goal: Make the verification of block cipher implementations largely automatic.

    4. Talk Outline Block ciphers and what we prove Example : AES General Java verification framework Application to block ciphers Case study: AES Strategies for reasoning about crypto code.

    5. Block ciphers Encrypt and decrypt using a shared, secret key. Operate on a small amount of data. Are the building blocks of larger systems. Many important examples: AES, DES, Triple DES, Blowfish, Twofish, IDEA, RC6

    6. What we verify Not the cryptographic strength of the algorithms. Instead, we check the implementations of those algorithms. Complicated by aggressive optimizations.

    7. One approach We could prove the inversion property: Decrypt(Encrypt(message,key),key) = message, for all messages and all keys. Guarantees no data loss But a trivial, insecure implementation satisfies inversion. Also, ignores key expansion.

    8. Our approach Prove that the implementation matches the official spec. For AES, the spec comes from FIPS-197. Formalized the AES spec in ACL2. Can run the spec on test vectors. Reused the spec to check three implementations.

    9. Example: AES Input: 128 bits of plaintext Output: 128 bits of ciphertext Key: 128, 192, or 256 bits Three interesting operations: key expansion, encrypt, and decrypt.

    10. Key expansion Takes 128-bit key and generates 1408 bits of key material. Fairly complex S-box lookups, word rotation, xor with “round constant”

    11. Encrypt Roughly speaking, performs 10 “rounds”. Operates on the “state,” a 4x4 array of bytes Each round: SubBytes – look up values in s-box. ShiftRows – each row shifts a different amount MixColumns – uses finite field multiplication, XOR AddRoundKey – uses XOR

    12. Decrypt Same as encrypt, except... uses the inverses of the subrounds. does the subrounds in reverse order. Use key material in opposite order (Implementation hack: some subrounds commute.)

    13. Java code From bouncycastle.org Three AES versions: light, regular, and fast Checked all three. Even “light” version has optimizations.

    14. Packing/Unpacking Data formats differ between spec and implementation. Ex: the “state” during AES encryption Spec: 4x4 array of unsigned bytes Implementation four, 32-bit signed words Ex: expanded key for AES Spec: 44x4 array of unsigned bytes Implementation: 11x4 array of signed 32-bit words

    15. Inner loop of “light” AES encrypt

    16. Final Theorem for encryptBlock If you run encryptBlock until it returns... ...then the AES “state” upon return has a certain value. imp-encrypt(state)=pack(spec-encrypt(unpack(state)))

    17. Java Verification Framework Verification is on bytecode, not Java source. Uses formal ACL2 model of JVM. Machine state is a LISP object (tuple). The model specifies how each JVM instruction affects that state. Theorems are about runs of the machine. Running the machine when method M is loaded has such-and-such affect.

    18. Cutpoint Framework Makes operational semantics “look like” Hoare logic. Just annotate with precondition, postcondition and loop invariants. Splits the code into finite-length paths. Check that all the paths preserve annotations. Appeal to generic result to get partial correctness.

    19. Symbolic Execution Check each path by symbolic execution. Start with an arbitrary state satisfying the annotation. Symbolically execute until the next annotated point. Results in a new symbolic state, expressed in terms of the original state. Must then show that the annotations are true in the new state.

    20. Automation Our tool automatically builds ACL2 proof script from user annotations. Can also automatically generate some annotations Type facts Simple loop bounds (but overflow complicates this) More room for improvement

    21. Applying this to block ciphers We developed a set of domain-specific strategies. They make use of nice features of crypto code.

    22. Crypto code Crypto code is nice to analyze. No complicated data structures No recursion Lots of for loops Annotations can be written using spec functions May need to pack / unpack too. Ex: “Unpack to spec format, apply two rounds of AES, pack back into implementation format.”

    23. Strategies Handle the smallest code chunks that match up conveniently with the spec. Handle key expansion, encryption, decryption separately. Handle mcol (column mixing) subroutine separately. Handle one or two rounds of encryption at a time – whatever one inner loop iteration does.

    24. Strategies (cont.) Observation: Crypto code has lots of bit vector operations. Strategy: Call a bit vector solver when only bit vector operations are left. We use STP.

    25. STP Developed by groupmate Vijay Ganesh. Often much faster than ACL2. Can save us from proving bit vector lemmas. Experience led to new “-x” option to simplify XORs. Speeds up our proofs a lot. Still takes some work to get things down to bit vectors.

    26. Strategies (cont.) Observation: Crypto code has lots of for-loops. Observation: Loop bounds are usually known. Ex: 10 rounds for 128-bit AES encryption Strategy: Unroll loops when possible. Might then be able to call STP. Doesn't always work.

    27. Strategies (cont.) Crypto loop counters often don't assume too many different values. Most so far is AES key expansion: i=4 to 43. Can split into one case for each possible value of the loop counter. Replace one harder proof (symbolic index) with 40 easier proofs (concrete index).

    28. Strategies (cont.) Observation: Crypto code uses lots of lookup tables. Strategy: Find the formula for the ith element in terms of i (using notions from the spec). Tool to automatically check the formula and generate appropriate lemma.

    29. Table example

    30. Progress so far Done: AES light, regular, and fast. In progress: DES. Lots of infrastructure development done. Ultimate goal is to make this nearly automatic.

    31. Future Work Verify some more block ciphers. Make infrastructure more robust. Look for more sources of automation. Possibly apply this approach to other languages (maybe C?).

    32. Related work Functional Correctness Proofs of Encryption Algorithms (Duan, Hurd, Li, Owens, Slind, Zhang) Proves inversion of several block ciphers specified in higher order logic. Cryptol language from Galois Connections. Can be compiled down to an implementation using (mostly) verified compiler transformations.

    33. Related Work (cont.) Formal Verification by Specification Extraction (Yin, Knight, Strunk, Weimer) Used a tool called Echo to verify AES. Transforms the code by undoing optimizations.

More Related