Title: Intrusion Tolerant Software Architectures
1Intrusion Tolerant Software Architectures
OASIS PI Meeting Santa Rosa, CA August 20, 2002
Bruno Dutertre and Hassen Saïdi System Design
Laboratory, SRI International bruno_at_sdl.sri.com
2Outline
- 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
3Status
- 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
4Enclaves
- 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
5Intrusion-Tolerant Architecture
- Group-management services distributed across n
leaders - Member authentication
- Group-key distribution
- Can tolerate up to f faulty leaders (Byzantine
failures) provided 3f1?n - Relies on
- Threshold cryptography
- Consistent broadcast protocol
- Symmetric-key crypto
Member
Member
Member
Leader
Leader
Leader
Leader
6Formal 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
7Formal Verification of the Authentication Protocol
- Done in 2000-2001 using the PVS specification and
verification system - Modeling based on Paulsons 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
8Leader 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 f1 good
leaders eventually enters the group - Stronger consistency guarantees cannot be
achieved (with a deterministic algorithm) in an
asynchronous network
9Coordination Protocol
- After successful authentication of user A
- Leader i sends
to all leaders - After receiving f1 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
10Model Checking
- Using SRIs SAL tool (developed in John Rushbys
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
11Model 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
12PVS 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
13Consistent 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 f1 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 for m received by leader i support for m
from i, received by j
request(i, m) support(i, j, m)
14PVS Excerpts
- State definition for consistent broadcast
protocol - Example transition
state TYPE good setleader,
trace setevent, supported leader
-gt setmessage, accepted leader -gt
setmessage, supportersleader, message
-gt setleader
Fail(q1,i,q2) bool q1good(i) AND
card(q1good) gt n-f AND q2 q1 WITH
good remove(i, q1good)
15Example 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
16PVS 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 leaders group view
without being authenticated by at least one good
leader - If a user A is authenticated by at least f1 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
17Conclusion
- 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