Secure Failure Detection in TrustedPals

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

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

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

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

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

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?