Protocol Design Jens Hermans & Roel Peeters, KU Leuven/COSIC
The ideal protocol … serves exactly the application’s needs … comes at a low cost … is simple (elegant) … is efficiently implementable … is provably secure … does not exist
Before you start, know this Protocol design is hard !!! Roughly half of the protocol papers start with “Attack on …” or “On the (claimed) security of …” You need someone that constantly challenges you Iterate, iterate, iterate > 1,5 years many many iterations
Overview Understand Your Application Common Goals Common Design Choices Building Blocks Basic Protocols Proofs Common Pitfalls
Understand Your Application This is the most important thing whether selecting an existing protocol or designing your own
Constraints Examples: Battery operated Limited storage Entire protocol < 400 ms (passive RFID tags) Needs to work (also) offline But also what is already available? E.g. AES instruction in processor, ECC-coprocessor already on chip
Goals Security Authentication (Entity / Data) Data Confidentiality Privacy … Efficiency (i.e. low cost) Simplicity Verifiability
Attacker capabilities Who is your attacker?
Example: Unlock front door
Example: Public Transportation
Example: Smartmeter
Example: Container Tracking
Example: Medicine tracking
Costs Different types of cost: Chip area Power Energy Speed Communication rounds Cost at the backend …
Common Goals
Eve Bob Alice Data Authentication
Hello, I am Alice Bob Eve Entity Authentication
Bob Alice Non-repudiation
Eve Bob Alice Data Confidentiality
Eve ? ? Privacy
Bob Eve Prevent Denial of Service
Eve Protect against key leakage (forward/backward secrecy)
Common Design Choices
Backend Processing Trust? Auth Alice Alice: € 100 … € 100
Symmetric/Asymmetric Key Symmetric Scale: O(N 2 ) keys, central authority, or share keys (=risk) Efficient Asymmetric O(N) keys
Key Management Use key only for one function: e.g., either MAC or ENC (or AE) Protect your keys HW security Key encapsulation (brute-force risk) Secret sharing … When to trust a key?
Key Updates 2006 2016 Swap keys (different algorithm?) Other parties: Central Authority? Individual notification? Linking?
Key Updates RFID Scene: change key every time (“improves” privacy) Problems Power to overwrite key in mem? 2x mem required Desynchronisation Inherent issues of symmetric key
Mutual Authentication Devices only respond to authorised queries Enhanced privacy, side-channel resistance First reader authentication, then tag authentication Optional data transfer Prevent DoS attacks when using coupons
Secure Hardware
Building Blocks
Key Derivation Function
Key Derivation Function Extract-then-Expand [Krawczyk]
Hash chains data data data hash(...) hash(...) hash(...)
Merkle Tree r d 1 d 2 d 3
One Time MAC Information-theoretic security Can only use key for one MAC Cheap! (but: where does the key come from?) Examples: pairwise-independent universal hash, Poly1305..
Authenticated Encryption Protect confidentiality & integrity CAESAR competition More on Wednesday!
Diffie-Hellman revisited x generate y generate x y compute y compute x compute k= ( y ) x compute k= ( x ) y • How does Alice know that she shares this secret key k with Bob? • Answer: Alice has no idea at all about who the other person is! The same holds for Bob
MITM attack on DH Eve shares a key k1 with Alice and a key k2 with Bob Requires active attack (Eve modifies messages) x2 x1 y2 y1 k2 =( y2 ) x2 =( x2 ) y2 k1 =( y1 ) x1 =( x1 ) y1
Pairings (bilinear maps)* G1 x G2 GT ê(aP, bQ) = ê(bP, aQ) = ê(abP, Q) = ê(P, abQ ) = ab ∙ ê(P, Q) Pairings for Cryptographers by S.D. Galbraith and K.G. Paterson and N.P. Smart [eprint 2006/165] Do not use pairings over F 2n !
Commitments Allow to commit to a choice without revealing it Binding: cannot be opened to any other value Hiding: cannot be determined to which value was been committed Both can be perfect/computational, however commitments can never be both perfectly binding and perfectly hiding
Bit Commitment Alice wants to commit a bit but does not want to reveal it till some time in future Bob wants to make sure Alice cannot change her committed choice Why not simply encrypt something and give the key later? - may find another key (it’s only a bit ) Using symmetric key: Bob sends R , Alice commits E K { R , b } to Bob, gives up K later
Feldman Commitment g x mod p Perfect binding Computationally hiding
Pedersen Commitment g x h y mod p where a is unknown w.r.t. g = h a mod p Computationally binding Perfect hiding
Zero Knowledge How to explain zero-knowledge protocols to your children [Quisquater et al. 89]
Schnorr Authentication x, X=xP X R = rP e s = ex + r X = e -1 (sP-R) ?
Schnorr Authentication Zero Knowledge: knowning only X one can come up with < R,e,s> such that X = e -1 (sP-R): Choose e and s at random Fix R = sP – eX History: EC-DSA vs. Schnorr
Schnorr Signature For a message M to be signed: x, X=xP X M R = rP e=H(R,M), s = ex + r R’ = sP – eX e = H(R’,M)?
Blind Signatures* For a message M to be signed: (d, N) (e, N) r at random M’= M ∙ r e mod N s ' = M’ d mod N s = s’ ∙ r -1 mod N
Homomorphic Encryption Enc is homomorphic for an operation □ on message space M iff Enc(m 1 □ m 2 ) = Enc(m 1 ) ◊ Enc(m 2 ) with ◊ operation on ciphertext space C If □ = +, then Enc is additively homomorphic If □ = x, then Enc is multiplicatively homomorphic
Multiplicative Homomorphic Textbook RSA e mod N = (m 1 ∙ m 2 ) e mod N ENC(m 1 ) ∙ENC( m 2 ) = m 1 e ∙ m 2 = ENC(m 1 ∙ m 2 ) ElGamal ENC(m 1 )∙ENC( m 2 ) = (g r1 , m 1 ∙ y r1 ) ∙ (g r2 , m 2 ∙ y r2 ) = (g r1 + r2 , (m 1 ∙ m 2 ) ∙ y r1 + r2 ) = ENC(m 1 ∙ m 2 )
Additive Homomorphic Exponential ElGamal Paillier n ) ∙ (g m2 ∙ r 2 ENC(m 1 )∙ENC( m 2 ) = (g m1 ∙ r 1 n ) = g m1 + m2 ∙ (r 1 ∙ r 2 ) n = ENC(m 1 + m 2 mod n 2 )
Secret Sharing # shares: n = 5 threshold: t+1 = 3 secret: x share i: x i Lagrange multipliers λ i x = ∑ x i ⋅ λ i
Verifiable Secret Sharing The dealer also commits to polynomial, allowing each recipient to verify that their share is on the same polynomial f(z) = a 0 + a 1 z + ... + a t z t with a 0 = s s j = f(j) c i = g ai g sj = ∏ i c i j i
Distributed Key Generation no single party knows the secret Each party acts as dealer Share = sum subshares Secret = sum subsecrets Public key needs to be extracted
Resharing A similar mechanism can be used to reshare a shared secret To recover from parts that have been compromised This is done by each dealer setting its current share as the secret in a new DKG protocol
Threshold Cryptography Combine homomorphic encryption with secret sharing: Each party can do partial decryptions using its part of the key Partial decryptions (> t+1) can be combined into the decryption A similar thing can be done for signature schemes (usually more involved because of distributed generation of randomness while signing)
Oblivious Transfer* m 0 , m 1 k random, b d, N, e (RSA) x 0 , x 1 random N, e, x 0 , x 1 v = x b + k e mod N v m 0 ’ = (v -x 0 ) d mod N + m 0 m 1 ’ = (v -x 1 ) d mod N + m 1 m 0 ’,m 1 ’ m b = m b ’ - k
PUFs* Process variations during manufacturing make chips unique ~ fingerprint Instead of programming keys into devices, you just take the fingerprint Measuring circuit + error correction (due to noise and bias) Low entropy Physical attacks to the chip (e.g. to extract keys) will result in destroying the PUF
Basic Protocols
Symmetric Authentication ISO/IEC 9798-2 or ISO/IEC 9798-4
Asymmetric Authentication ZK-proof Signatures (ISO/IEC 9798-3) (H)MQV-type key establishment
Schnorr Authentication x, X=xP X R = rP e s = ex + r X = e -1 (sP-R) ?
SIGMA
Proofs By trying to prove your protocol, you often identify mistakes Show that you thought about your proposed protocol
Information theoretic/ computational vs
Reductions Assume: attacker A on protocol Use attacker A to build attacker B on hard problem Since B can not exist, hence A can not
Random Oracle Model Replace hash by random oracle Input Output I 1 R 1 I 2 R 2
Generic Group Model Similar to RO, but for groups Perform group operations through oracle Dlog Handle 1 P 123 Q 124 R
Game Based Proofs
Recommend
More recommend
