Intrusion Tolerant Software Architectures

1
Intrusion 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
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
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
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
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 3f1?n
• Relies on
• Threshold cryptography
• Consistent broadcast protocol
• Symmetric-key crypto

Member
Member
Member
Leader
Leader
Leader
Leader
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
Formal 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

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 f1 good
  leaders eventually enters the group
• Stronger consistency guarantees cannot be
  achieved (with a deterministic algorithm) in an
  asynchronous network

9
Coordination 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

10
Model 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

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
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
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 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)
14
PVS 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)
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
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 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

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