1. Intrusion Tolerant Distributed Object Systems OASIS PI Meeting Norfolk, VA February 12-16, 2001 Gregg TallyBrent Whitmore gtally@nai.combwhitmor@nai.com

2. February 13, 2001 2 Agenda Motivation Overview Plans and Progress to Date Intrusion Tolerant CORBA Architecture Summary

3. February 13, 2001 3 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

4. February 13, 2001 4 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

5. February 13, 2001 5 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

6. February 13, 2001 6 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

7. February 13, 2001 7 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

8. February 13, 2001 8 Progress to Date Developing Intrusion Tolerant CORBA Architecture: – Documented low-level use cases – Reviewed prior work: Fault tolerant systems: Electra, Eternal Group communication systems: Rampart, Transis, ISIS, AQuA, SecureRing / SecureGroup, Castro-Liskov Cryptographic algorithms: – Burmeister-Desmedt's Eurocrypt 94 paper – Shoup's Eurocrypt 2000 threshold signature paper – Menezes et al's "Handbook of Applied Cryptography", OMG’s Fault Tolerant CORBA specifications WSU / Verizon-BBN Virtual Voting Machine

9. February 13, 2001 9 Progress (cont’d) Selected TAO as the prototype implementation ORB Received source code for Castro-Liskov group communication system Initial architecture nearing completion

10. February 13, 2001 10 Intrusion Tolerant CORBA Architecture

11. February 13, 2001 11 Conceptual Overview Firewall Secure, Reliable, Auth. Multicast GIOP Proxy Client Application Code IT ORB Voter Value Fault Detection / Voting Redundant Msg. Exclusion Time, Crash, other Fault Detection Encode/Decode Secure, Reliable, Auth. Multicast Firewall M-Cast GIOP Proxy Server Application Code IT ORB Server Application Code IT ORB Server Application Code IT ORB Firewall M-Cast GIOP Proxy Firewall M-Cast GIOP Proxy Client-Side Firewall Server-Side Firewalls Redundant Servers ITDOS Services

12. February 13, 2001 12 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)

13. February 13, 2001 13 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

14. February 13, 2001 14 Operating Constraints  f faulty processors  3 f available processors Deterministic services Separation of replicated servers – network – geography

15. February 13, 2001 15 Simplifying Assumptions Addition of replacement servers not addressed (first iteration) Network does not partition such that more than f servers are unreachable Secure configuration mechanism Other CORBA services handle these application needs: – object-level access control – audit – non-repudiation – user-level authentication

16. February 13, 2001 16 Architecture Detailed IT ORB Voting Machine Replication Manager Encode/Decode Secure Reliable Multicast Application Code Group Manager Replica Locator ITDOS Services Replicate d Objects

17. February 13, 2001 17 Voting Machine IT ORB Voting Machine Replication Manager Encode/Decode Secure Reliable Multicast Application Code Group Manager Replica Locator ITDOS Services

18. February 13, 2001 18 Voting Machine Borrows from Washington State University/Verizon- BBN work Abstracts out the voting algorithm Determine result from possibly inexact matches Permits alternatives to majority voting & strict equivalence Examples: – mean, median, mode – majority rule – floating point comparison

19. February 13, 2001 19 ITDOS Services - Group Manager IT ORB Voting Machine Replication Manager Encode/Decode Secure Reliable Multicast Application Code Group Manager Replica Locator ITDOS Services

20. February 13, 2001 20 Secure Multicast Groups Two flavors – Replica groups – Communication groups Features – IP Multicast address – Intra-group message secrecy – Message authentication Replicated Group Manager object – Creates/destroys groups – Tracks and manages membership – Administers secrecy, authentication, communication policy

21. February 13, 2001 21 Replica Groups Bind VM algorithm selections Define vote points – Send request/receive reply – Send reply/receive request “A” replicas “B” replicas

22. February 13, 2001 22 Communication Groups Serves an invocation binding Analogous to unicast connections Members see all requests & replies between client & server replica groups “A” replicas “B” replicas

23. February 13, 2001 23 Voting Value voting – Receiver – Generates agreement on the value of the request or reply Detection voting – Sender – Detects failure to invoke consistently on other objects Consequences of failure – Remove offending process from all groups

24. February 13, 2001 24 Voting “A” replicas “B” replicas 4 - Receive reply 3 - Send reply 1 - Send request 2 - Receive request DvDvDvDv DvDvDvDv DvDvDvDv DvDvDvDv DvDvDvDv DvDvDvDv VvVvVvVv VvVvVvVv VvVvVvVv VvVvVvVv VvVvVvVv VvVvVvVv Detection Votes Value Votes

25. February 13, 2001 25 ITDOS Services IT ORB Voting Machine Replication Manager Encode/Decode Secure Reliable Multicast Application Code Group Manager Replica Locator ITDOS Services

26. February 13, 2001 26 Replication Manager Manages replication policy – Replica group cardinality – Policy granularity at replica group level Directs Group Manager to establish replica group memberships Called by ORB at object activation – Replication transparent to client and server objects

27. February 13, 2001 27 Replica Locator Naming service Helps Replication Manager to: – Initiate group creation – Track replica assignment to groups Helps ORB bind CORBA objects to replica groups

28. February 13, 2001 28 Secure Reliable Multicast Protocol IT ORB Voting Machine Replication Manager Encode/Decode Secure Reliable Multicast Application Code Group Manager Replica Locator ITDOS Services

29. February 13, 2001 29 Secure Reliable Multicast Protocol Properties – Reliable Delivery by processes integrity - delivered only once & only if sent agreement - all delivered or none validity - delivered if sent – Totally ordered – Secure source authenticity message integrity confidentiality Uses IP multicast

30. February 13, 2001 30 Summary Continuing to refine Intrusion Tolerant CORBA Architecture – Developed initial architecture – Re-use and modify prior work to meet IT CORBA requirements – Expect to complete Architecture by end of March; begin implementation Plan to start Countermeasure Characterization in March

31. February 13, 2001 31 Backup

32. February 13, 2001 32 Metrics Cost/benefit of redundant servers – Tolerance of Byzantine faults (number of faulted servers) vs. impact on throughput due to additional replication – Throughput measured by operations per second – Invocation latency IA Countermeasure Characterization Experimentation at the TIC to validate countermeasure claims

33. February 13, 2001 33 4 Questions - Threats / Attacks Tolerate Byzantine (arbitrary) behavior by some threshold number (f) of servers in a replicated group of (n) object servers.  Guarantee availability of the servers, provided that greater than the threshold number of servers has not been compromised.  Guarantee integrity of the communication between the clients and servers, and accuracy of the answers provided by the servers.  Confidentiality of the communication, unless a replicated server or Group Manager is compromised  Given these considerations, any attack against a replicated server in our system may be defended against as long as the resilience threshold (of the replicated group) is not exceeded. However, we should note that DOS attacks against individual servers can affect the system as a whole in that it may impede performance, and possibly affect the eventual exclusion of the attacked (but correct) process.

34. February 13, 2001 34 4 Questions - Assumptions The OS and platforms are vulnerable to attack and failure, but a vulnerability in one OS or platform does not necessarily imply that a different OS or platform has the same vulnerability (i.e., diversity of implementation provides better survivability). We rely upon the integrity of the network infrastructure to the extent that not more than f replicated servers become unreachable. The network does not partition such that more than f of the replicated servers becomes unreachable. We assume that there will be  f faults in a replicated group at any one time, where the number of servers in the replicated group is > 3 f. Servers exhibit deterministic behavior.

35. February 13, 2001 35 4 Questions - Assumptions (cont’d) A correct server can not be delayed indefinitely. Cryptography prevents identity forgery and traffic sniffing Object-level access control, audit, non-repudiation, and user- level authentication are performed by other CORBA services. QoS and QoP are performed by entities external to our system. In a real deployment of our system, to limit the incidence of simultaneous failures, network and geography separate the replicated servers. We assume that the authentication tokens for each process are adequately protected and only available to authorized users.

36. February 13, 2001 36 4 Questions - Policies Policies governing group membership, based on identity of processes wishing to join groups: – Rules indicating fault tolerance level, which directly impacts the number of processes required for a replicated object group. – Policies on “open” operations. An open operation is performed when a client wishes to establish a connection with a replicated group. Voting behavior. In certain cases, there may be legitimate differences in values between replicas, even though the values are equivalent. There may be other cases where voting behavior can be driven by policy. Object-access control, although these will be enforced by CORBA security mechanisms. Those mechanisms are outside the scope of our project. Standard firewall behavior policies (permit / deny) to regulate the secure, reliable multicast protocol. INFOCON changes, especially those for replication levels.

37. February 13, 2001 37 4 Questions - Collection of Projects Integrate with intrusion detection – If an intrusion detection system noted a certain level of intrusion in a given network, an intrusion tolerant architecture could downgrade trust for entities within that network. – Or, in a replicated system, remove a replica from that network, and add one to another to proactively counteract the attack.

38. February 13, 2001 38 Schedule

39. February 13, 2001 39 Technology Transfer Work with OMG to revise existing specifications, create new specifications – Fault Tolerance specification – Unreliable Multicast specification – Firewall specification Joint experimentation with other DARPA and DoD programs Conferences and workshops