This is the Title Placeholder

1
(No Transcript)
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
• Doesnt 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 Marshall
ing 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
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
B3
A3
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 ORBs 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 Transport
SMIOP Acceptor
SMIOP Connector
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
• Doesnt 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 3f1 replicated components are faulty
• Supports heterogeneous replicas
• Started IT CORBA prototype implementation
• Started Countermeasure Characterization to
  validate assurance claims

46
Backup
47
Approach -- Whats 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 -- Whats 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