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
Data Authentication
Alice Bob
Eve
Entity Authentication
Eve
Hello,
I am Alice
Bob
Non-repudiation
Alice Bob
Data Confidentiality
Alice Bob
Eve
Privacy
? ?
Eve
Prevent Denial of Service
BobEve
Protect against key leakage(forward/backward secrecy)
Eve
Common Design
Choices
Backend Processing
Alice: €100
…
Auth Alice
€100
Trust?
Symmetric/Asymmetric Key
Symmetric
Scale: O(N2) 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
Optional data transfer
Prevent DoS attacks when using coupons
First reader authentication,
then tag authentication
Secure Hardware
Building Blocks
Key Derivation Function
Key Derivation Function
Extract-then-Expand [Krawczyk]
Hash chains
data
hash(...)
data
hash(...)
data
hash(...)
Merkle Tree
data
hash(...)
data
hash(...)
data
hash(...)
data
hash(...)
data
hash(...)
data
hash(...)
data
data
data
data
data
data
r
d1 d2 d3
1
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
ygenerate x
compute xgenerate y
compute y
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)
x1
y1
k1 =( y1) x1 =( x1)y1
x2
y2
k2 =( y2) x2 =( x2)y2
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 F2n !
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 EK{R,b} to Bob, gives up K later
Feldman Commitment
gx mod p
Perfect binding
Computationally hiding
Pedersen Commitment
gx hy mod p
where a is unknown w.r.t. g = ha mod p
Computationally binding
Perfect hiding
Zero Knowledge
How to explain zero-knowledge protocols to your children
[Quisquater et al. 89]
Schnorr Authentication
R = rP
e
s = ex + r
X = e-1(sP-R) ?
Xx, X=xP
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
M
e=H(R,M), s = ex + r
R’ = sP – eX
e = H(R’,M)?
Xx, X=xP
R = rP
For a message M to be signed:
Blind Signatures*
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
Homomorphic Encryption
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
Multiplicative Homomorphic
Textbook RSA
ENC(m1)∙ENC(m2) = m1e ∙ m2
e mod N = (m1 ∙ m2)e mod N
= ENC(m1 ∙ m2)
ElGamal
ENC(m1)∙ENC(m2) = (gr1 , m1 ∙ yr1 ) ∙ (gr2 , m2 ∙ y
r2 )
= (gr1 + r2 , (m1 ∙ m2) ∙ yr1 + r2 ) = ENC(m1 ∙ m2)
Additive Homomorphic
Exponential ElGamal
Paillier
ENC(m1)∙ENC(m2) = (gm1 ∙ r1n) ∙ (gm2 ∙ r2
n)
= gm1 + m2 ∙ (r1 ∙ r2)n
= ENC(m1 + m2 mod n2)
Secret Sharing
# shares: n = 5
threshold: t+1 = 3
secret: x
share i: xi
Lagrange multipliers λi
x = ∑ xi⋅λ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) = a0 + a1z + ... + atzt with a0 = s sj= f(j)
ci = gai
gsj = ∏i ci ji
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*
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
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
R = rP
e
s = ex + r
X = e-1(sP-R) ?
Xx, X=xP
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
I1 R1
I2 R2
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
Simulator Based Proofs
Forking Lemma (Rewinding)
CDH/DDH
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
ODH/StrongDH
OracleDH
DDH with restricted CDH oracle. Uses H(gab).
StrongDH
CDH with restricted DDH oracle
Oracle is useful to generate replies in protocols
Common Pitfalls
Attack Listing
Non-general Model
EMV protocol & tracing
Key extraction & tracing (red-dot test)
Circular definitions
Non-realistic Assumptions
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.”
Correctness !!!
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
Way too
complex
Keep It Simple Stupid
Inappropriate PUF Usage
PUFs are noisy and biased, this should be taken into account
If secure storage is needed, why a PUF in the first place?
Shooting Practice
BADH-1
BADH-2
BADH-2
Liao and Hsiao’s Secure ECC-based RFID Authentication
Scheme integrated with ID-Verifier Transfer Protocol
Yoking protocols