Cryptography Lecture 9.

Slides:



Advertisements
Similar presentations
Side Channel Attacks on CBC Encrypted Messages in the PKCS#7 Format
Advertisements

CIS 5371 Cryptography 3b. Pseudorandomness.
Asymmetric Cryptography part 1 & 2 Haya Shulman Many thanks to Amir Herzberg who donated some of the slides from
Computer Security CS 426 Lecture 3
Ryan Henry I 538 /B 609 : Introduction to Cryptography.
CS555Spring 2012/Topic 111 Cryptography CS 555 Topic 11: Encryption Modes and CCA Security.
IND-CPA and IND-CCA Concepts Summary  Basic Encryption Security Definition: IND-CPA  Strong Encryption Security Definition: IND-CCA  IND-CPA, IND-CCA.
Cryptography Lecture 2 Arpita Patra. Summary of Last Class  Introduction  Secure Communication in Symmetric Key setting >> SKE is the required primitive.
Cryptography Lecture 4 Arpita Patra.
CS555Spring 2012/Topic 71 Cryptography CS 555 Topic 7: Stream Ciphers and CPA Security.
CS555Spring 2012/Topic 81 Cryptography CS 555 Topic 8: Pseudorandom Functions and CPA Security.
Cryptography Lecture 8 Arpita Patra © Arpita Patra.
Cryptography Lecture 9 Arpita Patra © Arpita Patra.
CS555Spring 2012/Topic 151 Cryptography CS 555 Topic 15: HMAC, Combining Encryption & Authentication.
Cryptography Lecture 5 Arpita Patra © Arpita Patra.
Updated Office Hours Tuesday: 10:30 AM-11:30 AM
Authenticated encryption
Modern symmetric-key Encryption
Secrecy of (fixed-length) stream ciphers
Topic 11: Authenticated Encryption + CCA-Security
Cryptography Lecture 3.
Cryptography Lecture 13.
Cryptography Lecture 12.
Cryptography Lecture 4.
Topic 5: Constructing Secure Encryption Schemes
Cryptography Lecture 16.
B504/I538: Introduction to Cryptography
B504/I538: Introduction to Cryptography
Cryptography Lecture 5.
Cryptography Lecture 3 Arpita Patra © Arpita Patra.
Cryptography Lecture 6.
Cryptography Lecture 10.
Topic 7: Pseudorandom Functions and CPA-Security
B504/I538: Introduction to Cryptography
Cryptography Lecture 11 Arpita Patra © Arpita Patra.
Cryptography Lecture 7 Arpita Patra © Arpita Patra.
Cryptography Lecture 7.
Cryptography Lecture 25.
Cryptography Lecture 7 Arpita Patra © Arpita Patra.
B504/I538: Introduction to Cryptography
Cryptography Lecture 11.
Cryptography Lecture 5 Arpita Patra © Arpita Patra.
Cryptography Lecture 12 Arpita Patra © Arpita Patra.
Cryptography Lecture 4.
Cryptography Lecture 5.
Cryptography Lecture 8.
Block Ciphers (Crypto 2)
Cryptography Lecture 5 Arpita Patra © Arpita Patra.
Cryptography Lecture 11.
Cryptography Lecture 9.
Cryptography Lecture 12.
Topic 13: Message Authentication Code
Cryptography Lecture 6.
Cryptography Lecture 7.
Cryptography Lecture 9 Arpita Patra © Arpita Patra.
Cryptography Lecture 3.
Cryptography Lecture 10.
Cryptography Lecture 9.
Cryptography Lecture 11.
Cryptography Lecture 10.
Cryptography Lecture 6.
Cryptography Lecture 16.
Cryptography Lecture 21.
Cryptography Lecture 25.
Cryptography Lecture 24.
Cryptography Lecture 23.
Cryptography Lecture 15.
Secret-Key Encryption
Presentation transcript:

Cryptography Lecture 9

Breaking encryption schemes Recall encryption scheme from last time: Enck(m) = < r, Fk(r)  m > If r repeats, security fails Exactly analogous to multiple encryptions using the (pseudo)one-time pad scheme

Breaking encryption schemes Let F be a block cipher Two general CPA-attacks on a scheme F not used correctly (Function of) plaintext directly leaked in ciphertext F not used with a random, unknown key E.g., Enck(m) = < r, Fr(m) > Cause F to be evaluated on the same input twice E.g., Enck(m1, m2) = < r, Fk(r)  m1, Fk(m1)  m2 > Any deterministic scheme

Stream ciphers

Stream ciphers As we defined them, PRGs are limited They have fixed-length output They produce output in “one shot” In practice, PRGs are based on stream ciphers Can be viewed as producing an “infinite” stream of pseudorandom bits, on demand More flexible, more efficient

Stream ciphers Pair of efficient, deterministic algorithms (Init, GetBits) Init takes a seed s (and optional IV), and outputs initial state st0 GetBits takes the current state st and outputs a bit y along with updated state st’ In practice, y would be a block rather than a bit

Stream ciphers Can use (Init, GetBits) to generate any desired number of output bits from an initial seed s IV Init GetBits GetBits st0 st1 st2 y1 y2

Stream ciphers A stream cipher is secure (informally) if the output stream generated from a uniform seed is pseudorandom I.e., regardless of how long the output stream is (so long as it is polynomial) See book for formal definition

Modes of operation Stream-cipher modes of operation Synchronized Unsynchronized

Synchronized mode Sender and receiver maintain state (i.e., they are stateful), and must be synchronized Makes sense in the context of a limited-time communication session where messages are received in order, without being lost

Synchronized mode s s Init Init st0 st0 m1 y1 y1 c1 GetBits  

Unsynchronized mode Choose random IV to encrypt next message Similar to the first CPA-secure scheme we saw But “natively” handles arbitrary-length messages with better ciphertext expansion

Unsynchronized mode s IV IV s Init Init st0 st0 m y y c GetBits  

Unsynchronized mode Note that for security, we require the stream cipher to be a PRF I.e., for fixed seed s, the output of the stream cipher when using different IVs should all look uniform and independent

So far… Have been assuming only a passive, eavesdropping attacker (Even if it can carry out chosen-plaintext attacks)

c1  Enck(m1) … ct  Enck(mt) ... k k ct m1, …, mt c1  Enck(m1) … ct  Enck(mt)

So far… Have been assuming only a passive, eavesdropping attacker What if the attacker can be active? E.g., interfering with the communication channel

c c’ k k c  Enck(m) m’  Deck(c')

Malleability (Informal:) A scheme is malleable if it is possible to modify a ciphertext and thereby cause a predictable change to the plaintext Malleability can be dangerous! E.g., encrypted bank transactions

Malleability All the schemes we have seen so far are malleable! E.g., the one-time pad...

c1c2…cn c1c2…c’n k k c := (m1m2…mn)k m1m2…m’n := (c1c2…c’n)k

Malleability All the schemes we have seen so far are malleable! E.g., the one-time pad... Perfect secrecy does not imply non-malleability! Similar attacks (and sometimes others) on all the schemes we have seen so far

So far… Have been assuming only a passive, eavesdropping attacker What if the attacker can be active? E.g., “impersonating” the sender; injecting communication on the channel

c k k c  Enck(m) m’  Deck(c') c’ m’

Chosen-ciphertext attacks Models settings in which the attacker can influence what gets decrypted, and observe the effects How to model? Allow attacker to submit ciphertexts of its choice* to the receiver, and learn the corresponding plaintext In addition to being able to carry out a chosen-plaintext attack! *With one restriction, described next

CCA-security Define a randomized exp’t PrivCCAA,(n): k  Gen(1n) A(1n) interacts with an encryption oracle Enck(·), and a decryption oracle Deck(·), and then outputs m0, m1 of the same length b  {0,1}, c  Enck(mb), give c to A A can continue to interact with Enck(·), Deck(·), but may not request decryption of c A outputs b’; A succeeds if b = b’, and experiment evaluates to 1 in this case

CCA-security  is secure against chosen-ciphertext attacks (CCA-secure) if for all PPT attackers A, there is a negligible function  such that Pr[PrivCCAA,(n) = 1] ≤ ½ + (n)

Chosen-ciphertext attacks and malleability If a scheme is malleable, then it cannot be CCA-secure Modify c, submit modified ciphertext c’ to the decryption oracle and determine original message based on the result CCA-security implies non-malleability

CCA-security In the definition of CCA-security, the attacker can obtain the decryption of any ciphertext of its choice (besides the challenge ciphertext) Is this realistic? We show a scenario where: One bit about decrypted ciphertexts is leaked The scenario occurs in the real world! This can be exploited to learn the entire plaintext

CBC mode m1 m2 mt IV    … Fk Fk Fk c0 c1 c2 ct

Arbitrary-length messages? Message  encoded data  ciphertext PKCS #5 encoding: Assume message is an integral # of bytes Let L be the block length (in bytes) of the cipher Let b ≥ 1 be # of bytes that need to be appended to the message to get length a multiple of L 1 ≤ b ≤ L; note b  0 Append b (encoded in 1 byte), b times I.e., if 3 bytes of padding are needed, append 0x030303

Decryption? To decrypt: Use CBC-mode decryption to obtain encoded data Say the final byte of encoded data has value b If b=0 or b > L, return “error” If final b bytes of encoded data are not all equal to b, return “error” Otherwise, strip off the final b bytes of the encoded data, and output what remains as the message

Example (L=8) AB 01 4F 21 00 7C 02 02 AB 01 4F 21 00 7C 02 02

c k k c  Enck(m) Deck(c') c’ error? Padding oracle!

Padding oracles Padding oracles are frequently present in, e.g., web applications Even if an error is not explicitly returned, an attacker might be able to detect differences in timing, behavior, etc.

Main idea of the attack Consider a two-block ciphertext IV, c Encoded data = Fk-1(c)  IV Main observation: If an attacker modifies the ith byte of IV, this causes a predictable change (only) to the ith byte of the encoded data

 = Fk-1(c): IV: “Success” “Error” XX XX XX XX XX XX XX XX AB 01 4F 21 00 7C 02 9E = Encoded data: XX XX XX 06 XX 06 XX XX 06 06 XX 06 XX “Success” “Error”