Universally Composable Security with Specialized Environments

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?