Intrusion Tolerant Software

Architectures

Bruno Dutertre, Valentin Crettaz, Victoria Stavridou

System Design Laboratory, SRI International

bruno@sdl.sri.com

OASIS PI MeetingHilton Head, SC

March 13, 2002

2 2

Outline

Status

Intrusion-tolerant Enclaves Software architecture Cryptographic Protocols Tests and performance

Prototype Wireless Enclaves Implementation issues Security issues Future work

Conclusion

3 3

Status

Architecture refinement and transformation for intrusion-tolerant

systems Study of transformations that preserve noninterference properties

Security analysis of GENOA/CrisisNet (Eric Monteith, NAI Labs) Intrusion-tolerant CrisisNet (under way)

Intrusion-tolerant Enclaves Implementation and experiments Wireless prototype

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

Enclaves in 2000 and Before

Centralized Architecture

A single leader in charge of Authentication Group and Key

Management

Several Versions 1996-1997: Prototypes 2000: More robust

protocols for increased security, new implementation in Java

Leader

Member

MemberMember

Member

Member

6 6

Leader

Member Member

Leader Leader

Member

Leader

Intrusion-Tolerant Enclaves

Intrusion tolerance: Group management

performed by N distributed leaders

Tolerate failure of up to f leaders (provided 3f < N)

Technology Byzantine fault-tolerant

coordination protocol Threshold cryptography

(secret sharing) for group key management

Standard crypto for group communication

7 7

Group Key Share Generation

Leader secret:

Public values:

Share:

Validity proof:

ix

pggg ixi mod

ixi gsgdata ~~Hash

),,~,,,(~ random vsguggHcgv

guy iiy

y

Based on Cachin, Kursawe, and Shoup, 2000

8 8

Implementation

Java-based (SDK 1.3.1)

Uses Cryptix 3.2 libraries + our

implementation of the secret

sharing protocol

Applications incorporated via a

“plug in” mechanism

Code size: 10,000 lines of code Byte code

Leader: 196 Kb Client: 342 Kb

9 9

Existing Applications

Four Basic Plugins: Whiteboad, Chat, File transfer, Streaming Audio

10 10

Performance Issues

Leader coordination protocol: N digitally signed messages per user

Group key management Each leader generates a key share + a proof of validity Member gets at least f+1 shares, checks their validity, and

constructs the group key from f+1 valid shares Computation based on exponentiation modulo a large number p:

Share generation: 3 exponentiations Checking validity: 4 exponentiations per share Building the key: f+1 exponentiations

Intrusion-tolerant protocols require expensive crypto

11 11

Experiments

Test bed: 4 leaders on Pentium PCs (400 to 500MHz), Redhat Linux Clients on similar PCs Crypto:

512 bit DSA signatures Triple DES for symmetric-key encryption Length of a share: 128, 512, or 1024 bits

Measure: Signature generation/verification times Share generation time for a leader Share verification and group key construction for a client Encryption of group communication for different size of messages

12 12

Results

Digital Signatures (DSA-512 bits) Generation: 30-120 ms Verification: 30 ms

Encryption of messages:

Reasonable performance for a Java implementation

Existing C libraries do far better (e.g., openssl does more than 300

DSA-512 signatures per seconds on the same machine)

Message Size 1K 10K 50K

Encryption time 30-40 ms 120-140 ms 280-350 ms

13 13

Results (cont’d)

Secret sharing and group key generation

Share size 128 bits 512 bits 1024 bits

Share generation 3 -7 ms 150 -180 ms 800 - 1000ms

Share verification 12 - 40 ms 180 - 300 ms 1300-1700 ms

Key construction 29 - 40 ms 95 -131 ms 500-650 ms

Total connection time

(client on a 500MHz PIII)1.5 - 1.8 s 2 - 2.3 s 5 - 5.5 s

14 14

Performance Assessment

Performance with current implementation Connection time slow but still reasonable for human users Other operations are fast enough: encryption of small messages

Possible optimizations: Replace digital signatures with MACs, using point-to-point

communication between leaders Other optimizations possible to reduce signature overhead

Secret sharing algorithm will remain the bottleneck Possible improvement: native code

15 15

Wireless Enclaves Prototype

Port of Enclaves to IPAq: IPAq 3760:

StrongARM 206MHz 64MB RAM + 34 MB ROM

Linux OS Blackdown JAVA: 16MB

Wireless protocols: (ad hoc network) TBRPF routing protocol (SRI

ITAD) TBRPF-specific implementation

of IP multicast

Demo application: shared map + whiteboard

16 16

Performance issues

Crypto: Acceptable performance only with share length = 128 bits With share length = 512 bits, connection time is more than 1 minute Most likely explanation: no just-in-time compilation in the JVM

Solution: Native-code implementation of the secret sharing algorithm (under

way)

Java: Big footprint for the IPAq: Blackdown JRE: 11 Mbytes + core libraries: 5 Mbytes

17 17

Security Issues

TBRPF has no security Assumes all nodes are trustworthy Deals only with link failures

That’s a common problem with most ad hoc routing protocols

Enclaves architecture not designed for ad hoc networks: Server based (fixed set of leaders, known in advance) Clients need to maintain connectivity with at least 2f+1 leaders

Future work: Remove need for prespecified fixed leaders Improve security and reliability of the underlying wireless protocols

18 18

Conclusion

Prototype shows feasibility of intrusion-tolerant Enclaves despite

heavy secret sharing algorithm

Future work: Enclaves security validation (including formal verification) Improved implementation Relation with architecture refinement ideas

Wireless Enclaves: Requires new architecture Requires work on security of wireless protocols