Download hnd u Nonce u,v

1 © IBM, 2003-2004
Michael Backes
IBM Research GmbH, Rüschlikon, Switzerland
joint work with Birgit Pfitzmann and Michael Waidner
Formal Methods and Cryptography
FOSAD, September 2004
2 © IBM, 2003-2004
Lecture Overview
• A Reactively Secure
Dolev-Yao-style Cryptographic Library
• Proving the Needham-Schroeder-Lowe Protocol
with the Dolev-Yao-style Library
• Symmetric Primitives in the Library, Overview of
Other Results for Secure Reactive Systems
• Cryptographic Notions of Non-Interference
• Enterprise Privacy Policies
3 © IBM, 2003-2004
PART 1
A Reactively Secure
Dolev-Yao-style Cryptographic Library
4 © IBM, 2003-2004
Building Systems on Open Networks
E-Government
Hospital
Bank
5 © IBM, 2003-2004
Cryptography: The Details
Crypto-Toolbox
Fact(p*q)
Encryption
Hashfunction
Signature
Key establishment
DL(gx)
6 © IBM, 2003-2004
Cryptography: The Details
Crypto-Toolbox
Encryption
Hashfunction
Signature
Key establishment
Proof
7 © IBM, 2003-2004
Formal Methods: The Big Picture
But can we
justify
?
8 © IBM, 2003-2004
Overview of Our Approach
• Precise system model allowing cryptographic and
abstract operations
• “As secure as” with composition theorem
• Preservation theorems for security properties
• Concrete pairs of idealizations and secure
realizations
• In particular: Dolev-Yao style cryptographic library
• Detailed Proofs
• Poly-time, cryptographic bisimulations with static
information flow analysis, …
9 © IBM, 2003-2004
Automatic Proofs of Security Protocols
10 © IBM, 2003-2004
Why Formal Methods?
• Automation if
•
•
•
•
Repetitive
Tedious
Prone to human errors
Critical application
• A top candidate: Distributed
protocols
• Security variants for 20 years
11 © IBM, 2003-2004
Protocol Proof Tools
HOL Provers
Theory
1
Theory
n
Special
security provers

state
• Almost anything
• Much human interaction
• Special logic fragments for
security
• Approximations: correct, not
complete
Data
indep/
Model Checkers
• Fully automatic
• State exploration
12 © IBM, 2003-2004
Automating Security Protocol Proofs
• Even simple protocol classes & properties
undecidable
• Robust protocol design helps
• Full arithmetic is out
• Probability theory just developing
So how do current tools handle
cryptography?
13 © IBM, 2003-2004
Dolev-Yao Model
• Idea [DY81]
• Abstraction as term algebras, e.g., Dx(Ex(Ex(m)))
• Cancelation Rules, e.g., DxEx = e
• Well-developed proof theories
• Abstract data types
• Equational 1st-order logic
• Important for security proofs
• Inequalities! (Everything that cannot be derived.)
• Known as “initial model”
Important goal: Justify or replace
14 © IBM, 2003-2004
Dolev-Yao Model – Variants [Ours]
• Operators and equations
• sym enc, pub enc, nonce,
payload, pairing, sigs, MACs, ...
• Inequalities assumed across
operators!
• Untyped or typed
• Destructors explicit or implicit
• Abstraction from probabilism
• Finite selection, counting,
multisets
• Surrounding protocol language
• Special-purpose, CSP, picalculus, ... [any]
sign
pk’
E
pk
(,)
N
m
15 © IBM, 2003-2004
Other Work on DY Justification
• [AR00, AJ01, L01]: symmetric encryption, passive
• [HLM03]: public-key encryption, passive
• [MW04]: public-key encryption, much more
restricted, slightly “purer”
• [L04]: Active symmetric encryption (earlier than
ours).
Cryptography
16 © IBM, 2003-2004
17 © IBM, 2003-2004
Example: Encryption, passive
A1, A2  PPT:
P(b* = b ::
(sk, pk)  gen(k);
(m0, m1, v)  A1(k , pk);
b R {0, 1};
c := enc(pk, mb);
b*  A2(v, c) )
 1/2 + 1/poly(k)
(Attacker success)
(Keys)
(Message choice)
(Encrypt)
(Guess)
(Negligible)
18 © IBM, 2003-2004
Reactive Simulatability
(“as secure as”)
19 © IBM, 2003-2004
Reactive Simulatability


H
M1
M2
A

H

TH
A’
Real system
Ideal system
Idea: Whatever happens with real system
viewreal(H)
viewideal
(H)
could also happen
with ideal
system.
Indistinguishability of
random variables
20 © IBM, 2003-2004
Indistinguishability [Yao_82]
Families of random variables:
(vk)kIN poly (v'k)kIN
D (prob. poly. in first input):
| Pr(D(1k, vk) = 1) – Pr(D(1k, v'k) = 1) |
 1 / poly(k).
21 © IBM, 2003-2004
Interesting Secure Abstactions
22 © IBM, 2003-2004
Cryptographic Idealization Layers
Larger
abstractions
Small real
abstractions
VSS
Certified
mail
Credentials
[GM95]
[PSW00]
[CL01]
Secure
channels
[PW00, PW01,
CK02, BJP02,...]
Low-level crypto
(not abstract)
Encryption
as E(pk, 1len)
[LMMS98, PW00,
C01,...]
...
Auth/sigs as
statement database
...
[BPW03 ...]
Related: [SM93,P93]
Real auth/sig’s +
integrity lookup
[LMMS98, C01,...]
Normal cryptographic definitions
...
23 © IBM, 2003-2004
Ideal Dolev-Yao Style Library
24 © IBM, 2003-2004
Dolev-Yao-style Crypto Abstractions
• Recall: Term algebra, inequalities
• Major tasks:
• Represent ideal and real library in the same way
to higher protocols
• Prevent honest users from stupidity with real
crypto objects, but don’t restrict adversary
• E.g., sending a bitstring that’s almost a signature
• What imperfections are tolerable / must be
allowed?
25 © IBM, 2003-2004
Ideal Cryptographic Library
U
V
Commands,
payloads,
terms? handles
Term 1
For U:
For V:
For A:
Term 2
Tu,1
-
Payloads / test results,
terms? handles
Term 3
Tu,2
Tv,1
Ta,1
No crypto outputs!
Deterministic!
Tu,3
-
Not globally
known
A
E
pk
pk
E
m
pk
TH
m
26 © IBM, 2003-2004
Ideal Cryptographic Library (2)
U
V
Tu,4  encrypt(Tu,1, Tu,3)
received(U, Tv,2)
send(V, Tu,4)
Term 1
For U:
For V:
For A:
Term 2
Tu,1
-
Term 3
Tu,2
Tv,1
Ta,1
Tu,3
-
get_type(Tv,2)
Tv,3 := decrypt(...)
Term 4
...
E
A
E
pk
pk
E
m
pk
TH
pk
m
E
pk
m
27 © IBM, 2003-2004
Main Differences to Dolev-Yao
Tolerable imperfections:
• Lengths of encrypted messages cannot be kept
secret
• Adversary may include incorrect messages
inside encryptions
• Signature schemes can have memory
• Slightly restricted key usage for symmetric
encryption
28 © IBM, 2003-2004
Real Dolev-Yao Style Library
29 © IBM, 2003-2004
Real Cryptographic Library
U
V
Commands,
payloads,
handles
No crypto outputs!
Payloads / test results,
handles
pk
c1  E(pk, m)
c2  E(pk, m)
c1
A
Bitstrings
Real system
30 © IBM, 2003-2004
Main Additions to Given
Cryptosystems
• Type tags
• Tagging with keys
• Additional randomization (e.g., needed
when correct machines use A’s keys)
31 © IBM, 2003-2004
Proof Sketch of Dolev-Yao Style
Library
32 © IBM, 2003-2004
The Simulator
H
SH
inu outu • • •
clk !
SimH(A)
ina
THH
• Basic cmds
• Adv cmds
• Send cmds
outa
D
net_idu,v,x
Msg. here: index lind
• Results of cmds
• Received msgs
Msg. here:
(u, v, x, lhnd)
SimH
Da
with sk's for uH
netu,v,x(a)
netu,v,x(a)
Msg. here:
word l
A
33 © IBM, 2003-2004
Proof of Correct Simulation (1)
H
SH
H
SH
•••
Mu
Mv
•••
THH
A
SimH
A
Rewrite
H
H
SH
Idealize,
comp/
theorem
•••
M'u
M'v
EncH
A
SH
MH
•••
M'u
M'v
Encsim,H
A
34 © IBM, 2003-2004
Proof of Correct Simulation (2)
H
SH
•••
Combined
system
CH
A
Probabilistic
bisimulations
H
SH
MH
• With error sets (of runs)
• With info-flow analysis
H
SH
•••
M'u
Reduction proofs
for collisions,
guesses, forgeries
M'v
A
•••
THH
THSimH
Encsim,H
SimH
A
35 © IBM, 2003-2004
Proof of Correct Simulation (3)
H
H
SH
•••
•••
CH = C(0)H
Indistinguishable
A
by hybrid
argument
• Commitment problem
• Key cycles
H
SH
•••
Probabilistic
bisimulation
H
SH
MH
•••
M'u
SH
M'v
A
THH
THSimH
Encsim,H
•••
C*H = C(s(k))H
A
Probabilistic
bisimulation
SimH
A
36 © IBM, 2003-2004
Summary (Part 1)

•
Dolev-Yao model
Next:
•
Needham-Schroeder-Lowe
(hand-proved)
37 © IBM, 2003-2004
More Information
• {mbc,bpf,wmi}@zurich.ibm.com
• http://www.zurich.ibm.com/security/models/
• Read just one paper? ACM CCS 2003.
38 © IBM, 2003-2004
PART 2
Proving the Needham-Schroeder-Lowe
Protocol with the Dolev-Yao-style Library
39 © IBM, 2003-2004
Recall Summary & Outlook Part 1
•
•

Dolev-Yao model
Needham-Schroeder-Lowe
(hand-proved)
40 © IBM, 2003-2004
In Other Words:
Sound Abstract Protocol Proofs
Formalize with
given interface
Ideal DYstyle library
Abstract
primitives
Part 1 “≥”
NLS-PK
protocol
uses
Real DYstyle library
Abstract
goals
Comp/
“≥” theorem
uses Concrete
protocol
Clear
Entity
authentication
Abstract fulfils
protocol
replace
primitives
Concrete
primitives
Prove for NLS
fulfils
Pres/
theorem
General
defs
Concrete
goals
41 © IBM, 2003-2004
Composition as Needed Here
Given:

Then this holds:

42 © IBM, 2003-2004
Property Preservation
Preservation theorems over „“ for
• Integrity properties
• Some confidentiality properties:
• Non-interference
• Intransitive non-interference
• „Polynomial liveness“
Each time:
• Define cryptographic fulfilment
• Prove
Authenticity is
one of these
43 © IBM, 2003-2004
Integrity Preservation Theorem
• Integrity property: Set of permitted traces at
ports to the users
• E.g., semantics of temporal logic
• Cryptographic semantics
• Perfect / statistical / computational fulfillment
• Poly: APPT: P(run ports to the user Req)  NEGL
• Preservation Theorem:
(Sysreal  Sysideal)  (Sysideal  Req)
 Req poly testable
 (Sysreal poly
Req)
• Proof Idea: If this was different, build
distinguisher that recognizes situation
Events
here
44 © IBM, 2003-2004
The NSL Public-Key Protocol
• Originally Needham and Schroeder 78
• Modified by Lowe 95 after MITM attack
u  v: Epk_v(Nu, u)
v  u: Epk_u(Nu, Nv, v)
u  v: Epk_v(Nv)
• Multiple proofs over Dolev-Yao (Lowe,
Meadows, Syverson, Schneider, …)
• No prior cryptographic proof; concurrently by
Warinschi (directly cryptographic)
• All formal methods (and crypto) need refined
protocol definition; sometimes automated
45 © IBM, 2003-2004
The NSL Protocol over Our DYStyle Library
Refining u  v: Epk_v(Nu, u)
NSL1
NSL2
NSL3
CryptoLib-TH
NSL1
NSL2
NSL3
CL1
CL2
CL3
For NLSu:
1. nuhnd  gen_nonce();
2. Nonceu,v := Nonceu,v  {nuhnd};
3. uhnd  store(u);
4. lhnd  list(nuhnd, uhnd );
5. chnd  encrypt(pkeu,vhnd, lhnd );
6. send_i(v, chnd )
46 © IBM, 2003-2004
Informal Entity Authentication Property
 “When v thinks it speaks with u, then it
does.”
 “When v successfully terminates a
session thinking to speak with u, then u
indeed started a session with v.”
Remarks:
 Entity authentication is weak: no session key,
no time.
 Mutual authentication and replay prevention
possible.
47 © IBM, 2003-2004
Entity Authentication in Our Model
• Important for preservation theorem: Property
expressed as user in-/outputs
• Here
• “successful termination” as output for v
• “protocol start” as input from u
t1: EA_outv!(ok, u)
 t0 < t1: EA_inu?(new_prot, v)
48 © IBM, 2003-2004
Proving that NSL Fulfills Entity
Authentication
EA definition
Idea:
NSL1
NSL2
NSL3
CryptoLib-TH
Proof via invariants.
E.g., nonce secrecy:
•
•
v terminates protocol with u
 u sent 3rd message
 u obtained 2nd message
 v sent 2nd message
…
1. u  v: Epk_v(Nu,u)
2. v  u: Epk_u(Nu, Nv,v)
3. u  v: Epk_v(Nv)
Informal: Honest u created Nu for honest v
 Nu only known to u and v
Formal:
D[ j ].hndu  Nonceu,v  (D[ j ].hndw =  for all w  {u,v})
49 © IBM, 2003-2004
The Other Invariants
• Correct nonce owner
(Nonceu,v  handles)
• Unique nonce use
• Nonce list secrecy (List with
Nu has handles for u, v only)
• Correct list creator (for the 3
protocol messages)
1. u  v: Epk_v(Nu,u)
2. v  u: Epk_u(Nu, Nv,v)
3. u  v: Epk_v(Nv)
• Msg 1:
If D[ j ].type = list:
Let xi := D[ j ].arg[ i ] and xihnd := D[ xi ].hndu:
If x1hnd  Nonceu,v and D[ x2 ].type = data then D[ j ] was
created by user u in Step 4.
50 © IBM, 2003-2004
Summary Part 2
•
Needham-Schroeder-Lowe PK
• First cryptographic proof NSL (one of two, the
other direct).
• Proof by hand, but symbolic
• Invariants are quite similar to those in proof tools
• Tagging from real crypto library still there
• Like higher-level language vs. assembler
• Still there may be room for optimization
51 © IBM, 2003-2004
Summary
• Reactive simulatability: core definition to link
cryptography and formal methods
• Composition and property preservation theorems
enable usage
• Justifying Dolev-Yao-style abstraction was
particularly important
• For large systems higher-level abstractions will be
equally useful
• Low-level ideal systems more important for
cryptographic hand-proofs; not always more helpful
than classical definitions
• Formal methods won’t replace all hand-proofs for
a long time, but see [LMMS..., IK03]