intrusion tolerant software architectures bruno dutertre and hassen saïdi system design laboratory,...
TRANSCRIPT
![Page 1: Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory, SRI International bruno@sdl.sri.com OASIS PI Meeting](https://reader035.vdocuments.net/reader035/viewer/2022070402/56649f225503460f94c3a4d3/html5/thumbnails/1.jpg)
Intrusion Tolerant Software
Architectures
Bruno Dutertre and Hassen SaïdiSystem Design Laboratory, SRI International
OASIS PI MeetingSanta Rosa, CA
August 20, 2002
![Page 2: Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory, SRI International bruno@sdl.sri.com OASIS PI Meeting](https://reader035.vdocuments.net/reader035/viewer/2022070402/56649f225503460f94c3a4d3/html5/thumbnails/2.jpg)
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
![Page 3: Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory, SRI International bruno@sdl.sri.com OASIS PI Meeting](https://reader035.vdocuments.net/reader035/viewer/2022070402/56649f225503460f94c3a4d3/html5/thumbnails/3.jpg)
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
![Page 4: Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory, SRI International bruno@sdl.sri.com OASIS PI Meeting](https://reader035.vdocuments.net/reader035/viewer/2022070402/56649f225503460f94c3a4d3/html5/thumbnails/4.jpg)
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
![Page 5: Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory, SRI International bruno@sdl.sri.com OASIS PI Meeting](https://reader035.vdocuments.net/reader035/viewer/2022070402/56649f225503460f94c3a4d3/html5/thumbnails/5.jpg)
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
![Page 6: Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory, SRI International bruno@sdl.sri.com OASIS PI Meeting](https://reader035.vdocuments.net/reader035/viewer/2022070402/56649f225503460f94c3a4d3/html5/thumbnails/6.jpg)
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
![Page 7: Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory, SRI International bruno@sdl.sri.com OASIS PI Meeting](https://reader035.vdocuments.net/reader035/viewer/2022070402/56649f225503460f94c3a4d3/html5/thumbnails/7.jpg)
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
![Page 8: Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory, SRI International bruno@sdl.sri.com OASIS PI Meeting](https://reader035.vdocuments.net/reader035/viewer/2022070402/56649f225503460f94c3a4d3/html5/thumbnails/8.jpg)
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
![Page 9: Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory, SRI International bruno@sdl.sri.com OASIS PI Meeting](https://reader035.vdocuments.net/reader035/viewer/2022070402/56649f225503460f94c3a4d3/html5/thumbnails/9.jpg)
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,
![Page 10: Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory, SRI International bruno@sdl.sri.com OASIS PI Meeting](https://reader035.vdocuments.net/reader035/viewer/2022070402/56649f225503460f94c3a4d3/html5/thumbnails/10.jpg)
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
![Page 11: Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory, SRI International bruno@sdl.sri.com OASIS PI Meeting](https://reader035.vdocuments.net/reader035/viewer/2022070402/56649f225503460f94c3a4d3/html5/thumbnails/11.jpg)
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
![Page 12: Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory, SRI International bruno@sdl.sri.com OASIS PI Meeting](https://reader035.vdocuments.net/reader035/viewer/2022070402/56649f225503460f94c3a4d3/html5/thumbnails/12.jpg)
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
![Page 13: Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory, SRI International bruno@sdl.sri.com OASIS PI Meeting](https://reader035.vdocuments.net/reader035/viewer/2022070402/56649f225503460f94c3a4d3/html5/thumbnails/13.jpg)
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
![Page 14: Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory, SRI International bruno@sdl.sri.com OASIS PI Meeting](https://reader035.vdocuments.net/reader035/viewer/2022070402/56649f225503460f94c3a4d3/html5/thumbnails/14.jpg)
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) ]
![Page 15: Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory, SRI International bruno@sdl.sri.com OASIS PI Meeting](https://reader035.vdocuments.net/reader035/viewer/2022070402/56649f225503460f94c3a4d3/html5/thumbnails/15.jpg)
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
![Page 16: Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory, SRI International bruno@sdl.sri.com OASIS PI Meeting](https://reader035.vdocuments.net/reader035/viewer/2022070402/56649f225503460f94c3a4d3/html5/thumbnails/16.jpg)
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
![Page 17: Intrusion Tolerant Software Architectures Bruno Dutertre and Hassen Saïdi System Design Laboratory, SRI International bruno@sdl.sri.com OASIS PI Meeting](https://reader035.vdocuments.net/reader035/viewer/2022070402/56649f225503460f94c3a4d3/html5/thumbnails/17.jpg)
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