Refresher: Applied Cryptography (emphasis on common tools for secure processors) Chris Fletcher Fall 2017, 598 CLF, UIUC
Complementary reading Intel SGX Explained (ISE) Victor Costan, Srini Devadas https://eprint.iacr.org/2016/086.pdf Pages 31-42 Read, use as reference. Don t need to memorize. This lecture also takes material from Security Basics by Ruby Lee (Hot chips 2016)
Paper presentations Email me if You don t see your name on website for presentation & You haven t already gotten an email from me We have run out of days! If you aren t assigned yet, select from Additional reads papers Expectations for presentation Conference talk length (15-20 min) w/ slides Slides will be posted to website John Alsop on bat
Security objectives Privacy Alice sends msg m to Bob. Only Bob should be able to read m. Integrity Alice sends msgs m 1 m n to Bob. Authenticity Bob receives msg p. Bob can verify p \in m 1 m n. Freshness Bob has received msgs p 1 p n. Bob can verify p i = m i. Identity Availability Bob wants to know if Alice is really Alice Does Bob ever see the n messages?
Symmetric cryptography Encrypt key (p) = ciphertext Decrypt key (c) = plaintext Privacy Shared key (random bits) between encrypter/decrypter Key issues: generating a truly random key, keeping the key secret
One-time pad Goal: encrypt L bits key = [rand(0, 1) for i = 1 L] Encrypt key (bit i ) = bit i key i Decrypt key (bit i ) = bit i key i = xor Perfect secrecy Problem: key = L Basic mixing w/ XOR used by many modern cryptosystems (symmetric and asymmetric)
Block ciphers (e.g., DES, AES) Encrypt key (.), Decrypt key (.) take s-bit inputs One-time pads Encrypt arbitrary length message? Break into s-bit chunks. But how? P i = P j C i = C j When i!= j, this is a problem
Ciphertext travels with auxiliary state Recall: need CBC or CTR for randomized encryption Encrypt key (p) = c = {Ctr, ciphertext} Decrypt key (c) = plaintext Ctr sometimes called IV (initialization vector) Send increasing counter: sender must remember count Send random IV: must ensure IV is never re-used
Block cipher implementation Break into rounds e.g., Fiestel structure Once again, approximations to One-time pads = xor Single round encryption: Encrypt key (plaintext = {L 0, R 0 }): L 1 = R 0 Behavior depends R 1 = L 0 F(R 0, key) on key, R 0 is public = return {L 1, R 1 } attackable in HW Decrypt key (ciphertext = {L 1, R 1 }): R 0 = L 1 L 0 = R 1 F(L 1, key) return {L 0, R 0 } Decrypt key (Encrypt key ({L 0, R 0 })) = Decrypt key ( {R 0, L 0 F(R 0, key)} ) = {L 0 F(R 0, key) F(R 0, key), R 0 } = {L 0, R 0 }
Cryptographic hashing (e.g., SHA1 - SHA3) Hash(p) = digest p = arbitrarily long, digest length = λ is system property One way: If Hash(p) = digest: cannot determine p given digest and Hash(.) Avalanche: Bob Smith got an A+ in ELE386 in Spring 2005 01eace851b72386c46 Bob Smith got an B+ in ELE386 in Spring 2005 936f8991c111f2cefaw Ideally, we would have Random oracle model Hash(p): static Dict if Dict[in] == null: Dict[in] = flip λ fair coins return D[in]
Message Authentication Codes Privacy + Authenticity/Freshness? msg Keyed hash authenticity MAC = Hash(ciphertext key) msg = {MAC, ciphertext} w/o key, cannot forge MAC w/ key, can check MAC against ciphertext = concatenation Keyed hash + nonce freshness MAC = Hash(ciphertext i key i) msg = {MAC, i, ciphertext i } Nonce may be random or counter
Authenticated encryption Combine encryption scheme w/ extra mechanism for integrity Dedicated modes (e.g., GCM) for creating authentication tags Encryption then MAC
Secure processor (trusted) Protecting memory Privacy Randomized encryption Store {Ctr i, ciphertext i } tuples externally Integrity Authenticity Store {MAC i, Ctr i, ciphertext i } tuples externally Freshness Idea: Re-use Ctr i as the nonce! Totally broken. We store Ctr i externally, Adversary can give us any {MAC j, Ctr j, ciphertext j }. DRAM, Flash, Disk, Cold storage Fix: store all nonces inside processor Problem: Too much storage (~64bits / block of external memory)
Integrity trees Most common: Merkle tree = freshness w/ O(1) on-chip storage Secure processor (trusted) root = Hash(f 2i f 2i+1 ) root Check B 0? f i = Hash(g 2i g 2i+1 ) f 0 f 1 g i = Hash(h 2i h 2i+1 ) g 0 g 1 g 2 g 3 h i = Hash(B i ) h 0 h 1 h 2 h 3 h 4 h 5 h 6 h 7 B 0 B 1 B 2 B 3 B 4 B 5 B 6 B 7
Public key cryptography (e.g., RSA, EC, lattice-based) Two keys: private key (key_priv keep secret), public key(key_pub safe to release publicly) Encryption Encrypt key_pub (p) = ciphertext Decrypt key_priv (c) = plaintext Mailbox location is public, mailbox key is private Digital signatures Proof that msg comes from whoever owns private key corresponding to key_pub Sign key_priv (msg) := Hash(msg); signature = Encrypt key_priv (h) return {signature, msg} Verify step: Decrypt key_pub (signature) =? Hash(msg)
Public key crypto: RSA (functionality not security) First instance of public key crypto (circa 1978) Choose RSA modulus n We will work in group (Z* n, *); Z* n = {x < n gcd(x, n) = 1} Choose key_pub = e randomly, choose key_priv = d s.t. d*e 1 mod Z* n Encrypt e (m) = c = (m e ) mod n Decrypt d (m e ) = (m e ) d mod n = m (1 + Z*n k) mod n By our definition of d = m (mod n) By Euler s theorem Crucial security issues: how to choose n so that attacker can t get d
RSA issues Read out decryption key d via shared resource attacks Padding schemes How to get randomized encryption? E.g., CBC, CTR modes. If e is small, how to guarantee wrap-around mod n.
Public key equivocation Recall w/ digital signatures: Proof that msg comes from whoever owns private key corresponding to key_pub Problem: How do you know who key_pub belongs to? Key parties, https://keybase.io/ Web of trust: Person i posts certificate i = {name/etc i, key_pub i } Person j signs certificate i via key_priv j If you trust person j, you can now trust certificate i Many people can sign (endorse) certificate i to improve confidence.
Public key infrastructures (PKIs) Problem: Trust in web of trust is not black and white PKI: endorsement = chain of trust back to single key Root Certificate authority (RCA) Certificate authorities (CAs) Chain of trust: certificate i = {name/etc i, key_pub i } certificate i signed with key_priv CA_1 key_pub CA_1 signed with key_priv RCA key_pub RCA boxed with your machine. Hardware security module (HSM) e.g., IBM 4758 key_priv RCA key_pub RCA key_priv CA_0, key_priv CA_1, key_pub CA_0, key_pub CA_1,
Secure channels Asymetric crypto is slow, symmetric crypto is fast Privacy + Authenticity/Freshness msg Idea: establish key (symmetric) via Encrypt key_pub (key) Need to verify key_pub via PKI first
Putting it together: Secure Processor Init Initialization: Remote attestation Secure boot Computing a measurement (cryptographic hash) of software running on secure processor PKI Verifying that the measurement comes from the expected secure processor
Secure boot: Creating the measurement SHA-1 = cryptographic hash function Recall: Hash(p) = digest, one-way Figure: Intel SGX Explained; Victor Costan and Srini Devadas
PKI: Verifying the measurement