1. technology and computing
2. internet technology
3. email

Universally Composable
Security with Specialized
Environments
Ran Canetti
Sebastian Gajek
Tel Aviv University
Secsi 2011
Security Analysis Is Complex.
Security Analysis Is Complex
•
The basic model should allow expressing:
–
Real systems and their operation
–
Attacker capabilities and limitations
–
Security requirements
Security Analysis Is Complex
•
•
The basic model should allow expressing:
–
Real systems and their operation
–
Attacker capabilities and limitations
–
Security requirements
Security properties are delicate:
–
Quantitative, probabilistic
–
Parameterized by adversary capabilities
–
Highly dependent on the setting
Security Analysis Is Complex
•
The basic model should allow expressing:
–
Real systems and their operation
–
Attacker capabilities and limitations
–
Security requirements
•
•
Security properties are delicate:
–
Quantitative, probabilistic
–
Parameterized by adversary capabilities
–
Highly dependent on the setting
Asserting security properties is tricky:
–
Based on hardness assumptions
–
Parameterized, require “creative” reductions
Security Analysis Is Complex
•
The basic model should allow expressing:
–
Real systems and their operation
–
Attacker capabilities and limitations
–
Security requirements
•
Security properties are delicate:
–
Quantitative, probabilistic
–
Parameterized by adversary capabilities
–
Highly dependent on the setting
•
Asserting security properties is tricky:
–
Based on hardness assumptions
–
Parameterized, require “creative” reductions
Security Analysis Is Complex
Consequently, security analysis is:
•
Hard to generate
•
Hard to verify
•
Hard to interpret
Direct (“Cryptographic”) Analysis
[Goldwasser-Micali82,G-M-Rackoff85,Bellare-Rogaway93,...]
•
Directly models real programs and adversarial
capabilities in (almost) full detail
+ Soundness is apparent
- Inherits all the complexity:
Many parameters, asymptotics, probabilities...
Symbolic Analysis [Dolev-Yao83,...]
A great simplification:
–
Abstracts from many details
–
No asymptotics, fewer parameters
–
No hardness assumptions
–
In many cases sound [Abadi-Rogaway00,...]
Still, in of itself it is manual and labor intensive.
Automated analysis
•
Arguably, this is the only viable way for analyzing
security of large (or even medium) systems.
•
Requires some level of symbolic abstraction
•
There is a plethora of tools and techniques:
–
–
–
–
Model checkers (finite and infinite state),
Theorem provers (1st and 2nd order)
Logic Programming
…
Automated analysis
Main limitation: Can only analyze relatively simple systems,
else the computational complexity explodes.
Goal: Devise models where automated analysis:
•
Remains feasible
•
Implies full (computational) soundness
Partial results: ProVerif [Blanchet01], PCL [DattaDMR07] , Tagging
[Cortier-Delaitre-Delaune09], Typing [Fournet etal] , …
The modular approach
•
De-compose the system to small components
•
Analyze each component separately (and quickly)
•
Deduce the(...this
security
properties
of the overall,
is standard
in correctness analysis
re-composed system.
...this is standard in correctness analysis
But does it work for security analysis?
The modular approach
•
De-compose the system to small components
•
Analyze each component separately (and quickly)
•
Deduce the(...this
security
properties
of the overall,
is standard
in correctness analysis
re-composed system.
...this is standard in correctness analysis
But does it work for security analysis?
- Need composable security.
Composable Security Analysis
Need to:
•
Formulate a model that allow for decomposing
protocols.
•
Formulate symbolic security properties that
compose.
•
Develop tools that can assert these properties.
Composable Security Analysis
Need to:
•
Formulate a model that allow for decomposing
protocols.
•
Formulate symbolic security properties that
compose.
•
Develop automated tools that can assert these
computational properties.
In the rest of this talk
•
Review the UC framework
•
Review the use of UC in modular symbolic
analysis
•
Identify a limitation
•
Will show a workaround
Universally Composable (UC) Security
●
A framework that allows expressing any set of concerns
and requirements for any crypto task:
(e.g. authenticity, secrecy, anonymity, privacy,
correctness,unpredictability, fairness, public verifiability, coercionfreeness, termination, availability...)
●
●
A composition operation (“universal composition”) that
allows expressing practically any way in which protocols
interact and compose.
A way to assert security that's preserved under
universal composition.
The basic paradigm
[Goldreich-Micali-Wigderson87]
„A protocol is secure for some task if it “emulates”
an “ideal process” where the parties hand
their inputs to a “trusted party”, who locally
computes the desired outputs and hands
them back to the parties.‟
Intuitively very attractive.
But, how to formalize?
UC security
Will present in three steps:
• Formalize the process of protocol execution in
presence of an adversary
• Formalize the “ideal process” for realizing the
functionality
• Formalize the notion of “a protocol emulates the
ideal process for realizing a functionality.”
UC security:
Protocol execution:
E
P2
P1
A

P3
P4
UC security:
E
Ideal protocol:
P2
P1
S
P4
P3
F
UC security:
P2
P1
Protocol execution:
E
Ideal protocol:
P2
P1
S
P4
P3
F
A

P3
P4
Protocol  realizes functionality F if
running  emulates the ideal process for F:
For any adv. A there exists an adv. S
Such that no environment E can tell
whether it’s interacting with:
- A run of  with A
- An ideal run with F and S
Implications of the definition
Correctness: In the ideal process the parties get the “correct”
outputs, based on the inputs of all parties. Consequently, the
same must happen in the protocol execution (or else Z will tell
the difference).
Secrecy: In the ideal process the adversary learns nothing other
than the outputs of bad parties. Consequently, the same must
happen in the protocol execution.
Fairness, Availability, etc.: Argued in a similar way.
Security-preserving protocol composition
The composition operation:
Start with
• Protocol  that uses ideal calls to functionality F
• Protocol  that securely realizes F
Construct the composed protocol   :
• Each call to F is replaced with an invocation of .
• Each value returned from  is treated as coming
from F.
The composition operation
(single call to F)




F

The composition operation
(single call to F)




➔







F


The composition operation
(multiple calls to F)





F
➔









F
F
(Different instances of F/π are invoked with different session id’s )



The universal composition theorem:


Protocol
emulates protocol .
(That is, for any adversary A there exists an adversary S such that
no E can tell whether it is interacting with ( ,A) or with (,S).)
Corollary:
If  realizes functionality G then so does   .
The universality of universal
composition
Captures all common ways to combine protocols:
–
–
–
–
–
–
Subroutine calls
Sequential, parallel, concurrent, executions
Executions by same party, by unrelated parties
Executions on same/related inputs, on unrelated inputs
Unbounded number of executions
Dynamic and adversarial code generation (“chosen
protocol attacks”)
Strengths of UC analysis
•
Security in complex environments:
– Guarantee security when the protocol is running
alongside other (potentially unknown) protocols.
•
Supports modular security analysis
•
Supports abstraction and symbolic
representations
[Backes-Pfitzmann-Waidner03, C-Herzog06, Kuesters-Tuengerthal09...]
Limitations of UC analysis
•
Very strong security requirements:
–
–
–
Hard to assert
Don’t always hold
Makes de-composition to small components hard
Limitations of UC analysis:
Examples
•
Impossibility of UC commitments, Zero Knowledge,
general 2-party MPC
– Workaround: “trusted set-up” models
•
Can’t apply UC when protocols share secret state
– Workaround: Joint-state UC
•
Can’t apply UC when security depends on properties of
the inputs
– Workarounds: Relax the Functionality, Condition the
environment.
Example:
UC modeling of secure channels
Many components:
•
Registration (Cert. authorities, Authen. Servers,...)
•
Key exchange
•
Key derivation
•
Data encryption
•
Date authentication
•
Replay protection
How to model and analyze?
The general structure of PKI-based protocols
(common to IPSEC,SSL/TLS, most others...)
enc
enc
auth
auth
KE
KE
enc
...
...
PK: enc,/
Sig
CA
auth
KE
The general idea
•
•
•
Model each component as an ideal functionality (IF)
Separately analyze protocols for realizing each IF
Use the UC theorem to deduce overall security
Set the goal:
Ideal secure sessions: Functionality FSS
P1/P2
P1
Establish-Sess(P1,P2)
Establish-Sess(P1,P2)
ok
m)
Z
S
FSS
Send(P1,P2, 1|m|)
Deliver(P2,,P1,m‘)
P2
m)
Message Delivery
If P1, P2 is corrupted,
then set m  m‘
Will want to emulate a setting where each secure channel
Is represented by an instance of Fss.
Current modular analysis of secure channels
Enc+
auth
KE
Enc+
auth
...
Enc+
auth
Enc+
auth
KE ... KE
emulates
KE
Enc+
auth
...
Enc+
auth
Enc+
auth
KE ... KE
emulates
FPKE
...
Enc+
auth
KE
KE ... KE
FPKE
FPKE
emulates
FSS
(JUC)
ENC
Enc+
auth
...
emulates
FPKE
CA
Enc+
auth
Enc+
auth
...
Enc+
auth
FKE
FKE
...
FKE
emulates
Enc+
auth
Enc+
auth
...
Enc+
auth
FKE
FKE
...
FKE
FSS
...
FSS
Reflections
•
Abstracted each component separately
–
•
where all abstractions are symbolic.
Analyzed an implementation of each abstraction
separately
–
where the analysis considered only a single session
Reflections
•
Abstracted each component separately
–
•
where all abstractions are symbolic.
Analyzed an implementation of each abstraction
separately
–
•
where the analysis considered only a single session
Except for the case of symmetric encryption and
MAC:
–
Here we had to directly use the non-symbolic,
cryptographic notions...
UC symmetric encryption (and MAC)
How to define as stand alone primitives?
The crux of the problem:
How to treat the secret key?
- Internal to the protocol  Have to include the key
generation process in the same module
- Provided from the outside  Cannot guarantee
security...
UC symmetric encryption (and MAC):
Known formalizations
–
[Backes-Pfitzmann-Waidner03]:
Treat both the secret keys and ciphertexts as internal.
Indeed, Symmetric encryption is not a stand alone
primitive
– [Kuesters-Tuengerthal09]:
Treat ciphertexts and messages as external, but the secret
key is still internal. Indeed, symmetric encryption still is
not a stand alone primitive.
Symmetric encryption (and MAC)
within a secure session protocol
A typical secure session protocol (EtA):
– Run key exchange, obtain kmac and kenc.
– Invoke ENC,DEC, give them kenc.
– Invoke MAC,VER, give them kmac.
– Given a message m:
•
•
–
Hand m to ENC, obtain c
Hand c to MAC, obtain t, Send (c,t)
Upon receipt of (c,t):
•
•
Hand (c,t) to VER
If ok, hand c to DEC, output result
Symmetric encryption (and MAC)
within a secure session protocol
A typical secure session protocol (EtA):
– Run key exchange, obtain kmac and kenc.
– Invoke ENC,DEC, give them kenc.
– Invoke MAC,VER, give them kmac.
– Given a message m:
•
•
–
Hand m to ENC, obtain c
Hand c to MAC, obtain t, Send (c,t)
Upon receipt of (c,t):
•
•
Hand (c,t) to VER
If ok, hand c to DEC, output result
Note: ENC,DEC,MAC,VER get keys from the outside!
(but the keys never leave the secure session protocol)
How to properly capture the use of the symmetric
key?
Idea: Directly capture the “protected environment” in
which ENC,DEC, MAC,VER run, by appropriately
restricting the formal environment.
How to properly capture the use of the symmetric
key?
Idea: Directly capture the “protected environment” in
which ENC,DEC, MAC,VER run, by appropriately
restricting the formal environment.
How about using the “conditional environments” of
[Backes,Hofheinz,Kuesters06]?
How to properly capture the use of the symmetric
key?
Idea: Directly capture the “protected environment” in
which ENC,DEC, MAC,VER run, by appropriately
restricting the formal environment.
How about using the “conditional environments” of
[Backes,Hofheinz,Kuesters06]?
- Only provides restrictions on input patterns, not on
flow of information inside the environment.
 Need a new formalism...
Specialized Environments
Let R be an ITM (“The restriction”). An
env. is R-Specialized if it consists of a
component R and a generic component
E such that:
E
• All communication with the protocol and
adversary is done by R.
• E has access only to the outputs (and
outgoing communication) of R.
R
• E gives information to R via R’s input
and incoming communication tapes.
π
A
 R is a “filter” between E and the system.
SEUC-Security
A protocol π UC-emulates protocol φ wrt R-specialized
environments (π UCR-emulates φ) if for any A there is an S
such that no R-specialized environment can tell apart (π,A)
from (φ,S):
Definition (Protocol Emulation)
Let π,φ be two protocols. Let R be a restriction. We say π SEUC-emulates φ w.r.t. Rspecialized environments, if for any adversary A there exists a simulator S, s.t for any
R-specialized environment E, we have:
Execπ,A,E ≈ Execφ,S,E
SEUC security and other relaxations of UC
– Generalized UC with global set-up [C-Dodis-Pass-Walfish07]
Is a special case of SEUC security:
•
–
R plays the global set-up, and passes all I/O to E, except the
messages that are directed to the global set-up.
UC with angel-assisted adversaries [Prabhakaran-Sahai04]
is a special case of SEUC security:
•
R plays the angel, processing locally only the messages sent by
A to it. Other messages are passed to E.
SEUC security and other relaxations of UC
– Generalized UC with global set-up [C-Dodis-Pass-Walfish07]
Is a special case of SEUC security:
•
–
R plays the global set-up, and passes all I/O to E, except the
messages that are directed to the global set-up.
UC with angel-assisted adversaries [Prabhakaran-Sahai04]
is a special case of SEUC security:
•
R plays the angel, processing locally only the messages sent by
A to it. Other messages are passed to E.
Q: What about composability?
A: Each one of these cases has its own composability proof.
Q: Can we prove a general composition theorem for SEUC?
Specialized Environments: Protocol-only restrictions
R transmits:
• All the communication from A go to E
• All the inputs from E directed at A goes
to A,
E
 R “filters” only between E and the protocol.
R
π
A
Specialized Environments: Protocol-only restrictions
R transmits:
• All the communication from A go to E
• All the inputs from E directed at A goes
to A,
E
 R “filters” only between E and the protocol.
R
π
A
From now on we’ll consider only such restriction ITMs.
Is SEUC security composable?
(what does composability mean here?)
SEUC and dummy adversaries
• The Dummy Adversary is still universal
(simplifying life)
Claim
Let π,φ be two protocols. Let R be a protocol-only restriction. Then π UCR-emulates
φ if and only if it UCR-emulates φ w.r.t to the dummy adversary.
SEUC Composition (part 1)
Theorem 1:
If π UCR emulates φ then Rπ UC-emulates Rφ.
Proof of Theorem 1
E
E

R
π
A
R
π
A
SEUC Composition (part 2)
• Recall: Want to show composition as long
as parent protocol “behaves”. Here is a
formalization of “behaves”:
Definition (R-compliant):
Let ρ be a protocol and let R be a restriction ITM. We say ρ is R-compliant, if there
exists a simulator S, s.t. for all π and for all R-restricted environments E, we have
(here DA is the dummy adversary):
Exec ρπ,DA,E ≈ Exec Rπ,S,E
SEUC Composition (part 2)
Main theorem: If π emulates φ w.r.t R-restricted
environments, and ρ “behaves” w.r.t. R, then ρπ
emulates ρφ.
Theorem 2:
If π UCR emulates φ, and ρ is R-compliant, then ρπ UC-emulates ρφ.
- The proof is a natural extension of the proof of the UC theorem.
SYMMETRIC ENCRYPTION AND MAC
FOR SECURE CHANNEL PROTOCOLS
Modular analysis of secure channel protocols
From KE, IND-CPA enc, EU-CMA MAC
We provide:
• A stand-alone formulation of ideal symmetric
encryption, FSE
– A protocol is IND-CPA encryption iff it UCF’KE-realizes FSE.
(F’KE is FKE that gives the key to its subroutine)
• A stand-alone formulation of ideal MAC, FMAC
– A protocol is EU-CMA MAC iff it UCF’KE-realizes FMAC.
Functionality FMAC
k
k
R
S/V
T,V
m
S
Z
t=T(m)
m,t)
V
b
FMAC
S
Tagging:
Record (m, T(m)) pair
Verification:
if V(m,t)=1, no (m,t‘)
pair exists for any t‘,
and not corrupted,
then output forgery,
else set b=V(m,t)
Functionality FSE
k
k
R
E/D
E,D,
S
m
E
Z
c=E(0)
FSE
c
D
m
Additional Restriction R2
Prevent decryption of
„unknown“ ciphertexts
Encryption:
if E not corrupted,
then c=e(1|m|) and
record (m,c) pair
Decryption:
Decrypt only known
(m,c) pairs
Functionality FKE
P1/P2
(Establish-Key,P1,P2)
(Establish-Key,P1,P2)
(Key,P1,P2, κ‘)
Z
S
FKE
P1/P2
(Key,P1,P2,κ)
Key Distribution:
If P1, P2 is corrupted,
then set κ  κ‘
else set κ r {0,1}k
Protocol πEtA (sender side)
P1/P2
P1/P2
Establish-Key(P1,P2)
Establish-Sess(P1,P2)
Key(P2,P1,κ)
Setup(κ)
Send(P1,P2,m)
πEtA
Z
FKE
Enc(m)
c
FENC
Setup(κ)
A
c,tag
Mac(c)
tag
FMAC
Protocol πEtA (receiver side)
A
Setup(κ)
c,tag
Vrfy(c,tag)
valid?
πEtA
Z
Setup(κ)
Dec(c)
m
P2
Receive(P2,,P1,m)
FMAC
FENC
Modular analysis of secure channel protocols
From KE, IND-CPA enc, EU-CMA MAC
• We first show: πEtAFKE, FSE, FMAC UC-realizes FSS.
• Using Theorems 1 and 2 we show:
– πEtAFKE, FSE, πMAC UC-emulates πEtA
, FSE, FMAC .
FKE
– πEtAFKE, πSE, πMAC UC-emulates πEtAFKE, FSE, πMAC .
– πEtAπKE, πSE, πMAC UC-emulates πEtAFKE, πSE, πMAC .
What next?
•
Other uses of Specialized environments?
•
Symbolic UC?
•
Automated analysis of secure channels?
•
Automated UC security analysis?
•
Automated security analysis of large scale
systems?