Intrusion Tolerant Architectures

1. Intrusion Tolerant Architectures Bruno Dutertre (bruno@sdl.sri.com) Valentin Crettaz, Eric Monteith, Victoria Stavridou, Mohamed Layouni July 2001

2. Outline • GENOA – CrisisNet Case Study • GENOA Architecture • Security Assessment of the GENOA CrisisNet System • Intrusion Tolerant ENCLAVES System • Background: • Enclaves 1.0 • Enclaves 1.1 • Intrusion Tolerant Enclaves: • Architecture • Leader Coordination Protocol • Key Management

3. GENOA – CrisisNet • GENOA • Set of tools to support analysis, prediction, management of crisis situations • Activities Supported: • Information Gathering and Searching • Structured Argumentation • Group Collaboration • Maintenance of a “Corporate Memory” • CrisisNet: A Shared Persistent Datastore • A set of servers for storing information (CIP – Critical Information Packages, Products) • Supports information sharing between the GENOA tools • Provides access control and policy management

4. High-level Security Assessment • Threats to data integrity: • Illicit manipulation of documents by insiders (e.g., system administrator) • “Man-in-the-middle” attacks that modify data in transit • Server intrusions • Masquerading attacks: malicious hosts masquerade as a server • Threats to availability: • Denial-of-service attacks on servers • Malicious manipulation of metadata (including access control lists) • Countermeasures: • Cryptographic protection (e.g., integrity marks) • Digital signatures + PKI for server/client authentication • Intrusion Detection

5. Intrusion Tolerance in CrisisNet • Even with countermeasures in place, CrisisNet servers are single points of failure • Ongoing Work: • Integration of intrusion-tolerant technology in CrisisNet • Relevant Technology: • Survivable Information Storage • Authentication and key-management methods based on secret sharing schemes • Intrusion-tolerant support for group collaboration

6. Enclaves™ • Middleware for supporting secure group applications in insecure networks (Internet) • Lightweight, software-only implementation (currently Java) • Services provided: • Secure group multicast (confidentiality and integrity via encryption with a common group key) • Group management: • user authentication • join and leave protocols • group-key generation, distribution, refresh

7. Enclaves 1.0 (Li Gong, 1996) Member Member Member Group Leader Member Member

8. Enclaves 1.0 (continued) • Group leader provides all group management services • All present and past group members are trusted and must be trustworthy • No intrusion tolerance: • A compromised member can mount attacks on other members (e.g., prevent them from entering the group, force them to reuse compromised group keys). These attacks are possible even after the compromised member leaves the group. • Compromise of the leader can cause the application to fail or lead to violation of confidentiality requirements • Other vulnerabilities: • Replay attacks are possible (bugs in the protocols)

9. Enclaves 1.1 (Dutertre, Saïdi, 2000) • Same architecture as Enclaves 1.0 (centralized leader) • New, formally verified protocol for authentication, group management, and group key distribution and renewal • Increased intrusion tolerance • an arbitrary number of compromised members can be tolerated as long as the leader is not compromised • the protocols a resilient to attacks from current or past group members • guarantees: proper authentication and proper distribution of group-management messages • Implementation in Java • The group leader remains a single point of failure

10. Protocol in Enclaves 1.1 • Authentication and Distribution of Session Key • Group-Management Message • Leave

11. Enclaves 2.0 (Dutertre, Layouni 2001) • Multileader architecture: • n distributed leaders to avoid the single point of failure • Tolerates compromise of at most f out of n leaders provided n3f+1 • Byzantine fault model • Compromized leaders can behave arbitrarilty and collude to mount coordinated attacks • We assume that the encryption algorithms cannot be broken by the attacker and compromised leaders • Tolerates compromised members, as Enclaves 1.1

12. Enclaves 2.0: Architecture Member Member Leader 1 Leader 2 Leader N Leader 3

13. Group-management in Enclaves 2.0 • Once in the group, a member is in contact with 2f+1 leaders • The member establishes a one-to-one connection to each of these leaders with the Enclaves 1.1 protocol • The member gets a separate session key for all these leaders • All group-management services are provided by these leaders: • Distribution and refresh of group keys • Distribution of groupmembership information • A group-management message is accepted as valid by the member if it is received by at least f+1of its 2f+1leaders

14. Join Protocol • To join the group, a user A initiates 2f+1 separate authentication protocols with distinct leaders • If at least f+1 authentications succeed, the leaders run a coordination protocol to accept A as new group member • Once A is accepted, it is communicated the group key (using a secret sharing scheme) and the group composition • Same protocol used to coordinate leaders when a member leaves the group

15. Leader-Coordination Protocol • The noncompromised leaders must agree on whether A should be accepted • For consistency, all good leaders should accept the users in the same order; this requires Byzantine agreement • The network is asynchronous, so Byzantine agreement cannot be solved (by deterministic algorithms) • Solution: • Protocol based on consistent broadcast • Ensures consistency once the group is stable

16. Leader-Coordination Protocol • After successful authentication of A • Leader i sends to all leaders • After receiving f+1 valid messages of this form • Leader j sends to all leaders, if j hasnot already done so • A is accepted as a new group member by a leader when this leader receives n-f such messages

17. Properties of the Authentication and Coordination Process • An honest user cannot be prevented from joining the group by f compromised leaders (no denial of service) • If A is accepted by one good leader, A will be eventually accepted by all good leaders • If A is accepted then A has been authenticated by at least one noncompromised leader • Once the group is stable (nobody joins or leaves), all nonfaulty leaders eventually reach a consistent view

18. Protecting the Group Key • In the centralized architecture, the leader manages the group key • Generate a new group key when the group changes • Distribute the key to the members • The leader knows the group key • Requirements for multileader Enclaves: • Compromised leaders must not know or be able to construct the group key (to ensure confidentiality) • Compromised leaders cannot cause members to use an invalid key • Compromised leaders cannot prevent the communication of the current group keys to the members

19. Group Key Protocol • Secret sharing scheme (Cachin et al., 2000) • A leader knows only a share of the group key • f+1 shares are required to reconstruct the key • Shares are accompanied with a “proof of correctness” used by group members to check that the share is valid • New shares are computed when the group composition changes, these new shares correspond to a new group key

20. Properties of the Key Management Process • Confidentiality: • f compromised leaders cannot determine the current group key • future group keys are unpredictable • Robustness: • It is computationally infeasible for a leader to compute a valid proof of correctness for an invalid share • An honest member eventually gets f+1 valid shares and can then reconstruct the correct group key

21. Status and Future Work • Enclaves 2.0 Implementation • Under way • Java-based prototype • Demo this PI-meeting • GENOA CrisisNet • Development of an intrusion-tolerant architecture • Assessment and validation of this architecture • Intrusion Tolerant Architectures • Development of technology for comparing/assessing intrusion tolerance of different architectures • Application to intrusion-tolerant CrisisNet architecture