Middleware Security Research Overview and Planned Projects

1
Middleware SecurityResearch Overview
andPlanned Projects
Ulrich Lang ulrich.lang_at_cl.cam.ac.uk www.cl.cam.
ac.uk/ul201
2
Agenda

• Current Research Overview
• Middleware
• Middleware security architecture
• Middleware security policy
• Resource descriptor mapping
• Proof of concept
• Planned further work
• Service platforms for telecommunications
• Secure CORBA Components (CCM)
• COACH

3
General Problem Definition

• Middleware scenario application entities, which
  are distributed across the network, need to
  communicate
• More flexible interactions than traditional
  client/server
• Transparent to the application programmer
• Also need protection, in particular
• Authentication of application entities
• Access control to target application entities
  based on the identity of the caller

4
General Problem Definition

• Key questions
• Where should the policy be stored, evaluated,
  enforced?
• How can useful policies be expressed using
  available security attributes?
• Which identities are available at which
  location/layer?
• What is the relationship between communications
  of software components and communications of
  network nodes?
• What to do if there are mismatches across layers?

5
Related Work

• Access control can be done at various points in
  the communications path
• Network
• Operating system
• Middleware ( VM)
• Application
• Explicit
• Implicit
• Domain Boundary

J. Rushby and B. Randell. A distributed secure
system. IEEE Computer, 1983
DIA. Compartmented Mode Workstation Evaluation
Criteria, 1991
Lang, Gollmann, Schreiner VerifiableIdentifiers
in Middleware Security, ACSAC01
OMG, Resource Access Decision Facility
Specification, 2001
I. Welch and R. Stroud, Kava - A Reflective
Java based on Bytecode Rewriting, 2001
T. Riechmann, F. Hauk, Meta Objects for Access
Control, 1997
Schreiner, Lang. CORBA firewalls Introduction
and Analysis, ObjectSecurity, 2000
6
Defining Middleware

• General term used for any software that glues
  together two separate programs (normally across
  the network)
• Our more specific definition
• Based on the object-oriented model
• Resides between the application and the
  underlying (communications) technology
• Abstracts complexities of underlying technology
  from applications
• Automatically handles all communications between
  client and target applications
• Supports application portability, mechanism
  flexibility, interoperability, and scalability

7
Middleware Architecture

• Layered architecture
• Interfaces at layer boundaries

8
Middleware Invocation
9
Middleware Security

• Add security features
• Authentication (principal, peer)
• Message Protection (integrity, confidentiality)
• Access Control
• Audit
• Fit into the layered middleware architecture
• Preserve design requirements

10
Security Architecture

• Application layer
• All features below the application layer
  integrated in the communications path
• Preserves abstraction, portability, automation
• Middleware layer
• Access control and audit policies
• Preserves flexibility, interoperability
• Underlying technology layer
• Cryptography (esp. authentication protocols
  across the network)
• Preserves flexibility, interoperability

Access Control, Audit, Policies
Crypto Mechanism Authentication, Message
protection, Verifiable crypto identities (keys)
11
Middleware Security Policy

• Task need to locate the access control (or
  audit) policy that has to be enforced on the
  incoming invocation, based on client and target
• Need to represent client and target in the policy
• (non-) solution use communications (crypto)
  identities

Client application software entity that
initiates invocations Target application
software entity that responds to invocations and
that is protected by the reference monitor
12
Middleware Security Policy

• Communications identities granularity problem!
• represent the reference monitor on the middleware
  
• not the individual application entities
  (clients/targets)
• General problem network vs. application

Identity name that can be authenticated used in
the access control policy to represent an entity
in the system Principal software entity that
resides on one end of the security association,
i.e. can be verified as legitimate holder of the
corresponding identity
13
Descriptors

• Need additional descriptors to represent
  individual clients/targets above the middleware
• What should exactly be described?
• Resource service offered by target instance
  instance can change over time, but it will be
  protected by the same access rule
• Descriptor properties
• Uniqueness within the middleware principal
• Persistency
• No authentication mechanism
• Coupling with invocation mechanism

14
Existing Descriptor Options

• Client
• No representation on the middleware layer
• Have to use cryptographic identities from the
  underlying technology layer
• Problems granularity, flexibility, abstraction
• Target
• Cryptographic identities not usable because
  usually there are several targets per middleware
  component
• Two options on the middleware layer
• Object interface not unique, reliable, coupled
• Request header (from object reference) not
  persistent, unpredictable before instantiation

15
Resource Descriptor Mapping

• What should exactly be described?
• Mapping configuration

Resource service offered to a client by a target
instance. The instance that provides a resource
can change over time, but it will always be
protected by the same access rule. Resource
descriptor describes (inside the access policy) a
resource that is provided by a target instance.
16
Resource Descriptor Mapping

• Invocation Mapping

Client
Target
Target
Object
Instance
Instance
Reference
1
Mapping Table
Target
Resource
instance
descriptor
identifier
2
crypto identities
crypto identities
17
MICOSec Proof-of-Concept

• CORBA
• Common Object Request Broker Architecture
• Common interfaces protocols
• Independent from vendors, programming languages,
  software or hardware platforms
• Specified since 1989 by the Object Management
  Group (OMG)
• Designed in line with our definition of middleware

18
MICOSec Proof-of-Concept

• CORBASec
• Security features authentication, message
  protection, access control, audit
• Interfaces
• Security-enhanced protocols
• Mechanism-independent, but specifies how to
  integrate Kerberosv5, SESAME, SPKM, SSL
• Integrates with CORBA through interceptors

19
MICOSec Proof-of-Concept

• MICOSec (http//www.micosec.org)
• Our OpenSource CORBASec Implementation
• Includes resource descriptor mapping
• Uses only OpenSource products
• MICO ORB
• OpenSSL library
• PostgreSQL database
• Full MICOSec was ported to a Compaq iPAQ 3630
  PocketPC (under Linux)
• Current future development
• Almost finished CSIv2
• Next Authorisation Service (ATLAS) based PMI
• CORBA Component Model (CCM) (with security!)

20
MICOSec Main Features

• CORBASec level 2 version 1.7
• security aware and security unaware applications
   
• All features of MICO (latest version), including
  POA
• SSLIOP based on SSL v 3 with different ciphers
• Extended attributes for X.509 and environment
  information
• Plain IIOP
• Authentication
• Message protection
• Policies for secure associations
• Extended level 1 interfaces
• Auditing into file/syslog/RDBMS
• Secure interoperability with other ORBs
• Object Domain Mapping
• Domain based access control and auditing
• Domain Membership Management 
• Common Secure Interoperability CSIv2 level 0

21
Book on CORBASec

• Book on CORBASec and MICOSec
• In the CL library
• Use discount flyer
• Order from www.objectsecurity.com/book.html

22
Conclusion

• Middleware architecture separates the security
  problem from the security solution
• No good representation of client and target in
  the security policy on the middleware layer
• Communications crypto should (?) be hidden below
  the middleware (for flexibility), i.e. should not
  use identities directly in the policy
• (non-)solution access control for software
  components based on access control for network
  components
• Real-world workaround
• Client use crypto identities (only option!)
• Target resource descriptor mapping ( crypto
  identity)

23
Agenda

• Current Research Overview
• Middleware
• Middleware security architecture
• Middleware security policy
• Resource descriptor mapping
• Proof of concept
• Planned further work
• Service platforms for telecommunications
• Secure CORBA Components (CCM)
• COACH

24
The Challenge

• Telecoms made huge investments in 3G, need quick
  ROI
• 3G offers great opportunities for new
  applications/services
• Examples
• location based services,
• banking and financial services,
• messaging,
• M-Commerce,
• M-Payment,
• games,
• multimedia,
• voice integration

25
The Challenge

• But In the past the telecom operators have
  performed well at providing networks, but failed
  at providing services
• Better platforms for services and applications
  needed
• Usable both for operators and 3rd party service
  providers
• Operators have to open their networks to service
  providers
• Security very important issue!
• Our goal Quick and easy development of secure
  telecom applications

26
Telecom Service Platforms

• Telecom service platforms are already available
  (TINA, Parlay)
• Runtime framework for applicationsLifecycle,
  user profile, notification, messaging,...
• API to network functions
• Can be used in closed network of operators, but
  not in open networks
• Well suited for the development of telecom
  applications, but security issues
• Platform with CORBASec possible, but very low
  level of integration (gaps, mismatches, differing
  level of abstraction)
• Need better integration of service platform
  CORBASec
• Therefore

27
Do it yourself CORBA

• We used plain CORBA (MICOSec) to develop secure
  telecom applications
• CORBA with security services provides security
  functionality
• But many low level issues have to be considered
  in application
• We need a secure service platform!
• Stakeholders have different security
  requirements, for example
• Users privacy, data protection
• Operators protection of network integrity
• Service providers protection of their
  applications and data
• Additional legal requirements
• Mutual distrust

28
CCM for telecoms applications

• The CORBA Component Model (CCM) is a runtime
  framework for objects (inspired by EJB)
• A service platform is a special purpose component
  model
• Why not implementing telecom applications based
  on CCM?
• Network API and other telecom specific functions
  can be implemented as components
• But still many issues current state of CCM,
  security

29
Secure CCM

• First experiments with secure CCM
• MICOSec (CORBASec L2)
• MICOCCM (CCM Subset)
• CORBASec does not meet the requirements of CCM
• New CORBASec specification urgently needed
• Upcoming specs very helpful CSIv2, ATLAS, SDMM

30
COACH

• COmponent based open source ArCHitecture for
  distributed telecom applications
• European IST research project
• Main objectives
• Implementation and evaluation of CCM
• Extension of CCM to telecom domain
• Development of a security architecture for CCM
• Possibility to get research students involved!!!

31
COACH Partners

• T-Systems Nova (D, Coordinator)
• Humboldt University (D)
• Intracom (EL)
• Lucent Technologies (NL)
• THALES Group (F)
• LIFL (F)
• ObjectSecurity (UK)
• University Paris 6 (F)
• Fraunhofer FOKUS (D)

32
Object
TM
Security
The Security Policy Company
Ulrich.Lang_at_cl.cam.ac.uk www.cl.cam.ac.uk/ul201
www.micosec.org www.objectsecurity.com
33
SecureParlay

• Parlay is an API based telecom framework, mainly
  implemented with CORBA
• Parlay provides own (weak) security functions in
  conflict with CORBASec, e.g. authentication
• Goal better integration of Parlay and CORBASec
• CORBASec security context and Parlay session
  do not match!
• Our current approach
• Integration of Parlay user management and
  CORBASec privilege management
• CORBASec authorisation token used as Parlay
  service token