1. Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory, SRI International bruno@sdl.sri.com OASIS PI Meeting Santa Rosa, CA August 20, 2002

2. 2 2 Outline t Status t Formal Verification of Enclaves Intrusion-tolerant architecture Verification of the authentication protocol Verification of the leader-coordination protocol Model checking PVS formalization t Future work

3. 3 3 Status t Security analysis of Genoa CrisisNet Basic version (done 2001, Eric Monteith, NAI Labs) Intrusion-tolerant version based on DIT (NAI Labs) t Intrusion-tolerant Enclaves Java implementation, plugin architecture Prototype wireless version on IPAq (on top of TBRPF routing protocol for ad hoc networks) t Recent work Validation of Enclaves protocols via formal verification

4. 4 4 Enclaves t Originally proposed by Li Gong (1996) as lightweight software for supporting secure group collaboration t Middleware for building secure groupware applications Support collaboration between human users For small to medium groups t Provides means to construct and maintain a secure multicast channel between group members Protocols to authenticate and accept new members Crypto for secrecy and integrity of communication Group and key management services

5. 5 5 Leader Member Leader Member Leader Intrusion-Tolerant Architecture t Group-management services distributed across n leaders: Member authentication Group-key distribution t Can tolerate up to f faulty leaders (Byzantine failures) provided 3f+1  n t Relies on: Threshold cryptography Consistent broadcast protocol Symmetric-key crypto

6. 6 6 Formal Verification t Objective: Obtain high assurance that the Enclaves protocols are correct Find bugs t Two Enclaves components formally verified so far: Authentication protocol for establishing secure channels between a member and a leader Leader-coordination protocol based on the consistent broadcast protocol

7. 7 7 Formal Verification of the Authentication Protocol t Done in 2000-2001 using the PVS specification and verification system t Modeling based on Paulson’s inductive approach Trace-based model Attacker model: attacker can do anything except breaking the cryptographic primitives (e.g., replay, corrupt, fake, delete messages) t Verification techniques: Secrecy properties as invariants Construction of an abstraction (verification diagrams) t Results: Showed that long-term and session keys remain secret and that messages are received in the order they are sent

8. 8 8 Leader Coordination t The noncompromised leaders should agree on the group composition t Leader coordinate using the consistent broadcast protocol Objectives Consistency once the group is stable All group members have been authenticated by at least one good leader Any user authenticated by at least f+1 good leaders eventually enters the group Stronger consistency guarantees cannot be achieved (with a deterministic algorithm) in an asynchronous network

9. 9 9 Coordination Protocol t After successful authentication of user A Leader i sends to all leaders t After receiving f+1 valid messages of this form Leader j sends to all leaders if it has not already done so t A is accepted as a new group member by a leader when this leader receives n-f such messages t The same protocol is used when A leaves the group

10. 10 Model Checking t Using SRI’s SAL tool (developed in John Rushby’s group) SAL specification language based on guarded commands Intended for modeling state-transition systems Includes synchronous and asynchronous composition Includes an explicit-state model checker t Model-checking requires a finite model Fixed number of leaders and clients Communication channels of bounded size Finite message space

11. 11 Model Checking Results t One bug: violation of the consistency requirement t Cause: leaders ignore “leave” requests from users not in their view of the group This can lead to inconsistency if a leader receives (and ignores) a “leave” request before it receives the corresponding “join” request, while other leaders receive “join” first, then “leave” t Fix: leaders respond to “leave” or “join” request without taking their view of the group into account Group view determined by the number of joins - number of leaves

12. 12 PVS Verification t PVS verification decomposed into: Model of the consistent broadcast protocol Instantiation of this protocol as used in Enclaves t Approach: Protocol modeled as a state-transition system State includes set of currently good leaders Set of messages sent so far Transition relation includes: Protocol steps performed by the good leaders Actions of faulty leaders Failure of a leader

13. 13 Consistent Broadcast in PVS t Assumes a fixed but arbitrary message type t Two types of events: t Algorithm: When a request for m is received by i, leader i sends support for m to all leaders When j receives f+1 support messages for m, then j sends support for m to all leaders if it has not already done so Any leader that receives n-f support messages for m accepts m request(i, m) support(i, j, m) request for m received by leader i support for m from i, received by j

14. 14 PVS Excerpts t State definition for consistent broadcast protocol t Example transition: state: TYPE = [# good: set[leader], trace: set[event], supported: [leader -> set[message]], accepted: [leader -> set[message]], supporters:[leader, message -> set[leader]] #] Fail(q1,i,q2): bool = q1`good(i) AND card(q1`good) > n-f AND q2 = q1 WITH [`good := remove(i, q1`good) ]

15. 15 Example Proof: Consistency t Given a message m, consider different sets of leaders A(m): Good leaders that support m B(m, i): Leaders that have sent messages of the form support(i, j, m) to i F: Faulty leaders t Main lemma: the following property is invariant: A(m)  B(m,i)  A(m)  F t In a state where all messages related to m have been received, this implies that either all good leaders accept m or that none of them does

16. 16 PVS Results t Formal proofs of the correctness of the consistent broadcast protocol t Formal proofs of the following properties of Enclaves: Consistency: If there are no pending “leave”, “join”, or “support” messages then all the good leaders have the same group view Proper authentication: No user can get into a good leader’s group view without being authenticated by at least one good leader If a user A is authenticated by at least f+1 good leaders (and does not sends leave requests after that) then A is a group member when the group views are stable t Good evidence that the protocol is correct

17. 17 Conclusion t Demonstrated the usefulness of formal verification Found a non-obvious bug Obtained high assurance of correctness of the Enclaves protocols Byzantine fault-tolerant protocol Cryptographic protocol t What remains to be done: Put everything together: show that assumptions made by the leader-coordination protocol are satisfied by the authentication protocol t Future directions for Enclaves: Intrusion-detection, reconfiguration when faulty leaders are detected More lightweight version for wireless networks