CORBA Security Service: An Overview

1
CORBA Security Service An Overview

• Ming Xiong ltmxiong_at_dre.vanderbilt.edugt
• October 30, 2005

2
Agenda

• Motivation
• Overview
• CORBA Security Reference Model
• Participation
• Principals
• Secure object invocations
• Access Control
• Auditing
• Delegation
• Non-repudiation
• Domain
• CORBA Security Implementation Architecture
• Related work

3
Motivation

• CORBA starts without security
• The add-on security solutions either foster
  confusions regarding CORBA securitys use and
  utility, or lack the capabilities to meet the
  specific security requirement by CORBA
  applications
• We need an application-level standard that
  addresses the potential security needs of
  distributed object systems without specifying a
  feature solution for any specific system

4
Overview of CORBA Security Service

• First submitted on 1995-12-01, current version is
  1.8
• Defined and discussed by the OMGs Security
  Special Interest Group (SecSIG), chartered by the
  OMGs Architecture Board (AB) - indicates how
  important the OMG think security issues are!
• The purpose of the spec is to- Define a overall
  security reference model for CORBA- Describe an
  architecture that can be integrated with current
  security technologies- Define facilities and
  interfaces available to application as well as to
  ORB implementers
• But not to- Define any specific security
  technology

5
Reference Model

• Describe how and where the secure system enforce
  the security policies, e.g. - under what
  conditions active entities can access objects
• Sufficiently general to cover a wide variety of
  security policies and application domains
• Elements of the reference model . Participation
  . Principals and their security attributes .
  Secure object invocation . Access control model
  . Auditing . Delegation . Non-repudiation .
  Domains

6
Participation

• Security unaware - the application relies
  completely on the middleware for security -
  transparent protection should be provided
• Security policy controlling- the application
  directs the middleware to use specific,
  predefined policies, but relies on the middleware
  on enforcement
• Security policy enforcing- the application
  directs middleware to use specific policies and
  actively examines security context information to
  enforce policy

Different levels are not mutually exclusive
7
Principle

• Definition each human user or independently
  operating software entity that is registered in
  and authenticate to the system
• A principal has at least one identity it may
  have multiple identities- the mechanisms used
  to identify and authenticate principles can be
  internal or external, e.g. login procedure-
  identity can have different purposes
• A principal may also have privilege attributes
  that can be used to decide what it can access-
  attribute information is maintained in a
  credential

8
Secure Object Invocations

• What may happen during a secure invocation?-
  Establishing security association .
  establishing trust in each others identity .
  making the clients credentials available to
  target (server) object . establishing
  security context information, i.e. security
  policy- Deciding whether a principal or a
  client (representing an principal) can perform
  certain operations on an object - Auditing
  invocations if required- Message protection
  . Message integrity . Message confidentiality

9
Access Control Model

• A simple framework for many different control
  security policies.
• Two layers- Object Invocation Access Policy,
  which is enforced by ORB or security services.-
  Application Invocation Access Policy, which is
  enforced by client or object implementation

May control who can accept the request
May control who can access the invocation

• Decisions are based on
• Privilege Attribute, e.g. identity, groups, roles
  (related to the users job), security clearance
• Control Attribute, e.g. access control list,
  object label
• Application parameters

Defines condition that allow a target to accept a
object request
Defines condition that allow a client to access a
object invocation
10
Auditing

• Achieved by recording details of security related
  actions as events
• Audit policies are needed to classify events and
  to restrict the volume of recorded events
• System Audit Policy - Controls what events are
  recorded as a result of system activities, i.e.
  system events - Applied on all applications
• Application Audit Policy - Control what events
  are audited by application, i.e. application
  events

11
Privilege Delegation

• Delegation allows intermediary objects to
  represent the original principles identity and
  privilege attributes to subsequent targets
• Restrictions may be placed by client or by target
• CORBA Security Service provides different
  delegation mechanisms

• No Delegation
• Simple Delegation
• Composite Delegation
• Combined Delegation
• Traced Delegation

• Example

Client
Intermediate Object
Target
Client credential
Intermediate Credential
12
Delegation of attributes

• Delegation allows intermediary objects to
  represent the original principles identity and
  privilege attributes to subsequent targets
• Restrictions may be placed by client or by target
• CORBA Security Service provides different
  delegation mechanisms

• No Delegation
• Simple Delegation
• Composite Delegation
• Combined Delegation
• Traced Delegation

• Example

Client
Intermediate Object
Target
Client credential
Intermediate Credential
13
Delegation of attributes

• Delegation allows intermediary objects to
  represent the original principles identity and
  privilege attributes to subsequent targets
• Restrictions may be placed by client or by target
• CORBA Security Service provides different
  delegation mechanisms

• No Delegation
• Simple Delegation
• Composite Delegation
• Combined Delegation
• Traced Delegation

• Example

Client
Intermediate Object
Target
Client credential
Intermediate Credential
14
Delegation of attributes

• Delegation allows intermediary objects to
  represent the original principles identity and
  privilege attributes to subsequent targets
• Restrictions may be placed by client or by target
• CORBA Security Service provides different
  delegation mechanisms

• No Delegation
• Simple Delegation
• Composite Delegation
• Combined Delegation
• Traced Delegation

• Example

Client
Intermediate Object
Target
Client credential
Intermediate Credential
15
Delegation of attributes

• Delegation allows intermediary objects to
  represent the original principles identity and
  privilege attributes to subsequent targets
• Restrictions may be placed by client or by target
• CORBA Security Service provides different
  delegation mechanisms

• No Delegation
• Simple Delegation
• Composite Delegation
• Combined Delegation
• Traced Delegation

• Example

Client
Intermediate Object
Target
Client credential
Intermediate Credential
Combined Credential
16
Delegation of attributes

• Delegation allows intermediary objects to
  represent the original principles identity and
  privilege attributes to subsequent targets
• Restrictions may be placed by client or by target
• CORBA Security Service provides different
  delegation mechanisms

• No Delegation
• Simple Delegation
• Composite Delegation
• Combined Delegation
• Traced Delegation

• Example

Client
Intermediate Object
Target
Client credential
Intermediate Credential
17
Non-Repudiation

• A user of a secure systems shall be prevented
  from denying their actions within the system
• Non-Repudiation provide facilities to make users
  and other principals accountable for their
  actions
• Irrefutable evidence about a claimed event or
  action is generated and can be checked later to
  provide proof of the action
• Evidence is usually composed of -
  non-repudiation policy - type of action or
  event - parameters related to the action - date
  and time

18
Domain

• Objects in a secured system are organized into
  domains. Policies are defined with respect to a
  domain. There are several types of domains-
  Security Policy Domain- Security Environment
  Domain- Security Technology Domain

Example Hierarchical domain
19
Implementation Architecture

• Describes how the referenced model is implemented
• Should have four levels during object invocation
  - Application level components - Components
  implementing security services, including ORB
  core, ORB services, Security services and policy
  objects - Components implementing specific
  security technology - Basic protection and
  communication, provided by a combination of
  hardware and operating system mechanisms

20
OMG Security Architecture
A client simply invokes an operation via object
reference
When protection policy requires message integrity
or confidentiality, ORB core use a secure
communication protocol to establish trust
The distinction between underlying security
technology and security services/protocol allows
ORB implementers to choose appropriate security
technology
Security services/protocol rely on the underlying
security technology
ORB core is responsible for invoking security
services specified by applicable security policy
21
TAO Security Architecture
Client
A OpenSSL wrap-up that supports 1.Peer
authentication 2.Message integrity 3.Message
confidentiality
ORB Services
ORB Core
SSLIOPLevel1
Communication Protocol
SSLIOP

• Provide security aware application with
• Access to security attributes
• A means to control message protection level
• A means to control the establishment of trust
  between clients and servers

ORB
OpenSSL
22
Building Security Application in TAO

• Security Unaware Application- Largely a matter
  of configuring the environment, e.g. .conf file-
  Configuration file must specify the environment
  variables, e.g. the path to the CAs certificate
• Security Policy Controlling Application-
  Controlling message protection, e.g., by Quality
  of Protection Policy- Controlling Peer
  Authentication, e.g., by Establish Trust-
  Different policies can be configured via the
  interfaces provided by security service- We can
  enforce certain security certain policies to
  prevent application from downgrading the security
  level, e.g. no protection
• Security Enforcing Application- Cant take
  complete responsibility, because of contributing
  factors outside a software applications
  control- The context information made available
  via SecurityLevel is derived from a secure
  association that exists between a client and a
  server- The application can take an active part
  in enforcing the security policies by getting
  context information of security, e.g. by using
  no_context (), it can prevent malicious users
  from shutting down the server

23
Related work

• OASIS is working on a technical foundation for
  implementing security functions such as integrity
  and confidentiality in messages implementing
  higher-level Web services applications (Web
  Services Security (WSS)) http//www.oasis-open.o
  rg/committees/tc_home.php?wg_abbrevwss
• OMG is current working on a Security Service
  Protocol (SECP, submitted by Object Interface)
  aimed at CORBA applications. A formal method is
  used in this specification which allows the new
  protocol to not only verify the temporal aspects
  of the protocol, but also to formally verify
  certain modal propositions about the protocol.
  These propositions are formally verified using
  model checking tools. - OMG is intended to
  replace CORBA security service with
  SECPhttp//www.omg.org/technology/documents/form
  al/omg_security.htmSECP

24
What we are doing

• We are exploring the possible solutions for
  security issues regarding XML-based meta-data -
  The deployment infrastructure for CIAO/DAnCE is
  driven by XML, so it is necessary to be able to
  verify the authenticity of the metadata to
  prevent hijacking the infrastructure to deploy
  rogue components- XML signature?
• DDS security

25
references

• OMG CORBA Security Specification,
  v1.8http//www.omg.org/docs/formal/02-03-11.pdf
• TAO Developers Guide v1.3a, page 925- 1002,
  Object Computing Inc, 2003
• CORBA Security Overview, Chris Cleeland, Rob
  Martin,http//www.ociweb.com/cnb/CORBANewsBrief-2
  00205.html
• Security Service Protocol Specification,
  submission version http//www.omg.org/docs
  /security/04-06-01.pdf
• XML Signature WGhttp//www.w3.org/Signature/

26
Questions?
27
Extra info

• How SSL works?- customer contacts you with a
  secured URL (https) secured by a server id-
  server sends the customer the public key- the
  customer sends a encrypted session id to the
  server- after the server received the session
  id, a secured session started..
• What is secure communication?- Authentication a
  peers identity is genuine- Message Integrity
  the message can not be modified in transit
  without detection- Message confidentiality only
  a messages intended recipient can read it
• What are the cryptography techniques that SSL
  use?- public-key cryptography- secrete-key
  cryptography

28
Secrete-Key Cryptography

• Called symmetric encryption, is based ona single
  key that is known by a messages originator and
  its receiver
• Only provides message confidentiality, i.e. it
  does not detect whether the message was modified
  in transit
• Pitfall the key has to be know by the
  originator, thus it needs to be sent to the
  originator in advance, which pose a potential for
  tampering. Solution key server

29
Public-Key cryptography

• Also know as asymmetric encryption
• Provides message integrity, identity
  authentication and key exchange at run time
• Message integrity- verify integrity by checking
  digest at the receivers side, a digest is a
  fixed length message generated from an arbitrary
  long messages. If the digest at the sender and
  receiver sides match, then the message is not
  modified in transit

30
Digital signature

• Used to confirms the authenticity of a messages
  originator
• A signature is created by encrypting a messages
  digest using the originators private key. The
  receiver reads the message (using public key) and
  compares it with a locally generated digest. If
  two digests are comparable, it proves that the
  public keys owner sent the message and that the
  message was received intact

31
Digital Certificate

• A electronic document containing- certificate
  holders identity- certificate holders public
  key- issuers identity
• DC is used to bind the public key with a key-pair
  holder
• DC holders offers their DCs as proof of their
  identity and a means of conveying their public
  key (to the receiver)

32
Creating Digital Certificates

• First create certificate authority- this will
  generate a private key for CA
• Then create a certificate request- this will
  generate a private key for the request
• CA signs the request- CA will generate a public
  key according to the private key provided by the
  request

33
CORBA security feature packages

• Main functional packagesLevel 1 provides the
  most basic security capabilitiesLevel 2
  provides additional interfaces for accessing
  principals credentials and additional
  capabilities for security policy control and
  administration
• Security Replaceability Packages- provides loose
  coupling method to integrate a CORBA security
  implementation with an ORB- places al security
  service code outside the ORB core- ORB Services
  Replaceability or Security Services
  Replaceability
• Common Secure Interoperability (CSI)
  Packages-CSI0 Security policies are based on
  identity attribute only-CSI1 Security policies
  are based on identity attributes only. Delegation
  optional-CSI2 Security policies are based on
  identity and privilege attributes
• SSLIOP Interoperability Package- specifies that
  the ORB generates and uses security information
  in IORs and exchange messages with ORBs via
  SECIOP protocol using GIOP/IIOP
• Security Mechanism Packages- SPKM- GSS- CSI-
  SSL

34
Extra references

• http//www.ourshop.com/resources/ssl.html