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

bruno@sdl.sri.com

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