Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory,...
-
Upload
matilda-marsh -
Category
Documents
-
view
216 -
download
0
Transcript of Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory,...
Intrusion Tolerant Software
Architectures
Bruno Dutertre and Hassen SaïdiSystem Design Laboratory, SRI International
OASIS PI MeetingSanta Rosa, CA
August 20, 2002
2 2
Outline
Status
Formal Verification of Enclaves Intrusion-tolerant architecture Verification of the authentication protocol Verification of the leader-coordination protocol
Model checking PVS formalization
Future work
3 3
Status
Security analysis of Genoa CrisisNet Basic version (done 2001, Eric Monteith, NAI Labs) Intrusion-tolerant version based on DIT (NAI Labs)
Intrusion-tolerant Enclaves Java implementation, plugin architecture Prototype wireless version on IPAq (on top of TBRPF routing
protocol for ad hoc networks)
Recent work Validation of Enclaves protocols via formal verification
4 4
Enclaves
Originally proposed by Li Gong (1996) as lightweight software
for supporting secure group collaboration
Middleware for building secure groupware applications Support collaboration between human users For small to medium groups
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
Leader
Member Member
Leader Leader
Member
Leader
Intrusion-Tolerant Architecture
Group-management services
distributed across n leaders: Member authentication Group-key distribution
Can tolerate up to f faulty
leaders (Byzantine failures)
provided 3f+1n
Relies on: Threshold cryptography Consistent broadcast
protocol Symmetric-key crypto
6 6
Formal Verification
Objective: Obtain high assurance that the Enclaves protocols are correct Find bugs
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
Formal Verification of the Authentication Protocol
Done in 2000-2001 using the PVS specification and verification system
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)
Verification techniques: Secrecy properties as invariants Construction of an abstraction (verification diagrams)
Results: Showed that long-term and session keys remain secret and that
messages are received in the order they are sent
8 8
Leader Coordination
The noncompromised leaders should agree on the group
composition
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
Coordination Protocol
After successful authentication of user A Leader i sends to all leaders
After receiving f+1 valid messages of this form
Leader j sends to all leaders
if it has not already done so
A is accepted as a new group member by a leader when this
leader receives n-f such messages
The same protocol is used when A leaves the group
iinAi ,,Propose,
jjnAj ,,Propose,
10 10
Model Checking
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
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
One bug: violation of the consistency requirement
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”
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
PVS verification decomposed into: Model of the consistent broadcast protocol Instantiation of this protocol as used in Enclaves
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
Assumes a fixed but arbitrary message type
Two types of events:
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
State definition for consistent broadcast protocol
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
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
Main lemma: the following property is invariant:
A(m) B(m,i) A(m) F
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
Formal proofs of the correctness of the consistent broadcast protocol
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
Good evidence that the protocol is correct
17 17
Conclusion
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
What remains to be done: Put everything together: show that assumptions made by the
leader-coordination protocol are satisfied by the authentication protocol
Future directions for Enclaves: Intrusion-detection, reconfiguration when faulty leaders are
detected More lightweight version for wireless networks