Everything gets a bit more complicated if revocation of certificates is allowed, see below.
The SEMPER architecture consists of four main layers, see Figure 1.
Figure 1 Architecture of SEMPER -- Overview
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 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.
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.)
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.
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.