Intrusion Tolerant Software Architectures

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

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

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

6. 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. Group Key Share Generation Based on Cachin, Kursawe, and Shoup, 2000 • Leader secret: • Public values: • Share: • Validity proof:

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. Existing Applications Four Basic Plugins: Whiteboad, Chat, File transfer, Streaming Audio

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. 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. 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)

13. Results (cont’d) • Secret sharing and group key generation

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. 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. 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. 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. 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