Overcoming Impossibility Results in Composable Security using - - PowerPoint PPT Presentation

Overcoming Impossibility Results in Composable Security using Interval-Wise Guarantees

Daniel Jost Ueli Maurer ETH Zurich

Crypto 2020, August 17-21, 2020

Motivation: how to best define security?

Aug 17, 2020 Daniel Jost 2

Defining Security

Aug 17, 2020 Daniel Jost 3

Game-based security:

• Simple and minimal
• no direct link to real-world

executions

• many games
• no composition

Defining Security

Composable security:

Aug 17, 2020 Daniel Jost 4

• Guarantees linked to real-world application
• Modularization
• Composition
• Simple and minimal
• no direct link to real-world

executions

• many games
• no composition
• More complicated proofs
• Less efficient schemes
• Impossibility results

Game-based security:

Defining Security

Composable security:

Aug 17, 2020 Daniel Jost 5

• Guarantees linked to real-world application
• Modularization
• Composition
• Simple and minimal
• More complicated proofs
• Less efficient schemes
• Impossibility results

Game-based security:

Simulator-commitment problem

• no direct link to real-world

executions

• many games
• no composition

The Commitment Problem

• Example:

− encrypting a message to protect confidentiality − where adversaries that can (adaptively) learn parties’ state (including keys)

Aug 17, 2020 Daniel Jost 6

πA πB

Key

sim

The Commitment Problem

• Example:

− encrypting a message to protect confidentiality − where adversaries that can (adaptively) learn parties’ state (including keys)

Aug 17, 2020 Daniel Jost 7

πA πB

Key

sim

Authenticated channel Secure channel (Leakable) key

The Commitment Problem

• Example:

− encrypting a message to protect confidentiality − where adversaries that can (adaptively) learn parties’ state (including keys)

Aug 17, 2020 Daniel Jost 8

sim

≈

?

πA πB

Key

The Commitment Problem

• Example:

− encrypting a message to protect confidentiality − where adversaries that can (adaptively) learn parties’ state (including keys)

Aug 17, 2020 Daniel Jost 9

πA πB

Key

sim

1 m m

The Commitment Problem

• Example:

− encrypting a message to protect confidentiality − where adversaries that can (adaptively) learn parties’ state (including keys)

Aug 17, 2020 Daniel Jost 10

πA πB

Key

sim

1 m m 2 c c without m → committed

|m|

The Commitment Problem

• Example:

− encrypting a message to protect confidentiality − where adversaries that can (adaptively) learn parties’ state (including keys)

Aug 17, 2020 Daniel Jost 11

πA πB

Key

sim

1 m 2 c 3 k m c

|m| m

The Commitment Problem

• Example:

− encrypting a message to protect confidentiality − where adversaries that can (adaptively) learn parties’ state (including keys)

Aug 17, 2020 Daniel Jost 12

πA πB

Key

sim

m 2 c 3 k m c

|m| m

Cannot come up with k that explains c 1

The Commitment Problem

• Example:

− encrypting a message to protect confidentiality − where adversaries that can (adaptively) learn parties’ state (including keys)

Aug 17, 2020 Daniel Jost 13

πA πB

Key

sim

m 2 c 3 k m c

|m| m

Cannot come up with k that explains c 1

Observation:

• Leaking only the messages length (and the simulator creating a fake ciphertext) is

used to formalize that the message remains confidential until the key leaks

• But it causes problems to simulate after that event…

The Commitment Problem

• Existing solutions:

− Allowing for superpolynomial simulators → Still needs stronger schemes / additional setup − Non-information oracles: embedding game-based notions → Lack of clear composition rules

Aug 17, 2020 Daniel Jost 14

Contributions

Open question: How would such a notion fit within a composable framework?

Aug 17, 2020 Daniel Jost 15

Idea of this paper: Can we make to separate statements?

• One up to the moment the key leaks (for confidentiality)
• One after the key leaked (about the remaining guarantees)

Goal:

• Express security guarantees of

«regular» schemes composably Non-goals:

• Requireing less efficient schemes /

additional setup

• Fall back to game-based security

Specifications: a fresh take on composable security

Aug 17, 2020 Daniel Jost 16

Rethinking Composable Security: Specifications

Aug 17, 2020 Daniel Jost 17

a resource

Rethinking Composable Security: Specifications

Aug 17, 2020 Daniel Jost 18

Set of all resources Subset of resources with the desired properties → specification

Rethinking Composable Security: Specifications

Aug 17, 2020 Daniel Jost 19

▪ General statement: specification abstraction ▪ Abstract assumed specification by constructed one ▪ Easier to understand

Rethinking Composable Security: Specifications

Aug 17, 2020 Daniel Jost 20

▪ General statement: specification abstraction ▪ Abstract assumed specification by constructed one ▪ Easier to understand

Rethinking Composable Security: Specifications

Aug 17, 2020 Daniel Jost 21

▪ General statement: specification abstraction ▪ Abstract assumed specification by constructed one ▪ Easier to understand

Rethinking Composable Security: Specifications

Aug 17, 2020 Daniel Jost 22

▪ General statement: specification abstraction ▪ Abstract assumed specification by constructed one ▪ Easier to understand Introduced in Mau-Ren’16

Rethinking Composable Security: Specifications

Aug 17, 2020 Daniel Jost 23

▪ General statement: specification abstraction ▪ Abstract assumed specification by constructed one ▪ Easier to understand ▪ While traditional composable framework have a single type of statement, specifications give us flexibility: ▪ Basic properties and compositional guarantees fixed ▪ But not the types of specifications!

Rethinking Composable Security: Specifications

Aug 17, 2020 Daniel Jost 24

▪ Advantages: ▪ Absolute statement: no «forgotten» attacks ▪ Composition: transitivity of subset relation ▪ Intersection

Rethinking Composable Security: Specifications

Aug 17, 2020 Daniel Jost 25

▪ Advantages: ▪ Absolute statement: no «forgotten» attacks ▪ Composition: transitivity of subset relation ▪ Intersection

∧

Rethinking Composable Security: Specifications

Aug 17, 2020 Daniel Jost 26

▪ Advantages: ▪ Absolute statement: no «forgotten» attacks ▪ Composition: transitivity of subset relation ▪ Intersection

Guarantee 1 (e.g authenticity) Guarantee 2 (e.g confidentiality)

Simulation-based Security

Aug 17, 2020 Daniel Jost 27

▪ The standard «simulation-based» notion can be expressed as a special case

• f specification abstraction:

πA πB

Key

sim

≈

Simulation-based Security

Aug 17, 2020 Daniel Jost 28

▪ The standard «simulation-based» notion can be expressed as a special case

• f specification abstraction:

πA πB

Key

sim

≈

Simulation-based Security

Aug 17, 2020 Daniel Jost 29

▪ The standard «simulation-based» notion can be expressed as a special case

• f specification abstraction:

πA πB

Key

sim

≈

Easy to see what Eve can do

Simulation-based Security

Aug 17, 2020 Daniel Jost 30

▪ The standard «simulation-based» notion can be expressed as a special case

• f specification abstraction:

πA πB

Key

sim

≈

Simulation-based Security

Aug 17, 2020 Daniel Jost 31

▪ The standard «simulation-based» notion can be expressed as a special case

• f specification abstraction:

πA πB

Key

sim

≈ ⊆

Simulation-based Security

Aug 17, 2020 Daniel Jost 32

▪ The standard «simulation-based» notion can be expressed as a special case

• f specification abstraction:

πA πB

Key

sim

≈ ⊆

ε-relaxation: the set of all resources that are computationally indistinguishable to one of the original (green) specification.

Simulation-based Security

Aug 17, 2020 Daniel Jost 33

▪ The ε-relaxation has two important properties:

• 1. Commutes with protocol application

𝜌 ℛ𝜗 ⊆ 𝜌ℛ 𝜗

• 2. Monotonicity:

ℛ ⊆ 𝒯 ⟹ ℛ𝜗⊆ 𝑇𝜗

Simulation-based Security

Aug 17, 2020 Daniel Jost 34

▪ The ε-relaxation has two important properties:

• 1. Commutes with protocol application

𝜌 ℛ𝜗 ⊆ 𝜌ℛ 𝜗

• 2. Monotonicity:

ℛ ⊆ 𝒯 ⟹ ℛ𝜗⊆ 𝑇𝜗

• The «standard» composition rule can be recovered as a syntactic derivation rule
• In particular simulator and ε-relaxation can be ignored in further construction step

➔ Having structured specifications is crucial for true modularity!

Interval-wise Relaxations

Aug 17, 2020 Daniel Jost 35

Interval-wise Guarantees

We use this specification based view this to overcome commitment problem!

• Recall: cannot simulate across exposure of key
• Solution: we formalize the guarantees before and after

the key exposure as separate specifications:

• 1. Confidentiality until the key is exposed
• 2. Remaining guarantees afterwards

Aug 17, 2020 Daniel Jost 36

πA πB

Key m c k

sim

m c

|m| m

1 2 3

Interval-wise Guarantees

Formalization of interval-wise guarantees as a specification:

• 1. Start with unachievable resource

(what one might hope for)

• 2. Apply suitable relaxations:

− Until-rexation: waives all guarantees after a certain event − From-relaxation: waives all guarantees before a certain event

Aug 17, 2020 Daniel Jost 37

m

|m| m

1 2 3

Interval-wise Guarantees

Until-relaxation:

• System S gets relaxed to the set T of systems that behave identically until the

event happens.

• Formalized by considering the projection of the systems

that no longer replies from the event on.

Aug 17, 2020 Daniel Jost 38

S T

Interval-wise Guarantees

From-relaxation:

• How to formalize that the interaction only starts at a certain event?

Aug 17, 2020 Daniel Jost 39

sim

m c

|m| m

Simulator should only have to work from the moment on it learns the meessage due to the leakage fo the key.

Interval-wise Guarantees

From-relaxation:

• How to formalize that the interaction only starts at a certain event?
• → Solution: only consider so-called external events from

CC with events [J-Mau-Mul’19b]

Aug 17, 2020 Daniel Jost 40

sim

m c

|m| m

Simulator should only have to work from the moment on it learns the meessage due to the leakage fo the key.

Constructive Cryptography with Events

Aug 17, 2020 Daniel Jost 41

Event History

• …
• Alice sent m
• Alice’s key leaked

from a memory (real world)

• r from the simulator (ideal world)

m Conf( ) Auth( ) (deliver) (inject) (leak) m m

Interval-wise Guarantees

Putting it all together: − The guarantees for each interval are formalized as a specification. − Each such specification might involve a simulator, but not necessarily the same one! − The interval-wise specifications are built around relaxations of the same (overly idealized) resource. − We show how those relaxations interaction with the ε-relaxation and protocol attachment → Syntactical composition rules

Aug 17, 2020 Daniel Jost 42

Examples

We considered two additional examples:

• Identity-based encryption

− [Hof-Mat-Mau’15] : Simulation-based secure IBE is impossible in the standard model − Using interval-wise guarantees we introduce a composable notion that is equivalent to the standard IND-ID-CPA notion.

Aug 17, 2020 Daniel Jost 43

Examples

We considered two additional examples:

• Identity-based encryption

− [Hof-Mat-Mau’15] : Simulation-based secure IBE is impossible in the standard model − Using interval-wise guarantees we introduce a composable notion that is equivalent to the standard IND-ID-CPA notion.

• Coin-tossing over the phone without setup (via commitments)

Aug 17, 2020 Daniel Jost 44

Conclusions

• 1. Specifications allow for a more flexible approach towards composable

security.

• 2. Considering structured specifications: syntactic composition rules.
• 3. Interval-wise specifications: avoid several impossibility results due to the

simulator-commitment problem.

Aug 17, 2020 Daniel Jost 45

Mau-Ren’16 – TCC 2016b Ueli Maurer and Renato Renner From indifferentiability to constructive cryptography (and back) J-Mau-Mul’19b – TCC 2019 Daniel Jost, Ueli Maurer, and Marta Mularczyk A Unified and Composable Take on Ratcheting Hof-Mat-Mau’15 – Asiacrypt 2015 Dennis Hofheinz, Christian Matt, and Ueli Maurer Idealizing Identity-Based Encryption

Credits: Images by xkcd.com (CC BY-NC 2.5)

Thank you for your attention!