Post on 20-Dec-2015
Computationally Sound Symbolic Protocol Analysis:
Correspondence Theorems
18739A: Foundations of Security and Privacy
Anupam Datta
CMU
Fall 2007-08
Protocol Analysis Techniques
Crypto Protocol Analysis
Formal Models Computational Models
Protocol LogicsModel Checking Inductive Proofs
Dolev-Yao(perfect cryptography)
Random oracleProbabilistic process calculiProbabilistic I/O automata-Correspondence theorems-Computational PCL…
Process Calculi …
Applied -calculusBAN, PCLMurphi, AVISPA Paulson, MSR
Computational and Symbolic Analysis
Cryptography: computational constructions • Define actual algorithms operating on bit strings• For example, RSA is defined as a triple of algorithms
– Key generation: public key is (n,e), private key is d where n=pq for some large primes p,q; ed=1 mod (p-1)(q-1)
– Encryption of m: me mod n– Decryption of c: cd mod n
Formal model: abstract treatment of crypto• Instead of defining cryptographic algorithms, simply
say that they satisfy a certain set of properties– Given ciphertext, obtain plaintext if have exactly the right key– Cannot learn anything from ciphertext without the right key
Goal: Soundness of Formal Analysis
Prove that properties assumed in the formal model are true for some cryptographic constructions
Formal proofs must be sound in following sense:• For any attack in concrete (computational) model…• …there is matching attack in abstract (formal) model• …or else the concrete attack violates computational
security of some cryptographic primitive
If we don’t find an attack in the formal model, then no computational attack exists
– More precisely, probability that a computational attack exists is negligible
Correspondence Theorems
Protocol specification
language
Abstract execution
model
Concreteexecution
model
Securityproperties
Securityproperties
Formal security
Cryptographic security
Soundness theoremRelation
Representative Papers
Abadi, Rogaway. “Reconciling Two Views of Cryptography (The Computational Soundness of Formal Encryption)”. J. Cryptology, 2002.• Symmetric encryption only, passive adversary
Backes, Pfitzmann, Waidner. “Universally Composable Cryptographic Library”. CCS 2003.• Public key encryption, signatures; active adversary
Micciancio, Warinschi. “Soundness of Formal Encryption in the Presence of Active Adversaries”. TCC 2004.• Public-key encryption, active adversary Today
Another Approach
Symbolic Model•PCL Semantics (Meaning of formulas)
Unbounded # concurrent sessions
PCL •Syntax (Properties)•Proof System (Proofs)
Soundness Theorem
(Induction)
High-level proof principles
Cryptographic Model•PCL Semantics (Meaning of formulas)
Polynomial # concurrent sessions
Computational PCL •Syntax ± •Proof System±
Soundness Theorem
(Reduction)
[BPW, MW,…]
Representative Papers
Datta, Derek, Mitchell, Shmatikov, Turuani. “Probabilistic Polynomial-time Semantics for a Protocol Security Logic”. ICALP 2005.• Public-key encryption, active adversary
A. Datta, A. Derek, J. C. Mitchell, B. Warinschi, Computationally Sound Compositional Logic for Key Exchange Protocols, in Proceedings of 19th IEEE Computer Security Foundations Workshop, pp. 321-334, July 2006. • Signatures, key exchange, secure sessions
A. Roy, A. Datta, A. Derek, J. C. Mitchell, Inductive Proofs of Computational Secrecy, in Proceedings of 12th European Symposium On Research In Computer Security , September 2007. • Symmetric and public key encryption; secrecy proof technique
A. Roy, A. Datta, J. C. Mitchell, Formal Proofs of Cryptographic Security of Diffie-Hellman based Protocols, in Proceedings of Symposium on Trustworthy Global Computing, November 2007.• Diffie-Hellman, symmetric and public key encryption, signatures.
Next lecture
Outline
Define what it means for an encryption scheme to be secure against adaptive chosen-ciphertext attack in the multi-user setting
Define a formal language for describing protocols Define concrete trace semantics for protocols
• Actual execution traces of protocols obtained by instantiating nonces with bit strings, etc.
• Traces include actions of the concrete adversary
Show that almost every action of concrete adversary maps to an action of abstract adversary• This will follow from security of encryption scheme
Simple Protocol Language
Pairing and encryption onlyTerm ::= Id | Identity
Key | Public keys onlyNonce |Pair | Ciphertext
Pair ::= (Term, Term)Ciphertext ::= {Term}Key
Can write simple protocols with this syntax• Must describe valid computations of honest parties
– For example, (B receives {X}pk(A), B sends {X}pk(B)) is not
valid because B can’t decrypt {X}pk(A)
Abstract vs. Concrete Execution
A {Na,A}pk(X)
B {Nb,NA}pk(A)
A {Nb}pk(X)
Abstract execution
A bits(m1ex mod nx)
B bits(m2ea mod na)
A bits(m3ex mod nx)
Concrete execution (with RSA)
(ex, nx) is responder’s RSA public key; m1 is a number encoding a concatentation of a random bit string representing nonce Na
and a fixed bit string representing A’s identity
(ea, na) is A’s RSA public key; m2 is a number encoding a concatentation of a random bit string representing nonce Nb
and the bit string extracted from the message received by B
(ex, nx) is responder’s RSA public key; m3 is a number encoding the bit string
extracted from the message received by A
Abstract vs. Concrete Adversary
Fix some set of corrupt users C. Let M be messages sent prior to some point in protocol execution.
• M know(C,M)• If t,t’ know(C,M), then (t,t’) know(C,M)• If (t,t’) know(C,M), then t,t’ know(C,M)
• If t know(C,M), then {t}k know(C,M) for any key k Keys
- Adversary can access any encryption oracle
• If {t}ki know(C,M) and Ai C, then t know(C,M)
- Adversary can decrypt only messages encrypted with public keys of corrupt users
Abstract adversary Concrete adversary
Any polynomial-time algorithm (maybe
probabilistic)
Equivalence of Concrete & Abstract
Need to prove that concrete adversary cannot achieve more than the abstract adversary except with negligible probability• E.g., may guess secret key with negligible
probability
Show that almost any concrete trace is an implementation of some valid abstract trace• Concrete traces represent everything that the
concrete adversary can achieve• If almost any concrete trace can be achieved by
the abstract adversary, it is sufficient to look only at the abstract adversary when doing analysis
Concrete and Abstract Traces
Representation function R maps abstract symbols (nonces, keys, identities) to bit strings• Defines concrete “implementation” of abstract
protocol
Concrete trace is an implementation of an abstract trace if exists a representation function R such that every message in concrete trace is a bit string instantiation of a message in abstract trace• Intuitively, concrete trace is an implementation if it is
created by plugging bit strings in place of abstract symbols in the abstract trace
• Denote implementation relation as
How Can This Fail?
A {Na,A}pk(B)
B ???
Abstract execution
A meb mod nb
B m2eb mod nb
Concrete execution (with RSA)
Suppose encryption scheme is malleable• Can change encrypted message without
decrypting• Plain old RSA is malleable!
Adversary intercepts and squares; B receives m2eb
instead of meb
There is no abstract operation corresponding to
the action of concrete adversary!
…some abstract trace generated by abstract
adversary interacting with abstract encryption and
decryption oracles
is an implementation of…
Every concrete trace generated by concrete adversary interacting with concrete encryption and decryption
oracles...(note that concrete adversary and concrete encryption oracles are
randomized)
There exists an abstract adversary such that…
If the encryption scheme used in the protocol is IND-CCA secure, then for any concrete adversary Ac
ProbRA,Ro(Af: traceset(Af, Of) traceset(Ac(RA),Oc(RO))
1-()
Main Theorem
With overwhelming probability (i.e., dominated by any
polynomial function of security parameter)
Probability is taken over randomness of concrete adversary and encryption oracles
(recall that concrete adversary may be probabilistic and public-key encryption must
be probabilistic)
Proof Outline
1. For any (randomized) concrete adversary, construct the corresponding abstract adversary Af
Abstract “model” of concrete adversary’s behavior Guarantees traceset(Af, Of) traceset(Ac(RA),Oc(RO))
2. Show that every action performed by constructed adversary is a valid action in the abstract model (with overwhelming probability) Abstract adversary is only permitted to decrypt if he
knows the right key (e.g., cannot gain partial info) Prove: constructed adversary doesn’t do anything else
Constructing Abstract Adversary
Concrete adversary Abstract adversary
1. Fix coin tosses (i.e., randomness) of honest participants and concrete adversary
2. This uniquely determines keys and nonces of honest participants Use symbolic constants to give them names in abstract model
3. Every bitstring which is not an honest participant’s key or nonce is considered the adversary’s nonce and given some symbolic name
Must prove that every concrete action can be represented by a valid
abstract action
Reduction to IND-CCA
Prove that every time concrete adversary does something that’s not permitted in abstract model, he breaks IND-CCA security of encryption• This can only happen with negligible probability• Therefore, with overwhelming probability every
concrete action implements some valid abstract action
We’ll prove this by constructing a simulator who runs the concrete adversary in a “box” and breaks IND-CCA exactly when the concrete adversary deviates from the abstract model
Overview of Reduction
Encryption anddecryption oracles(CCA game)
CCA adversary
Concrete adversary Ac
CCA adversary runs concrete adversary as a
subroutine
CCA adversary interacts with encryption and decryption
oracles according to rules of CCA game
To do this, CCA adversary must be able to simulate protocol to Ac (i.e., create an
illusion for Ac that he is interacting with the actual protocol)
CCA adversary wins CCA game exactly when Af does
something illegal in the abstract model
Abstraction Af
What’s Illegal in Abstract Model?
The only way in which constructed abstract adversary Af may violate rules of abstract model is by sending a term with some honest nonce X that he could not have learned by abstract actions• X cannot be learned from messages sent by honest
parties by simple decryption and unpairing rules
Case 1: If Af sends X in plaintext, this means that concrete adversary managed to open encryption• Recall that Af is abstraction of concrete adversary Ac
• If concrete adversary extracts a bitstring (abstracted as nonce X) from under encryption, he wins the CCA game
What if Encryption is Malleable?
Case 2: Af sends {t[X]}k, but neither t[X], nor {t[X]}k was previously sent by honest parties• Adversary managed to take some encryption
containing X and convert it into another encryption containing X
• This is known as malleability. For example, with RSA can convert an encryption of m into encryption of m2
In this case, CCA adversary will win CCA game by using the concrete adversary’s ability to convert one encryption into another• But to do this, CCA adversary must be able to
simulate protocol execution to the concrete adversary
Winning the CCA Game (Simplified)
CCA adversary
users
m0 m1
Left-right selector LR(m0,m1,b)
1. CCA adversary guesses nonce X and picks two values xo and x1
b
…
t(xb)
4. From t(xb) CCA adversary learns whether xo or x1 is inside; outputs bit b correctly
Concrete adversary Ac
2. Every time Ac asks for enck(s(X)), CCA adversary uses oracles to obtain enck(s(xb))
s(xo), s(x1)
enck(s(xb))enck(s(xb))
3. When Ac outputs enck(t(xb)), CCA adversary submits it to decryption oracle
enck(t(xb))enck(t(xb))
Ok, since the ciphertext was not previously created by encryption
oracle
Summary
If the encryption scheme used in the protocol is non-malleable under chosen-ciphertext attack, then the abstract model is sound• If an attack is not discovered in the abstract model,
a concrete attack may exist only with negligible probability
See this paper for a similar result with a formal definition of the operational semantics of the simulator• A. Roy, A. Datta, A. Derek, J. C. Mitchell, Inductive
Trace Properties for Computational Security, invited to appear in Journal of Computer Security.
In more detail…
Abstract execution model and security properties
Concrete execution model and security properties
Relating abstract and concrete security properties
Semantics
• A protocol defines two interactive programs, one for the Initiator and one for the Responder;
• The program of a party A running the NSL protocol with intended responder B:
- Choose random NA, encrypt (A,NA) and send the ciphertext to B;
- Receive a message C; decrypt C with the secret key of A; parse
the plaintext as (B, NA, NB);
- If successful, send the encryption of NB under the public key of B.
(1) I > R : {I,NI}
(2) R > I : {R,NI,NR}
(3) I > R : {NR}
KR
KI
KR
Semantics
• The local state of a party:
- program counter
- an assignment from protocol variables to values, e.g. for the NSL protocol
For the initiator A of a run between parties A, B the initial state: I=A, R=B, KI=KA,KR=KB, NI=NA, NR=?
• The local state of the party changes by receiving/sending messages.
Execution Model
Adv
Environment Env maintains the global state of all parties
• Adversary can create new sessions of the protocol: new(A,B)
new(A,B) A/B Party A A/B Party B
M
N
• Adversary can send messages to any party running the protocol and obtains the message the party would normally output
Abstract Execution Model
AdvA
{C,N}
new(A,B) A/B Party AI=A ; R=B
NI=NA ;NR=?{A,NA
}KB
A/B Party BI=A ; R=B
NI=? ;NR=NB
new(C,A) C/A Party CI=C ; R=A
NI=NC ;NR=?
C/A Party CI=C ; R=A
NI=N ;NR=NA
11 1
1 2
KA
{C,NC}
1
KA
EnvA maintains the global state of all parties;
(1) I > R : {I,NI}
(2) R > I : {R,NI,NR}
(3) I > R : {NR}
KR
KI
KR
• Message are terms from a term algebra
• Adversary is a Dolev-Yao
Abstract Execution Trace
• The interaction between each abstract adversary AdvA and the abstract environment EnvA determines an execution trace
• Denote by Tr(AdvA,EnvA) the trace F0,F1,F2,…,Fn, i.e. the sequence of the global state of the honest parties
F0 F1 Fn…
Abstract Security Properties
• An abstract security property is a predicate PropA on the set of all possible abstract execution traces
• A protocol satisfies abstractly the security property PropA if for all Dolev-Yao adversaries AdvA Tr(AdvA,EnvA) PropA
Concrete Execution Model
AdvC
{c,n}
new(a,b)
{a,nA}PKb
new(c,a)
1
PKa
{c,nc}1
PKa
a/b Party aI=a ; R=b
NI=nA ;NR=?
a/b Party bI=a ; R=b
NI=? ;NR=nB
c/a Party aI=c ; R=a
NI=nC ;NR=?
c/a Party cI=c ; R=a
NI=n ;NR=nA
1 1
1 2
EnvC maintains the global state of all parties(1) I > R : {I,NI}
(2) R > I : {R,NI,NR}
(3) I > R : {NR}
KR
KI
KR
• Messages are bit-strings
• Adversary is any probabilistic polynomial time Turing machine
Concrete Execution Model
AdvC
{c,n}
new(a,b)
{a,nA}PKb
new(c,a)
1
PKa
{c,nc}1
PKa
a/b Party aI=a ; R=b
NI=nA ;NR=?
a/b Party bI=a ; R=b
NI=? ;NR=nB
c/a Party cI=c ; R=a
NI=nC ;NR=?
c/a Party cI=c ; R=a
NI=n ;NR=nA
1 1
1 2
Radv
Renv
EnvC maintains the global state of all parties
• Fixing the randomness of the adversaries and of the parties, determines a unique execution trace
• Denote by Tr(AdvC(Radv),EnvC(Renv)) the trace C0, C1, …, Cn determined by adversary AdvC using randomness Radv and environment EnvC using randomness Renv
Concrete Execution Trace
C0 C1 Cn
Radv
RenvRadv
RenvRadv
Renv
…
Concrete Security Properties
• A concrete security property is a predicate PropC on the set of all possible execution traces
• A protocol satisfies security property PropC if for any probabilistic polynomial-time adversaries AdvC
Tr(AdvC(Radv),EnvC(Renv)) PropC
with overwhelming probability over the random choices Radv and Renv
Relating Abstract/Concrete Security Properties
• Fix PropA and PropC, an abstract and a concrete security property
• PropA < PropC if for all injective functions F, mapping formal values to appropriate bit-strings
F(PropA) PropC
• “Mutual authentication” can be naturally specified in both frameworks, and a relation as the one above holds
Soundness Theorem
THEOREM: Assume formal/computational security properties PropA < PropC and a protocol implemented with an IND-CCA secure encryption scheme. If the abstract execution of the protocol is secure (with respect to PropA), then the concrete execution is secure (with respect to PropC).
Acknowledgements
Thanks to Vitaly Shmatikov and Bogdan Warinschi for providing a number of slides.