secure failure detection in trustedpals
Download
Skip this Video
Download Presentation
Secure Failure Detection in TrustedPals

Loading in 2 Seconds...

play fullscreen
1 / 13

Secure Failure Detection in TrustedPals - PowerPoint PPT Presentation


  • 87 Views
  • Uploaded on

Secure Failure Detection in TrustedPals. Aachen. Joint Work with: Marjan Ghajar-Azadanlou RWTH Aachen University, Germany Lucia Draque Penso University of Mannheim, Germany Roberto Corti ñ as, Alberto Lafuente, Mikel Larrea, Iratxe Soraluze

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Secure Failure Detection in TrustedPals' - solange


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
secure failure detection in trustedpals

Secure Failure Detection in TrustedPals

Aachen

  • Joint Work with:
  • Marjan Ghajar-Azadanlou
    • RWTH Aachen University, Germany
  • Lucia Draque Penso
    • University of Mannheim, Germany
  • Roberto Cortiñas,Alberto Lafuente,Mikel Larrea,Iratxe Soraluze
    • University of the Basque Country, San Sebastian, Spain

Felix Freiling

University of Mannheim

Mannheim

San Sebastian

secure multiparty computation smc
Secure Multiparty Computation (SMC)
  • Set of parties with inputs
  • Jointly want to compute a function and receive the result
  • Input must remain as secret as possible

x2

x1

F(x1, ..., xn)

x3

x5

x4

  • Lots of applications (fair exchange of digital items, e-voting)
  • Easy if you have Trusted Third Party (TTP)
  • Can be done without TTP using heavy crypto and many messages
distributed ttp
Distributed TTP?

you

me

  • Practical example: Mobile phones with SIM Cards
    • Mobile phone: multi purpose computing device
      • Owner can install applications
    • SIM Card: special purpose computing device
      • Certified and tamper proof, only operator can install
  • "I trust your SIM Card but not your mobile phone"
  • Can all SIM Cards together simulate a TTP?
trustedpals

Z. Benenson, M. Fort, F. Freiling, D. Kesdogan, L. Draque Penso: TrustedPals: Secure Multiparty Computation Implemented with Smart Cards. ESORICS 2006.

TrustedPals
  • Smartcard-based implementation of SMC
  • Reduces SMC to Consensus

host2

host1

untrusted host

untrusted host

Byzantine

security module

security module

host3

untrusted

system

information barrier

sec.

mod.1

security module

sec.

mod.2

general omission

untrusted host

sec.

mod.3

trusted

subsystem

Assumes a synchronous setting ...

question and outline
Question and Outline
  • Can we redesign TrustedPals so that it works in a system with weaker synchrony assumptions?
  • We follow the failure detector approach:
    • Delegate synchrony assumptions into a module called failure detector
    • Implement "asynchronous" consensus algorithm
    • Implement failure detector under weaker synchrony assumptions
    • Integrate failure detection and consensus into TrustedPals so that security properties are maintained

see also: C. Delporte-Gallet, H. Fauconnier, F. C. Freiling: Revisiting failure detection and consensus in omission failure environments.

ICTAC 2005

Asynchronous General Omission Consensus Algorithm

General Omission Failure Detector

Eventually synchronous system model

trusted system
Trusted System

sec.

mod.1

sec.

mod.2

general omission

sec.

mod.3

trusted

subsystem

  • System Model:
    • Reliable channels
    • Eventual synchrony (à la Dwork, Lynch, Stockmeyer)
  • Failure model: General omission
    • Process crashes
    • Send and receive omissions of messages
  • Correct process = a process which does not fail
  • Faulty process = not correct process
  • Assume a majority of correct processes
  • Difficulty: Omissive processes are hard to determine
    • p sends message m to q but message doesn\'t arrive
    • Did p send omit or q receive omit m?
classes of processes
Classes of Processes
  • A process p is in-connected iff
    • p is correct or
    • p does not crash and there exists a process q such that q is in-connected and all messages sent by q to p are eventually received timely by p (i.e. no omissions from q to p)
  • A process p is out-connected iff
    • p is correct or
    • p does not crash and there exists a process q such that q is out-connected and all messages sent by p to q are eventually received timely by q (i.e. no omissions from p to q)
  • Intuition:
    • In-connected processes are able to receive information from correct processes
    • Out-connected processes are able to send information to correct processes
  • Note that correct processes are both in- and out-connected.
examples
Examples
  • a  b means "unomissive eventual timely message flows" from a to b (not a communication channel)
  • Examples:
    • q is out-connected, p is also out-connected
    • r and v are in-connected and also out-connected, but not correct
    • s is in-connected
    • u is neither in- nor out-connected
p failure detector
P Failure Detector
  • Class of eventually perfect failure detectors P satisfies:
    • Strong Completeness: Eventually every process that is not out-connected will be permanently considered as not out-connected by every in-connected process.
    • Eventual Strong Accuracy: Eventual Strong Accuracy. Eventually every process that is out-connected will be permanently considered as out-connected by every in-connected process.
    • In-connectivity: Eventually every process that is in-connected will permanently consider itself as in-connected.
  • Intuition: Eventually suspect all processes from which I am not able to receive information
    • Only necessary for in-connected processes
  • Implemented using heartbeats, sequence numbers, connectivity matrices (see paper)
p based consensus
P-based Consensus
  • Termination: Every in-connected process eventually decides some value.
  • Integrity: Every process decides at most once.
  • Uniform agreement: No two processes decide differently.
  • Validity: If a process decides v, then v was proposed by some process.
  • Algorithm similar to classic Chandra-Toueg algorithm (see paper)
  • Difficulties:
    • Need a relaying mechanism since omissions make simple "all-to-all" communication impossible
    • Only in-connected processes volunteer as coordinators
integration in trustedpals
Integration in TrustedPals

Asynchronous General Omission Consensus Algorithm

Asynchronous General Omission Consensus Algorithm

  • Adversary has full control over messages at faulty processes
  • Adversary can fool a naive implementation as follows:
    • Omit only consensus protocol messages and not failure detector messages
    • Result: protocol blocks
  • Attack is possible even if all messages are encrypted (traffic analysis)

General Omission Failure Detector

General Omission Failure Detector

Eventually synchronous system model with adversary

secure integration
Secure Integration

Scrambler in action ...

  • Use a scrambler to obfuscate traffic
    • Pad messages to fixed size
    • Encrypt and authenticate every message
  • Use failure detector messages as transport mechanism for (fragmented) consensus messages
  • Security analysis technique: Attack trees (similar to fault-tree analysis)

Module architecture on smartcard

conclusions
Conclusions
  • We made TrustedPals work in partially synchronous systems with correct majority
  • Open questions:
    • Is correct majority necessary? Or only connected majority?
    • Are smartcard-based systems really partially synchronous?
      • In practice the owner of the smartcard can slow down clock arbitrarily (clock attack)
      • Or he can buffer messages arbitrarily
      • Conjecture: Problem is impossible in the presence of such attacks
      • How can they still be solved?
ad