Protocol Design - COSIC · Efficient Asymmetric O(N) keys. Key Management ... Enc is homomorphic...

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