The SEMPER Architecture

This document gives an overview of the SEMPER architecture including pointers to javadoc documentation of all SEMPER APIs.

1 Infrastructure

Before anyone can become a player on the marketplace (mostly a user, i.e., a buyer or seller), they have to obtain the necessary software and hardware and access to an underlying network. Since the user's security depends on these components, there are some serious security consequences of this:

A user must be able to trust in the design of the components, i.e., in the claims made about the security and functionality of these components.

Users must be able to trust that the actual components received are implemented according to the trusted design; i.e., they have to trust in the specific code copied from an ftp archive or received on a disk or CD-ROM, or in the specific smartcard received from a bank.

Users must be able to trust that the machine and code they are actually using are not unintentionally or maliciously manipulated during operation, e.g., by an error in the operating system, a computer virus, or a Trojan horse.

Solving these problems in general is almost impossible and certainly out of scope of SEMPER. The approach used for the SEMPER prototypes and trials is as follows.

The design of SEMPER itself will be open and public, which will allow security evaluations. Clearly, this may not be possible for the typical user. However, it allows independent verification of the components of SEMPER. It will be clearly indicated which existing basic components (like payment systems, cryptographic tools) have been used to provide the actual security services, but the SEMPER consortium will not take actions to increase the trust in such components not developed by the consortium itself.

The software required for participation in the initial SEMPER trials will be available at ftp archives and additionally distributed via disks. The SEMPER software will be digitally signed using generally available security tools (e.g., PGP) by a designated participant of SEMPER (other partners can verify this signature, thus the correctness of the signed package will essentially be the responsibility of the consortium, not a single partner). The fingerprint of the public key used by the SEMPER consortium will be published reliably, e.g., in journal publications of SEMPER and on public http servers. A user getting the software can now verify the signature against the (fingerprint of the) public key. To increase credibility, a recipient can retrieve and compare copies of the SEMPER software and the public key from different sources.

SEMPER supports the use of various hardware platforms including tamper-resistant hardware. However, it does not enforce tamper-resistance, and in the first year trials such hardware will probably not be available. This is important for the openness of the architecture for future developments, in particular in the area of mobile devices. The initial trials will usebe software-only systems, except where existing basic components already use smartcards. It is currently the user's responsibility to protect their machine and SEMPER software against malicious modifications. Note, however, that by verifying the SEMPER software against the signature received originally, changes to the components can be detected.

2 Certificates in SEMPER

Generally, we define a certificate to be any signed statement about a person. We distinguish three types of certificates:

Key certificates: Here, the statement is only that a particular public key belongs to a particular identity (distinguished name). For instance, the well-known X.509 certificates are of this type.

Attribute certificates: These certify attributes of either the person or of a certain key (identified by a certificate identifier) of this person, e.g., that the person is willing to accept legal responsibility for signatures made with this public key under certain types of statements. These certificates may also be used to give proxy to a user.

Hybrid certificates: These contain both a public key and attributes, typically a description of what this public key can be used for. They are mainly intended for service providers issuing certificates particularly for their own service.

In the cryptographic literature, the term credential is used instead of hybrid certificates, but we use this term for the personal information shown by the user at registration.

The exact data in a certificate, e.g., expiration dates, algorithm identifiers, the identity of the certifying authority, and how much responsibility the certifying authority is willing to assume about the signed statement (e.g., depending on how well the user's identity was verified in registration), will depend on the actual registration and certification module. See the description of the certificate manager for these details.

2.1 Details about What a Certificate Means to a Recipient

A certificate is a signed statement, and thus, if the recipient acts on it and later finds out that it was wrong, he can hold the signer responsible for it, as far as the responsibility indicated in the certificate goes. We now emphasize some particular points that sometimes cause confusion:

A certificate does not mean that the statement certified is true, only that the certifier says so. It is in the recipient's judgement to believe this certifier or not. In some cases, the fact that the certifier assumes responsibility is enough, but in some cases it would not help the recipient much if the certifier is punished or has to pay damages after the fact.

Someone signing a certificate only assumes responsibility for the statement signed. In particular, someone signing a key certificate is only responsible for correct linkage between person and key, and in no way for this person's trustworthiness. Similarly, someone signing an attribute certificate that the person has declared herself willing to accept legal responsibility for her key for certain types of statements is not signing that this person is able to do so -- this is a typical attribute of the key, in contrast to an attribute of the person, such as a credit limit. A physical analogue is a passport: It links a certain hand-written signature to a certain identity, and confirms (given laws about hand-written signatures) that this person will be held responsible for any document signed with this signature, e.g., cheques over high values. But of course the passport issuer does not in any way suggest that this person has an arbitrary amount of money to back these cheques, or even assume responsibility for these cheques.

Note that here we deal with the semantics of certificates, not with their internal data structure. In an implementation, someone who only signs one type of hybrid certificates, i.e., always with the same attributes, may not include the attributes explicitly. In particular, this may hold for some legacy certificates. However, for an open architecture like SEMPER, there must be a standardized method for recipients of such certificates to find out what the certificate means. For instance, we may prescribe that any certificate that syntactically contains no attributes nor responsibilities whatsoever really is interpreted as a pure key certificate, and that the certifier is entirely responsible. Alternatively, one can decide that the recipient of a certificate always has to get another signed statement from the certifier that explains the semantics of the certificates.

A certificate about a person A cannot make A responsible for anything. Only what A herself does can. This may sound confusing for certificates that state that A is willing to accept legal responsibility for a certain key, but it is no problem: What makes A responsible is A's own declaration of intent towards the certifier. If the certifier is afraid that A might later deny this intent, he has to store evidence, such as a hand-written signature by A.

Everything gets a bit more complicated if revocation of certificates is allowed, see below.

3 User Registration and Certification

In order to perform certain actions on the electronic marketplace, user registration and certification is required for the necessary security services, e.g., subscription to an electronic payment system or registration of cryptographic keys needed for digital signatures. This registration is necessary in order to link electronic actions to physical organisations and individuals, which is the basis of all kind of commerce.

The SEMPER architecture consists of four main layers, see Figure 1.

Figure 1 Architecture of SEMPER -- Overview

4 The Business Application

The Business Application stands for the environment where the SEMPER library is used. Currently, http servers are implemented to embed the SEMPER library into the World-Wide-Web (See chapter ``Implementation Architecture'' for details).

The business application should not perform actions which influence the security of the user, i.e., all flow of control should be implemented in lower lay

5 The Commerce Layer

The Commerce Layer provides services that directly implement protocols of business sessions, e.g., how specific merchants or types of merchants handle customer registration and offering, ordering, payment, and delivery of goods. Later, we will provide a secure downloading mechanisms to enable clients to interact with formerly unknown server commerce services and still retain security. Naturally, this involves some kind of code certification.

However, the commerce layer does not only offer entire such protocols, but also building blocks that may be of more general use, in particular for buyers. In particular, these standardized services may offer template services, e.g., to display and fill-out standardized order-forms and construct a container from itit is responsible for handling statement templates, such as generic, user-friendly order forms.

Currently, only these basic building blocks are implemented whereas the control flow is done by the business application and downloading of services is not implemented.

6 The Exchange Layer

The Exchange Layerprovides services for the fair exchange of containers. ``Fair'' means that, if A and B agreed on what to exchange , Party A receives B's container if and only if B receives A's container. (Without fairness, this would be just two transfers.)

7 The Transfer Layer

The Transfer Layer provides send, receive composition services for containers in order to transfer information between client and server according to given security attributes.

As mentioned in in the deliverable (section 2.2), everything that can be transferred by the transfer layer is encapsulatedcomprised in one data type called container. Each container can contain several basic items, such as signed documents, information, and money. Moreover, the transfer or the container may have security attributes. For instance, the sender (more precisely: the invoking entity) specifies that the transfer of the container should be with non-repudiation of origin; then the sender's entities of the transfer layer, with the help of the supporting services, attach a suitable signature and send everything off, and the recipient's entities of the transfer layer verify the signature and tell the recipient something like ``you received this container, and the sender cannot deny the transfer''.

This layer contains the transfer manager, the payment service block, the statement service block, and the certificate service block. Basically, methods of the transfer manager parse containers to be transferred, and lets signed documents and information be handled and transferred by the statement service block and payments by the payment service block. The certificate service blocks helps the others in the administration of the necessary certificates and performs user-registration procedures. These service blocks are later described in more detail.

In addition to the actual transfers, the transfer layer also offers invoking entities to manage these transfer services, e.g., to manage the contents of an electronic purse or to set up relations to enabling third parties. In contrast to the actual transfers, such services do not need to go via the transfer manager, e.g., the payment service block can immediately be used by higher layers for purse management.

8 Supporting Services

The Supporting Services provide support to all the upper layers.

o The Cryptographic Services provides all cryptographic services, which are needed for secure services in SEMPER. Examples for such services are message encryption and decryption, hash functions, message authentication codes, digital signatures, and their key generation (e.g., as described in [gcs-api]). The crypto block is entirely used as a supporting service and does not provide a transaction class allowing the creation of crypto sessions.

o The Communication Services support communication between entities on different devices. The services offered are independent of the network and protocols actually used, i.e., they are defined only via quality of service parameters. Thus the communication service block shields the other upper layers from network details. The basic communication service is povided by ComPoints. A ComPoint is an object which allows to access the underlying communication protocol, currently, tcp, http or mail. This service is refined by Channel, which allow the receiving module to specify the correlator of the message that it is expecting. ComPoint and Channel APIs are based on the synchronous, i.e. blocking, model (See section ``Implementation Architecture'').

o The Archive Services services for local data storage and archiving. It is in charge of storage and retrieval of all persistent data. Examples are digitally signed messages, certificates, and cryptographic keys. It includes features for persistent and secure local storage of data by, e.g., encrypting the data or archiving in tamper-resistant memory (e.g., on a smartcard).

o The Trusted Interactive Graphical User Interface Services (TINGUIN) support the interaction between services and the human user. The basic idea as that by providing a distinguished user interface to the security services, the user is aware that all inputs through this user interface are critical and that the ``usual'' business application user-interface (e.g., www-browser) must not be used for any critical input.

Naturally, the security services user-interface must be under control of the user's own device. For instance, if a buyer verifies the identity of a seller, the message ``the verification of the identity was correct'' cannot come with the seller's html-pages dependably: Any fake seller could simply provide this message ready on its html-page! Instead, the user's own device must show this message in a way so that the user can recognise it as a message from her own device. Ideally, the TINGUIN would reside on a mobile user interface, such as a PDA [PPSW 95].

Moreover, ergonomics has to be considered in the design of the TINGUIN even more carefully than usual, because any misunderstanding by the user may destroy the security.

The Preference Services define what choices a user has and what default values are given. The part that defines how the user is shown the available preferences is closely related to the TINGUIN, and what preferences are needed has to be defined by the designers of the individual managers. In addition, the preference block keeps stores the actually installed configuration, i.e., all information specific to a particular installation like the target system, the memory size, the screen type or any other hardware devices currently supported.

o Access Control Services. provide all services needed to implement access control on the methods of the various SEMPER blocks. Access control ensures that potentially dangerous, compromising or undesirable operations cannot be performed by unauthorised users or without the user's explicit consent. Access control is capability based. Each SEMPER block must declare a capability for each action for which unconditional access is undesirable. Such a capability must be verified each time the corresponding method is called. The Access Control Block provides the necessary services to manage such capabilities based on roles.
By the way, we assume that they only try to access each other nicely by their services, i.e., that the operating system does not allow them to tamper with each other's code or memory.
The roles are currently unlocked after appropriate user authoization. Later, this should e based on a policy fixing

o how and at what times the user device makes sure that the correct user is there, identification (also called user access control),

o and at what times the user must be asked for an OK, authorisation, in particular whether higher layers can ask for authorisation for many actions, e.g., many small payments, in advance, that would have to be authorised by the user if they were carried out individually.

o In addition, the actual implementation also contains a utility block with various utility services for, e.g., converting objects into streams of bytes, and for logging and debugging.

The service blocks described so far are shown in Figure 2.

Figure 2 Service blocks of Supporting and Transfer Services

Access control among components. Here we ask: Are all local entities allowed to access all the services of the SEMPER layers? By the way, we assume that they only try to access each other nicely by their services, i.e., that the operating system does not allow them to tamper with each other's code or memory. We do assume that all SEMPER managers and all fixed SEMPER modules are equally trusted, and thus they are allowed to call each other at will. However, there may be existing modules from outside providers, e.g., different existing payment systems, that we do not want to trust too much, and modules and even managers for the commerce layer that can come from many sources.

The question whether these modules can do any harm by calling SEMPER services is closely related to user authorisation: at least if the SEMPER modules offer some services where they do not ask for user's OK at a critical step, because higher-level managers say they took care of this in advance, these services should not be available to non-SEMPER modules. Access control depends on support by the programming language and the operating system, and, therefore, do not consider it for the first year trials.

The whole architecture has to be considered specifically to provide for trusted hardware on small mobile devices (ranging from a smartcard that can only be used together with another device of the same user, to a PDA that is used on its own). Of course, if trusted hardware is available at all, as much as possible should be implemented on it, but there are limits in program storage, computing capability, and the quality of the user interfacee.

9 Full JAVADOC Specification

Last Modified: 01:14pm PDT, Septembet 13, 1996

Editor: M. Schunter, University of Hildesheim, Germany <[email protected]>