Securing The Electronic Market: The KEYSTONE Public Key Infrastructure Architecture

1. Introduction

Use of electronic messaging is becoming more widespread as information and communication technology becomes more effective and cheaper and telecommunications become more advanced. However, the increased user interconnectivity, the growth of electronic commerce and the reliance upon electronic communications means that more information is being carried electronically. Sensitive information such as contracts, money transactions and personal details become vulnerable to attacks such as eavesdropping, non-authorized modification and masquerade.

Public Key Infrastructure (usage of public and private keys for data encryption and for digitally signing of messages) can play an integral role in countering these attacks by providing end-to-end security of information in terms of confidentiality, integrity, availability and non-repudiation security services. The strength of these security services depend upon the security of the underlying keys, whether they are used for data encryption or for message signing. In any case, security features require first of all the protection of the confidentiality of the private keys and the integrity of the public keys in the delivery and storage processes.

In a small community, the integrity of the public keys may be ensured by manual delivery of the keys.

However, in an international electronic messaging environment, the manual delivery of keys between users is neither practical nor adequate. Automatic key management by a trusted agent is necessary and this must be performed by a Trusted Third Party (TTP), in order to facilitate the use of public key cryptography and digital signing.

Public Key Infrastructure (PKI) is an essential security component of electronic trusted services. The development of robust and scaleable PKI is an important task, which has been a field of active research for a number of years. Several standards and ad-hoc solutions have been proposed [1]-[15]; however, the work is still far from complete.

The aim of this paper is to present the unified, abstract KEYSTONE Public Key Infrastructure. This architecture consists of a reference model, a functional architecture specification, and a set of technologies that can be used for implementing the functional units, along with all relevant standards. It was derived within the course of the KEYSTONE project, which was funded by the European Commission under the Electronic Trust Services II Programme.The proposed PKI architecture guarantees openness, scalability, flexibility, extensibility, integration with existing TTP and information infrastructure, transparency and, above all, security.

The paper is structured as follows: In section 2, the list of services that a PKI offers are presented.These form the ground upon which the rest of the work is based. In section 3, the KEYSTONE Reference Model is presented. Section 4 describes the functional architecture and the proposed technology profiles that can be used in order to implement the functional units. Section 5 describes the KEYSTONE integrated Public Key Infrastructure Architecture in terms of functional units, accompanied with the relevant candidate technologies, and the relationships between these functional units. Finally, section 6 summarizes our conclusions.

2. PKI Ser vices and Functions

Previous attempts [16] to define a set of services that a PKI should be offering were not user-needs-oriented. User requirements from a PKI have been recorded in several references [17]-[25]. Each one of these works recorded user requirements for their own application domain. However, a common ground can be and has been found [26, 27]. This ‘minimal set’ of user requirements includes authentication of users, integrity of messages, privacy and confidentiality of messages, non-repudiation of message origin and destination, availability of services, ease of use. In addition to this minimal set, issues like anonymity of participants, time-stamping, uniqueness of documents, interoperability between different elements, protection from abuse of any participant by another, legal issues have been identified as important.

A comprehensive list of PKI services that satisfy the above requirements follows [27]. The functions required to perform each of these services can subsequently be defined.

The specified PKI services are as follows:

1. Registration. In order for a user to join the PKI environments s/he must register with a certifying TTP belonging to the PKI. The primary goal of this service is to establish the reliable uniquebinding between a user and her/his public keyFunctions supporting this service include: Initial request submission, Registration form’s format validity checks on behalf of the TTP, end entity authentication and identification, and anonymity assurance.

2. Digital Signatures. In order to satisfy the message authentication, message integrity and non-repudiation of origin user requirements, the PKI should offer digital signature services. Functions supporting this service include message hash generation and message hash encryption/ decryption.

3. Encryption. Encryption is a basic service providing the cryptographic functions for protection of message confidentiality in a computer network. Functions supporting this service include encryption and decryption of the message.

4. Time-stamping. Time-stamping is described as the process of attaching data and time to a document in order to prove that it existed at a particular moment of time. Functions supporting this service include: acceptance of a request for a time-stamp, retrieval of the time/date data for the time-stamp, appendage of time-stamps to a message and submission to the requesting entity, verification of the validity of the time-stamp certificate, selection and distribution to the public of the set of hash functions for producing message digests, selection of a digital signature scheme for signing time-stamp certificates, maintenance of a database of time-stamp certificates, generation and delivery of error messages to the requesting entity, maintenance of a log of time-stamping authority (TSA) activity, hav-ing the TSA log time-stamped, provision of secure communiction channels, maintenance of procedural security controls, distribution of information to the public.

5. Non-repudiation. Non-repudiation involves the generation, accumulation, retrieval, and interpretation of evidence that a particular party processed a particular data item.The evidence must be capable of convincing an independent third party, potentially at a much later time, as to the validity of a claim. Functions supporting this service include initialization, revocation and dispute resolution and notary.

6. Key Management. Key management is a principal service within a PKI architecture. This service deals primarily with the handling of cryptographic keys in a proper, efficient, scaleable and secure way. It includes: key generation, random number generation, key personalization, distribution of keys, key storage, key retrieval, key recovery, backup and restore, key update, key compromise related functions, validation of requests for key accessing functions, determination of the rights of the personnel on key management functions.

7. Certificate Management. A digital certificate is an electronic token ensuring the binding between an entity and its public key. The functions supporting this service include generation, distribution, storage, retrieval, and revocation of digital certificates.
8. Information Repository. This service maintains the collection of data critical for the operation of the TTP system. It states the general means and fashion for storing, archiving and maintaining several types of data ranging from organization’s legal requirements, to system recovery needs. The functions supporting this service include determination of the items to be archived, determination of the retention period, authorization, authentication, update of the archive, retrieval of information, retrieval of authorization and consignment details of archived documents, distribution of information, deletion.

9. Directory Services. In order to interact, a member of a PKI must have access to information about other PKI members.This is achieved by the use of Directory Services which are supported by the following functions: update with new certificates, update with revoked certificates, distribution, replication, caching, searching, retrieval (for certification purposes), retrieval (for cross-certification purposes), returning information.

10.Camouflaging communications. Camouflaging communications not only provides data confidentiality, but also hides the very fact of communication. This is achieved by adding dummy messages into the data stream enabling TTPs and users to hide real data transfers, both in terms of their occurrence and frequency. Functions supporting this service are responsible for camouflaging online as well off-line communications.

11.Authorization. The PKI should enable requesting entities to delegate access rights at will to other PKI entities.This means that a PKI user who possesses a resource may grant the right to another PKI user to access this resource. TTPs should ensure the granting of rights, including the ability to access specific information or resources. Supporting functions include authentication, group definition, rights update, group update, enrolment of a user into a group, resolving of rights, determination of administrative authorities.

12.Audit. In order to ensure that certain operational, procedural, legal, qualitative and several other requirements are complied with, so that trust is enhanced, an auditing service is required. The functions supporting this service fall into two categories: Initial preparatory phase functions and main operation of the audit plan phase functions.

13.Quality assurance and trust enhancement services. It is expected that the potential users of PKI services would require products and services of a given quality to be delivered or be available by a given time and to be priced so that best value for money is achieved. In order to achieve this level of quality, PKI services must be quality assured. Functions supporting this service include organization operations manual specification, organization operations maintenance and improvement.

14.Customer oriented services.This group of PKI services includes services which directly involve users or that require some contact, or some kind of dealing or bargaining with the end user. Examples of such services are legal aspects and payment negotiations between a user and a TTP.This group of services is implemented by the following functions: liability and insurability, underwriting, accounting management, ordinary operations assistance and support provision.

15.TTP to TTP interoperability. It is unlikely that in a large scale PKI all users will be connected to a unique TTP. Interoperability services are concerned with the issues necessary for establishing a network of TTPs, possibly operating by different companies with different policies and different domain specialization. Functions supporting this service include: accepting a request, validating a request, return of the validation result, finding the certification path, validation of the certification path, sending cross-certification requests, accepting the certification result, retrieval of information from other domains, response to other domains’ requests, translation, other operational functions.

Detailed descriptions for all the aforementioned functions can be found in [27].

3.KEYSTONE Reference Model

The specified PKI services and functions were used to create a high-level model of ETS and associated PKI. This model is called the ‘KEYSTONE Reference model’ and is described in terms of actors and their roles.

The KEYSTONE Reference model is depicted in Figure 1. Two types of organizational entities (actors) are identified: TTPs and PKI users. Trust services are offered by the TTPs to the users at the TTP-User interface. A user uses trust services of one TTP in its domain.TTPs in different domains cooperate, in order to meet their users’ needs. The interaction between TTPs is performed at the TTP-TTP interface.Within each Security Domain or Business Sector one or many users are depicted, and within each TTP one or more roles are depicted. Roles are specific individual tasks performed by a TTP, in order to provide security services to meet specific user requirements and therefore implement trust services.

The specified TTP roles are as follows:

1. The time-stamping role.This role is responsible for fulfilling the PKI community requirement for valid transactions and unique documents sets. The time-stamping role can be seen as a transaction notary, which commits the fact of existence and correctness of a document and a transaction respectively, by producing, storing and verifying time-stamped documents. It is highly possible that the role is performed by an independent and trustful entity providing indisputable time-stamps.

2. Management and trust enhancement role.This role could be simply considered as the administrative department of a trust-based organizational system. The basic duties of this role include establishment of a TTP organizational structure; establishment, operation and management of quality assurance and audit plans; establishment and enforcement of organization’s policies, etc.

3. Legal issues management role. This role is responsible for studying the existing legal context of the

Figure 1: KEYSTONE Reference Model

PKI operation, for contributing to the emerging legal frameworks and for monitoring the PKI operation, in order to handle legal issues or possible problems in either a PKI«User or a TTP«TTP relation.

1. Key management role. This role is related to the key management functions supported by the TTP. The role has a number of almost independent duties such as key generation, key certification, key distribution, key revocation, key escrow/recovery, key translation, key storage and backup.

2. Customer support role.This role is involved in the provision of services which are addressed directly to the end-users who may need contact, support (technical, informational, financial etc.) or some kind of dealing or bargaining. Examples of the duties of this role are client charging and billing, dispute handling and resolution, and 24-hrs helpdesk and hotline.
3. Accounting role. Like every organization, the TTP is obliged to have a role involved in the internal accounting, according to certain rules applied by governments and local tax authorities. The role’s duties are to ensure that imposed accounting controls are strictly followed, to propose a proper way of asset management, to ensure that only valid transactions are processed and recorded in the accounting records, etc.

4. Registration role. This role is responsible for actions performed when a new entity subscribes for TTP services. The activities involved with the every day operation of this role include evaluation

Roles Services	Time-stamping role	Management & Trust enhancement role	Legal issues management role	Key management role	Customer support role	Accounting role	Registration role	Certification role
Registration			+				+
Digital Signatures	+		+	+				+
Encryption		+	+	+				+
Time-stamping	+		+
Non-repudiation	+		+
Key management		+	+	+				+
Certificate management			+					+
Information Repository		+	+					+
Directory Services			+	+				+
Camouflaging communications		+	+	+
Authorisation		+	+				+
Audit		+	+
Quality Assurance & Trust enhancement services		+	+			+
Customer-Oriented Services			+		+	+	+
TTP to TTP interoperability			+	+			+	+

Table 1: Relationship between TTP services and roles

of registration forms and supporting documents, authentication and identification of candidate entities, user anonymity assurance, notification of candidate entities about evaluation results, etc.

8. Certification role. This role forms the heart of each TTP. The ultimate goal of this role is to effectively manage the certificates generated and revoked by the TTP. Its duties involve certificate generation, certificate storage and retrieval, maintenance of certificate revocation list, storage and retrieval of certificate revocation list.

The relation between the roles and the PKI services is summarized in Table 1.

4.KEYSTONEFunctional Architecture

The KEYSTONE Functional Architecture describes the TTP information system at the level of functional units interacting across clearly defined interfaces. The list of functional units is presented along with the descriptions of individual units, their interfaces, and the overall picture of information processing in the TTP information system.

4.1. Functional Architecture Elements

The Functional Architecture is made up of a number of functional units, each of which performs a specific task within the TTP.The functional unit definition specifies clearly the functionality provided, without being tied to any particular technology.The functional units provide services to one another by means of abstract primitives, i.e. operations that they carry out for one another. Each functional unit exports a number of abstract primitives to the others, and imports some abstract primitives from the others.

In order to simplify the management of the functional units, all importing and exporting of abstract primitives is from and to the kernel (see Figure 2). The use of a central kernel allows the easy addition of new functional units without any changes being required to the others, and thus facilitates the provision of new services by the TTP. By forbidding any exchange of abstract primitives except via the kernel, the Functional Architecture divorces each functional unit from the internal details of the other. This makes the TTPs

Figure 2: Kernel as a bus for abstract primitives Figure 3:TTP and its users

easier to develop and maintain, and also facilitates distribution of TTP functionality, if required. Such an architecture is well suited to implementation using an object management technology such as CORBA [28, 29].

Since the functional unit is not tied to any particular technology, any technology that provides the functions defined for the functional unit (and thus the abstract primitives that it exports) may be used. In the event of a new technology appearing, such as a new encryption algorithm or a message digest technique, this may be added to the TTP without any changes to any functional unit other than the one concerned. Thus, the functional unit acts as a gateway between a particular technology and a set of functions, which are required by the TTP.

4.2. TTP and its users

In order to design the KEYSTONE Functional Architecture, the relationship between the TTP information system and its users has been studied. This relationship is schematically depicted in Figure 3.

Each TTP information system deals with three different kinds of external entities: TTP personnel, TTP customer, other TTPs.

There are two fundamental types of interaction:

• Service provision: takes place between a TTP and the TTP customers or between two TTPs. It is an interaction where the TTP offers the requested service to a TTP customer or to another TTP for a certain reward.

• Management operation: takes place between a TTP and the TTP personnel. Initiated by the TTP personnel, a management operation modifies a certain aspect of TTP behaviour.

• Service provision or management operation is initiated by a service request or a management operation request respectively; these are issued by external entities. The purpose of a service request is similar to a paper based order form. It facilitates service provision and has to carry information present in usual order forms:
• Service description.

• Service delivery method description.

• Payment method description.

• Invoice and receipt delivery method description.

• Date and time.

• Requester’s identification and digital signature.

The format of the service request must be standardized to facilitate interoperability. The rules must also be defined to convert service requests from other service requests formats into the KEYSTONE service request format. The rest of the commands is given to the TTP information system in the form of management operation requests. Because of high security requirements, the originator of a management operation request must be authenticated and his/her rights to initiate the requested operation must be strictly controlled.

4.3. Functional Architecture Overview

From the information processing point of view, the KEYSTONE TTP functions naturally fall into six groups:

1. Managerial functions — all decision making by TTP personnel (e.g. application form validation, operations manual specification, etc.).

2. Management access — all technical means providing TTP personnel with controlled access to the TTP configuration (processing of management operation requests).

3. Customer access — all technical means providing TTP customers and other TTPs with controlled access to the trusted services (processing of service requests).

4. Trusted services — all technical functions implementing trusted services (e.g. certification path validation, time stamp generation, etc.).

5. Localized supporting services — technical functions locally implementing basic mechanisms required by the rest of the TTP (e.g. encryption, archiving, database management, logging, etc.).

6. Infrastructure supporting services — technical functions providing access to distributed network services essential for TTP functioning. (e.g. directory service access, access to Visa/MasterCard Secure Electronic Transaction infrastructure, etc.).

The interrelations between these functional groups while processing user requests is schematically depicted in Figure 4.

The detailed mapping of the specified functions on the functional unit groups can be found in [27].

4.4. Analysis of Functional Units

Service requests are first processed by the customer access functions that perform customer authentication, customer access rights control, and payment. Following this, the requested service is performed by the appropriate functional unit. Similarly, management operation requests are first processed by the management access functions that perform request originator authentication and access rights control. Following this, the requested management operation is performed by the

Figure 4: Functional groups and their interrelation.

corresponding functional unit. Supporting services, such as cryptographic computations, database management, and logging can be used in every step of the user request processing.

The KEYSTONE Functional Architecture splits the functional groups of Figure 4 into interrelated functional units, and specifies interfaces between them. The logical view of the KEYSTONE Functional Architecture (the kernel is not shown) is presented in Figure 5.

The Customer Access group is divided into the Secure Customer Access, Customer Access Rights Control, Payment, and Customers’ Accounts functional units.

• The Secure Customer Access functional unit is responsible for establishing the secure communication between the TTP and the TTP customers over an insecure network. It provides service request authentication, data exchange integrity and confidentiality.

• The Customer Access Rights Control functional unit verifies that the customer has the right to use the requested type of service.The decision is made on the basis of the access control information stored in the customer’s account.

• The Payment functional unit is responsible for checking whether the customer has to pay for the requested service or not, and, if payment is required, for charging the customer’s

account or for initiating an electronic payment transaction.

• The Customers’ Accounts functional unit maintains the database of customers’ accounts. A customer’s account holds the entire information about the customer: identification information, access rights, payment details, etc.

The service request is sequentially processed by the Secure Customer Access, Customer Access Rights Control, and Payment functional units. Following this, the request is dispatched by the kernel to the appropriate functional unit. This division of service request processing into three steps helps to build the TTP using specialized packages, and creates the opportunity for service request pipelining.

The Management Access group is divided into three functional units: Secure Management Access, Management Access Rights Control, and Management Accounts.

Figure 5: KEYSTONE Functional Architecture (the Kernel is not shown).

• The Secure Management Access functional unit is responsible for establishing the secure communication between the TTP and the TTP personnel over an insecure network. It provides management operation request authentication, data exchange integrity and confidentiality.

• The Management Access Rights Control functional unit verifies that the particular member of TTP personnel has the right to initiate the requested management operation. The decision is made on the basis of the access control information stored in her/his management account.

• The Management accounts functional unit maintains the database that holds information about the members of the TTP personnel necessary to allow them to perform their managerial functions. Each record stores identification information, access rights, etc.

• The Trusted Services functional group is divided into five functional units, each of which implements a particular type of trusted service:
• The Certificate management functional unit supports the certificate management service. It performs certificate generation, certificate distribution, certificate storage and retrieval, and certificate revocation.

• The Key management functional unit supports the key management service. It performs functions such as key generation, key personalization, distribution of keys, key storage, retrieval, recovery, etc.

• The Non-repudiation functional unit supports the non-repudiation service. It performs functions such as generation of records about events, storage of these records, and presenting these records for dispute resolution, when required.

• The Time-stamping functional unit supports the time-stamping service. It performs retrieval of the time/date data for the time-stamp, appendage of time-stamps to a message, verification of the validity of the time-stamp certificate, maintenance of a database of time-stamp certificates, maintenance of a log of TSA activity, etc.

• The Camouflaging communications functional unit supports the camouflaging communications service. It takes the message submitted for camouflaged transmission and passes it through the network of camouflaging TTPs to its destination. Onion routing and data flow concealing are used to provide camouflaging.

This service-per-unit approach used in the Trusted Services group simplifies addition and removal of support for trusted services by actual TTPs.

The remaining two functional groups (Local-ized Supporting Services and Infrastructure Supporting Services) provide general purpose functionality used in trusted services, and access related functional units.

The Localized Supporting Services group is split into four functional units: Cryptographic services, Logging, Archiving, and Database management.

• The Cryptographic services functional unit provides various functions that perform cryptographic computations on a block of data.

• The Logging functional unit provides functions for creating and subsequent analysis of various logs of events.

• The Archiving functional unit provides access to archiving facilities. Its major functions are to save a named block of data in the archive, and to restore it from the archive.

• The Database management functional unit provides functionality necessary for creating and maintaining various databases.

The Infrastructure Supporting Services functional group is divided into four functional units: Electronic payment access, Directory service access, Delivery system access, and Service Client.

• The Electronic payment mechanisms functional unit supports various online payment mechanisms. Its major function is to accept payments for services from TTP clients and other TTPs. It has to maintain databases of certificates and be registered with various online payment systems such as Visa/MasterCard SET, MONDEX, etc.

• The Directory access functional unit provides access to various directory services and online databases. Its major functions are to retrieve a known object from a directory or an online database, to search a

	KEYSTONE PKI services
Standards and specifications	Registration	Digital Sign	Encryption	Time stamping	Non repudiation	Key management	Certificate management	Information Repository	Directory	Camouflaging	Authorisation	Audit	Assurance	Customer	TTP to TTP
ISO 9594 ITU-T X.500 (The Directory)	+	+				+	+	+	+		+			+	+
ISO 9796 (Digital signature giving message recovery)		+	+
ISO 14888 (Digital signatures with appendix)		+
ISO 11770 (Key management)						+	+
ISO 9798 (Entity authentication)		+		+							+
ISO 13888 (Non repudiation framework)					+			+
ISO 13335 (Management of IT security)												+	+
ISO 15416 (Management of TTPs)												+	+		+
ISO 15408 (Evaluation criteria for IT security)												+	+
ISO TR-13569 (Information security guidelines in banking)								+				+	+
ISO 9735 (EDIFACT)			+
ENV 12388 (Algorithm for digital signature services)		+
PKIX						+	+								+
SPKI						+	+				+				+
LDAP	+								+
WHOIS++	+								+
PEM			+			+	+								+
S/MIME			+
SSL			+
IPSEC			+
DNSSEC	+						+	+	+
GSS-API		+	+			+
Microsoft CryptoAPI		+	+			+
GCS-API		+	+			+
CORBA Security Services		+	+		+	+					+	+
RSA PKCS		+	+			+	+
SET			+		+

Table 2: Standards and KEYSTONE PKI services. ‘+’ means that the standard describes the mechanisms and/or guidelines that implement the service on their own or in co-operation with other mechanisms and/or guidelines.

directory or an on-line database for specific objects, and to provide read/write access to the record(s) about the TTP in the directory service(s) and/or online database(s).

• The Delivery system access functional unit provides access to various delivery services such as E-mail, electronic file transfer, fax, and postal mail. These services are used for key distribution, camouflaged message delivery, etc. The major function of this functional unit is to transmit a block of data to a specified destination using a specified means of transport.

• The Service Client functional unit provides other functional units (primarily trusted services) with a mechanism to request trusted services from other TTPs. This is essential for camouflaged communications, disclosing a newly generated key to the government key escrow agency, etc.

4.5. Technology Evaluation

In order to ensure TTP to TTP interoperation, standards must be adopted at the TTP operation level as well at the TTP to TTP interconnection level. Standard status gives a technology additional competing advantage on the market. Such technologies are considered to be particularly promising candidates. Twenty-seven PKI related International and European standards have been reviewed in [27].The applicability of PKI standards for different KEYSTONE PKI services is summarized in Table 2.

The review of PKI related standards demonstrated that many PKI services are covered with standards of some form.There are international standards dedicated to encrypted communications, digital signatures, digital certificates, non-repudiation services, key management, TTP security assurance and TTP management. Other PKI services or their elements are discussed as parts of large framework standards or as supporting services for other PKI services.

Every service in the above table corresponds to one or more functional units through its supporting functions. In order to implement these functional units, available technologies have been evaluated.The rest of this section evaluates available technologies in each functional area in the KEYSTONE Functional Architecture and highlights the most promising candidates in each functional area.

We understand functional area as a group of functional units that are based on the same technologies. The KEYSTONE Functional Architecture consists of fifteen functional areas:

• System Interconnect (the Kernel).

• Secure customer and management access (Secure Customer Access and Secure Management Access, and Service Client functional units).

• Access rights and payment control (Customer Access Rights Control, Payment, and Management Access Rights Control functional units).

• Digital certificates (Certificate Management functional unit).

• Key management (Key Management functional unit).

• Time-stamping (Time-stamping functional unit).

• Non-repudiation (Non-repudiation functional unit).

• Camouflaging communications (Camouflaging Communications functional unit).

• Cryptographic services (Cryptographic Services functional unit).

• Database management (Database Management functional unit).

• Archiving (Archiving functional unit).

• Logging (Logging functional unit).

• Electronic payment mechanisms (Electronic Payment Mechanisms functional unit).

• Directory access (Directory Access functional unit).

• Delivery (Delivery System Access functional unit).

Also there are two functional units that are totally based on services provided by other functional units and do not require additional technology. These are the Customers’ Accounts and the Management Accounts functional units.

Not all of the above functional areas can employ a widely accepted standard. That is why we will use a rather broad definition of technology.We will understand a technology as either

Functional area	Most promising candidate technologies
System interconnection	CORBA
Secure management and customer access	WWW + SSL,
	SSH + custom application
	Secure email (S/MIME, PGP)
	Postal mail
Access rights and payment control	Policy Maker or a proprietary system
Digital certificates	X.509
	SPKI
Key management	ISO 8732
	ISO 11770
	PKCS
Time Stamping	U.S. patent 5,136,647,
	Annex to ISO 13888-3
Non-repudiation	ISO 13888
	CORBA Non-repudiation service
Camouflaging communications	Onion routing
	Traffic padding
Cryptographic services	RSA Cryptoki Microsoft CryptoAPI Open Group’s GCS-API
Database management systems	Medium-class or high-end DBMS supporting SQL
Archiving	Unix tar
	IBM ADSM
Logging	Unix logging
	CORBA Audit service
Electronic payment mechanisms	SET
	Ecash
	Mondex
Directory access	X.500/LDAP
	Z.39.50
Delivery	Secure E-mail (S/MIME, PGP)
	Postal mail

Table 3: KEYSTONE technology profile.

• A precise specification of service provision or data processing, which defines data formats, algorithms, protocols, etc. There may be a software or hardware implementation of the specification, which can be used as a building block for a TTP.

• A widely accepted scenario/approach for service provision or data processing. In the absence of a precise specification, this can be used in as a guideline for designing a good proprietary solution.

The most promising candidate technologies, on the basis of which a highly interoperable and secure TTP can be built, have been highlighted. The technology profile presented in Table 3 lists the most promising candidate technologies on a per-functional area basis.

Of course, the above technology profile is not fixed. When a new suitable technology appears, it can be added to it.

5. The KEYSTONEAbstract Public Key Infrastructure Architecture

The main characteristics of this architecture are the following:

1. Openness: this means that open data networks should be employed as the carriage for the KEYSTONE PKI instead of closed proprietary Value Added Networks. Despite its security risks, the Internet is a very good candidate for the KEYSTONE PKI. VANs are very expensive and base their security on their closed nature rather than on the robust security mechanisms they provide. In addition, during the last years there has been a lot of progress in solving security related problems deriving from the Internet’s untrusted nature (e.g. IPv6). Furthermore, the proposed infrastructure is based on well established standards that have been implemented over the Internet (i.e. HTTP, SSL, S/MIME, LDAP, X.509, X500 etc.). As a result it can integrate other non compliant PKIs due to the use of protocol gateways that should be established at the intersection points of the PKI and the proprietary PKIs.

2. Scalability: during the past few years we have witnessed an evolution from small-medium scale organizational networks to large-scale intranets. The proposed infrastructure has been designed in such a way that it provides the same (or improved services) as the information and computing resources grow and become distributed.

3. Flexibility-Extensibility: as soon as new technologies are adopted and old ones become obsolete, a PKI must be capable to easily merge any changes to the corporate infrastructure. The TTP internal structure has been designed with Object Orientation principles in mind. As a result modularity and logical independence between structural components (functional units) has been achieved. This fact guarantees that technological changes can be easily adopted from the KEYSTONE PKI as soon as new technologies come up and old ones become obsolete.

4. Integration with existing information and technological infrastructure: the proposed architecture has been designed to coexist with pre-established technological solutions.The CORBA (its security enhanced version, of course) kernel guarantees

that legacy infrastructure (software code as well as legacy hardware) can interoperate with the KEYSTONE PKI.

1. Transparency: the proposed model enables users that use specific software or hardware platforms to transparently interact with users that use equipment that is different and non compliant with their own. Platform independence is achieved through the use of CORBA at the kernel level. CORBA offers mechanisms whereby platform dependent code can be wrapped and exported through higher level common interfaces.The platforms that are expected to dominate are Unix and Microsoft Windows.

2. Security of reserved information. The prop-osed architecture has adopted all the state of the art services, functions, mechanisms and standards with regard to information security. As a result, the confidentiality and integrity of sensitive information, as well as authentication is guaranteed.

The proposed abstract KEYSTONE PKI is depicted in Figure 6.

The basic communications that take place in such a model are the following:

1. User to TTP communication: each user is equipped with the Customer access and Directory access functional units. Using the Internet, the user is connected to the Customer access or the Directory access functional units at the TTP’s side. The process of such a communication request as well as the relationships between the involved functional units has been described in Figures 4 and 5.

2. KEYSTONE-PKI-member-TTP to KEY-STONE-PKI-member-TTP communication: the communication between two different KEYSTONE TTPs takes place through the Service Client functional unit, which belongs to the Infrastructure Supporting Services group. Since this communication is based on well-established standards, no further analysis is needed at this

Figure 6: Unified KEYSTONE Abstract Public Key Infrastructure Architecture.

point. The same holds true for non-KEYSTONE PKI member TTP (or PKI) that implements the same (or compliant with those) standards that the KEYSTONE PKI utilizes.

3. Other-TTP to KEYSTONE-PKI-member-TTP communication. In that case protocol and standard converters or bridges should be utilized in order to translate transmitted information from KEYSTONE based format to other PKI’s based format and vice versa. These bridges should be the intersection points between the KEYSTONE PKI and the foreign PKI.The bridges need not necessarily reside in sites that belong to KEYSTONE infrastructure.

6. Conclusions

A PKI architecture has been proposed, which consists of: a set of services that should be offered; a set of functions implementing these services; an abstract reference model describing the operation of a PKI TTP in terms of roles and actions; a functional specification comprising functional units and a communication kernel; and a set of technologies and relevant standards implementing the defined functional units.

The proposed KEYSTONE Architecture has all the desirable characteristics and fulfils all those criteria that are essential for a PKI to constitute a successful framework for the development of inter-domain and international Trusted Services.The object methodology followed during the architecture evolution promises that the KEYSTONE architecture will easily adjust to future technological variations. Furthermore, the adoption of standards s uitable for the TCP/IP protocol stack guarantees that the KEYSTONE may constitute the future vehicle for the European Trusted services, taking advantage of the Internet as the information highway back bone.

References

[1] W. T. Polk, D. F. Dodson, et al, Public Key Infrastructure: From Theory to Implementation, http:// csrc.nist.gov/ pki/ panel/overview.html .

[2] Public Key Infrastructure, http://www. ietf.org/ html.charters/pkix-charter.html .

[3] B. Kaliski, An overview of the PKCS standards, RSA Laboratories, 1993.

[4] P. R. Zimmermann, The Official PGP User’s Guide,MIT Press, 1995.

[5] C. Ellison et al., SPKI Examples, 1998 (draft-ietf-spki-cert-examples-01.txt).

[6] C. Ellison et al., SPKI requirements, 1998 (draft-ietf-spki-cert-req-02.txt).

[7] C. Ellison et al., Simple Public Key Certificate, 1998 (draft-ietf-spki-cert-structure-05.txt).

[8] C. Ellison et al., SPKI Certificate Theory, 1998 (draft-ietf-spki-cert-theory-03.txt).

[9] R.L. Rivest, B. Lampson, SDSI – A Simple Distributed Security Infrastructure, http:// theory.lcs.mit. edu/cis/sdsi.html .

[10] M.Blaze, J. Feigenbaum, J. Lacy, “Decentralized Trust Management”, in Proceedings, IEEE Conference on Security and Privacy, IEEE Computer Society Press, 1996.

[11] Q. He, K. Sycara and Z. Su, “A solution to open standard of PKI”, in C. Boyd and E. Dawson (Eds.), Information Security and Privacy, Lecture Notes in Computer Science, Springer-Verlag, 1998.

[12] W. Burr D. Dodson, N. Nazario, T. Polk, MISPKI: Minimum Interoperability Specification for PKI Components, June 1997, NIST.

[13] Specifications for Trusted Third Party Services, September 1997, ETSI DEN/SEC-003001.

[14] T. Gustavsson, “A WWW based Certification Infrastructure for secure open network transactions”, in P. Horster (Ed.) Communications and Multimedia Security Volume 2, Chapman & Hall, 1996.

[15] SET Secure Electronic Transactions Specification version 1.0, Books 1-3, SET consortium, 1997.

[16] A. van Rensburg and S. von Solms, “A reference framework for Certification Authorities / Trusted Third Parties”, in L.Yngstrom and J. Carlsen (Eds.), Proceedings, IFIP 13^th International Information Security Conference, Chapman & Hall, 1996.

[17] Trusted Health Information Systems (THIS) project,

Final report: Requirements on electronic signature services and TTP services, Swedish Institute for Health Services Development, 1995.

[18] TrustHealth-ETS project, Functional specification of TTP services, Swedish Institute for Health Services Development, 1995.

[19] TTP & Electronic Signature Trial for Inter-Modal Transport (TESTFIT) project, Final report, CEC/DGXI-II/B6, 1995

[20] BOLERO project, Final Report, CEC/DGXIII/B6, 1995.

[21] Ebridge project, Final Report, CEC/DGXIII/B6, 1995.

[22] EAGLE project, Software description and functional specification of the TTP demonstrator, Deliverable 3, CEC/DGXIII/B6, 1997.

[23] S2101 Project, User requirements for TTP services, CEC/DGXIII/B6, 1993.

[24] EUROMED-ETS project, Final Report, CEC/DGXI-II/B6, 1998.

[25] A.Nilson, European Trusted Services (ETS) - Results of 1995 TTPs Projects. Final Report, Marinade Ltd., 1997

[26] KEYSTONE project, KEYSTONE deliverable 1.1: User Requirements Statement, 1998.

[27] KEYSTONE project, KEYSTONE deliverable 9.1: Final project report, 1998.

[28] CORBA, The Common Object Request Broker Architecture: Architecture and Specification, OMG, 1995.

[29] CORBA, CORBA Services Specification, OMG, 1997.