1 Secure Failure Detection in TrustedPals Felix Freiling University of Mannheim San Sebastian Aachen Mannheim 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

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 x1x1 x2x2 x3x3 x4x4 x5x5 F(x 1,..., x n ) ● 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? ● 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? me you

4 TrustedPals ● Smartcard-based implementation of SMC ● Reduces SMC to Consensus Z. Benenson, M. Fort, F. Freiling, D. Kesdogan, L. Draque Penso: TrustedPals: Secure Multiparty Computation Implemented with Smart Cards. ESORICS security module untrusted host security module untrusted host Byzantine general omission untrusted system trusted subsystem host 3 host 2 host 1 sec. mod. 1 sec. mod. 2 sec. mod. 3 security module Assumes a synchronous setting... information barrier

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 ● 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? general omission trusted subsystem sec. mod. 1 sec. mod. 2 sec. mod. 3

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 ● 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) Asynchronous General Omission Consensus Algorithm General Omission Failure Detector Eventually synchronous system model with adversary Asynchronous General Omission Consensus Algorithm General Omission Failure Detector

12 Secure Integration ● 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) Scrambler in action... 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?