Middleware Security Research Overview and Planned Projects Ulrich

Middleware Security Research Overview and Planned Projects Ulrich Lang ulrich. lang@cl. cam. ac. uk www. cl. cam. ac. uk/~ul 201

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

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 Middleware Security • Also need protection, in particular: • Authentication of application entities • Access control to target application entities based on the identity of the caller

General Problem Definition Middleware Security • 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?

Related Work • Access control can be done at various points in the communications path: Middleware Security • Network [ J. Rushby and B. Randell. A distributed secure system. IEEE Computer, 1983] • Operating system [DIA. Compartmented Mode Workstation Evaluation Criteria, 1991] • Middleware (& VM) [Lang, Gollmann, Schreiner: Verifiable Identifiers in Middleware Security, ACSAC 01] • Application • Explicit • Implicit • Domain Boundary [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, Object. Security, 2000 ]

Defining Middleware Security • 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

Middleware Architecture Middleware Security • Layered architecture • Interfaces at layer boundaries Interoperability Interface Client Application Target Object Portability Interface Middleware Underlying Technology Middleware Flexibility Interface Underlying Technology

Middleware Invocation Client Application 2 1 3 Middleware Security Target Servant Middleware 7 Middleware 4 6 OS/Network 5

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

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 Middleware Security • 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)

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 Middleware Security • 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

Middleware Security Policy • Communications identities: granularity problem! • represent the reference monitor on the middleware • not the individual application entities (clients/targets) Middleware Security • 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

Descriptors • Need additional descriptors to represent individual clients/targets above the middleware • What should exactly be described? Middleware Security • 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

Existing Descriptor Options • Client: • No representation on the middleware layer • Have to use cryptographic identities from the underlying technology layer • Problems: granularity, flexibility, abstraction Middleware Security • 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

Resource Descriptor Mapping • What should exactly be described? 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. Middleware Security • Mapping configuration:

Resource Descriptor Mapping • Invocation Mapping Target Client Instance Object Reference Target Instance Middleware Security 1 Reference Monitor 3 Client-side Middleware crypto identities Target-side Middleware 2 crypto identities 4 Mapping Table Target instance identifier Resource descriptor

MICOSec Proof-of-Concept • CORBA • “Common Object Request Broker Architecture” Middleware Security • 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

MICOSec Proof-of-Concept Middleware Security • CORBASec • Security features: authentication, message protection, access control, audit • Interfaces • Security-enhanced protocols • Mechanism-independent, but specifies how to integrate Kerberosv 5, SESAME, SPKM, SSL • Integrates with CORBA through interceptors

MICOSec Proof-of-Concept • MICOSec (http: //www. micosec. org) Middleware Security • Our Open. Source CORBASec Implementation • Includes resource descriptor mapping • Uses only Open. Source products: • MICO ORB • Open. SSL library • Postgre. SQL database • Full MICOSec was ported to a Compaq i. PAQ 3630 Pocket. PC (under Linux) • Current & future development • Almost finished: CSIv 2 • Next: Authorisation Service (ATLAS) based PMI • CORBA Component Model (CCM) (with security!)

Middleware Security 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 CSIv 2 level 0

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

Conclusion Middleware Security • 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)

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

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

The Challenge Middleware Security • 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 3 rd 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

Telecom Service Platforms • Telecom service platforms are already available (TINA, Parlay) Middleware Security • 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…

Middleware Security 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

Middleware Security 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

Secure CCM • First experiments with secure CCM Middleware Security • MICOSec (CORBASec L 2) • MICOCCM (CCM Subset) • CORBASec does not meet the requirements of CCM • New CORBASec specification urgently needed • Upcoming specs very helpful: CSIv 2, ATLAS, SDMM

COACH Middleware Security • “COmponent based open source Ar. CHitecture 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!!!

Middleware Security COACH Partners • • • T-Systems Nova (D, Coordinator) Humboldt University (D) Intracom (EL) Lucent Technologies (NL) THALES Group (F) LIFL (F) Object. Security (UK) University Paris 6 (F) Fraunhofer FOKUS (D)

Object Security Middleware Security TM Ulrich. Lang@cl. cam. ac. uk www. cl. cam. ac. uk/~ul 201 www. micosec. org www. objectsecurity. com

Secure. Parlay Middleware Security • 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