Upload
azize
View
54
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Intrusion Tolerant Architectures. Bruno Dutertre ([email protected]) Valentin Crettaz, Eric Monteith, Victoria Stavridou, Mohamed Layouni July 2001. Outline. GENOA – CrisisNet Case Study GENOA Architecture Security Assessment of the GENOA CrisisNet System Intrusion Tolerant ENCLAVES System - PowerPoint PPT Presentation
Citation preview
1
Intrusion Tolerant Architectures
Bruno Dutertre ([email protected])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