1. Intrusion Tolerant Software Architectures Bruno Dutertre, Valentin Crettaz, Victoria Stavridou System Design Laboratory, SRI International bruno@sdl.sri.com OASIS PI Meeting Hilton Head, SC March 13, 2002

2. 2 2 Outline t Status t Intrusion-tolerant Enclaves Software architecture Cryptographic Protocols Tests and performance t Prototype Wireless Enclaves Implementation issues Security issues Future work t Conclusion

3. 3 3 Status t Architecture refinement and transformation for intrusion-tolerant systems Study of transformations that preserve noninterference properties t Security analysis of GENOA/CrisisNet (Eric Monteith, NAI Labs) Intrusion-tolerant CrisisNet (under way) t Intrusion-tolerant Enclaves Implementation and experiments Wireless prototype

4. 4 4 Enclaves t Originally proposed by Li Gong (1996) as lightweight software for supporting secure group collaboration t Middleware for building secure groupware applications Support collaboration between human users For small to medium groups t 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 5 Enclaves in 2000 and Before t Centralized Architecture t A single leader in charge of Authentication Group and Key Management t Several Versions 1996-1997: Prototypes 2000: More robust protocols for increased security, new implementation in Java Leader Member

6. 6 6 Intrusion-Tolerant Enclaves t Intrusion tolerance: Group management performed by N distributed leaders Tolerate failure of up to f leaders (provided 3f < N) t Technology Byzantine fault-tolerant coordination protocol Threshold cryptography (secret sharing) for group key management Standard crypto for group communication

7. 7 7 Group Key Share Generation t Leader secret: t Public values: t Share: t Validity proof: Based on Cachin, Kursawe, and Shoup, 2000

8. 8 8 Implementation t Java-based (SDK 1.3.1) t Uses Cryptix 3.2 libraries + our implementation of the secret sharing protocol t Applications incorporated via a “plug in” mechanism t Code size: 10,000 lines of code Byte code Leader: 196 Kb Client: 342 Kb

9. 9 9 Existing Applications Four Basic Plugins: Whiteboad, Chat, File transfer, Streaming Audio

10. 10 Performance Issues t Leader coordination protocol: N digitally signed messages per user t 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 t 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 t 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 t Digital Signatures (DSA-512 bits) Generation: 30-120 ms Verification: 30 ms t Encryption of messages: t Reasonable performance for a Java implementation t Existing C libraries do far better (e.g., openssl does more than 300 DSA-512 signatures per seconds on the same machine) Message Size1K10K50K Encryption time30-40 ms120-140 ms280-350 ms

13. 13 Results (cont’d) t Secret sharing and group key generation Share size128 bits512 bits1024 bits Share generation3 -7 ms150 -180 ms800 - 1000ms Share verification12 - 40 ms180 - 300 ms1300-1700 ms Key construction29 - 40 ms95 -131 ms500-650 ms Total connection time ( client on a 500MHz PIII) 1.5 - 1.8 s2 - 2.3 s5 - 5.5 s

14. 14 Performance Assessment t Performance with current implementation Connection time slow but still reasonable for human users Other operations are fast enough: encryption of small messages t Possible optimizations : Replace digital signatures with MACs, using point-to-point communication between leaders Other optimizations possible to reduce signature overhead t Secret sharing algorithm will remain the bottleneck Possible improvement: native code

15. 15 Wireless Enclaves Prototype t Port of Enclaves to IPAq: IPAq 3760: StrongARM 206MHz 64MB RAM + 34 MB ROM Linux OS Blackdown JAVA: 16MB t Wireless protocols: (ad hoc network) TBRPF routing protocol (SRI ITAD) TBRPF-specific implementation of IP multicast t Demo application: shared map + whiteboard

16. 16 Performance issues t 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 t Solution: Native-code implementation of the secret sharing algorithm (under way) t Java : Big footprint for the IPAq: Blackdown JRE: 11 Mbytes + core libraries: 5 Mbytes

17. 17 Security Issues t 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 t 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 t Future work: Remove need for prespecified fixed leaders Improve security and reliability of the underlying wireless protocols

18. 18 Conclusion t Prototype shows feasibility of intrusion-tolerant Enclaves despite heavy secret sharing algorithm t Future work: Enclaves security validation (including formal verification) Improved implementation Relation with architecture refinement ideas t Wireless Enclaves: Requires new architecture Requires work on security of wireless protocols