Protocol Design
Jens Hermans & Roel Peeters, KU Leuven/COSIC
Protocol Design Jens Hermans & Roel Peeters, KU Leuven/COSIC - - PowerPoint PPT Presentation
Protocol Design Jens Hermans & Roel Peeters, KU Leuven/COSIC The ideal protocol serves exactly the applications needs comes at a low cost is simple (elegant) is efficiently implementable is provably
Jens Hermans & Roel Peeters, KU Leuven/COSIC
… serves exactly the application’s needs … comes at a low cost … is simple (elegant) … is efficiently implementable … is provably secure … does not exist
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
Understand Your Application Common Goals Common Design Choices Building Blocks Basic Protocols Proofs Common Pitfalls
This is the most important thing whether selecting an existing protocol or designing your own
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
Security
Authentication (Entity / Data) Data Confidentiality Privacy …
Efficiency (i.e. low cost) Simplicity Verifiability
Who is your attacker?
Different types of cost: Chip area Power Energy Speed Communication rounds Cost at the backend …
Alice Bob Eve
Eve
Hello, I am Alice
Bob
Alice Bob
Alice Bob Eve
? ? Eve
Bob Eve
(forward/backward secrecy) Eve
Alice: €100 … Auth Alice €100
Trust?
Scale: O(N2) keys, central authority, or share keys (=risk) Efficient
O(N) keys
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?
2006 2016
Swap keys (different algorithm?) Other parties:
Central Authority? Individual notification? Linking?
RFID Scene: change key every time (“improves” privacy) Problems
Power to overwrite key in mem? 2x mem required Desynchronisation Inherent issues of symmetric key
Devices only respond to authorised queries
Enhanced privacy, side-channel resistance
Optional data transfer Prevent DoS attacks when using coupons
Extract-then-Expand
[Krawczyk]
data hash(...) data hash(...) data hash(...)
r d1 d2 d3
Information-theoretic security Can only use key for one MAC Cheap! (but: where does the key come from?) Examples: pairwise-independent universal hash, Poly1305..
Protect confidentiality & integrity CAESAR competition More on Wednesday!
x y generate x compute x generate y compute y compute k=( y) x compute k=( x)y
Eve shares a key k1 with Alice and a key k2 with Bob Requires active attack (Eve modifies messages)
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 F2n !
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
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?
Using symmetric key: Bob sends R, Alice commits EK{R,b} to Bob, gives up K later
gx mod p Perfect binding Computationally hiding
gx hy mod p where a is unknown w.r.t. g = ha mod p Computationally binding Perfect hiding
How to explain zero-knowledge protocols to your children [Quisquater et al. 89]
R = rP e s = ex + r X = e-1(sP-R) ? X x, X=xP
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
M e=H(R,M), s = ex + r R’ = sP – eX e = H(R’,M)? X x, X=xP R = rP For a message M to be signed:
M’= M ∙ re mod N s' = M’d mod N (e, N) (d, N) For a message M to be signed: r at random s = s’ ∙ r-1 mod N
Enc is homomorphic for an operation □ on message space M iff Enc(m1 □ m2) = Enc(m1) ◊ Enc(m2) with ◊ operation on ciphertext space C If □ = +, then Enc is additively homomorphic If □ = x, then Enc is multiplicatively homomorphic
Textbook RSA ENC(m1)∙ENC(m2) = m1
e ∙ m2 e mod N = (m1 ∙ m2)e mod N
= ENC(m1 ∙ m2) ElGamal ENC(m1)∙ENC(m2) = (gr1 , m1 ∙ yr1 ) ∙ (gr2 , m2 ∙ yr2 ) = (gr1 + r2 , (m1 ∙ m2) ∙ yr1 + r2 ) = ENC(m1 ∙ m2)
Exponential ElGamal Paillier ENC(m1)∙ENC(m2) = (gm1 ∙ r1
n) ∙ (gm2 ∙ r2 n)
= gm1 + m2 ∙ (r1 ∙ r2)n = ENC(m1 + m2 mod n2)
# shares: n = 5 threshold: t+1 = 3 secret: x share i: xi Lagrange multipliers λi x = ∑ xi⋅λi
The dealer also commits to polynomial, allowing each recipient to verify that their share is on the same polynomial
f(z) = a0 + a1z + ... + atzt with a0 = s sj= f(j) ci = gai gsj = ∏i ci ji
no single party knows the secret Each party acts as dealer Share = sum subshares Secret = sum subsecrets Public key needs to be extracted
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
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)
m0, m1 k random, b d, N, e (RSA) x0, x1 random N, e, x0, x1 v v = xb + ke mod N m0’ = (v-x0)d mod N + m0 m1’ = (v-x1)d mod N + m1 m0’,m1’ mb = mb’ - k
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
ISO/IEC 9798-2 or ISO/IEC 9798-4
ZK-proof Signatures (ISO/IEC 9798-3) (H)MQV-type key establishment
R = rP e s = ex + r X = e-1(sP-R) ? X x, X=xP
By trying to prove your protocol, you often identify mistakes Show that you thought about your proposed protocol
Assume: attacker A on protocol Use attacker A to build attacker B on hard problem Since B can not exist, hence A can not
Replace hash by random oracle Input Output I1 R1 I2 R2
Similar to RO, but for groups Perform group operations through oracle Dlog Handle
1 P 123 Q
124 R
CDH: given ga and gb , it is hard to compute gab DDH: given ga, gb and gc, it is hard to determine if gc = gab
OracleDH
DDH with restricted CDH oracle. Uses H(gab).
StrongDH
CDH with restricted DDH oracle Oracle is useful to generate replies in protocols
EMV protocol & tracing Key extraction & tracing (red-dot test) Circular definitions
Physical attacks: reveal everything but… The ‘wise’ adversary [Ng et al. ESORICS2008] “An adversary A who is ‘wise’ on oracle access will not make any oracle access that is redundant, or in other words, brings no advantage to him in attacking privacy of the protocol. Simply speaking, A will not waste any oracle access.”
Efficient, secure, private authentication Efficient: no computation, no communication Secure: no one that is not allowed to go in, can possibly go in Private: no communication
Keep It Simple Stupid
PUFs are noisy and biased, this should be taken into account If secure storage is needed, why a PUF in the first place?
Liao and Hsiao’s Secure ECC-based RFID Authentication Scheme integrated with ID-Verifier Transfer Protocol