Transcript Folie 1

Secure Failure Detection in TrustedPals
Felix Freiling
University of Mannheim
Aachen
Joint Work with:
Marjan Ghajar-Azadanlou
Mannheim
RWTH Aachen University, Germany
Lucia Draque Penso
University of Mannheim, Germany
Roberto Cortiñas,
Alberto Lafuente,
Mikel Larrea,
Iratxe Soraluze
San Sebastian
University of the Basque Country,
San Sebastian, Spain
1
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
2
crypto and many messages
Distributed TTP?
me
●
you
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?
3
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
untrusted
host
untrusted
host
Byzantine
security
module
security
module
host2
host1
untrusted
system
host3
information barrier
security
module
sec.
mod.1
general omission
untrusted
host
Assumes a synchronous setting ...
sec.
mod.2
trusted
subsystem
sec.
mod.3
4
Question and Outline
●
Can we redesign TrustedPals so that it works in a system with
weaker synchrony assumptions?
Asynchronous General Omission Consensus Algorithm
General Omission Failure Detector
Eventually synchronous system model
●
see also: C. DelporteGallet, H. Fauconnier, F.
C. Freiling: Revisiting
failure detection and
consensus in omission
failure environments.
ICTAC 2005
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
5
Trusted System
●
System Model:
–
–
●
sec.
mod.1
sec.
mod.2
general omission
trusted
subsystem
sec.
mod.3
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?
6
Classes of Processes
●
A process p is in-connected iff
–
–
●
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 outconnected and all messages sent by p to q are eventually received
timely by q (i.e. no omissions from p to q)
Intuition:
–
–
●
p is correct or
p does not crash and there exists a process q such that q is inconnected and all messages sent by q to p are eventually received
timely by p (i.e. no omissions from q to p)
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.
7
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
8
P Failure Detector
●
Class of eventually perfect failure detectors P satisfies:
–
–
–
●
Intuition: Eventually suspect all processes from which I am
not able to receive information
–
●
Strong Completeness: Eventually every process that is not outconnected 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.
Only necessary for in-connected processes
Implemented using heartbeats, sequence numbers, connectivity
matrices (see paper)
9
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 "allto-all" communication impossible
Only in-connected processes volunteer as coordinators
10
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)
11
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)
12
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?
13