Security in CORBA-based electronic commerce systems

Information Security Technical Report, Vol. 3, No. 2 (1998) 64-70

Security in CORBA-based Electronic rce Svstems

By Dieter Gollmann, Microsoft Research Ltd and Ulrich Lang, University of Cambridge Computer Laboratory.

Electronic commerce provides business with new ways of advertising and selling goods, services, and information to large groups of customers in dynamic open electronic commerce environments. In 1997, a total of 10 million PCs in the United States were used

for shopping on the Internet, both for electronic and physical goods and setvices. This article addresses the technologies for realizing electronic commerce applications that go beyond the current state-of-the- art, focussing on the relevance of the CORBA framework for these solutions.

Introduction

Until very recently, electronic commerce only happened within closed groups of participants who could agree on common policies and platforms. For example, Electronic Data Interchange (EDI) was (and still is) used to securely transfer data between a number of branches of an organization or between organizations that have established some sort of contractual relationship. In these early stages, electronic commerce systems only dealt with certain aspects of a complete business transaction. For example, the Secure Electronic Transaction (SET) protocol provides an electronic payment system that facilitates Internet-based credit card purchases. SET does not cover the entire shopping process, and it has even been criticized for being too complex as it tries to accommodate different purchase scenarios.

A more comprehensive concept of electronic commerce as a means of transferring goods

and value over the Internet was established when the first Web-based shops emerged that could be used by clients through their Web browsers. At the time of writing, most electronic commerce systems are Web-based (‘Web shop’) and allow clients to buy goods via their Web browsers and pay for them with their credit cards. However, the limited functionality of Web-based applications makes it difficult to provide a full range of services to the clients.

In the future, the requirements for electronic commerce solutions will go beyond the current state-of-the-art. Future systems will have to meet the requirements of dynamic open environments with multiple autonomous service providers, which have differing policies and use different underlying technologies. Electronic commerce will be a distributed process that involves complex interactions between multiple trading parties. In an open market, there are many independent providers of goods and services, and there may be intermediaries who provide services by combining services supplied by third parties. Also, clients themselves may combine on-demand products or services to realize composite packages. Hence, modern electronic commerce systems must be able to integrate users who mutually distrust each other across heterogeneous participating systems and policy domains.

The Vision: An Open Electronic Marketplace

Imagine a large number of online services, all linked via a common electronic commerce framework. In this vision of an open electronic

62 0167-4048/98/$19.00 0 1998, Elsevier Science Ltd

Security in CORBA-based Electronic Commerce Systems

market, businesses of all kinds will routinely outsource functions such as fulfilment and shipping over the Net to other businesses that specialize in such services. Distributors themselves will go virtual and outsource warehousing and logistics. Numerous industry-specific electronic markets, e.g. real estate, automobile parts, financial services will be formed. For example, companies belonging to the real estate market may get secure working capital through the financial market. Global manufacturing industries such as the automobile industry will integrate their multi-tiered supply chains through the Net. Creative entrepreneurs will set up new virtual businesses, which add value to existing online enterprises or create new kinds of virtual products. Online businesses would gain fundamental leverage by outsourcing, joining markets, and letting others add value to their services. Future electronic commerce applications in an open environment will enable all commerce activities, such as searching and advertising, negotiating, contracting and ordering, distribution and receipt, billing and payment, accounting, and customer services.

The Reality...

The explosive growth of the Internet yields a unique potential for electronic commerce by providing a common communications environment for a large group of customers and providers. Today, there are thousands of consumer-orientated and business-orientated commercial sites on the Net, and the number is rapidly increasing.

From the customer perspective, one of the positive aspects of this large-scale system is that users can choose from a wide range of products and search for the most suitable product. The provider benefits both from the large number of potential customers and from reduced transaction costs.

However, rapid and uncontrolled growth has created various problems, both of organizational and technical nature. Markets are still closed and do often not fully meet the requirements of customers and providers. Today’s electronic commerce systems run on proprietary platforms, and therefore applications cannot interoperate or build on each other. Security and payment systems are still immature and often inappropriate. Only a standardized electronic commerce framework can solve these problems.

Security

The main security problem of future electronic commerce systems is that they have to operate in a dynamic and open, and therefore uncontrolled environment with complex component topologies and trust relationships. Most electronic payment systems used for electronic commerce need to be available off- the-shelf, and have to transparently provide authentication, integrity protection, confidentiality protection, and non- repudiation. In addition, confidentiality and integrity of data should be preserved on the communications link between client and provider, firstly to protect the client’s privacy, and secondly to ensure that the service a client buys cannot be tampered with.

Unfortunately, today’s (Web-based) electronic commerce systems do not meet these requirements, both with respect to functionality and security. The following sections describe how CORBA can be used to solve some of the problems.

The CORBA Vision

The Common Object Request Broker Architecture (CORBA) is a specification that was originally developed in 1995 by the Object Management Group (OMG) (see [2] for details). Its core part is the Object Request Broker (ORB), a software bus which facilitates

Information Security Technical Report, Vol. 3, No. 2 63


- -

,__________________ I I I Server Application L--_---_-__-_____--

--I

I ______. ___.- Figure 1 : CORBA binding and method invocation.

interoperability and integration across different hardware and software platforms. From a software developer’s perspective, the ORB abstracts the inherent complexities of remote method invocations in distributed systems. CORBA can abstract the communications, the distribution of components, platform differences, programming language differences, and it can transparently provide the security functionality required for electronic commerce. In addition, CORBA specifies a number of CORBA services, which focus on specific aspects of a distributed system, such as naming service, trader service, time service, or security service.

Figure 2 illustrates in a simplified way how CORBA works: in the initial binding phase, the client application connects to an Activation Component or Naming Service via the ORB library (0, O), which then in turn looks up the target object reference in the Implementation Repository (0) and launches

the target object if it is not already running (a,@). The target object reference is then passed back to the client-side ORB library (0).

Whenever the client invokes target-side methods (0) through the object code stubs (a), the ORB library transparently connects to the target ORB library (@) which then mediates the request to the target object through the target code skeleton (@, 11) . The reply is sent back along the chain qljto 8.

CORBA’s flexible method invocation system allows clients to dynamically bind to providers, thereby facilitating flexible and dynamic composition of services, coordination of their interactions, interoperability, and maintenance of state during shopping sessions.

Also, CORBA enables electronic commerce systems to support the notion of complex product or service packages consisting of items from multiple providers. For example, a

64 Information Security Technical Report, Vol. 3, No. 2


travel agent can provide a travel package that consists of flight tickets, hotel reservations, car rental, guided tours etc.

CORBA Reality...

Unfortunately, in practice most CORBA implementations do not fully conform to the specification, and many services are not yet available. This is particularly unfortunate for the security service, which is absolutely critical for any CORBA-based electronic commerce system. Also, CORBA implementations from different vendors do not always fully inter-operate, especially when other CORBA services are in use. Off- the-shelf CORBA security services do only partially or not at all comply with the specification which makes interoperability impossible.

The CORBA Security Vision

The CORBA security specification includes a security model and interfaces and facilities for applications, administrators, and implementers. The Common Security Interoperability part of the specification defines common security mechanisms, which enable secure interoperability.

The CORBA security model for distributed object systems is based on the security properties shown in Table 1.

The CORBA security service specification defines various object interfaces, which provide the following security functionality to enforce the security properties mentioned above (see [l] for more details) (see Table 2).

The Reality for CORBA Security

In practice, particularly in an electronic commerce environment, a security service of

Confidentiality

Integrity

Accountability

i Table 1: Security Properties.

the size and complexity of the CORBA security service specification will inevitably be too heavyweight and complex. Individual electronic commerce systems may have specific security requirements that differ from the CORBA systems originally envisioned by the OMG.

It may be worth pointing out at this stage that the CORBA security service was designed around the ideas of Distributed Computing Environment (DCE) and Kerberos, which both typically work in a campus-like closed environment where the underlying platforms and policies can be controlled (i.e. the DCE security infrastructure could be installed and managed). In this kind of environment, the primary security requirement was to protect the system from unauthorized usage and modification.

Electronic Commerce Security Requirements

In today’s electronic commerce systems, some of the security requirements differ dramatically from DCE-like environments. In DCE, the clients had to trust the servers and the system, whereas the servers were protected from unauthorized clients. In



Security Administration: Policies and Domains

Authentication

Security context establishment

Access control

Communications protection (integrity, confidentiality)

Security audit

Non-repudiation

Able 2: Securityfimctionality of the CORBA Security Service specification.

electronic commerce environments parties need protection from malicious insiders. Hence, the system has to protect the clients from malicious servers and from other clients, and the servers from unauthorized clients. This concept of mutually distrusting parties is not inherent to DCE.

In traditional environments, responsibility for a system was assigned through ownership, and the trust boundaries were defined by these ownership domains (see Figuve 2). In open systems, trust boundaries, ownership, and responsibility domains may differ, which causes various problems. For example, a merchant may be responsible for the security of the shopping process without being able to control the client system (see Figure 3). In addition, the shop owner often cannot dictate the platform (e.g. CORBA product, Java version, operating system) or security policy

(e.g. operating system security configuration) on which her client software runs. On the other hand, a client may be responsible for a piece of software which he does not understand, which is supposed to work transparently in the background, and which may be supplied by a merchant who could become involved in a dispute with the client. This poses the question how the trusted part of the system is distributed between the merchant side and the client side.

Contractual relationships between business partners should specify the allocation of risks, liabilities, and rules for dispute resolution. With electronic commerce, the difficulties in establishing such relationships are compounded by the fact that we now have to deal with hardware and software that potentially comes from many untrusted sources and runs on insecure underlying



cases, no big security infrastructure a la DCE can be installed on the client machine. Also, the client-side security policy may not allow shop software to be installed permanently on the client machine.

In order to make open electronic commerce happen in practice, secure electronic commerce products need to be available off- the-shelf,-and banks need to cover for potential security breaches of electronic payment systems.

Figure 2: Traditional matching trust and ownership boundaries.

operating systems. This software can fail accidentally or behave maliciously, and is too complex to be the responsibility of most end users.

In line with the credit card philosophy, banks and merchants will probably cover most of the risk in the end because they want customers to use the system.

On a more technical level, there is a requirement for strong integrity and confidentiality protection of transactions and payments, and at the same time ensuring anonymity of electronic cash. There may also be a requirement for lightweight client applications that can be downloaded in the browser at the time of shopping. In these

CORBA and Electronic Commerce Security

The CORBA security service specification provides message level integrity and the authentication/authorization of principals, which are both critical for electronic commerce applications. However, the OMG’s Electronic Commerce Domain Task Force (OMG-ECDTF) identified several additional security requirements for electronic commerce systems [3]. The following requirements are not met by the CORBA specification, either because they have not been specified yet or because they are beyond of what can be achieved within CORBA:

?? Transaction Auditing: The CORBA Security specification provides generation of audit

Owned by Owned by customer merchant

Owned by customer

Owned by merchant

boundary Network (untrusted) boundary

Network (untrusted )

Figure 3: Examples of differing trust and ownership boundaries for open systems.

information Security Technical Report, Vol. 3, No. 2 67


data, but not of the required data and granularity.

Role-Based Access Control: Electronic commerce assumes role-based access control as a predominant form although individual access control may be required at finer granularity or sensitive commerce transactions. CORBA Security does not provide role-based access control. /

Non-repudiation: CORBA provides for evidence generation, but no facilities for evidence storage, retrieval, and verification of evidence are provided. The full non- repudiation functionality required for electronic commerce includes evidence generation, verification, storage, retrieval, and a delivery authority. The service should be able to provide non-repudiation of creation, origin, receipt, submission, approval, delivery, and action.

Integrity: Functionality should be provided that allows to convert data into integrity protected data, convert integrity protected data back into the original data, and to check loss of integrity. In addition, many other integrity issues need to be addressed. For example, there needs to be some mechanisms to prevent unauthorized modifications of object executables by malicious software such as computer viruses. Apart from message level integrity, CORBA does not provide any integrity functionality on the level required for electronic commerce systems.

Delegation: CORBA provides ‘impersonation delegation’ which facilitates individual accountability. However, electronic commerce requires additional delegation options, such as simple delegation, composite delegation, combined privileges delegation (which does not allow to trace the privileges back

to certain intermediate nodes), and traced delegation (which provides a trace of delegates in the chain). Currently, CORBA does not mandate the provision of those delegation modes.

Delegation must also play a role in security auditing. It supports tracing a complex chain of object requests back to the original user.

Security Audit Repository Management: The audit service can be used to ensure that all users are accountable for the security- relevant events they initiate, and that an audit trail of security-relevant events is established, maintained, and protected. In addition, alarm facilities must be provided, and collection, profiling, filtering, analysis, and query of audit data must be possible. CORBA does currently not provide any audit management functionality.

Security Management: Electronic commerce security management should be concerned with the following three categories: security of management functions, security service management, and security mechanism management. Currently, CORBA does not provide any security management facilities.

CORBA-based Electronic Commerce in Practice

Using CORBA as the underlying architecture for electronic commerce systems has many advantages, some of which will be summarized in this section.

Two of the main requirements of open electronic commerce systems are interoperability and integration. All client and merchant applications should be able to interoperate within a flexible, dynamic and open framework, and across different



platforms, programming languages and commerce topologies. CORBA can abstract from these complexities of the open electronic commerce environment. Also, CORBA facilitates the interaction between electronic commerce systems and other systems, e.g. stock management system, accounting system, marketing system, and enables easy integration of legacy applications, for example, an old stock database system.

From a software developer’s point of view, CORBA can make life a lot easier, especially if several different shop configurations are to be deployed. CORBA abstracts the network and dynamic remote shop invocations, which allows application developers to focus on the actual applications rather than on the inner workings of the underlying architecture. Application developers can reuse parts of existing systems, for example the security system, for new applications. Also, CORBA’s flexible architecture gives developers the ability to implement a subset of a full mall to meet specific business requirements, and provides a solid basis for further enhancements to the system and for easy upgrade of parts of the mall software. In the future, individual CORBA-based off-the-shelf mall components will be available which can be purchased and easily plugged into existing malls in order to enhance or upgrade the shop system.

In order to make dynamic interoperability of shop components work, a well-defined set of standardized services needs to be available within the electronic commerce environment. For example, the semantics used to describe objects such as goods, services, contracts, invoices, or payments, need to be universally defined. As a consequence, the OMG and CommerceNet have jointly defined the requirements for a set of electronic commerce services in [3], namely semantic data facilities, selection/negotiation facilities

and payment services. The Semantic Data Facility provides support for the exchange of semantic information between electronic market participants. Negotiation Services provide support for the mutual agreement on the selection and configuration of service or facility across a group of participants engaging in a commerce transaction, and Electronic Payment Facilities are concerned with payments protocol invocation.

In practice, CORBA is still often considered an immature technology, especially with respect to the missing implementations for many of the CORBA services such as the security service. In addition to problems associated with immature ORB implementations, software developers are often not fully trained to write CORBA-based components. Development of CORBA-based applications hardly differs from normal software development for local applications and does therefore not really pose a problem, but for example implementing a security service which transparently provides security on the ORB level requires specialist knowledge.

Currently, the mere publicity value of CORBA-based electronic commerce systems is sufficient to make the development pay off for some companies. For example, banks deploying CORBA-based personal banking or stock trading systems may benefit from the reputation as a provider of leading-edge technology services to customers.

Conclusion

Many of CORBA’s core concepts are useful for electronic commerce systems, such as interoperability and integration, flexibility

of platforms/programming languages/ security mechanisms etc., abstraction from the underlying component topologies



and the network, transparency of security functionality, automatic security enforcement.

However, the CORBA implementations currently available are rather immature and do not (yet) cover the full CORBA functionality originally specified. For example, no full implementation of the security service is available off-the-shelf at the moment. This leaves the job of implementing custom security services either to the application programmers or to specialist contractors, who need to have expert knowledge of security and of the inner workings of the particular CORBA product used.

The fundamental concepts described in this article will be core requirements for any electronic commerce middle-ware even if CORBA does not take off as expected and is replaced by something else in the future (e.g. Java RMI or COM+). If CORBA becomes the new Internet standard for electronic commerce, as many people predict, businesses

will benefit the more the sooner they can provide CORBA-based malls and services. Therefore it is definitely worth for software developers and architects to familiarize themselves with the CORBA concepts now in order to have a competitive advantage when distributed object middle-ware gets widely used.

Acknowledgement

Ulrich Lang was supported by a studentship from DERA.

References

[I] Belinda Fairthorne, ICL Ltd, Security in CORBA Distributed Object Systems, Information Security Technical Report, Vol. 1, No. 2 (1996), pp. 56-63.

[2] OMG, CORBA Specification, www.omg.org.

[3] OMG/COMMERCENET, joint Electronic Commerce Whitepaper, July 1997.


Documents

Security in CORBA-based electronic commerce systems