View
223
Download
2
Tags:
Embed Size (px)
Citation preview
Mid
dle
ware
Secu
rity
Middleware SecurityResearch Overview
and
Planned Projects
Ulrich Lang
[email protected]/~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
[email protected]/~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