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)

Group LeaderMember

Member

MemberMember

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

Ka32

Pa21

Pa1

}N,{NL,A,,AuthAckKey:LAKa},N,N A,{L, A,L, st, AuthKeyDi:AL

}N L, A,{ L, A,Req, AuthInit:LA

Ka32i22i

Ka22i12i}N,N L, {A, L, A, Ack,:LA

X},N,N A,L,{ A,L, AdminMsg,:AL

KaL} {A, L, A,ReqClose, :LA

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 n3f+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

Leader 3

Enclaves 2.0: Architecture

Member Member

Leader 1 Leader 2 Leader N

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+1 of its 2f+1 leaders

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 has

not already done so

A is accepted as a new group member by a leader when this leader receives n-f such messages

iinAi ,,Propose,

jjnAj ,,Propose,

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