Mid

dle

ware

Secu

rity

Middleware SecurityResearch Overview

and

Planned Projects

Ulrich Lang

ulrich.lang@cl.cam.ac.ukwww.cl.cam.ac.uk/~ul201

ObjectSecurity

TM

Mid

dle

ware

Secu

rity

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

ObjectSecurity

TM

Mid

dle

ware

Secu

rity

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

Mid

dle

ware

Secu

rity

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?

Mid

dle

ware

Secu

rity

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]

[I. Welch and R. Stroud, Kava - A Reflective Java based on Bytecode Rewriting, 2001]

[T. Riechmann, F. Hauk, Meta Objects

for Access Control, 1997]

[OMG, Resource Access Decision Facility Specification, 2001]

[Schreiner, Lang. CORBA firewalls – Introduction and Analysis, ObjectSecurity, 2000 ]

[Lang, Gollmann, Schreiner: VerifiableIdentifiers in Middleware Security, ACSAC01]

Mid

dle

ware

Secu

rity

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

Mid

dle

ware

Secu

rity

Middleware Architecture

• Layered architecture• Interfaces at layer boundaries

Middleware

Underlying Technology

ClientApplication

Middleware

Underlying Technology

TargetObject

Portability Interface

Flexibility Interface

InteroperabilityInterface

Mid

dle

ware

Secu

rity

Middleware Invocation

3

5

OS/Network OS/Network

TargetServant

ClientApplication

Middleware Middleware

4 6

71

2

Mid

dle

ware

Secu

rity

Middleware Security

• Add security features:• Authentication (principal, peer)• Message Protection (integrity, confidentiality)• Access Control• Audit

• Fit into the layered middleware architecture• Preserve design requirements …

Mid

dle

ware

Secu

rity

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

Middleware

Underlying Technology

ClientApplication

Middleware

Underlying Technology

TargetObject

Crypto Mechanism: Authentication, Message protection, Verifiable crypto identities (keys)

Access Control,Audit, Policies

Mid

dle

ware

Secu

rity

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

Mid

dle

ware

Secu

rity

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

C2

IC IT

Middleware

PT

Middleware

PC

C3C1 T2 T3T1C2

IC IT

Middleware

PT

Middleware

PC

C3C1 T2 T3T1

Mid

dle

ware

Secu

rity

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

Mid

dle

ware

Secu

rity

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

Mid

dle

ware

Secu

rity

Resource Descriptor Mapping

• What should exactly be described?

• Mapping configuration:

Target-sideMiddleware

TargetInstance

trigger instantiation,provide resource descriptor

Mapping Table

Target instance identifier

Resourcedescriptor

Object Reference

12

3

4

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.

Mid

dle

ware

Secu

rity

Resource Descriptor Mapping

• Invocation Mapping

Target-sideMiddleware

TargetInstance

Mapping Table

Target instance identifier

Resourcedescriptor

ObjectReference

1

2

4

Client-sideMiddleware

TargetInstanceClient

3

cryptoidentities

ReferenceMonitor

cryptoidentities

Mid

dle

ware

Secu

rity

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

Mid

dle

ware

Secu

rity

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

Mid

dle

ware

Secu

rity

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!)

Mid

dle

ware

Secu

rity

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

Mid

dle

ware

Secu

rity

Book on CORBASec

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

Mid

dle

ware

Secu

rity

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)

Mid

dle

ware

Secu

rity

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

ObjectSecurity

TM

Mid

dle

ware

Secu

rity

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

Mid

dle

ware

Secu

rity

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

Mid

dle

ware

Secu

rity

Telecom Service Platforms

• Telecom service platforms are already available (TINA, Parlay)• Runtime framework for applications:

Lifecycle, 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…

Mid

dle

ware

Secu

rity

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

Mid

dle

ware

Secu

rity

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

Mid

dle

ware

Secu

rity

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

Mid

dle

ware

Secu

rity

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!!!

Mid

dle

ware

Secu

rityCOACH 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)

Mid

dle

ware

Secu

rity

Ulrich.Lang@cl.cam.ac.ukwww.cl.cam.ac.uk/~ul201

www.micosec.org

www.objectsecurity.com

ObjectSecurity

TM

ObjectSecurity

TM

Mid

dle

ware

Secu

rity

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