Agenda

2. Agenda • Overview • Intrusion Tolerant CORBA Architecture • Survivability Assurance • Integration • Plans and Progress to Date • Summary

3. Overview

4. Motivation • Mission critical applications are being developed using CORBA on COTS platforms • CORBA Security protects at middleware level, but applications vulnerable to O/S and network attacks • Fault Tolerant CORBA does not protect against malicious faults

5. Technical Objectives • Provide intrusion tolerance for CORBA applications • System level approach • Middleware • Eliminate reliance on any single server • secure, reliable group communication directly between clients and replicated servers • Detect Byzantine (arbitrary) faults in servers • Support heterogeneity (diversity of implementation) • Boundary controllers (firewalls) • Protocol inspection • End-to-end authentication between clients and servers

6. Existing Approaches • OMG supports Fault Tolerance for CORBA • Doesn’t tolerate Byzantine faults • No firewall support • Prior and Current Research • Avoided ORB changes by intercepting process level communications; forces homogeneous server implementation • Uses “primary” or “lead” server that may not tolerate Byzantine faults • Ensemble, Maestro, AQuA, Rampart, Eternal, others

7. Technical Approach • Leverage prior work on fault tolerant CORBA; secure, reliable, authenticated multicast; total ordering; Byzantine fault detection • Modify prior work to fit intrusion tolerance requirements • Active replication of clients and servers with voting • Protect client and server hosts with application proxy firewall; include firewall in multicast group • Integrate with open-source ORB • Detect value faults in middleware • Replace transport layer with secure, reliable, authenticated multicast

8. Expected Achievements • At least one implementation of an ORB on two or more heterogeneous platforms that tolerates Byzantine faults • Integrated application proxy firewall support to protect COTS client and server hosts • Understand trade-off between performance and degrees of intrusion tolerance • Develop Countermeasure Characterization to identify assumptions and residual risks

9. Intrusion Tolerant CORBAArchitecture

10. Simplifying Assumptions • Addition of replacement servers not addressed (first iteration) • Network does not partition • Secure configuration mechanism

11. Conceptual Overview Server-Side Firewalls Redundant Servers Client Application Code IT ORB Voter Marshalling Secure, Reliable Multicast IP Multicast Server Application Code IT ORB Client-Side Firewall Firewall IT-CORBA Proxy Group Mgr Firewall IT-CORBA Proxy (Secure, Reliable Multicast) Server Application Code IT ORB Firewall IT-CORBA Proxy Group Mgr Server Application Code IT ORB Firewall IT-CORBA Proxy Group Mgr

12. Replication Domain Element Replicated Objects

13. Replication Domains and Elements • Replicated domain element (RDE) • Contains application objects • Fundamental unit of replication • Each RDE in a domain replicates the same set of application objects • Authenticates messages sent to others • Constraint: • If 2 replicated objects are co-located in one RDE, they are co-located in all RDEs containing either object • Replication domains • Contain Replication Domain Elements

14. “C” Object Replicas “C” Object Replicas “C” Object Replicas “C” Object Replicas Example Replication Domain Replication Domain “A”

15. Communication Groups • Analogous to unicast connections • Two multicast addresses - one each way • Secrecy key • Typically pooled & reused for later invocations Replication Domain “A” Replication Domain “B” Request Reply A1 B1 A2 B2 A3 B3

16. Group Manager RDE

17. Group Manager • Replicated service • Not an object • Independent of the ORB, no ORB marshalling • Uses lower level transport directly • Establishes own replication domain • Located at a well-known multicast address

18. Group Manager Functions • Manages groups by: • Assigning multicast addresses to replication domains • Generating, assigning & distributing communication group secrecy keys • Tracking and managing membership • Re-keying for changes in group membership • Administers policy • Secrecy • Replication • Communication/access control

19. Secure Multicast InterORB Protocol

20. ORB Interface

21. ORB Interface • Provides SMIOP as connection-oriented communication between ORBs • Provides access to ORB’s marshalling layer from transport. • Installed as TAO extensible transport

22. TAO Integration Application TAO ORB SMIOP Connection Manager SMIOP Protocol Factory SMIOP Pluggable Protocol SMIOP Acceptor SMIOP Connector SMIOP Transport ITDOS Socket Secure Reliable Multicast IP Multicast

23. ITDOS Sockets

24. ITDOS Sockets • Convenient, accessible abstraction • Holds & updates communication group keys • Silently calls on Voter for inbound messages

25. Socket Manager

26. Socket Manager • Endpoint for SMIOP connection and group management messages • Handles details of open/close/control connection • Receives and dispatches key update operations • Unifies error & timeout indication

27. Voter

28. Voter • Coalesces duplicate messages • Duplicate inbound invocations from replicated client group • Duplicate replies from server group • Value voting • Generate agreement on the value of request or reply • Identifies senders that disagree as Byzantine • Floating Point Voter (Washington State Univ.) • Need deterministic behavior; cannot modify values to compute results of the vote (e.g., mean average not usable) • Handles Byzantine processes • Remove offending process and all other processes on the same host from all groups

29. Voting 1 - Send request 2 - Receive request 3 - Send reply 4 - Receive reply “B” replicas Value Votes Vv Vv Vv Vv Vv Vv Value Votes “A” replicas

30. Secure Reliable Multicast

31. Secure Reliable Multicast • Uses IP multicast • Reliable transport • Totally ordered • Tolerates Byzantine reliability & ordering failures • Authenticated & confidential • Uses protocol developed by Castro & Liskov • “Practical Byzantine Fault Tolerance” — Feb. 1999 & Nov. 2000 (thesis)

32. Integrating Castro-Liskov • Castro-Liskov uses a Replicated State-Machine model • Replica state held in a contiguous memory block • Synchronizes state between replicas when it cannot recover a message • Doesn’t map well to a CORBA application • ITDOS defines “state” as the ordered set of messages delivered to a process • Contiguous memory block is used as a queue for delivered messages • Queue management delivers messages to ORB transport and synchronizes garbage collection

33. Integration Model Castro-Liskov Thread ORB Thread Message Queue 1 2 3 4 5 6 7 8 9 Castro-Liskov BFT M/C IP Multicast

34. Survivability Assurance

35. Countermeasure Characterization • CMC is a simple mechanism • takes a lot of thought • easy to produce • Conveys the essential and distinctive features and dependencies. • Highlights threats that are not addressed by objectives or assumptions • Extensible to entire systems • evaluation tool for secure architectures • basis for selecting countermeasures

36. RATIONALE TABLE

37. Example: Firewall CCM Requirements Rationale Table

38. Integration Opportunities

39. Integration Opportunities • Potential to investigate more complete intrusion tolerant systems • Many systems use CORBA backend, web front-end • Single point of failure if using standard web server as singleton CORBA client to replicated servers • Replicated web servers as clients to IT CORBA backend? • Alternative Byzantine Fault Tolerant protocol • Evaluate performance trade-offs, resiliency

40. Progress to Date and Future Plans

41. Progress to Date • Developed draft Intrusion Tolerant CORBA Architecture: • Selected Castro-Liskov for underlying Byzantine Fault Tolerant protocol • Presented IT CORBA architecture at DOCSec Workshop in Annapolis (March 29, 2001) • Building IT CORBA prototype for TAO / C++ / Linux • Developing Countermeasure Characterization of IT CORBA Architecture

42. Schedule

43. Near-term Plans • Complete initial IT CORBA prototype for Linux • Update IT CORBA Architecture document • Design Firewall Architecture • Present architecture to TAO Workshop in St. Louis, August 5-6

44. Summary

45. Summary • Completed Intrusion Tolerant CORBA Architecture Draft • Provides correct operation when fewer than f out of 3f+1 replicated components are faulty • Supports heterogeneous replicas • Started IT CORBA prototype implementation • Started Countermeasure Characterization to validate assurance claims

46. Backup

47. Approach -- What’s Different ? • All servers are equal • eliminate need for “primary” or “lead” server • Detect value faults in the ORB • encoding of CORBA messages depends on the source platform (i.e, byte ordering) • permits heterogeneous implementations • different O/S, hardware, ORBs • permits parametric comparisons • exact matches not required for inexact values (e.g., floating point)

48. Approach -- What’s Different ? • Transparent object replication • Application proxy firewall integrated into the architecture • better protection for COTS client and server hosts • end-to-end authentication of client and server • may have better performance than IIOP/SSL proxies

49. Socket Manager • Manages endpoints for SRM Socket connection and group management messages • Handles details of open/close/control connection • Receives and dispatches crypto key update operations • Unifies error & timeout indication