Secure Failure Detection in TrustedPals

1
Secure Failure Detection in TrustedPals

• Felix Freiling
• University of Mannheim

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
Mannheim
San Sebastian
2
Secure Multiparty Computation (SMC)
x2
x1
F(x1, ..., xn)
x3
x5
x4

• Set of parties with inputs
• Jointly want to compute a function and receive
  the result
• Input must remain as secret as possible

• 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

3
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?

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

• 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
sec. mod.2
security module
general omission
untrusted host
sec. mod.3
trusted subsystem
Assumes a synchronous setting ...
5
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
6
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?

7
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.

8
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

9
?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)

10
?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

11
Integration in TrustedPals
Asynchronous General Omission Consensus Algorithm
Asynchronous General Omission Consensus Algorithm
General Omission Failure Detector
General Omission Failure Detector
Eventually synchronous system model with adversary

• 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)

12
Secure Integration
Scrambler in action ...
Module architecture on smartcard

• 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)

13
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?