Formacrypt meeting, March 6. 2006
CryptographicallySound Implementations for Communicating Processes
Cédric FournetMicrosoft Research
Joint work with Pedro Adão, IST Lisboa
Draft paper available athttp://research.microsoft/com/~fournet/crypto-sound-processes-draft.pdf
2
Abstractions for Cryptography
Abstractions are needed to design and analyze protocols;abstractions may hide important flaws of the real system.
Two main approaches have been successfully applied to protocols and programs that use cryptography
Formal, or algebraic approach Structural view of protocols, using simple formal languages,
and methods from logic, programming languages, concurrency
Compositional, good tool support for verification Too abstract?
Computational approach Messages are probability distributions over concrete
bitstrings Adversaries range over PPT Turing Machines Mostly manual proofs, with scalability issues Seems more accurate, hence more widely accepted
3
Our Perspective
formal (algebraic)
computational (PPT)
secu
rity
abst
ract
ions
cryp
togr
aphi
c pr
imiti
ves
ML, C#
CCS, Pi, Join
cryptoalgorithms
& assumptions
???
simpler proofs & tools
stronger guarantees
securechannels
idealizedcrypto library
sound encoding
abstracttraces
PPTcalculi
Spi, sjoin, applied pi
XML
4
This Work
We consider direct cryptographic implementationsof high-level communicating processes
We design and implement a distributed process calculuswith secure messaging and high-level authentication
Our calculus supports simple reasoning, based on labelled transitions and observational equivalence
We implement processes in a concrete computational setting, using standard machines and cryptographic assumptions
We obtain soundness and completeness for all safe processes,in the presence of active adversaries
We do not rely on DY cryptographic primitives Full abstraction for spi or applied pi calculus is too hard High-level code should not meddle with crypto materials
(ruling out key cycles, key compromises,...)
5
This Talk
1. Low-level target: spec, crypto assumptions, constraints
2. High-level language: design, semantics
3. High-level reasoning: traces, equivalences
4. Low-level implementation (outline)
5. Theorems
6. Conclusions, future work
Low-Level Target Model
8
Low-Level Systems
Pa Pb
Adv
Pc
9
Low-Level Adversary
Pa Pb
Adv
Pc
10
Low-Level Runs
11
Low-Level Equivalence (Target)
P1 Q1
P2 Q2 Adv Advguess
Pi Qi
¼¼
High-Level Processes
13
Terms and Local Processes
14
Two Forms of Authentication
15
Local Semantics
16
Distributed Systems
17
Global Semantics (Messaging)
18
Global Semantics (Certificates)
High-Level Reasoning
20
High-Level Equivalence
21
High-Level Equivalence (Definition)
22
Example – Secure Messaging
23
Applications
Anonymizers (one synchronous mix-in)
An electronic commerce protocol (traces properties)
Initialization (bootstrap)
Encodings from other calculi Local pi-calculus processes Distributed authenticated channels a la join-calculus
Low-Level Machinery
25
Machines for Local Processes
Adv
Inita
Key Cache
Check
Verify
Receive
Decrypt
AKeyGen
Auth
Sign
Send
Encrypt
For each principal b
Kbverify,
Kbenc
Route Collect; Sort
Verify
MarshallUnmarshallSign SKeyGen
Kasign,
Kaverify
EKeyGen
Kadec,
Kaenc
Random
Sig Cachea:x1(M1),..., a:xn(Mn)(x:a M)
Run Pa
?inpa !outaInitaInita
Key Cache
Check
Verify
Receive
Decrypt
AKeyGen
Auth
Sign
Send
Encrypt
For each principal b
Kbverify,
Kbenc
Key Cache
Check
Verify
Receive
Decrypt
Key Cache
Check
Verify
Receive
Decrypt
AKeyGen
Auth
Sign
Send
Encrypt
AKeyGen
Auth
Sign
Send
Encrypt
For each principal b
Kbverify,
Kbenc
Route Collect; Sort
Verify
MarshallUnmarshall
Verify
MarshallUnmarshallSign SKeyGen
Kasign,
Kaverify
SKeyGen
Kasign,
Kaverify
EKeyGen
Kadec,
Kaenc
EKeyGen
Kadec,
Kaenc
Random
Sig Cachea:x1(M1),..., a:xn(Mn)(x:a M)
Run Pa Random
Sig Cachea:x1(M1),..., a:xn(Mn)(x:a M)
Run Pa
?inpa?inpa !outa!outa
26
Machines for Local Processes
We use an abstract machineto implement local reductions
We normalize processes We use an arbitrary
deterministic scheduler We internally represent
names, tags, and principalsusing various bitstrings
We draw random bitstringsof size for new names
Adv
Inita
Key Cache
Check
Verify
Receive
Decrypt
AKeyGen
Auth
Sign
Send
Encrypt
For each principal b
Kbverify,
Kbenc
Route Collect; Sort
Verify
MarshallUnmarshallSign SKeyGen
Kasign,
Kaverify
EKeyGen
Kadec,
Kaenc
Random
Sig Cachea:x1(M1),..., a:xn(Mn)(x:a M)
Run Pa
?inpa !outaInitaInita
Key Cache
Check
Verify
Receive
Decrypt
AKeyGen
Auth
Sign
Send
Encrypt
For each principal b
Kbverify,
Kbenc
Key Cache
Check
Verify
Receive
Decrypt
Key Cache
Check
Verify
Receive
Decrypt
AKeyGen
Auth
Sign
Send
Encrypt
AKeyGen
Auth
Sign
Send
Encrypt
For each principal b
Kbverify,
Kbenc
Route Collect; Sort
Verify
MarshallUnmarshall
Verify
MarshallUnmarshallSign SKeyGen
Kasign,
Kaverify
SKeyGen
Kasign,
Kaverify
EKeyGen
Kadec,
Kaenc
EKeyGen
Kadec,
Kaenc
Random
Sig Cachea:x1(M1),..., a:xn(Mn)(x:a M)
Run Pa Random
Sig Cachea:x1(M1),..., a:xn(Mn)(x:a M)
Run Pa
?inpa?inpa !outa!outa
27
Machines for Local Processes
Marshall and unmarshall functions convert betweenour wire format and internal representations for terms
Signatures are generated on demand during marshalling (and cached)
All signatures are checked during unmarshallingAdv
Inita
Key Cache
Check
Verify
Receive
Decrypt
AKeyGen
Auth
Sign
Send
Encrypt
For each principal b
Kbverify,
Kbenc
Route Collect; Sort
Verify
MarshallUnmarshallSign SKeyGen
Kasign,
Kaverify
EKeyGen
Kadec,
Kaenc
Random
Sig Cachea:x1(M1),..., a:xn(Mn)(x:a M)
Run Pa
?inpa !outaInitaInita
Key Cache
Check
Verify
Receive
Decrypt
AKeyGen
Auth
Sign
Send
Encrypt
For each principal b
Kbverify,
Kbenc
Key Cache
Check
Verify
Receive
Decrypt
Key Cache
Check
Verify
Receive
Decrypt
AKeyGen
Auth
Sign
Send
Encrypt
AKeyGen
Auth
Sign
Send
Encrypt
For each principal b
Kbverify,
Kbenc
Route Collect; Sort
Verify
MarshallUnmarshall
Verify
MarshallUnmarshallSign SKeyGen
Kasign,
Kaverify
SKeyGen
Kasign,
Kaverify
EKeyGen
Kadec,
Kaenc
EKeyGen
Kadec,
Kaenc
Random
Sig Cachea:x1(M1),..., a:xn(Mn)(x:a M)
Run Pa Random
Sig Cachea:x1(M1),..., a:xn(Mn)(x:a M)
Run Pa
?inpa?inpa !outa!outa
28
Machines for Local Processes
Principals run a basic communication protocol:
Generate a fresh key k Authenticate msg with k Sign (k,b) with a’s signing
key Encrypt
(msg,ida,k,sig,auth) with b’s public key;
We use an anti-replay cache
We pad all messages toa fixed length
We sort all outgoing messages after encryption
Adv
Inita
Key Cache
Check
Verify
Receive
Decrypt
AKeyGen
Auth
Sign
Send
Encrypt
For each principal b
Kbverify,
Kbenc
Route Collect; Sort
Verify
MarshallUnmarshallSign SKeyGen
Kasign,
Kaverify
EKeyGen
Kadec,
Kaenc
Random
Sig Cachea:x1(M1),..., a:xn(Mn)(x:a M)
Run Pa
?inpa !outaInitaInita
Key Cache
Check
Verify
Receive
Decrypt
AKeyGen
Auth
Sign
Send
Encrypt
For each principal b
Kbverify,
Kbenc
Key Cache
Check
Verify
Receive
Decrypt
Key Cache
Check
Verify
Receive
Decrypt
AKeyGen
Auth
Sign
Send
Encrypt
AKeyGen
Auth
Sign
Send
Encrypt
For each principal b
Kbverify,
Kbenc
Route Collect; Sort
Verify
MarshallUnmarshall
Verify
MarshallUnmarshallSign SKeyGen
Kasign,
Kaverify
SKeyGen
Kasign,
Kaverify
EKeyGen
Kadec,
Kaenc
EKeyGen
Kadec,
Kaenc
Random
Sig Cachea:x1(M1),..., a:xn(Mn)(x:a M)
Run Pa Random
Sig Cachea:x1(M1),..., a:xn(Mn)(x:a M)
Run Pa
?inpa?inpa !outa!outa
29
From Systems to Machines
Soundness, Completeness
31
Main Results
32
Summary
We design a distributed process calculus with high-level primitivesfor communications and authentication
Our calculus supports simple reasoning, based on scopes, labelled transitions and observational equivalence
We give a computational interpretation of processes using abstract machines and standard cryptographic assumptions
We prove soundness and completeness in the presence ofactive adversaries (without factoring through spi/applied pi)
The proofs are tricky, and less modular than expected Many small design choices affect cryptographic reductions Intermediate states of low-level system are hard to
represent
Many difficult problems left for future work Expressiveness, various restrictions
Questions?
