Off-line Transfer of Electronic Tokens between Peer-Devices

1.1 TECHNICAL BACKGROUND

Since the late 1970s, a variety of schemes has been proposed to allow payments of services and goods to be effected across computer networks. The arrival of the Internet pushed these schemes by removing many obstacles helping to interconnect using the network of networks. Part of the evolvement results in relationships Business-to-Consumers (B2C). This is now part of the electronic commerce (eCommerce), meaning to sell goods and services to consumers. The success of electronic commerce is closely related to the success of electronic retail payment instruments suitable for transactions in cyberspace. Another part of this evolution process is the shift of Business-to-Business (B2B) relationships of trade companies to electronic on-line marketplaces.

The proliferation of digital networks, mobile phones, and handheld wireless devices is a boom referring to transactions carried out with the assistance of Internet Communication Technology (ICT) services. Smartphones, PDAs, or laptops can be used nowadays to access services available through the Internet. Any electronic payment system able to fulfill the needs of B2B and B2C conforming to mobile commerce (mCommerce) has the potential to become a very large payment technology. The evolution process has involved a move from the physical transfer of tangible, materialized tokens of value-like coins and bank notes to an exchange of information between parties. The recent availability of ultra-high-speed mobile networks has greatly enhanced the opportunity to use this infrastructure. Although the shift from physical to virtual payments and the broader availability of flat rates has brought enormous benefits to consumers and merchants; it increases the pressure on payment technology providers to invent user-friendly, secure, and robust Digital Cash based solutions. This is the point where most security payment protocol designs come into play, because (and that is not really surprising) digital information can easily be copied even in protected applications, if the attacker is able to find a way to capture the embedded secrets stored in hardware or transferred over a telecommunications channel (see for example D. Chaum and T. P. Pedersen, "Wallet Databases with Observers," Proceedings of the 12th Annual International Cryptology Conference on Advances in Cryptology, 1993; or I. Ray and I. Ray, "An Anonymous Fair Exchange E-commerce Protocol", Proceedings of the International Workshop on Internet Computing and ECommerce, ed: IEEE Computer Society, 2001, pp. 172-179). The use of a Hardware Security Module (HSM) in combination with an algorithmic secure transfer protocol limits this ability by combining physical security with strong cryptography. Integrating security from the very early beginning of the design- cycle is essential. Basic approaches follow maxims like: The design of payment systems should be done in a way that achieves a maximum of fairness, information from one compromised eWallet (an electronic device that consists at least of a secure money purse chip with integrated and external non-volatile storage. The integrated non-volatile storage is used to store the secret data, the external memory stores electronic Coins and other encrypted objects) shouldn't be useful in compromising other eWallets,

countermeasures to security threats should be treated like an insurance police,

grade of system security protection needs to be defined by the cost of breaking it versus the achievable profit and the resulting damage potential to the system itself.

1.1.1 Money and Cash Terminology

What is Digital Cash? Unfortunately, many of the schemes that the popular press frequently refers to as "Digital Cash" are actually not cash (for example see S. Brands, "Electronic cash on the Internet," presented at the Proceedings of the 1995 Symposium on Network and Distributed System Security (SNDSS'95), 1995; D. Chaum, et al., "Untraceable Electronic Cash," in Advantages in Cryptology / Crypto '88, 1988, pp. 319-327; or J. Schmidt, et al., "1st elektronisches Bargeld realisierbar?", in VIS proceedings 1999, ed Braunschweig: DuD Fachbeitrage, 1999, pp. 1-18). A system providing only little more than yet another commercial transaction mechanism by adding a secure transmission capability for credit card numbers over the Internet which is not much of a financial innovation in comparison to Digital Cash. Most examples of electronic banking do not involve a different form of money, but instead simply represent a different way in accessing traditional financial (banking) services, extending the supply chain.

The terminological confusion found in many publications regarding matters related to Digital Cash, the field of ePayment (electronic payment) and eMoney (electronic money) should be explained. Most of them are using a vocabulary not rigidly defined, originated from the fact that these systems are being designed for execution by use of intelligent hardware like autonomous eWallets on one hand and software-only systems designed for electronic Internet transfers on the other. Such generalization tends to blur the distinction between Digital Cash and electronic banking in general. One can get easily confused in matters relating to word origins and actual meanings. The following table shows definitions as used in this document.

Electronic Money, Cash or eMoney These are generic definitions for all means of payment in the digital space.

Physical Money, pMoney or pCash They always mean physical coins and physical bills

functioning as legal tender.

Digital Cash or eCash These terms are a slight modification of eMoney mimicking the behavior of physical money. They are not legal tender, namely, money issued by the state and designated as legal tender for the payment of taxes and other debts, but technically it could declare them an eCurrency. Electronic Currency or eCurrency They always mean eCoins and eBills acting as legal tender legalized by a central bank, comparable to or serving as digital banknote. To date, such surrogate of pMoney is only theoretical fiction and does not exist in any country. The only thing to make this happen is for a central bank to officially adopt a Digital Cash scheme, so that digital tokens are going hand-in-hand with physical cash, both central bank-issued tokens.

Table 1 : Different modifications in definitions for money and cash.

1.1.2 Challenging Success Factors of Digital Cash

In literature of eCommerce and ePayment, special wording serving the specific needs, is often being used within the community. To clarify their importance and meaning some terms f equently used herein, inter alia include:

the electronic wallet (e Wallet),

the transfer of the electronic coins (eCoins),

aspects of the protocol,

privacy and confidentiality,

fairness,

- possible ways to counterfeit electronic coins,

redemption and risk-management.

To state this in advance, it will be shown below that the system and methods for transferring electronic tokens, in particular when the electronic tokens are electronic coins, allows for using electronic coins in an anonymous way, and ensures that they are transferable free of repudiation to support the ability of sending and receiving money, and that the money exchange can be conducted in a safe way and with good rigidity against misuse. These factors also apply to traditional cash, which explains it's general acceptance. One of the manifold objectives of this invention, when applying it to the Digital Cash context, is showing how to make the transition to a highly sophisticated secure electronic form of Digital Cash, without sacrificing the unique qualities of physical cash.

1.1.3 Kinds of contactless Mobile Payment Models

Payments for goods or services initiated from an eWallet based mobile phone or smartphone, PDA or any other (mobile) device are termed mPayment. In consistency with the banking industry's public definition there are two kinds of mobile payments:

- remote mobile payments and

- proximity mobile payments.

Most mobile eWallets are currently expected to be used in combination with a smartphone. As they may be equipped with various types of communication interfaces, a flexible adaptation is desirable to utilize them as communication channel. Figure 1 depicts the available possibilities to set up such connections using different pairing constellations.

Short-range wireless or proximity mobile payments are defined as wireless payment operations ranging in a broadcast-domain ad-hoc topology. Most proximity mobile payments are expected to be made at both, attended Point-of-Sale (PoS) locations (such as stores), and unattended locations (such as vending machines), using an existing merchant's payment infrastructure, including local direct peer-to-peer connections between two gadgets with their attached eWallets. To pay, the user simply brings his mobile eWallet with the other user's eWallet or the contactless payment enabled PoS system to within a few inches, and the transaction occurs. The technical range of a proximity system is typically below 10 meters, the Near Field Communication (NFC) or Radio Frequency IDentification (RFID) named range typically less than 10 cm. This is the case if someone is shopping in a mall wanting to checkout with selected goods or services at a Point-of-Sale (PoS). Excluding the cases with nobody sitting at the cash desk or the customer being the only person waiting for service, the customer himself is in a queue standing with other customers waiting for the pay-up. In these situations, a single eWallet-to-e Wallet enabled payment will be sufficient. This payment model is a penurious one using queues: Multiple clients are trying to pay at a single cash desk by waiting in a queue condition.

Using a local ICT infrastructure, an underlying network needs to support multiple payers to connect to the eWallet operated access (gate/touch) point. A good representative of such situation is a payment gate where masses (even hundreds or more) of transactions have to be processed in a few seconds. In most cases this involves broadcast domain collisions in the cell of a LAN or Personal Area Network (PAN). According to the statistics one has to provide enough bandwidth within the collision domain and available eWallet (service) resources in standby state to satisfy the average demand of the requests and to prevent from deceiving the customers. Important design aspects are for example the speed of a payment transaction and the number of concurrent payment actions. The operating mode commonly is an ad-hoc network configuration (in contrast to an infrastructure-based one) to allow for rapid contacts between payment parties. Mostly, both contracting parties are sojourning in the same room or meeting within a distance of less than 50 meters. In most cases a range of 2 meters is sufficient. This prevents customers from moving away after having established a pairing and before the termination of the protocol-execution.

Long-range wireless or remote mobile payments are defined as wireless payment operations ranging in a single-cast environment by phone number and/or MAC/IP or other means of identification. Practical use cases for remote mobile payments may include physical good purchases from a web merchant or payments for digital goods (and/or (cloud) services). Remote mobile payments are ideal to be used in markets requiring person-to-person payments and for under-banked consumer and merchant environments. To transfer money, a user simply initiates a P2P Internet connection using his mobile gadget and the counterpart authorizes the transfer. In contrast to the previous local model, the scope of remote payments is a global one. This payment situation arises if both peers have to connect over long distance. The Internet, mobile radio services, or leased line based networks will be mostly used in such situations.

1.1.4 Anonymity

One distinguishing feature between account-based and pre-paid coin systems is the anonymity a token-based system can provide to its users. In contrast, account-based systems by design need to identify the system users and their transactions. As with identified eMoney, both, off-line and on-line, the bank always can reconstruct the path the cash has taken through the economy. Reasons for anonymity are manifold. Although anonymity is addressed by several payment mechanism schemes, nearly none of them provides this feature satisfactorily (see H. Neumann and B. Fay, "Anonymitat in digitalen Miinzsystemen mit Wechselgeld," in GI Jahrestagung (Schwerpunkt "Sicherheit - Schutz und Zuverlassigkeit"), 2003, pp. 317-327).

Only off-line and anonymous eMoney has the ability to hide the transaction trail (if the eMoney is not multiply spent). In the (standard) case, the bank can neither determine the identity of the original spender, nor can it reconstruct the travel path. Most existing procedures to provide anonymity are based on digital blind signatures (see D. Chaum, "Blind signature systems," in Crypto 83, 1984, pp. 153-158; and US 4,759,063 to D. Chaum). They offer only conditional anonymity in order to reveal anonymity in case of multiple spending or other (fraud) cases and furthermore are lacking multi-hop ability, i.e. after one transfer of an electronic token the electronic token has to be cleared with the bank, thereby revealing the movement of the electronic token to the bank, hence removing anonymity. 1.2 SUMMARY OF THE INVENTION

One of the objects of this invention is to provide a method for transferring electronic tokens between peer-devices. Another object of the invention is to suggest the design of a transaction protocol that allows for a peer-to-peer transfer of electronic tokens between peer-devices. Furthermore, it is another object to suggest a transaction system/transaction protocol in which the electronic tokens can be transferred from device to device without increasing their size. An additional but optional object is to allow the parties of a transaction to stay (unconditionally) anonymous in the transaction protocol.

Further objects of the invention are related to the design of a tamper-protected semiconductor module usable for transferring electronic tokens between peer-devices.

Another object of the invention is to suggest designs for increasing tamper resistance of a hardware (e.g. a device, semiconductor module or hardware module). This object is independent from the other objects of the invention. Nevertheless, the suggested tamper-protected hardware may also be usable in hardware for use in the transaction system proposed herein.

One of the various aspects of the invention is to suggest a protocol capable to transfer electronic tokens between two tamper-protected semiconductor modules using a peer-to-peer link. The protocol is designed to transfer the electronic tokens without requiring inter-action with a (trusted) third party. Hence, the transfer of the electronic tokens can always be regarded as an off-line transaction between two tamper-protected semiconductor modules, for which reason the protocol is also referred an offline transaction protocol. A variety of triggers/events may cause an interruption of the off-line transaction protocol, which will lead to a termination of the off-line transaction protocol in either a fair state for tamper-protected semiconductor modules (respectively their users) or rarely in an unfair state for the tamper-protected semiconductor modules. The tamper-protected semiconductor modules may be implemented in peer-devices for example.

In case of a successful transfer of the electronic tokens between the two peer-devices, i.e. terminating the off-line transaction protocol without interruption prior to the end of the protocol-run, the off-line transaction protocol is of course fair to both parties of the transaction. However, in case of an interruption prior to the expected end of the off-line transaction protocol's run (e.g. due to a channel break of the peer-to-peer link, incompatibility of the change electronic token type, expiry of certificates, or other sources of errors), the off-line transaction protocol may terminate in an unfair state, but still offers the possibility to prove the loss of electronic tokens in a later compensation procedure, thus establishing de-facto delayed fairness to both parties of the transaction. The compensation procedure may be performed on-line or off-line, respectively. The separation of the fairness reconstruction (by means of the compensation procedure) from the off-line transaction protocol for transferring the electronic tokens enables de-facto off-line transactions between two peer- devices via a peer-to-peer link, and ensures delayed fairness to the transaction by means of separate compensation procedures for an incidental dispute resolution.

Accordingly, one embodiment of the invention is related to a method for transferring electronic tokens between two tamper-protected semiconductor modules. The method executes an off-line transaction protocol that is controlling the exchange of protocol messages between the two tamper-protected semiconductor modules including a transfer of electronic tokens between the tamper-protected semiconductor modules via a peer-to-peer link, wherein the off-line transaction protocol further enables delayed-true fairness.

In a more detailed exemplary embodiment of the invention, in case of an interruption prior to the expected end of the protocol-run of the off-line transaction protocol, each tamper-protected semiconductor module autonomously terminates the off-line transaction protocol in either

a fair state in which the transfer of the electronic tokens is either successfully completed or the initial state prior to the transaction is restored, or

an unfair state for the respective tamper-protected semiconductor module in which one or more electronic tokens irrevocably lost at the respective tamper-protected semiconductor module.

In case a termination of the off-line protocol is possible only in an unfair state of a respective tamper- protected semiconductor module, the transaction protocol enables delayed-true fairness by providing a proof of loss of one or more electronic tokens by the respective tamper-protected semiconductor module vis-a-vis a third party. In one example, the third party is an issuing authority that issued the one or more electronic tokens that have been lost.

As mentioned above, the off-line transaction protocol may terminate in an unfair state. For the reconstruction of fairness, it may therefore be advantageous, if the parties of the transaction (i.e. the tamper-protected semiconductor modules) use a mechanism that allows for proving the loss of any electronic token to a third party in a (later applied) fairness reconstruction process. According to one further aspect of the invention, this proof of loss is provided by means of a so-called electronic document (eDoc) which can be considered a non-repudiation token to ensure non-repudiability of the transaction. In one exemplary embodiment of the invention, the transaction protocol messages exchanged by the tamper-protected semiconductor modules during a so-called negotiation phase and a so-called electronic token transfer phase comprise an electronic document which includes information about the state of the transfer of the electronic tokens and which is part of the proof of loss provided in case the off-line transaction protocol terminates in an unfair state at a respective tamper-protected semiconductor module.

According to another exemplary embodiment, the first (initial) version of the electronic document is generated within the negotiation phase of the electronic tokens to be transferred in the transaction. The electronic document will be updated and exchanged by the tamper-protected semiconductor modules as part of the transaction protocol messages exchanged by the tamper-protected semiconductor modules in both, the negotiation phase, and the electronic token transfer phase. The tamper-protected semiconductor modules may e.g. mutually sign and counter-sign information added to the electronic document as part of the update thereof.

Another aspect of the invention is the provision of a tamper-protected hardware for use in the transaction system described herein. In this respect, aspects of the invention focus on the functionality of the tamper-protected hardware (which may of course also depend on its firmware), and on the design of the tamper-protected hardware so as to avoid misuse and cloning of the tamper-protected hardware and transaction system. It will become apparent from the following that there is often also a synergy between functionality and design concepts, which in combination improve the robustness of the transaction system.

As to the functionality of the tamper-protected hardware, same may be inter alia responsible for executing the off-line transaction protocol according to one of the various embodiments described herein in a tamper-protected environment, which is one important security aspect of the system. Optionally, also the error handling of the off-line transaction protocol (for termination in case of an interruption prior to the expected end of the protocol-run) and/or the fairness reconstruction procedure for dispute resolution may be functionality provided by the tamper-protected hardware. The respective functionality may be provided by the firmware (e.g. by means of TRUSTLET(s), and/or including integrity checking functions - see below), or may be provided in some dedicated hardware of the tamper-protected hardware. As some of the security measures to improve the tamper resistance of the hardware/device on the chip level and others provide tamper protection on the packaged chip level, it will be referred to (tamper-protected) semiconductor modules and (tamper-protected) hardware modules. A semiconductor module is denoting the packaged hardware module (chip). In one exemplary implementation, a semiconductor module is obtained by bonding the hardware module on a circuit carrier and packaging the bonded hardware module into a casing box. A hardware module could be, for example, implemented as a chip, a die, or a multi-die. A tamper-protected semiconductor module may also be referred to as a Hardware Security Module (HSM).

Accordingly, another embodiment of the invention provides a tamper-protected semiconductor module for transferring electronic tokens between the tamper-protected semiconductor module and another tamper-protected semiconductor module. The tamper-protected semiconductor module is adapted to execute an off-line transaction protocol controlling the exchange of protocol messages between the two tamper-protected semiconductor modules and which includes transfers of electronic tokens between the tamper-protected semiconductor modules via a peer-to-peer link, and wherein the off-line transaction protocol enables delayed-true fairness.

In one exemplary embodiment, the tamper-protected semiconductor module is a tamper-protected chip, die or multi-die. In another exemplary embodiment of the invention, the tamper-protected module is implemented in a tamper-protected integrated circuit (IC). The tamper-protected IC may be implemented as a tamper-protected die having a tamper-protected enclosure.

Furthermore, another embodiment of the invention is also related to a hardware or device comprising a tamper-protected semiconductor module of a hardware module according to one of the various embodiments described herein. The device may optionally further comprise one or more wired and or wireless interface(s) and wherein the tamper-protected semiconductor module of the device is adapted to perform the off-line transaction protocol via wired and/or wireless peer-to-peer link(s) using one of the device's wired and/or wireless interfaces, or using an external (mobile) device with Internet access to serve as Internet gateway or access point for other devices (such a mechanism is also referred to as tethering).

A further aspect of the invention is related to the design of tamper-protected hardware. The tamper- protected hardware described herein may be usable in a transaction system, but is not limited to such use. The various designs of tamper-protected hardware according to this invention are not limited to any specific application, but could be used to "harden" virtually any hardware against tampering. This includes hardening/annealing the hardware against tampering on the hardware/device and or semiconductor module and/or hardware module level.

In this context, it is a further aspect of the invention to provide a tamper-protected hardware that is provided with a hardware structure providing a Physical Unclonable Function (PUF). A set of known challenges and their respective corresponding responses of the hardware PUF is used to verify integrity of the tamper-protected semiconductor modules: Basically, the hardware structure implementing the PUF could be challenged by one or more challenges for which at least one response of a challenge is known, and in case the tamper-protected hardware is a "cloned" tamper-protected hardware, the PUF response provided by the hardware structure would not match the expected and known response(s).

For example, in one exemplary embodiment of the invention, a tamper-protected hardware comprises a hardware structure providing a PUF - referred to as "hardware PUF" below. The hardware structure provides a response to an input challenge to the PUF implemented in the hardware structure. Furthermore, the tamper-protected hardware may be equipped with a processor unit for providing at least one challenge to the hardware PUF, for which the correct PUF response by the hardware PUF is known. The processor unit receives a respective PUF response for each challenge provided to the hardware PUF, and verifies integrity of the tamper-protected hardware by checking whether the response to the at least one challenge for which the correct PUF response is known is matching the response received from the hardware PUF.

Another possible way to use the hardware PUF for securing the tamper-protected hardware module is its use in a segmentation process of secrets (e.g. electronic tokens, encryption keys such as for example a secret key, a private key as part of a public key-pair, certificates, etc.) performed by the tamper-protected hardware module: A secret is split into two parts using a so called "constructor function" or "key generation function". The construction function uses the hardware PUF to produce a file called "helper data", which is one of the parts of the secret. Due to the unique nature of the hardware PUF, the "helper data" is also unique like an individual lock and its key. The original secret can only be reconstructed using the (correct) hardware PUF as well as the correct "helper data". Such procedure avoids the (need of) storing of the secrets in a digital form on the device as only the helper data is stored. The helper data do not need to be protected. The secrets are extracted from the device by using the constructor function only if required. The secrets, once used, can be removed from all internal (semiconductor) registers and memories.

Another aspect of the invention related to the design of tamper-protected hardware (which may be used together with the hardware PUF functionality or independent therefore) is to provide a tamper- protected hardware module with a FPGA that has a given configuration of an array of processing- elements to provide a given functionality. This given configuration of processing elements can be considered a fingerprint of the programmed FPGA. Moreover, a storage unit of the tamper-protected hardware module may store signed configuration information indicating the initial configuration of the array of processing-elements of the FPGA of the hardware module. The hardware module's processor unit could then verify integrity of the hardware module by verifying integrity of the initial configuration information of the FPGA based on its signature and comparing the verified initial configuration information of the FPGA with the current configuration information of the processing- elements of the FPGA.

Another aspect of the invention is related to the design of the tamper-protected semiconductor module. Please note that this aspect is independent of the other aspects of the invention provided herein, but - in some embodiments of the invention - the tamper-protected semiconductor module may be used in combination with them to further improve tamper resistibility. The basic approach underlying this aspect of the invention is to design a semiconductor module which has unique properties with respect to the deflection of a physical measurand in response to an excitation. These unique deflection properties are introduced by the production process of the semiconductor module and are thus capable of uniquely identifying the semiconductor module. Further, tampering of the semiconductor module will alter its deflection properties, which makes tampering attempts observable. Therefore, the semiconductor module is referred to as "tamper-protected".

In one exemplary embodiment of the invention in line with this aspect, there is provided a tamper- protected semiconductor module comprising a tamper-protected hardware module. The hardware module comprises one or more emitters for emitting a predetermined excitation that can be measured as one or more physical measurands. Further, the hardware module may comprise one or more sensors for sensing the (back-) scatter of the predetermined excitation in form of the physical measurand(s) in a contactless manner. The tamper-protected semiconductor module further has a cocoon that houses the hardware module. This cocoon may also be referred to as a package or housing. The cocoon is configured to influence the (back-) scatter of the predetermined excitation to be sensed by the sensors.

The deflection properties of the inside of the cocoon and thus also the (back-) scatter of a given excitation depends on the production process, e.g. the packaging process of the hardware module. Therefore, the measured (back-) scatter of the predetermined excitation influenced by the cocoon (deflection properties depending on the production process of the cocoon) provides a PUF specific to the tamper-protected hardware module. This PUF function of the tamper-protected semiconductor module is also referred to "cocoon PUF" for simplicity. Using this cocoon PUF, the hardware module - according to another more detailed embodiment of the invention - is able to detect any tampering of the tamper-protected semiconductor module, including non-invasive (or passive), semi-invasive, and full-invasive attacks to access the inside of the covering cocoon, respectively.

Another aspect of the invention is to control a tamper-protected hardware to boot in a controllable operating environment. Many attacks on tamper-protected hardware succeed by managing the attacked hardware to boot into a non-secure operating environment allowing the execution and/or exploit of the hardware. To prevent such type of attacks, the invention introduces so-called TRUSTLETs which can be considered integrity protected entity blocks (e.g. an entity block contains a code block and optionally a data section (e.g. comprising static data and/or initialization data or the like)) of software/firmware functionality to be executed by the tamper-protected hardware. The integrity of each TRUSTLET to be executed, e.g. within the bootstrapping of a tamper-protected hardware module, is verified prior to its execution using a public key infrastructure, so that the execution of malicious code is prevented.

According to one exemplary embodiment of the invention, a method for generating a software module (i.e. TRUSTLET) is provided. An entity block to be included to the software module is provided. The entity block can be considered executable piece of software/firmware (e.g. providing a given functionality). A fingerprint of the entity block using a hash function is generated. The fingerprint allows the verification of the integrity of the entity block. The fingerprint is then encrypted using the private key of a public key pair, to thereby generate a digital signature of the entity block. The entity block is then combined with the encrypted fingerprint to form an integrity protected entity block. Optionally, the entity block may be compressed prior to combining its with the encrypted fingerprint. Furthermore, the integrity protected entity block is encrypted using a random secret key to thereby form an encrypted and integrity protected entity block. The random secret key is also encrypted using the private key of a public key pair. The software module (i.e. TRUSTLET) is assembled (or generated) by combining the encrypted and integrity protected entity block, and the encrypted random secret key.

Optionally, each entity block that is included into a TRUSTLET may itself comprise functionality to execute another TRUSTLET, including the verification of the other TRUSTLET 's integrity.

Furthermore, according to another embodiment of the invention, there is provided a method for bootstrapping a host device/hardware by executing a set of software modules (i.e. TRUSTLETs) in a given order. The bootstrapping may include:

a) decrypting an encrypted random secret key of one of said set of software modules to be executed next, b) decrypting an encrypted and integrity protected entity block of the software module to be executed next, using the decrypted random secret key, to thereby obtain an integrity protected entity block of the software module to be executed, c) decrypting an encrypted fingerprint comprised in the integrity protected entity block of the software module to be executed next, and d) generating another fingerprint of the entity block using the same hash function as used to generate the encrypted fingerprint, e) verifying the integrity of the entity block of the integrity protected entity block of the software module to be executed next by comparing the fingerprint decrypted in step c) with the fingerprint generated in step d), and f) only in case the integrity of the entity block of the software module to be executed next is successfully verified, executing the entity block of the software module to be executed next, wherein steps a) to f) are performed for each software module of the set of software modules thereby realizing a chain of trust.

A further aspect of the invention, which can be considered to be a functional and design aspect of the tamper-protected hardware, is related to providing a validation process of the tamper-protected hardware, which could be considered an "initialization" of the tamper-protected hardware. This validation process/initialization of the tamper-protected hardware may be performed at a Root Certification Authority and provides the tamper-protected hardware module with a certificate that is used as the "identity" or identifying descriptor item (e.g. a serial number) of the tamper-protected hardware in any transaction performed. Any tamper-protected hardware that does not undergo the validation process/initialization at the Root Certification Authority and that has thus not obtained "its" certificate from the Root Certification Authority will be unusable in the transaction system.

1.3 BRIEF DESCRIPTION OF THE FIGURES In the following the invention is described in more detail in reference to the attached figures and drawings. Similar or corresponding detail in the figures is marked with the same reference numerals.

Figure 1 illustrates the options of pairing (proximity and remote pairing) of peer-devices, Figure 2 shows an exemplary PKJ infrastructure for use in a transaction system according to an exemplary embodiment of the invention, the PKI infrastructure based on the standard ITU-T X509, version 3,

Figure 3 shows another simplified PKI infrastructure for use in a transaction system according to an exemplary embodiment of the invention,

Figure 4 shows an overview on the exchange of protocol messages between two peer-devices according to the off-line transaction protocol of an exemplary embodiment of the invention for protocol case [a],

Figure 5 shows the exchange of protocol messages between two peer-devices according to the off-line transaction protocol of an exemplary embodiment of the invention for protocol case [a],

Figure 6 shows the exchange of protocol messages between two peer-devices according to the off-line transaction protocol of an exemplary embodiment of the invention for protocol case [b],

Figure 7 shows the flow of messages in the Pairing Phase of the proposed off-line transaction protocol according to an exemplary embodiment of the invention, Figure 8 shows the flow of messages in the VPN VPC Setup Phase of the proposed off-line transaction protocol according to an exemplary embodiment of the invention,

Figure 9 shows the flow of messages in the Negotiation Phase of the proposed off-line transaction protocol according to an exemplary embodiment of the invention,

Figure 10 shows the flow of messages in the Value Data Transfer Phase of the proposed off-line transaction protocol according to an exemplary embodiment of the invention,

Figure 11 shows the flow of messages in the Confirmation Phase of the proposed off-line transaction protocol according to an exemplary embodiment of the invention,

Figure 12 shows an exemplary state decision tree for the protocol case [a] of the proposed off-line transaction protocol according to an exemplary embodiment of the invention,

Figure 13 shows an exemplary state decision tree for the protocol case [b] of the proposed off-line transaction protocol according to an exemplary embodiment of the invention,

Figure 14 shows a table summarizing all possible protocol state pairs of the two transaction partners upon an interruption and in the success case of the proposed off-line transaction protocol for the protocol case [a] and the respective operations performed by the respective transaction partners,

Figure 15 shows a table summarizing all possible protocol state pairs of the two transaction partners upon an interruption and in the success case of the proposed off-line transaction protocol for the protocol case [b] and the respective operations preformed by the respective transaction partners,

Figure 16 exemplifies the state transitions of a CASTOR in form of a Mealy automat, executing the off-line transaction protocol according to an exemplary embodiment of the invention,

Figure 17 shows a block diagram of a tamper-protected hardware module (CASTOR) according to an exemplary embodiment of the invention,

Figure 18 shows a generation process of a TRUSTLET according to an exemplary embodiment of the invention,

Figure 19 shows the process for validating a TRUSTLET prior to its execution according to an exemplary embodiment of the invention,

Figure 20 shows an exemplary trusted bootstrapping of a CASTOR using TRUSTLETs according to an exemplary embodiment of the invention,

Figure 21 shows a comparison of a Read Only Memory (ROM), a Crypto-Function and a Physical

Unclonable Function (PUF), Figure 22 exemplifies the PSSBI approach provided by the API Filter of the CASTOR's firmware in combination with the hardware according to an exemplary embodiment of the invention,

Figure 23 exemplifies the logical PSSBI filter interface functionalism according to an exemplary embodiment of the invention,

Figure 24 shows an exemplary crypto-coprocessor implemented as a reconfigurable array of

Processing-Elements and switch-boxes (FPGA),

Figure 25 shows a single processing element of the exemplary crypto-coprocessor,

Figure 26 exemplifies the operation of a switch-box interconnecting processing element,

Figure 27 shows an exemplary tamper-protected semiconductor module provided with a cocoon

PUF as chip carrier and/or housing, also known as a chip container or chip package,

Figure 28 shows an exemplary embodiment of a hardware module containing sensor elements and emitters for an excitation comprised by the tamper-protected semiconductor module of Figure 27,

Figure 29 exemplifies the separation of a secret by a helper data generation function based on the secret and the PUF data provided by a PUF, and

Figure 30 exemplifies the reconstruction of the secret by a secret generation function based on the helper data and the PUF data provided by a PUF,

Figure 31 shows an exemplary trusted bootstrapping model covering the serial chain strategy of a

CASTOR using TRUSTLETs according to an exemplary embodiment of the invention,

Figure 32 shows an exemplary trusted bootstrapping model covering the central chain strategy of a CASTOR using TRUSTLETs according to an exemplary embodiment of the invention, and

Figure 33 shows an exemplary trusted bootstrapping model covering a hybrid form variation strategy of a CASTOR using TRUSTLETs according to an exemplary embodiment of the invention.

1.4 DETAILED DESCRIPTION

In the following different aspects of the invention will be described with respect to various exemplary embodiments that - to the largest extend - will refer to the Digital Cash eCash context, i.e. the transfer of electronic coins between two peer-devices. However, it should be noted that the various aspects of the invention are not limited to a Digital Cash/eCash context, as it will become apparent from the following description. Furthermore, besides the definition of a protocol that allows the transfer of electronic tokens between two peer-devices (also referred to as "off-line transaction protocol" or "teleportation" herein) - which is of course one aspect of this invention - a further idea that may be subject to a separate invention is referred to as an "aspect of the invention" herein. Further aspects of the invention include design aspects of a tamper-protected hardware usable for transferring electronic tokens among two peer-devices, strategies and design aspect to improve resistibility of the tamper- protected hardware against attacks (in general), e.g. by means of a hardware PUF, cocoon PUF, etc., a bootstrapping mechanism using special software modules (also referred to as TRUSTLETs herein) to avoid the execution of manipulated or other party code, the provision of a special format of an electronic document comprising information on the transaction and its state of termination for the purpose of providing proofs, non-repudiation aspects, the grade of commitment and evidence etc. However, the aspects of the invention are not limited by this non-exhaustive list of aspects. Please note that for all cases where certain functionality is provided by some piece of hardware according to one of the various aspects of the invention herein, the invention also envisions protection for methods and systems making use of such piece of hardware.

1.4.1 Terminology

In the following paragraphs the meaning of some terms, frequently occurring in this document, will be defined before describing the various aspects of the invention in further detail.

1.4.1.1 Electronic Tokens

In this document, the term "electronic token" is used to denote an asset, liability, securitization of debt as a principle of an originate-to-distribute model, or secrets that are represented in a digital format, e.g. in form of a digital certificate. With respect to the different embodiments of the off-line transaction method discussed herein, being able to transfer any type of asset, liability, securitization of debt as a principle of an originate-to-distribute model, signature transfers or secrets represented in digital format, the following is only an non-limiting exemplary list of assets, liabilities, securitization of debt as a principle of an originate-to-distribute model or secrets representable by the electronic tokens.

It should be apparent that the "means of exchange" used so far in the described system are financial instruments like Euros (€), Dollars ($), or any other national currency. The invention is however not limited to exchange only electronic tokens of such format (eCoins). As mentioned previously, the electronic tokens may represent anything that can be represented electronically (e.g. in form of a certificate) in the physical or virtual world like provision of services, such as for example a digital representation of money (i.e. coins and bank notes of one or more arbitrary currencies), natural resources or goods e.g.

- metal (e.g. precious metal like platinum, gold, silver, copper), etc.,

- renewable raw materials (e.g. eggs, pigs, cows, corn, rice, wheat), etc.,

- (raw) oil, diamonds, sapphires, rubies, crops, coal, etc., - properties (e.g. parts of accounted dependencies like forestry trees in south America, estates and landholding), etc.,

- services (e.g. (the receipt of) natural gas, petrol, oil, water, electrical power), etc.,

- properties already confirmed by documents (e.g. shares/stocks or rights, tickets (cinema, public transport, sport event, media libraries, eBooks)), etc.,

- licenses and cryptographic key exchanges (e.g. in form of license keys for software applications, decryption keys for streaming multimedia, digital content license for eBooks, music, videos), etc.,

- guarding medical records, soiling certificates (e.g. CO ₂ ), or even as replacements for physical keys as used for doors, cars, office cupboards, etc.

Moreover, it is assumed that the electronic tokens are provided in form of certificates that are issued by an issuing authority. Please note that there may be multiple issuing authorities of electronic tokens in the system, and electronic tokens of different issuing authorities may be the receivable in a transaction. In essence, the asset, liability, securitization of debt as a principle of an originate-to- distribute model or secret subject to a respective electronic token (and the - optional - remaining contents of the electronic token), is signed by the issuing authority.

Each electronic token can be checked and tracked down the chain of trust against the root certificate (also called Type- VI certificate herein) of the Root Certification Authority (RCA) as provided in the underlying hierarchical Public Key Infrastructure (see for example IETF RFC 3280,„Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile", available at http://www.ietf.org or ITU-T X.509, "Information technology - Open systems interconnection - The Directory: Public-key and attribute certificate frameworks", 2008 available at http://www.itu.int). As it will be outlined below, in one exemplary embodiment of the invention, the public key part of the signing key of the Root Certification Authority may be provided immune against counterfeit in the tamper-protected hardware module (e.g. in a ROM or EEPROM, "hardcoded" integrated circuit (IC) or other hardware structure thereof), so that even in case of attacks against the system, a manipulation can be detected by checking a certificate down the chain of trust to the root certificate. Depending on the application of the invention, the Root Certification Authority and the issuing authority may be or may not the same authority.

In one exemplary embodiment, the electronic tokens are unconditionally identified, conditionally anonymous or unconditionally anonymous. In another example, the electronic tokens are atomic.

In some embodiments of the invention, each electronic token has a validity period (i.e. a date and/or time when it will expire). In other embodiments of the invention, an electronic token has both, a validity period and a transferability period (indicated by the date and time of its expiry). The electronic tokens may be transferred freely from one device to any other device (i.e. there may be more than one transfer before an electronic token is cleared) within the transferability period, while expiry of the transferability period the electronic tokens need to be cleared directly with the issuing authority (eMint).

As it will become more apparent from the following, the different embodiments of the off-line transaction protocol described below are capable to transfer electronic tokens between two peer- devices (or more precisely, between two tamper-protected semiconductor modules comprised in the respective peer-devices/hardware or between one tamper-protected semiconductor module and a protected electronic minting issuing service institution/authority).

1.4.1.2 Type of Transfer

Within this document, the definition of the terms "on-line" and "off-line" is tied to the model of how the transaction is done and not to the technical way of transmission. In brief, "off-line" means some given transactions can be performed between two peer-devices directly without requiring any interaction with a (trusted) third party. An "off-line" transaction of electronic tokens thus manages the whole transaction between two peer-devices as peer-to-peer (P2P) relationship process. This means a user of a peer-device can freely pass an the electronic token(s) to another party (another peer-device) without involving a third party. Off-line transfers do not need an external service (e.g. provided by a (trusted) third party acting as a fairness arbiter) to execute the transaction protocol, but the electronic tokens are transferred between two peer-devices.

In contrast, the term "on-line" means the involvement of a (trusted) third party in a given transaction. An "on-line transaction" hence means: There is the need of a (trusted) third party as a service institution (which may be an intermediate clearer) in order to conduct the transaction. Some of the biggest obstacles of an on-line transfer of electronic tokens include the impossibility to transfer the electronic tokens, if the service is down or unreachable and, that an anonymous transfer of electronic tokens is impossible due to the case the service based on the ability to identify one or more transaction partners.

1.4.1.3 Non-repudiation

In general, non-repudiation is not an essential requirement for fair transaction protocols, offering payer and payee dispute-free message transmission. As will be explained in detail below, non-repudiation elements need to be a part of the off-line protocol and are part of the out-of-transaction protocol dispute-resolving-mechanism, that handles the occurrence or non-occurrence of claimed events or actions in order to enable the settlement of disputes after a failed transaction.

Both, the protocol originator, which receives its Non-Repudiation of Receipt (NRR) evidence, and the recipient, which receives his message together with the Non-Repudiation of Origin (NRO) evidence (this process is also called evidence collection during the protocol-run) have that at the end after a correct and complete exchange, or none of them receives any valid evidence. Non-repudiation is composed of four distinct phases: The evidence generation, the transfer and storage of its messages, their verification, and the disputes resolution. Following important non-repudiation services are distinguished (see ISO IEC 13888-3, section Information technology - Security techniques - Non- repudiation - Part 3: Mechanisms using asymmetric techniques; edition 2.0, 2009, p. 14).

Consider for example the following paradigmatic scenario of a transaction between two users, referred to as Alice and Bob. Bob, the merchant, wishes to be able to prove that Alice authorized the electronic transaction in order to ensure Alice will not attempt to deny it later. Bob may also want an assurance that Alice has the funds to pay and an assurance that the money will be transferred to him. In some circumstances both, Alice and Bob may also wish to avoid revealing the fact of the transaction against third parties. Meanwhile, Alice wishes to ensure that unauthorized payments are impossible, so Bob cannot deny having received her payment, and that the fact of transaction is private.

To achieve this, every transaction needs to be permanent. This means no one is able to reverse the transaction and take the money back. Nobody will honor any request to undo the transaction performed by an authorized user. The only way of getting the money back: The recipient has to spend it back to the electronic wallet it originated from. If the payer is uncertain, whether the payee electronic wallet's identification he entered or selected is correct, a direct payee contact for confirmation of the correct electronic wallet identification is the only way. If there is any reason to doubt whether the payee will deliver the goods or services being promised, a trusted third party needs to be engaged to serve as an escrow agent (i.e. the dispute resolution is in not part of the transaction protocol).

NRR and NRO capabilities prevent and or protect the payee and payer against acting suffering dishonest in a transaction against any false denial a particular event or action has taken place and provides trust to the transaction system. In general, NRR and NRO capabilities ensure that an agreed contract cannot be denied later on by any of the involved parties (payer or payee), once the payment has been given or granted from one party to the other. The payer (or the issuing authority) has no technical means to force the recipient to 'undo' the transaction. In the financial world such behavior is known as 'final payment'. It is a must to resolve as many conflicts as possible automatically within the exchange system itself, thus increasing the degree of fairness. This may be very easily achieved for face-to-face agreements; however, for remote transactions it is not. The challenging part of non- repudiation is to hinder one of the implied entities to cheat. To ensure this when Alice sends some information to Bob, neither Alice, nor Bob can deny having participated in partially or entirely in this communication; meaning it can be verified respectively, who the sender and who the recipient were (in fact the parties, which claimed to send or receive the message). In other words: NRO proves data has been sent, and NRR proves it has been received. Without guaranteeing a fair exchange of electronic tokens against a receipt within the transaction protocol, nobody would want to use that system. As it will become more apparent from the following, non-repudiation is supported in the transaction system proposed herein by, explicitly:

- binding payer and payee with evidence objects (electronic document - eDoc) to the transaction,

- blocking potential fraud attempts by trying to repudiate the transaction,

- supporting the legal right system by creating evidence,

- validating evidence referring to the transaction,

assuming a state of mutual distrust for both/all parties involved in a transaction,

- resolving disputes about a transaction by generation of valid irrefutable provable evidence,

realizing a fair exchange of electronic tokens by using an "electronic token for a receipt" paradigm.

1.4.1.4 Delayed-true Fairness and its Implication on Fairness Restoration

In non-electronic, traditional scenarios, fair exchange can be easily achieved by a physical exchange over the counter, or by fixing the terms in a contract, while settling arising disputes at court or real- world notaries. In the digital world, the transaction procedure needs to implement and guarantee fair exchange of electronic tokens.

Consider an exemplary case where Alice wants the transaction to be fully anonymous - not even Bob should know Alice's identity. In this case, however, Bob wants to ensure that Alice remains unable to disavow the obligation to pay. If the transaction is entirely electronic, each of the parties will need a mechanism to ensure the other party will pay what is required. In an ideal fair exchange world, both parties involved in the transaction for conducting a payment either receive each other's electronic tokens (i.e. at the end of the protocol-run both parties have what they want) or nothing (i.e. they are in the same state as before execution of the protocol). An off-line transaction protocol implementing an "electronic token payment for a receipf'-transfer ensures non-repudiability is therefore desirable.

As outlined below in further detail, according to one aspect of the invention, the dispute resolving mechanism (also referred to as fairness reconstruction procedure or mechanism) is not part of the offline transaction protocol for transferring the electronic tokens between the peer-devices, which in turn implies that the termination of the off-line transaction protocol in an unfair state to one or both parties (originator and recipient) of a transaction is possible. The non-repudiation property is important for the dispute resolving mechanism, which is independent from the off-line transaction protocol. The dispute resolving mechanism is an on-line or off-line procedure which "recreates" fairness to both parties of the transaction. As fairness for the parties to a transaction is established after termination of the offline transaction protocol between the peer-devices (i.e. upon the protocol-run of the off-line transaction protocol having ended), the delayed-true fairness is achieved. To ensure non-repudiation, the off-line transaction protocol provides the parties of the transaction with valid irrefutable evidence after completion of the protocol without giving a party an advantage over the other at any stage of the off-line transaction protocol-run.

Considering the exemplary case in which a recipient sent a reply to provide the originator of a transaction with sufficient evidence of receipt, there are two possible reasons such reply doesn't arrive at the originator:

- the reply has been sent, however, hasn't been delivered for some reasons or

- the peer-device of the recipient doesn't follow the given off-line transaction protocol intentionally or accidentally.

From the originator's perspective these two situations are indistinguishable. The recipient may repudiate the receipt of a message even if it was received by untruly claiming a communication channel failure.

The off-line transaction protocol (being one of the various aspects of the invention) discussed below in further detail acts optimistically in terms of allowing the exchange of electronic tokens without involving a (trusted) third party (as a fairness arbiter) unless one of the parties behaves unfairly (i.e. by interrupting the transaction protocol), or the communication channel breaks down (e.g. due to temporary system failure involving either process, network node, communication, etc.). Both cases may produce potentially an unfair situation upon termination of the off-line transaction protocol. The basic procedure is as follows:

1. Two parties, Alice (the originator) and Bob (the recipient), want to enter into a mutual transaction of electronic tokens. This involves the pairing of Alice's and Bob's peer-devices.

2. Both parties negotiate the terms for exchanging the electronic tokens using their peer-devices.

Once they agree on the negotiated terms, the exchange of the agreed electronic tokens takes place by transferring each electronic token through the established peer-to-peer link.

3. Evidence is collected during the execution of the off-line transaction protocol in form of an electronic document (also denoted eDoc herein). This eDoc is a message object of the off-line transaction protocol messages exchanged between Alice and Bob, and can be used to resolve postponed disputes. The electronic tokens are mutually exchanged (e.g. payment and change money), the payer gets his receipt as well as both receive their non-repudiation tokens to ensure non-repudiability of the transaction.

4. After each party has received the respective electronic tokens, they check for a match against the previous promises. . The off-line transaction protocol either ends successfully, i.e. the negotiated electronic tokens have been exchanged successfully or un-successfully, i.e. an interruption/failure of the off-line transaction protocol (e.g. due to a broken channel between the peer-devices) occurred.

6. In case of any interruption failure occurs or any party misbehaves, fairness is restored as follows:

"No loss of fairness happened. Then there is no need for a fairness recreation procedure": An automatic local termination of the off-line transaction protocol is performed by the tamper- protected semiconductor module (executing the off-line transaction protocol and controlling the electronic tokens). In cases such evidence is available at the respective tamper-protected semiconductor module, it is sufficient to unambiguously allow both tamper-protected semiconductor modules to independently decide either "deal" or "no-deal", i.e. the transaction is regarded to be either successful or un-successful. In such case no third party will or has to be involved.

"Need for a fairness recreation procedure": In rare cases, the interruption/failure is not recoverable with the local evidence available to the two involved tamper-protected semiconductor modules. In these cases, according to the heuristic policy "no profit from any failure" the affected electronic tokens (subject to the transaction) will be "annihilated" at the tamper-protected semiconductor modules (where needed). For compensation, an acceptable proof (affidavit) for an external fairness arbiter is created, which may be used for (auto-) resolving the dispute on-line after termination of the off-line transaction protocol assuming there is (then) a reliable communication channel between the external arbiter and each party to the transaction available.

To emphasize the fact of separation once again, the potential dispute resolution is not a part of the offline transaction protocol. For this reason the overall transaction system proposed herein provides a "delayed" but "optimistic" fair exchange of electronic tokens.

1.4.1.5 Signing and Certificates A digital cryptographic signature is based on a mathematical scheme to demonstrate and provide the authenticity of a digital message or document by a proof. A valid digital signature (digital signature schemes herein are based upon cryptographic principles) makes a recipient believe the message has been created by a known sender, and it hasn't altered during transition. Digital signatures are commonly used for software distribution, financial transactions, and in other cases where it is important to detect forgery or tampering. They employ a type of asymmetric cryptography. For messages sent through a non-secure channel, a properly implemented digital signature gives the receiver reason to believe the message was sent by the claimed sender. Digital signatures can also provide non-repudiation, meaning that the signer cannot successfully claim they did not sign a message, while also claiming their private key remains secret; further, some non-repudiation schemes offer a time stamp for the digital signature, so that even if the private key is exposed, the signature is valid nonetheless.

Digitally signed messages may contain anything representable by a bit-string: Examples include keys, electronic tokens, electronic mails, contracts, or messages sent by the presented off-line transaction protocol. A signature can be applied to a bit-string (representing the data record/message to be signed) by using a hash function to calculate a hash value of the bit-string and to encrypt the hash value using a private signing key of the signing party. The encrypted hash value forms the so-called signature of the bit-string. Authenticity of the bit-string can be verified by a party by freshly calculating the hash value of the bit-string using the same hash function as used in signing the bit-string, and comparing the freshly generated hash value with the decrypted hash value of the signature - if the hash values match each other, the bit-string has not been altered. For decryption of the encrypted hash value (i.e. the signature), the counterpart public key of the private signing key of the signing party is used. This public key may be for example provided by a public key certificate (see below).

In the simplest form, a message and its signature is also called a "certificate". An electronic token that is implemented as a certificate thus contains at minimum a data record of the electronic token and a signature applied on the data record by the issuing authority. In another embodiment, the electronic tokens are provided in form of ITU-T X.509-compliant (version 3) certificates. For example, considering an eCash system, an eCoin can be considered to comprise a data record containing at least the value of the eCoin and a serial number thereof, and optionally currency information. The eCoin is provided in form of a certificate, i.e. contains the data record signed by the issuing authority.

In cryptography, a public key certificate (also known as a digital certificate or identity certificate) is an electronic document which uses a digital signature to bind a public key with a data record. In most cases this data record contains identity information such as the name of a person or an organization, their address, etc. These data records conclude not only information about a Root Certification Authority (RCA) and Certification Authorities (CAs) based on the ITU-T X.509 (version 3) PKI trust standard, but also about electronic mints (eMints), tamper-protected semiconductor modules (CASTORs / eWallets), electronic tokens (such as for example eCoins), acknowledge tickets, challenges and responses, eDocs and other system-related objects.

The public key certificate can be used to verify that a public key belongs to an entity (e.g. an individual, an organization or a tamper-protected semiconductor module). The digital signature(s) on a certificate are attestations by the certificate signer that the data record information and the public key belong together.

1.4.2 Summary of the Off-line Transaction Protocol - Teleportation

As mentioned above, one of the aspects of the invention is to suggest a protocol that is capable of transferring electronic tokens between two peer-devices using a peer-to-peer link. The transfer of the electronic tokens is thereby not requiring inter-action with a (trusted) third party as a fairness arbiter, so that this transfer is realized "off-line". Accordingly, this protocol is also referred to as off-line transaction protocol herein. As it will become apparent from the following more detailed description of the off-line transaction protocol, same is not necessarily establishing fairness of the transaction within the off-line protocol.

In case of a successful transfer of the electronic tokens between the two peer-devices, i.e. terminating the off-line transaction protocol without interruption or another error, the off-line transaction protocol is fair to both parties to the transaction. However, in case of an interruption of the off-line transaction protocol (e.g. due to a break of the channel of the peer-to-peer link, incompatibility of the change electronic token type, expiry of certificates, or other sources of errors), the off-line transaction protocol may be terminated in an unfair state with the possibility to prove the loss of electronic tokens in a later (on-line) compensation procedure establishing de-facto delayed fairness to the parties of the transaction.

It can be expected that the vast majority of the transactions using the off-line transaction protocol are terminated successfully and a third party is never required in these cases. As it will become also more apparent from the following, also in case of an interruption of the off-line transaction protocol the number of "states" in which the off-line transaction protocol is terminated in an unfair state can be minimized by smart protocol design. Hence, besides limiting the "need" for a third party only to a separate (on-line or off-line) fairness reconstruction procedure, also the frequency of the "need" of an on-line fairness arbiter (trusted third party) for dispute resolution is minimized. The separation of the fairness reconstruction from the transaction protocol for transferring the electronic tokens enables de- facto off-line transactions between two peer-devices via a peer-to-peer link, and allows ensuring delayed fairness to the transaction by means of a separate (on-line or off-line) fairness reconstruction procedure for dispute resolution.

Accordingly, one embodiment of the invention is related to method for transferring electronic tokens between two tamper-protected semiconductor modules (which may be part of respective peer-devices). The method executes an off-line transaction protocol that is controlling the exchange of protocol messages between the two tamper-protected semiconductor modules including a transfer of electronic tokens between the tamper-protected semiconductor modules via a peer-to-peer link, wherein the off- line transaction protocol further enables delayed-true fairness.

In a more detailed exemplary embodiment of the invention, in case of an interruption of the off-line transaction protocol, each tamper-protected semiconductor module autonomously terminates the offline transaction protocol in either

- a fair state in which the transfer of the electronic tokens is either successfully completed or the initial state prior to starting the transaction is restored, or in an unfair state for the respective tamper-protected semiconductor module in which one or more electronic tokens is/are irrevocably lost at the respective tamper-protected semiconductor module.

In case the off-line transaction protocol terminates in an unfair state is possible in a respective tamper- protected semiconductor module, the transaction protocol enables delayed-true fairness by providing a proof of loss of the one of more electronic tokens by the respective tamper-protected semiconductor module vis-a-vis a third party. In one example, the third party is the issuing authority that issued the lost one of more electronic tokens.

As indicated above, after termination of the off-line transaction protocol, the tamper-protected semiconductor module(s) encountering a loss of electronic tokens may perform a separate on-line compensation procedure with a third party (e.g. an issuing authority). In this on-line compensation procedure, the tamper-protected semiconductor module encountering the loss of one or more electronic tokens can prove its loss of one or more electronic tokens to the third party (e.g. issuing authority) using the proof of loss and receives a compensation of the lost electronic token(s) from the issuing authority. Please note that the compensation procedure may also be performed off-line, depending on the target scenario where the invention is used.

In another exemplary embodiment of the invention, the compensation procedure is being based on generatability of electronic tokens by the issuing authority or on the ability to compensate in form of a fiat money account transfer (in case of financial compensation using bank accounts).

In a further embodiment of the invention, the off-line transaction protocol will be executed in the tamper-protected semiconductor modules, respectively. Moreover, the proof of loss may be signed by the tamper-protected semiconductor module using a signing key of the tamper-protected semiconductor module.

In another embodiment of the invention, the off-line transfer protocol is of fail-stop type. A protocol is of fail-stop type if, whenever a critical issue is detected, all causally follow-up messages in the next step or later are not sent, i.e. the protocol will be halted (interrupted) and terminated. This means that timers are used to control timeliness of message exchange in the off-line transaction protocol. In case one of the tamper-protected semiconductor modules does not receive the next protocol message within the time period prescribed by a timer, the tamper-protected semiconductor module interrupts the offline transaction protocol and terminates the off-line transaction protocol in a fair or unfair state as described above. Since the tamper-protected semiconductor module will thus not send any further protocol messages to the other tamper-protected semiconductor module during this session, the other tamper-protected semiconductor module will also time-out and terminate the off-line transaction protocol either in a fair or an unfair state as described above. Hence, termination of the transaction protocol may also be performed by the respective tamper-protected semiconductor module in response to a timeout. The following paragraphs will discuss some special cases for an interruption of the off-line transaction protocol, and their handling in a post-transaction protocol termination process in further detail. It should be noticed that electronic tokens successfully sent by a peer-device/ tamper-protected hardware module (but maybe not successfully received by the other peer-device/ tamper-protected hardware module) are automatically irrevocably destroyed by the transmitting peer device/tamper-protected hardware module. The procedure for handling interruptions that results in situations where the respective local knowledge of the tamper-protected semiconductor modules on the transaction is insufficient to allow both tamper-protected semiconductor modules to conclude on the success or failure of the transaction (in a manner that both tamper-protected semiconductor modules come to the same result) exemplarily referred to as a "weak deal" phase of the off-line transaction protocol (i.e. the "weak deal" phase is also off-line). All other situations where the local knowledge is sufficient to allow both tamper-protected semiconductor modules to conclude on the success or failure of the transaction can arise may lead to an immediate termination of the off-line transaction protocol without any "weak deal" phase being executed.

As will become apparent from the following exemplary situations that may arise and that are handled on the "weak deal" phase of the off-line transaction protocol, the "weak deal" phase of the off-line transaction protocol mainly consists of the two tamper-protected semiconductor modules trying to re- contact each other in a (configurable or negotiable) lock timeout period in order to come to either a successful termination of the transaction ("weak-deal" "deal") or unsuccessful termination of the transaction ("weak-deal" - "no deal"). According to whether there is a deal or no deal for the respective tamper-protected semiconductor modules the take respective actions to avoid misuse of the transaction system, such as for example destroying electronic tokens, generating a proof of loss where applicable, etc.

In one exemplary situation (as exemplified, for example, in states IDs 07a, 08a, 06b, 07b in Figures 14 and 15, respectively), the off-line transaction protocol is terminated after one of the tamper protected semiconductor modules ("payer") has transferred its electronic tokens without having received the expected response from the other tamper protected hardware module ("payee"). In this situation, the tamper-protected semiconductor module ("payer") lacking the expected response, terminates the offline transaction protocol immediately in a final, but however unfair state, in which the transferred electronic tokens are irrevocably destroyed and provides a proof of loss for the irrevocably destroyed electronic tokens.

The other tamper-protected semiconductor module ("payee") terminates the off-line transaction protocol immediately in a final and fair state, in case the other tamper-protected semiconductor module ("payee") has not received the transferred electronic tokens.

Otherwise, i.e. in case the other tamper-protected semiconductor module ("payee") has successfully received the transferred electronic tokens (and nothing else thereafter), it terminates the off-line transaction protocol after expiry of a previously defined lock timeout period in a final but unfair state in which the other tamper-protected semiconductor module ("payee") has irrevocably destroyed the received electronic tokens and provides a proof of loss, in case the other tamper-protected semiconductor module ("payee") has transferred change electronic tokens to the tamper-protected semiconductor module ("payer") in response to its reception of the other tamper-protected semiconductor module's ("payee's") electronic tokens.

Another exemplary special situation (see, for example, states IDs 08a, 09a, 07b and 08b in Figures 14 and 15, respectively) is a situation where the off-line transaction protocol is terminated after one of the tamper-protected semiconductor modules ("payer") has transferred its electronic tokens to the other tamper-protected semiconductor module ("payee"). It is further assumed that the other tamper- protected semiconductor module ("payee") successfully received the electronic tokens and returned a confirmation of receipt for the transferred electronic tokens and, optionally, change electronic tokens, but the other tamper-protected semiconductor module ("payee") did not receive the expected response to its confirmation of receipt for the transferred electronic tokens and, optionally, change electronic tokens form the tamper-protected semiconductor modules ("payer"), as exemplified, for example, in states IDs 07b and 08a in Figures 14 and 15, respectively.

In this situation, the tamper-protected semiconductor module ("payer") terminates the off-line transaction protocol immediately in a final but unfair state, in which its transferred electronic tokens are irrevocably destroyed, and a proof of loss for the irrevocably destroyed electronic tokens is provided by the tamper protected hardware module ("payer"), in case it has not received the other tamper-protected semiconductor module's ("payee's") confirmation of receipt for the transferred electronic tokens and the optional change electronic tokens.

Otherwise, as exemplified, for example, in states IDs 09a and 08b in Figures 14 and 15, respectively in case the tamper-protected semiconductor module ("payer") has received the other tamper-protected semiconductor module's ("payee's") confirmation of receipt for the transferred electronic tokens and the optional change electronic tokens, the tamper protected hardware module ("payer") terminates the off-line transaction protocol in a final and fair state or in a final and unfair state. The off-line transaction protocol is terminated in a final and fair state in case both tamper-protected semiconductor modules re-contact each other and finish the transaction within a previously defined lock timeout period successfully. Otherwise, the tamper-protected semiconductor module ("payer"), which has transferred its electronic tokens to the other tamper-protected semiconductor module ("payee"), terminates the off-line transaction protocol in a final but unfair state after expiry of the previously defined lock timeout period, in which the tamper-protected semiconductor module ("payer") produces a proof of loss for the value of the electronic tokens already transferred to the other tamper-protected semiconductor module ("payee") and irrevocably destroys the electronic change tokens received from the other tamper-protected semiconductor module ("payee"). The other tamper-protected semiconductor module ("payee"), which did not receive the expected response to its confirmation of receipt for the transferred change electronic tokens terminates the offline transaction protocol after expiry of a previously defined lock timeout period in a final but unfair state, in case the tamper-protected semiconductor modules fail to re-contact each other within the previously defined lock timeout period successfully: The other tamper-protected semiconductor module ("payee") irrevocably destroys the previously received electronic tokens and provides a proof of loss for the previously sent change electronic tokens, in case the other tamper-protected semiconductor module ("payee") has transferred change electronic tokens to the tamper-protected semiconductor module ("payer") in response to having received the electronic tokens from the tamper- protected semiconductor module ("payer").

In case the tamper-protected semiconductor modules are able to re-contact each other and finish the transaction within a previously defined lock timeout period successfully, the other tamper-protected semiconductor module ("payee") terminates the off-line transaction protocol in a final and fair state.

A further exemplary special situation (see, for example, states IDs 09a, 10a, 08b and 09b in Figures 14 and 15, respectively) is a situation where the off-line transaction protocol is terminated after one of the tamper-protected semiconductor modules ("payer") having transferred its electronic tokens to the other tamper-protected semiconductor module ("payee"). Further the tamper-protected semiconductor module ("payer") received a confirmation of receipt for the transferred electronic tokens and, optionally, change electronic tokens from the other tamper-protected semiconductor module ("payee"), but the the tamper-protected semiconductor module ("payee") did not receive the expected response to a further confirmation message transmitted from the the tamper-protected semiconductor module ("payer") to the other tamper-protected semiconductor module ("payee") for confirming the confirmation of receipt for the transferred electronic tokens and, optionally, change electronic tokens.

In this situation, the tamper-protected semiconductor module ("payer") having transferred its electronic tokens to the other tamper-protected semiconductor module ("payee") terminates the offline transaction protocol in a final and fair state, in case the tamper-protected semiconductor modules re-contact each other and successfully finish the transaction within a lock timeout period. Otherwise, the the tamper-protected semiconductor module ("payer") terminates the off-line transaction protocol in a final but unfair state after expiry of the lock timeout period, in which the tamper-protected semiconductor module produces a proof of loss for the value of the electronic tokens transferred to the other tamper-protected semiconductor module and irrevocably destroyed the change electronic tokens received from the other tamper-protected semiconductor module.

The other tamper-protected semiconductor module ("payee") terminates the off-line transaction protocol in a final and fair state or a final and unfair state, in case the other tamper-protected hardware module has not received the conformation message confirming the confirmation of receipt for the transferred electronic tokens and, optionally, change electronic tokens,. The off-line transaction protocol is terminated by the other tamper-protected semiconductor module ("payee") in a final and fair state, in case the tamper-protected semiconductor modules re-contact each other and successfully finish the transaction within a lock timeout period. Otherwise other tamper-protected semiconductor module ("payee") terminates the off-line transaction protocol in a final but unfair state after expiry of the lock timeout period, in which the other tamper-protected semiconductor module ("payee") produces a proof of loss for the value of the change electronic tokens (if any) and irrevocably destroys the electronic tokens received from the tamper-protected semiconductor module ("payer").

In case the other tamper-protected hardware module ("payee") has received the conformation message confirming the confirmation of receipt for the transferred electronic tokens and, optionally, change electronic tokens, the other tamper-protected hardware module ("payee") terminates the off-line transaction protocol in a final and fair state in which the transaction is considered successful by the other tamper-protected hardware module ("payee").

For the case that the other tamper-protected hardware module ("payee") considers the transaction successful, but the tamper-protected hardware module ("payer") terminates the off-line transaction protocol in a final but unfair state after expiry of the lock timeout period, in which the tamper- protected semiconductor module produces a proof of loss for the value of the electronic tokens transferred to the other tamper-protected semiconductor module and irrevocably destroyed the change electronic tokens received from the other tamper-protected semiconductor module, the tamper- protected hardware module ("payer") may obtain a reimbursement of the value of the electronic tokens transferred to the other tamper-protected semiconductor module ("payee") from the issuing authority against the proof of loss and revealing the user's identity (i.e. the identify of the user of the tamper- protected hardware module ("payer")). This reimbursement of "lost" electronic tokens against a proof of loss may be for example follow the principle "in dubio mitius". Furthermore, in a more detailed exemplary embodiment, a fraud can be detected by the issuing authority recognizing that the electronic tokens claimed to be lost by the tamper-protected hardware module ("payer") - and having been reimbursed - are cleared by another party, e.g. the other tamper-protected semiconductor module ("payee") or another tamper-protected semiconductor module.

The following enumeration exemplary lists conditions in which - besides timeouts - a fail-stop of the off-line transaction protocol is caused by one of the tamper-protected semiconductor modules:

- The storage capacity of a token memory in the respective tamper-protected semiconductor module has reached its limit (no more free space),

the tamper-protected semiconductor modules cannot agree on any supported denomination distribution of electronic tokens for the transaction in the Negotiation Phase of the off-line transaction protocol,

- the electronic tokens stored in the respective tamper-protected hardware do not allow for fulfilling a receivable of the transaction (no more transferability), the type(s) of electronic token(s) to be exchanged is incompatible within the intended transaction, authentication of one or more electronic token(s) subject to the transfer fails at the respective tamper-protected semiconductor module,

checking validity of a certificate by the respective tamper-protected semiconductor module fails due to the certificate being unauthenticated, outdated, or blacklisted in a Certificate Revocation

List (CRL) signed by a Root Certification Authority, and

an incompatibility in rules to be enforced by the tamper-protected semiconductor modules exists, wherein the incompatibility in the rules consists of an incompatibility between the rules to be enforced as defined by the users, by Capability Flag Vectors (CFVs) of the tamper-protected semiconductor modules, by a regulation authority, or a transaction limit of a the tamper-protected semiconductor module.

Furthermore, in one exemplary embodiment, one of the tamper-protected semiconductor modules is owned by the electronic tokens issuing authority. This may be e.g. advantageous in cases where the electronic tokens represent electronic coins (eCash). In this scenario the tamper-protected semiconductor modules may also be owned by a bank (in which the user can be a customer). In this context, the off-line transaction protocol may be used to withdraw or deposit electronic coins from at the bank/issuing authority. As the bank issuing authority has to deal with a huge number of concurrent withdrawals and deposits simultaneously (i.e. there is a high number of parallel executions of the offline transaction protocol, concurrency criteria) it may be advantageous to implement (parts of) the tamper-protected semiconductor module of the bank/issuing authority in software.

1.4.2.1 Summary of the Pairing Phase

Exemplarily, the off-line transaction protocol may be considered to consist of different protocol phases. Please note that the invention is not limited to the following description of protocol phases. Nevertheless they are merely exemplarily used to explain the structure of the off-line transaction protocol.

For example, the off-line transaction protocol may start with a Pairing Phase to pair the two tamper- protected semiconductor modules for a single execution of the off-line transaction protocol. The Pairing Phase may comprise a mutual exchange of certificates, which respectively identify the tamper- protected semiconductor module. The certificates exchanged may, for example, comprise a respective public key of the respective tamper-protected semiconductor module's public key-pair.

Each tamper-protected semiconductor module confirms the validity of the respective other tamper- protected semiconductor module's certificate. If the validity is not confirmed it will interrupt the transaction protocol prior to the transfer of any electronic token. Please note that it is assumed that all certificates are checked by traversing the chain of trust down to the root certificate of the Root Certification Authority, and that the validity will not be confirmed if one single check within the chain of trust is not affirmative. In one exemplary embodiment, checking the validity of the certificate of the respective other tamper- protected semiconductor module also comprises checking whether an identifying descriptor item of the certificate is contained in a Certificate Revocation List of revoked certificates of tamper-protected semiconductor modules. If yes, the transaction protocol is interrupted prior to the transfer of any electronic tokens. The descriptor item of the certificate may be for example a unique identification of the respective tamper-protected semiconductor module, such as a serial number or a public key specific to the tamper-protected semiconductor module comprised in the certificate.

During the Pairing Phase the tamper-protected semiconductor modules "detect" the respective other transaction partner. This may include the exchange of a set of transaction protocol messages as prescribed by the off-line transaction protocol. One of the transaction protocol message transmitted by a respective one of the tamper-protected semiconductor modules during the Pairing Phase comprises at least one of:

a certificate identifying the respective tamper-protected semiconductor module, the certificate including the public key of the respective tamper-protected semiconductor module used by the off- line transaction protocol between the tamper-protected semiconductor modules,

a device identifier and/or network identifier of a peer-device describing a particular one of the two tamper-protected semiconductor modules for addressing subsequent transaction protocol messages to be exchanged between the two tamper-protected semiconductor modules,

one or more Capability Flag Vectors (CFVs) which identifies the cryptographic schemes supported by the respective tamper-protected semiconductor module, usable according to crypto- regulations and user definable restrictions (e.g. a lowermost mandatory minimum security level) applying to the transfer of the electronic tokens,

a timestamp indicating the point in time of the generation or transmission of the respective transaction protocol message,

- a random number for establishing a transaction identifier during a Secure Connection Setup Phase of the transaction protocol,

a signature to ensure integrity of the contents of the respective transaction protocol message, wherein the signature is obtained using a signing key of the respective tamper-protected semiconductor module transmitting the respective transaction protocol message, and

- a voucher in form of an affidavit usable for the compensation claim against the issuing authority.

In one exemplary embodiment of the invention, there may be multiple Capability Flag Vectors of the respective tamper-protected semiconductor module that describe for example the (crypto-) capabilities of the hardware of the respective tamper-protected semiconductor module, the (crypto-) capabilities supported by the firmware running on the respective tamper-protected semiconductor module. The (crypto-) capabilities reflect whether the user will allow or deny negotiated facts of the off-line transaction running on the respective tamper-protected semiconductor module (i.e. preventing off-line transactions under a defined minimum of (crypto-) protection strength), and (crypto-) capabilities allowed to be used the by local regulation (i.e. crypto-regulations applying to the transfer of the electronic tokens).

Advantageously, each respective tamper-protected semiconductor module compiles a Capability Flag Vector based on a combination (e.g. by applying a simple AND function to the bitwise fact mattering encoded vectors) of its Capability Flag Vectors and sends the result to the respective other tamper- protected semiconductor module. Based on the local Capability Flag Vectors and the one received from the respective other tamper-protected semiconductor module, each tamper-protected semiconductor module can determine the effective (crypto-) capabilities to be applied to the transaction by combining (e.g. applying a simple AND function to the vectors) of the Capability Flag Vectors. In one exemplary implementation the Capability Flag Vector (CFV) indicating the (crypto-) capabilities of the hardware of the respective tamper-protected semiconductor module may be comprised in the root certificate (Type-VI) of the Root Certification Authority.

Please note that in case the exchanged Capability Flag Vectors indicate a non-resolvable incompatibility between the tamper-protected semiconductor modules, no electronic tokens may be transferred and the off-line transaction protocol is terminated by the tamper-protected semiconductor module. A termination at this early stage of the off-line transaction protocol will typically resolve into a fair state, as none of the tamper-protected semiconductor module has transferred any electronic token yet.

Furthermore, in another exemplary embodiment of the invention, the transaction protocol messages of the Pairing Phase are exchanged by the tamper-protected semiconductor modules using an initial wired or wireless access technology, while the transaction protocol messages of the off-line transaction protocol not being part of the Pairing Phase are exchanged between the tamper-protected semiconductor modules using another (second) wired or wireless access technology. This may be for example advantageous in cases where the initial wired or wireless access technology is offering advantages for the physical pairing process, but is providing an undesirably low or insufficient bandwidth for the payload transfer. The second access technology may differ from the first access technology and may advantageously provide a higher (sufficient) bandwidth for payload transfer. Hence, it may be possible to pair the peer-devices (comprising the tamper-protected semiconductor modules) using an initial first access technology (e.g. Radio Frequency IDentification (RFID) or another Near Field Communication (NFC) technology), while the remaining phases of the off-line transaction protocol will be executed through another channel, i.e. using a different access technology, e.g. Bluetooth, WLAN, cellular radio, etc. 1.4.2.2 Summary of the Secure Connection Establishment Phase (also: VPN/VPC Setup)

Following the Pairing Phase, the off-line transaction protocol could further comprise a Secure Connection Establishment Phase. In this phase the tamper-protected semiconductor modules may establish a secure tunnel/channel through the peer-to-peer link. For example, this phase may set up a virtual private network/channel (VPN, VPC) between the two tamper-protected semiconductor modules. Please note that the Secure Connection Establishment Phase is optional, and there may be applications of the invention, in which no secure connection for transferring the electronic tokens is required, desired, or allowed by regulation. The Secure Connection Establishment Phase may be used to establish cryptographic parameters in the tamper-protected semiconductor modules to encrypt and sign the (further) transaction protocol messages to be exchanged between the two tamper-protected semiconductor modules.

To encrypt and sign the transaction protocol messages, the tamper-protected semiconductor modules may use different session keys. A key establishment scheme may be used to generate (different) session keys for encryption and signing of the transaction protocol messages in the Secure Connection Establishment Phase. Optionally, session keys used solely for encrypting the electronic tokens exchanged between the tamper-protected semiconductor modules may be generated in this course as well.

In one embodiment of the invention, the validity of the session keys is limited to one session. Hence, the session keys may be generated by the tamper-protected semiconductor module for each execution of the off-line transaction protocol. The transaction protocol messages, following the Secure Connection Establishment Phase, may thus be encrypted and signed by the tamper-protected semiconductor modules using the session keys established for the given execution of the off-line transaction protocol.

In one embodiment of the invention, the encryption function VPN VPC may be disabled, for example manually by the user or due to regulations. In case the encryption function of the VPN/VPC is disabled, the protocol messages exchanged between the tamper-protected semiconductor modules are still signed by the sending tamper-protected semiconductor module to allow the other tamper- protected semiconductor module to verify integrity of the message contents. The tamper-protected semiconductor modules may use respective session keys to sign the messages.

Furthermore, the tamper-protected semiconductor modules may each use different key-pairs for signing (firstly) the contents of transaction protocol messages and encrypting (secondly) the contents of transaction protocol messages prior to transmission to the respective other tamper-protected semiconductor module.

Session keys may be symmetric, but asymmetric keys could be used also as session keys. Furthermore, session keys may be for example generated by local instances (i.e. by the tamper-protected semiconductor modules) end-to-end and not externally (as for example in SKYPE or EC/Credit Cards due to penurious local resources or due to other reasons). This way, privacy of the transaction partners may be achieved. In another exemplary embodiment, the session keys are always generated within a key generation process that is part of the off-line transaction protocol.

The session keys may for example be generated by using mechanisms like discrete logarithm cryptography (DLC)- based key establishment schemes as, for example, the full unified modified Diffie-Hellman hybrid scheme (as used within the Elliptic Curve Diffie-Hellman, ECDH or Elliptic Curve Signature Algorithm, ECDSA) with two ephemeral keys and two static keys which are using Elliptic Curve Cryptography (ECC) and a Cofactor Diffie-Hellman (CDH) primitive, or as the full unified (Cofactor) Menezes-Qu-Vanstone hybrid scheme (as used within the Elliptic Curve Menezes- Qu-Vanstone, ECMQV) with two ephemeral keys and two static keys which are using Elliptic Curve Cryptography (ECC) and a Menezes-Qu-Vanstone (MQV) primitive. In one exemplary embodiment, the parameters of the session key generation mechanism are provided in a tamper-protected semiconductor module-specific certificate (e.g. the Type- VI certificate outlined below) so that so- called "Man In The Middle Attacks" (MITMA) can be ruled out.

Moreover, in case one of the tamper-protected semiconductor modules determines upon confirming validity of the certificate of the respective other tamper-protected semiconductor module the identifying descriptor item of the certificate is contained in a Certificate Revocation List (CRL) of revoked certificates of tamper-protected semiconductor modules, the tamper-protected semiconductor module informs the respective other tamper-protected semiconductor module its certificate having been revoked within a transaction protocol message. The respective other tamper-protected semiconductor module disables itself in response to the reception of the transaction protocol message which indicates the respective other tamper-protected semiconductor module's certificate is revoked. Revocation of certificates in the transaction system may be implemented by a (e.g. viral) distribution of Certificate Revocation Lists (CRLs).

Disabling the tamper-protected semiconductor module means the module is making itself unavailable permanently or temporarily for any further transactions. For example, this could mean that the tamper- protected semiconductor module is destroying (e.g. burning) some die area or circuit path(s) so it becomes permanently dysfunctional or clear stored secrets required for functionality. Alternatively, the firmware of the tamper-protected semiconductor module could prevent any further transactions being executed temporarily until the tamper-protected semiconductor module is unlocked again, either in an on-line procedure with a trusted party (e.g. the Root Certification Authority) or the tamper- protected semiconductor module (respectively, the device containing same) may be unlocked (physically) directly at a trusted party (e.g. the Root Certification Authority). Please note there may be manifold possibilities how to permanently or temporarily (by firmware) disable the tamper-protected semiconductor module, and also manifold mechanisms may be employed to enable the tamper- protected semiconductor module for transactions again, after the firmware temporarily disabling same. In a further exemplary embodiment, the firmware of the tamper-protected semiconductor module may not immediately interrupt execution of the off-line transaction protocol upon determining the other tamper-protected semiconductor module is listed in a Certificate Revocation List, but the off-line transaction protocol is continued until the end of a Negotiation Phase of the off-line transaction protocol, and thereupon the off-line transaction protocol is interrupted. This may be particularly useful in implementations in which - as part of the Negotiation Phase - the tamper-protected semiconductor modules exchange their Certificate Revocation Lists. By continuing the off-line transaction protocol the "corrupted" tamper-protected semiconductor module may be updated by the other tamper- protected semiconductor module with the Certificate Revocation List of revoked certificates of tamper-protected semiconductor modules (including the "corrupted" tamper-protected semiconductor module) and may thereby learn its tamper-protected semiconductor module certificate has been revoked or the revocation has been resolved. Accordingly, the update of the Certificate Revocation List will then cause the "corrupted" tamper-protected semiconductor module to disable (or (re)enable) itself, as outlined above.

According to another embodiment of the invention, the first transaction protocol message of the Secure Connection Establishment Phase comprises a running message counter incremented in each subsequent message of the off-line transaction protocol exchanged between the tamper-protected semiconductor modules. Moreover, a tamper-protected semiconductor module interrupts the off-line transaction protocol's execution in response to the detection of an incorrect increment of the running message counter in a received transaction protocol message. The utilization of a running message counter may be one of the measures to immunize the off-line transaction protocol against replay attacks.

Moreover, according to a further embodiment of the invention, the transaction protocol messages exchanged in the Secure Connection Establishment Phase comprise a transaction identifier determined based on random numbers exchanged between the tamper-protected semiconductor modules during the Pairing Phase. This transaction identifier is uniquely identifying the transaction.

Generally, the contents of the transaction protocol messages exchanged between the tamper-protected semiconductor modules in the Pairing Phase and the Secure Connection Establishment Phase may be signed by the respective tamper-protected semiconductor module using their respective signing key. The public key used for verifying the signature by the respective other tamper-protected semiconductor module may be comprised in the certificate received from the other tamper-protected semiconductor module during the Pairing Phase.

Furthermore, timestamps may exist in the transaction protocol messages exchanged in the Pairing Phase and/or Secure Connection Establishment Phase. For example, these timestamps may be used by the respective tamper-protected semiconductor modules to determine channel characteristics of the peer-to-peer link, and the tamper-protected semiconductor modules determine timer values of the timers controlling the timeliness of the off-line transaction protocol messages based on the channel characteristics. This may be especially useful in case the off-line transaction protocol is of fail-stop type: The timers controlling the timeliness of protocol messages may thus be determined on the individual channel characteristics, which is another measure to further immunize the off-line transaction protocol against replay attacks.

1.4.2.3 Summary of the Negotiation Phase

Moreover, the off-line transaction protocol may also comprise a Negotiation Phase. As its name suggests, the Negotiation Phase is inter alia used to negotiate the transaction, e.g. the type and/or number of electronic tokens to be exchanged. Please note the Negotiation Phase may not necessarily negotiate the receivable of the transaction itself, but rather how (e.g. under which conditions) the receivable of the transaction is transferred between the two tamper-protected semiconductor modules. As part of the Negotiation Phase the tamper-protected semiconductor modules may further exchange user certificates of the users of the respective peer-devices comprising a respective one of the two tamper-protected semiconductor modules. Further, as part of the transaction's negotiation the tamper- protected semiconductor modules also negotiate their ability to conduct the transfer of the electronic tokens.

According to another embodiment of the invention, each tamper-protected semiconductor module confirms the user certificate's validity of the other respective tamper-protected semiconductor module and interrupts the transaction protocol prior to the transfer of any electronic tokens if the validity is not confirmed. The confirmation of the user certificate's validity of the respective other tamper-protected semiconductor module may e.g. comprise of checking whether a certificate's identifying descriptor item is contained in a user Certificate Revocation List of revoked user certificates. If this is true the transaction protocol will be interrupted prior to the transfer of any electronic tokens.

In case the tamper-protected semiconductor module determines, upon confirming validity of the user certificate of the respective other tamper-protected semiconductor module, the identifying descriptor item of the user certificate is contained in the user Certificate Revocation List, the tamper-protected semiconductor module may advise the respective other tamper-protected semiconductor module of the user certificate's revocation within a transaction protocol message, whereupon the respective other tamper-protected semiconductor module will disable itself in response to the reception of the transaction protocol message indicating user certificate's revocation. In a more detailed exemplary implementation, in case one of the user certificates has been invalidated (i.e. in the Certificate Revocation List of user certificates), the tamper-protected semiconductor modules may continue to execute the off-line transaction protocol until the end of the Negotiation Phase of the off-line transaction protocol and thereupon interrupt the off-line transaction protocol. Essentially, these steps are similar to the checking of the respective tamper-protected semiconductor module's certificate as described in the Summary of the Secure Connection Establishment Phase (also: VPN VPC Setup). As mentioned also earlier and according to another embodiment of the invention the tamper-protected semiconductor modules exchange Certificate Revocation Lists (e.g. revocation lists of tamper- protected semiconductor module certificates, user certificates, electronic token certificates, issuing authority certificates etc.) and update the respective Certificate Revocation List(s) in the Negotiation Phase based on the Certificate Revocation List received from the respective other tamper-protected semiconductor module.

In an exemplary implementation of a Negotiation Phase of the off-line transaction protocol according to an embodiment of the invention, a first of the two tamper-protected semiconductor modules generates a„Ranked Suggestion List (RSL)" of preferred candidate combinations of atomic electronic tokens stored in the first tamper-protected semiconductor module and respective, optional change preferred candidate combinations of atomic electronic tokens that fulfill a receivable of the transaction, and transmits the„Ranked Suggestion List (RSL)" to the second, other tamper-protected semiconductor module in a transaction protocol message (e.g. as part of the eDoc). Further, the second tamper-protected semiconductor module determines whether one of the preferred candidate combinations of atomic electronic tokens and respective, optional change preferred candidate combinations of atomic electronic tokens out of the„Ranked Suggestion List" can be accepted in view of the atomic electronic tokens available at the second tamper-protected semiconductor module.

If this is the case (or simply optionally) the second tamper-protected semiconductor module may modify or add a counter proposal to the„Ranked Suggestion List", which e.g. contains new preferred candidate combinations of atomic electronic tokens stored in the second tamper-protected semiconductor module, and optional change preferred candidate combinations of atomic electronic tokens that fulfill the receivable of the transaction, respectively. The second tamper-protected semiconductor module transmits a transaction protocol message comprising the optionally modified or counter proposed„Ranked Suggestion List" (e.g. as part of the eDoc) to the first tamper-protected semiconductor module, which in turn selects one of the preferred candidate combinations of atomic electronic tokens and respective, optional change preferred candidate combinations of atomic electronic tokens out of the „Ranked Suggestion List" and informs the other tamper-protected semiconductor module about its selection.

The first tamper-protected semiconductor module then transfers the atomic electronic tokens as indicated by the selected one candidate combination of atomic electronic tokens and respective, optional change combinations of atomic electronic tokens out of the„Ranked Suggestion List" from the first tamper-protected semiconductor module to the second tamper-protected semiconductor module. Please note that the transfer step may be formally considered part of the Electronic Token Transfer Phase of the off-line transaction protocol, as will be discussed in further detail below.

In an alternative exemplary implementation, the first of the two tamper-protected semiconductor modules generates a„Ranked Suggestion List" of candidate combinations of atomic electronic tokens stored in the first tamper-protected semiconductor module and optional, respective change combinations of atomic electronic tokens that fulfill a receivable of the transaction, and transmits the „Ranked Suggestion List" to the second, other tamper-protected semiconductor module in a transaction protocol message.

The second tamper-protected semiconductor module selects one of the preferred candidate combinations of atomic electronic tokens and optional, respective change preferred candidate combinations of atomic electronic tokens out of the„Ranked Suggestion List", informs its partner tamper-protected semiconductor module about its selection and transfers the atomic electronic tokens as indicated by the selected candidate combination of atomic electronic tokens and optional, respective change combination of atomic electronic tokens out of the„Ranked Suggestion List" from the second tamper-protected semiconductor module to the first tamper-protected semiconductor module. Please note that the transfer step may be formally considered part of the Electronic Token Transfer Phase of the off-line transaction protocol, as will be discussed in further detail below.

1.4.2.4 Summary of the Electronic Token Transfer Phase (also: Value Data Transfer) The off-line transaction protocol could further comprise an Electronic Token Transfer Phase following the Negotiation Phase. In this Electronic Token Transfer Phase, the tamper-protected semiconductor modules transfer the electronic tokens as negotiated in the Negotiation Phase.

The transfer of electronic tokens from a first tamper-protected semiconductor module to the second, other tamper-protected semiconductor module may be for example realized by transmitting the transaction protocol message comprising the electronic tokens to the second tamper-protected semiconductor module, and ensuring by the first tamper-protected semiconductor module that electronic tokens are irrevocably destroyed upon successful completion or termination (even in unsuccessful cases) of the off-line transaction protocol once it has been transmitted to the second tamper-protected semiconductor module. This combination of transmission and assured controlled destruction of the electronic tokens once they have been transmitted is also referred to as "teleportation" herein.

Hence, the off-line transaction protocol ensures (or to be more precise, the firmware of the tamper- protected semiconductor modules implementing the off-line transaction protocol) that once an electronic token has been transmitted by a tamper-protected semiconductor module, the electronic token is irrevocably destroyed. This irrevocable destruction of electronic tokens may result in an unfair termination of the off-line transaction protocol in case same is interrupted. However, the controlled irrevocable destruction may be desirable as it is one effective measure to prevent multi- spending of electronic tokens by any party of the transaction, justifying the occasional unfair termination of the off-line transaction protocol and the necessity of a postponed (on-line) compensation procedure with a trusted authority (e.g. the issuing authority). In an exemplary implementation, the transferred electronic tokens are part of the transaction protocol messages' content (i.e. part of the payload) and are separately encrypted by the respective tamper- protected semiconductor module prior to their inclusion in the transaction protocol messages. Hence, even in case no secure connection is used (e.g. since there is no Secure Connection Establishment Phase by design of the off-line transaction protocol or crypto-regulation do not allow for use of an encryption), the electronic tokens may nevertheless be encrypted prior to their transmission. In other words: The encryption of the electronic tokens may be a feature independent from the use of a secure connection on the peer-to-peer link between the tamper-protected semiconductor modules. Optionally, the electronic tokens to be transmitted in a respective transaction protocol message may also be compressed prior to their encryption. For encryption purposes, special session keys generated by the tamper-protected semiconductor modules may be used. Alternatively, the tamper-protected semiconductor modules could also use the respective other tamper-protected semiconductor module's public key portion contained in the certificate of the respective other tamper-protected semiconductor module or the public key portion of the other user certificate of the user of the respective other tamper- protected semiconductor module. Furthermore, the encryption of the electronic tokens may be independent from the settings in the Capability Flag Vectors of the tamper-protected semiconductor modules.

In one exemplary embodiment, the electronic tokens transferred between the tamper-protected semiconductor modules are identified by uniquely identifying descriptor items (e.g. a bit sequence and/or a serial number). The inclusion of a descriptor item to the electronic tokens may for example be used in a verification of the electronic tokens received by a tamper-protected semiconductor module with respect to their validity and/or their compliance with the negotiated receivable of the transaction. As mentioned earlier, the tamper-protected semiconductor modules may indicate the descriptor items (e.g. bit sequence and/or serial numbers) of the electronic tokens to be transferred in the Negotiation Phase and either one or both of the tamper-protected semiconductor modules could check, whether the descriptor items contained in the electronic tokens received from the respective other the tamper- protected semiconductor module matches the descriptor items of the electronic tokens negotiated in the Negotiation Phase.

Optionally and according to a further embodiment of the invention, one of the tamper-protected semiconductor modules or both tamper-protected semiconductor modules could check whether the one or more electronic tokens to be transferred by the respective other tamper-protected semiconductor module are blacklisted in a Certificate Revocation List of revoked electronic tokens prior to proceeding further with an Electronic Token Transfer Phase of the off-line transaction protocol.

Depending on the target application in which the invention is employed, this check for revocation (which may be considered part of a validity check) may be off-line if the Certificate Revocation List is locally available, or on-line with one of more issuing authorities that maintain respective Certificate

Revocation List(s) of their issued electronic tokens. Checking the electronic tokens to be transferred for revocation (or validity in general) could be for example particularly suitable in applications, in which one of the tamper-protected semiconductor modules (is included in a device that) is located at some location having permanent on-line access. For example, a tamper-protected semiconductor module provided at a Point of Sale (PoS) could check the revocation/validity of the electronic tokens to be received from the respective other tamper-protected semiconductor module against a Certificate Revocation List of electronic tokens.

Although this check may be part of the Electronic Token Transfer Phase of the off-line transaction protocol, this check of the electronic tokens could also be realized as part of the Negotiation Phase. However, there may not yet be sufficient information available upon negotiation to check the validity of the electronic tokens, but just enough information to check the revocation of the electronic tokens. For example, if the descriptor items (e.g. bit sequences and/or serial numbers) of the electronic tokens to be transferred in the transaction are exchanged in the Negotiation Phase, they could be checked for revocation against a Certificate Revocation List of electronic tokens.

For a full respectively a complete validity check, however, the electronic token may need to be received first. As part of a validity check of the electronic tokens, either one or both of the tamper- protected semiconductor modules check, whether the respective electronic tokens received from the respective other the tamper-protected semiconductor module match with the promises previously made as part of the Negotiation Phase and have not expired.

1.4.2.5 Summary of the Acknowledgement Phase (also: Confirmation) Further, the off-line transaction protocol may comprise an Acknowledgement Phase following the Electronic Token Transfer Phase, in which the tamper-protected semiconductor modules acknowledge receipts of the electronic tokens transferred in the Electronic Token Transfer Phase. The acknowledgements may be further used for non-repudiation, proof generation, and other things, in particular in case a fairness reconstruction is necessary due to termination of the off-line transaction protocol in an unfair state.

In one exemplary embodiment, the tamper-protected semiconductor module receiving the last transaction protocol message of the Electronic Token Transfer Phase comprising electronic tokens, transmits a first acknowledgement message to the other tamper-protected semiconductor module to thereby acknowledge the successful reception of all electronic tokens as agreed on in the Negotiation Phase. Thereupon, the other tamper-protected semiconductor module responds by sending a second acknowledgement message to thereby acknowledge the receipt of the first acknowledgement message. Upon successful reception of the first and second acknowledgement messages at the tamper-protected semiconductor modules respectively, the off-line transaction protocol is always ended by both tamper- protected semiconductor modules successfully in a fair state, i.e. even an interruption of the off-line transaction protocol will now result in the successful termination of the off-line transaction protocol. Basically, the two first acknowledgement messages thus represent a proof of non-repudiation. Optionally, the tamper-protected semiconductor module receiving the second acknowledgement message transmits a third acknowledgement message to the other tamper-protected semiconductor module to thereby indicate to the other tamper-protected hardware that the transaction of the electronic tokens has been terminated successfully in a fair state. From a protocol-perspective, this "last" acknowledgement is strictly speaking not necessary, but it may be desirable as it enriches the other tamper-protected semiconductor module's (meta) knowledge about the transaction. The other tamper- protected semiconductor module could, based on the reception of the third acknowledgement message, prove the tamper-protected semiconductor module from which the third acknowledgement has been received has successfully terminated the off-line transaction protocol (without interruption). 1.4.3 Summary of Functionality & Design of the Tamper-Protected Hardware

Another aspect of the invention is the provision of tamper-protected hardware to be used in the transaction system described herein. In this respect, aspects of the invention focus on the functionality of the tamper-protected hardware (as for example provided by its firmware), and on the design of the tamper-protected hardware so as to avoid misuse and/or cloning of the tamper-protected hardware and its transaction system. It will become apparent from the following that there also often is synergy between functionality and design concepts, which, in combination, improve the robustness of the transaction system. Furthermore, it should be noted that the different designs improve the tamper- resistance on the chip level and/or on the semiconductor module level and so far on the device level.

As to the functionality of the tamper-protected hardware, same may be inter alia responsible for executing the off-line transaction protocol according to one of the various embodiments described herein in a tamper-protected environment, which is one important security aspect of the system.

Optionally, also the error handling of the off-line transaction protocol (for termination in case of an interruption prior to a successful ending of the protocol-run as foreseen by the off-line transaction protocol) and/or the compensation procedure for dispute resolution may be functionality provided by the tamper-protected semiconductor module. The respective functionality may be provided by the firmware (e.g. by means of TRUSTLET(s) - see below) or may be provided in some dedicated hardware of the tamper-protected hardware.

A tamper-protected hardware module (as part of a tamper-protected semiconductor module) could be for example a tamper-protected die or provided as a tamper-protected IC. The tamper-protected IC may be for example implemented as a tamper-protected die or multi-die having a tamper-protected enclosure as will be outlined below in more detail.

Furthermore, for enabling communication between the two tamper-protected semiconductor modules via a peer-to-peer link, some communication interface needs to be accessible and usable by a tamper- protected semiconductor module. Depending on the implementation, a tamper-protected semiconductor module may be provided with one or more wired and or wireless communication interfaces directly, or one or more wired and/or wireless communication interfaces may be implemented internally in the device housing or externally to the device housing accessible to the tamper-protected semiconductor module via an (internal and/or external) I O-interface (I/O-port) thereof. For example, the tamper-protected semiconductor module and the communication interface(s) could be provided in a host device, which could be - depending on the application - a PDA, mobile (smart) phone, or other portable device, a cash system provided at a Point of Sale, Access Control System (e.g. in a subway, in an airport, at train state, in an aircraft, fair ground, sports stadium, cinema, etc.), just to name a few.

A device comprising a tamper-protected semiconductor module could thus be provided with one or more wired and/or wireless interfaces and the tamper-protected semiconductor module of the device enabled to perform the off-line transaction protocol via wired and/or wireless peer-to-peer link utilizing one of the device's wired and/or wireless interfaces. The wireless interfaces could include at least one of a Radio Frequency IDentification (RFID) interface, a Near Field Communication interface (NFC), a Bluetooth interface (BIT), a WLAN interface (IEEE 802.11), a WiMAX interface (IEEE 802.16), and a mobile communications interface according to a 3GPP or 3GPP2 standard. The wired interfaces could for example include at least one choice of either an USB interface, an Ethernet interface (IEEE 802.3), a HomePlug interface, a PowerLAN interface, a Powerline Communication (PLC) interface (IEEE 1901) and a FireWire interface (IEEE 1394).

Generally, one could also consider combining tamper-protected semiconductor modules with additional hardware elements, such as memory (volatile memory and/or non- volatile memory), communication interface(s), etc. within the same die and/or another enclosure, e.g. a separate shared housing, which may be referred to as an electronic wallet (eWallet) or as single IC. This electronic wallet may then in turn be integrated into the respective devices.

Another functionality provided by a tamper-protected semiconductor module according to another embodiment of the invention is the possibility to perform a secure bootstrapping process of its hardware module, thereby avoiding malicious firmware being executed on the tamper-protected semiconductor module. This concept of performing a secure bootstrapping by means of TRUSTLETs (i.e. specially designed software modules of executable code) is another aspect of the invention which is not limited to use in a tamper-protected semiconductor module but may be used for bootstrapping any hardware in general, independent of their utilization in a transaction system.

1.4.3.1 PUFs

A Physical Unclonable Function or PUF is a function that is embodied in a physical structure and is easy to evaluate but hard to predict. Further, an individual PUF device must be easy to make but practically impossible to duplicate, even given the exact manufacturing process that produced it. In this respect it is the hardware analogue of a one-way function. Rather than embodying a single cryptographic key, PUFs can be used to implement challenge- response authentication. When a physical stimulus (excitation) is applied to the structure, it reacts in an unpredictable way due to the complex interaction of the stimulus with the physical microstructure of the device. This exact microstructure depends on physical factors introduced during manufacture which are unpredictable. The applied stimulus is called the challenge, and the reaction of the PUF is called the response. A specific challenge and its corresponding response together form a challenge- response pair. The device's identity is established by the properties of the microstructure itself. As this structure is not directly revealed by the challenge-response mechanism such a device is resistant to spoofing attacks.

Unclonability means that each PUF device has a unique and unpredictable way of mapping challenges to responses, even if it was manufactured with the same process as a similar device, and it is infeasible to construct a PUF with the same challenge-response behavior as another given PUF because exact control over the manufacturing process is infeasible.

Different sources of physical randomness can be used in PUFs. A distinction is made between PUFs in which physical randomness is explicitly introduced and PUFs that use randomness that is intrinsically present in a physical system.

According to another aspect of the invention, hardware modules could be provided with a hardware structure that provides a Physical Unclonable Function (PUF) which can aid the improvement of their tamper resistance. A set of known challenges and their respective corresponding responses of the hardware PUF could then be used to verify integrity of the tamper-protected hardware modules: Basically, the hardware structure implementing the hardware PUF could be challenged by one or more challenges for which at least one response to a challenge is known, and in case the tamper-protected hardware module is a "cloned" tamper-protected semiconductor module, the hardware PUF response provided by the hardware structure will not match the expected and known response(s).

In another optional implementation the response of the hardware PUF may be compressed using a cryptographic hash function. For example, in applications where a response of the hardware PUF is used only to be checked for being correct (i.e. matching /not matching a known response of the un- tampered hardware module) this implementation may be advantageously used to reduce the size of the response data, which could be for example of interest in case one or more responses of the hardware PUF need to be provided via a communications interface to another party providing the challenge(s). In this alternative exemplary implementation a response of the hardware PUF to a given challenge can be verified (and thereby the integrity of the tamper-protected hardware module) by comparing the hash value thereof to the hash value of the known response of the hardware PUF to this given challenge. Of course, the same cryptographic hash function needs to be used to calculate the hash values.

Moreover, in a more advanced implementation, prior to "hash compression" of a response by the hardware PUF, the response is stabilized against minor deviations introduced by the physical hardware nature of the hardware PUF. Such stabilization could be for example realized by functionality used within information and coding theory for applications in computer science and telecommunication like error detection and correction or error control techniques (Error-Correcting-Code, ECC) used for the detection of errors and reconstruction of the original, error-free data.

Another possible way to use the hardware PUF for securing the tamper-protected hardware module is its utilization in a segmentation process of secrets used within the tamper-protected semiconductor module: A secret is split into two parts using a so called "constructor function": Such construction function uses the hardware PUF to produce a file called "helper data" which constitutes one of the secret's parts. Due to the unique nature of the hardware PUF, the "helper data" is also unique. The original secret can only be reconstructed if both, the (correct) hardware PUF and the correct "helper data", are applied. This procedure can be used to avoid digitally storing secrets in the hardware. The secrets, once used, can be removed from all internal semiconductor registers and memories. The secrets will be extracted from the hardware as required.

1.4.3.1.1 Chip-internal Hardware PUFs

For example, in one exemplary embodiment of the invention, the tamper-protected hardware module comprises a hardware structure providing a PUF. A processor unit comprised by the tamper-protected hardware module provides, to the hardware structure implementing the PUF, at least one challenge, for which the correct PUF response by hardware structure implementing the PUF is known. The processor receives a respective PUF response for each challenge provided to the hardware structure implementing the PUF, and verifies integrity of the tamper-protected hardware module by checking whether the response to the at least one challenge for which the correct PUF response is known is matching the response received from the hardware structure implementing the PUF.

According to a more advanced embodiment of the invention the tamper-protected hardware module further comprises an I O-interface for receiving at least one challenge for which the correct (cryptographic hash of) hardware PUF response by hardware structure implementing the hardware PUF is known. The respective (cryptographic hash of) the hardware PUF response for each challenge applied to the hardware structure implementing the hardware PUF could be then made available outside the tamper-protected hardware module through the I O-interface.

This would e.g. allow external authorities or devices to check the integrity of the tamper-protected hardware module. Hence, the challenge(s) to the hardware PUF could be received from a device comprising the tamper-protected hardware module (i.e. from an "external component" of the device) or on-line from another, external device. Likewise, the respective (cryptographic hash of) hardware PUF responses for each challenge provided to the hardware structure implementing the PUF could be provided to the device comprising the tamper-protected hardware module or on-line to the external device, respectively. An integrity check of the tamper-protected hardware module utilizing the hardware structure providing the PUF may for example be a tamper-protected hardware module function, implemented by the firmware (e.g. upon power-up or reset of the tamper-protected hardware module). For this purpose, in another embodiment, the tamper-protected hardware module may further comprise a storage unit for storing a set of challenges and their (known) corresponding (cryptographic hash of) hardware PUF responses. In one exemplary embodiment, the challenges and their corresponding (cryptographic hash of) hardware PUF responses are signed by a Root Certification Authority to allow verification of their integrity.

The tamper-protected hardware module may verify the integrity of at least one challenge and its (cryptographic hash of) hardware PUF response based on its signature. The challenges and their corresponding (cryptographic hash of) hardware PUF responses could for example be signed by the Root Certification Authority using a signing key-pair's private signing key, while the public key is provided immune against counterfeit in the tamper-protected hardware module, is used to verify the integrity of the challenges and their corresponding (cryptographic hash of) hardware PUF responses. Moreover, another embodiment of the invention relates to a tamper-protected semiconductor module provided with a tamper-protected hardware module having a hardware structure implementing a PUF, as discussed above. Further, another embodiment of the invention provides a device which comprises such tamper-protected semiconductor module.

The type of the hardware PUF can be of standard hardware (silicon, optical, magnetic, acoustic, coating, butterfly, or intrinsic) PUF, or even a Cocoon PUF.

1.4.3.1.2 Semiconductor Modules with Cocoon PUFs

Another aspect of the invention is related to the design of the tamper-protected semiconductor module so as to avoid misuse and cloning of the tamper-protected semiconductor module. Please note that this aspect is independent of the other aspects of the invention provided herein, but - in some embodiments of the invention - may nevertheless used in combination with them to further improve tamper resistance.

The basic approach underlying this aspect of the invention is to design a semiconductor module which has unique properties with respect to the deflection of a physical measurand in response to an excitation (which could also be denoted a challenge). These unique deflection properties are caused by natural variances or deliberate stochastic parameter variations introduced during the production process of the semiconductor module and are thus capable of uniquely identifying the semiconductor module. Further, any attempt to tamper the semiconductor module will alter its deflection properties, which makes tampering attempts observable by the semiconductor module. Therefore, it is referred to as "tamper-protected". In one exemplary embodiment of the invention a tamper-protected semiconductor module comprising a hardware module is provided. This hardware module comprises one or more emitters to emit a predetermined excitation which can be measured as a physical measurand (German: MessgroBe). Further, the hardware module may comprise one or more sensors for sensing the (back-) scatter of the predetermined excitation as physical measurand in a contactless manner. The tamper-protected semiconductor module further has a cocoon encasing the hardware module. This cocoon may also be referred to as a package or housing. The cocoon is configured to influence the (back-) scatter of the predetermined excitation to be detected by the sensor(s).

Since the deflection properties of the inside of the cocoon and thus the (back-) scatter of a given excitation is influenced by natural or deliberate variations in the production process, e.g. the packaging process of the hardware module, the measured (back-) scatter of the predetermined excitation influenced by the cocoon provides a Physical Unclonable Function (PUF) specific to the tamper- protected semiconductor module. For simplicity the tamper-protected semiconductor module's PUF function provided by the unique deflection properties of the cocoon is also referred to "cocoon PUF". Using this cocoon PUF, the hardware module - according to another more detailed embodiment of the invention - is able to detect any tampering of the tamper-protected semiconductor module, respectively, and non-invasive (or "passive", e.g. scanning the tamper-protected semiconductor module through a beam of (LASER) light, other radiation fields or screening technology), semi- invasive and full-invasive attacks to access the inside of the cocoon, respectively the hardware module.

Furthermore, in another embodiment of the invention, the hardware module makes itself temporarily or permanently unusable, once the hardware module detects a tampering of the tamper-protected semiconductor module.

Please note that in the following it will be often referred to "emitters" and "sensors" in plural. However, also implementations where the hardware module has only one single emitter and/or one single sensor are encompassed by this invention.

How the tamper-protected semiconductor module is using its cocoon PUF functionality to detect tampering may be implemented in various ways. For example, in one exemplary embodiment of the invention, the tamper-protected semiconductor module may generate a digital "measured fingerprint" (denoting the fingerprint that has - so to say - just been "measured" by the sensors) of the tamper- protected semiconductor module from the measured values (German: Messwerte) of the (back-) scatter of the excitation provided by the respective sensors and detects an attempt to tamper the tamper- protected semiconductor module by comparing the measured digital fingerprint with a digitized fingerprint of the un-tampered tamper-protected semiconductor module (which may have been for example stored previously). It should be apparent that repeated verification of the integrity of the cocoon, respectively, the tamper-protected semiconductor module requires the same predetermined excitation emitted in each verification process, i.e. each measurement of the (back-) scatter of the predetermined excitation (for details on the "same" predetermined excitation, please see below).

In another exemplary embodiment of the invention, the tamper-protected semiconductor module also generates a measured digital fingerprint of the tamper-protected semiconductor module from the measured values of (back-) scatter of the excitation provided by the sensors. Further, a processor unit of the hardware module could receive (so-called) helper data from storage, and generates a secret based on the measured digital fingerprint and the helper data (a two-factor secret). In case the measured digital fingerprint is not sufficiently corresponding to the "correct" (previously measured and digitized) fingerprint of the un-tampered tamper-protected semiconductor module, the generated (recombined two-factor) secret is incorrect, meaning that it is not corresponding to the "correct" secret that would have been obtained when generating the secret using the helper data and the "correct" fingerprint of the un-tampered tamper-protected semiconductor module.

In such case, the generation of an incorrect secret implies that the unique deflection properties inside the cocoon must have changed somehow (i.e. the cocoon PUF function of the tamper-protected semiconductor module has also changed), which in turn indicates an attempt to try to access the inside of the cocoon (respectively, tamper-protected semiconductor module) yielding a tampering attempt.

There are also different possibilities how to provide one or more emitters on the hardware module. According to one exemplary embodiment of the invention, the one or more emitters is/are circuitry and/or integrated circuits of the hardware. Hence, in some applications, the individual circuit components, wires or some chip areas of the hardware module may have properties of an oscillator/clock generator/radiator and may thus be used as emitters (thus no separate emitters may need to be used). In order to ensure the emission of the predetermined excitation, the tamper-protected semiconductor module operates the emitters at predetermined operation conditions during the period in which the sensors are to measure the (back-) scatter of the excitation.

Alternatively, or in addition to those emitter(s) formed by circuitry and/or integrated circuits of the hardware module, in another exemplary embodiment, the one or more emitters are provided as one or more oscillators comprised by the hardware modules. The oscillators together (and optionally in combination with the emitter(s) formed by circuitry and/or integrated circuits of the hardware module) emit the predetermined excitation.

Moreover, it should be noted that the excitation by the emitter(s) may be an electromagnetic excitation (e.g. electromagnetic fields (e.g. in the radio spectrum), x-ray, etc.), an optical excitation (e.g. generated by LED or LASER elements) and acoustic excitation (e.g. infra- or ultrasonic), or combinations thereof. Apparently, the sensors that sense the (back-) scatter of the excitation are electromagnetic sensors, electric field sensors, magnetic field sensors, acoustic sensors, optical sensors or other radiation sensors, depending on the excitation type. For example, the sensors and/or the emitters provided as part of the hardware module may be semiconductor elements and/or Micro- Electro-Mechanical-Systems (MEMS) and/or Nano-Electro-Mechanical-Systems (NEMS). MEMS are also known as Micro-Machines (MM) or Micro-System-Technology (MST).

Furthermore, in one further embodiment of the invention, the cocoon comprises a shield to prevent interference with the predetermined excitation from the outside of the tamper-protected hardware. Another aspect of the shielding is to prevent undesirable emittance of the excitation to the outer world beyond the limits of the cocoon serving as covering (e.g. Electro-Magnetic-Interference, EMI, in case the excitation is of this type). Accordingly, the shielding ensures the sensors measure the (back-) scatter of the predetermined excitation within the limits of the cocoon (respectively, the shielding provided therein). The required type of shielding is of course depending on the type of the excitation by the emitter(s). Hence, the shielding can be an electromagnetic shielding, an electric shielding, a magnetic shielding, an acoustic shielding, an optical shielding or a combination thereof.

In a further exemplary embodiment of the invention, the shielding comprises or is a metallic plumbiferous or aluminum based shield.

In embodiments of the invention, where an acoustic shielding is desired, the shielding material may for example comprise or consist of structured permanently elastic foam like compounds. However, other materials that absorb sound and attenuate the acoustic excitation may also be used to provide an acoustic shield.

According to another embodiment of the invention, an optical shielding may comprise one or more surface reflectors or could be implemented as a surface reflector at least a portion of the hardware module. For example, in one exemplary implementation, the surface reflector(s) could be made of metal.

Further, in another embodiment of the invention, the cocoon is non-transparent in the optical and infrared spectrum of electromagnetic radiation. This feature may for example be advantageous to prevent non-invasive attacks on the inside of the tamper-protected semiconductor module (respectively, its cocoon as the outer part), e.g. by means of infrared light or other optical scanning methods.

Moreover, in another embodiment of the invention, the cocoon may have a high thermal conductivity. This may be advantageous in that heat (generated by the operation of the hardware modules circuitry and circuit components) may be provided to the outside of the cocoon, respectively, cooling of the hardware modules from the outside of the surrounding cocoon becomes possible.

In order to provide unique deflection properties inside the cocoon, the design of the cocoon (besides adding a shield) may ensure for such property. For example, in a further embodiment of the invention, the cocoon comprises a coating and/or a potting compound including a material or material mixture (e.g. granulate added to a conventional coating/potting material, such as a ceramic or a synthetic material) influencing the (back-) scatter of the predetermined excitation. Please note that the coating and/or potting is applied inside the shielding.

For example, in one exemplary implementation the material or the material mixture comprises a granulate whose granules are influencing the (back-) scatter of the predetermined excitation. In a more detailed implementation the granules of the material or the material mixture could for example have different mechanical dimensions: They may be of different size (e.g. nano-sized granules to macro- sized granules) and/or different shape.

The granules of the material or the material mixture may be non-regularly (randomly) distributed in the potting material thereby influencing the (back-) scatter of the predetermined excitation in way unique to the tamper-protected semiconductor module. This may be for example achieved by the production process that is providing the coating and/or potting to form the cocoon encapsulating the hardware module. In one example, the potting material is made of ceramics and may contain a granulate of the material or the material mixture influencing the (back-) scatter of the predetermined excitation.

In another exemplary embodiment of the invention, the material or material of the shielding or the granules thereof are similar to the material mixture of the hardware module and/or its bonding with respect to their chemical characteristics (and optionally the physical characteristics). The idea behind this is to make full-invasive attacks on the tamper-protected semiconductor module more difficult: For example, the package being or including the cocoon of the tamper-protected semiconductor module might be removed using acids or chemical bases in order to access the inside hardware module. By choosing the chemical character of the cocoon's material and the hardware module's material (and/or its bonding) to have similar chemical resistance against acids chemical bases, it is difficult to control the etching to remove the cocoon material only without damaging the hardware module or its bonding. Similarity of the physical character may be another optionally desired property, since the physical characteristics influences the reaction time with the acid/base so that it becomes even more difficult to control the edging to only remove the cocoon material, while not damaging the hardware module or its bonding.

Regarding the predetermined excitation, there are also various ways to generate such predetermined excitation. Of course, to be able to reproduce the "fingerprint" (for the un-tampered case) the predetermined excitation should be the same for each measuring process that determines the actual "just measured" fingerprint. In practice it may be difficult to achieve identical excitations (for example, due to temperature variations, drift effects of physical material properties in time, noisy measurement, fuzzy sensors, etc.). Hence, the same excitations should not be interpreted as 100% identical excitations; however, the variations may be compensated by the generation process of the fingerprint from the measured values provided by the sensors, and/or countermeasures may keep variations of the excitation in an acceptable range not critical to the uniqueness and stability of the generated fingerprint. In one exemplary embodiment, the cocoon's influence on the (back-) scatter of the excitation to be detected by the sensors is insensible to change of temperature (in a definable range or desirable range of temperatures).

Please note, there may be a tradeoff, respectively a mutual influence, between the foreseeing countermeasures keeping variations of the excitation in an acceptable range not critical to the uniqueness and stability of the generated fingerprint and the generation process of the fingerprint from the measured values provided by the sensors (i.e. the measured values so to speak form the data base for the determination of the fingerprint): On the one hand, the generation process of the fingerprint may not reduce the data spectrum for the generation of the fingerprint in a way it loses its uniqueness; on the other hand, countermeasures keeping variations of the excitation in an acceptable range may aid to minimize the reduction of the data spectrum for the fingerprint but may be expensive to implement.

To generate a sufficiently wide data spectrum (i.e. a sufficient number of measured values (respectively "bits" once the measured values are quantized) that can be used for the generation of the unique fingerprint of the tamper-protected semiconductor module, different possibilities to design the predetermined excitation of the one or more emitters are possible. For example, one possibility may be that the predetermined excitation is a constant predetermined excitation, i.e. not varying over time. Alternatively, the predetermined excitation could also be an excitation varying in a predetermined manner - which implies the sensors should measure the measurand multiple times within a measurement period. The variation of the excitation could for example be implemented by the hardware module comprising an excitation controller that controls the emitters individually or in combination to produce the predetermined excitation varying in time. For example, different sets of emitters are used in a given sequence in time to generate respective excitations (i.e. a predetermined sequence of individual excitations) that form the predetermined excitation.

In a further embodiment, the sensors to provide a measured value of the measurand that is to be part of the data base for generating the fingerprint could be controlled by the hardware module. For example, the hardware module may trigger/query different sets of sensors at different times of a measurement cycle to receive their measurement results. This control of the sensors may of course be readily combined with the control of the emitters described in the preceding paragraph.

Moreover, the hardware module protected by the cocoon may virtually be any hardware structure that should be made tamper resistant. In one exemplary embodiment of the invention, the hardware module is a die, a multi-die, or a chip comprising of one or more integrated circuits (ICs). Likewise and in another embodiment of the invention, the hardware module is a die, a multi-die, or a chip comprising of one or more ICs assembled on a circuit carrier (e.g. by means of a bonding process).

As indicated above, it may be possible that circuitry and/or integrated circuits of the hardware module is/are used as the one or more emitter(s) of the predetermined excitation. In order to allow the emission of a predetermined excitation, according to one embodiment of the invention, the tamper- protected semiconductor module deactivates the (integrated) circuit parts of the hardware module occasionally during a measurement cycle in which the one or more sensor(s) detect the (back-) scatter of the predetermined excitation. For instance, the deactivation may be a deep power down to minimize the interference of the (integrated) circuit parts of the hardware module with the (back-) scatter of the predetermined excitation.

For the purpose of controlling emitters and sensors and optionally for deactivating the (integrated) circuit parts of the hardware module during a measurement cycle a measurement unit may be provided on the hardware module. This management unit may be considered an IC of the hardware module. The management unit is provided with an I/O-interface for transmitting and/or receiving standardized commands and or data packets from the other integrated circuit parts of the hardware module, e.g. the sensors and emitters. For example, the measurement unit may coordinate the one or more sensor(s) and the one or more emitter(s) in a measurement cycle.

Please note the cocoon may be the housing of the hardware module or may be itself included in a housing together with the hardware module. Likewise, the shielding of the tamper-protected semiconductor module could be part of the cocoon or may enclose same. In case a "separate" housing is provided, the cocoon could be provided in form of a malleable mass between the housing and the hardware module.

Another aspect of the invention is the provision of a method for manufacturing a tamper-protected semiconductor module with a cocoon PUF as described herein. According to an embodiment of the invention a manufacturing method of a tamper-protected semiconductor module with a cocoon PUF comprises of providing a hardware module equipped with one or more emitters for emitting a predetermined excitation that can be measured as a physical measurand, and one or more sensors for sensing the (back-) scatter of the excitation in form of the physical measurand in a contactless manner. Further according to this manufacturing method, the hardware module is housed in a cocoon to obtain the tamper-protected semiconductor module, wherein the cocoon influences the (back-) scatter of the excitation detected by the sensors in a way unique to the tamper-protected semiconductor module.

In an exemplary embodiment of the invention, housing the hardware module in the cocoon includes the enclosure of the hardware module in a potting material, and encapsulating the hardware module enclosed by the potting material inside a shield to prevent interference with the predetermined excitation from the outside of the tamper-protected semiconductor module. As noted above, the shielding may be but is not necessarily part of the cocoon.

Furthermore, in another embodiment of the invention, the exemplified shielding is produced using one or more of the following technical processes for producing different layers of shielding material on the inside and/or outside of the cocoon surface: - sintering one or more shielding materials,

- sputtering one or more shielding materials,

- spraying, spritzing or bubbling one or more shielding materials (e.g. using High-Volume-/Low- Pressure plants (HVLP)),

- coating and/or plating one or more shielding materials (e.g. electric conductive (finishing) paint/lacquers containing/made of epoxy, polyurethane or acrylic with expletive particles like silver, silver plated copper, pure copper or nickel),

- immersing in one or more baths of fluids comprising the shielding material,

- evaporating, optional in a vacuum, of one or more shielding materials (e.g. Physical Vapor Deposition (PVD)),

- electroless plating one or more shielding materials (e.g. one layer/sheet/lamina e.g. of pure copper, followed by another layer/sheet/lamina e.g. of nickel-phosphorus alloy),

- electrolysis using one or more same shielding materials.

Optionally, the shielding may be subject to (additional) thermal treatment.

In one exemplary embodiment of the invention, the potting material comprises conductive material or a conductive material mixture influencing the (back-) scatter of the excitation to be detected by the sensors provided on the hardware module. Optionally, the manufacturing method provides a passivation (e.g. electrical isolation) to the hardware module and/or to its outside.

In a further exemplary embodiment, the provision of the hardware module as part of the manufacturing process includes implementing the hardware module in a standard wafer process. For example, the standard wafer process is a silicon semiconductor process.

A further aspect of the invention is to provide a method to detect tamper attempts against a tamper- protected semiconductor module equipped with a cocoon PUF (the hardware module of the tamper- protected semiconductor module with the cocoon PUF):

a) causes the one or more emitters of the hardware module to emit predetermined excitation, and further

b) causes the one or more sensors of the hardware module to sense the (back-) scatter of the predetermined excitation reflected by the cocoon of the tamper-protected semiconductor module.

Further, the hardware module then

c) generates a digital "measured fingerprint" from (back-) scatter of the predetermined excitation sensed by the one or more sensors, and

d) verifies the integrity of the cocoon by using the measured digital fingerprint recorded. As before, the term "measured fingerprint" is used to denote the fingerprint derived from the just/last measured values of the (back-) scatter of the predetermined excitation sensed by the one or more sensors.

Please note that the hardware module may perform these steps a) to d) not only once, but also repeatedly. Hence, an ongoing verification of the integrity of the tamper-protected semiconductor module is possible. Steps a) to d) may be for example repeatedly performed in irregular intervals or on a random basis.

The method according to another embodiment of the invention further comprises a step

e) of producing an interrupt, in case integrity could not be verified in step d). This interrupt may cause the hardware module disable itself permanently or temporarily.

In a further embodiment of the invention, the method further comprises a step

f) of deactivating integrated circuit parts of the hardware module during a measurement cycle in which the one or more sensors detect the (back-) scatter of the predetermined excitation. This may be helpful to produce the same predetermined excitation in all measurements.

Furthermore, as noted previously, there may be different possibilities how to make use of the cocoon PUF for verifying the integrity of the cocoon/tamper-protected hardware module. In one exemplary embodiment of the invention the integrity of the cocoon is verified by comparing the measured digital fingerprint (i.e. the digital fingerprint just generated from the latest measured values of the sensors) with a digital fingerprint of the un-tampered cocoon (this latter fingerprint could also be referred to as the "reference fingerprint" or "un-tampered fingerprint). For instance, the fingerprint of the un- tampered cocoon is stored in form of a certificate in a memory.

In a further exemplary embodiment, the method for checking the integrity of the cocoon may further comprise the following steps of

g) initializing the hardware module by creating and recording a fingerprint of the un-tampered semiconductor module,

h) securing this fingerprint of step g) using a certificate signed by an Certification Authority, and i) storing the certified fingerprint in a semiconductor non-volatile memory. In one exemplary embodiment, this certificate may be signed by the Root Certification Authority (RCA) or another Certification Authority that can be validated against the RCA's certificate containing the public key part of the RCA's public key-pair.

Another possibility for verifying the integrity of the cocoon is the use of the cocoon PUF as part of a key restoration process (two-factor secret). Using the cocoon PUF this key restoration process is used to recreate the key (also referred to as "recombined secret") from helper data. The helper data is generated based on the key using the cocoon PUF of the un-tampered cocoon, respectively, un- tampered (tamper-protected) semiconductor module, which binds the recreation of the key to this specific cocoon PUF. If the cocoon PUF is altered due to a tampering attempt, the key may be temporarily or permanently destroyed, since the PUF of the cocoon will be temporarily or permanently changed as a result of the tampering attempt, so that the key generation function is unable to reconstruct the correct key (again) or due to the intention of the designer/IP owner to trigger a backlash. Hence, in this exemplary embodiment, the verification of the integrity of the cocoon is realized by means of a key restoration process generating a key based on helper data and the detected (back-) scatter of the predetermined excitation.

The generation of the helper data may be e.g. part of an initialization procedure of the semiconductor module in an un-tampered case (e.g. by performing the initialization at a trusted party; a trusted party could be for example a Root Certification Authority, the manufacturer of the tamper-protected semiconductor module, the manufacturer of a device comprising the tamper-protected semiconductor module, the customer/user, etc.). Therefore, in another embodiment of the invention, the method further comprises the steps of g) initializing the hardware module by creating and recording a fingerprint of the un-tampered semiconductor module, and generating the helper data based on the key and the sensed (back-) scatter of the predetermined excitation. This helper data may then be stored in a non-volatile memory.

Please note that the helper data may not need to be protected, since it is impossible to recreate the secret from the helper data without the correct PUF. Hence, the helper data may be stored either in the hardware module or in an external storage of a device or another hardware structure that contains the tamper-protected semiconductor module.

1.4.3.2 Maze of Knossos - Configuration of the FPGA

Another aspect of the invention is to provide a hardware module (chip) with a FPGA having a configuration of an array of Processing-Elements to provide a given functionality. Moreover, a storage unit of the tamper-protected semiconductor module could store signed configuration information ("fingerprint") indicating the initial configuration of the array of Processing-Elements of the FPGA of the hardware module. The hardware module's processor unit could then verify integrity of the hardware module by verifying the integrity of initial configuration information based on its signature and comparing the verified initial configuration information with configuration information of the Processing-Elements of the FPGA. If a mismatch is detected, the hardware module may for example disable itself temporarily or permanently. As this mechanism allows detecting attacks on the hardware module it can be considered tamper-protected. The principle of a configuration fingerprint may also be implemented with other programmable ICs (hardware structures) that have a unique, programming dependent configuration (excluding ROMs). For simplicity, it is referred to FPGAs herein, but the concept outlined herein may also be used in other programmable ICs (programmable hardware modules). Please note that the use of a hardware structure providing a hardware PUF for which a set of challenges and corresponding (cryptographic hash of) responses is known and the use of a FPGA whose initial Processing-Elements' configuration is known within a hardware module in principle are two independent aspects of the invention to improve the robustness of a tamper-protected hardware module which may be used independently. However, it may of course be advantageous to use the combination of both of them (and optionally even more protections mechanisms) to improve the tamper-resistibility of the tamper-protected hardware module. In case the tamper-protected hardware module cannot verify its integrity, the tamper-protected hardware module is capable to disable itself temporarily or permanently.

1.4.3.3 On-chip Trusted Time Source

Another aspect of the invention facilitating an improvement of the tamper-resistibility of the tamper- protected hardware module is the provision of an on-chip trusted time-source within the tamper- protected hardware module. Please note a trustable time-source is required for example in order to be able to verify the validity of all kinds of certificates (which do typically have an expiration date and time). In one exemplary embodiment, the on-chip of the tamper-protected hardware module's trusted time-source is implemented as a (strong) monotone timer which is erased after a predetermined time span upon disconnection from its power supply. Please note that the expression "predetermined time span" is intended to express the (strong) monotone timer will be erased once its counter value cannot longer be held in memory due to disconnection from the power supply. Please note also, in case the trusted time source is to be reinitialized after erasure, the tamper-protected hardware module may receive on-line the current date and time from a Root Certification Authority, signed by a Root Certification Authority, and initialize the trusted time source with the current date and time only if the signature of the Root Certification Authority can be verified successfully.

It should be apparent that without a local valid trusted time-source, none of the certificates can be verified, so the reestablishment of the validity of the trusted time source should be performed first before any other protocol communication operation, including any transaction, can be done.

1.4.3.4 Crypto-Initialization of the Tamper-protected Hardware Module (CASTOR)

Another aspect of the invention related to increasing the tamper-resistibility of a tamper-protected hardware module is to provide a validation process of the tamper-protected hardware module, which could be considered an "initialization" of the tamper-protected hardware module. This validation process/initialization of the tamper-protected hardware module may be performed at the Root Certification Authority and provides the tamper-protected hardware module with a certificate used as the "identity" or identifying descriptor item (e.g. a serial number) of the tamper-protected hardware module in any transaction performed. Any tamper-protected hardware module that does not undergo the validation process/initialization at the Root Certification Authority and that's thus not equipped with such certificate will be unusable in the transaction system. Hence, tamper-protected hardware modules embezzled from the production process become unusable.

For this purpose, according to an exemplary embodiment of the invention, a tamper-protected hardware module comprises a key generation unit which autonomously generates a predetermined set of one or more symmetric keys and one or more asymmetric (public) key-pairs in response to an initialization request. Optionally, the key generation unit could be adapted to autonomously generate the keys only once upon initialization.

One of these generated keys is used to identify the tamper-protected hardware module, respectively the tamper-protected semiconductor module comprising same, similar to an identifying descriptor item of the tamper-protected hardware. Furthermore, the tamper-protected hardware module is equipped with an I/O-interface for providing the key used for identification of the tamper-protected hardware module to the outside of the tamper-protected hardware module in response to the initialization request. Furthermore, through its I/O-interface the tamper-protected hardware module receives a certificate from a Root Certification Authority comprising the key used to identify the tamper- protected hardware module and stores the certificate comprising the key used for identification of the tamper-protected hardware module and (together with) the generated predetermined set of symmetric keys and asymmetric key-pairs in a storage unit.

The certificate of the Root Certification Authority provided as part of the initialization of the tamper- protected hardware module may for example further comprise public keys of the Root Certification Authority for encryption and verifying the Root Certification Authority's signatures. Moreover, the Root Certification Authority's certificate could optionally comprise the public key of the public key- pair for internal encryption and hashing purposes generated by the tamper-protected hardware module in response to an initialization request. For example the public keys may be used in the protection of a symmetric key for on-the-fly encryption/decryption of data as to be explained below (umbrella protection).

In another embodiment of the invention, besides the key/keys used to identify the tamper-protected hardware module, the key generation unit may further generate a symmetric key for on-the-fly encryption/decryption (also called umbrella encryption decryption) of data to be maintained and/or stored inside or outside the tamper-protected hardware module in a host device including the tamper- protected hardware module prior to its exchange through the I/O-interface.

Furthermore, the symmetric key for on-the-fly encryption/decryption of data could be then stored by or in the external storage of a host device comprising the tamper-protected hardware module. In a more detailed exemplary embodiment, the symmetric key is processed as follows prior to its storage: a) The symmetric key is first encrypted using a public key of an asymmetric key-pair of the Root Certification Authority. b) Then the encrypted symmetric key of step a) is encrypted through a private key of a key-pair used for internal encryption, and hashing purposes being generated by the tamper-protected hardware module in response to an initialization request.

c) Finally, the double-encrypted symmetric key of step b) is signed using a public key of an asymmetric key-pair of the Root Certification Authority.

The signed and double-encrypted symmetric key of step c) is then stored by in a host device's external storage comprising the tamper-protected hardware module (i.e. a storage residing outside the tamper- protected hardware module).

In one embodiment of the invention, the predetermined set of one or more symmetric keys and one or more asymmetric key-pairs generated by the key generation unit comprises a public key-pair for internal encryption and hashing purposes being generated by the tamper-protected hardware module in response to an initialization request (i.e. the public key-pair used in step b) is inter alia used for encrypting the symmetric key for on-the-fly encryption/decryption of data mentioned above).

Moreover, in a more detailed exemplary implementation, the tamper-protected hardware module could on demand provide the public key part of the public key-pair for internal encryption and hashing purposes to the exterior of the tamper-protected hardware module via the I O-interface.

For example, the symmetric key for on-the-fly encryption/decryption of data could be used to encrypt electronic tokens that then could be stored in encrypted form outside the tamper-protected hardware module in a host device including the tamper-protected hardware module. In case the tamper-protected hardware module is destroyed or rendered unusable (permanently or temporarily), the encrypted electronic tokens stored in a host device's storage outside to the tamper-protected hardware could be recovered by the Root Certification Authority (or alternatively by the Escalation Authority, EA), assuming that the Root Certification Authority maintains the respective tamper-protected hardware's public key-part of the public key-pair for internal encryption and hashing purposes, as described above.

The decision to enable or disable this functionality may be up to the user/owner of the tamper- protected hardware module. Accordingly, in one embodiment of the invention, the user/owner of the tamper-protected hardware module can configure whether or not the tamper-protected hardware module stores the symmetric key for on-the-fly encryption decryption outside the tamper-protected hardware module. The symmetric key for on-the-fly encryption decryption may be protected by steps a), b) and c) as mentioned before, before storing same outside the tamper-protected hardware module.

1.4.3.5 Summary

It should become apparent from the foregoing explanations there are several individual functional and design-related measures of the tamper-protected semiconductor module making same less vulnerable to misuse or cloning. It should be apparent that the individual functional and design measures of the tamper-protected hardware (including also Secure Bootstrapping explained below) may be advantageously combined to obtain an overall security architecture that allows to achieve a very high- level of tamper resistance of the tamper-protected semiconductor module.

1.4.4 Summary of Trusted Boot through TRUSTLETs

As indicated above, another aspect of the invention is the suggestion of a bootstrapping mechanism for hardware. This bootstrapping mechanism may be used for bootstrapping a tamper-protected hardware module as used in a transaction system, but could be - in general - also used to bootstrap any type of IC (firmware) or device (firmware and/or software). The bootstrapping mechanism is based on the provisioning of firmware/software in form of one or more software module(s) (also called TRUSTLET(s) herein) each of which providing a piece of the overall functionality of the firmware/software - of course, also one (standard) software module could provide the entire firmware/software functionality. The idea of the bootstrapping mechanism is to generate a chain of trust by one software module checking the validity of the next software module to be executed prior to its execution. If the verification of the subsequent software module fails, the bootstrapping is stopped, which may leave the bootstrapped hardware (temporarily) dysfunctional. The individual software modules are encrypted and signed themselves which is intended to protect the software modules against being tampered by attackers.

According to an exemplary embodiment of the invention, the software modules are generated as follows: It is assumed that a entity block is provided to be included into the software module. The entity block provides an executable piece of software implementing a given (set of) functionality of the firmware/software. First, the software module is signed: A fingerprint of the (uncompressed) software module is generated using a hash function (e.g. by using the Secure Hash Algorithm Standard (SHA - see FIPS PUB 180-3, "Secure Hash Signature Standard", available at http://csrc.nist.gov) in order to allow verification of the integrity of the software module. This fingerprint is then encrypted using the private key of a public key-pair (signing key) to thereby generate a digital signature of the software module.

Optionally, the software module is additionally compressed to reduce its size. The - compressed or uncompressed - software module is then combined with the encrypted fingerprint to form an integrity- protected software module. This integrity protected software module is encrypted using a random secret key to thereby form an encrypted and integrity protected software module.

The random secret key is encrypted using the private key of a public key-pair, and the software module is obtained by combining the encrypted and integrity protected entity block, and the encrypted random secret key. Please note that a software module generated according to this process (or according to a more advanced exemplary implementation thereof) is also referred to as a TRUSTLET herein. Please note, the public key part of a public key-pair used for encrypting the random secret key is assumed to be known to the bootstrapping hardware (in order of being able to decrypt, verify and execute).

The public key encryption may for example be realized according to one of the Elliptic Curve Cryptography (ECC) Standards (ECC is included in numerous standards around the world. This issue of Code and Cipher focuses on three key standards bodies that incorporate ECC: ANSI, IETF and NIST. Standards are: ANS X9.62, WAP WTLS, ANS X9.63, and IEEE 1363, and recommendation NIST SP 800-56). For example, the fingerprint could be encrypted with the private key of the key-pair using a Digital Signature Algorithm (DSA), or an Elliptic Curve Digital Signature Algorithm (ECDSA), DSA, and ECDSA can be found within FIPS PUB 186-3, pp. 19 to 26, available at http://csrc.nist.gov.

In one exemplary further implementation, the integrity protected entity block is encrypted using symmetric-key encryption, such as for example the Advanced Encryption Standard (AES, see FIPS PUB 197, available at http://csrc.nist.gov) or Data Encryption Standard (DES, see FIPS PUB 46-3, available at http://csrc.nist.gov). Accordingly, the random secret key may be a symmetric key.

In order to implement a chain of trust between the software modules upon bootstrapping, the entity block of a software module may comprise instructions to execute another software module. Basically, these instructions may enable:

decryption of an encrypted random secret key of the other software module, decryption of the encrypted and integrity protected entity block of the other software module using the decrypted random secret key to thereby obtain an integrity protected entity block of the other software module,

decryption of an encrypted fingerprint (i.e. the digital signature) comprised in the integrity protected entity block of the other software module, and

- generation of another fingerprint of the entity block using the same hash function as used to generate the encrypted fingerprint of the other software module,

- verification of the entity block's integrity of the other software module's integrity protected entity block by comparing the decrypted fingerprint with the other generated fingerprint, and execution of the other software module's entity block, only in case the integrity of the other software module's entity block is verified successfully.

In a further exemplary embodiment of the invention, the private key used to encrypt the fingerprint differs from the private key used for encrypting the random secret key. Further, the public keys corresponding to the private keys to encrypt the fingerprint and random secret key, respectively, are assumed to be provided in form of a certificate originating from the Root Certification Authority. This means the public keys are signed by a Root Certification Authority using a private signing key (part) of a signing key-pair, the public key (part) of which is provided immune against counterfeit in the hardware to execute the software module.

Being provided with such software modules (TRUSTLETs), according to a further embodiment of the invention, a piece of hardware is bootstrapped into a controlled environment by executing a set of software modules in a given order as follows:

a) decrypting an encrypted random secret key of one of said set of software modules to be executed next,

b) decrypting an encrypted and integrity protected software module's entity block to be executed next, using the decrypted random secret key, to thereby obtain an integrity protected software module's entity block to be executed,

c) decrypting an encrypted fingerprint comprised in the integrity protected software module's entity block to be executed next, and

d) generating another entity block's fingerprint using the same hash function as used to generate the encrypted fingerprint,

e) verifying the entity block's integrity of the software module's integrity protected entity block to be executed next by comparing the fingerprint decrypted in step c) with the fingerprint generated in step d), and

f) only in case the integrity of the software module's entity block to be executed next is successfully verified, this software module's entity block will get executed next,

Steps a) to f) are to be performed for each software module of the set of software modules thereby realizing a chain of trust.

In one further exemplary embodiment of the invention, the functionality to perform steps a) to f) for the set of software modules' first software module is implemented in the hardware (e.g. is stored in a ROM, or the like within the hardware as a gate-based hardcoded (never to be changed) implementation). The hardware's or its piece(s) providing functionality to perform steps a) to f) therefore should be advantageously tamper-protected.

Furthermore, the processing of a software module to be executed next may further comprise g) obtaining a certificate comprising one or more public keys, wherein the one or more public keys are signed by a Root Certification Authority using a signing key-pair's private signing key (part), the public key (part) of which is provided immune against counterfeit in the host device, and h) verifying the one or more public key(s) (part's) integrity comprised in the certificate using the public key (part) provided immune against counterfeit in the host device. One verified public key of the certificate is used for decrypting the encrypted random secret key in step a) and one verified public key of the certificate is used for decrypting the encrypted fingerprint in step c). The two public keys may be the same or different (more secure).

As for steps a) through f), the functionality to perform steps g) and h) for the first software module of the set of software modules may be implemented in hardware. The (piece(s) of the) hardware that provides functionality to perform steps g) to h) may therefore be equally tamper-protected.

Furthermore, the functionality to perform steps a) through f) (respectively steps a) through h)) for a software module other than the first software module could be implemented in hardware or could be implemented in software within the entity block of the software module executed prior to said given software module.

Furthermore, it should be apparent that the unsuccessful execution of one or more of steps a) to f) (respectively a) to h)) results in interrupting the bootstrapping of hardware. This interruption of the bootstrapping could result in the hardware becoming temporarily or permanently unusable. Alternatively, depending on the functionality to be provided by the firmware/software, the boot process could be finished, but certain functionality - in particular functionality which has to be immune against attacks and/or counterfeit - may be disabled by the hardware.

In one exemplary embodiment of the invention, the bootstrapped hardware is a tamper-protected hardware module, and the functionality provided by the software modules (TRUSTLETs) includes at least one of:

- An interface filter (API Filter) for cooperation with a host device's filter controller and for controlling messages exchanged via an I/O-interface of the tamper-protected hardware module for interfacing with the host device comprising the tamper-protected hardware module,

- A license check module which implements "Identification Friend or Foe" (IFF) to analyze the local tamper-protected hardware module. This is helpful to indemnify the decision if the tamper- protected hardware module is a legalized or counterfeit hardware and which application the hardware is licensed to run.

- An initial program loader module (IPL Boot). This TRUSTLET makes it possible to coordinate the boot process and to allow options within same. It may for example contain an extended Power- On-System-Test (POST) and may manage (parts of) the update process of the tamper-protected hardware module. The initial program loader may be optionally provided with a simple (user) interface able to allow user-selectable decisions and features.

- An embedded operation system (micro) kernel to handle the various operations of the tamper- protected hardware module's application module. The application for the tamper-protected hardware module specifying the tasks and features same is able to do.

An implementation of an off-line transaction protocol for a transfer of electronic tokens between two hardware-protected hardware modules (respectively two host devices comprising same), and - A handler (i.e. a piece of software or dedicated hardware managing the respective task(s)) for termination of the off-line transaction protocol in case of an off-line transaction protocol's interruption, including a generation of a proof of loss of electronic token in response to the off-line transaction protocol terminating in an unfair state.

A handler for checking and maintaining (e.g. by performing an on-line refresh of the trusted time- source - if necessary) a trusted time-source comprised in the host device,

- A handler for initialization of the I/O-key-unit for real-time I/O-encryption and decryption of information exchanged via an I/O-interface of the host device (umbrella encryption/decryption),

- A handler for compensation for a loss of electronic tokens using a proof of loss of electronic token provided in response to the off-line transaction protocol terminating in an unfair state, and - A handler for checking a semiconductor module's cocoon PUF fingerprint comprising the tamper- protected hardware module.

The tamper-protected hardware module may for example store the software modules in an internal or external memory. Moreover, the hardware could receive an update of one or more of the software modules from a third party.

Furthermore, in another embodiment of the invention a certificate (see e.g. Type-V certificate below) is appended to the software module (e.g. firmware or software) which is signed by a Root Certification Authority using a private signing key of a signing key-pair. The public key of this signing key-pair is provided immune against counterfeit in the bootstrapped hardware, respectively the tamper-protected hardware module. Please note that the certificate may already be appended to the software modules upon generation.

It should be further noted, according to this aspect of the invention, that the invention is not only related to the generation of the software modules and bootstrapping mechanism using same, but also provides the hardware and/or software to perform the generation of the software modules, respectively a hardware to perform the bootstrapping mechanism using same. Hence, further embodiments of the invention provide a device, adapted to perform the generation of the software modules, and further a tamper-protected die or multi-die, a tamper-protected chip, and/or a device adapted to perform bootstrapping mechanism using same. 1.4.5 Exemplary Off-line Transaction Protocol for an eCash System

As indicated above, one aspect of the invention is the provision of an off-line transaction protocol that is capable of transferring electronic tokens (of arbitrary contents) between two tamper-protected semiconductor modules, which may be for example part of respective peer-devices. The parties of the transaction, respectively the tamper-protected semiconductor modules or devices they use respectively, will be referred to as "Alice" and "Bob". The off-line transaction protocol controls the exchange of protocol messages between the two tamper-protected semiconductor modules, which includes messages for transferring electronic tokens between the two tamper-protected semiconductor modules via a peer-to-peer link. The off-line transaction protocol further is a delayed-true fair protocol. In case of an interruption of the off-line transaction protocol, each tamper-protected semiconductor module can autonomously terminate the off-line transaction protocol in either a fan- state in which the transfer of the electronic tokens is either successfully completed or the initial state prior to starting the transaction is, or in an unfair state for the respective tamper-protected semiconductor module in which one or more electronic tokens is/are irrevocably lost at the respective tamper-protected semiconductor module.

As will become more apparent from the example off-line transaction protocol discussed below in the following sections, the states in which the protocol ends "fair" are the states denoted by IDs Ola, 02a, 03a, 04a, 05a, 06a, 11a and 12a shown in Figure 14, and IDs 01b, 02b, 03b, 04b, 05b, 10b and l ib shown in Figure 15. The states in which the protocol terminates in an unfair state for the respective tamper-protected semiconductor module in which one or more electronic tokens is/are irrevocably lost at the respective tamper-protected semiconductor module are the states denoted the with IDs 07a, 08a, 09a and 10a shown in Figure 14, and IDs 06b, 07b, 08b and 09b shown in Figure 15.

From an abstract point of view, the off-line transaction protocol goes through a "phase-change" transition during its run:

- The off-line transaction protocol starts collecting information about the deal Alice and Bob want to negotiate. Either initial assumption about the deal state is "no deal". Then - during the protocol-run - both parties "learn" about each other more and more by adding non-repudiation objects to their local deal basket. If the off-line transfer protocol fails in this phase, the protocol terminates in one of the states referenced within the case IDs Ola, 02a, 03a, 04a, 05a or 06a as shown in Figure 14, or

IDs 01b, 02b, 03b, 04b or 05b as shown in Figure 15.

- Starting with ED 07a (see Figure 14) and ID 06b (see Figure 15), the off-line transaction protocol enters a position where a failure results into an immediate termination (both parties "no deal") of the off-line transaction protocol with the "price" in which one or more electronic token(s) is/are irrevocably lost at the respective tamper-protected semiconductor module (in case ID 07a for Alice and in case ID 06b for Bob). - The cases with the IDs 08a, 09a, 10a (as shown in Figure 14) and IDs 07b, 08b 09b (as shown in Figure 15) can result into a so called "weak deal" as mentioned and explained in detail later for one or even both transacting entities.

- The successful cases as represented with the IDs 11a, 12a (as shown in Figure 14) and IDs 10b, 1 lb (as shown in Figure 15) transfer both parties Alice and Bob into a successful "deal" state.

In the following passages exemplary embodiments of the invention will be described that provide an overview of the off-line transaction protocol for use in an eCash system and the format and contents of the messages exchanged at a protocol-run of the off-line transaction protocol. In this example, the electronic tokens can be considered to represent eCoins, i.e. an electronic representation of coins and bank notes. It should be noted that the off-line transaction protocol discussed below with respect to an eCash system is not limited to such use, as indicated previously. The off-line transaction protocol described below may be used for transferring electronic tokens in general, not just eCoins.

1.4.5.1 Protocol Defin itions

The wording of basic notation and the off-line transaction protocol discussed is following below symbology and notations, optimized for the eCoin exchange, but not limited to such application.

Symbol Interpretation

A Principal 'Alice', the protocol message originator.

B Principal 'Bob', the protocol message recipient.

TTP Principal 'ΤΤΡ'. This can for example be the issuing authority of the

(Trusted Third electronic tokens (i.e. the so-called eMint of the eCoins in the eCash

Party) system)

NodelD(X) Uniquely distinguished physical node identity of entity 'X'. The physical node identity may identify a peer-device 'X' containing a tamper-protected semiconductor module (only) in the Pairing Phase during possible out-band negotiations (e.g. using RFIDs/NFCs). Should be 128-bit sized.

NetlD(X) Uniquely distinguishing logical network identity of entity 'X'. This may for example be a network header-based ID addressing for in-band network operations, i.e. the same channel can be used for pairing and the subsequent protocol steps. Should be 128-bit sized.

TID _X Transaction identification 'TID _X ' (not necessarily globally unique) used

between Alice and Bob to maintain context between them. 'X' is the issuing principal. The TID may be a 32-bit unsigned integer. TSID Transaction and session identification, a n-bit nonce (e.g. at least 32-bit) valid for a single protocol-run only. The TSID may for example be obtained by the following exemplary concatenation:

'TSID = X((TID _A xor TTD _B ) || DTC _A || DTC _B || NetlD(A) || NetlD(B) || NodelD(A) || NodelD(B))'.

H(m) Hash 'H' based on a collision & 2 ^nd pre-image resistant one-way iterated cryptographic function of 'm'.

C(m) Hash 'C based on a collision and 2 ^nd pre-image resistant symmetric block cipher function of 'm\

X(m) e {H(m), Denotes either keyed HMAC 'H(m)' (e.g. HMAC-SHA-512) or block C(m)} cipher CMAC 'C(m)' (e.g. CMAC-AES-256) of the message 'm'.

¾ := {X(m)} _K 'Sx' is a digital signature of data (message) 'm'. 'K' is a private key, 'X' is the principal. The result of signature verification is TRUE, if the signature is valid and FALSE otherwise.

DTCx Date Time Code used to find outdated elements. 'X' is the principal.

TimeStamp _x Time measurement for current transmission channel properties of party 'X'.

TimeStamp _x is for example 32-bit in size (UTC at start plus increment since then).

A -» B:m Principal 'Alice' transmits message 'm' to 'Bob' (no guarantee of delivery).

A «- B:m Principal 'Alice' fetches message 'm' from 'Bob' (no guarantee of receipt). ni] II m ₂ Concatenation of items 'mi' and 'm ₂ ' in that order.

M When 'x' is a set, then [x ^~ ] denotes the number of elements of 'x' else

Round(log ₂ (x) + 0,5).

|m| The bit length of the message 'm'. xor or Θ Bitwise logical 'exclusive-or'. randO True physical random generator, usable for cryptographic purposes.

{Msg.Elem.} This is an optional message element, can be omitted in case of no need, e.g.

the change secret or for the viral inducted spreading of updates (CRL et al.). ψ Unsigned integer nonce 'ψ' generated by the rand function. Should be 32- bit sized or greater.

SALT* Nonce 'SALT _X ' used in the generation process of the premaster-secret. 'X' is the principal. Should be 32-byte sized or greater.

#(x) Variable 'x' is generated afresh.

Λ(χ) Restrict the validity of the variable 'x' in time being usable only temporary.

/App,Phase,Cmd,Count A flag indicating the purpose of a message using specific construction

logic.

App Bit pattern identifier serving as Start-of-Message delimiter for the protocol.

For example, 96-bit sized. For messages [01-04]: could be defined as App := "Tb II Ver || Rev'

Tb (Teleportation Identifier to flag the first four messages, For example, 64-bit sized.

Beam)

Ver Version number of the off-line transfer protocol. For example, 16-bit sized.

Rev Revision number of the off-line transfer protocol. For example, 16-bit sized.

Phase Protocol phase stage (Pairing, VPN/VPC, Exchange, Commit). For

example, 8-bit sized.

Cmd Protocol message type (Req, ACK, Value, Info). For example, 8-bit sized.

Count Number of protocol phase stage message (1, 255). For example, 16-bit sized.

Table 2: Symbols used in an Off-line Transaction Protocol for an eCash System and their meaning. It is defined and assumed for exemplary purposes only that

- Alice is always the off-line transaction protocol initiator and that Bob is always the off-line transaction protocol responder.

Alice can be the source or the sink of the main secret (or value). Bob is than acting in the opposite role, the sink or the source for the main secret (or value), respectively.

The change secret (or value) is always supplied by the party acting in the role of the sink of the main secret (or value).

In case of an eCoin system, the party acting in the role of the source of the main secret (or value) is denoted to be a payer. The other entity in the role of the source of the change secret (or value) is denoted to be a payee, respectively. Complex objects exchanged or referenced by the exemplary off-line transaction protocol are listed and explained in the Table 3 below.

Table 3: Objects exchanged or referenced by the exemplary teleportation protocol and their meaning. 1.4.5.2 Protocol Cases

As will be outlined below once again the protocol may have two different protocol cases, depending on whether Alice or Bob is acting as the payer (being the electronic token source providing the "main secret" of the transaction) and who is the payee (being the electronic token sink receiving the "main secret" of the transaction and optionally providing their "change secret") in combination of being the protocol initiator or responder.

Please note, the electronic token source and electronic token sink is defined by the electronic token's value: A "main secret" should be of comparatively of greater value than the change secret in the eCash system, or in other words, the monetary value of the eCoins to be provided from the electronic token source is higher than the monetary value of the change eCoins to be provided by the electronic token sink.

In protocol case [a], Alice sends the electronic tokens (eCoins) in her role as payer while Bob receives the electronic tokens in his role as payee. The first message after the establishment of the VPN/VPC in the Negotiation Phase can be used for a protocol flow inversion passing the initiative over to Bob. It is possible to reduce the electronic token exchange only to transfer of electronic tokens from Alice to Bob, without any "change electronic token" in return. Please note, even if there is no "change electronic token" returned by Bob, Bob provides an electronic receipt (eReceipt) as acquittance for the transfer of the electronic token(s) (i.e. the payment in the eCash context) to Alice. Figure 5 shows the message flow of the Electronic Token Transfer Phase (Value Data Transfer Phase) and the Acknowledgement Phase (Confirmation Phase) of the exemplary off-line transaction protocol for the protocol case [a].

In protocol case [b], Bob is the payer and Alice receives the electronic tokens in her role as payee. The rest of the protocol-execution is again identical to the first sub case [a], exchanging the position of Alice and Bob. Figure 6 shows the message flow of the Electronic Token Transfer Phase (Value Data Transfer Phase) and the Acknowledgement Phase (Confirmation Phase) of the exemplary off-line transaction protocol for the protocol case [b].

It is assumed for exemplary purposes, Alice is always in the role of a protocol initiator and Bob dedicated to the role of a responder. If the opposite is needed, the roles between Alice and Bob are simply reversed. The adaptation to the electronic token source role (secret source) or electronic token sink role (secret sink) introduces slight changes to the protocol: In protocol case [a] Alice is the source of the "main secret" (payer), which reverses - see Figure 5 - to the electronic token sink role (payee) in case [b] - see Figure 6.

1.4.5.3 Message Format of the Transaction Protocol Messages

In an exemplary embodiment of the invention, each transaction protocol message of the off-line transaction protocol comprises a header wherein the header indicates (and differentiates) the application of the off-line transaction protocol (from other applications) and contains also a bit pattern identifier for "start-of-message" delimiter purposes. The header further may identify for example at least one of the contents of the respective transaction protocol message, the phase of the off-line transaction protocol to which the respective message belongs, and the respective transaction protocol message in the predetermined sequence of messages of the off-line transaction protocol.

Optionally, the header could further identify the version of the off-line transaction protocol executed by the respective tamper-protected semiconductor modules, and the tamper-protected semiconductor modules agree on a compatible off-line transaction protocol version based on the indicated version in the header. This may be useful for example if there are different versions of the off-line transaction protocol provided in the transaction systems, where newer protocol versions may be designed backward compatible to earlier versions. In case the version of the off-line transaction protocol running at the respective tamper-protected semiconductor module is identified by the message headers, the two tamper-protected semiconductor modules performing the transaction can conclude on a protocol version executable by both tamper-protected semiconductor modules to enable the transaction.

Further advantageous features of the message formats of the respective transaction protocol messages will become more apparent from the more detailed description below.

1.4.5.4 Design of the Off-line Transaction Protocol

As shown in Figure 4, and has also been indicated in the protocol summary above, the exemplary offline transaction protocol may be divided into five phases, arranged in top-down order, following an ascending timeline of interactions for the payer (i.e. first CASTOR/tamper-protected semiconductor module) and the payee (i.e. second CASTOR/tamper-protected semiconductor module). A general survey of the protocol steps of the CASTORs involved in the transaction depending on being an initiator or a responder, in combination with spending or receiving eCoins (or in more general, transmitting or receiving electronic tokens) is presented in Figure 4: The message flow relates to the case, where the initiator of the protocol is the payer (protocol case [a]).

In this protocol case [a], Alice starts the Pairing Phase by transmitting an invitation request to Bob (e.g. message [01], as discussed below), so Alice can be regarded as the initiator of the transaction. Please note that the names Alice and Bob are only used for exemplary purposes and do indeed denote two users, respectively, their respective tamper-protected semiconductor module executing the off-line transaction protocol. If Bob answers Alice's invitation request with the correct response (e.g. message [02], as discussed below), both tamper-protected semiconductor modules are paired for an off-line transaction protocol-run.

Following the Pairing Phase, Alice and Bob exchange two messages (e.g. messages [03] and [04], as discussed below) in the VPN/VPC Setup Phase displayed in Figure 4 (or the Secure Connection Establishment Phase). If these two messages are exchanged successfully, an application-based VPN/VPC will be established and activated to transport every protocol communication beginning with the next message until the last message (in a protected form). Please note that Figure 4 only shows the simplified transaction workflow which is limited to the executing of the off-line transaction protocol. Figure 4 shows the message flow for the initiator on the left and for the responder on the right. As a first action for the transaction - and not shown in Figure 4 - it may be assumed that the originator (Alice) collects all information needed to conduct the transaction and thus pushing the off-line transaction protocol for transferring the electronic tokens. This collection of information on the transaction is done before entering the Pairing Phase. Consequently the recipient (Bob) has to provide all requisite information for the transaction including his authorization of the transaction before the Pairing Phase of the off-line transaction protocol can be acknowledged. It is possible to make this anticipatory available.

This pre-negotiation of the transaction in advance of the actual transfer of the electronic tokens subject to the transaction by means of the off-line transaction protocol may be performed in various fashions. Upon the two parties to the transaction having exchanged all necessary information for the transaction and have authorized same, the relevant information of the transaction may be provided to the CASTOR (i.e. the tamper-protected semiconductor module) via an I/O-port thereof and the execution run of the off-line transaction protocol is triggered.

Following this application-based VPN VPC Alice and Bob enter the Negotiation Phase. The Negotiation Phase is inter alia used to negotiate the transaction, e.g. the electronic tokens to be exchanged. For example, in the eCash context, this phase of the off-line transaction protocol is used to allow Alice and Bob to determine the denomination of eCoins and change eCoins (please note that the eCoins are atomic), that need to be exchanged to fulfill the receivable of the transaction.

The Negotiation Phase may not necessarily negotiate the receivable of the transaction itself. This may be done beforehand, i.e. before executing the off-line transaction protocol, as outlined above. Rather the Negotiation Phase is used to negotiate how the receivable of the transaction is transferred between the two tamper-protected semiconductor modules. The Negotiation Phase may be further used to exchange the user certificates of Alice and Bob and/or to negotiate the ability to conduct the transfer of the electronic tokens between Alice and Bob using the Capability Flag Vectors (CFVs) as will be outlined below in further detail.

As indicated in Figure 4, Figure 5 and Figure 6, the negotiation of the transaction details may use a special container format, the so-called eDoc already mentioned earlier herein. Basically, the eDoc defines a flexible container format to exchange the necessary information (e.g. CFVs, denomination of eCoins and change eCoins, etc.) for allowing the CASTORs of Alice and Bob to conclude on how to conduct the electronic token transfer. In one exemplary embodiment, the Negotiation Phase exchanges the messages [05] and [06] which may be slightly different for protocol cases [a] and [b] as will be outlined below and as indicated in Figure 5 and Figure 6.

Once the CASTORs of Alice and Bob could successfully agree on how to conduct the actual transfer of the electronic tokens (eCoins), they enter the so-called Electronic Token Transfer Phase (Value Data Transfer Phase) in which the electronic tokens agreed on in the Negotiation Phase are exchanged. As indicated in Figure 4, Alice and Bob may also process the respective received electronic tokens (eCoins), for example to confirm that the correct denomination of electronic tokens agreed has been transferred, to confirm that the transferred electronic tokens have the correct identifying descriptor item and or to confirm that the transferred electronic tokens have not been revoked or are not expired yet. As further indicated in Figure 4, Figure 5 and Figure 6, the eDoc is continuously updated to document the state of the transaction and is exchanged by Alice and Bob (on a ping-pong base). The two messages for exchanging the electronic tokens (i.e. the eCoins of payer and the optional change eCoins of the payee) may be implemented as exemplified by messages [07] and [08] the contents of which may again depend on the protocol case as shown in Figure 5 and Figure 6.

After having transferred the electronic tokens (eCoins), the off-line transaction protocol enters into the Acknowledgement Phase (Confirmation Phase) in which Alice and Bob confirm the successful transfer of the electronic tokens/receipt of messages by sending acknowledgements. In the exemplary embodiments shown in Figure 4, Figure 5 and Figure 6, three acknowledgment messages are exchanged between Alice and Bob. These acknowledgment messages may be for example implemented as messages [09], [10], and [11] discussed below.

In the following the individual five phases of the exemplary off-line transaction protocol will be described in further details. Please also note, in the following it is assumed in one exemplary embodiment of the invention that (successful) reception of a message does not only mean, the party receiving the message has received the message through the communication channel successfully, but also that the message passed an integrity check successfully. This message's integrity check may for example include checking for the correct setting of the message type flag, the correct setting of the running message counter Ψ, and the correct TSED in the message. Furthermore, where signatures or certificates are involved, e.g. when signing (complete) messages or message objects (e.g. eCoins, eDoc sections, etc.) the integrity check may further include a verification of the signature's and certificate's validity respectively. The validation of certificates may also include checking them against a Certificate Revocation List.

If the integrity check is not successful, the respective party may for example cause a fail-stop of the off-line transaction protocol, i.e. it does not send any further message so the respective other party will also time out and interrupt the off-line transaction protocol-run, too.

1.4.5.5 Pairing Phase

In general, the Pairing Phase may be considered a procedure where two mutual unknown and idle peers (CASTORs) indicate their pairing-requests (i.e. messages [01] and [02]) by mutually exchanging their CASTOR root certificates (also known as RCA certificates or Type-VI certificates) in combination with their node-ID (e.g. from the transceiving node interface used to exchange (only) the pairing messages; could be a MAC address used on the network interface, a Mobile Directory Number (MDN) etc.) and network-IDs (e.g. an IP address) with an Evidence of Origin (EoO) proof done by adding a signature s _A and SB to all unencrypted messages sent. This signature prevents a possibly successful Man-In-The-Middle-Attack (MITMA). All signatures and certificates are protected by an architecture inspired by PKI X.509, version 3. The CASTOR certificates are also referred to as Type- VI certificates, RCA certificate or CASTOR root certificate, and an exemplary implementation thereof will be described below in further detail.

Additionally, the CASTORs may further exchange their timestamps and a SALT for a logical time bind of the protocol-run in combination of a unique transaction session ID (build from both SALTed TIDs). The timestamps at the end of messages [01] to [04] are used to gather statistical information about channel throughput. Furthermore, messages [01] and [02] comprise the CFV _A and CFVB objects of Alice and Bob, respectively. These are the effective Capability-Flag- Vectors mutual exchanged, and are used at the respective other CASTOR to calculate the greatest common regulated crypto- strength allowed by both CASTORs for the installation of the VPN/VPC in the subsequent VPN VPC Setup Phase.

Using her CASTOR, Alice starts this process to enter the payment transaction by collecting and selecting all necessary information. Then her CASTOR tries to connect to the targeted CASTOR of Bob by using available kinds of contactless mobile models like the remote or the proximity mobile payment communication methods (e.g. RFID/NFC, WLAN, etc.) or wired non-portable infrastructure model based methods (e.g. Ethernet, Powerline, etc.). In more detail, Alice sends the first "invitation" message [01] marked with the flag '/App,Pairing,Req,i \ indicating her intention to pair the two CASTORs followed by a the CASTOR root certificate of her CASTOR and her effective Capability-Flag-Vector CFV _A . Alice's CASTOR root certificate (Cert _A [Type-VTJ.obj) certifies the identity of her product platform (e.g. an CASTOR or the eWallet comprising the CASTOR). If her product platform is found being involved in inappropriate activities, same product platform's certificate will be entered in a blacklist (Certificate Revocation List, CRL) maintained by the TTP (RCA). The CRL may be distributed in the eCash system by passing on system update information (as will be described below in further detail - see section "Negotiation Phase").

Accordingly, Bob may check whether Alice's CASTOR root certificate is blacklisted and, if yes, may interrupt the off-line transaction protocol immediately. In an alternative implementation, Bob may proceed running the off-line transaction protocol, until he is able to provide Alice with the CRL blacklisting Alice's CASTOR root certificate as part of the system object update and may then interrupt the off-line transaction protocol.

The CFV _A may be a calculated parameter needed to handle worldwide region-depending crypto- regulations. This allows support and enforcement of different local legislation in case of cross-border connections by setting the connecting VPN VPC's cryptographic strength to the highest common denominator. Please note, it may also be possible to inhibit VPN/VPC protection for the exchange of the transaction protocol messages, e.g. by the creation of a special CFV _Party set in the user certificates of Alice and Bob. Irrespective of whether a VPN VPC protection is used, it may be possible to protect the electronic tokens (eCoins), respectively; the transfer may use a separate cryptographic protection method: All electronic tokens to be transferred may be encrypted prior to their inclusion to the respective transaction protocol message transferring same.

Within the initial pairing message [01] two identifiers indicate Alice's (her CASTOR's) (physical) identity:

- The NodelD address refers to the physical part of a network-addressing scheme. It can be the Ethernet-MAC address taken from Alice transceiver on her Network Interface Card (NIC) of the device housing of the CASTOR, her physical Bluetooth ID, or even a Mobile Directory Number (MDN) and

the NetID address referring a statically or dynamically assigned IP/DNS network address.

This information is sufficient for a simple Point-to-Point (P2P) association during this early transaction phase. An in-depth user-certification-based pairing may be implemented later in the VPN VPC-protected transaction part. Table 4 exemplifies the initial pairing message [01] sent by Alice.

Table 4: Pairing step 1.

Bob answers Alice's pairing message [01] with the pairing acknowledge message [02], which is indicated by the flag ' _A pp4>airmg,ACK,2' as shown in Table 5 below and Bob approves the pairing request (reasons for not approving may be implementation and policy dependent). The structure of this message is similar to the previous one. The signature 'SB' servers again as EoO proof to prevent MITMA. Table 5 exemplifies the pairing message [02] returned by Bob to Alice. Msg. Transfer Elements Comments

Flag indicating "Pairing acknowledge".

Cert _B [Type-VI].obj Bob's Type- VI CASTOR root certificate.

Bob's effective calculated set of

CFV _B

Capability-Flag- Vectors.

Uniquely distinguishing principal

B A NodeID(B), NetID(B)

02 recipient identity.

[in clear]

DTC _B Bob's local time stamp (e.g. 64-bit).

Transaction identification salt 'ΤΠ¾'

#(Tro _B ) (e.g. 32-bit).

Signature of Hash(Msg. 02) for all

S _B := A({X(Msg. 02)}Ks:CASTOR:SUDI,prv) elements, except 'SB' .

Table 5: Pairing step 2.

After Alice's platform has successfully received message two, and if Bob's CASTOR root certificate is not blacklisted in the CRL pool, both entities are capable

- to mutually verify their tamper-protected semiconductor modules (CASTORs) by providing a proof of authenticity,

to detect any MITMA until the end of the protocol,

to adapt to local crypto laws and regulations.

If Bob's CASTOR root certificate is blacklisted, Alice's CASTOR may interrupt the off-line transaction protocol's run immediately. In an alternative implementation, Alice may proceed with the off-line transaction protocol until she has provided the CRL that is blacklisting Bob's CASTOR root certificate to Bob's CASTOR as part of the system object update, and may then interrupt the off-line transaction protocol.

If the Pairing Phase is successful, initiator Alice and responder Bob are mutually connected and trust each other's CASTOR. If a CASTOR has been successfully paired and is thus connected to another CASTOR, the already connected CASTORs may ignore any further pairing request during the current run of the off-line transaction protocol.

The exemplary pairing-mechanism described above allows two CASTORs to enter an out-of-band pairing process e.g. introduced by RFIDs/NFCs before they switch connection over to an in-band communication to improve range and bandwidth. In other words, pairing of two CASTORs (respectively their housing eWallets/devices) may be done using one communication technology (e.g. RFID/NFC) while the exchange of all transaction protocol messages following the Pairing Phase may be established using an different communication technology (e.g. WLAN, Bluetooth, etc.). Additionally, the indication of two IDs (NodelD and NetID) in the pairing messages may be used to prevent from the vast majority of spoofing attacks during connection requests. DTCA contains the current date and time for the generation of message [01] and can thus be used to prevent replay attacks. Further, the freshly generated unique transaction session identifier TTD _A can be used later as a premaster-secret in the session key generation algorithm. It may also be used to compute the transaction session identification number TSID in the common secrets exchange step.

The last element in this message [01] can be considered to provide an EoO proof. By adding the signature SA over all unencrypted message elements of message [01] by Alice, a protective measure to prevent a Man-In-The-Middle-Attack (MITMA) is provided. This signature is constructed using a cryptographic hash 'X' in combination with the private signing key part 'KS _: CASTOR:SUDI,PTV' of Alice's CASTOR. This fresh generated signature allows Bob's CASTOR to verify, that this message is really sent from Alice's CASTOR.

Figure 7 exemplifies the Pairing Phase distingusihing between actions to be taken by Alice and Bob (the users), their CASTORs (eWallets), and their NetNodes (i.e. the devices housing the CASTORs of Alice and Bob):

1. Alice collects all information to conduct a payment and initiates it. All of this information is transferred to the CASTOR of Alice ahead of the teleportation protocol invocation to prepare the execution of the off-line transaction protocol. In one exemplary implementation, the information collected by Alice includes at least one of NodelD(B) and NetID(B) so that the CASTOR can autonomously contact the CASTOR of Bob and forward the receivable of the transaction (i.e. the amount of money to be payable by Alice for protocol case [a], respectively Bob for protocol case [b]).

2. Alice's CASTOR receives all information and uses (a part of) it to create a pairing request message [01].

3. The pairing request message [01] is transferred through a network to the target's NetNode (i.e. the device of Bob housing the CASTOR (eWallet)). Please note that proper routing of the pairing request message [01] to Bob may be based on the available information, e.g. in case at least one of NodeID(B) and NetlD(B) is known to Alice.

4. Bob's CASTOR (e Wallet) receives and processes the pairing request message [01]. This may for example include checking Alice's CASTOR root certificate against a blacklist of revoked

CASTOR root certificates.

5. The target CASTOR of Bob requests Bob (e.g. using a display and input means) to authorize the transaction and waits for an authorization or timeout. It is possible for Bob to pre-authorize transactions (according to user-specific rules) - see enumeration point 6 below. 6. If Bob accepts the pairing request by Alice (respectively, the transaction), Bob supplies further required data for the transaction (if any) and his authorization of the payment. Please note that it may be possible to automate the authorization for certain applications (steps 5 and 6), respectively for pre-defined CASTORs: For example, it may be possible to configure a CASTOR to accept by default transaction requests of one or more pre-determined CASTORs (e.g. identified by means of their CASTOR root certificate) without interacting with the user, i.e. can pre-authorize transactions for certain applications (e.g. daily usage of public transportation) and/or CASTORs (e.g. known PoS). The user may for example be also allowed to set limits to the maximum amount of money transferred (per time frame) to achieve some control on the amount of eCoins transferred (e.g. a user could pre-authorize the CASTOR of the local underground transport system to charge a fare for transportation up to a specific amount of money per time period (day/week/month)).

7. Bob's CASTOR replies sending a pairing message [02] to the CASTOR of Alice (which may contain additional data for the transaction and an (implicit) authorization of the transaction).

8. The pairing message [02] is transferred through the network to Alice's NetNode.

9. Alice's CASTOR receives and processes the pairing message [02]. If successful, the connection between Alice and Bob is established. Please note, strictly speaking the next message [03] allows Bob to confirm pairing has been successful.

The presented pairing mechanism is an example of how to connect and bind two CASTORs for a single off-line transaction protocol's run. There are in principle many (unlimited) ways to perform the pairing of the CASTORs, and the invention is not limited to the presented pairing mechanism. The pairing mechanism above is advantageous as it offers the technical edge of being effective (just two messages) and secure (exchange of a certificate in combination with signed - and later possibly encrypted - messages) while ruling out MITMAs.

It should be noted, the exemplary implementation of the Pairing Phase as discussed above is not limited to the use of the off-line transaction protocol in an eCash system, however the off-line transaction protocol's Pairing Phase is usable in any application.

1.4.5.6 Secure Connection Establishment Phase (also: VPN/VPC Setup)

The purpose of the optional VPN VPC Setup Phase is to establish an application based bidirectional VPN/VPC between Alice and Bob allowing them to communicate securely, where third parties (MITMA) are not able to intercept and decode messages exchanged between them. Protocol messages sent via the VPC/VPN are encrypted and/or signed by the CASTOR sending the protocol message by means of session keys, the generation of which is based on the information exchanged in the VPN/VPC Setup Phase. Alice assembles message [03] by starting with the '/ _APP , _V P _N ,R«I,3' flag, indicating the VPN VPC setup request, followed by a transaction session ID 'TSID'.

Using the rand function Alice creates a fresh ping-pong running message counter 'ψ'. The running message counter 'ψ' is used to identify the correct order of all subsequent messages belonging to this off-line transaction protocol's run. The running message counter 'ψ' is incremented (modulo 2 ³² -l, according to the 32 bit size) with every message exchanged between the two peers during the protocol's run. The use of the running message counter 'ψ' may be regarded as another measure to prevent replay attacks.

Alice's public key part 'K _Q ^C _AS TOR' of the freshly generated ephemeral key-pair is added to the VPN/VPC setup message [03]. The freshly generated 'SALT _A ' object is used as part of the premaster secret to generate keying material needed for the secure channel between Alice and Bob. The ephemeral key-pairs, the static key-pairs, and the 'SALT _A ' object are used by Alice and Bob to generate the session keys for the VPC/VPN. A 'TimeStamp _A ' identifies the moment of starting the signature generation of this message. The freshly computed signature s _A is also added to the payload of VPN/VPC setup message [03]. Table 6 below shows an exemplary implementation of VPN/VPC setup message [03].

Table 6: VPN/VPC setup step 1.

Bob completes the pairing by creating a VPN/VPC acknowledge message [04], which is essentially similar to message [03] from Alice. Table 7 shows an exemplary implementation of a VPN/VPC acknowledge-message [04]. Please note, Bob's ephemeral key-pair, his static key-pair, and 'SALT _B ' object are used by Alice and Bob to generate the session keys for the VPC/VPN.

Table 7: VPN/VPC setup step 2.

With the exchange of messages [03] and [04], the session key generation algorithm will be able to generate all secret session keys needed to establish the VPN/VPC. The introduction of timestamps enables the tamper-protected semiconductor module (eWallet) to make an (implicit) realistic assumption of the channel throughput. After Alice has successfully received message [04] from Bob, both parties obtain

- the corresponding party's public static PK DLC key part within the corresponding party's CASTOR root certificate (Type- VI),

- the other party's freshly generated public ephemeral DLC key part

- the ability to generate the secret VPN/VPC session keys, as outlined below.

Both parties are now able to

process the key agreement scheme,

generate the shared secrets (cryptographic session keys),

switch over from a clear to a safe VPN/VPC encrypted and authenticated communication mode.

After completing the off-line transaction protocol's pairing part, an application based VPN/VPC will be established between Alice and Bob. In this example, the VPN/VPC will use four different session keys, two session keys for encrypting the messages in each direction (A→B and B→A) and another two different session keys for message authentication.

After having established the VPN/VPC, the off-line transaction protocol differentiates slightly between the two protocol cases [a] and [b]. - Protocol case [a] is executed only in the case the protocol initiator is the source (provider) of the "main secret" (eCoins).

Protocol case [b] is executed only in the case the protocol initiator is the sink (receiver) of the "main secret" (eCoins).

Please note, the VPN VPC Setup Phase ends with message [04] from Bob to Alice, because Alice, per definition, is always the protocol initiator. That means, Alice also has to issue the next message after the message [04]. For protocol case [b] this is already the appropriate message order. However, for protocol case [a] it is required that Bob issues the next message. To solve this case to avoid the construction of a contradiction for protocol case [a], Alice passes over the flow initiative to Bob. This flow reversion is done with message [05a] (discussed below), which has no logical counterpart in protocol case [b].

As already indicated above, the two CASTORs of Alice and Bob use a key generation mechanism to generate the session keys for the off-line transaction protocol's run. The CASTORs may for example support the following different primitives and methods for a Discrete Logarithm Cryptography (DLC)- based key establishment scheme:

C(2,2,ECC,CDH): This classifies a full unified modified Diffie-Hellman hybrid scheme (as used within the Elliptic Curve Diffie-Hellman, ECDH or Elliptic Curve Digital Signature Algorithm, ECDSA) with two ephemeral keys and two static keys which use Elliptic Curve Cryptography (ECC) and a Cofactor Diffie-Hellman (CDH) primitive.

- C(2,2,ECC,MQV): This classifies the full unified (Cofactor) Menezes-Qu-Vanstone hybrid scheme (as used within the Elliptic Curve Menezes-Qu-Vanstone, ECMQV) with two ephemeral keys and two static keys which use Elliptic Curve Cryptography (ECC) and a Menezes-Qu- Vanstone (MQV) primitive.

Furthermore, in case a session key for the encryption of the eCoins is needed, a DLC-based key establishment scheme may also be used to generate symmetric session keys for encrypting the eCoins to be transferred prior to their inclusion with the respective protocol messages. Alternatively, a CASTOR may encrypt the eCoins prior to their inclusion to a protocol message using the respective other CASTOR'S root certificate public key parts or the public protocol partner's user certificate key part.

Session keys for encrypting the eCoins may be symmetric session keys of an AES symmetrical encryption scheme.

Please note, the parameters for the DLC-based key establishment scheme utilize public/private ephemeral key-pairs (their public parts (see key class of K _QE:JHX ) that are exchanged by Alice and Bob in messages [03] and [04]), and public/private static key-pairs (their public parts (see key class of Q _S3D[X ) that are exchanged by Alice and Bob in messages [01] and [02]), contained in the CASTOR Root certificate Type- VI in combination with co-factor parameters (ECCDomainParamTable), also contained in the respective Type-VI certificates. Both are to be exchanged between Alice and Bob in a safe manner, e.g. both as certified parts of one certificate. The nonce generation and exchange as premaster secret (SALTs) by Alice and Bob in messages [03] and [04] collateralize the key generation process. This way MITMA can be prevented.

Please note, different session key generation mechanisms may be supported or used to generate the session keys for the VPN/VPC, too.

Figure 8 exemplifies the VPN VPC Setup Phase distingusihing between actions to be taken by Alice and Bob (the users), their CASTORs (eWallets), and their NetNodes (i.e. the devices housing the CASTORs of Alice and Bob):

1. Alice's CASTOR (eWallet) sends a VPN VPC setup message [03] to Bob's CASTOR (eWallet) and waits for an acknowledgment or timeout.

2. The VPN VPC setup message [03] is transferred through a network to Bob's node.

3. Bob's CASTOR (eWallet) receives and processes the VPN/VPC setup message [03].

4. Bob's CASTOR replies with an VPN/VPC acknowledge message [04] to Alice.

5. The VPN/VPC acknowledge message [04] is transferred through the network to Alice's node.

6. Alice's CASTOR receives and processes the VPN/VPC acknowledge message [04], the VPN/VPC for Alice is established. Please note, the next message [05] from Alice to Bob will confirm the VPN/VPC establishment for Bob.

1.4.5.7 Negotiation Phase

After the Pairing Phase and the VPN/VPC Setup Phase, if executed, Alice's CASTOR executing the off-line transaction protocol collects the information available to negotiate the transfer details for electronic tokens. In the eCash context, this details may for example contain information about the goods or services, the currency of the payment (in a multi-currency eCash system), and the price. The information on the price (and currency) allows Alice to determine the denomination(s) of the atomic eCoins available to her CASTOR (and change eCoins to be returned by Bob) that could be transferred to execute the payment.

The so-called lock timeout period (also known as "WeakDealLockDelay" or WDLD) is another parameter that may be negotiated in the Negotiation Phase. This parameter defines a period in time in which the CASTORs need to re-contact each other to resolve weak deal states in case of an interruption of the off-line transaction protocol. This re-contacting to resolve the unfinished transaction in case of a weak deal is not part of the off-line transaction protocol. So to speak, the lock timeout period defines the period of time in which Alice and Bob can resolve potential unfair terminations of the off-line transaction protocol in case of an interruption on a peer-to-peer basis, i.e. before fairness reconstruction via a fairness arbiter (trusted third party, e.g. the issuing authority of the eCoins (eMint)) becomes necessary to reconstruct the fairness. If the lock timeout period is not a predetermined value, Alice and Bob have to agree to this value in advance before entering into the Value Data Transfer Phase. The lock timeout period is negotiated using the exchange mechanism of the eDoc objects in its pre-flow incarnations (see messages [05] and [06], Table 71, Table 72 and Table 73). Alternatively, the lock timeout period may also be negotiated by other means prior to the off-line transaction protocol's execution and may be provided to the CASTORs as a restricted parameter for the transaction.

Please note, although the Pairing Phase and the VPN/VPC Setup Phase may have been executed successfully, the further transaction steps and the general possibility of exchange of electronic tokens are not guaranteed. Reasons for not being able to conduct the transaction can be manifold and include for example:

- the token memory's storage capacity in the CASTOR or eWallet/device housing is reaching its limit (no more free space),

- a denomination distribution of eCoins is unfavorable for which reason the payment cannot be conducted,

- the CASTOR/eWallet simply does not contain enough value (eCoins),

the types of eCoins within the intended transaction are incompatible (e.g.€ vs. US-$),

Alice and Bob cannot agree on the so-called lock timeout period (also "WeakDealLockDelay", WDLD),

a notified eCoin cannot be authenticated, e.g.

1. due to a missing or invalid batch production certificate (CRL) of the issuing authority (Type- VII certificate),

2. due to counterfeited money (CRL of Type-VOT), or

3. due to a blacklisted issuing-authority/eMint (CRL of Type-rV).

some policy would be violated if this transfer is allowed to be performed, etc.

The problem of finding the correct denomination of eCoins is also known in literature as exact payment, k-payment or n-spendable eCoins. In general, the solution of this problem is on the one hand depending on the algorithm deciding on the denomination of the eCoins upon withdrawal from the user's "bank" - this case is outside the scope of this invention. On the other hand, the solution to this problem is depending on the eCoin dispensing algorithm within the CASTOR when spending the eCoins. Regarding this latter dispensing algorithm, in one exemplary embodiment of the invention, the exact payment problem is solved following certain policies or transfer-rules: find fitting combinations of eCoins allowing to conduct the exchange (payment), compile a list of suitable combinations, ranking from the best to the worst solution („Ranked Suggestion List" (RSL)),

- bind the exchange process of these lists equal to not more than three iterations,

- minimize the eCoins' exchange for the transaction (no change, whenever possible),

- use as much ..higher value" eCoins as possible in order not to run out of "low value" eCoins, allow over-spending and under-charging as a transaction enabling rescue method, and

avoid combinations lowering the possibility for being able to conduct a subsequent payment.

The creator of the initial eDoc (so-called eDoc[I] object) has all necessary information to compile a first RSL of eCoin combinations for "paying". The RSL may be determined based on the policies outlined above. The initial RSL includes possible eCoin sets to achieve the eCoin exchange, taking only into account the own local CASTOR database (i.e. the locally available eCoins).

It is further to be noted, that it makes no difference if the creator of the initial incarnation eDoc (eDoc[I]) containing the initial RSL is the source or the sink CASTOR for the eCoins. To make such mechanism better understandable an example is considered, where eCoins of the well-known€- (Euro- ) denomination are used for payment. Without loss of generality, it is further assumed Alice was the creator of the initial eDoc (eDoc[I] object) and wanted to transfer the amount of e.g. 286,57€ to Bob. She has the choice to differentiate between "exact payment" and "all other" solutions. If Alice is able to make an exact payment, her CASTOR/e Wallet compiles only a single "selection" of her [(Main Secret),(Change Secret)] combination in the following way with an empty change secret:

Selection _A iice := [(200, 50, 20, 10, 5, 1, 0.5, 0.05, 0.02),()]

In this case the RSL has only one entry. Of course exact payment may not always be possible so that Alice has to compile an RSL (with more entries) of supported denominations of eCoins for the payment. Table 8 below shows an RSL that exemplifies denominations of eCoins for the payment of 286.57€ in this example. Please note, the RSL may be limited to cover only up to a predefined system limit, e.g. fifty different entries (Pos). Pos Main Secret Change Secret

1 200, 50, 20, 10, 5, 1, 0.5, 0.1 0.02, 0.01

2 200, 50, 20, 10, 5, 2 2x0.2, 0.02, 0.01

42 200, 100 10, 2, 1, 0.2, 0.2, 0.02, 0.01

43 200, 100 10, 3x1, 0.2, 0.2, 0.02, 0.01

44 200, 100 2x5, 3x1, 0.2, 0.2, 0.02, 0.01

45 200, 100 1x5, 2x2, 4x1, 0.2, 0.2, 0.02, 0.01

46 200, 100 1x5, 1x2, 6x1, 0.2, 0.2, 0.02, 0.01

47 200, 100 1x5, 8x1, 0.2, 0.2, 0.02, 0.01

48 200, 100 2x2, 9x1, 0.2, 0.2, 0.02, 0.01

49 200, 100 1x2, 11x1, 0.2, 0.2, 0.02, 0.01

50 200, 100 13x1, 0.2, 0.2, 0.02, 0.01

Table 8:„Ranked Suggestion List" (RSL) of how to conduct the eCoin exchange.

Assuming Alice can make an exact payment, Bob (has to) accept(s) this proposal because Alice is the payer and she is able to make an exact payment - no further cooperation will be required, Alice's CASTOR, so-to-speak, takes this decision on its own. In all other cases, Alice's CASTOR needs to contact Bob's CASTOR for an agreement on one of the denominations of eCoins for payment. In this case, Alice's CASTOR generates an RSL (as exemplified above) and sends it to Bob's CASTOR as part of the eDoc[I] object in the message [05a] in protocol case [a] or message [06b] in protocol case [b].

In the protocol case [a], as shown in Figure 5, Bob is able to make a counterproposal (optionally using partial knowledge from the previous proposal: Bob „learns", which eCoins Alice has in her CASTOR eWallet by studying the denominations of her RSL) and sends his own RSL of denominations of eCoins for the payment, which Alice has then to choose from. Please note, in case Alice and Bob do not find a common denomination of eCoins supported by both, the transaction fails and the off-line transaction protocol is interrupted.

In protocol case [b], as shown in Figure 6, Bob cannot make a counterproposal and has to pick a denomination of eCoins from Alice's RSL. Otherwise the transfer is not successful and the off-line transaction protocol is interrupted. Please note, in protocol case [b] the Negotiation Phase only consists of sending message [06b] from Alice to Bob, which contains the eDoc with Alice's RSL. In case of receiving a single selection for the eCoin distribution (i.e. an RSL with one entry only) with change eCoins, Bob's CASTOR checks if it can provide the presented denominated change eCoin set and, if so, Bob's CASTOR can accept the proposal by sending the next protocol message [07b]. Otherwise, the transaction fails and the off-line transaction protocol is interrupted.

Please note, the off-line transaction protocol may not only be used to make payments between users or a PoS and a user, respectively, but may likewise be used to withdraw or deposit money from a user's bank. For depositing or withdrawing eCoins, the user and the user's bank may first determine the amount of money (eCoins) to be deposited/withdrawn. This may be for example implemented by means of a known online-banking portal which allows the user to make an eCash remittance to his CASTOR or user account (identified by a user certificate (Type-1/Π certificate). The bank would then transfer the dedicated amount from the user's checking account and make it available through a "cash machine/ATM" (having a hardware and/or software implementation of a CASTOR, i.e. the bank's CASTOR). A push or poll mechanism triggered by the bank's "cash machine/ATM" or by the user's eWallet device comprising his CASTOR could then be used to execute a run of the off-line transaction protocol between the user's CASTOR and the bank's CASTOR to "withdraw" the eCoins. A similar mechanism could be used to deposit (i.e. to clear) eCoins at the user's giro account as his/her bank. In all other cases, the CASTOR of Bob processes the RSL of Alice - starting with the first (best) eCoin denomination indicated therein. In protocol case [a], if Bob's CASTOR is able to use one of the suggested eCoin denominations, it selects the first (highest ranked) eCoin denomination supported. Bob's CASTOR signals its selection by appending information on the selected eCoin denomination into the updated eDoc in form of a selectionBob entry.

In case of no match Bob has to make a decision. If he is already at the protocol stage where he needs to send a value message containing eCoins, he has to generate a new selection _Bob entry on his own and to signal his vote to Alice within the eDoc object. Or Bob interrupts the protocol and does not send any further message to Alice to cause a timeout at her end (fail-stop). He uses this selection for the combination of secrets he sends within the same message. If Bob is not in that need (being in the [a] protocol case) he can supply a RSL by his own. It can be helpful if Bob optionally used partial knowledge from the previous proposal (Alice's RSL) by„learning", which eCoins Alice has in her CASTOR/eWallet by "studying" the presented denomination set proposals from the RSL he already received from Alice within his generation process. If Alice notices Bob uses an eCoin-distribution set she is unable to supply, she has to interrupt protocol-execution, what drives her into the 'transaction not possible' fail-stop behavior, documented before.

As indicated above, in protocol case [a] shown in Figure 5, Alice inverts the message flow by sending a message [05a] ('a' to denote the protocol case [a]) to Bob). This message [05a] does not only pass the initiative to Bob, but also provides additional information to negotiate the details of the electronic token transfer as discussed above.

Sending message [05a] from Alice's CASTOR to Bob's CASTOR is an adaptive step imperatively necessary only in case [a] to prevent the generation of more different protocol trees. Message [05a] comprises the user certificate of Alice (Cert _A [Type-I/II].obj), which is also referred to as a T pe-I or Type-Π certificate and is specific to the user (here: Alice). Please note, the CASTOR may be bound to be used together with only one Type-I/II certificate, i.e. may be bound to be exclusively used by a single person or institution only (not both at the same time). The user certificate of Alice enables Bob (respectively Bob's CASTOR) to identify and confirm the person or organization "Alice", who/which is requesting the transaction.

If the validation of the Alice's and Bob's user certificates by Bob's CASTOR, respectively by Alice's CASTOR fails, the respective CASTOR may immediately interrupt the off-line transaction protocol's run. In an alternative implementation, the respective CASTOR continues execution of the off-line transaction protocol until the CRL, blacklisting the user certificate of Alice, respectively Bob, has been provided to the other party's CASTOR as part of the system object update, and then an interrupt of the off-line transaction protocol is caused.

The inclusion of TSID to message [05a] makes the whole off-line transaction protocol-execution's run unique, and the incrementing (modulo 2 ³² -l) ping-pong number ψ assures the correct ordering of the messages. The (optional) control object of the type "Challenge" contains internal data for the viral- distribution carrier of updateable system information. The viral distribution may be optionally subject to an ageing process with respect to time and or the number of hops by which the system update information is distributed onwards, in order to achieve a controlled cascading effect. This ageing may inhibit the development of an "uncontrollable chain reaction" in the viral distribution of the system update information.

Message [05a] can also be used to carry the initial version of the eDoc generated by Alice (eDoc[Ii _a ] object). This initial eDoc contains the details about the nature of transfer of eCoins, as for example the nature of the request (e.g. invoice, withdrawal, deposit, remittance), the type of currency to be used, the amount of value (in eCoins) to be transferred, and the RSL table of eCoin denomination(s) (entries) suggested by Alice to transfer the value. The eDoc may optionally comprise further information e.g. details of the CASTOR of Alice, the TSID, transaction date and time, etc. All this information is signed by Alice using the private part corresponding to a public key supplied in the user certificate Type-I or Type-II. The signature may not include the RSL since, in protocol case [a], Bob is able to make a counterproposal and may change the RSL in a way the final selected eCoin denomination is not yet known. Table 9 shows the exemplary message [05a] according to the exemplary embodiment described above.

Ta e : ay oa egot at ons step .

Compared to message [06b] for protocol case [b] sent by Bob, the initial eDoc included by Alice with message [05a] contains only a part of the complete information due to Alice protocol role. The information about the transaction will be completed by Bob in the message [06a] as will be outlined below.

Bob's CASTOR receives message [05a] and checks the contents thereof, e.g. by verifying the validity of Alice's user certificate (Cert _A [Type-I/II].obj), and also checks for the correct TSID and the incrementing message counter. Furthermore, as outlined above, Bob's CASTOR has to determine whether one (or more) of the eCoin denominations in the RSL is acceptable, i.e. if it can be supported or if it cannot. Since Bob can make a counterproposal in this protocol case [a] even if no eCoin denomination of Alice is acceptable, Bob's CASTOR may compile a new RSL of eCoin denominations Bob would support. Of course, if Bob supports one or more of the eCoin denominations, those will be included in the RSL to be sent by Bob in message [06a]. If Alice proposes her exact payment, Bob (has to) accept(s) this proposal by including Alice's eCoin denomination for the exact payment to the RSL to be sent by Bob in message [06a]. The RSL is included in an updated version of the eDoc (eDoc[I _la ].obj) received from Alice. This updated version of the eDoc is referred to as eDoc[l _2a ] obj.

The message content of message [06a] is quite similar to the content of message [05a]. The message starts with a message tag '/App,Exchan _g e,info,6' to identify this message as message [06a]. Further, it includes user Bob's certificate (Cert _B [Type-I/II].obj) to enable Alice to identify and confirm the person or organization "Bob". The inclusion of TSID makes the whole protocol-execution-run unique, while the incrementing ping-pong number ψ assures the correct message ordering in the transaction protocol message sequence.

The (optional) control object of the type "Response 1" contains internal data for a viral-distribution carrier of updateable system information. Furthermore, Bob's CASTOR includes the updated version of the eDoc received from Alice, the eDoc[I _2a ] object, to message [06a]. This updated eDoc contains the RSL generated by Bob's CASTOR and further updated information about the transaction protocol-run and current protocol-state. Bob may sign all information recently added to the updated eDoc (optionally except for his RSL with the eCoin denominations). Moreover, Bob's CASTOR may optionally countersign the information contained in the eDoc received from Alice. Table 9 shows an exemplary message [06a] according to the exemplary embodiment described above.

Table 10: Payload Negotiations step 2.

For protocol case [b] the Negotiation Phase only consists of one message [06b] sent from Bob to Alice. Structurally, this message is quite similar to message [05a] and is exemplified in Table 11. In protocol case [b] Bob must select an eCoin denomination from the RSL proposed by Alice in message [06b] otherwise no transfer of eCoins is possible. Furthermore, the provision of Bob's user certificate to Alice is postponed to the actual Value Data Transfer Phase (see message [07b] below), where Bob's user certificate is provided with the main secret of the transaction.

Table 11 : Payload Negotiations step 1. Note, there is no explicit cryptographic checksum or signature of messages [05a], [06a] and [06b] to protect the messages, because the messages will be sent through the established VPN VPC (which can be reduced to only provide signature protection). The transmission of messages [05a], [06a], [06b] and the rest of the protocol messages (through the VPN/VPC if present) between Alice to Bob may also be considered a mechanism to allow Alice and Bob to verify integrity of the received message even in the case no VPN/VPC is effective. It should be also noted; in case a VPN VPC is used its encryption function may be disabled. In this case, the messages are still signed by using the session keys for signing generated in the VPN/VPC Setup Phase so at least some integrity protection to the message contents (which is sent in clear) is provided.

Figure 9 exemplifies the exchange of messages [05a] and [06a] for protocol case [a].

1. Alice's CASTOR (eWallet) creates and sends the initial eDoc object (including the RSL of eCoin denominations) to Bob's CASTOR in message [05a]. This message may further comprise additional information about the transaction and state thereof.

2. Message [05a] is transferred from Alice through a network to the Bob's node. The message may be sent through the previously established VPN/VPC.

3. Bob's CASTOR (eWallet) receives and processes the message. Please note, the reception of message [05a] may be considered as confirmation of the establishment of the VPN/VPC for Bob.

4. Bob's CASTOR (eWallet) replies to the received message by adding information about the transaction and state thereof by updating the eDoc received from Alice and adds the updated eDoc to a message [06a]. This message further comprises an updated RSL of eCoin denominations.

5. Message [06a] is transferred through the network to the Alice's node. The message may be sent through the previously established VPN/VPC.

6. Alice's CASTOR (eWallet) receives and processes message [06a].

Further as mentioned above, the control (Ctrl) objects sent in the Negotiation Phase (and Value Data Transfer Phase) are responsible for a viral diffusion of system update information on a peer-to-peer basis. All the three possible incarnations (Challenge, Response l, and Response_2) of the control objects can be used to distribute and update one or more of the following (non-limiting and non- conclusive) enumeration:

- a Certificate Revocation List of revoked CASTOR root certificates (Type-V) in order to allow the exception of individual CASTORs from the transaction system,

- a Certificate Revocation List of revoked batch production certificates of eCoins (Type-VII) to allow the exclusion of a complete eCoin batch production from the transaction system,

- a Certificate Revocation List of revoked eCoins (Type-VOT) in order to allow the exception of individual eCoins from the transaction system, - a Certificate Revocation List of revoked certificates of issuing authorities of eCoins (Type-IV) in order to allow the exception of individual issuing authorities (e.g. eMints) from the transaction system,

- a Certificate Revocation List of revoked user certificates (Type-1/Π) in order to allow the exception of individual users from the transaction system,

- a Certificate Revocation List of revoked Certification Authority certificates (Type-Ill) in order to allow the exception of individual Certification Authorities from the transaction system,

- firmware updates for updating the firmware of the CASTORs, and

- policy rules updates for updating the policies (e.g. new crypto-regulations in a country, changed eMoney regulations (e.g. due to money laundering), flexible responses to potential phishing and/or spoofing, new or changed operation behavior of the I O-interface, etc.) of the CASTORs.

In case the VPN VPC is in use, only encrypted information travels between Alice and Bob using the (symmetrical) secret key encryption scheme which has been previously negotiated in the VPN/VPC Setup Phase. Both peers thus exchange their user-certificates, challenge- and response-objects for system update and the eDoc messages under VPN/VPC-protection.

It should be further noted, the actual selection of the eCoin denomination for the transfer (given Alice and Bob agree on one) is performed prior to sending the next protocol message and is implicit to the eCoins (main secret of the transaction) to be sent in this next protocol message. Therefore, the selection of the eCoin denomination for the transfer of eCoins may be considered part of the Value Data Transfer Phase discussed below (however, this is matter of definition).

Furthermore it should be apparent; that the provision of an RSL of eCoin denominations for the payment is specific to the eCash context. In case the transaction allows no choice of electronic tokens to be transferred, i.e. the electronic tokens to be transferred are known from the pre-negotiations before the run of the off-line transaction protocol, no "negotiation" on the transfer details is needed, so the RSL may not be included to the eDoc(s) exchanged. The remaining message contents of messages [05a], [06a], and [06b] may however stay unchanged also in other applications of the off-line transaction protocol as the eDoc contents may be part of the evidence for a later fairness reconstruction after the off-line transaction protocol's termination.

As indicated above, the update of system objects may be realized by a challenge-response mechanism. In one exemplary embodiment, the challenge and their respective responses are using a sort of ping- pong mechanism:

1. The Challenge message (being the ping) contains the respective version number and a date/time stamp of its generation for each updatable system object. This is enough information for the recipient of the challenge ("receiver") to generate a first response (being a pong). The CASTOR ("sender") sending message [05 a], respectively message [06b], amends the Challenge control object (Ctrl[Challenge].obj) by information on the sender's status of the updatable system objects, e.g. firmware, policy rules and CRLs, for example by indicating their last update (timestamp including date) and/or their version number.

The first response (Ctrl[Response_l].obj) contains a status field and a data field for each previously requested updateable system object from the challenge message. Possible status values are [Null, Object, Request]. "Null" indicates that no update is needed; in this case the respective data field is empty or without any meaning. "Object" indicates that a newer system object (referenced by position in respect to the previously sent version number and date/time stamp) is contained within the data field representing an update for the challenge issuing party ("sender").

"Request" indicates that the recipient of the challenge ("receiver") identified an older system object at the receiver based on the version/date/time information in the challenge and now requests an update from the challenging party ("sender"). In this case the respective data field is empty or without any meaning. The challenge receiving CASTOR ("receiver") receives message [05a], respectively message [06b], can check:

a. Whether the receiver has an outdated version of one or more of the indicated system objects, and if so, the receiver includes a "Request" signal for every outdated/requested object to the Response l control object (Ctrl[Response_l].obj) in message [06a] or, message [07b], respectively.

b. Whether the receiver has a newer version of one or more of the indicated system objects, respectively more up-to-date system objects, and if so, the receiver includes an "Object" signal for every more up-to-date object together with the more up-to-date system objects to the Response_l control object (Ctrl[Response_l].obj) in message [06a] or message [07b], respectively.

c. Whether the receiver has same version of one or more the indicated system objects, and if so the receiver includes a "Null" signal for every same object to the Response l control object (Ctrl[Response_l].obj) in message [06a] or message [07b], respectively.

The sender of the initial challenge receives the first response (Ctrl[Response_l].obj). The sender prepares, as a consecutive step, a second response message (Ctrl[Response_2].obj) containing a status and a data field for each previously requested object (from the first response message).

Possible status values are [Null, Object]. A "Null" indicates that no update is to be done; in this case the data field is empty or without any meaning. An "Object" indicates that a (requested) newer object (referenced by position in respect to the previously sent version number and date/time stamp) is contained within the data field representing an update for the receiver. Upon reception of the first response message (Ctrl[Response_l].obj) by the sender, it updates its system objects based on the contents of the control object of the first response message and finally checks whether the first response control object requests the transmission of system objects indicated by a "Request" signal, respectively. If so, the sender includes the more up-to-date system objects to the last response message's control object (Ctrl[Response_2].obj) and sends this updated control object to the receiver in message [07a] or message [08b], respectively. Thereupon the receiver updates its system objects based on the content of the second response message's control object

(Ctrl[Response_2].obj).

This is one exemplary implementation according to achieve an efficient distribution supported by a "viral" mechanism to distribute system update information (like firmware or other data objects) among the tamper-protected semiconductor modules in the system.

Furthermore, in one exemplary implementation according to another embodiment of the invention, in case any CRL is updated in a CASTOR, this CASTOR checks (as part of the off-line transaction protocol or after its termination) whether any of the locally available certificates is listed in an updated CRL and "locks" the respective listed certificates. If the blacklisted certificate is the CASTOR root certificate or the user certificate (assuming that one user is bound to the CASTOR), the CASTOR may temporarily or permanently disable the respective CASTOR so no further transactions can be executed. A temporary disablement could allow the user of the CASTOR to re-enable the CASTOR, for example, by requesting the Root Certification Authority to reinitialize the CASTOR, or to un-list the CASTOR or user from the respective CRL. Such operations could be conducted by using any standard transfer protocol, e.g. email for the transport of the respective updated system objects and a local terminal based I/O-operation for the provisioning of the updated system objects to the disabled CASTOR.

Alternatively, it is also possible that each CASTOR provides the respective other CASTOR with its (complete) set of system objects and lets the other CASTOR decide which system objects are to be updated. However, this approach appears less favorable, since it introduces additional overhead to the transferred payload, because system objects are sent without checking whether they are more up-to- date than the system objects available at the other CASTOR.

In case one of the CASTORs recognizes that the other CASTOR'S root Type- VI certificate or user certificate Type-Ι Π is on a respective CRL in an earlier protocol phase, this CASTOR may optionally not fail-stop immediately but may proceed the off-line transaction protocol until having provided the CRL listing to the other CASTOR as part of the system object update procedure. After sending the message with the CRL listing (and the updated objects, respectively) to the other CASTOR, the sending CASTOR is then interrupting the off-line transaction protocol, triggering a timeout at the other CASTOR. Assuming, a CASTOR had the ability to disable itself if its CASTOR root certificate or its user's user certificate were blacklisted, this mechanism would be advantageous as it would not only avoid the transaction to be performed but would further provide the blacklisted CASTOR (i.e. the CASTOR of which the user certificate of its user or its CASTOR root certificate is blacklisted) with the respective CRL "through the back-door" to disable (or to re-enable) the blacklisted CASTOR and to prevent the blacklisted CASTOR from initiating any further run of the off-line transaction protocol.

A CASTOR may be optionally enabled to decide upon detection of a blacklisted CASTOR root certificate or user certificate whether to interrupt the off-line transaction protocol immediately or to proceed up to the Negotiation Phase to push the CRL with the other party's blacklisted CASTOR root certificate or user certificate to the other party's CASTOR.

For example, this decision may depend on the role of the respective CASTOR in the protocol-run, i.e. the protocol case: If the push of the CRL with the other party's blacklisted CASTOR root certificate or user certificate to the other CASTOR was part of the Response_2 control object, i.e. part of message [07a] or [08b], it may not be desirable to proceed since this implies that the respective CASTOR has to send the eCoins of the change secret.

Furthermore in another, alternative implementation, the CASTOR detecting the other transaction partner's CASTOR root certificate or user certificate to be blacklisted could always proceed with the protocol-run. In case the CASTOR needs to send the CRL blacklisting the other transaction partner's CASTOR root certificate or user certificate in a message together with electronic tokens the CASTOR could simply not include any electronic tokens to the respective message. A CASTOR can be configured to perform a system update also in cases the message is erroneous (here: electronic tokens would be missing in the message). If this procedure means the CASTOR detecting the other transaction partner's CASTOR root certificate or user certificate is blacklisted it receives the electronic tokens of the main secret before providing the system update with the CRL blacklisting the other transaction partner's CASTOR root certificate or user certificate to the other transaction partner's CASTOR. Then the CASTOR should not allow its user to dispose of the electronic tokens of the main secret.

Furthermore in another embodiment of the invention, the challenge-response update mechanic may be also used to re-enable a previously disabled/locked CASTOR; for example in case the previous reason(s) is/are for disabling same do no longer exists (e.g. the locked CASTOR is detached from a previous CRL by a newer (updated) one). In this embodiment, a CASTOR is configured to perform/allow a system update also in cases where the CASTOR itself is locked. The system update could be for example performed on-line with a trusted party, such as the RCA or as part of a "incomplete" run of the off-line transaction protocol. In the latter case the restriction for the locked CASTOR of not being allowed to execute the off-line transaction protocol will be lowered/reduced to of not being allowed to exchange (transmit or receive) electronic tokens, so that even in the lock case, a CASTOR is still able to start an off-line transfer protocol (which will be - of cause - later in the protocol steps always not successful, ending with a (fair) interrupt). 1.4.5.8 Electronic Token Transfer Phase (also: Value Data Transfer)

The successful entry into this protocol phase documents the ability of both CASTORs now to exchange the previously negotiated electronic tokens (eCoins). This phase of the off-line transaction protocol is fairly simple as it just exchanges two messages between Alice and Bob (messages [07] and [08]) which contain the eCoins of the main secret and the eCoins of the change secret (if needed). However as will be outlined below in further detail, the Value Data Transfer and the first two acknowledgment messages [09] and [10] are crucial with respect to the rollback in case of an interruption of the off-line transaction protocol and a possible subsequent fairness reconstruction, because an interruption of the off-line transaction protocol could lead to termination of the off-line transaction protocol in an unfair state.

Generally it should be noted, the respective CASTORs may check all eCoins to be transferred after their reception to assure their validity. Optionally, the transmitting CASTOR may check the transferred eCoins (again) prior to their transmission, too. These checks enable the detection of counterfeit eCoins (counterfeit eCoins are blocked and not transferred) and the validity of all involved digital signatures and certificates. In case of any irregularity a CASTOR detecting same will fail-stop and thereby cause the interruption of the off-line transaction protocol.

Although the protocol is designed to be operable off-line it may be possible that one of or both CASTOR(s) of Alice (and Bob) check the validity of the eCoins on-line by obtaining the latest CRL of eCoins to check the serial numbers of the eCoins against this CRL. This may for example be applicable in cases where one of the CASTORs has access to a permanent on-line connection (e.g. Internet connection), e.g. a CASTOR at a PoS. This on-line access for the validation of the eCoins is of course only optional and may be for example subject to user configuration. Even in case an on-line connection is used to check the validity of the eCoins with a third party, anonymity of the payment may be guaranteed as the third party providing the up-to-date CRL does not gain any information on the payment as such (i.e. is not acting as a fairness arbiter for the transaction). Of course, the update of CRLs (e.g. for the eCoins) may not necessarily be part of the off-line transaction protocol. For example, prior to starting the run of the off-line transaction protocol to transfer the electronic tokens, the CASTORs (as far as an on-line connection is available) could update the CRL(s), the CRL(s) could be updated in predetermined intervals, or the update of the CRL(s) could be triggered by an online connection becoming available. The update of CRLs outside the off-line transaction protocol may be advantageous, since it allows transferring the electronic tokens truly off-line in the sense that no online connection is employed for the transfer.

In another alternative embodiment the on-line check of the eCoins may be combined with a subsequent on-line clearing of the eCoins at the user's bank (e.g. eMint). A CASTOR could be receiving eCoins within an off-line transaction protocol and may simultaneously have an on-line connection to the eMint. The CASTOR contemporary tries to first verify the validity of the eCoins and then clears the received eCoins immediately with the eMint in a combined off-line transaction protocol session with the other (customer) CASTOR and an on-line session with the bank's CASTOR.

For example, the CASTOR can pass the identifying descriptor items (e.g. a serial numbers) of the eCoins to be received within the off-line transaction protocol-run on-line to the eMint before the eCoins are exchanged off-line. The clearing of the eCoins is technically - of course - only possible after the respective eCoins are "unlocked" by the off-line transaction protocol-run and become disposable for the other (parallel) on-line protocol with the eMint.

Checking the eCoins on-line for their validity may be advantageous as the risk of accepting counterfeit eCoins can be minimized. This is especially true in case where the eCoins are checked for their validity using the information of the Negotiation Phase (prior to the eCoin exchange) of the off-line transaction protocol (e.g. based on their identifying descriptor item (e.g. a serial number)). If this check is successful, the CASTOR can "accept" the eCoins and can optionally clear them afterwards. Otherwise, in case the eCoins are blacklisted, this event may cause a fail-stop of the off-line transaction protocol.

Besides the transfer of the eCoins, messages [07] and [08] represent final ping-pong exchanges of the eDoc objects. If these two messages are successfully delivered, the off-line transaction protocol enters into its termination sequence, the Confirmation Phase. After having successfully finished the transfer of message [08], both parties have successfully exchanged eCoins against an electronic receipt in return.

It should be also noted, that the CASTORs of Alice and Bob are configured to delete all electronic tokens (eCoins) at the respective CASTOR once they have been included into protocol messages [07] and [08], respectively, independent of the successful ending of the protocol. Hence, in case of an interruption of the off-line transaction protocol, this annihilation of transferred eCoins may cause a termination of the protocol's run in an unfair state but this is - with regard to protocol and system design - desirable in order to prevent multi-spending of eCoins.

Exchange and contents of the protocol messages [07] and [08] for the protocol cases [a] and [b] will be outlined in further detail below.

Considering protocol case [a] as exemplified in Figure 12, Alice approved her connection to the correct peering partner based on the user certificate she received from Bob with message [06a], she transfers the negotiated eCoins to Bob. The eCoins (∑Token[Secrets].obj) are included in message [07a]. Alice's CASTOR creates and transmits this message to Bob's CASTOR. Message [07a] is identified by its tag ' App,Exchan _g e,vaiue,7'- The viral distribution of system object updates keeps the management and security information within this transfer system accurate: The (optional) control object type "Response_2" carries system information used to keep operating CASTORs 'up- to-date'. Due to bandwidth considerations (to minimize the traffic overhead occupied for system update purposes) it is possible to restrict the update process to objects with relevance to the concrete transaction run at hand.

Message [07a] further comprises the next updated version of the eDoc, the so-called eDoc[II _a ] object to which Alice adds the serial number of the eCoins transferred in this message as the "main secret" of the transaction and signs this information block inside the eDoc object using her signing private key (e.g. Ks _: user:Type-i/n _; prv)- An exemplary message [07a] is shown in Table 12. Once message [07a] has been sent by Alice her CASTOR ensures the eCoins are irrevocably destroyed - the only thing Alice may obtain in case of a protocol interruption is a proof of loss ("credit note" or "affidavit") for the "lost" eCoins.

Table 12: Valuable Data Transfer step 1.

Upon reception of message [07a] Bob's CASTOR checks the contents of this message which includes for example checking the validity of the transferred eCoins (e.g. with respect to their expiry, the eCoins being blacklisted in a CRL of revoked eCoins, checking the correct TSID or the increment of the message counter ψ, etc.). If Bob's CASTOR successfully checked message [07a] from Alice, and in case he confirmed he is connected to the appropriate peering partner (based upon the user certificate he received with message [05a]), he finally approves the transfer. Bob's CASTOR creates and transmits message [08a] in which he transfers his change eCoins (∑Token[Secrets].obj) - if any - and which confirms the successfully receipt of message [07a] and Alice's eCoins. The message sent by Bob is identified by a tag 7App,Exchan _g e,vaiu _e ,8'- Further, Bob's CASTOR once again updates the eDoc exchanged in the protocol messages by adding the serial numbers of the change eCoins transferred in the same message and signs this information block inside the eDoc object using his signing private key (e.g. KsuserType-i/nprv) to the eDoc. Optionally, Bob's CASTOR could also countersign the serial number block previously inserted and transferred by Alice in order to indicate their safe reception and to lock this information block against any changes. The resulting eDoc is referred to as eDoc[in _a ] object. An exemplary message [08a] is shown in Table 13. Once Bob has sent message [08a] his CASTOR ensures the change eCoins are irrevocably destroyed - the only thing Bob may obtain in case of a protocol interruption is a proof of loss ("credit note" or "affidavit") for the "lost" eCoins.

Table 13: Value Data Transfer step 2. Upon reception of message [08a] Alice's CASTOR checks the content of message [08a] received from Bob, which includes for example checking the validity of the transferred eCoins (e.g. with respect to their expiry, the eCoins being blacklisted in a CRL of revoked eCoins, checking the correct TSID or the increment of the message counter ψ, etc.). If Alice's CASTOR successfully checked message [08a] from Bob, both parties achieved

- negotiated eCoins have been exchanged against an electronic receipt (element part of the eDoc object) and

- all steps required for the option updates of system level objects are done.

Note, there is no separate explicit cryptographic checksum or signature of messages [07a] and [08a] to protect them because these messages will be sent through the established VPN VPC tunnel. The transmission of messages [07a] and [08a] through the VPN/VPC tunnel between Alice to Bob may also be considered a mechanism to allow Alice and Bob to verify integrity of the received message. It should be also noted, in case a VPN/VPC is used, its encryption function may be disabled. In this case, the messages are still signed by using the session keys for signing generated in the VPN VPC Setup Phase so at least some integrity protection to the message contents (which is sent in clear) is provided. Figure 10 exemplifies the Value Data Transfer Phase according to an exemplary embodiment of the invention.

1. Alice's CASTOR (e Wallet) sends a messages [07a] containing the mid-flow eDoc object (eDoc[II _a ].obj), and the main secret (here eCoins) of the transaction. Optionally, other objects as system update information may be included to the message.

2. Message [07a] is transferred through a network to the Bob's node.

3. Bob's CASTOR (eWallet) receives and processes messages [07a] received from Alice. 4. Bob's CASTOR (eWallet) replies to messages [07a] by sending message [08a] which contains optional the change secret (eCoins) and a post-flow eDoc object (eDoc[III _a ].obj).

5. Message [08a] is transferred through the network to the Alice's node.

6. Alice's CASTOR (eWallet) receives and processes the message [08a].

The protocol case [b] is essentially similar to the protocol case [a], except for the inversed message flow (message [07b] is sent by Bob, message [08b] by Alice) and some minor changes to the protocol messages as will be shown below (see Figure 13).

Message [07b] is exemplified in Table 14. The main difference between message [07a] and message [07b] regarding their content is the inclusion of Bob's user certificate (Cert _B [Type-I/II].obj) to message [07b] which enables Alice to identify and confirm the person or organization "Bob". In protocol case [b] where the Negotiation Phase essentially only comprises message [06b] message [07b] is used to transfer the Bob's user certificate to Alice. Accordingly, Alice may check Bob's user certificate the first time upon receipt of message [07b]. Moreover, the (optional) control- object-type changes from a "Response_2" to a "Response 1" in view of the protocol flow change in protocol case [b]. As described above, once message [07b] has been sent by Bob, his CASTOR ensures that the eCoins are irrevocably destroyed - all Bob may obtain in case of a protocol interruption is a proof of loss ("credit note" or "affidavit") for the "lost" eCoins.

Table 14: Valuable Data Transfer step 1.

Also message [08b] of protocol case [b] as shown in Table 15 is similar to message [08a] in protocol case [a]. The only difference is an (optional) control object of "Response_2" type in order to complete the system information update. Please further note, once message [08b] has been sent by Alice her CASTOR ensures the eCoins are irrevocably destroyed - a proof of loss ("credit note" or "affidavit") for the "lost" eCoins is the only thing Alice may obtain in case of a protocol interruption.

In one further exemplary embodiment, irrespective of whether or not the encryption function of the VPN/VPC is in use between Alice and Bob to protect the contents of the protocol messages, the eCoins comprised in the respective messages [07] and [08] for both protocol cases [a] and [b] may be included to the messages in encrypted form. One of many motivations to do so is to avoid any third party is able to intercept the eCoins in clear and usable form.

The CASTOR sending its eCoins may for example encrypt the eCoins using a session key dedicated for this purpose. This session key may have been generated already in the VPN/VPC Setup Phase. Another alternative implementation may be Alice's and Bob's CASTORs, respectively, encrypt the eCoins of the main secret and the optional change secret by means of using a private/public key-pair (encrypting with the public key part and decrypting with the respective private key part). For example, Alice could use the public key part of the public key-pair of Bob's CASTOR or alternatively Bob's user public key-pair, the public key part which is included in the CASTOR root certificate, respectively Bob's user certificate. Similarly, Bob could use a respective public key of Alice to encrypt the eCoins prior to inclusion thereof to the protocol message.

Please note, the Value Data Transfer Phase could be designed also for applications other than an eCash system as described above. The messages may however be adapted to the respective application. For example, in case the off-line transaction protocol was used to a purchase software license the purchasing party should transfer the main secret (payment of the software license (eCoins)) while the licensor could provide the software license key as part of the message transferring the optional change secret (eCoins). The software license could be included as an additional message object or as part of the eDoc (e.g. as part of or being the electronic receipt). The license key may be signed by the licensor's private signing key part of a key-pair (where the public verification key part is provided within the user certificate of a Type-I/II of the licensor). It should be clear, the "means of exchange" used so far in the described system are financial instruments like Euros (€), Dollars ($), or any other national currency. The invention is however not limited to exchange only electronic tokens of such format (eCoins). As mentioned previously, the electronic tokens may represent anything that can be represented electronically (e.g. in form of a certificate) in the physical or virtual world like provision of services, such as for example a digital representation of money (i.e. coins and bank notes of one or more arbitrary currencies), natural resources or goods e.g.

- metal (e.g. precious metal like platinum, gold, silver, copper), etc.,

- renewable raw materials (e.g. eggs, pigs, cows, corn, rice, wheat), etc.,

- (raw) oil, diamonds, sapphires, rubies, crops, coal, etc.,

- properties (e.g. parts of accounted dependencies like forestry trees in south America, estates and landholding), etc.,

- services (e.g. (the receipt of) natural gas, petrol, oil, water, electrical power), etc.,

- properties already confirmed by documents (e.g. shares/stocks or rights, tickets (cinema, public transport, sport event, media libraries, eBooks)), etc.,

- licenses and cryptographic key exchanges (e.g. in form of license keys for software applications, decryption keys for streaming multimedia, digital content license for eBooks, music, videos), etc.,

- guarding medical records, soiling certificates (e.g. CO ₂ ), or even as replacements for physical keys as used for doors, cars, office cupboards, etc.

Similarly in other applications, where no eMoney/e Value is transferred, no eCoins may need to be transferred, but the type and definition of electronic tokens to be included in the protocol messages may depend on the application type.

1.4.5.9 Acknowledgment Phase (also: Confirmation)

The Confirmation Phase is the off-line transaction protocol's last phase and is used to commit the transfer of the electronic tokens in the Value Data Transfer Phase outlined above. The Confirmation Phase renders the transfer repudiation-free.

In protocol case [a] the ACK1-, ACK2- and ACK3-tickets (referred to as messages [09a], [10a], and [11a] below) are exchanged as security tokens after the successful delivery of message [08a] from Bob to Alice. Message [09a] acknowledges Alice's reception of the previous message [08a] from Bob. If Bob does not receive message [09a] the protocol-execution may not be successful (i.e. interruption at this point in time of the protocol-run may still lead to a termination in an unfair state). Message [10a] informs Alice, Bob acknowledges the successful protocol-execution (and the reception of message [09a]). If Alice does not receive this message the protocol-run may not terminate successfully.

Message [11a] is Alice's farewell heard by Bob (according to this transaction). Please note, message [1 la] is optional and does not have any effect on the successful or unsuccessful ending of the off-line transaction protocol's run. However, this message may nevertheless be desirable in the protocol to allow Bob to confirm Alice has successfully received message [10a] which implies that the off-line transaction protocol was ended successfully (and thus in a fair state) for Alice.

After having successfully exchanged the three acknowledgment messages the off-line transaction protocol's run ends and both parties achieve the successful exchange of eCoins against an electronic receipt (eReceipt).

In one exemplary implementation of the Confirmation Phase for protocol case [a] Alice creates and transmits message [09a] to Bob. Message [09a] may be identified by the tag '/ _Ap p .Commit. Info,9 '. As indicated above message [09a] acknowledges reception (and successful validation) of Bob's previous message [08a]. As for the previous messages, also message [09a] contains the TSID of the off-line transaction protocol's run and an appropriately incremented message counter ψ. Furthermore, message [09a] comprises the ACKl-ticket object (Ticket[ACKl].obj) which provides the evidence on the reception of Bob's message [08a] in a non-repudiable form Table 16 exemplifies message [09a] sent from Alice to Bob.

Table 16: Commit step 1. The ACK1 ticket object could for example be implemented as shown in Table 17. The ACK1 ticket object may for example indicate its Type as "AC 1 -TICKET" and comprises an Evidence and Signature section. The Evidence section contains a signature on a predetermined set of information on the transaction, e.g. the TSID of the transaction, a timestamp DTC _A , and a nonce as shown in Table 17. The signature is signed using the private signing key of the CASTOR root certificate KS _:C ASTOR:SUDI,PIV (i.e. the private key counterpart to the public key comprised in the Type- VI certificate). Type ACK1 -TICKET (for commitment and confirmation, 8 bit)

Proof. s _A := A({X(TSID || DTCA || NONCE ₂ 56bi,)}Ks _: cASTOR:suDi,prv)

Evidence. AlgorithmlD CFV-Definition

ACK1. Signature.

DigestKey e.g.: 7453 FDC5 AE52 063D AC4F ...

AlgorithmlD CFV-Definition

Signature.

DigestKey e.g.: 7453 FDC5 AE52 063D AC4F ...

Table 17: ACK1 ticket.

The Evidence section (and optionally the Type) is further signed by Alice's CASTOR, for example by means of the Alice's private key part corresponding to the public key comprised in Alice's Type-VI certificate. This implementation is only exemplary. It is likewise possible to apply one signature to the Evidence section (and optionally the Type) by using one of the before mentioned private keys. Finally, the ACKl-ticket object is signed in the Signature section using Alice's private key part corresponding to the public key comprised in Alice's user certificate (Type-1/Π).

If the delivery of message [09a] to Bob is successful the protocol enters into the next commit iteration. After receiving message [09a] Bob's CASTOR starts its commitment procedure. Bob's CASTOR creates and transmits this pre-final confirmation message [10a]. An exemplary implementation thereof is shown in Table 18. Message [10a] may be identified by a tag '/App,commit,info,io'- As for the previous messages, also message [10a] contains the TSID of the off-line transaction protocol's run and an appropriately incremented message counter ψ. The ACK2-ticket object (Ticket[ACK2].obj) informs the receiver Alice about the successful protocol-execution of entity Bob (an ACK for an ACK) as a positive feedback.

Table 18: Commit step 2. The ACK2-ticket object is similar to the ACK1 -ticket object, except for indicating "AC 2-TICKET" in the type field. An example ACK2-ticket object is shown in Table 19.

Table 19: ACK2 ticket.

Upon successful reception of message [10a] from Bob Alice creates and transmits her final confirmation message [1 1a] that will terminate the off-line transaction protocol's run. The final message [1 1a] may be identified by the tag '/App,commit,info,n'- As for the previous messages message [11a] contains the TSID of the off-line transaction protocol's run and an appropriately incremented message counter ψ, too. The ACK3-ticket object (Ticket[ACK3].obj) informs Bob about the successful protocol termination by Alice (an ACK for an ACK for an ACK) as a positive feedback. In case the message [11a] is lost this will have no effect on the successful termination of the off-line transaction protocol, i.e. the protocol-run is still successful. Table 20 shows an exemplary of message [11a].

Table 20: Commit step 3.

The ACK3-ticket object is similar to the ACKl -ticket except for indicating a different message in the type field. An exemplary implementation of the ACK3 ticket object is shown in Table 21.

Table 21: ACK3 ticket. Figure 11 exemplifies the exchange of confirmation messages in the Confirmation Phase for protocol case [a].

1. Alice's CASTOR (e Wallet) generates a fresh ACKl -ticket object and sends it as part of message [09a] to Bob.

2. Message [09a] is transferred through a network to Bob's node.

3. Bob's CASTOR (e Wallet) receives and processes the message [09a].

4. Bob's CASTOR (e Wallet) replies to message [09a] by creating and sending message [10a] comprising an ACK2-ticket object.

5. Message [10a] is transferred through the network to Alice's node.

6. Alice's CASTOR (eWallet) receives and processes message [10a].

7. Alice gets informed about her transfer's transaction status.

8. Alice's CASTOR (eWallet) replies to message [10a] by creating and sending message [11a] containing the ACK3-ticket object. After transmission of this message the connection to Bob is terminated.

9. Message [1 la] is transferred through a network to Bob's node.

10. Bob's CASTOR (eWallet) receives and processes message [1 la] and terminates the connection to Alice.

11. Bob gets informed about his transaction status of the transfer.

Regarding protocol case [b] the Confirmation Phase is basically identical to the protocol case [a] except its flow of messages: In protocol case [b] messages [09b] and [1 lb] are sent by Bob while message [10b] is sent by Alice. Otherwise the contents of messages [09b], [10b], and [l ib] are identical to messages [09a], [10a], and [11a] as discussed above. The following tables nevertheless briefly outline the message structures for protocol case [b]. Table 22 exemplifies message [09b] sent by Bob.

Table 24: Commit step 3.

In one exemplary embodiment of the invention all confirmation messages [09] to [11] are repeated multiple times in a transmission burst to lower the loss possibility as a precautious countermeasure against statistical occurrences of temporal shadowing radio transmission interruptions and/or distortions. Regarding the Confirmation Phase it should be noted, this phase of the off-line transaction protocol may be implemented as described above in other applications, too.

1.4.5.10 Termination of the Off-line Transaction Protocol's Run

The end of the Confirmation Phase constitutes also the end of the off-line transaction protocol's run. If the protocol's run has terminated successfully both parties have successfully completed the off-line transaction protocol's run and exchanged their main and change secrets (here eCoins) and optionally the (partial) update of system objects as described above. Hence, the protocol has been terminated in a fair state so that no fairness reconstruction is necessary. Accordingly, the off-line transaction protocol allows transferring electronic tokens between two peers via a direct link, without the interaction of any third party. In cases in which an interruption of the off-line transaction protocol has occurred a post- transaction protocol fairness recreation process using the proofs generated during the off-line transaction protocol's run may need to be performed to reconstruct fairness to both parties of the transaction, e.g. for achieving reimbursement compensation for a loss of electronic tokens.

1.4.6 State-flow Transition-logic of a CASTOR

Figure 16 shows a state-flow transition-logic of a single CASTOR implementing the off-line transaction protocol including the "weak deal" handling procedure (also referred in this connection reference as "teleportation") according to an exemplary embodiment of the invention. It is important to keep in mind, the discussed teleportation works by atomizing the asynchronous exchange-process: Operations are protected either to be completely done or not at all. This makes the teleportation durable and guarantees reliable processing consistency. In the following, the states and events of the Mealy automat are elucidated briefly:

1.4.6.1 State "Off"

The CASTOR is off-line, power-downed, or in sleep mode. It won't respond to any request, except a power-on-event.

1.4.6.2 State "Begin "

The CASTOR is powered-on by the user. An internal Build-In-System-Test (BIST) is performed. In case of an error this event may be indicated to the user; else, the control is passed to state "Conflict pending check". 1.4.6.3 State "Conflict pending check"

A check is performed whether the last teleportation-execution has been successfully terminated or whether the CASTOR may need to resolve conflicts arising from an earlier teleportation-run. This check may be advantageous, since the CASTOR can be stopped at any time by an external event or by the user. Since all steps of the transaction are atomistic, all operations may be recorded by an internal transaction-tracking-system of the CASTOR in a manner that even in case of a power-loss, they will be 'finished' by a logical rollback (state: "Conflict resolution"). In case a conflict resolution is needed, the CASTOR will propagate to the "Conflict resolution" state; else, the control is passed to the state "Ready".

1.4.6.4 State "Ready"

As long as the CASTOR is not initiating a run of the teleportation or in case the CASTOR does not need to reply to an incoming request, it remains in idle state. Only in case of having been switched off by the user, it passes the control to "Stop". If a run of the teleportation is requested, the CASTOR passes its state to "Pairing".

1.4.6.5 State "Stop "

This state disengages the CASTOR. Disengagement can be done by powering-down the CASTOR or forcing by it in some kind of sleep-mode. Only the user of the CASTOR is able to switch it to "Stop" state.

1.4.6.6 State "Conflict esolution " In case of a pending conflict (e.g. due to a previous power-failure) found in the non-violate transaction memory, this conflict must first be cleared. After the completion of this (also atomistic) conflict resolution procedure, the state is passed to "Ready".

1.4.6.7 State "Fail"

This state is reached if the off-line transaction protocol-run is interrupted without any deficit of fairness. In most cases the protocol-break is caused by a "Fail (fair)", which happens is if neither the expected message failed to reach its destination nor Alice nor Bob face a loss of any (value) secrets. This state clears all internal pending transactions and transfers the CASTOR back into the "Ready" state.

1.4.6.8 State "Pairing" In response to an external paring request from a partnering CASTOR or in response to a user interaction with the CASTOR, a pairing-process is issued, and the CASTOR enters into the "Pairing" state. If this step can be finished successfully, the next step is the "VPN/VPC" state; else, the timeout "Fail" state is entered. 1.4.6.9 State "VPN/VPC"

Alice and Bob are mutually exchanging information for the (optional) creation of a VPN VPC channel. After both peers have computed the common shared secrets (e.g. session keys) the (optional) encryption takes place and the secure channel is (optional) established. If everything succeeds the state advances to "Payload negotiations"; otherwise to "Fail".

1.4.6.10 State "Payload negotiations "

After the (optional) establishment of a secure private communication channel (VPN/VPC), Alice and Bob negotiate the transaction's payload, i.e. what the payload is and how it shall be exchanged. It may happen, the type of secrets on both sides aren't compatible (e.g. eCoins in€uros versus U$-Dollars), a CASTOR has not enough value stored inside to conduct the transaction, or even the granularity (eCoins are atomic and not divisible) do not allow for the change, etc. In cases where the transaction isn't possible, the CASTOR switches to the state "Transaction not possible" and interrupts the teleportation-run. If the exchange, however, is possible, and if no failure occurs, the CASTOR advances into the state "Secrets exchange".

1.4.6.11 State "Secrets exchange"

The secrets are exchanged to conduct the payment (exchange of secrets) against a receipt between Alice and Bob. If the transfer can be completed without an interruption (either an immediately effective successful off-line transaction protocol-transfer or a successfully delayed "weak deal"), both partners have a "Success". The CASTOR state then advances to "Commit". In any other case, the transfer hasn't been successful and a fail event comes up. In case the fail is a fair one, the CASTOR'S state is changed to "Fail"; else, the state is changed to "Affidavit generation for fairness recreation" to generate of a proof of loss.

1.4.6.12 State "Commit"

This protocol state is the last one in the teleportation and consolidates the transaction. A successfully commitment terminates the teleportation-run and returns to the state "Ready". In case of a "fail" the teleportation-run switches to 'Affidavit generation for fairness recreation'.

1.4.6.13 State "Transaction not possible"

In case a logical hindrance that (e.g. not enough value/money) prevents the transaction the teleportation-run is stopped and not performed. The state of the CASTOR transfers to "Fail". 1.4.6.14 State "Affidavit generation for fairness recreation "

In case the teleportation-run escalates to an unfair fail no further messages are exchanged. Secrets of one or both protocol-parties are lost because of something went wrong or due to an error. Note, since the teleportation transaction model is asynchronous, a CASTOR deciding something went wrong does not necessarily imply any incorrectly behaving other CASTOR. The handling of this state is one of the most challenging tasks in the teleportation. The CASTOR prepares actions to create a legally binding affidavit for later (delayed) lost-secret compensation through the eMint. After this step, the protocol state advances to "Fail".

1.4.6.15 Event "Power-on " The power-supply is activated by the user switching the CASTOR "On". This event transits the CASTOR from "Off" state to "Begin" state.

1.4.6.16 Event "Reset"

This event is fired in case the CASTOR-device switches its state from "Begin" to "Conflict pending check". As one of the first moves after a Reset the internal circuitry processes several functional tests (BIST), and the state shift indicates their successful completion (else the error indicator of the CASTOR is activated).

1.4.6.17 Event "Yes "

The last "Power-off' event did not lead to a normal shutdown of the CASTOR through the "Stop" and "Off' states. This event causes the CASTOR to enter the "Conflict resolution" state.

1.4.6.18 Event "No "

The last "Power-off' event leads to a normal shutdown of the CASTOR. The CASTOR enters into the "Ready" state.

1.4.6.19 Event "Solved"

After conflict resolution caused by the previous "Power-off incident the CASTOR is back operable again by advancing its state to "Ready".

1.4.6.20 Event "Idle"

The idle event is occurring as long as the CASTOR is in "Ready" state, i.e. no teleportation-process is running. 1.4.6.21 Event "Power-off"

The CASTOR is switched "off by the user. The CASTOR checks, if it is in the "Ready" state and if yes, it prepares itself for a "power-down" to transit into the "Stop" state. If a "Power-off signal is raised while not being in "Ready" state, the CASTOR performs a "fail-stop" action.

1.4.6.22 Event "Down "

After processing the "Stop" state, the CASTOR deactivates itself by disconnecting from the power supply. The "Down" event causes the CASTOR to transit to the "Off state.

1.4.6.23 Event "Request"

The "Request" event is issued either if the user triggers execution of a teleportation-run (the local user initiates a payment-request) or if an external message requesting paring has been received. The "Request" event transits the CASTOR from "Ready" state to "Pairing" state.

1.4.6.24 Event "Ok"

This is the expected normal state progressing step to advance within the protocol processing.

1.4.6.25 Event "Cleared" This event is automatically triggered in the "Fail" state after the internal processing of the fail-case and induces the "Ready" state.

1.4.6.26 Event "Logical-stop"

After "Payload negotiations" state the CASTOR checks if the negotiated requirements can be fulfilled. If yes, the CASTOR advances to the next state ("Ok"); else it will "pull the brake" by issuing this event.

1.4.6.27 Event "Abort"

The transaction cannot be completed, if it is impossible to conduct the transaction (e.g. due to both CASTORs cannot agree on the transaction's conditions or there is not enough money/value in the CASTOR). This event raised by the 'Transaction not possible" state switches the CASTOR to the "Fail" state.

1.4.6.28 Event "Fail (fair) "

In case the transaction is interrupted and the CASTOR detects no fairness-deficit upon termination of the teleportation-run, the "Fail (fair)" event is triggered to transit the CASTOR to the "Fail" state. 1.4.6.29 Event "Fail (unfair)

In case the transaction is interrupted, and the CASTOR detects a fairness-deficit upon termination of the teleportation-run, an affidavit proof of loss is generated by the CASTOR to restore the "status quo ante". The "Fail (unfair)" event is triggered in this case so as to transit the CASTOR to the "Affidavit generation for fairness recreation" state.

1.4.6.30 Event "Success "

After the successful transfer of the secrets, the CASTOR has to accomplish the non-repudiation generation-process, and therefore enters into the "Commit" state, and consecutively advances to the "Ready" state to become available for the next teleportation request. 1.4.7 Handling of Interruptions of the Off-line Transaction Protocol

As shown in the previous section, eleven protocol messages in protocol case [a] and ten protocol messages in protocol case [b] are to be transferred between Alice and Bob within the peer-to-peer offline transaction protocol. Within the first four messages the two protocol partners Alice and Bob pair and establish a secure VPN VPC channel (raising their transaction states from 'unknown' over 'paired' to 'authenticated') for the rest of their yet to be exchanged messages. Please note, due to some error/timeout possibility, the protocol can fail and stop after every single atomized action (message sent or received): Therefore, the transaction may not proceed and further messages won't be sent or received. To distinguish the two protocol cases [a] and [b], Figure 5 and Figure 6 show the message flow of the off-line transaction protocol case [a] and [b], respectively.

As shown in Figure 5, the eDoc[Ii _a ] object (serving as an electronic invoice, withdrawal, deposit or remittance) is transmitted from Alice to Bob within message [05a]. The message informs Bob why Alice sent this message, and the eDoc[Ii _a ] object comprises fields which can be used as evidence in a fairness reconstruction process. The eDoc objects differ from each other depending on the protocol case and state. Bob answers to Alice's message by adding his part to the eDocf _a ] object within message [06a].

Alice's message [07a] sends her payment (eCoins of the main secret) to Bob together with an updated eDoc[II _a ] object. As of the moment message [07a] has been sent, the interval of state uncertainly in case of a protocol interruption begins for Alice. In Figure 5 this time interval is therefore also referred to as "critical section". It ends with the successful reception of message [10a] or with an interruption of the off-line transaction protocol, e.g. due to a message-timeout or another error cause. Same applies for Bob: His "critical section" starts with the transmission of message [08a] and ends with the successful reception of message [09a].

Both "critical section" intervals are indicated by the two different triangles in Figure 5. The combination of both "Success" states (for Alice and Bob) means: The off-line transaction protocol state would result in a fair (successful) termination of the off-line transaction protocol for both parties upon any following interruption. Bob gets his "Success" after the reception of message [09a], Alice gets hers after receiving message [10a]. Both parties need a "Success" to make the off-line transaction protocol successful with a "deal" for Alice and Bob. "Deal" means, Alice and Bob both assume they have a contract with each other. These confirmation messages are important for the deal's confirmation in the final Confirmation Phase.

The general logic of Figure 6 for protocol case [b] is the same as described for Figure 5 except two technical details. First, there is no message [05b] in protocol case [b] because the flow logic doesn't need to be reversed as in protocol case [a]. The second distinction is the message flow direction: Due to the change of the main secret source (from Alice in protocol case [a] to Bob in protocol case [b]) the origins of messages [06] to [11] are reversed. Please note, the entity acting as source for the main secret being transferred is always the one which is in charge to successfully deliver message [09] to ensure a "Success" for the other entity.

1.4.7.1 Protocol State Analyses Next, all possible state transitions of the off-line transaction protocol discussed above and their results are analyzed taking into account the protocol behaves fail-stop. Please note, due to the off-line transaction protocol being of fail-stop type, no Byzantine failure (i.e. an erratic behavior of an entity with an intermediate error) possibility exists because a fail-stop does not allow any operation in case of incorrect behavior. The use of a fail-stop protocol means, whenever one CASTOR encounters an event calling for an interruption of the protocol-run, no error messages are produced or sent to the peer partner; instead the protocol is halted and the peer partner will time out. Questions to be answered will be:

- Can one CASTOR unambiguously detect the states of both CASTORs upon protocol interruption under all circumstances?

- Which states of failure for Alice and Bob will end in an unfair situation (e.g. losing the electronic tokens)?

- Can all unfair situations be handled in a way so fairness can be recreated, and how?

To answer these questions, the local states of both off-line transaction protocol-execution entities (Alice's and Bob's CASTORs) with respect to their local knowledge will be analyzed based on the state transition diagrams displayed in Figure 12 and Figure 13, for off-line transaction protocol cases [a] and [b], respectively. These state transition diagrams contain all possible combinations of the off-line transaction protocol states same is able to produce. All off-line transaction protocol failures at one off-line transaction protocol entity leading to an interruption become visible as timeouts at the other off-line transaction protocol entity, if the expected next off-line transaction protocol message cannot successfully be received within a predetermined period (timer) at the other off-line transaction protocol entity. Each fail-stop event causes an interruption of the off-line transaction protocol-run.

State diagram Figure 12 shows all possible states of the off-line transaction protocol for protocol case [a] (including the protocol states in case of an interruption). Alice's and Bob's states are shown in the boxes on the left-hand side and right-hand side, while the arrows are indicating the different protocol messages flowing between Alice and Bob.

As outlined above, Alice starts the protocol by transmitting message [01] to Bob. If this message goes lost nothing happens for Bob, and Alice faces a timeout, indicated by the state box [Alice TOl]. In order to do the transaction, Alice will have to reiterate the off-line transaction protocol by sending her first message [01] again. If Bob received message [01] successfully (i.e. message received and integrity check is passed) he answers by sending message [02] to Alice. In case of Bob doesn't receive message [01] he is not even aware a transaction had been intended!

If message [02] isn't successfully received by Alice (i.e. no message reception or message not passing the integrity check), she - again - faces the already aforementioned timeout. In this case the timeout will result in Alice terminating the protocol in state [Alice TOl].

Please note, on Alice's side all indicated left hand state boxes in Figure 12 starting with [Alice TOl] up to [WeakCommitted] indicate timeouts and thus (kind of) error states. Similarly, the right hand boxes on Bob's side starting from [Bob T01] to [Committed] indicate the timeout and (kind of) error states of Bob for protocol case [a]. Timeouts break the protocol flow by causing a fail-stop, i.e. an interruption of the off-line transaction protocol-run as indicated earlier herein.

The dotted state boxes [Commit3] on Alice's and Bob's side indicate the successful protocol-run for the respective protocol entity including the [Committed] timeout state.

Because no electronic tokens or any other valuable information is transferred during the exchange of the first messages (up to message [07]), all protocol failures for Alice and Bob ([Alice TOl], [Alice T02], [Bob TOl], [Bob T02]) always lead to the off-line transaction protocol's termination in a fan- state for both parties. The protocol failure cases [Alice T03] and [Bob T03] are not raising fairness problems because no fairness relevant information, in particular no electronic tokens, has been transferred yet.

Error event [Alice Ala] is a critical case for Alice. It happens if a timeout occurred after the transmission of message [07a]. Alice has transferred her electronic tokens to Bob without in turn obtaining the "receipt". This results in an unfair situation for Alice. In case of the [WeakCommitted] event for Alice, she has received evidence of her payment (i.e. transfer of her electronic tokens) in form of a valid electronic receipt (message [08a]), but she missed Bob's message [10a] (with the ACK2-ticket object) as an answer to her previously sent message [09a] (with the ACKl-ticket object). This also causes an unfair situation since Alice is still within the "critical section" of the off-line transaction protocol (i.e. has a "weak deal"), while Bob already considers the transaction a "deal".

In case Alice has successfully received message [10a] (with the ACK2-ticket object) from Bob, she enters - after sending her message [11a] with the ACK3-ticket object to Bob - into the [Commit3]- state and passes the protocol-execution successfully in a (final) fair state.

Regarding Bob, in case of a timeout or another error resulting in error state [Bob Bla], he previously sent his message [08a] containing his change secret (electronic tokens) and does not receive his receipt (i.e. message [09a]). Due to missing message [09a] containing the ACKl -ticket object the previously received main secret (electronic tokens) in message [07a] from Alice is destroyed by Bob's CASTOR and will not be released to the user's (i.e. Bob's) access.

In case of a successful reception of message [09a] from Alice with the ACKl-ticket object, Bob sends his message [10a] with the ACK2-ticket object to Alice in his [Commit2] state. In this case Bob has enough information about the deal for a successful termination in a (final) fair state. Depending on the reception of message [11a] with the ACK3-ticket object, Bob passes the protocol-run with an additional knowledge about the successful protocol-run of entity Alice in a [Commit3] state or simply within a [Committed] timeout.

For the protocol case [a], in conclusion, unfair situations imperative to be handled are the timeouts/error states [Alice Ala], [WeakCommitted] and [Bob Bla].

Figure 13 displays a state diagram with all possible off-line transaction protocol states for protocol case [b] (including the protocol states in case of an interruption). Figure 13 is indeed very similar to the state diagram described with respect to Figure 12 for protocol case [a]. The main difference between state diagram Figure 12 and state diagram Figure 13 is the respective role of Alice and Bob with reference to their payment: In Figure 13 and protocol case [b] Alice is the payee receiving the main secret while Bob is the payer to provide the main secret so that the state diagram of Figure 13 is essentially identical to that of Figure 12 with the positions of Alice and Bob reversed (except for message [05] missing in protocol case [b]).

In conclusion, unfair situations imperative to be handled for the protocol case [b] are the [Bob Bib], [WeakCommitted] and [Alice Alb] timeouts/error states.

1.4.7.2 State Discussion The tables shown in Figure 14 and Figure 15 show all possible ways how to terminate the off-line transaction protocol-run in case [a] and case [b], respectively, including also the terminations where both parties terminate in a fair state. Note that the abbreviation "C3" stands for a "Commit3" state. In the description below the terms "secret" and "value" have the same meaning. The column "ID" in the tables of Figure 14 and Figure 15 is used as reference to indicate a certain protocol stop situation. The column "State Pair" indicates the concrete stop event combination of Alice's and Bob's CASTORs as shown in Figure 12 and Figure 13. The two last state pairs in the tables provided by Figure 14 and Figure 15 are not caused by a timeout event. They refer to successful deals, respectively.

The column "Fairness deficit" indicates whether the protocol termination state of Alice respectively Bob (even to eMint) leads to an unfair state. "None" means, no party terminates the protocol in an unfair state. In case a name or names is/are indicated in the column, it they denote(s) the transaction party facing a fairness deficit due to the transmission situation of the off-line transaction protocol. The remaining columns in the tables shown in Figure 14 and Figure 15 are depending on the protocol role of the entities, distinguishing between Alice and Bob.

The column "Strategy" indicates for Alice and Bob, respectively, what the respective entity (Alice or Bob) has to do in case a fairness deficit for the entity occurs, "final" indicates the respective party doesn't have to do anything (no fairness deficit) and the off-line transaction protocol can be terminated in a final state, "rollback" indicates the undoing of the transaction processed so far. Please note, a "rollback" case for Alice is only possible for IDs 07a and 08a and a "rollback" case for Bob is only possible for IDs 06b and 07b. For the "locked wait" case, please refer to the more detailed discussion below. In these "rollback" cases the main secret has been transferred by Alice or Bob, but they have not received the change secret successfully meaning the reception of the message with the change secret is missing or the integrity check failed. As can be perceived from Figure 14 and Figure 15 for these states and for the respective other transaction party, these cases are terminated without a deal/contract, so Alice and Bob - in theory - could both rollback the transaction by un-deleting their respective eCoins for the main secret. Hence Alice and Bob could rollback the protocol-run '¾ack to the initial situation" before starting same.

However, for security reasons this may be undesirable, as it effectively allows a protocol termination case in which the CASTORs could decide not to destroy eCoins irrevocably once they have been transmitted, while the other party has received same (i.e. they are available at the other CASTOR as well, which facilitates a multi-spending case which should be avoided). This is thus a potential source of unwanted duplication of eCoins (i.e. the CASTORs would be effectively allowed to copy eCoins in special cases). Hence, even though a rollback is possible in the state combinations of IDs 07a, 08a, 06b, and 07b, i.e. Alice and Bob could perform the rollback in protocol cases [a] and [b], respectively, Alice and Bob nevertheless irrevocably destroy the transferred eCoins of the main secret and issue a proof of loss ("credit note" or "affidavit") for the eCoins of the main secret. Similarly, the CASTORs of Bob and Alice as receivers of the main secret in protocol cases [a] and [b], respectively, do not allow Bob and Alice to dispose the eCoins of the main secret in case they received message [07a] or [07b], respectively. Please note, in Figure 14 and in Figure 15 there are protocol case dependencies for the "weak deal" state. This is indicated by the words "Ok:" and "Nok:". "Ok" means, that the "weak deal" will finally end in a successful way. "Nok:" means the opposite, i.e. the "weak deal" will finally end in an unsuccessful way. This will be discussed in a more detail below.

The outcome of a transaction can be a state that is not immediately clear. This leads to situations, where the off-line transaction protocol is not able to produce final states. In these cases at least one of Alice and Bob has a "weak deal" meaning a sort of a legally unconfirmed claim. "Weak deals" will be intermediate states limited in time. They are in no case causing a deadlock situation. The off-line transaction protocol may help to prepare for the subsequent resolution of the "weak deal" - which is realized outside of the off-line transaction protocol itself - as it may allow for the CASTORs agreeing on a lock timeout period ("WeakDealLockDelay", WDLD) for "weak deals" in the Negotiation Phase. As mentioned above, alternatively, the lock timeout period is predetermined, or could also be negotiated between Alice and Bob in advance (i.e. before the run of the off-line transaction protocol), optional in combination with a restriction rule (e.g. not lower as and/or not higher as) and is passed to the CASTORs as a parameter for the protocol-run.

During this lock timeout period the CASTORs try to (re)contact each other and try to transit the "weak deal" to a "deal" by exchanging the "missing" information. Both CASTORs also know what to do after expiry of the lock timeout period, e.g. whether a respective CASTOR may dispose of the exchanged eCoins and/or receipt of the other party, whether to maintain this data in a storage or whether to irrevocably destroy these data blocks.

In the special cases of IDs 08a and 07b, Bob and Alice, respectively, initially encounter a "weak deal", which will always become "no deal" (i.e. no contract between Alice and Bob). This is due to the respective other protocol partner's state upon interruption (i.e. for ID 08a, Alice is in state Alice Ala; for ID 07b Bob is in state Bob Bib) leading to an (immediate) final termination (for Alice Ala and Bob Bib) of the off-line transaction protocol (through rollback) to a "no deal" situation, which means that Bob (Bla) and Alice (Alb), respectively, will never (as it is impossible) be contacted within a lock timeout period (meaning that in this case the "weak deal" partner have to wait to finish the complete lock timeout period) by their protocol partners (as they can/have immediately terminate/terminated the transaction) to resolve the "weak deal" for Bob, respectively Alice.

Hence, the "rollback" case in the column "Strategy", in Figure 14 and in Figure 15 may be considered as special case of the "final" case in terms of allowing the immediate termination of the off-line transaction protocol in a final state at the respective entity, but with a loss of the electronic eCoins of the main secret for Alice and Bob for a proof of loss and the collateral damage of waiting time, i.e. the complete lock timeout period for the respective partner entity. Hence, although rollback and termination of the protocol into a fair state would be possible in theory, the off-line protocol is terminated in an unfair state for the sender of the main secret. Alternatively, in case of the security concerns with respect to the duplication of eCoins (so called multi-spending) it is not imperative to handle protocol interruptions in a way to allow the sender of the main secret to keep the eCoins of the main secret, while the receiver of the main secret may need to clear the eCoins of the main secret.

The column "to clear" indicates whether any eCoins and at which amount need to be destroyed by the respective local CASTOR of Alice and Bob to achieve fairness, respectively. The columns "to refund" indicates whether any proof of loss ("credit note" or "affidavit") and at which amount the proof of loss needs to be created by the local CASTOR, which may be used in a fairness recreation process upon having terminated the off-line transaction protocol. In these two columns the "none" case is self- explanatory, "main value" denotes the eCoins of the main secret of the transaction and "change value" the optional change secret of the transaction.

The columns "receipt" in Figure 14 and in Figure 15 indicate the state of the receipt (also referenced as quittance or receipt) after the off-line transaction protocol-run. "invalid" means, the receipt is not longer valid, i.e. it is invalidated by the CASTOR.

The columns "state" , in Figure 14 and in Figure 15 indicate whether Alice and Bob conclude a deal has happened (i.e. a contract on the receivables of the transaction) or not (no deal), i.e. whether they consider them legally bound to a contract or not. It should be noted, Alice and Bob always come to the same conclusion on whether they have a deal or not (see column "state") for all state combinations with one exception: There is the possibility of a contradiction (see IDs 10a and 09b); this special case will be discussed in more detail below.

The "locked wait" case in the column "Strategy" indicates that the local knowledge at the respective entity is insufficient to conclude on whether there has been a deal or not (see IDs 08a, 09a, 10a for protocol case [a] and IDs 07b, 08b and 09b for protocol case [b]). It is thus the only case that the offline transaction protocol is terminating with a "locked wait" (un-final) state decision (in contrast to "final" and "rollback") for the respective entity. In case of such "locked wait" condition the protocol partners have to try to (re)contact each other (again) within a lock timeout period, so as to decide whether a deal (contract) is existent or not (see section "Fairness Recreation" below for more details). Of course, in case only one CASTOR is in the "locked wait" state, only this CASTOR will try to contact the other CASTOR. During the Negotiation Phase, Alice and Bob mutually negotiate a lock timeout period ("WeakDealLockDelay", WDLD) as a maximum time span during which Alice and Bob need to contact each other to resolve the protocol situation to - at best - a deal situation. If this doesn't lead to a success (due to the impossibility to (re)contact the other (former) partner party or because the time window is closed (lock timeout expired)), there finally will be no deal.

The following paragraphs will discuss some special cases for an interruption of the off-line transaction protocol, and their handling in a post-transaction protocol termination process in further detail. In case a respective one of the tamper-protected semiconductor module has not sent any electronic tokens yet, it may terminate the off-line transaction protocol immediately in a final and fair state. For example, in the states identified by IDs Ola, 02a, 03a, 04a, 05a, 06a, 07a, 01b, 02b, 03b, 04b, and 05b in Figures 14 and 15, respectively, the CASTOR of Bob can terminate the off-line transaction protocol immediately in a final and fair state. For Alice, the situation is slightly different: The CASTOR of Alice terminates the off-line transaction protocol immediately in a final and fair state in the states identified by IDs Ola, 02a, 03a, 04a, 05a, 06a, 01b, 02b, 03b, 04b, 05b, and 06b in Figures 14 and 15, respectively.

In the states identified by IDs 07a, 08a, 06b, 07b in Figures 14 and 15, respectively, the off-line transaction protocol is terminated after one of the tamper protected semiconductor modules, i.e. the CASTOR of the "payer", has transferred its electronic tokens without having received the expected response from the CASTOR of the "payee". In this situation, the CASTOR of the "payer" lacking the expected response, terminates the off-line transaction protocol immediately in a final, but however unfair state, in which the transferred electronic tokens are irrevocably destroyed and provides a proof of loss for the irrevocably destroyed electronic tokens.

In case the "payee" has successfully received the transferred electronic tokens (and nothing else thereafter) and has transferred change electronic tokens to the "payer", the "payee" terminates the "weak deal" phase of the off-line transaction protocol after expiry of a previously defined lock timeout period in a final but unfair state (see IDs 08a, 09a, 07b, 08b in Figures 14 and 15, respectively), in which the CASTOR of the "payee" irrevocably destroys the received electronic tokens (for main value) and provides a proof of loss (for the change value).

Another situation to be handled is the situation where the off-line transaction protocol is terminated after the CASTOR of the "payer" has transferred its electronic tokens to the CASTOR of the "payee". Further is assumed that the CASTOR of the "payee" successfully received the electronic tokens and returned a confirmation of receipt for the transferred electronic tokens and, optionally, change electronic tokens, but the "payee" did not receive the expected response to its confirmation of receipt for the transferred electronic tokens and, optionally, change electronic tokens the CASTOR of the "payer" - see, states IDs 08a, 09a, 07b and 08b in Figures 14 and 15, respectively. In this situation, the CASTOR of the "payer" terminates the off-line transaction protocol either immediately in a final but unfair state (state Bob Bib), in which its transferred electronic tokens (for the change value) are irrevocably destroyed, and a proof of loss for the main value is provided by the CASTOR of the "payer", in case it has not received the "payee's" confirmation of receipt for the transferred electronic tokens and the optional change electronic tokens or in a weak commit (WC) state (state Bob C2).

In case the CASTOR of the "payer" has received the "payee's" confirmation of receipt for the transferred electronic tokens and the optional change electronic tokens, the CASTOR of the "payer" terminates the off-line transaction protocol either in a final and fair state (see IDs 1 la, 12a, 10b, 1 lb) in case the 'Commit2' message was received or in a weak deal state (see IDs 09a, 10a, 08b, 09b). The off-line transaction protocol is terminated in a final and fair state (see IDs 11a, 12a, 10b, l ib) in case both tamper-protected semiconductor modules immediately receive all required messages or if both re-contact (within the "weak deal" phase of the off-line transaction protocol) each other and finish the transaction in a "weak deal" within a previously defined lock timeout period successfully. Otherwise the CASTOR of the "payer", which has transferred its electronic tokens to the CASTOR of the "payee", terminates the "weak deal" phase of the off-line transaction protocol in a final but unfair state (see IDs 09a, 10a, 08b, 09b) after expiry of the previously defined lock timeout period, in which the CASTOR of the "payer" produces a proof of loss for the main value of the electronic tokens already transferred to the CASTOR of the "payee" and irrevocably destroys the electronic change tokens received from the CASTOR of the "payee".

The CASTOR of the "payee", which did not receive the expected response to its confirmation of receipt for the transferred change electronic tokens (see IDs 08a, 09a, 7b and 08b) terminates the "weak deal" phase of the off-line transaction protocol after expiry of a previously defined lock timeout period in a final but unfair state, in case the tamper-protected semiconductor modules fail to re-contact each other within the previously defined lock timeout period successfully: The CASTOR of the "payee" irrevocably destroys the previously received electronic tokens of the main value and provides a proof of loss for change value of the previously sent electronic change tokens, in case the CASTOR of the "payee" has transferred change electronic tokens to CASTOR of the "payer" in response to having received the main electronic tokens from the CASTOR of the "payer".

With respect to the special cases denoted with IDs 09a (and 10a) and 08b (and 09b), it should be noted that the indicated state combinations of Alice and Bob upon interruption of the protocol are the only ones that do not allow to terminate the off-line transaction protocol in a predetermined (logically) final state. A final state of the transaction in terms whether Alice and Bob assume a deal or no deal to be achieved, depends on whether the two CASTORs can resolve the situation by (re-)contacting each other during a lock timeout period within the "weak deal" phase of the off-line transaction protocol. If this is not the case, the CASTORs transition the intermediate "weak deal" state to a final "no deal" state. If the two CASTORs (re)-contact each other successfully within the lock timeout period - this is not part of the off-line transaction protocol -, the CASTORs can transit the intermediate "weak deal" state to a final "deal" state.

In these situations identified by IDs 09a and 08b both (Alice and Bob) have a "weak deal". This offline transaction protocol state will decide within the already addressed lock timeout period ("WeakDealLockDelay", WDLD) for both entities always at the same (identical) outcome state: Both CASTORs decide either for "no deal" or for "deal"; there will be never a contradicting outcome.

The only possibility for a contradiction in the termination of the off-line transaction protocol potentially exists in cases ID 10a or ID 09b: It could be argued, what happens if the off-line transaction protocol entity having the "weak deal" ("WeakCommit" state) in the state combinations of IDs 10a and 09b does not catch-up the missing message (up to the end of the lock timeout period) from the other protocol entity (which assumes a deal having been made) anymore and concludes on "no deal" (contradiction). This might happen indeed.

Assume for exemplary purposes, the protocol entity experiencing the "weak deal" was buying a service or tangible/intangible product ("Customer") and the other protocol entity was supplying the service or tangible/intangible product ("Merchant"), and that the Merchant assumed a deal, and the Customer has transited his/her "weak deal" to a "no deal". In this case the contradiction on the success state of the transaction remains: The Customer assumes no deal being made, while the Merchant considers the opposite (see for example, ID 10a and 09b of the tables in Figure 14 and Figure 15). This contradiction can be resolved as follows: The Customer (who lost his eCoins according to his final state of the off-line transaction protocol = no deal) contacts his eCoins issuing authority (eMint) and claims compensation for the eCoins paid to the Merchant. The proof of loss having been generated for eCoins paid to the Merchant by the Customer's CASTOR in case of terminating the transaction protocol finally in a "no deal" state serves as evidence the Customer can provide to claim for compensation. Please note, it is assumed that the proof of loss does not only indicates the eCoins (e.g. their identifying descriptor items (e.g. serial numbers) and value) destroyed by the Customer's CASTOR, but also provides additional information on the transaction partners, so that the Merchant is identified (e.g. by means of a vendor ID on the electronic receipt and the user Type-I II certificate).

It's up to the issuing authority/eMint's policy if the Customer is compensated for his loss instantly or if he has to wait until the Merchant (or any other party) clears the eCoins against the issuing authority within their transferability period (eCoins can be defined to be transferable for a significantly shorter period of time (e.g. several months, e.g. 3 month), but would be valid for a much longer time (e.g. 3 years)). If (respecting to the second possibility) the "lost" eCoins are not cleared in this transferability period of time, the issuing authority/eMint compensates the Customer for the loss.

In this end-of-transferability-period moment (but no later than the clearing of the eCoins), the issuing authority/eMint is able to detect if a collision occurs (i.e. the eCoins being claimed by the Customer for compensation have been cleared by someone else, i.e. the Merchant). If no collision is detected (i.e. the eCoins to be compensated for have not been cleared yet), the issuing authority/eMint compensates the Customer, but now knows the identity of the Customer in return (which may used in a liability claim for fraud, etc.).

If eCoins for which compensation has been claimed by the Customer (which are still in the possession of the Merchant) are not (never) cleared (and expire as a consequence of that), the compensation claim is settled for the issuing authority/eMint, because fairness is restored: Neither the issuing authority/eMint nor the Merchant nor the Customer suffers a loss (equivalent to destroying a bill). However, in case the Merchant clears the eCoins with his authority/eMint (either directly or spending/travelling them through the economy), the authority/eMint will in turn ask the Customer for compensation. Please note, the Customer is known to the authority/eMint as he requested compensation of the eCoins. At this point, the Customer could be requested to clear the situation (e.g. by proving the deal hasn't been successful (i.e. "no deal"), i.e. the Customer has not received the service or tangible/intangible product subject to the deal. In case the authority/eMint can prove the Customer's allegation wasn't true (e.g. by evidence received from the authority/eMint's CASTOR), the Customer is convicted of fraud. This is discussed in more details later this section. Overall, there is a low probability for encountering such situations, and the intentional creation of such situation is not attractive in view of the evidence on each transaction produced by the CASTORs and the de- anonymization of the parties (Customer and Merchant).

Due to the importance of understanding the cases where a contradiction in the termination of the offline transaction protocol for Alice and Bob occurs, the previous discussion is reduced in the following (due to a measure of redundancy reduction) leading only to the [a] case. The situation in the [b] case is logically identical to case [a], reversing the Alice's and Bob's entity positions:

In case of ID 10a, Bob always has a "deal", but for Alice it is possible to have a "no deal" due to the possibility of erratic channel behavior. This contradiction (as indicated above) makes it necessary to escalate fairness clearing to a higher level (all other cases don't need special treatment as they always have identical common states) and contradiction cannot be healed on a formal algorithmic layer within acceptable expenses. The way to solve it results from the nature of the treatment of same loss problem: In case of the transition "weak deal" -> "no deal", the party suffering the loss is in the necessity of requesting compensation by using the affidavit generated by the CASTOR. This leads to several consequences like the de-anonymization of the party with the claimed loss, knowing the identity of the transaction partner of the party with the loss, and the identifying descriptor item (e.g. serial numbers) of the used eCoins. Additionally, the eMint can check/prove the existing ID case of the contradiction (IDs 10a, ID 09b).

During the refund procedure the eMint can (mostly always) check within her legal limits or only in selected cases (e.g. depending on the level of the loss) if the loss claiming party additionally receives the paid product or service. This is also possible within money remittances, withdrawals, or payments of an amount of money. If the eMint is able to find evidence the party claiming the loss nevertheless took the counter-value of the transaction, the eMint might refuse compensation and escalate the situation to court.

It should be noticed, a multi-spending scenario does not occur in any situation. Not a single eCoin never ever will be replaced by a counterpart of the same identifying descriptor item (e.g. serial number). The finality of the transaction is also not destroyed, the success case is in every circumstance immediate, except in the "weak deal" cases (when WeakDealLockDelay (WDLD) > zero). 1.4.8 "Weak Deal" Phase

The "weak deal" phase of the off-line transaction protocol (i.e. the "weak deal" phase is also off-line) is entered in case there is an interruption of the off-line transaction protocol in a situation, in order to give the two CASTORs the chance to re-contact each other and to end the transaction successfully (e.g. by exchanging the previously missing protocol messages for a successful ending of the run of the off-line transaction protocol). The "weak deal" phase is not entered every time the off-line transaction protocol is interrupted, but only in cases where the respective local knowledge of the CASTORs on the transaction is insufficient to allow both CASTORs to conclude on the success or failure of the transaction. These are the states identified with IDs 8a, 9a, 10a in Figure 14 and IDs 7b, 8b and 9b in Figure 15. The weak deal" phase of the off-line transaction protocol is basically the "protocol" the two CASTORs follow in these cases and mainly consists of the two CASTORs trying to re-contact each other in a lock timeout period ("WeakDealLockDelay", WDLD) in order to come to either a successful termination of the transaction ("weak-deal" -> "deal") or unsuccessful termination of the transaction ("weak-deal" -> "no deal"). According to whether there is a deal or no deal for the respective tamper-protected semiconductor modules the take respective actions to avoid misuse of the transaction system, such as for example destroying electronic tokens, generating a proof of loss where applicable, etc. In chapter "Fairness Recreation" below, it will be outlined in detail on how the CASTORs behave in case the "weak deal" becomes a "no deal", i.e. the transaction is not successfully terminated within the lock timeout period.

In one exemplary embodiment, in case of an interruption of the off-line transaction protocol in a situation in which the response to the message [10] with the ACK2-ticket object is outstanding at the CASTOR sending message [10] (IDs 10a and 9b), the respective CASTOR repeatedly sends message [10] with the ACK2-ticket object also during the lock timeout period. This can be considered a re- contacting of the CASTORs. As can be noted in Figure 14 and Figure 15 upon reception of the ACK2- ticket object, both CASTORs consider the transaction sucessful. The repetition of message [10] during the lock timeout period may be advantageous as it increases the chance the other CASTOR receives message [10] with the ACK2-ticket object and advances to the next state (IDs 1 la and 10b) in which Alice and Bob have a deal, and no fairness deficit occurs.

At the end of the lock timeout period ("WeakDealLockDelay", WDLD) one of the following two possible "weak deal" transitions will be performed/finalized:

- Missing message [10] has been successfully delivered: transition "weak-deal" -> "deal" is fulfilled, else

- "weak-deal" -» "no deal" is fulfilled/settled.

It is also possible to define a lock timeout period of zero duration. In this case the "weak deal" protocol is de facto not existent. In this case, all state decisions of the off-line transfer protocol are immediately final. All "weak deals" depicted in Figure 14 and Figure 15 then transit into "no deal" states, and the distinction of "Ok" and 'TSiok" (not ok) will collapse to the "Nok" option. In this sense the "weak deal" protocol is the more general case including the "in statu nascendi" final (zero lock) case.

The following list shows exhaustively all (theoretically) possible combinations of "reasons, why the contradiction has happened" for protocol Case [a] - for protocol Case [b] the roles of Alice and Bob are reversed:

- Statistical error case: Due to the very small probability of transmission errors over erratic channels the off-line transfer protocol can collapse into a "weak-deal" -> "no deal" condition. In this case the eMint may accept the loss and take the ownership of the referenced goods or services paid by the party which is to be compensated due to the affidavit mechanism. This could be handled like an insurance calculation based model.

- Alice cheats: Alice "constructs" this exceptional case wishing as well to get compensated by the eMint and as to receive the paid goods or services. In this case the eMint compensates Alice and becomes aware of Alice's identity (a recommended condition), Bob's identity (contained in the presented eDoc, part of the affidavit), and the identifying descriptor items (e.g. serial numbers) of the used eCoins. Sooner or later (up to the eCoin travelling speed through the economy and the clearing moment of the involved eCoins), the eMint is able to prove if Alice has produced a fraudulent claim against the eMint.

- Bob cheats: This is impossible (in protocol Case [a]).

- Alice and Bob are teaming to cheat: Both parties produce fictitious transactions to generate loss which then shall be paid by the eMint (claiming compensation). As one of the pre-conditions for loss compensation the eMint has to become aware of Alice's identity (only feasible with the recommended de-anonymization). Thus, if Alice cheats the eMint will become aware not only of Alice's but also of Bob's identity (because it is contained in the eDoc's data structure as part of the affidavit), and the identifying descriptor items" (e.g. the serial numbers used herein), too.

- Even if Bob "supported" Alice by not telling the truth about a specific former transaction the eMint can prove the untruth of Bob's statement once Alice clears the respective eCoins.

Table 25 contains a rating comparison of methods and arguments for a down-streamed "weak deal" handling (WeakDealLockDelay (WDLD) > zero) or an immediate handling (WeakDealLockDelay (WDLD) = zero) in the "weak deal" case:

Table 25: Preliminary considerations for "weak deal" handling possibilities.

The fundamental difference between a "weak deal" and an "instant deal", as discussed above, is the reduction of the "weak deal no deal" occurrence's probability. This result from the effect of chaining up Alice and Bob together for a limited time frame (WeakDealLockDelay, WDLD) to provoke a (re)connect.

Summarizing the protocol Case [a] as shown in the table of Figure 14 the following should be noted:

- There are no more than 12 different ways to terminate the off-line transaction protocol.

- Eight of them (IDs Ola, 02a, 03a, 04a, 05a, 06a, 11a, 12a) terminate the protocol always in an immediately fair state to both parties, meaning fairness reconstruction is not required.

- Three (IDs 07a, 08a, 09a) terminate the protocol in an unfair state (always for IDs 07a, 08a, and only within a given probability for ID 09a), and may possibly cause the necessity of a postponed fairness reconstruction.

- One (ID 10a) possibility of state contradiction (as discussed above) leads to a more complex handling of a postponed fairness reconstruction process to the parties. - "weak deal - no deal" and "weak deal -> deal" mean a transformation from intermediate state to an final state within the "weak deal" phase of the off-line transaction protocol, indicating part of a "phase-change" transition of the off-line transaction protocol.

In protocol Case [b], as shown in the table of Figure 15, it is important to notice the following:

- There are no more than 11 different ways to terminate the off-line transaction protocol.

- Seven of them (IDs 01b, 02b, 03b, 04b, 05b, 10b, and l ib) terminate the protocol always in an immediately fair state to both parties, meaning fairness reconstruction is not required.

- Three transaction results (IDs 06b, 07b, and 08b) terminate the protocol in an unfair state (always for IDs 06b, 07b, and only within a given probability for ID 08b) and may possibly cause the necessity of a postponed fairness reconstruction.

- One (ID 09b) possibility of state contradiction (as discussed above) leads to a more complex handling of a postponed fairness reconstruction process to the parties.

- "weak deal - no deal" and "weak deal deal" mean transformations from an intermediate state to an final state within the "weak deal" phase of the off-line transaction protocol, indicating part of a "phase-change" transition of the off-line transaction protocol.

An error event that interrupts the off-line transaction protocol is raised in cases where the expected next message is not successfully received by the entity within a given time frame (timeout) or in cases where the error is caused by an unsuccessful integrity check of a message or another source of error (e.g. communication channel down, sudden power outage at one peer-device, manual termination of the transaction by the user, etc.). Beyond this fact one can be speculate about the reception of the previous message sent by the party which triggers the error-event at the respective other protocol- partner: Either the previous message was not received and the protocol partner faced already a timeout error event itself, or the previous message was received and there are other reasons, why the next message was not transmitted or received.

The tables of Figure 14 and Figure 15 reflect this "Byzantine General" transmission effect in the column "State Pair". Every timeout/error state is indicated twice for Alice and Bob, which can be interpreted as a state-case-splitting. For example, error state TOl for Alice in the table displayed in Figure 15 is shown in the ID-cases 01b and 02b. These two cases directly fit into the assumption dilemma (of not being able to know), why the expected message was not received successfully. Fact is Alice is unable to decide, which reason caused her timeout. This is a fundamental preposition for the off-line transfer protocol's intention. However, she is not in the need to differentiate. The situation can be cleared without Alice knowing the (exact) reason why her timeout/break resulted in the error state. 1.4.9 Fairness Recreation

As shown in the previous section as well in Figure 14 and Figure 15, it is impossible for the sender of a lost message to differentiate between the case the message has been received by the receiver, and the case the sender had missed the subsequent message. Therefore, from the perspective of this basic observation, the following paragraphs will discuss in further detail the actions needed for fairness recreation after the termination of the off-line transaction protocol.

Applying to the directive "pacta sunt servanda" ("promises must be kept") a transaction system has to guarantee the finality of payments under all circumstances. Due to the inevitability of losing (some) messages, the underlying strategy is loss compensation. It is important to note, if it is possible to compensate a protocol entity that experiences a loss of eCoins induced by the transmission thereof, the off-line transaction protocol is a "closed shop". A transaction system may thus guarantee through the usage of its off-line transaction protocol:

- it is impossible to increase the value (inflation of eCoins) and

- it is also impossible to lose value (deflation of eCoins).

This guarantees it is impossible to get an advantage neither over the other protocol party nor over the issuing authority/eMint as the protocol party for clearance/deposit, withdrawal, etc.

1.4.9.1 Proof of Loss in the eCash System (using the Electronic Document - eDOC)

As indicated above, the off-line transaction protocol may terminate in an unfair state. In order to reconstruct fairness to the parties of the transaction, it may therefore be advantageous if the parties to the transaction (in more detail the tamper-protected semiconductor modules) use a mechanism that allows to prove loss of any electronic token to a third party in a fairness reconstruction processes. According to another aspect of the invention, this is achieved by providing an electronic document that can be considered a non-repudiation token to ensure non-repudiability of the transaction.

In an exemplary implementation, the transaction protocol messages exchanged by the tamper- protected semiconductor modules during the Negotiation Phase and the Electronic Token Transfer Phase each comprise an electronic document that contains information on the state of the transfer of the electronic tokens and which is part of the proof of loss provided in a respective tamper-protected semiconductor module if a termination of the transaction protocol ends in an unfair state.

Such electronic document may for example comprise at least one of:

- an information on the transaction (e.g. type of the transaction (e.g. invoice, withdrawal, deposit, remittance, etc.), transaction ID, semiconductor module ID, amount and type of the electronic tokens, date, time, serial number information, user certificate references, and other data from the local user environment and/or the operating platform (e.g. comprised, at least in part, in the eDoc.eRequest.HTML5_Script section), please refer to the eRequest eDoc structure documented in chapter "eDoc Type Objects") and the tamper-protected semiconductor module(s) executing the transaction, the information being signed by a signing key of the tamper-protected semiconductor module initiating the transaction and/or counter-signed during the message exchange process by a signing key of the tamper-protected semiconductor modules concerned in that transaction, a "WeakDealLockDelay (WDLD) section, including a place (scratch) where to exchange proposed values for the weak deal lock delay prior to the negotiation and indicating the selected and negotiated value for a potentially later applied weak deal handling procedure. This information may also being signed and/or counter-signed as it is the case in the later delineated eRequest eDoc data structure,

a "Ranked Suggestion List" (RSL) of candidate combinations of atomic electronic token denominations stored in the tamper-protected semiconductor module and respective, optional change preferred candidate combinations of atomic electronic token denominations that fulfill the receivable of the transaction (signed and/or counter-signed),

a selection of one of the candidate combinations of atomic electronic token denominations and respective, optional change preferred candidate combinations of atomic electronic token denominations selected from the„Ranked Suggestion List" (signed and/or counter-signed), identifying descriptor items of the selected candidate main combination of atomic electronic tokens stored in the first tamper-protected semiconductor module transferred to the second tamper-protected semiconductor module, wherein the identifying descriptor items of the selected candidate combination of atomic electronic tokens are signed and or counter-signed by the signing key of the first tamper-protected semiconductor module,

identifying descriptor items of the selected candidate change combination of atomic electronic tokens stored in the second tamper-protected semiconductor module transferred to the first tamper-protected semiconductor module, wherein the identifying descriptor items of the selected candidate change combination of atomic electronic tokens are signed and/or counter-signed by the signing key of the second tamper-protected semiconductor module, and

a confirmation of receipt of electronic tokens (e.g. comprised, at least in part, in the eDoc.eReceipt.HTML5_Script section) signed and/or counter-signed by the signing key of either the first or the second tamper-protected semiconductor module, depending on whether the first or the second tamper-protected semiconductor module initiated the transaction,

a voucher in form of an affidavit usable for the compensation claim against the issuing authority/eMint.

According to an exemplary embodiment, the first version of the electronic document is generated within the Negotiation Phase of the electronic tokens to be transferred in the transaction and the electronic document is updated and exchanged by the tamper-protected semiconductor modules as part of the transaction protocol messages exchanged by the tamper-protected semiconductor modules in the Negotiation Phase and the Electronic Token Transfer Phase. The tamper-protected semiconductor modules may for example mutually sign and counter-sign information added to the electronic document as part of the update thereof.

Such a proof of loss provided by a CASTOR can be considered a voucher in form of an affidavit to an external arbiter (issuing authority of the eCoins/eMint). This voucher can be exchanged for eCoins of the corresponding value. The eCash system uses this mechanism to compensate a party with a fairness deficit to recover fairness. A proof of loss may be constructed similarly to the eCoins, however lacking the "transferability" property.

1.4.9.2 Unfair Transactions or Compensation Cases

In the previous section "Handling of Interruptions of the Off-line Transaction Protocol", the state pairs which may lead to an unfair termination of the off-line transaction protocol as shown in the tables of Figure 14 and Figure 15 already have been a discussed. In these cases Alice and/or Bob (as the users) receive a proof of loss from their CASTOR to prove their loss of the eCoins of the main secret/values and/or the eCoins of the change secret/values, respectively.

Overall, only four state pairs (IDs) exist where a post off-line transaction protocol fairness reconstruction (may) become(s) necessary to restore fairness. For protocol Case [a] these are the state pairs corresponding to IDs 07a, 08a, 09a, and 10a of the table shown in Figure 14 and another four in the protocol Case [b] for the state pairs corresponding to IDs 06b, 07b, 08b, and 09b as shown in the table of Figure 15. All others state pairs lead to an immediate final termination of the off-line transaction protocol into a fair state for Alice and Bob, so no compensation of any loss has to be performed.

Fairness recovery includes a reimbursement of an eCoin loss for the transacting party incurring the loss, so the original state before entering into the transaction is restored, e.g. no transaction ever happened ("no deal"). None of the successful deals (i.e. "deal") require any compensation. In some rare cases, however, the transaction results into a "weak deal" status. In these cases, it depends on the (delayed) final status of the transaction (deal or no deal), whether the transaction resulted in a loss, calling for a fairness reconstruction. It is assumed in the presented eCash system, the issuing authorities of the electronic tokens (eMints) always are "collecting all losses and forming the source of reimbursement for the parties with the loss". This will be outlined further below in the section " Reimbursement Treatment resolved by the Issuing Authority (eMint)". 1.4.9.3 Unfair State Case Alice Ala

Table 26: Excerpt from Figure 14 of the termination pairings.

This state pair occurs if Alice (as the payer) transmitted the eCoins of the main secret (main value) to Bob (as payee) within message [07a], and Alice didn't receive Bob's message [08a] with the eCoins of the change secret (change value) that would contain Bob's receipt (as part of the eDoc) to confirm reception of Alice's message [07a] in return. Instead, Alice faces a timeout. As outlined above, this situation may be - in theory - resolvable by a rollback and "recreation" of the main secret by Alice's CASTOR. As outlined above, such "minting capability" for CASTORs is undesirable. In this case the rollback performed by Alice's CASTOR will immediately and finally conclude there is "no deal" (see column "state"), and her CASTOR will terminate the off-line transaction protocol so Alice loses her main value (i.e. her eCoins of the main secret are deleted). Further, Alice's CASTOR generates and provides a proof of loss for these eCoins for a postponed compensation with the eCoin-issuing- authority (eMint) - see column to "to refund" indicating "main value". Alice has no receipt from Bob - see column "receipt" indicating "missing", and the deal with him is not successful ("no deal"). 1.4.9.4 Unfair State Case Bob Bib

Table 27: Extract from Figure 15 of the termination pairings.

This is the almost same situation as outlined for Alice in the section "Unfair State Case Alice Ala" above but the roles of Alice and Bob exchanged due to no flow reversal in the protocol Case [b].

1.4.9.5 Unfair State Case Bob Bla

Table 28: Extract from Figure 14 of the termination pairings. This situation may occur in protocol Case [a], if Bob's CASTOR sent his eCoins of the change secret to Alice in message [08a] - i.e. after having received her main value in message [07a] - in his (Bob's) role as payee. However, the expected first confirmation message [09a] ('Commitl ' message) does not arrive at Bob's CASTOR, and it goes into a timeout.

This situation will result into a lock state as consequence of the "weak deal". This is indicated for Alice by the 'WC, an acronym for a 'Weak Commit'. Bob currently doesn't have a valid contract with Alice, and therefore, he cannot bank Alice's payment (Alice's eCoins of the main secret) - see column "to clear" indicating "main value" for the case there finally is no deal. Being locked means, Bob's CASTOR cannot immediately terminate the off-line transaction protocol into a final state. A lock imposes a lock timeout period for any party which has a reconnection opportunity to change the "weak deal" to a successful "deal" status.

If Bob is able to conclude the transaction within that time frame (lock timeout period) because he's able to re-contact Alice and to finally receive her confirmation message [09a], the deal ends with a success for Bob. The lock will be removed, no proof of loss will be generated, and no value is cleared. Alice's eCoins of the main secret are "unfrozen" by Bob's CASTOR and transferred into his value pool for further disposition through Bob.

If the lock time window (lock timeout period) at Bob's side is "closed" without a prosperous reconnection, Bob's CASTOR will transit the intermediate state of the transaction from "weak deal" into "no deal". Before removing the lock in this case, the main value (i.e. Alice's eCoins of the main secret) that Bob received previously within message [07a] will be irrevocably destroyed - see column "to clear" indicating "main value" -, and a proof of loss will be generated for the lost eCoins of the change secret - see column "to refund" indicating "change value". The previously sent receipt will be annulled (it loses its validity).

It is noteworthy, in case of ID 08a the deal will be always unsuccessful ("weak deal no deal") for Bob, i.e. the "weak deal" state will always transit to a "no deal" state in order to come to the same final transaction state for this case as Alice who has to conclude, no deal had been made due to the missing eCoins for the change secret of message [08a] at her side (see table in Figure 14).

During lock state, both CASTORs are able to effect other (further) transactions; only the data objects of the "weak deal" will remain blocked and, with respect to data coherence, unavailable.

1.4.9.6 Unfair State Case Alice Alb

Table 29: Excerpt from Figure 15 of the termination pairings. This is almost the same situation as outlined for Alice in section "Unfair State Case Bob Bla" above, except for exchanged roles of Bob and Alice due to no flow reversal in the protocol case [b].

1.4.9.7 Unfair State Case Alice Weak Commit (WC)

Table 30: Extract from Figure 14 of the termination pairings.

In this situation, Alice sends her first confirmation message [09a] ('Commitl ' message) to Bob after she has received his eCoins of the change secret with the receipt. Alice is acting in her role as payer. Nevertheless, Alice doesn't receive the expected confirmation message [10a] ('Commit2' message) from Bob so she runs into a timeout. This situation results into a lock state, a consequence of the "weak deal". Alice currently has no valid contract with Bob. This is indicated by 'WC, an acronym for 'Weak Commit'. Being locked means, Alice's CASTOR cannot immediately terminate the off-line transaction protocol in a final state. A lock imposes a lock timeout period for a party having a reconnection opportunity to change the "weak deal" to a successful "deal" status.

If Alice is able to conclude the transaction within that time window (lock timeout period) by being able to contact Bob (who also has a "weak deal" for the state pair corresponding to ID 09a) and finally by receiving her confirmation message [10a] from Bob, the deal ends with success for Alice, i.e. the "weak deal" will be transitioned to a "deal". The lock will be removed and no proof of loss will be generated.

If the lock timeout window is "closed" at Alice's end without a prosperous reconnect there is "no deal". Before removing the lock in this case, a proof of loss is generated for Alice's main value - see column "to refund" - and Bob's change payment is deleted - see column "to clear". The previously received receipt from Bob (as part of message [08a]) will be annulled and turned into a proof of loss for the lost main secret. In the unsuccessful ID 10a case ("Nok:"), the eMint loses the main value to Alice.

Please note, in cases the transferred eCoins are to be destroyed irrevocably (later) upon termination of the protocol and not immediately after their transfer, it'd be possible to still use these eCoins as internally available eCoins for compensation purposes. This solution, however, may be considered less favorable because being more risky.

During the lock state the CASTORs may be able to effect other (further) transactions; only the data objects of the weak deal will stay blocked and, with respect to data coherence, unavailable. The indication 'C2' is an acronym for a 'Commit2' for Bob in the ID 10a.

1.4.9.8 Unfair State Case Bob Weak Commit (WC)

Table 31: Excerpt from Figure 15 of the termination pairings.

This is almost the same situation as outlined for Alice in the section "Unfair State Case Alice Weak Commit (WC)" above except for exchanged roles of Alice and Bob due to no flow reversal in the protocol case [b].

1.4.10 Reimbursement Treatment resolved by the Issuing Authority (eMint)

The compensation is granted by the eCoins issuing authority (eMint) to be compensated in exchange of the proof of the loss the CASTORs generate in case of (unfair) termination of the off-line transaction protocol, including the clearing (i.e. deletion) of eCoins. The proof of loss for the thus lost eCoins may for example be provided by means of the eDoc object updated and exchanged between Alice and Bob as part of the protocol-run.

In all cases where a user is to be compensated for a loss, the issuing authority (eMint) should mandate the user to reveal his identity before it refunds the user's eCoins. Please note the off-line transaction protocol may provide full anonymity to the users. Cases of refunding eCoins to Alice and Bob are adapted to the principle 'in dubio mitius' (latin for„In the doubts the mild/the more favorable"), because it is considered impossible for the CASTOR to detect, whether transmission of a message from the other CASTOR during the run of the transaction protocol really happened, or not. It is assumed, in these compensation cases the CASTORs had followed the off-line transaction protocol, and the CASTORs were not tampered (see also the countermeasures to prevent tampering of the CASTORs discussed herein). As mentioned above, the CASTOR annihilates eCoins before it provides (in exchange) any proof of loss effecting the reimbursement as one measure of security.

One possibility to implement a fairness restoration process after termination of the off-line transaction protocol for the compensation of eCoins could consist of a direct transfer of the compensated eCoins in form of newly generated eCoins to the loss claiming party's CASTOR after a presentation and validity confirmation of a proof of loss automatically generated by the CASTOR itself. For the fairness recreation process it is not critical how the proof of loss is transferred to the issuing authority responsible to compensate the loss (eMint). For example, the proof of loss could be sent even (several times) within an email or be uploaded to the issuing authority by any other means. It is unattractive to misuse the fairness restoration compensation mechanism to generate (steal) value due to the way eDocs and EoO tickets are used since those are signed by the respective. CASTOR which uses its signing key corresponding to the public keys indicated in their respective root certificate (Type-VI) and user certificate (Type-I II). Hence, a misuse would become possible only if the PKI of the eCash system was broken, which is considered impossible.

As already indicated above, the eDoc object exchanged between the CASTORs during the off-line transaction protocol-run - inter alia - contains the lost eCoins identifying descriptor items (e.g. serial numbers). Please note all information that may serve as a proof of loss can be included in the eDoc. Furthermore, the issuing authorities are assumed to keep track of self-minted eCoins cleared by the users. Hence, using their multi-spending database, each issuing authority can check whether the "to be cleared" eCoins have been cleared already, or whether eCoins declared as "lost" weren't multi-spent or cleared by someone else already, respectively.

In case of a valid compensation request, the lost eCoins due to be compensated will be added to the multi-spending database (i.e. their identifying descriptor items (e.g. their serial numbers) are stored therein). This enrollment ensures that any party trying to clear those eCoins (again) will be detected. The expenses for a proof of loss falsification are comparable to multi-spending expenses; in both cases the CASTOR itself had to be manipulated, which is presently considered impossible due to the usage of a PKI infrastructure and due to the usage of several additional structural and functional measures which improve the CASTOR'S tamper-resistibility (which are comprised in other design elements of the invention as previously mentioned herein).

The (policy dependent) requirement to unveil anonymity in case a user is claiming a reimbursement makes, lowers the incentive to misuse the compensation mechanism for fairness restoration. Indeed, the compensation mechanism for fairness recreation won't increase the threat potential against the presented eCash system. The fairness restoration process doesn't include any interdependence between the transaction parties Alice, Bob, and the issuing authority (eMint); all relationships are reduced to Alice vs. issuing authority or Bob vs. issuing authority. Every transaction party in the eCash system can act on its own interest without the necessity to perform a "menage a trois". This is a consequence of the "delayed-true fairness" goal which separates the on-line fairness reconstruction process from the actual value transfer process by means of the off-line transaction protocol.

Last but not least, some additional measures of efficiency and security should be noted:

- Electronic receipts exchanged between Alice and Bob as part of the transaction protocol messages (e.g. as part of the eDoc objects) are used to indicate an evidence proving a transaction within the eCash system. The practical intention might be a legal claim of the payer against the payee (e.g. ticket).

- In case of a transition from the intermediate "weak deal" state to a final "no deal" state, where the proof of loss comes into play, the meaning of an eReceipt changes immediately: Its original intent being a receipt expires. Instead, from now on it represents the evidence for a reimbursement claim against the issuing authority (eMint), which can be claimed as part of the fairness reconstruction (this can only be the case in the IDs 09a, 10a, 08b, and 09b).

- If a CASTOR ever creates a proof of loss for eCoins lost within an eCoin clearing transaction the proof of loss also contains identifying descriptor items (e.g. serial numbers) of the destroyed eCoins, which aids the detection of multi-spending attempts.

- Measures are to be taken to prevent against the fraudulent double-usage of the electronic receipt as well as documentary evidence against the transaction partner as well as a proof of loss for a reimbursement claim against the issuing authority (eMint). 1.4.11 Effectiveness

1.4.11.1 Forfeiture Probability

To calculate the resource demand for the issuing authority's reimbursement processing capacity realistically one has to know, how often protocol-runs will end with a fairness deficit (that requires the reimbursement of eCoins). To answer this question one has to focus on the following central issues: 1. What is the statistical occurrence for the off-line transaction protocol to be interrupted and terminated in an unfair state in relation to the total amount of complete (successful) protocol-runs? This is a protocol specific value based on the amount of bitsin the critical messages in relationship to all the bits transferred in a single protocol-run (without any interruption).

2. What Quality of Service (QoS) can be expected from the network transmission channel itself? The statistical expectation of critical network problems which could cause the off-line transaction protocol a premature dropout should be known.

1.4.11.2 Assumptions for the calculations

Assuming a uniform distribution of the Bit Error Rate (BER) of bits which cause a fail-stop for the transmitted messages the ratio between the numbers of "critical bits" against the number of all bits transmitted within a complete protocol-run has to be calculated. Note, the assumed value of this ratio will be worse than realistic because of the high probability of burst errors. To count the "critical bits", the size of all messages which can generate an unfair protocol termination if they aren't successfully received, are added up. The size of all messages is the amount of data from the first to the last bit of a complete transfer (294.288 kbit for the exemplary calculations). Of course, a few assumptions about the size of the keys, protocol objects, and eCoins have to be made. The following is assumed:

- ten (10) eCoins as main secret are transferred,

- five (5) eCoins for the change secret are transferred,

- three (3) CRL updates (of six) are transferred within the Response_l object,

- three (3) CRL updates (of six) are transferred within the Response_2 object, - 100 (one hundred) entries are contained in every transferred CRL,

- 10 kbit HTML5 code is contained in every transferred eRequest section of the eDoc,

- 10 kbit HTML5 code is contained in every transferred eReceipt section of the eDoc.

1.4.11.2.1 Message Sizes

The assumed values for object sizes as shown in Table 32 are taken into account for sub case [b] because of the less convenient case. Please note, the sizes assumed in Table 32 only serve exemplary purposes. The resulting size for the complete protocol-run is 294.3 kbit, while 202.1 kbit is the size of all critical messages together. The unit kbit denotes an equivalent of 1000 bits.

Table 32: Assumed object sizes and their critical or non-critical status with reference to fairness. Hence, the eCash system is facing a probability of approx. 69% (i.e. 202.1/294.3) a service failure hits a critical message. Therefore, it can expect that 69 of 100 broken transactions will terminate in an unfair state with the need of fairness recreation, which at a first glance isn't an impressive figure.

Focusing on the second question about the expected QoS (which in turn allows to conclude on the probability of a service failure), the current international standard ISO/EN/IEC 60870-5- 104:2007- 10- 01 and the ITU-T recommendation G.114 provide a definition of QoS priority levels (up to 7). In both standards, the QoS level is mainly depending on parameters like latency, jitter, BER, Packet Loss Rate (PLR), and the Service Availability (SA). For the performance of the transaction system, SA is the key factor that determines the QoS. It should be further taken into account that communication problems preferably appear as single events or massed as bursts. Their event may generate an effect on the physical network layer but not necessarily cause a problem for the application. There are several error detection and correction mechanisms within the protocol stack of the network (service) itself. The fact of their existence increases the latency and reduces the throughput of the payload. Therefore, as long as the service is available and the lock timeout windows are passed, this is a minor problem.

Today most Service Level Agreements (SLA) for business contracts between an ISP and a customer define a service availability of better than 99,999%. The SA forms the guideline of requirements of the upper transaction fail-rate boundary for IP-based radio data communication in packet radio service networks like GSM, UMTS, LTE, LTE-Advanced, Terra, WiMAX, WLAN or Bluetooth which are defined to be better than 95% per hour. This means, the SA rate is the decisive factor for the transaction protocol. Therefore, the "worst case" service failure probability can be assumed to be 100%-95%=5%.

By combining the two statistically independent probabilities one obtains a failure rate of 5%*69%=3.5% for the unfair case. This is the worst-case scenario to be expected. This means, thirty- five thousand (35.000) of one million transactions are expected to terminate in an unfair state with the subsequent need of fairness recreation. In most cases, however, the SA is much better, even in the local loop proximity model case: Failure rates under one hundred transactions terminating in an unfair state per one million transactions (0,01%) are expected.

1.4.11.2.2 Execution Times

For usability of eCash systems the average transaction time is a matter of interest, too. Exemplary transaction time calculations for several network usage cases are listed in following Table 33.

Table 33: Transaction protocol runtime calculations for different networks. The unit kbit/s is a data transfer rate equal to 1000 bits per second. Mbit/s denotes a data transfer rate equal to 1000 kbits per second.

The uplink speed of the General Packet Radio Service (GPRS) network is calculated by using the most robust Coding Scheme (CS-1), which is used when the Mobile Station (MS) is further away from a Base Transceiver Station (BTS). It can achieve a payload speed of 8.0 kbit/s per time slot, but provides 98% of normal coverage. Four timeslots are assumed, because almost all MS and BTS can provide such. Therefore, a (theoretical) payload throughput of 32 kbit/s can be considered.

Table 33 shows the estimated run-time for an eCash transfer by using the off-line transaction protocol calculated for some well-known networks. The network name specifies the public name of the standard. The column "Uplink speed" denotes the minimally guaranteed payload transfer throughput without packet protocol overhead (at its minimum 20% or more of the said transfer throughput for mobile network services) and not the Baud rate. In most cases the downlink speed is much higher. The Round Trip Time (RTT) is a network quality factor taken from official standards or published performance evaluations. The "Processing Time" is the maximum time for a CASTOR to perform the complete processing after the last bit of the message has been received including all cryptographic operations and the complete transmission of the response. The "Run Time" of a complete transaction (for the [a] case) is calculated in the following way:

Expected RunTime := Protocol Traffic Size / Uplink Speed + 10*(RTT/2+Processing Time) For a realistic interpretation of the values shown in Table 33, fast advancing technology especially in the fields of communications and electronics should be taken into account. Hence, it appears reasonable at present to assume the availability of high-speed network services will be a counting fact, and almost every smartphone will be well equipped with high-speed short haul P2P communication. Network speeds above 200 kbit s do not decrease the transaction times much more. Instead, the real asymptotic barriers are network latency (more or less half of the RTT) and the CASTOR'S processing speed (processing delay).

1.4.12 Overview on the Public Key Infrastructure

Figure 2 (and Figure 3) shows an exemplary overview over a Public Key Infrastructure and the trust relationship between the different entities in the eCash system for the exemplary off-line transaction protocol, as discussed above. Please note, this Public Key Infrastructure is based upon the ITU-T X.509 (version 3), "Information technology - Open systems interconnection - The Directory: Public- key and attribute certificate frameworks", 2008 available at http://www.itu.int, mentioned already earlier herein and is not limited to be used in an eCash system. Nevertheless, the following paragraphs will relate to the eCash system, but the explanations equally apply to multiple types of (transaction) systems should be still remembered.

If a user requests a new tamper-protected semiconductor module (or a device comprising same) the tamper-protected semiconductor module is provided with its firmware and its CASTOR root certificate issued by the Root Certification Authority (see Type- VI certificate). Nothing else has to be done to access (booting into) the eCash system. A directory containing "List of Files" files (signed by the RCA) plays an important role as it will become apparent from the following. The tamper-protected semiconductor module can capture this directory by following the information from the internal CASTOR product certificate (Type-V certificate, please refer to the "RootDirectoryPtr").

1.4.12.1 Authorities

The following authorities play an important role in the provided PKI. Their tasks and meanings are described below.

1.4.12.1.1 Escalation Authority (EA)

This institution is an additional authority not defined in the ITU-T X.509. The Escalation Authority (EA) takes over the control of the RCA in exceptional cases "to solve" a specific problem or request. An example for such exceptional case can be the certification of new RCA, CA, or eMint authorities, the revocation of trust of already certified RCA, CA, or eMint authorities, or technical help within a refund process based on the physical ability to recover defective CASTORs. Furthermore, the EA may also take the role of the RCA and may be responsible for the initialization of the CASTORs (providing them with their CASTOR root certificate (Type-VT) and CASTOR product certificate (Type-V)). Note, the EA is not directly visible within the system described herein, in particular for the CASTORs. In this document, the EA institution is explicitly mentioned in exceptional cases. Nevertheless, it should be clear, that the EA is capable of taking the role of the RCA in any arbitrary matter.

1.4.12.1.2 Root Certification Authority (RCA)

A tamper-protected semiconductor module needs to know where to find the Root Certificate Authority (RCA) within the eCash system. The "List of Files" directory contains a digitally signed "List of RCAs" file, with one or more entries indicating the approved RCA(s). Typically, the RCA list file only comprises one entry of one single RCA. In general - if there is more than a single entry, more than one RCA - the user may confirm the authority applying to him. The tamper-protected semiconductor module then extracts the reference information from the entry (off- and/or on-line) and stores the reference information enabling itself to contact this RCA in the future without the need to load the RCA list again (which is only the case in an update condition).

1.4.12.1.3 Certification Authorities (CAs)

For example, the tamper-protected semiconductor module may need to know which Certification Authorities (CAs) - sometimes also referred to as Trust Centers (TCs) - are available within the eCash system to find its appropriate counterpart. The "List of Files" directory points to a "List of CAs" file, which contains a digitally signed list of all approved TC/CA institutions available to tamper-protected semiconductor modules within the eCash system. The user may select his/her preferred or appropriate TC/CA. The tamper-protected semiconductor module then extracts the reference information from the TC/CA list (off- and/or on-line) and stores the reference information enabling itself to contact this TC/CA in the future without the need to load the CA list again. Furthermore, the users obtain their user certificate (Type-1/Π) from the selected TC/CA. 1.4.12.1.4 Issuing Authorities (eMints)

Furthermore, a tamper-protected semiconductor module may also need to know wherefrom to obtain the eCoins of the currency its user wants to store within (the device containing) the tamper-protected semiconductor module. There may be one (or more) issuing authorities (eMints) for every currency. Hence, for each requested currency the tamper-protected semiconductor module needs to know where to find the respective issuing authority (eMint). The "List of eMints" file contains a digitally signed list of all approved currencies and of all approved eMint-institutions worldwide available to the tamper-protected semiconductor modules. The user can select the desired currencies. Then the tamper- protected semiconductor module extracts the reference information for the selected issuing authority or authorities from the eMint list (off- and/or on-line) which contains the information on which eMint is minting the requested currency and stores this reference information.

An issuing authority may optionally also solely issue a variety of different currencies by offering different types of eCoins. In this case, the issuing authority may foster a currency list in a single "List of Currency Editions" file of all different currencies it supports. Moreover and also optionally, a tamper-protected semiconductor module may load the respective eCoin batch production-certificates (Type- VII) which reference all eCoin batch productions and therefore the associated eCoins. The required reference information is included in the currency list file provided by the issuing authority. Using this reference information the tamper-protected semiconductor module is able to load all required Type- VII certificates for the desired currencies (off- and or on-line).

The tamper-protected semiconductor module extracts the intended reference information to be taken from the currency list file, learns it permanently, and enables itself to handle these currencies from this moment in time. Such list file is supplied by every eMint.

1.4.12.2 Alternative PKI Architectures

The exemplary PKI architecture shown in Figure 2 is inter alia applicable in eCash systems to be deployed worldwide. However, the PKI infrastructure of Figure 2 may not be desirable or advantageous for any application of this invention. Accordingly, more simple or even more complex PKI infrastructures may be used instead. The PKI infrastructure shown in Figure 2 could be simplified by combining two or more authorities into a single authority. In the extreme case, the functions of the EA, RCA, CA, and issuing authorities (eMints) could all be offered by a single institution - organization, as exemplarily shown in Figure 3. It may also be possible to distribute functionality of one authority to two or more authorities, as it is for example also the case in Figure 2, where the EA can take over functions that would normally performed by the RCA according to the standard ITU-T X.509. 1.4.12.3 System Updates

The off-line transaction protocol may - according to another aspect of the invention - further support a "viral infection" mechanism to distribute system update information (like firmware or other data objects) among the tamper-protected semiconductor modules in the system. This means that system update information (like firmware and/or other data objects) may be exchanged in a viral manner between tamper-protected semiconductor modules whenever they perform a transaction with another tamper-protected semiconductor module.

In one exemplary embodiment, at least one of the transaction protocol messages exchanged between the tamper-protected semiconductor modules comprises system update information for updating system parameters, data objects and/or software/firmware of the tamper-protected semiconductor modules. The system update information, data objects and/or software/firmware could for example comprise at least one of:

a Certificate Revocation List of revoked tamper-protected semiconductor module's certificates, a Certificate Revocation List of revoked batch production certificates of electronic tokens, a Certificate Revocation List of revoked electronic tokens,

a Certificate Revocation List of revoked certificates of issuing authorities of the electronic tokens, a Certificate Revocation List of revoked user certificates,

a Certificate Revocation List of revoked Certification Authority certificates,

software/firmware updates for updating the software/firmware of the tamper-protected semiconductor modules, and

policy or rule updates to modify the policies of the tamper-protected semiconductor modules.

In one exemplary implementation, the system update information, data objects and/or software/firmware is comprised in transaction protocol messages of a Negotiation Phase or an Electronic Token Transfer Phase of the off-line transaction protocol.

To update system information, a tamper-protected semiconductor module may contact the "List of Files" directory to learn which updates are available within the eCash system. A system update in a "List of System Updates" file provided by the RCA contains a digitally signed list of all approved update objects available for tamper-protected semiconductor modules. The user may make a selection of the updates he/she wants to obtain, respectively. Some of the updates, for example security or system relevant updates, may be mandatory. The tamper-protected semiconductor module then extracts their respective reference information from that system update list, loads the complementary files, and installs them permanently into its non- violate memory. It should be noted; the systematic viral update distribution which may be implemented in the off-line transaction protocol is an additional supplemental update mechanism to the ordinary "download" mechanism initiated by the user itself.

1.4.12.4 Verification Chains To verify the public key infrastructure's objects (e.g. certificates, CRL, or other digitally signed objects) the chain of trust needs to be verified up to the CASTOR root certificate provided by the RCA. A correct CASTOR root certificate should be present in the tamper-protected semiconductor module. Otherwise the tamper-protected semiconductor module may not be operable. In one embodiment of the invention, the CASTOR root certificate may be hardcoded into the tamper- protected semiconductor module's internal circuitry. To prevent any tampering or manipulation, the trust for this certificate is implicit. As will be outlined below, various techniques may be employed to protect the tamper-protected semiconductor module against attacks.

The general procedure to verify a certificate, a CRL, or any other digitally signed object works as follows:

- Search for the complete chain of certificates down to the CASTOR root certificate.

- Ensure all certificates aren't expired or aren't revoked.

Verify all digital signatures are valid.

1.4.13 Design of the Tamper-Resistant Semiconductor Module (CASTOR)

As already indicated above, different aspects of the invention relate to improving the tamper resistance of semiconductor modules respectively the hardware module (e.g. die/multi-die/chip packaged therein). A semiconductor module may be for example a die/multi-die bonded onto a circuit carrier and packaged into a housing. In general, tamper resistance can be best achieved by building a programmable full custom ASIC. Such ASIC may be for example realized as a System-on-Chip (SoC) with integrated processing capabilities and a non-volatile memory to store electronic secrets, tokens, keys, passwords, and digital certificates.

A tamper-protected semiconductor module may make use of a variety of known and/or new techniques to become tamper-resistant and making reverse-engineering as well as micro probing a challenging and difficult task. The property of tamper-resistance may not be treated as an absolute security measure as it is known, every tamper-resistant semiconductor module using today's known techniques for making it tamper-resistant can be completely reverse engineered (see S. Skorobogatov, "Hardware security: trends and pitfalls of the past decade", University of Cambridge, 2009). An attack can be considered successful if all protected information (root-secret) as electronic tokens, encryption keys, and software code is revealed. However, the design of the transaction system with its PKI infrastructure, the design of the off-line transaction protocol discussed above, and further hardware- based and software-based techniques to "harden" against attacks may - in combination - prevent an attacker from gaining the equivalent or more of the invested money used to break the semiconductor module. This is very likely to deter the attacker from attempts to attack the system

Although model and design of the CASTOR discussed below in further detail combines a variety of techniques to prevent tampering, it is to be noted that not all techniques may need to be used simultaneously in order to provide a tamper-resistant semiconductor module. Every technique may increase the tamper-resistance and sometimes may interact with another technique to improve tamper resistance of the semiconductor module. Further, especially the novel techniques to improve tamper resistance discussed herein represent individual aspects of the invention, but also new uses of known techniques, such as a PUF, are proposed in some aspects of the invention.

Moreover, the techniques to improve tamper resistance of the semiconductor module (CASTOR) are not limited to semiconductor modules for use in a transaction system, but may readily be used in order to improve the tamper resistance of a semiconductor module intended for any application, e.g. in computers, cars, smart-phones, smartcards, gaming consoles, PoS terminals, etc. just to name a few. 1.4.13.1 Model of a CASTOR Chip

Figure 17 shows an exemplary block diagram of a CASTOR chip according to one exemplary embodiment of the invention. The IC/die is referred to as the CASTOR chip while the packaged CASTOR chip is referred to as the CASTOR. However, in most cases this distinction inspired by the production process is not important for the overall understanding. For sake of simplicity it is more often referred as CASTOR or a (tamper-protected) semiconductor module in most sections herein.

Exemplarily, the CASTOR chip comprises a main processor (CPU), e.g. an ARM processor with an integrated interrupt controller (INT), a Memory Managing Unit (MMU), a Direct Memory Access (DMA) unit, and a L1 L2 cache. The chip may for example include a separate hardware interrupt service unit (INT ISR). Additionally, a timer-unit and/or Clock Phase Lock Loop (Clock PLL), which may be used to implement timers for detecting timeouts (e.g. fail-stop timeouts, lock timeouts, etc.), and to provide a WatchDOG timer (WDOG) in combination with a reset logic may be provided. The CASTOR may further include power management circuitry (e.g. a sleep mode & wake-up logic, voltage & power regulator sensors, filters, etc.). The CASTOR also includes a volatile and nonvolatile Random Access Memory (RAM), e.g. an SRAM, DRAM, EEPROM, FLASH, MRAM, PCRAM, PRAM or the like. Optionally, the CASTOR may also be provided with circuitry to generate and maintain (en-/decrypting, signing and checking by recalculation) crypto objects (e.g. keys, unique objects and other security relevant objects) - see "Crypto Primitives" unit. Further, the CASTOR may also include a Scatter/Gather DMA speedup engine to improve the DMA performance.

The CASTOR may further comprise an I/O-unit which allows to exchange information (commands/messages and data) with its environment. For example, the CASTOR may be provided in a device and could use the device's memory or BUS functionality to communicate with another CASTOR or another device/server/authority (e.g. the issuing authority (eMint), RCA, etc.) through the I/O-interface. Alternatively, the CASTOR may also use tethering mechanisms for communication.

The circuitry providing the crypto-objects in combination with the crypto-coprocessor (see below) and the scatter/gather DMA can form an efficient bulk cryptographic offload engine, able to collect packets and their fragments from multiple locations in system memory, and write back the data upon completion of the cryptographic operation. This can eliminate demand for the main processor to require direct control on the cipher- and DMA-operations.

In addition to these elements of the CASTOR, the CASTOR may further comprise a crypto- coprocessor (Soft Core Maze of Knossos Processor implemented as FPGA) which assists the main processor taking over cryptographic operations like primitive en-/deciphering, signing, verifying certificates and signatures, etc. Moreover, a PUF unit is providing a hardware functionality, which may be used to verify the CASTOR chip's integrity. The off-line transfer protocol unit is a dedicated circuitry performing the off-line transaction protocol, handling interruptions due to transmission errors and other tasks related to the transaction processing like the execution of an on-line fairness reconstruction process, obtaining system update information from a trusted party, etc.

The optional key generation unit (PK/TD Generator & License Info) is a circuitry to generate keys, e.g. the session keys for a transaction, keys for the umbrella encryption, the CASTOR'S public key-pair (SUDI and PUDI, the latter is contained in the CASTOR root certificate), and numerous other keys required for the execution of transactions and management functions in the system. Further, this unit may also store the various generated keys. The key generation unit (PK/ID Generator & License Info) is an optional unit of the CASTOR, as for example its functions could be also performed by the main processor (optionally in combination with the crypto-coprocessor and the crypto-primitives unit).

Moreover, the CASTOR may comprise a bootstrapping unit (Init, Build-In-System-Test (BIST), TRUSTLET startup) dedicated to boot the CASTOR upon power-on or reset. The bootstrapping unit may for example perform a BIST and may control the loading of the firmware, e.g. using secure firmware modules (TRUSTLETs) as discussed herein.

The Process-Service-Security-Balanced-Interface (PSSBI) filter controller, which is another optional component of the CASTOR, is responsible to control/filter the I/O-traffic of commands and data according to the defined communication protocol with the external host device.

Furthermore, the CASTOR chip may also be provided with a cocoon PUF, when packaging same.

Please note, not all components of the CASTOR shown in Figure 17 are needed to provide a semiconductor module. Some functionality provided by dedicated circuitry (e.g. the off-line transfer protocol unit, the key generator unit, the crypto-coprocessor, the crypto-primitives unit, etc.) may also be performed by the main processor however, with less performance as if using dedicated circuits, optimized to the respective function or task.

1.4.13.2 Concept of the CASTOR Design Philosophy

The exemplary CASTOR shown in Figure 17 is constructed to provide an effective protection system, able to generate a kind of hard-to-clone chips in spite of mass production. To improve the tamper resistance of the CASTOR chip, the CASTOR chip may

- contain a standard hardware (silicon, optical, magnetic, acoustic, coating, butterfly, or intrinsic) hardware PUF,

- contain a cocoon PUF,

- be balanced by the Soft Core Maze of Knossos Processor,

- contain a security monitor to enable the detection of potential attacks,

- generate its own identifying descriptor item (e.g. serial number) crypto identity,

- generate its own public key-pair (PUDI, SUDI) to be used for digital signing purposes,

- generate an I O-key (K _E :CASTOR:i _/ o.s m) for the umbrella-encryption, and/or

- be validated by certifying the identifying descriptor item (e.g. serial number) by the RCA.

Using SoC processes to design and implement the CASTOR chip may be one technological means to create very secure systems. One reason is the achievable grade of integration: The smaller the chip structures the harder their reverse engineering becomes. Attackers routinely are using second-hand semiconductor manufacturing and testing equipment only countered by the use of the latest highest- density technologies. The application of unique-per-chip embedded secret storage in non-volatile memory in combination with a cocoon PUF and/or hardware PUF is among the best of these techniques. Such combination is an advantage with respect to cost and effort for a physical attack because it raises the hurdle an attacker has to leapfrog with technical expertise, and financial resources sufficient to mount an attack.

Detected attacks against the CASTOR may be responded by temporarily or permanently making the CASTOR unusable. This could be e.g. achieved by an instant erasure or - even better - by falsification of the CASTOR'S root certificate or other essential CASTOR-internal objects, which are key elements for the CASTOR to be operable in the transaction system. In addition thereto, essential functional circuitry and stored information may be partially and/or functionally self-destroying in a manner that leaves the CASTOR in a state where it still seems to work, however in an erratic and wrong way. The destruction process can be realized by driving high currents through internal circuit's logic conducts. A silent self-destruction may be even more advantageous than indicating the perception of the attack as feedback to the attacker. 1.4.13.3 Expected Attacks on the CASTOR and their Countermeasures

This section discusses several possible attacks and a selection of countermeasures that may be implemented in the CASTOR or CASTOR chip.

1.4.13.3.1 Simple Power Analysis (SPA) and Differential Power Analysis (DP A)

With respect to SPA and DP A, one effective countermeasure may be the use of internal randomized power protection (adding random noise via injection to internal power supply of the SoC) and jittering clock signals in combination with (only partially) asynchronous self-timed dual-rail logic with alarm functionality by the CASTOR chip. It counters SPA and DPA by blurring and de-correlating statistical predictions. Each bit will be signaled on two wires: (0,1) states "zero", (1,0) signals "one" while everything else raises an alarm. There is a high probability a single transistor failure might also result in alarm propagation. The power supply may be internally filtered for fluctuation integration, realized through an 'on-chip' capacitor, which partially buffers the energy consumption and reduces signal sizes. The additional usage of an idiot (idle) task (e.g. prime number generation) can be helpful, too.

1.4.13.3.2 Date and Time Manipulation

Another possible attack on the CASTOR may be based upon date and time manipulation. The usage of certificates and CRLs, the determination of the electronic token transferability, and the prevention of all kinds of replay-attacks make the transaction system potentially prone to date and time manipulation since all these objects rely on the system time, devaluating their meaning over time. One countermeasure may be the provision of a trusted time-source on the CASTOR chip.

1.4.13.3.3 Glitches and other Fault Injections

Further, the use of a self-clocking gate-design (which can prevent and limit the delay and skew of the clock by an internal Phase-Locked-Loop (PLL), robust low-frequency sensors, a RESET filter, and overAunder voltage protection are effective measures to counter glitch attacks introduced through clock frequency manipulation.

Low-frequency sensors will trigger if no clock edge has been seen for a period longer than a specified time-limit. In this case, it may be advantageous if parts of the CASTOR chip's internal logic are resetted immediately, and if bus lines as well as registers are erased/grounded quickly. An intrinsic self-test built into the detector prevents a simple disabling. An attempt to tamper with the sensor should lead to a malfunction of the entire CASTOR chip. Furthermore, external resets may not directly be forwarded to the internal reset lines; it may be better to cause the reduction of the clock signal by an additional frequency-divider which then triggers the sensor and leads to an internal reset of the CASTOR chip, which finally deactivates the divider.

Glitches, Electro-Static-Discharge (ESD) measures, and other fault-based attacks are frequently injected with radiation (e.g. LASER UV light). Passive and active CASTOR shielding in combination with light detectors and radiation-sensors will enable the design of a resistant chip. Situating the logic design inboard between metal layers makes this type of attacks more improbable. Furthermore, an additional option is the use of a cocoon PUF.

1.4.13.3.4 Optical Scanning

On-chip busses and memory structures on the SoC are easily optically identifiable. To prevent against an easy useful sniffing attack which gathers information directly from the SoC-internal busses or cell memories, busses and cell memories may be protected by encryption and/or dynamic address permutation. This may be a countermeasure which can prevent attacks on CASTOR chip internal data structures and transfers by ECC, EDC and CRC protection mechanisms, or a sealing with signed values.

1.4.13.3.5 Electro-Magnetic-Analysis (EMA) and EMission SECurity (EMSEC)

One common attack against a chip is to sense Electro-Magnetic-Interference (EMI) emitted from the chip as "black-box reconstruction-approach". The CASTOR chip or CASTOR may therefore be designed in a way that reduces electromagnetic emanation by shielding (e.g. through a TEMPEST design) and/or obscured by faking the radiation. The protection provided by a shielding could be further enhanced by "salting" the SoC with additional oscillators. In one embodiment, the shielding is provided by a cocoon upon packaging, the cocoon providing a cocoon PUF.

1.4.13.3.6 Laser Cutting

A further security measure may be the bonding of the CASTOR chip to the circuit carrier and its encapsulation into a non-standard BGA package with custom markings. This allows to prevent direct access to the external chip interconnections. Additional metal passivation sandwich-layers on the CASTOR chip may be a good measure to avoid critical structures being exposed to the attacker without removing active layers first.

In one exemplary implementation of the CASTOR chip, each layer is planarized using a Chemical- Mechanical-Planarization (CMP) process before applying the next layer. As a result, the top metal layer does not show the impact of the layers beneath. The only way to reveal their structure is to remove (the) top metal layer(s).

A further security measure may be to render the chip's/die's layout design virtually random, for example by conducting a simulated annealing. Distracting components over multiple layers and locations in combination with the usage of own fixed (macro) structures not found in a public ASIC library will make the process of logical reverse engineering and reconstruction much more time consuming.

Moreover, the usage of meshed glue logic could further be used to make it hard to find signals for physical probing. Modular redundancy of critical design parts makes it even harder for the attacker to launch successful modifications through wire cutting and micro wiring (patches). 1.4.13.4 Further Design Optimizations for improving Tamper Resistance

In order to provide a safe storage (e.g. for secrets/configuration data), distributed One Time Programmable (OTP) memory in combination with embedded non-volatile (e.g. flash, EEPROM, MRAM, PCRAM, PRAM etc.) memories could be used on the CASTOR chip/die. They are physically integrated on the same die all over the chip structure even lying in-between different layers.

The structurally destruction (e.g. burning) of integrated debugging ports, unused access- and test circuitry (including interfaces) like JTAG scan chains or BIST logic before the product release is another measure which may improves tamper resistance of the resulting CASTOR. The destruction of such structures on the CASTOR chip/die prevents read-back or direct-write to internal memory cells through external interfaces. The destruction of these structures may be for example realized by burning them, e.g. by creating high currents from external I/Os that will destroy the circuit structures.

Another optimization is to make memory states dependent on a number of bits of physical storage, by distributing their logical meaning over multiple different memory cells, so no single-transistor failure can subvert the chip's security policy. It can be useful to seal the data using CRC, ECC and EDC codes. As a result of data-remanence for memory artifacts in some technologies (even by cooling down the die), all relevant secrets and data stored on the chip may be continuously moved and inverted. Moreover, a low temperature sensor could be provided on the chip for auto-powering down the CASTOR chip in case temperatures below -40° Celsius (or similar low temperatures commonly not encountered in nature or within the operating limits) are detected.

Further, it is possible to scan and snatch memory cell contents of all storage technologies, including ROM, RAM, EEPROM, FLASH, MRAM, PCRAM, PRAM or the like by using Focused-Ion-Beams (FIBs), Laser-Cutters (LCs), Electron-Beam-Testers (EBTs), Electron-Microscopes (EMs), Atomic- Force-Microscopes (AFMs), Scanning-Probe-Microscopes (SPMs), Scanning Capacitance Microscopes (SCMs), Scanning Spreading Resistance Microscopes (SSRMs), Scanning Tunneling Microscopes (STMs), Magnetic Force Microscopes (MFMs), Scanning Surface Potential Microscopes (SSPMs), Scanning Thermal Microscopes (SThMs), Scanning Electron Microscopes (SEMs), and other tools.

To make such attacks as expensive as possible, one countermeasure may be the usage of the smallest available SoC structures for the CASTOR chip. Furthermore, the use of on-chip-encryption and the realization of memory cells deep between the core layers make their direct read-out a challenging task for the hacker. These countermeasures may be further supported by precautionary flanking them with extra metal refractory passivation sandwich on-die layers. Each of these layers may be planarized using CMP before applying the next layer. Opaque top-metal grids and shields as generic protective measure may further be used on the chip to raise the bar for an attacker in terms of time and equipment cost Another optional security measure is the usage of a die wrapping cocoon. The naked CASTOR chip/die may be protected by a thin high-resistance wire-based intrusion sensor to harden the chip decapsulation process countering any further external probing. Such wrapping cocoon encloses the chip/die to be protected, while a very low current (in the nano Ampere range) is used to check the wrapping cocoon's physical integrity, if the protection wire remained untouched (opens and shorts). If the sensor line is broken, shortened to ground, or electrical voltage or its resistance changes significantly, the chip/die may detect an attack and may take the foreseen procedures like a temporary disablement of the chip/die or even a self-destruction of the chip/die. The wire of the wrapping cocoon may be folded back over itself and wound as multiple parallel strands to increase the sensitivity of the wrapping cocoon. A mixture of copper and silicon (potting material as similar as possible in both appearance and chemistry to the bond wire and the die) powder with ceramic cement may be used to cement the wrapping cocoon in the package.

To prevent against attacker using IR LASER techniques, one possible countermeasure may be to replace bulk silicon with material not transparent at useful LASER frequencies (e.g. Silicon Metal Oxide (SiMOX), Silicon-on-Sapphire (SoS) or other Si-on-Insulator (Sol) technologies).

1.4.14 Trusted Boot through TRUSTLETs

As already indicated above, one further aspect of the invention is the provisioning of a secure bootstrapping procedure "for starting" a chip or device, also referred to as trusted startup. This bootstrapping is using secured software modules (comprising executable code and optionally data; also referred to as entity blocks below) provided by the firmware. The provision of a trustable bootstrapping process may be of particular importance for chips (or devices containing same) that should be updatable. The trusted boot process discussed in this section has a capability to device the chip's firmware into multiple small functional parts, each of them carrying out a specialized function. These secure self-contained fragments/software modules are called TRUSTLETs. It is apparent that a trusted boot by the use of TRUSTLETs can thus improve tamper resistance of the semiconductor module (CASTOR).

The basic idea of the proposed secure bootstrapping process is simple: It identifies a systemic way of distinction in order to differentiate between a secure interior (a tamper-protected hardware module) and an unsafe exterior (the rest of the world). To achieve this, the bootstrapping model covers two different main organizational strategies:

1. The serial chain strategy, where one TRUSTLET passes the control to the next TRUSTLET, where every TRUSTLET is started to be executed only once every time, and

2. the central chain strategy, where one (distinguished) TRUSTLET (which may be the first TRUSTLET started in the bootstrapping process) coordinates the execution of other TRUSTLETs. The other TRUSTLETs are started to be executed only once every time and return the control back to the (distinguished) TRUSTLET after their execution.

It is also possible to have hybrid variations of both of these organizational principles. The expression "started to be executed only once a time" intends to clarify that the exemplary TRUSTLET gets only one single start. It does not mean that (parts of) the code of the respective TRUSTLETs are not resident servicing the tamper-protected hardware module during the work-phase.

The utilization of a trusted bootstrapping process using TRUSTLETs is not limited to its use for chips to be employed as part of devices in a transaction system. The trusted bootstrapping by means of TRUSTLETs may readily be used in chips, semiconductor modules, and devices intended for any application, e.g. in smart-phones, computers, smartcards, gaming consoles, just to name a few.

The trusted boot joins into the various security concepts presented herein that can be used to make a chip or a semiconductor module in which it is packaged more tamper resistant. Furthermore, since one possible scenario where the trusted boot can be employed are chips or semiconductor modules for use in a transaction system as presented herein, and may form part of the overall security architecture therein, it will be also referred to the integration of the trusted bootstrapping in the context of a transaction system. More specifically, the trusted boot by means of TRUSTLETs can be a part of a layered security strategy, which allows the establishment of trust between the CASTORs and the eCash system (e.g. represented by services from RCA/CAs/eMints).

As will be outlined below in further detail, TRUSTLETs are compressed and encrypted entity blocks which allow checks of their integrity and of the authentic creation source. If a chip can be booted into an environment which honors security and compliant functions to access restricted data, the data integrity within the chip can be assured. If trusted bootstrapping cannot be assured, the chip or device comprising same is prone to boot it into an unsecure operating system, whatever security management system the secure kernel provides. Trusted bootstrapping ensures boot integrity protection because: - It can protect the chip against off-line attack vectors by an authentication process,

- It locks the chip, because if any entity block is tampered with, the system will not boot

- It ensures that only an un-tampered chip is operational.

TRUSTLETs also facilitate secure firmware updates (even Over-the-Air). Further, TRUSTLETs are countering the following integrity attacks:

- bootstrapping manipulation,

- code manipulations of the operating system,

- unauthorized generic code and data changes,

- use of own (unauthenticated) code. 1.4.14.1 TRUSTLET Generation Process

Figure 18 shows an exemplary process for the generation of TRUSTLETs by the RCA according to an exemplary embodiment of the invention. The software pieces (entity blocks) of the firmware may be for example generated using the standard tool-chain of compiling and linking. An entity block is a piece of executable code (e.g. comprised in a code section of the entity block) and optional data (e.g. comprised in a data section of the code block). In one exemplary embodiment of the invention, the entity block is the resulting data of the linking process performed by a linker, but the entity blocks are not limited thereto. The data that may be optionally comprised in the entity block are for example data static data (e.g. constant variables for the runtime system), and/or data for initialization of parameters/variables (e.g. predetermined variables of the runtime system), etc.

In a first step, an entity block to be "transformed" into a TRUSTLET will be hashed using a hash function (e.g. SHA1). The entity block may be optionally compressed - it should be apparent that the hash-fingerprint is determined from the uncompressed entity block.

The hash-fingerprint of the entity block is then signed by encrypting it with a RCA's private key for encryption (K _E: F _W:TI -XXX. _PIV ) to generate a digital signature thereof. For example, an Elliptic-Curve- Digital-Signature-Algorithm (ECDSA) could be used for encryption, but also other asymmetric encryption algorithms may be used. This digital signature is then combined with the (compressed) entity block.

Hereafter, this linked package (containing the (compressed) entity block and the digital signature) is again encrypted with a random key, e.g. a symmetric key. For this, AES (e.g. with a 256 bit key) could be used in the XTS encryption-block cipher-mode. However, other symmetric encryption schemes and/or cipher-modes could be used, too. The random key is then encrypted with a RCA's private key for encryption (K _E: FW:T ₂ -xxx.prv)- Please note, the RCA may use the same or different private keys for encrypting the hash-fingerprint (signing) and encrypting the random key (encryption). The encryption of the random key may use for example ECC (e.g. with a 571 bit key) or another asymmetric encryption scheme.

The private key or keys used by the RCA to encrypt the hash-fingerprint (signing) and the random key (encryption) is/are owned by the RCA, while its/their public key counterpart(s) is/are contained in the CASTOR product (firmware) certificate (Type-V). In the final building step, the concealed entity block is combined with the encrypted random key to form the TRUSTLET.

Optionally, the RCA may include to each TRUSTLET (or only one for all TRUSTLETs constituting the firmware), the CASTOR product certificate (Type-V) which contains the public key(s) required for the decryption and validation of the TRUSTLET at the respective chip (or device) executing the TRUSTLET. Alternatively, the CASTOR product certificate (Type-V) may also be made available to the chips (respectively, devices) by some other means. 1.4.14.2 Use ofTRUSTLETs in the Trusted Bootstrapping Process

Before being executed or read, each TRUSTLET is validated using the process described below with respect to Figure 19. Figure 19 shows an exemplary embodiment of a validation process for a TRUSTLET which has been produced according to the procedure described above with respect to Figure 18. As discussed above, the TRUSTLET comprises two main parts: The encrypted random key and the concealed entity block. To validate the TRUSTLET, the bootstrapping chip/device is first using the counterpart public key (K _D:FW:T2 .xxx.pub) to the RCA's private key for encryption (K _E:FW: T2- xx prv) to decrypt the random key (symmetric key) which has been used previously to encrypt the (compressed) entity block and its digital signature. If successful, the random key is subsequently used to decrypt the concealed entity block comprising the (compressed) entity block and its digital signature. Next, the bootstrapping chip/device is verifying the digital signature of the (compressed) entity block. For this purpose, the entity block is decompressed (if it is included in compressed format to the TRUSTLET) and a hash-fingerprint is calculated from the (decompressed) entity block using the same hash function as used by the RCA when creating the entity block's fingerprint. Further, the digital signature is decoded using the counterpart public key (K _D :FW:Ti-xxx. _P ub) to the RCA's private key for encryption (K _E;F w:Ti-xxx.prv) to obtain a reconstructed fingerprint of the entity block. The reconstructed fingerprint and the freshly generated fingerprint are compared and if they match, the entity block has been successfully validated and is allowed being executed by the chip.

It should be apparent that any attempt to modify the contents of the TRUSTLET would falsify the validation process and interrupt the bootstrapping process.

It is worth noting that the functionality to validate the first TRUSTLET to be executed in the trusted bootstrapping process is hardcoded in the chip.

Moreover it should be noted that the counterpart public key (K _D; FW:T2-xxx.pub) an the counterpart public key (K _D: FW:Ti-xxx.pub) may be identical, although it may be more advantageous to use distinct keys for signing and encryption by the RCA. The counterpart public key(s) used in the validation process may be for example provided to the chip for example by means of a certificate, such as for example the CASTOR product (firmware) certificate (Type-V) previously herein. This certificate may be for example appended to the TRUSTLETs (or may be part thereof) or may be provided to the chip by some other means, e.g. by downloading it on-line from the RCA.

Execution of a TRUSTLET starts through a previous TRUSTLET in the (logical) chain or, if the TRUSTLET is the first TRUSTLET to be executed, with functionality hardcoded in the chip itself as already stated above. Execution means the following herein:

- a measurement of the current code/data state: checking the authenticity,

- case yes: CASTOR passes the execution control to the measured, decrypted and decompressed TRUSTLET, - case no: CASTOR performs a RESET. In such case the CASTOR starts over with the same procedure as performed by a power-on-event. Alternatively to that method the following techniques may be employed: Entering into an error mode (and the indication of same to the user) or performing a (deep) sleep or power-downing the CASTOR.

This execution is performed with every TRUSTLET within the chain. Please note, there are many possible different logical chain configurations. Three possibilities are depicted in Figure 31, Figure 32, and Figure 33. The chain position of every TRUSTLET is hardcoded during the compilation/- generation phase of the chip's firmware, so every TRUSTLET knows it's succeeding TRUSTLET. During its boot phase, the CASTOR cycles through the chain of all of its firmware's TRUSTLETs. The chain of trust is kept alive as long as each TRUSTLET ensures any subsequent TRUSTLET is "executed in the way as explained above".

This structured execution assures neither off-line system tampering nor an attempt to boot an unauthorized firmware can happen. A trusted startup employing TRUSTLETs protects the system boot process by ensuring tamper-freeness before releasing the system control to the embedded operating system and granting system access to the protected application. Trusted startup enabled system secrets could be for example protected by using the chip to encrypt root-secrets, rather than protecting through obfuscation or by shared passwords.

The trusted startup protected chip is resilient against advanced methods of off-line code and data modification on the secured storage. Assuming that the chip is tamper-protected (using one of te various measures described herein), i.e. provides the hardware protection for the startup integrity, decryption keys, and the sealed storage, every attempt to change a boot sequence component makes the firmware inaccessible, the system unbootable, and the application data unattainable (as being protected by the application of an umbrella encryption).

The functionality for the provisioning of the umbrella encryption may be implemented e.g. as a TRUSTLET, too. Therefore, not only a chip-internal storage may be encrypted, but also data stored outside the chip can be encrypted by means of the umbrella protection, as described for the CASTOR chip herein. Because memory content and external stored data objects may be encrypted in real time while being transferred to the external mass storage device through secured-I/O, data objects like eCoins, certificates, CRLs, and any (open) document or (cached) secrets (and e.g. even swap files) are also encrypted under this umbrella protection. Therefore, the mass storage data can be encrypted completely and is therefore not exploitable. Off-line attacks cannot compromise or reveal system passwords, keys, or any other data. In addition, replay or image duplication attacks (launched by the attacker by copying the content of the external memory with the encrypted eCoins and intends their reuse) are thwarted by synchronization checks to the last safe sealed transaction state using the chip- internal memories. By comparing certain boot process characteristics to previously stored measurements (e.g. signed cryptographic hashes), a trusted startup through TRUSTLETs can detect system tampering while starting up. This enables the trusted startup to verify system integrity at an early stage, improves data security, and reduces equipment-re-purposing concerns. The feature is simple to deploy and operate, and it enables an easy system management.

Although it may be advantageous to interrupt the trusted bootstrapping (leaving the chip without a usable embedded operating system) in case a TRUSTLET cannot be validated successfully, this interruption may not always be feasible or desirable depending on the target application. TRUSTLETs may contain only individual functions of the firmware, security relevant ones as well as security irrelevant ones. Therefore, in another embodiment of the invention the chip may also be able to continue bootstrapping with the subsequent TRUSTLET in chain, even if one or more TRUSTLETs cannot be validated, thereby possibly being able to boot at least a partially operable system. Thus, the functionality of the non-executed TRUSTLET(s) (due to a validation error) won't be available to the system.

Furthermore, another option may be that an entity block of a TRUSTLET comprises multiple code sections with executable code and optionally further data sections. In case the TRUSTLET cannot be validated successfully, a specifically dedicated code of one code section could be executed, while in case the TRUSTLET is validated successfully, another code of another code section is executed. The code of the respective code sections (and the corresponding data in the data sections) may be adapted to the specific needs and application of the chip or system in which the trusted startup is used. For example, the code of the code sections executed in cases where the TRUSTLET cannot be validated successfully could ensure the bootstrapping of the chip with a minimal operating system of the chip which is for example not allowing any transactions requiring a secure environment. The code of the code sections executed in cases where the TRUSTLET is validated successfully could be for example ensure the bootstrapping of the chip with the full-functional operating system of the chip allowing to perform also transactions requiring a secure environment.

A further option to react to a validation error of a TRUSTLET may be that the chip (e.g. its boot manager) continues booting the system and - without allowing any security relevant operations - notifies the RCA, if it encountered a non-validated TRUSTLET on the chip/device. This notice to the RCA may for example include an identifying descriptor item (e.g. serial number) of the chip, which would allow the RCA to lock the device by (black-) listing its identifying descriptor item (e.g. serial number) in a respective RCL, assuming the chip's identifying descriptor item is rovided in form of a certificate. Upon having notified the RCA, the chip may then disable itself or the entire device.

Optionally, instead of a sequential bootstrapping process where one TRUSTLET validates and starts the next TRUSTLET to be executed, the bootstrapping process may be changed as follows: The first TRUSTLET to be executed may provide a boot-manager's functionality (please refer to Figure 32) which controls the execution of the subsequent bootstrapping process. Please note, the boot manager may be part of the hardware or may be implemented as part of the hardware functionality. The boot manager may thus control the execution of (further) TRUSTLETs. For this purpose the boot manager provides the necessary functions to validate TRUSTLETs as described above with respect to Figure 19, and some decision logic to decide how to proceed (in) the bootstrapping process (or how to interrupt same) in case a validity check fails for a TRUSTLET. Further, the boot manager may of course be further aware in which order the TRUSTLETs should be executed.

1.4.14.3 Trusted Bootstrapping of a Chip/Device for use in the Transaction System

Figure 20 shows exemplified a bootstrapping process according to an exemplary embodiment of the invention, which specifically relates to the use of the trusted bootstrapping for a device (respectively, the CASTOR chip) used within a transaction system as described herein:

1. After power-on, the CASTOR hardware (i.e. the chip to be bootstrapped) is initialized, which may for example include a basic BIST internal hardware functionality test. This initial BIST may be later on augmented with a more comprehensive test. Thereafter, a first TRUSTLET (being the API filter in this example) is executed as exemplified above. All these actions are performed by the hardware; no software is involved at this stage.

2. Given the first TRUSTLET (in this specific case the API filter) is successfully executed; the subsequent TRUSTLET will be executed next. Each TRUSTLET may comprise code (see Figure 31 and Figure 33) to perform the execution process described with respect to Figure 19 for the next TRUSTLET or only a "managing TRUSTLET" may comprise that code (see Figure 32). Accordingly, at the "end" of the execution of the first TRUSTLET, this first TRUSTLET will execute the next TRUSTLET only in case the next TRUSTLET can be successfully validated. This procedure is continued until the last firmware's TRUSTLET is executed. As each TRUSTLET checks the validity of the next TRUSTLET prior to its execution, a chain of trust is generated, and it is not possible to sneak unauthorized code into the bootstrapping process (of course presuming that the PKI infrastructure is not broken, which is extremely unlikely if not impossible). In case a TRUSTLET is not validated successfully the bootstrapping process may be interrupted. In case the API filter executes successfully, in turn, the License Check TRUSTLET is next.

3. The License Check TRUSTLET is responsible for performing a more comprehensive system test, e.g. by checking the chip's (or the semiconductor module's) integrity using one or more of the further security means to detect tampering of the chip or the semiconductor comprising same, such as e.g. checking the integrity by using the built in hardware PUF, the cocoon PUF and/or a configuration check of the crypto-coprocessor, etc., respectively. Furthermore, the License Check TRUSTLET authenticates the chip's license information as provided in the respective section (e.g. Cert.Unit.Info.CLC) of the CASTORs Type-VI RCA root certificate. One possible (but not exclusive) way to achieve this is cross-referencing the information provided by the RCA root certificate with other - later on delivered - on-line or off-line available information provided by the RCA to the CASTOR (e.g. if licensee do not pay its license fees or is not a certified customer of the system anymore). In case the License Check executes successfully, in turn, the IPL (Initial Program Loader) Boot TRUSTLET is executed next.

4. The IPL Boot TRUSTLET is the bootstrap service loader for the (embedded) operating system. It performs the extended Power-On-System-Test (POST) and manages the update process of the chip's firmware. In case the IPL Boot executes successfully, in turn, the (embedded) operating system TRUSTLET is next.

5. The (embedded) operating system TRUSTLET is the operating micro kernel responsible for the on-CASTOR management. After its initialization this software is responsible to load the application. In case the (embedded) operating system executes successfully, in turn, the application TRUSTLET is next.

6. The last TRUSTLET in the chain will be the application. In one embodiment of the invention this is the eCash transaction system application.

It should be noticed, any executable code not validated (e.g. non-validated TRUSTLETs or standard code) is impossible to be executed in such environment (excluding the above mentioned "relaxed" security handling possibilities). A chain of trust can only be assured by the exclusive use of TRUSTLETs. If ever the execution chain "forks" to an invalid TRUSTLET the chain of trust ends with the last validated TRUSTLET. Henceforward, control of the CASTOR within a guaranteed secure environment is not possible. As already mentioned earlier in this section this can make sense due to the nature of the (intended) application e.g. with no or only negligible needs for security.

The "logical chain of trust" which provides trusted boot capability implemented by the TRUSTLET system can be technically encompassed in various architectural ways. Figure 31 depicts the simplest linear model. As shown in Figure 32, also a central approach is possible, where a "managing TRUSTLET" (e.g. the IPL boot TRUSTLET) sits in the center of the boot process. Countless hybrid forms are also possible; one of them is exemplary depicted in Figure 33.

1.4.14.4 Exemplary TRUSTLET: API-Filter

In the transaction system described above the CASTOR chip communicates with an external host, i.e. the device containing and/or operating the CASTOR. The CASTOR'S host may never even provide an operating platform through a (graphical) user interface. However, its communication capabilities can nevertheless be used to communicate with the external (remote) world.

The interface between the CASTOR chip's I/O-unit and the host may follow a point-to-point architecture consisting of two participants, the security service provider (CASTOR chip), and a generic service consumer device (e.g. PC, smart-phone, TV, Car, eFilling station, paddle, separate eWallet etc.). The interface of such architecture is sometimes also referred to as a Process-Service- Security-Balanced-Interface or PSSBI (general outlined in Figure 22) and is provided by the API Filter TRUSTLET. According to a certain policy, conventional security APIs provide a command set using cryptography to control the processing of and the access to sensitive data. The tasks of a security API are to allow users to process data and key material, achieve flexibility and atomicity according to the designer's intention, and prevent any malicious command sequences which might violate these intention. It provides a communications interface for commands on a very low level (meaning to provide only basic and simple operations) with the intension of being usable in a more general way.

In contrast, according to an embodiment of the invention, the API filter provides a communication filter interface for services on a very high level (e.g. application specific level). Data is exchanged over this PSSBI interface in form of Protocol Data Units (PDUs) located between a hardware module and the external host (please take a look to Figure 23). There are two types of PDUs:

- command PDUs containing data sent to the CASTOR chip, and

- response PDUs containing data sent by the CASTOR chip.

To prevent some sort of abuse attacks, the API Filter TRUSTLET further enhances the CASTOR chip (owning the PSSBI Filter Controller as hardware resource) with a PSSBI gatekeeper, which

- checks incoming PDUs for their correct formats,

- formats outgoing PDUs, and

- calls the respective internal CASTOR chip service based on the PDU received from the host.

Optionally, the PSSBI gatekeeper may provide protection against buffer overflow attacks and may further detect, repeal, and recover from known (interface related) attacks. 1.4.15 PUFs

The application of a Physical Unclonable Function (PUF) is a technology in which an easy to evaluate function, embodied in a physical structure, maps a set of challenges to a set of responses based upon a hard to characterize complex physical system. The physical structure of a PUF consists of many random components introduced during the manufacturing process in a not controllable fashion. They can be regarded as digital fingerprint or "digital DNA" of a chip-identity. The PUF can help to enhance a system's security because parts of or even the complete root secret can be stored and protected without the application of digitally stored information.

As depicted in Figure 21, a PUF can be regarded in functional comparison to other mapping techniques like the ROM or a crypto function. The displayed ROM maps 2 ¹²⁸ different 'challenges' to a 128 bit wide 'response'. If the ROM matrix is filled with white noised data an almost perfect digital mapping with two exceptions is achieved: It will never be possible to build a ROM able to carry more bits than the number of stars in the universe, (2 ¹²⁸ )*128 bits as required in this case. And even in case this was possible it would be susceptible to a copy attack. If a cryptographic function like 3DES, AES or others is used, such function can replace the ROM mapping device. This is usually done in every Electronic Codebook (ECB) encryption block cipher mode of operation, the simplest one. The problem with such approach for a PUF is that there is no copy protection of the crypto cipher at all (once the crypto function becomes known, the protection is gone).

PUFs inherit their un-clonability property from the fact every PUF has a unique and unpredictable way of mapping challenges to responses in an iterative way. Due to the manufacturing process, even dies located on the same wafer (e.g. used for silicon and intrinsic PUFs) still exhibit a unique challenge- response behavior. PUFs are useful in authentication: Due to the presence of these random components, the PUF reacts in an unpredictable way (the corresponding response) if a physical stimulus (the challenge) is applied. The un-clonability property makes is impossible to build a PUF with identical challenge-response behavior as observed from a given PUF. In PUFs, different sources of physical randomness can be used. A distinction is made between PUFs in which physical randomness is explicitly introduced and PUFs using randomness intrinsically present in a physical system

According to one aspect of the invention, a PUF implemented in is used to validate the integrity of a hardware module (which may be a die, multi-die or IC). A hardware module can also be referred to as a chip. In some embodiments of the invention, the chip comprises a hardware structure providing a PUF. To use the PUF for integrity checking, it is provided with a set of challenges and the PUF's responses thereto are stored as pairs of challenges and corresponding responses.

The integrity of the chip can be checked by applying a set of challenges to the hardware structure of the chip providing the PUF and by receiving the PUF's responses to these challenges. For at least one challenge, the PUF response is known from the previously stored set of PUF challenges and corresponding PUF responses. A mismatch between the known PUF response for a challenge and the actual PUF response received from the hardware structure of the chip indicates a tampering or cloning of the tested chip.

Such PUF based integrity check may be used in different fashions.

In one exemplary implementation, the integrity check based on the PUF could be chip internal. In this case the challenges and their corresponding known PUF responses should be recorded and provided by a trusted party (e.g. RCA) in form of a certificate, which is stored in non-volatile memory inside the chip. By validating known challenges and corresponding known PUF responses, the chip can assure the challenges and corresponding known PUF responses haven't been tampered.

In this exemplary implementation, the chip could provide some integrity checking function, which may be part of the firmware in charge to check the integrity of the chip in given regular or random intervals (and at the least at bootstrapping). The integrity checking function may select an arbitrary challenge from the validated pool of challenge/response pairs and tests the PUF for the correct PUF response.

The PUF may also be used to allow for an authority to check the integrity of a chip. In this case the authority (e.g. host device, the RCA, an institution manufacturing a product containing the chip with the PUF, etc.) has recorded a set of PUF challenges and their corresponding PUF responses. For integrity checking, the chip would be provided with one or more challenge to which the response is known to the authority. If the PUF response(s) provided by the chip is/are correct, the authority can confirm the integrity of the chip, or the host device, respectively. Otherwise the authority could e.g. cause a deactivation of the chip respectively its host device, an action also feasible by means of a CRL. In one advanced implementation, the challenge(s) for which the PUF response is known is/are sent to the chip as part of a set of challenges, so the chip cannot know which of the challenges is "hot", i.e. for which challenge(s) the querying authority knows the appropriate PUF response(s).

In one exemplary embodiment of the invention, the PUF is implemented in a CASTOR chip for use in a transaction system as described herein. In this exemplary embodiment, the RCA may record the challenges and their corresponding PUF responses as part of the CASTOR'S crypto-initialization at the RCA (for more details, see section Crypto-Initialization of the Tamper-Protected Hardware Module (CASTOR)). The PUF may be used by the RCA to verify integrity of the CASTOR or may also be used by the CASTOR chip internally for verification of the integrity as described above.

1.4.15.1 Chip-internal Hardware PUFs The (standard) hardware structure provides a response to challenges input into the hardware PUF. Furthermore, the tamper-protected hardware module may be equipped with a processor unit for providing at least one challenge to the hardware structure implementing the hardware PUF, who's correct (cryptographic hash of) response from hardware structure implementing the hardware PUF is known. The processor unit receives a respective (cryptographic hash of) hardware PUF response for each challenge provided to the hardware structure implementing the hardware PUF and verifies integrity of the tamper-protected hardware module by checking whether the (cryptographic hash of) response to at least one challenge (for which the correct (cryptographic hash of) hardware PUF response is known) is matching the (cryptographic hash of) response received from the hardware structure implementing the hardware PUF.

In one exemplary embodiment of the invention the processor unit of the tamper-protected hardware module provides plurality of challenges to the hardware structure implementing the hardware PUF. The plurality of challenges including the before-mentioned or more challenges for which the correct (cryptographic hash of) hardware PUF response is known. This may be advantageous as the processor unit cannot recognize which challenge(s) response(s) to the hardware PUF (and their cryptographic hash(es), respectively) is/are known already. Therefore, it is unable to differentiate between a fake challenge and a critical one. According to a more advanced embodiment of the invention the tamper-protected hardware module further comprises an I/O-interface for receiving at least one challenge for which the correct (cryptographic hash of) hardware PUF response by hardware structure implementing the hardware PUF is known. The respective (cryptographic hash of) the hardware PUF response for each challenge applied to the hardware structure implementing the hardware PUF could be then made available outside the tamper-protected hardware module through the I O-interface.

This would e.g. allow external authorities or devices to check the integrity of the tamper-protected hardware module. Hence, the challenge(s) to the hardware PUF could be received from a device comprising the tamper-protected hardware module (i.e. from an "external component" of the device) or on-line from another, external device. Likewise, the respective (cryptographic hash of) hardware PUF responses for each challenge provided to the hardware structure implementing the PUF could be provided to the device comprising the tamper-protected hardware module or on-line to the external device, respectively.

An integrity check of the tamper-protected hardware module utilizing the hardware structure providing the PUF may for example be a tamper-protected hardware module function, implemented by the firmware (e.g. upon power-up or reset of the tamper-protected hardware module). For this purpose, in another embodiment, the tamper-protected hardware module may further comprise a storage unit for storing a set of challenges and their (known) corresponding (cryptographic hash of) hardware PUF responses. In one exemplary embodiment, the challenges and their corresponding (cryptographic hash of) hardware PUF responses are signed by a Root Certification Authority to allow verification of their integrity. The tamper-protected hardware module may verify the integrity of at least one challenge and its (cryptographic hash of) hardware PUF response based on its signature. The challenges and their corresponding (cryptographic hash of) hardware PUF responses could for example be signed by the Root Certification Authority using a signing key-pair's private signing key, while the public key is provided immune against counterfeit in the tamper-protected hardware module, is used to verify the integrity of the challenges and their corresponding (cryptographic hash of) hardware PUF responses.

Moreover, another embodiment of the invention relates to a tamper-protected semiconductor module provided with a tamper-protected hardware module having a hardware structure implementing a PUF, as discussed above. Further, another embodiment of the invention provides a device which comprises such tamper-protected semiconductor module.

The type of the hardware PUF can be of standard hardware (silicon, optical, magnetic, acoustic, coating, butterfly, or intrinsic) PUF, or even a Cocoon PUF.

1.4.15.2 Semiconductor Modules with Cocoon PUFs

Another aspect of the invention is related to the design of the tamper-protected semiconductor module. Please note, this aspect is independent of the other aspects of the invention provided herein, but - in some embodiments of the invention - may nevertheless used in combination with them to further improve tamper resistance.

The basic approach underlying this aspect of the invention is to design a semiconductor module which has unique properties with respect to the deflection of a physical measurand within the semiconductor module in response to an excitation (which could be also denoted a challenge). These unique deflection properties inside the semiconductor module are introduced by the production process of the semiconductor module (for example as a result of its manufacturing process) and are thus capable of uniquely identifying the semiconductor module. Further, any attempt to tamper the semiconductor module will alter its deflection properties since any attack on the inside of the semiconductor module will influence the physical measurand. This makes tampering attempts observable by the semiconductor module. Therefore, it is referred to as "tamper-protected".

Figure 27 shows a tamper-protected semiconductor module according to an exemplary embodiment of the invention, which is provided with a cocoon PUF. The semiconductor module is made of a hardware module (die/chip). The hardware module of the semiconductor module is exemplified in Figure 28 and comprises one or more emitters and one or more sensors. The emitters emit a predetermined excitation which can be measured as a physical measurand. The one or more sensors of the hardware module sense the (back-) scatter of the predetermined excitation in form of the physical measurand in a contactless manner. As shown in Figure 27, the hardware module is bonded (e.g. by means of a ball grid) to a circuit carrier providing terminals to the outside of the housing. The bonding and the provision of the connection terminals may be realized by any suitable technique known state of the art.

The hardware module protected by the cocoon may be any hardware structure that should be made tamper resistant. In one exemplary embodiment of the invention, the hardware module is a die, a multi-die, or a chip comprising one or more integrated circuits (ICs). Likewise and in another embodiment of the invention, the hardware module is a die, a multi-die, or a chip comprising one or more ICs assembled on a circuit carrier (e.g. by means of a bonding process).

The tamper-protected semiconductor module further has a cocoon that houses the hardware module (housing). This cocoon may also be referred to as a package or housing. The cocoon is configured to influence the (back-) scatter of the predetermined excitation to be sensed by the sensors. In the example of Figure 27 the cocoon comprises a shielding which is advantageously provided towards the inside of the housing and which is surrounding the entire hardware module and the circuit carrier. The shielding is preventing interference with the measurand from the outside of the semiconductor module. Furthermore, the inside of the housing (and inside the shielding), the (gap inside the) semiconductor module (between the hardware module and the cocoon) may be filled with a potting material or - in another implementation possibility - the housing is the cocoon and thus contains the potting material. Further, the housing may be non-transparent in the optical and infrared spectrum. This feature may be for example advantageous for preventing non-invasive attacks on the inside of the tamper-protected semiconductor module (respectively, its cocoon as the outer part), e.g. by means of infrared light or other optical scanning methods. Moreover, the cocoon may have a high thermal conductivity, so that heat (generated by the operation of the hardware modules circuitry and/or circuit components) may be guided to the outside of the cocoon thus enabling cooling of the hardware modules from the outside of

A high thermal conductivity may be defined as a thermal

In order to provide unique deflection properties inside the cocoon, the design of the cocoon (besides adding a shielding) may ensure for such property. For example, the cocoon comprises a coating and/or a potting compound including a material or material mixture (e.g. granules added to a conventional coating/potting material, such as a ceramic or a synthetic material) influencing the (back-) scatter of the predetermined excitation. Please note the coating and/or potting is provided inside the shielding. In the exemplary embodiment shown in Figure 27 the potting material is provided with some material (here, granules) which influences the (back-) scatter of the predetermined excitation of the emitters. In this embodiment, an electromagnetic excitation is used, i.e. the sensors may for example sense the electromagnetic field (e.g. magnetic field intensity and/or electric field intensity) of the (back-) scatter of the predetermined excitation from a specific point or region of the cocoon emitted from the emitters on the hardware module, which could be viewed as charting of an excitation map. These measured values are then quantized and form the digital PUF "response" to the "challenge", i.e. the predetermined excitation.

The granules within the potting and/or coating are of a material which reflects the excitation within the limits of the cocoon (i.e. the shielding) so that a unique (back-) scatter is sensed by the sensors. The distribution of the granules within the potting material is virtually random and depending on the production process of the cocoon. Therefore, the (back-) scatter obtained in response to the predetermined excitation is unique to the semiconductor module.

In another exemplary embodiment of the invention, the material of the shielding and/or the material of the granules thereof are similar to the material mixture of the hardware module and/or its bonding with respect to their chemical character (and optionally the physical character) to make full-invasive attacks on the tamper-protected semiconductor module more difficult: The package (cocoon) of a semiconductor module can be removed using acids or chemical bases in order to access the inside hardware module. By choosing the chemical character of the cocoon material and the hardware modules material (and/or its bonding) to have similar chemical resistance against acids/chemical bases, it is difficult to control the edging to only remove the cocoon material, while not damaging the hardware module and/or its bonding. Similarity in the physical character may be advantageous, since the physical character influences the reaction time with the acid/base. Hence, it becomes even more difficult to control etching precisely enough it only removes the cocoon material without damaging the hardware module or its bonding.

1.4.15.2.1 Different principles of a Cocoon PUF

Since the properties of deflection, reflection, absorption, (back-) scattering, and refraction of the inside of the cocoon in combination with a given excitation depends on the production process, e.g. the packaging process of the hardware module, the measured (back-) scatter of the predetermined excitation influenced by the cocoon (deflection properties depending on the production process of the cocoon) provides a physical unclonable function (PUF) specific to the tamper-protected hardware module. This PUF functionality of the tamper-protected semiconductor module is for simplicity also referred to as "cocoon PUF". Using this cocoon PUF the hardware module is able to detect tampering of the tamper-protected semiconductor module and to detect non-invasive (or passive), semi-invasive and full-invasive attacks to access the inside of the cocoon or the hardware module, respectively. In case the hardware module detects a tampering attempt to the tamper-protected semiconductor module, the hardware module could for example make itself temporarily or permanently unusable.

How the tamper-protected semiconductor module is using its PUF functionality to detect tampering may be implemented in various ways. For example, in one exemplary embodiment of the invention, the tamper-protected semiconductor module may generate a digital "measured fingerprint" susceptible to be represented as e.g. a map (i.e. containing positional information, denoting the fingerprint that has been - so to say - just been "measured" by the sensors) of the tamper-protected semiconductor module from the measured values of the (back-) scatter of the excitation provided by the respective sensors and detects an attempt to tamper the tamper-protected semiconductor module by comparing the measured digital fingerprint with a digitized fingerprint of the un-tampered tamper-protected semiconductor module (which may have been for example stored previously). It should be apparent that the repeated verification of the integrity of the cocoon or the tamper-protected semiconductor module requires the same predetermined (map of) excitation is emitted in each verification process, i.e. each measurement of the (back-) scatter of the (map of) predetermined excitation (for details on the "same" predetermined excitation, please see below).

In another exemplary embodiment of the invention, the cocoon PUF may be used to reconstruct a two- factor secret from helper data. If the cocoon PUF is changed, the original, correct secret cannot be recovered from the helper data any more. This procedure will be outlined in the following in more detail with respect to Figure 29 and Figure 30.

As depicted in Figure 29, the helper data generation process is exemplified, which is to be performed with the un-tampered semiconductor module. The helper data generation function provided in the hardware module is provided with a secret and uses the PUF data obtained from the cocoon PUF by the measurement unit (collecting the sensors' measured values of the predetermined excitation's (back- ) scatter) to generate helper data. The secret is thus split into two parts, the PUF data and the corresponding helper data. The helper data can be left un-protected and may be stored in a CASTORs internal or external non-volatile memory without any further protection. In order to recover the secret, a "secret generation function" is used, which is inversing the operation of the helper data generating function, given correct PUF data and helper data are used. Hence, the helper data is loaded from the CASTORs internal or external storage and the secret generation function obtains the latest PUF data from the measurement unit (collecting the sensors measured (map of) values of latest measurement of the (back-) scatter of the (map of) predetermined excitation) to generate a secret. As long as the PUF data is the same PUF data previously used in the helper data generation process and the helper data is the helper data generated in the previous helper data generation process, the correct secret is reconstructed, otherwise another, however incorrect, "secret" is obtained.

Using this mechanism for tamper protection, some essential data required by the firmware to operate the hardware module could be input to the helper data generation function upon setup or initialization of the hardware module, and only the helper data thus obtained is stored in the hardware module (or an external memory). Hence, in order to operate the hardware module, the tamper-protected semiconductor module requires the correct secret (i.e. the essential data). Accordingly, the hardware module might generate a measured digital fingerprint of the tamper-protected semiconductor module from the (map of) measured values of (back-) scatter of the excitation provided by the sensors, receive the helper data from memory, and generate a secret based on the measured digital fingerprint and the helper data (a two-factor secret), as depicted in Figure 30. In case the measured digital fingerprint is not corresponding to the "correct" (previously measured and digitized) fingerprint of the un-tampered tamper-protected semiconductor module, the generated (recombined two-factor) secret is incorrect. This means: It is not corresponding to the "correct" secret that had been obtained from the generation of the secret using the helper data and the "correct" fingerprint of the un-tampered tamper-protected semiconductor module.

Hence, in this case the hardware module won't be operable as the essential data won't be correct. Furthermore, the generation of an incorrect secret does also imply, the unique deflection properties inside the cocoon must have been changed somehow (i.e. the PUF function of the tamper-protected semiconductor module has also changed), which in turn indicates an attempt to access the inside of the cocoon (respectively, tamper-protected semiconductor module), thus flagging a tampering attempt. 1.4.15.2.1.1 Electromagnetic (radio) Fingerprinting

If electromagnetic excitation is used, the shielding should be an electromagnetic shielding to provide a Faraday cage within itself. For example, the shielding material may be or comprise a metal or another material with high magnetic permeability and high electrical conductivity. This electromagnetic shield may shield anything inside its cocoon, the shielding from all electromagnetic excitations, or at least electromagnetic excitations up to frequencies in the GHz or even THz range. Hence, the permeability of the shielding material should be selected accordingly. In one embodiment of the invention, the magnetic permeability of the material of the electromagnetic shielding is as high as possible. In an exemplary embodiment of the invention, the shielding has high magnetic permeability, such as for example Permalloy (e.g. a Nickel-Iron magnetic alloy). Furthermore, in some applications low coercivity, near zero magneto-striction, and significant anisotropic magneto-resistance of the shielding material may be desirable. High magnetic permeability for example means permeability _r higher than approx. 5.000 H/m.

The electrical conductivity (the specific conductance is the reciprocal quantity, and measures a material's ability to conduct an electric current) of the material of the electromagnetic shielding is as high as possible. In an exemplary embodiment of the invention, the shielding has high electrical conductivity, such as a metal like aluminum, gold, copper or silver for example. High electrical conductivity for example means a conductivity σ (commonly represented by the Greek letter σ , but also the Greek letters κ and γ are occasionally used) higher than approx. 10 ⁶ S/m.

There are also various possibilities how to provide the one or more emitters on the hardware module. For example, one possibility is to use (non-specific) circuitry and/or integrated circuits of the hardware module (e.g. semiconductor elements and/or Micro-Electro-Mechanical-Systems (MEMS)) as emitters. Hence, individual circuit components, wires or some chip areas of the hardware module may have properties of an oscillator/clock generator/radiator and may thus be used as emitters for emitting the predetermined electromagnetic excitation. In order to ensure the emission of the predetermined excitation, the tamper-protected semiconductor module operates the emitters at predetermined operation conditions during the period in time the sensors are to measure the (back-) scatter of the excitation. To establish such operation conditions, the tamper-protected semiconductor module may (partially) deactivate the (integrated) circuit parts of the hardware module during a measurement cycle in which the one or more sensors sense the (back-) scatter of the predetermined excitation. For instance, such (partly) deactivation may be a deep power down to minimize the interference of the (integrated) circuit parts of the hardware module with the (back-) scatter of the predetermined excitation.

Alternatively or in addition, the circuitry use and/or integrated circuits of the hardware modules emitter, oscillators/radiators may be provided on the hardware modules for the purpose of emitting the predetermined excitation. The entirety of the oscillators/radiators together (and optionally in combination with the emitter(s) formed by circuitry and/or integrated circuits of the hardware module) emits the predetermined excitation.

The concept of the cocoon PUF is, however, not limited to the use of electromagnetic excitations. The emitter(s) may provide an electromagnetic excitation (e.g. electromagnetic fields, x-ray, etc.), an optical excitation (e.g. generated by LED or LASER elements) and acoustic excitation (e.g. infra- or ultrasonic), or combinations thereof (please see below). Accordingly, the sensors that sense the (back-) scatter of the excitation are - dependent on the type of the excitation - electromagnetic sensors, electric field sensors, magnetic field sensors, acoustic sensors, optical sensors or other radiation sensors. The sensors and/or the emitters may be implemented as Micro-Electro-Mechanical-Systems (MEMS) and or Nano-Electro-Mechanical-Systems (NEMS).

1.4.15.2.1.2 Optical (light) Fingerprinting

Optical imaging is a technique and process used to create images of the environment for further processing purposes (physical procedures seeking to reveal, analyze or examine information for an "initial pattern learning" or "recognition match with already known patterns"). Although imaging physical structures of interest can be performed for analyzing reasons, such procedures are not usually referred to as picture imaging, but rather could be a part of cocoon fingerprinting. As a discipline and in its widest sense it is part of general imaging and incorporates investigative radiological sciences, thermography, and photography. Measurement and recording techniques which are not primarily designed to produce images, but which produce data susceptible to be represented as maps (i.e. containing positional information) can be seen as forms and means of fingerprinting imaging that may also be used to generate a fingerprint of a given semiconductor module including a cocoon.

An example for such optical fingerprinting that may be used also for generating fingerprints of a semiconductor is an optical radar, particularly a laser radar (Light Detection And Ranging (LIDAR)) used to record range images (the name for a collection of techniques which are used to produce a 2D image showing the distance to points in a scene from a specific point, normally associated with some type of sensor device) or reflection images (same constructed from the reflection and on the formation of light). It consists of a light source (serving as an emitter of the excitation), a light receiver (serving as a sensor) and a processing unit. The light source and the light receiver can be e.g. constructed as diode rows which operate in conjunction with one or more imaging optics in a manner a light pulse from a particular transmitter diode is imaged on a particular receiver diode after reflection in a particular scanning field of the objective lens. For fingerprinting a semiconductor module, one or more light sources and one or ore light receivers could be provided on the hardware module and the scanning field may be defined within the inside of the cocoon encapsulating the hardware module.

1.4.15.2.1.3 Acoustic (sonic) Fingerprinting

An acoustic wave is the propagation of oscillations of molecules or point masses. The sonic speed is up to pressure, temperature, material properties, frequency and amplitude. At every place the contemporaneous measurement of time-dependent physical values like the elongation of atoms/- molecules from their middle position, speed, pressure, temperature, and density is possible. This leads to the calculation of sound pressure, energy density, sound power, sound intensity, and sound pressure level, usable for a fingerprint generation process. An example for such principle is the navigation of bats through ultra supersonics, allowing them the acoustic classification of landmarks and identification of objects. Another example of sonic fingerprinting is found in the field of underwater acoustics: The study of sound-propagation in water and the interaction of the mechanical waves that constitute sound with the water and its boundaries. This leads then to a number of other fields of acoustic study, including sonar, transduction, acoustic signal processing, acoustical oceanography, bioacoustics, and physical acoustics. All these areas use the physics of acoustic waves for fingerprinting purposes in one or another way and the principles may also be used for generating an acoustic (sonic) fingerprint of a semiconductor module. For example, an acoustic (sonic) excitation can be emitted by the emitters on the hardware module and the sensors measure (or a processing unit determines from measurement values of the sensor(s)) one or more of the parameters sound pressure, energy density, sound power, sound intensity, and sound pressure level, which are used to defined a fingerprint of the semiconductor module is some predetermined way.

1.4.15.2.1.4 Digital Geometry Processing (DGP) Fingerprinting

Digital geometry processing is used to generate a three-dimensional image of the inside of an object and its detailed internal structures from a large series of two-dimensional images. Known examples are Computer Tomography (CT) scanning systems and Magnetic Resonance Imaging / Tomography (MRI MRT) systems. Both produce a volume of data which can be manipulated through a process known as "windowing" in order to analyze various structures based on their ability to block the radiation. Although most common in medicine, they are also used in other fields, such as nondestructive materials testing. Another example is archaeological use. In this invention, these mechanisms can be used to generate a PUF fingerprint inside the cocoon (shielding) of the semiconductor module.

1.4.15.2.2 The Shielding

The shielding, of course, also depends on the type of the excitation by the emitter(s). Hence, the shielding can be an electric, magnetic, electromagnetic, acoustic, optical shielding or a combination thereof (as descript above). The mechanism of action of a shielding is a combination of reflecting and absorbing/attenuating an excitation, so that only very little excitation would penetrate the cocoon (with the shielding).

The intended effect of a shielding comprises two principle strategies:

- preventing undesirable emittance of the excitation to the outer world beyond the limits of the cocoon, to minimize EMI and insofar protecting the environment from a pollution of the excitation, and

- preventing a "mixture" of the self-generated "predetermined" excitation with an excitation coming from the outside of the tamper-protected hardware. This ensures the sensors measure of only the (back-) scatter of the predetermined excitation within the limits of the cocoon (respectively, the shielding provided therein).

Different types of shielding are to be applied depending on the type of the excitation by the emitter(s). 1.4.15.2.2.1 Optical Shields

An optical shielding may for example comprise one or more surface reflectors or could be implemented as a surface reflector that covers at least a portion of the hardware module. For example, in one exemplary implementation, the surface reflector(s) could be made of metal (e.g. aluminum, silver or the like) in form of a coating e.g. on the inner and/or outer surface of the cocoon. Another exemplary realization of an optical shielding is to use the principle of optical fibres. The light is "waveguided" on the top of the cocoon on the hardware module by the shielding - acting as "light pipe" - using a process of total reflection between two dielectric materials of the shielding with different refractive indices. Another way is the more or less high absorption known from black bodies. 1.4.15.2.2.2 Acoustic Shields

An exemplary known way to shield acoustic excitation is the anechoic room that can be for example provided inside the cocoon (more precisely, the shielding) of a semiconductor module. An anechoic chamber is designed to suppress the acoustic echo-waves and isolates from the acoustic noise present in the external environment.

Another way is the usage of Active Noise Reduction (ANR) inside the cocoon of the semiconductor module in cases where the structure of the noise is known (e.g. by using internal and/or external microphones). Noise-cancelling may be for example realized by emitting a sound wave with the same amplitude but with inverted phase (also known as antiphase) to the original sound. The waves combine to form a new wave, in a process called interference, and effectively cancel each other out - an effect which is called phase cancellation.

Another exemplary implementation of an acoustic shielding is provided using shielding material able to comprise or consist of permanently elastic compound structured foamed material, which could be provided inside the cocoon of the semiconductor module.

1.4.15.2.2.3 Magnetic Shields

In another embodiment of the invention, a magnetic shielding can be provided. The conductivity/permeability of the shielding material should be as high as possible. In an exemplary embodiment of the invention, the shielding material comprises or is a material that has a high permeability, such as Permalloy for example (e.g. a Nickel-Iron magnetic alloy).

Furthermore, in some applications it may be desirable that the shielding material furthermore has low coercivity, close to zero magneto-striction, and significant anisotropic magneto-resistance. High permeability may for example mean permeability μ _Γ higher than 50,000 H/m or at least 5,000 H/m.

1.4.15.2.2.4 Electric Shields

Another possibility is to use an electric shielding. The electric shield is reducing the electrostatic field in a space by blocking the field with barriers made of conductive materials. The same precautionary measures applied against the electromagnetic shielding are also suitable for blocking this type of field. 1.4.15.2.2.5 Electromagnetic Shields

For example, to provide an electromagnetic shielding, in one embodiment of the invention, the shielding material is providing a Faraday cage. The shielding material may be or comprises of a (combination of) metals (e.g. aluminum, silver or the like) and/or other material with high conductivity/permeability.

The Faraday cage shields the inside of the cocoon from electromagnetic interference from the outside. This electromagnetic shield should protect everything inside its cocoon against electromagnetic excitations in the band up to frequencies in the GHz or even THz range. Hence, the conductivity/permeability of the shielding material should be selected accordingly.

1.4.15.2.3 Generation of the Shielding

The shielding can be produced by using one or more of the following technical processes for producing different layers of shielding material on the inside and/or outside of the cocoon surface:

- sintering one or more shielding materials,

- sputtering one or more shielding materials,

- spraying, spritzing or bubbling one or more shielding materials (e.g. using High-Volume-/Low- Pressure plants (HVLP)),

- coating and or plating one or more shielding materials (e.g. electric conductive (finishing) paint/lacquers containing/made of epoxy, polyurethane or acrylic with expletive particles like silver, silver plated copper, pure copper or nickel),

- immersing in one or more baths of fluids comprising the shielding material,

- evaporating, optional in a vacuum, of one or more shielding materials (e.g. Physical Vapor Deposition (PVD)),

- electroless plating one or more shielding materials (e.g. one layer/sheet/lamina e.g. of pure copper, followed by another layer/sheet/lamina e.g. of nickel-phosphorus alloy),

- electrolysis using one or more same shielding materials.

1.4.15.2.4 Generation of the Fingerprint

Regarding the predetermined excitation, there are also various possibilities how to generate such predetermined excitation. To reproduce the "fingerprint" (of the un-tampered hardware) the predetermined excitation should be the same in each measurement cycle in which the sensors sense their measured values that are used to determine the actual "just measured" fingerprint. In practice, it may be difficult to achieve identical excitations (for example, due to temperature variations, drift effects of physical material properties in time, the fact of a noisy measurement, fuzzy sensors, etc.). Hence, the same excitations should not be interpreted as 100% identical excitations; however, the variations may be compensated by the fingerprint generation process (e.g. using error detection and correction mechanism, e.g. ECC, EDC and CRC) of the fingerprint from the measured values provided by the sensors and/or countermeasures may keep variations of the excitation in an acceptable range not critical to the uniqueness and stability of the generated fingerprint. In one exemplary embodiment, the cocoon's influence the (back-) scatter of the excitation to be sensed by the sensors is insensible to change of temperature (at least within a definable range or desirable range of temperatures).

There may be a tradeoff in terms of a mutual influence between the implemented countermeasures keeping variations of the excitation in an acceptable range not critical to the uniqueness and stability of the generated fingerprint (effectively, such countermeasures may reduce the amount of usable digital data for the fingerprint) and the generation process of the fingerprint from the measured values provided by the sensors (i.e. the measured values so to say forms the data basis for determining the fingerprint): On the one hand, the generation process of the fingerprint should not reduce the data basis for the generation of the fingerprint such that it loses its uniqueness; on the other hand, countermeasures keeping variations of the excitation in an acceptable range may aid to minimize the reduction of the data basis for the fingerprint, but may be expensive to implement. However, by providing a sufficiently large data basis, i.e. sufficient number of measured values by the sensors for the countermeasures to keep variations of the excitation in an acceptable range may be one solution to solve this tradeoff.

To generate a sufficient data base (i.e. a sufficient number of measured values (respectively "bits") once the measured values are quantized) that can be used for the generation of the unique fingerprint of the tamper-protected semiconductor module, different possibilities to design the predetermined excitation of the one or more emitters are possible. For example, one possibility may be that the predetermined excitation is a constant predetermined excitation, i.e. not varying in time. Alternatively, the predetermined excitation could be also an excitation that is varying in a predetermined manner - which implies that the sensors should measure the measurand multiple times within a measurement period. The variation of the excitation could be for example implemented by the hardware module comprising an excitation controller that controls the emitters individually or in combination to produce the predetermined excitation varying in time. For example, different sets of emitters are used in a given sequence in time to generate respective excitations (i.e. a predetermined sequence of individual excitations) that form the predetermined excitation.

In one exemplary implementation of the invention, the measurement process uses the feature of localization (pinpointing) to increase the available database of measurands.

In a further embodiment, the sensors to provide a measured value of the measurand that is to be part of the data basis for generating the fingerprint could be controlled by the hardware module. For example, the hardware module may trigger/query different sets of sensors at different times of a measurement cycle to receive their measurement results. This control of the sensors may of course be readily combined with the control of the emitters described in the preceding paragraph.

For the purpose of controlling emitters and sensors and optionally of deactivating the (integrated) circuit parts of the hardware module during a measurement cycle, a measurement unit may be provided on or by the hardware module. This management unit may be considered an IC of the hardware module or may be implemented in its firmware. The management unit transmits and/or receives commands and/or data packets from the other integrated circuit parts of the hardware module, e.g. the sensors and emitters to control their emission, respectively receive the measured values. Further, the measurement unit may coordinate the one or more sensors and the one or more emitters in a measurement cycle.

Please note, the cocoon may be the housing of the hardware module or may itself be included in a housing together with the hardware module. Likewise, the shielding of the tamper-protected semiconductor module could be part of the cocoon or may enclose same. In case a "separate" housing is provided the cocoon could be provided in form of a malleable mass between the housing and the hardware module.

1.4.15.2.5 Manufacturing of a Tamper-Protected Semiconductor Module with Cocoon PUF

Another aspect of the invention is the provision of a manufacturing process for a tamper-protected semiconductor module with a cocoon PUF. According to an embodiment of the invention the manufacturing process of a tamper-protected semiconductor module with a cocoon PUF comprises the provision of a hardware module equipped with one or more emitters for emitting a predetermined excitation that can be measured as a physical measurand, and one or more sensors for sensing the (back-) scatter of the excitation in form of the physical measurand in a contactless manner. Further, as another step of the manufacturing process, the hardware module is housed in a cocoon to realize the tamper-protected semiconductor module, wherein the cocoon influences the (back-) scatter of the excitation sensed by the sensors in a way unique to the tamper-protected semiconductor module.

Housing the hardware module in the cocoon comprises enclosing the hardware module in a potting material, and encapsulating the hardware module enclosed by the potting material with a shielding to prevent interference with the predetermined excitation from the outside of the tamper-protected semiconductor module. As noted above, the shielding may be but is not necessarily part of the cocoon. Optionally, the shielding may be subject to thermal treatment. Further optionally, the manufacturing method provides a passivation (e.g. electrical isolation) to the hardware module.

The hardware module may be manufactured in a standard wafer process, for example a silicon semiconductor process. 1.4.15.2.6 Detection of Attacks

A further aspect of the invention is to provide a method for detecting an attempt to tamper a tamper- protected semiconductor module equipped with a cocoon PUF. The hardware module of the tamper- protected semiconductor module with the cocoon PUF

a) causes the one or more emitters of the hardware module to emit predetermined excitation, and further

b) caused the one or more sensors of the hardware module to sense the (back-) scatter of the predetermined excitation reflected by the cocoon of the tamper-protected semiconductor module.

Further, the hardware module then

c) generates a digital "measured fingerprint" from (back-) scatter of the predetermined excitation sensed by the one or more sensors, and

d) verifies the integrity of the cocoon by using the measured digital fingerprint recorded.

The "measured fingerprint" is denoting the fingerprint derived from the most recently measured values of the (back-) scatter of the predetermined excitation sensed by the one or more sensors.

The hardware module may perform steps a) to d) not only once, but also repeatedly. Hence, an ongoing verification of the integrity of the tamper-protected semiconductor module is possible. Steps a) to d) may be for example repeatedly performed in irregular intervals or on a random basis.

e) In this further step of the measurement process, an interrupt is produced, in case integrity could not be verified in step d). This interrupt may cause the hardware module to permanently or temporarily make itself unusable. In a further embodiment of the invention, the measurement process further comprises another step

f) of deactivating integrated circuit parts of the hardware module during a measurement cycle in which the one or more sensors sense the (back-) scatter of the predetermined excitation. This may be helpful to produce the same predetermined excitation in all measurements.

In a further exemplary embodiment, the method for checking the integrity of the cocoon may further comprise the following steps of

g) initializing the hardware module by creating and recording a fingerprint of the un-tampered semiconductor module,

h) securing this fingerprint of step g) using a certificate signed by an Certification Authority, and i) storing the certified fingerprint in a semiconductor non-volatile memory. In one exemplary embodiment, this certificate may be signed by the Root Certification Authority (RCA) or another Certification Authority that can be validated against the RCA's certificate containing the public key part of the RCA's public key-pair.

Another possibility for verifying the integrity of the cocoon is the use of the cocoon PUF as part of a key restoration process (two-factor secret). This key restoration process is used to recreate the key (also referred to as "recombined secret") from helper data using the cocoon PUF. The helper data is generated based on the key using the cocoon PUF of the un-tampered cocoon, respectively, un- tampered (tamper-protected) semiconductor module, which binds the recreation of the key to this specific cocoon PUF. If the cocoon PUF is altered due to a tampering attempt, the key may be temporarily or permanently destroyed, as the cocoon PUF will be temporarily or permanently changed as a result of the tampering attempt, so that the key generation function is unable to reconstruct the correct key (again). Hence, in this exemplary embodiment, the verification of the integrity of the cocoon is realized by means of a key restoration process generating a key based on helper data and the sensed (back-) scatter of the predetermined excitation.

The generation of the helper data may be for example part of an initialization procedure of the semiconductor module in an un-tampered case (e.g. by performing the initialization at a trusted party; a trusted party could be for example a Root Certification Authority, the manufacturer of the tamper- protected semiconductor module, the manufacturer of a device comprising the tamper-protected semiconductor module, the customer/user, etc.). Therefore, in another embodiment of the invention, the method further comprises the steps of g) initializing the hardware module by creating and recording a fingerprint of the un-tampered semiconductor module, and generating the helper data based on the key and the sensed (back-) scatter of the predetermined excitation. This helper data may then be stored in a non-volatile memory.

Please note that the helper data may not need to be protected, since it is impossible to recreate the secret from the helper data without the correct hardware PUF. Hence, the helper data may be stored either in the hardware module or in an external storage of a device or another hardware structure that contains the tamper-protected semiconductor module.

1.4.16 Maze of Knossos - Configuration of the FPGA

Another aspect of the invention is the use of a unique configuration of FPGAs (Field Programmable Gate Arrays) on a chip (after programming the FPGA to fulfill the desired functionality), which allows integrity checking based on the uniqueness of their configuration. FPGAs may be used on chips to provide various customized functionality. The unique configuration of the FPGA after its programming can be considered a fingerprint of the FPGA itself. For example, a FPGA may be used to implement a crypto-coprocessor though this aspect of the invention is not limited to this use.

The Maze of Knossos introduces another element of chip individualization through randomness. It allows a limited change of the soft-core functionality even during runtime on a small scale similar to the FPGA fundamental basic approach. The programming is done through six non-volatile configuration memory cells in every interconnection point, which are distributed all over the maze array. The FPGA inspired maze structure consists of many functional Processing-Elements (PE) interconnected by Switch-Boxes (SB) as shown in Figure 24. The PE elements are scaled on their function and not on the gate level. A type code indicates their functionality. Different values mean the PEs provide different functionality. Thousands of different PE types could be designed. The distribution of the PEs (with their intended functionality) on the die changes with every mask revision.

Figure 25 exemplarily shows the more detailed structure of the PEs. In Figure 25 a PE of type '6789' is exemplified, however this hasn't any implications on the PEs' structures. The PEs are optimized and fixed (not programmable) hard macros consisting of a simple control (sequencer) logic, two different logic functions, a small register bank, and a SRAM based distributed memory.

Figure 26 exemplarily shows the logical design-principle of a switch-box (SB). In this example, every SB consists of four inter-connection-points acting as routing element with 4x4 rows and columns. Every interconnection may for example consist of six pass transistors, like programmable switches (shown in the middle). The gates of the pass transistors are driven by non-volatile configuration memory cells. SBs behave like inverse fuse based connections: non-programmed interconnection points represent an open connection (shown on the left hand side of Figure 26). After programming the SB connects its neighbors as shown on the right hand side of Figure 26.

The Maze of Knossos can be used to realize a programmable limited cryptographic functionality. Due to its structure, there are multiple ways to create identical functionality using different configurations of the PEs and SBs, comparable to a maze in which more than a single direction is pointing the way out. This translates to the possibility of different sets of different programmed PEs and switch-boxes in fact leading to the same overall functionality being provided by the FPGA. This means, though they provide the same functionality, each FPGA within a chip can be implemented in a unique way.

The unique selected set of configuration memory cells within a FPGA in combination with uniqueness (introduced by the PUF) thus builds a fragile well-balanced system which allows testing the chip- identity. Any cloning of the chip can be detected, if either one of the configurations of the PEs or SBs is altered, due to the change of its FPGA configuration.

For integrity checking of the chip, the unique configuration of its FPGA can be used in different fashions, similar to the use of a PUF.

In one exemplary implementation, the integrity check based on the FPGA configuration ("FPGA fingerprint") could be chip internal. In this case the FPGA configuration of the chip is recorded by a trusted party (e.g. RCA) in form of a certificate which is stored in memory inside the chip. By validating the certificate of the original FPGA configuration the chip can assure the FPGA's configuration hasn't been changed.

In this exemplary implementation, the chip could provide some integrity checking function (e.g. as part of the firmware) which checks the integrity of the chip during bootstrapping. The integrity checking function may read the chip's current FPGA configuration and compares it to the original FPGA's configuration provided in the certificate. A mismatch indicates that this chip is a clone.

The FPGA configuration may also be used to allow an authority to check the integrity of a chip. In this case the authority (e.g. host device, the RCA, an institution manufacturing a product containing the chip with the PUF, etc.) has recorded the original and correct FPGA configuration for a chip. For integrity checking, the chip is queried by the authority to obtain its FPGA's configuration. If the FPGA configuration provided by the chip is correct, i.e. if it matches the previously stored original FPGA configuration, the authority may confirm the integrity of the chip, or the host device, respectively. Otherwise the authority might for example cause a disablement of the chip or its host device, respectively, which could be implemented via a CRL as well.

In one exemplary embodiment, a FPGA is used to implement a crypto-coprocessor in a tamper- protected chip for use in a transaction system as described herein. In this exemplary embodiment, the RCA may record the FPGA configuration as part of the CASTOR'S crypto-initialization at the RCA (for more details, see section "Crypto-initialization of the Tamper-Protected Hardware Module (CASTOR)"). The recorded original FPGA configuration may be used by the RCA to verify integrity of the CASTOR or may also be used by the CASTOR chip internally for verification of the integrity as described above.

Furthermore it should be apparent that using the uniqueness of a FPGA's configuration for integrity checking may be readily combined with other security measures for integrity checking, e.g. the use of a PUF on a chip. If the RCA's certificates were used for the integrity check, the RCA might provide all relevant information needed to confirm integrity in one certificate.

1.4.17 On-chip Trusted Time Source

An option for the CASTOR-internal provision of a trusted time could be the integration of an energy- buffered and trusted real-time source on the CASTOR chip with a battery. However, as the battery may be difficult to integrate in the chip (even enlarging the waste disposal procedures), in one embodiment of the invention the CASTOR chip is provided with a strong monotonic counter. This counter always reflects the CASTOR'S latest date and time. If date and time information provided by the counter becomes invalid (e.g. due to a power-loss), a trusted resynchronization with a reliable source is performed (e.g. by contacting the RCA or other authority able to provide a signed, new, and up-to-date date and time). The resync may be for example performed in the following events:

- If the CASTOR discerns another CASTOR'S date and time as 'more recent'. This can be detected e.g. in the Pairing Phase, where the CASTORs include local timestamps into the messages. Please note, as a measure of security in CASTOR-to-CASTOR communications only a "move forward" in time is possible but not a move back into the past. - If in CASTOR-to-authority communications an automated update triggers and res nchronizes the date and time or a push message with an updated date and time received from trusted authorities, the CASTOR is provided with a signed 'set-monotone-counter' message and takes over this certified date and time, even in case the system is brought 'back to the past'. 1.4.18 Crypto-Initialization of the Tamper-Protected Hardware Module (CASTOR)

Private keys (as private key parts of public-key-pairs or as secret symmetrical keys) of a CASTOR are managed internally inside the CASTOR and are never revealed or propagated to the outer world. Keys (if) stored externally are secured beneath the umbrella encryption (all data that is passed to the outside of the CASTOR via the CASTORs I/O-interface e.g. the PSSBI discussed above, is protected by using this method). All keys are managed by the CASTOR'S firmware. They are created, used, replaced and destroyed based on a security policy without any user intervention. After the production process of the CASTOR chip, a validation by the RCA takes place with the effect to generate a validated CASTOR chip. As part of the validation process:

- The CASTOR chip may itself generate its identifying descriptor item (e.g. serial number) based on cryptographic physical randomization effects.

- The CASTOR chip itself may generate a public key-pair used by the CASTOR for signing to thereby allow verification of the CASTOR' s identity in the transaction system. The private key part of this signing key-pair is denoted SUDI (Secret Unique Device Identity), and the public key part (Ks:CASTOR:PUDi _>P ub) of the signing key-pair is denoted PUDI (Public Unique Device Identity).

- The CASTOR chip itself generates its CON (Consistency) public key-pair for internal hash signing and checking purposes.

- The RCA signs the PUDI key and provide a cryptographic hashed version of the signed PUDI key in the CASTOR root certificate (Type-VI) which is thus individual for each CASTOR (also referred as "CertXicenselD" within the CASTOR root certificate).

Some keys are truly random number based, self-generated on chip by the CASTOR (please refer also to section "Private Key Rings"), never leaving the protected environment of the CASTOR and never being exposed to the outer unsafe world. This generation mechanism is also true for the CASTOR identifier (ID) and the individual en/decryption key for the umbrella protected access via the CASTOR chip's I/O-interface.

Each CASTOR undergoes a validation process at the RCA, as noted above. Without such validation, the CASTOR is useless. This validation at the RCA, also referred to as initialization procedure, may include the following steps:

- An on-chip key and identification generation process is initiated by an external command through the I/O-interface of the CASTOR chip. For example, this process can only be done once in a CASTOR'S lifetime (the ID change of a CASTOR is impossible). During this on-chip key and identification generation process, the above mentioned keys and objects are generated - among other things (e.g. the setup of the security system).

- The PUDI and the public key part of CON are delivered to the external world, the RCA. The PUDI may be handed over to the outside of the CASTOR chip without any restriction in time or how often this could be done. The public key part of the consistency key-pair will be delivered to the outside of the CASTOR chip only once in a lifetime of the physical CASTOR.

- RCA will store the PUDI and the public key part of the consistency key-pair. RCA generates a CASTOR root certificate (Type-VT) for the CASTOR, comprising the "Cert.LicenselD". The public key part of the consistency key-pair is not listed in any public available certificate.

- The CASTOR root certificate (Type-VI) is then transferred into the CASTOR chip and is stored therein (in a safe manner) to prevent manipulation of same.

- Furthermore, the CASTOR chip generates its PIO (Private-I O) key (also denoted I O or umbrella key), which is a symmetric key (e.g. a 256 bit AES symmetric key) used for encrypted data read/write operations ("umbrella encryption") through the I/O-interface to CASTOR chip-external memory. The PIO key may be generated as part of the on-chip key and identification generation process but may also be generated (or destroyed) by the CASTOR chip later within a setup process (e.g. triggered by the user).

The user setup process may for example also allow the user to decide whether his/her CASTOR should be operated more secure or with more recovery options in case of a CASTOR chip defect. (Please note, this user setup process is not identical to the validation initialization procedure described above, which is only executed once in a CASTOR lifetime at the RCA site). If the user decides for a more secure operation, the PIO key will never be exposed outside the CASTOR. In case of a CASTOR defect it won't be possible to recover electronic tokes and all other encrypted data of the transaction system having been subject to the umbrella encryption and being stored outside the CASTOR.

In case the user has chosen the operation with more recovery options, an encrypted copy of the PIO key will be stored in the external storage. The storage of that specific PIO is done WITHOUT UMBRELLA PROTECTON to allow a later recovery of same. This storage of the encrypted PIO key is the only exception to the "on-the-fly" umbrella protection, which isn't effective herein. The PIO key is encrypted by using the following scheme:

1. The CASTOR uses the RCA's public key for encryption purposes (K _D;R cA:TYPE-vi,pub) to encrypt the PIO key (even while breaking the naming convention as this key formally is marked to be of type decryption key). The RCA's public key used for the encryption is comprised in the CASTOR root certificate (Type-VI certificate) particularly for recovery purposes and is the same for all

CASTORs. This encryption makes it impossible for any third party to recover the PIO key. 2. The CASTOR then uses the secret key part of its consistency key-pair (K _S: C _A STO _R :CO _N , _PI V) to encrypt the result of the previous encryption process (i.e. the encrypted PIO key). This encryption with the secret key part of its consistency key-pair essentially proves the PIO key to be the specific CASTOR's one. The public key part of the CASTORs consistency key-pair is known to the RCA from the on-chip key and identification generation process.

3. The CASTOR then uses another RCA's public key for signing purposes ( s _:R cA:TYPE-vi _)P ub) to sign the previously twice-encrypted PIO key (see steps 1 and 2). This RCA's public key for signing purposes is also comprised in the CASTOR root certificate (Type- VI) for recovery purposes, and is the same for all CASTORs. This fixes the previously done encryption process and makes it impossible to disturb the security process for any third party.

In case the CASTOR chip is defective while the external memory remains intact (which may be highly probable if using a RAID-1 storage concept) the electronic tokens and the other transaction related data are stored encrypted by the PIO key in the memory ("the umbrella protection") together with the PIO key encrypted using the above procedure. The RCA may recover the electronic tokens and the transaction system related data for a user by recovering the PIO key from the memory and decrypting same (in case the signature can be validated) and then decrypt the electronic tokens and transaction system related data using the recovered PIO key - however, only if the user agreed to choose the operation mode with a recovery operation prior the failure incident.

1.4.19 Data Object Structures

In the following exemplary implementations of several data objects, including the various certificates and keys referred to herein, used within the transaction system are shown in further detail. It should be apparent that the structure of the data objects is only exemplary and the exact structure of the data objects may depend on the intended application of the transaction system.

1.4.19.1 Keys used in the Transaction System This section will provide an exemplary overview on the different keys for encryption and signing within the transaction system. Please note that the overview is only representing one exemplary embodiment, which keys should be used for encryption and signing, but also other key rings than specified be used may be used in a transaction system. Keys used within the transaction system may be distinguished between their category, their generating instance, and their place of action. The grouping criterion is their affiliation to the following four categories:

- Public key rings in certificates for verifying signatures or for DLC-based key agreement,

- Private key rings for signing purposes, secret signature checking or ID evidences,

- Session key generation, mainly used for the creation of the VPN/VPC tunnel, - Other special keys, e.g. internally used within the CASTOR, e.g. for trusted bootstrapping using TRUSTLETs.

Key names are constructed by the notation shown in the following Table 34:

Table 34: Keys and their meaning used within this document.

"A" can be of {Signature, Εηα,-,,ίοη, Decryption} - "B" is the affected (controlled) trust party, e.g. an EA, RCA, CA, eMint or CASTOR. "X" is the type code or use case, e.g. the certificate type, "e" means an ephemeral key part, "s" means a static key part, "pub" means the public key part of a public key-pair, "prv" means the private key part of a public key-pair.

1.4.19.1.1 Private Key Rings

This section provides an overview on the private key parts of particular public key-pairs. They are not distributed and kept secret by the owning device or organization. All keys of this type from one instance form the internal key ring. Table 35 shows an overview on the different entities of the PKI infrastructure of the transaction system as shown in Figure 2 and the respective private key parts used by same for the different tasks. Please note that the simplified PKI infrastructure of Figure 3 could be simply implemented by logical collecting and assigning all keys from EA, RCA, CA, and eMint as de icted in Figure 2 to the single GA of the simplified PKI infrastructure of Figure 3.

The following tables provide a better overview on the use of the different private keys to be used by the different entities in the PKI infrastructure. The EA uses the following private keys listed in Table 36.

Table 37: Private key parts of a PK pair assigned to the RCA. The CAs in the PKI infrastructure as depicted in Figure 2 use their private keys according to the following Table 38.

Table 38: Private key parts of a PK pair assigned to a CA. The issuing authorities (eMints) in the PKI infrastructure as depicted in Figure 2 use their private keys as shown in Table 39.

Table 40: Private key parts of a PK pair assigned to an eWallet. Public Key Rings

This section provides an overview of the public key parts of particular public key-pairs. They are distributed as key elements within the certificates. Table 41 shows an overview on the different entities of the PKI infrastructure of the transaction system as shown in Figure 2 and the respective private key parts used by same for different tasks. Please note that the simplified PKI infrastructure of Figure 3 could be implemented by logical collecting and assigning all keys from EA, RCA, CA, and int as de icted in Figure 2 to the single GA of the simplified PKI infrastructure of Figure 3.

Ta e : Overview about the ent t es o t e pu c ey ngs. The EA in the PKI infrastructure as depicted in Figure 2 uses its public keys as shown in Table 42.

Key name Where to find Purpose

KQ Cert. T pe-VI static key part for DLC-based key exchange/agreement management.

Table 42: Public key parts of a PK pair assigned to the EA organization.

The RCA in the PKI infrastructure as depicted in Figure 2 use its public keys as shown in Table 43.

The CAs in the PKI infrastructure as depicted in Figure 2 use their public keys as shown in Table 44.

Table 44: Public key parts of a PK pair assigned to a CA. The issuing authorities in the PKI infrastructure as depicted in Figure 2 use their public keys as shown in Table 45.

Table 45: Public key parts of a PK pair assigned to an eMint.

The CASTORs in the PKI infrastructure as depicted in Figure 2 use their public keys as shown in Table 46.

Table 46: Public key parts of a PK pair assigned to an eWallet.

1.4.19.1.3 Session Keys for VPN/VPC

Session keys are generated within a key generation process for a single run of the off-line transaction protocol, using the ephemeral public PK parts KQ.^ and their ephemeral private PK partner parts KD _E:X , and their static relatives. Table 47 shows their (static partner key parts) usage for all possible entity-to- entity communication possibilities within the transaction system, assuming the PKI infrastructure as shown in Figure 2. Please note, for the simplified PKI infrastructure of Figure 3 all keys not needed may be omitted, thus using only four between the GA (e.g. in the position of the RCA) and a CASTOR.

Keys marked Italic in Table 47, are the private static key parts for a DLC-based key exchange/agreement scheme; the other keys are their corresponding public static partner parts. Every communication party/entity may use its own static key-pair to establish the VPN/VPC protected communication link, so that there are a total of four static keys in use for the VPN/VPC.

Since there is no need for the EA entity to establish a VPN VPC protected communication link with itself, the respective keys are omitted in the table above. The same is true for the RCA in case there is only one. In cases where this is not true, the currently missing four keys in Table 47 between two RCAs need to be associated.

The DLC-based key exchange/agreement schemes in the transaction system are generating and exchanging sufficient information between the two protocol parties, so that the protocol parties can share these secrets without any other third party in a MITMA secure way. Note that the lifetime for these session keys is limited to the context of a single protocol-run. The teleportation protocol uses four different (nameless) symmetrical link session keys to operate the VPN/VPC tunnel:

- a session encryption decryption (symmetrical) key for messages initiated by authority/party one,

- a session encryption/decryption (symmetrical) key for messages initiated by authority/party two,

- a session authentication (symmetrical) key for messages initiated by authority/party one, and

- a session authentication (symmetrical) key for messages initiated by authority/party two.

1.4.19.2 Certificates and CRLs

1.4.19.2.1 Personal User Certificate (Type-I)

Every CASTOR owns a unique user certificate of the Type-I or Type-II style. They are issued by local CAs. Without such valid certificate, CASTORs are unable to execute the off-line transaction protocol successfully. An exemplary personal user certificate of Type-I is shown in Table 48.

Name Name of a user certificate, max. 20 characters (160 bit)

Type CERT-TYPE-I [certificate for checking the signature identity of a CASTOR] (8 bit)

Version Version number [16-bit unsigned integer describing the data object version]

YYMMDDHHMMSSZ [UTCTIME as Date & Time stamp for the time of

DTStamp

generation] (64 bit)

CertificateFormatVersion Version number 3

CertificateSerialNumber Serial number [128-bit size]

Cert.

X509. Keys.

http://www.UserSign.com [WebSiteAddress, 64 Chars,

IssuerX500Name. URL=

ISO 646 String] Info@UserSign.com [EmailAddress, 64 Chars, ISO 646

Email=

String]

DNS= UserSign.com.root.user [DNS Network name] (64*8 bit)

IP= 2001 :0db8:85a3:08d3:1319:8a2e:0370:7334 [IPv6]

C= US [ISO 3166 country code] (5*8 bit)

SP= Ohio, Lorain County [State or Province] (16 bit) o= UserSign Trust Network Ltd. [Organization, 64 Chars,

ISO 646 String]

ou= UserSign Headquarter [OrganizationalUnitName, 64

Chars, ISO 646 String]

Secretary of Certification Authorities [CommonName, 64

CN=

Chars, ISO 646 String]

L= 2075 Grafton [Locality, 64 Chars, ISO 646 String]

South Avon Belden Road 13 [StreetAddress, 64 Chars,

ST=

ISO 646 String]

notBefore YYMMDDHHMMSSZ [UTCTIME] (64 bit)

ValidityPeriod.

notAfter YYMMDDHHMMSSZ [UTCTIME] (64 bit)

Exmpl.: UserSign Certification Authority (CA) Local Issuing

IssuerUniqueldentifier

Service valid for only a single (DE) country (128 bit)

Exmpl.: Owner of this certificate is a CASTOR identified under

SubjectUniqueldentifier

CERT-TYPE- VI.LicenselD

ASYMCIPHER 128-bit, Public Key Block Cipher Methods

COMP 128-bit, Lossless Compression Payload Methods

DIGEST 128-bit, One Way Message Digest and Cryptographic Hash Methods

DIGSIG 128-bit, Message Identification and Authentication Signature Methods

CFV. FCS 128-bit, Integrity Frame Checking Sequence Methods

(1280 128-bit, Interactive Authentic Key Management and Exchange bit) KEYDISTRI

Methods

MACSIG 128-bit, Message Authentication Code Methods

PAD 128-bit, Padding Methods

RAND 128-bit, Random Bit Generation Methods

SYMCIPHER 128-bit, Secret Key Block Cipher with Mode of Operation Methods

Version 32-bit Identifier for the Domain Parameter Table

572-bits, field size, may be either an odd prime p or 2 ^m , m is prime

FR 572-bits, basis used

ECCDornainParamTable. 576-bits, field element that define the curve equation

576-bits, field element that define the curve equation

SEED 160*2-bits, optimal string for randomly generated curve

572*2*2-bits, generating point, (XG, VG) of prime order on the curve n 572-bits, order of the point G

32-bits, cofactor, equal to the order of the curve divided h

by n

AlgorithmID CFV-Definition (128 bit)

Signature.

DigestKey Exmpl.: 7453 FDC5 AE52 063D AC4F ... (512 bit)

Table 48: Example of a CA issued personal user certificate of type CERT-TYPE-I. 1.4.19.2.2 CRL for Personal User Certificates (Type-I)

This style of CRL-TYPE-I Certificate Revocation List is released from the respective CA for everybody. This revocation mechanism is used to invalidate previously issued personal Type-I user certificates. The effect of this revocation is that the (single) CASTOR using that previously released user certificate will be unable to transfer eCoins anymore. The user of a CASTOR has to acquire a new user certificate, in case his/her user certificate is revoked. An exemplary CRL for personal user certificates of T e-I is shown in Table 49.

Today YYMMDDHHMMSSZ [UTCTIME]

UpdateTimes.

NextTime YYMMDDHHMMSSZ [UTCTIME]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

... ...

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

AlgorithmID CFV-Defmition

Signature.

DigestKey Exmpl.: 7453 FDC5 AE52 063D AC4F ...

Table 49: Example of a CA issued revocation list of type CRL-TYPE-I.

1.4.19.2.3 Commercial User Certificate (Type-II)

Every CASTOR owns a unique user certificate of the Type-I or Type-II style. They are issued by local CAs. Without such valid certificate, CASTORs are unable to execute the off-line transaction protocol successfully. An exemplary personal user certificate of Type-II is shown in Table 50.

Name Name of a user certificate, max. 20 characters (160 bit)

Type CERT-TYPE-II [certificate for checking the signature identity of a Castor] (8 bit)

Version Version number 1 [16-bit unsigned integer describing the data object version]

YYMMDDHHMMSSZ [UTCTIME as Date & Time stamp for the time of

DTStamp

generation] (64 bit)

CertificateFormatVersion Version number 3

CertificateSerialNumber Serial number [128-bit size]

Keys

http://www.UserSign.com [WebSiteAddress, 64 Chars,

URL=

Cert. ISO 646 String]

Info@UserSign.com [EmailAddress, 64 Chars, ISO 646

Email=

String]

X509.

UserSign.com.root.user [DNS Network name] (64*8

DNS=

bit)

IP= 2001:0db8:85a3:08d3: 1319:8a2e:0370:7334 [IPv6] c= US [ISO 3166 country code] (5*8 bit)

SP= Ohio, Lorain County [State or Province] (16 bit)

IssuerX500Name.

o= UserSign Trust Network Ltd. [Organization, 64 Chars,

ISO 646 String]

ou= UserSign Headquarter [OrganizationalUnitName, 64

Chars, ISO 646 String]

Secretary of Certification Authorities [CommonName,

CN=

64 Chars, ISO 646 String]

2075 Grafton [Locality, 64 Chars, ISO 646 String]

South Avon Belden Road 13 [StreetAddress, 64 Chars,

ST=

ISO 646 String]

notBefore YYMMDDHHMMSSZ [UTCTIME] (64 bit)

ValidityPeriod.

notAfter YYMMDDHHMMSSZ [UTCTIME] (64 bit) Exmpl.: UserSign Certification Authority (CA) Local Issuing

IssuerUniqueldentifier

Service valid for only a single (DE) country (128 bit)

Exmpl.: Owner of this certificate is a CASTOR identified

Subj ectUniqueldentifier

under CERT-TYPE- VI.LicenselD

ASYMCIPHER 128-bit, Public Key Block Cipher Methods

COMP 128-bit, Lossless Compression Payload Methods

DIGEST 128-bit, One Way Message Digest and Cryptographic Hash Methods

128-bit, Message Identification and Authentication Signature

DIGSIG

Methods

CFV. FCS 128-bit, Integrity Frame Checking Sequence Methods

(1280

bits) 128-bit, Interactive Authentic Key Management and Exchange

KEYDISTRI

Methods

MACSIG 128-bit, Message Authentication Code Methods

PAD 128-bit, Padding Methods

RAND 128-bit, Random Bit Generation Methods

SYMCIPHER 128-bit, Secret Key Block Cipher with Mode of Operation Methods

AlgorithmID CFV-Definition (64 bit)

Signature.

DigestKey Exmpl.: 7453 FDC5 AE52 063D AC4F ... (512 bit)

Table 50: Example of a CA issued commercial user certificate of type CERT-TYPE-II.

1.4.19.2.4 CRL for Commercial User Certificates (Type-H)

This style of CRL-ΤΥΡΕ-Π Certificate Revocation List is released from the respective CA for everybody. This revocation mechanism is used to invalidate previously issued commercial Type-II user certificates. The effect of this revocation is that the (single) CASTOR using that previously released user-certificate will be unable to transfer eCoins anymore. The user of a CASTOR has to acquire a new user certificate in case his/her user certificate is revoked. An exemplary CRL for commercial user certificates of Type-II is shown in Table 51.

Name Name of a CRL file, max. 20 characters

Type CRL-TYPE-II [revocation list for CERT-TYPE-II]

Version Version number [16-bit unsigned integer describing the data object version]

YYMMDDHHMMSSZ [UTCTIME as Date & Time stamp for the time of

DTStamp

generation]

CRLFormatVersion Version number 3

CRLSerialNumber Serial number [128-bit size]

http://www.UserSign.com [WebSiteAddress, 64

URL=

Chars, ISO 646 String]

Info@UserSign.com [EmailAddress, 64 Chars, ISO

Email=

646 String]

DNS= UserSign.com.root.user [DNS Network name]

IP= 2001:0db8:85a3:08d3:1319:8a2e:0370:7334 [IPv6] c= US [ISO 3166 country code]

SP= Ohio, Lorain County [State or Province]

IssuerX500Name.

U rganization, 64 Chars,

CRL. 0= serSign Trust Network Ltd. [O

ISO 646 String]

ou= UserSign Headquarter [OrganizationalUnitName, 64 Chars, ISO 646 String]

X509.

Secretary of Certification Authorities [CommonName,

CN=

64 Chars, ISO 646 String]

L= 2075 Grafton [Locality, 64 Chars, ISO 646 String]

South Avon Belden Road 13 [StreetAddress, 64 Chars,

ST=

ISO 646 String]

Today YYMMDDHHMMSSZ [UTCTIME]

UpdateTimes.

NextTime YYMMDDHHMMSSZ [UTCTIME]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate] Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

AlgorithmID CFV-Definition

Signature.

DigestKey Exmpl.: 7453 FDC5 AE52 063D AC4F ...

Table 51: Example of a CA issued revocation list of type CRL-TYPE-II. 1.4.19.2.5 CA Certificate (Type-Ill)

This style of CERT-TYPE-III is released from RCA to every valid CA. Therefore, every authorized CA owns a unique CA certificate. Without such valid certificate, CASTORs are unable to identify the selected CA as being valid for the eCash system. It is used for certifying user certificates of Type-I and Type-II by the CAs. An exemplary CA certificate is shown in Table 52.

Name Name of a CA certificate, max. 20 characters

Type CERT-TYPE-III [certificate for checking the signature identity of this CA]

Version Version number [16-bit unsigned integer describing the data object version]

YYMMDDHHMMSSZ [UTCTIME as Date & Time stamp for the time of

DTStamp

generation]

ProductID 128-bit product identifier (here eCash) with version and revision number

128-bit protocol identifier (here teleportation protocol) with version and revision

ProtocolID

number

LicenselD 128-bit license identifier (here eCash licensee)

CertificateFormatVersion Version number 3

CertificateSerialNumber Serial number [128-bit size]

Cert.

X509.

http://www.CASign.org [WebSiteAddress, 64 Chars,

URL=

ISO 646 String]

Info@CASign.org [EmailAddress, 64 Chars, ISO 646

Email=

String]

IssuerX500Name. DNS= CASign.org.root.user [DNS Network name]

IP= 2001:0db8:85a3:08d3:1319:8a2e:0370:7334 [IPv6]

C= DE [ISO 3166 country code]

SP= Schleswig-Holstein [State or Province] o= CASign Ltd. [Organization, 64 Chars, ISO 646 String]

CASign Headquarter [OrganizationalUnitName, 64

OU=

Chars, ISO 646 String]

Secretary of CASign Affaires [CommonName, 64

CN=

Chars, ISO 646 String]

L= 24118 Kiel [Locality, 64 Chars, ISO 646 String]

Hermann-Rodewald-StraBe 3 [StreetAddress, 64 Chars,

ST=

ISO 646 String]

notBefore YYMMDDHHMMSSZ [UTCTIME]

ValidityPeriod.

notAfter YYMMDDHHMMSSZ [UTCTIME]

Exmpl.: CASign Root Certification Authority (RCA)

IssuerUniqueldentifier

Central Issuing Service valid for all countries (128 bit)

Exmpl.: CASign Certification Authority (CA) Local

Subj ectUniqueldentifier Issuing Service valid for only a single (DE) country

(128 bit)

AlgorithmID CFV-Definition

Signature.

DigestKey Exmpl.: 7453 FDC5 AE52 063D AC4F

Table 52: Example of a CA issued certificate of type CERT-ΤΥΡΕ-ΙΠ. 1.4.19.2.6 CRL for CA Certificates (Type-Ill)

This style of CRL-ΤΥΡΕ-ΙΠ Certificate Revocation List is released from the RCA for everybody. This revocation mechanism is used to invalidate previously issued CA certificates. The effect of this revocation is that all certificates issued from this CA institution will be invalidated. All CASTORs operated beneath a Type-I or Type-Π user certificate released by a CA, the CA of which is revoked, will be unable to transfer eCoins anymore and have to acquire new users certificate. A CRL for CA certificate is shown in Table 53. Name Name of a CRL file, max. 20 characters

Type CRL-TYPE-in [revocation list for CERT-TYPE-III]

Version Version number [16-bit unsigned integer describing the data object version]

YYMMDDHHMMSSZ [UTCTIME as Date & Time stamp for the time of

DTStamp

generation]

CRLFormatVersion Version number 3

CRLSerialNumber Serial number [128-bit size]

CRL.

X509.

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

AlgorithmID CFV-Definition

Signature.

DigestKey Exmpl.: 7453 FDC5 AE52 063D AC4F

Table 53: Example of an RCA issued revocation list of type CRL-ΤΥΡΕ-ΠΙ. 1.4.19.2.7 eMint Certificate (Type-IV)

This style of CERT-TYPE-IV is released from RCA to every valid eMint. Therefore, every authorized eMint organization owns a unique eMint certificate. Without such valid certificate, CASTORs are unable to identify the selected eMint as being valid for the eCash system. The eMint certificate is used for checking eMint-issued CERT-TYPE- VII certificates and the list of currency editions. An exemplary eMint certificate is shown in Table 54.

Name Name of an eMint certificate, max. 20 characters

Type CERT-TYPE-IV [certificate for checking Type-VII CERTs of this eMint]

Version Version number [16-bit unsigned integer describing the data object version]

YYMMDDHHMMSSZ [UTCTIME as Date & Time stamp for the time of

DTStamp

generation]

ProductID 128-bit product identifier (here eCash) with version and revision number

ProtocolID 128-bit protocol identifier (here teleportation) with version and revision number

LicenselD 128-bit license identifier (here eCash licensee)

Cert.

http://www.eMint.org [WebSiteAddress, 64 Chars, ISO

URL=

646 String]

X509. Info@eMint.org [EmailAddress, 64 Chars, ISO 646

Email=

String]

DNS= eMint.org.root.user [DNS Network name]

Π ^» = 2001:0db8:85a3:08d3:1319:8a2e:0370:7334 [IPv6]

C= DE [ISO 3166 country code]

IssuerX500Name. SP= Schleswig-Holstein [State or Province]

0= eMint Ltd. [Organization, 64 Chars, ISO 646 String] eMint Headquarter [OrganizationalUnitName, 64 Chars,

OU=

ISO 646 String]

Secretary of eMint Affaires [CommonName, 64 Chars,

CN=

ISO 646 String]

L= 24118 Kiel [Locality, 64 Chars, ISO 646 String]

ST= Hermann-Rodewald-StraBe 3 [StreetAddress, 64 Chars, ISO 646 String]

notBefore YYMMDDHHMMSSZ [UTCTTME]

ValidityPeriod.

notAfter YYMMDDHHMMSSZ [UTCTIME]

Exmpl.: eMint Root Certification Authority (RCA) Central

IssuerUniqueldentifier

Issuing Service valid for all countries (128 bit)

Exmpl.: Cash eMinting Authority (eMint) Local Issuing

SubjectUniqueldentifier

Service (128 bit)

AlgorithmlD CFV-Definition

Signature.

DigestKey Exmpl.: 7453 FDC5 AE52 063D AC4F

Table 54: Example of an RCA issued eMint certificate of type CERT-TYPE-IV.

1.4.19.2.8 CRL for eMint Certificates (Type-IV)

This style of CRL-TYPE-IV Certificate Revocation List is released from the RCA for everybody. This revocation mechanism is used to invalidate previously issued CERT-TYPE-IV certificates. This revocation causes all certificates and signed objects (eCoins) issued from this eMint institution to get invalidated. eCoins minted and released by this eMint institution cannot be transferred any more. An exemplary CRL for eMint certificate is shown in Table 55.

Name Name of a CRL file. max. 20 characters

Type CRL-TYPE-IV [revocation list for CERT-TYPE-IV]

Version Version number [16-bit unsigned integer describing the data object version]

YYMMDDHHMMSSZ [UTCTIME as Date & Time stamp for the time of

DTStamp

generation]

CRLFormatVersion Version number 3

CRLSerialNumber Serial number [128-bit size]

CRL.

X509.

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

AlgorithmID CFV-Definition

Signature.

DigestKey Exmpl: 7453 FDC5 AE52 063D AC4F

Table 55: Example of an RCA issued revocation list of type CRL-TYPE-IV. 1.4.19.2.9 CASTOR Product Certificate (Type-V)

This style of CERT-TYPE-V is released from RCA to every valid CASTOR firmware image (the location of this certificate is contained within the image). It is the validation at the eCash system application level. Therefore, every authorized CASTOR owns a unique CASTOR product certificate. Without such valid certificate, CASTORs are unable to identify themselves as valid and trustable members of the eCash system. The CASTOR Product Certificate is used for checking and proving a CASTOR's authentic unique identity. The CFVs in this certificate are reflecting the firmware capabilities. An exemplary embodiment of a CASTOR product certificate is shown in Table 56.

Name Name of a CASTOR firmware certificate, max. 20 characters

CERT-TYPE-V [certificate for checking the firmware signature identity of an

Type

CASTOR]

Version Version number [16-bit unsigned integer describing the data object version]

YYMMDDHHMMSSZ [UTCTIME as Date & Time stamp for the time of

DTStamp

generation]

ProductID 128-bit product identifier (here eCash) with version and revision number

ProtocolID 128-bit protocol identifier (here teleportation) with version and revision number

LicenselD 128-bit license identifier (here eCash licensee)

CertificateFormatVersion Version number 3

CertificateSerialNumber Serial number [128-bit size]

AlgorithmID CFV-Definition

PublicKey key part for authentication purposes.

AlgorithmID CFV-Definition

PublicKey key part for decryption purposes.

AlgorithmID CFV-Definition (128 bit)

¾:FW:Tl-API,pub

PublicKey Trustled-Boot-Phase: API Check

Cert. AlgorithmID CFV-Definition

PublicKey Trustled-Boot-Phase: IPL Check

AlgorithmID CFV-Definition

PublicKey Trustled-Boot-Phase: License Check

X509. AlgorithmID CFV-Definition

Keys. PublicKey Trustled-Boot-Phase: OS-Check

AlgorithmID CFV-Definition

PublicKey Trustled-Boot-Phase: App Check

AlgorithmID CFV-Definition

PublicKey Trustled-Boot-Phase: Tele Check

AlgorithmID CFV-Definition

PublicKey Trustled-Boot-Phase: Weak Check

AlgorithmID CFV-Definition

PublicKey Trustled-Boot-Phase: Time Check

AlgorithmID CFV-Definition

PublicKey Trustled-Boot-Phase: Ink Check

K.D:FW:Tl-AFFI,pub AlgorithmID CFV-Definition PublicKey Trustled-Boot-Phase: Affi Check

AlgorithmlD CFV-Definition

PublicKey Trustled-Boot-Phase: PUF Check

AlgorithmlD CFV-Definition (128 bit)

PublicKey Trustled-Boot-Phase: API Check

AlgorithmlD CFV-Definition

PublicKey Trustled-Boot-Phase: IPL Check

AlgorithmlD CFV-Definition

PublicKey Trustled-Boot-Phase: License Check

AlgorithmlD CFV-Definition

PublicKey Trustled-Boot-Phase: OS-Check

AlgorithmlD CFV-Definition

PublicKey Trustled-Boot-Phase: App Check

AlgorithmlD CFV-Definition

PublicKey Trustled-Boot-Phase: Tele Check

AlgorithmlD CFV-Definition

PublicKey Trustled-Boot-Phase: Weak Check

AlgorithmlD CFV-Definition

PublicKey Trustled-Boot-Phase: Time Check

AlgorithmlD CFV-Definition

PublicKey Trustled-Boot-Phase: Init Check

AlgorithmlD CFV-Definition

PublicKey Trustled-Boot-Phase: Affi Check

AlgorithmlD CFV-Definition

PublicKey Trustled-Boot-Phase: PUF Check

AlgorithmlD CFV-Definition

KQs:RCA A public static PK part for (hybrid) DLC key

PublicKey

exchange/agreement management schemes

RootDirectoryPtr

64 Chars, ISO 646 String]

http://www.eCash.org [WebSiteAddress, 64 Chars,

URL=

ISO 646 String]

Info@eCash.org [EmailAddress, 64 Chars, ISO 646

Email=

String]

DNS= eCash.org.root.user [DNS Network name]

IP= 2001:Odb8:85a3:08d3:1319:8a2e:0370:7334 [IPv6]

C= DE [ISO 3166 country code]

SP= Schleswig-Holstein [State or Province]

IssuerX500Name.

0= eCash Ltd. [Organization, 64 Chars, ISO 646 String] eCash Headquarter [OrganizationalUnitName, 64

OU=

Chars, ISO 646 String]

Secretary of eCash Affaires [CommonName, 64

CN=

Chars, ISO 646 String]

L= 24118 Kiel [Locality, 64 Chars, ISO 646 String]

Hermann-Rodewald-StraBe 3 [StreetAddress, 64

ST=

Chars, ISO 646 String] notBefore YYMMDDHHMMSSZ [UTCTIME]

ValidityPeriod.

notAfter YYMMDDHHMMSSZ [UTCTIME]

Exmpl.: eCash Root Certification Authority (RCA) Central

IssuerUniqueldentifier

Issuing Service valid for all countries (128 bit)

Exmpl.: Owner of this certificate is a CASTOR identified

SubjectUniqueldentifier

under CERT-TYPE- VI.LicenselD

CFV

Version 32-bit Identifier for the Domain Parameter Table

572-bits, field size, may be either an odd prime p or 2 ^m , m is prime

FR 572-bits, basis used

576-bits, field element that define the curve equation

576-bits, field element that define the curve equation

ECCDomainParamTable.

SEED 160*2-bits, optimal string for randomly generated curve

572*2*2-bits, generating point, (x _a yo) of prime order on

G

the curve

572-bits, order of the point G

32-bits, cofactor, equal to the order of the curve divided by n

AlgorithmID CFV-Definition

Signature.

DigestKey Exmpl.: 7453 FDC5 AE52 063D AC4F

Table 56: Examp ^' e of an RCA issued CASTOR product firmware certificate of type CERT-TYPE- V.

1.4.19.2.10 CRL for CASTOR Product Certificates (Type-V)

This style of CRL-TYPE-V Certificate Revocation List is released from the RCA for everybody. This revocation mechanism is used to invalidate previously issued CASTOR product certificates of Type V. The consequence of such revocation affects all CASTORs referenced in such CRL resulting in their deactivation. An exemplary CRL for CASTOR product certificates of Type-V is shown in Table 57. Name Name of a CRL file, max. 20 characters

Type CRL-TYPE-V [revocation list for CERT-TYPE- V]

Version Version number [16-bit unsigned integer describing the data object version]

YYMMDDHHMMSSZ [UTCTIME as Date & Time stamp for the time of

DTStamp

generation]

CRLFormatVersion Version number 3

CRLSerialNumber Serial number [128-bit size]

CRL

X509.

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

Serial number [128-bit size, reference to the revoked

RevokedCERTSerialNumber

certificate]

AlgorithmID CFV-Defmition

Signature.

DigestKey Exmpl.: 7453 FDC5 AE52 063D AC4F

Table 57: Examp e of an RCA issued revocation list of type CRL-TYPE-V. 1.4.19.2.11 CASTOR Root Certificate (Type- VI)

This style of CERT-TYPE-VI is released from the RCA during the hardware serialization, validation and certification (see section "Crypto-Initialization of the Tamper-Protected Hardware Module (CASTOR)"). The CASTOR root (hardware) certificate is used for checking and proving a CASTOR authentic identity. The CFVs in this certificate are reflecting the hardware capabilities of the CASTOR. An exemplary CASTOR root certificate of Type- VI is shown in Table 58.

CertificateFormatVersion Version number 3 (8 bit)

CernficateSerialNumber Serial number [128-bit size]

Keys.

Cert.

X509. http://www.eCash.org [WebSiteAddress, 64 Chars, ISO

URL=

646 String]

Info@eCash.org [EmailAddress, 64 Chars, ISO 646

Email=

String]

DNS= eCash.org.root.user [DNS Network name] (64*8 bit)

2001:0db8:85a3:08d3: 1319:8a2e:0370:7334 [IPv6] (128

IP=

bit)

IssuerX500Name. C= DE [ISO 3166 country code] (5*8 bit)

SP= Schleswig-Holstein [State or Province] (16 bit)

0= eCash Ltd. [Organization, 64 Chars, ISO 646 String] eCash Headquarter [OrganizationalUnitName, 64 Chars,

OU=

ISO 646 String]

Secretary of eCash Affaires [CommonName, 64 Chars,

CN=

ISO 646 String]

L= 24118 Kiel [Locality, 64 Chars, ISO 646 String] Hermann-Rodewald-StraBe 3 [StreetAddress, 64 Chars,

ST=

ISO 646 String]

notBefore YYMMDDHHMMSSZ [UTCTIME] (64 bit)

ValidityPeriod.

notAfter YYMMDDHHMMSSZ [UTCTIME] (64 bit)

Exmpl.: eCash Root Certification Authority (RCA) Central

IssuerUniqueldentifier

Issuing Service valid for all countries (128 bit)

Exmpl: The owner of this CASTOR: CERT-TYPE-

Subj ectUniqueldentifier

VI.LicenselD

ASYMCIPHER 128-bit, Public Key Block Cipher Methods

COMP 128-bit, Lossless Compression Payload Methods

128-bit, One Way Message Digest and Cryptographic Hash

DIGEST

Methods

128-bit, Message Identification and Authentication Signature

DIGSIG

Methods

CFV. FCS 128-bit, Integrity Frame Checking Sequence Methods

128-bit, Interactive Authentic Key Management and Exchange

KEYDISTRI

Methods

MACSIG 128-bit, Message Authentication Code Methods

PAD 128-bit, Padding Methods

RAND 128-bit, Random Bit Generation Methods

SYMCIPHER 128-bit, Secret Key Block Cipher with Mode of Operation Methods

Brand Max. 20 characters (20x8 bit)

ProductLine Max. 4 characters (4x8 bit)

Slotl Max. 2 characters (2x8 bit)

Slot2 Max. 2 characters (2x8 bit)

Slot3 Max. 2 characters (2x8 bit)

Slot4 Max. 2 characters (2x8 bit)

FamilyCode.

Slot5 Max. 2 characters (2x8 bit)

Slot6 Max. 2 characters (2x8 bit)

Slot7 Max. 2 characters (2x8 bit)

Slot8 Max. 2 characters (2x8 bit)

Info. Creation 64-bits, when (Date, Time) was the DEVICE created

Version/Revision 64-bits, version and revision code

Unit. 64-bits, when (Date, Time) will the DEVICE be

Expiry

expired

Model 32-bits, identity info about the DEVICE model code

32-bits id about the DEVICE manufacturer (not the

Manufacturer

CASTOR chip)

ReleaseCode Release identification as version/revision code (64 bit)

SerialCode Identify uniquely the DEVICE (128 bit)

128-bits 'DEVICE License-Code', identify uniquely

CLC

the licensee of the product

64-bits, when (Date, Time) was the CASTOR chip

Creation

created

CASTOR. Version/Revision 64-bits, version and revision code

32-bits, identity info about the CASTOR chip model

Model

code Manufacturer 32-bits id about the silicon chip manufacturer

ReleaseCode Release identification as version revision code

SerialCode Identify uniquely the CASTOR- SoC-Chip (64 bit)

128-bits 'CASTOR License-Code', identify uniquely

CLC

the licensee of the SoC (128 bit)

Creation 64-bits, when (Date, Time) was the PCB created

Version Revision 64-bits, version and revision code

PCB. Model 32-bits, identity info about the PCB model code

Manufacturer 32-bits id about the PCB manufacturer

ReleaseCode Release identification as version/revision code (64 bit)

128-bits [IEEE 48-bit or Registered Extended],

Bluetooth

Organizationally Unique Identifier (OUI)

128-bits [ΓΕΕΕ 48-bit or Registered Extended],

WLAN WiFi

Organizationally Unique Identifier (OUI)

128-bits [IEEE 48-bit or Registered Extended],

NIC. RFID NFC

Organizationally Unique Identifier (OUI)

128-bits [IEEE 48-bit or Registered Extended],

USB

Organizationally Unique Identifier (OUI)

128-bits [IEEE 48-bit or Registered Extended],

Ethernet

Organizationally Unique Identifier (OUT)

Version 32-bit Identifier for the Domain Parameter Table

572-bits, field size, may be either an odd prime p or 2 ^m , m is prime

FR 572-bits, basis used

576-bits, field element that define the curve equation

576-bits, field element that define the curve equation

ECCDomainParamTable. 160*2-bits, optimal string for randomly generated

SEED

curve

572*2*2-bits, generating point, (x _a y _G ) of prime order

G

on the curve

572-bits, order of the point G

32-bits, cofactor, equal to the order of the curve divided by n

AlgorithmID CFV-Definition (128 bit)

Signature.

DigestKey Exmpl.: 7453 FDC5 AE52 063D AC4F

Table 58: Example of an RCA issued CASTOR Root certificate of type CERT-TYPE- VI.

Please note, there is no CRL for CASTOR root certificates foreseen in the transaction system, and the firmware of each CASTOR may even ensure a CRL for CASTOR root certificates (if encountered, e.g. due to an attack) won't be considered. Basically, a CRL revoked a CASTOR root certificate would thereby revoke the RCA's public verification key part Ks _: RCA:TYPE-vi,pub, which is used for validating all certificates in the eCash system. A revocation of this key would render the entire eCash system dysfunctional (kill switch). 1.4.19.2.12 eMint Batch Production Certificate (Type-VH)

Every eMint has at least one or more batch production certificates for each currency (in case there is more than only a single currency), according to the number of issued eCoin batches so far released. These Type- VII certificates have to be present as long as there are still eCoins in the economy referring to them. Revoking a batch production certificate means revoking all eCoins of that batch (making the respective eCoins invalid). The standard method to clear Type- VII certificates no longer needed is to revoke them. Of course, this could only be done after the last eCoin relating to that batch production certificate is cleared or expired. The user initially loads batch production certificates during the currency setup process (by selecting the desired currencies, the respective eMints are identified). The user's eWallet/CASTOR contacts then these eMints and requests all batch production certificates from them with a relationship of the wanted currencies (if there is more than a single currency the user wants to have from a single or from multiple eMint(s)). In case a later update of a batch production certificate is required (e.g. the user selects a new currency, loads new eCoins referring to an unknown (new) Type-Vn certificate, or a transaction partner's eWallet/CASTOR refers to a (new) batch production certificate the user's eWallet/CASTOR is not aware of), the required batch production certificate can be transferred off-line within the off-line transaction protocol or on-line directly from the source eMint. The implementation not to integrate additional fields directly into the eCoin certificate may be advantageous as it allows reducing the size of the eCoin. Alternatively, validity period and the transferability period of an eCoin could be indicated in the certificate as separate fields. This style of self-certified currency certificate is released from an eMint to everybody. Every eMint can issue as many different currencies as desired. For every production-batch of eCoins a new certificate of this type has to be published. This mechanism may be advantageous as it allows implementing an ageing-mechanism for the eCoins' transferability. The eMint will release new production batches of eCoins to replace the old ones in a regular manner. These certificates will be removed at the earliest from the eMint's public data repository after the last referenced eCoin has lost its transferability. Therefore, there may always be several eMint batch production certificates available from every single eMint. An exemplary eMint batch production certificate of Type- VII is shown in Table 59.

Name Name of an eMint batch production-currency-certificate, max. 20 characters

CERT-TYPE- VII-001 [certificate for checking the signature identity of own minted

Type

eCoins; three digit codes how many CERTs there are]

Version Version number [16-bit unsigned integer describing the data object version]

Cert.

YYMMDDHHMMSSZ [UTCTIME as Date & Time stamp for the time of

DTStamp

generation]

Serial. 128-bit serial number of the eMint Root Certificate [CERT-TYPE-IV]

CertificateFormatVersion Version number 3

X509.

CertificateSerialNumber Serial number [128-bit size] AlgorithmID CFV bit-array based definition

Ks:eMint:CuiTList,pub key part for authentication purposes (List

PublicKey

of Currency Editions)

AlgorithmID CFV bit-array based definition

Ks:eMint:TYPE-Vn,pub

PublicKey key part for authentication purposes.

AlgorithmID CFV bit-array based definition

Keys. Ks :eMint:TYPE-Vin,pub key part for authentication purposes

PublicKey

(eCoins)

AlgorithmID CFV bit-array based definition

K.D:eMint:TYPE-VII,pub

PublicKey key part for decryption purposes.

AlgorithmID CFV bit-array based definition

KQ _s:e Mint A public static PK part for (hybrid) DLC

PublicKey key exchange/agreement management schemes

notBefore YYMMDDHHMMSSZ [UTCTIME]

ValidityPeriod.

notAfter YYMMDDHHMMSSZ [UTCTIME]

Exmpl.: eMint Cash eMinting Authority (eMint) Local

IssuerUniqueldentifier

Issuing Service (128 bit)

Exmpl.: eMint Cash eMinting Authority (eMint) Local

Subj ectUniqueldentifier

Issuing Service (128 bit)

Identification of an eCoin batch, max. 20 characters {optional

ID

information}

Batch. CurrencylD Three character code (e.g. EUR)

Yes/No: is this "have to" trust money, legalized from the

LegalTender

government? {optional information} Identification of financial institution internal MSDB, max. 20

CodeDatabase

characters {optional information}

First 128-bit unsigned integer {optional information}

Serial.

Last 128-bit unsigned integer {optional information}

TotalAmount 128-bit unsigned integer {optional information}

YYMMDDHHMMSSZ

FullTransferability [UTCTIME]

ExpirationLifeEnd.

YYMMDDHHMMSSZ

LimitedTransferability

[UTCTIME]

Version 32-bit Identifier for the Domain Parameter Table

ECCDomainParamTable. 572-bits, field size, may be either an odd prime p or 2 ^m , m is prime FR 572-bits, basis used

a 576-bits, field element that define the curve equation b 576-bits, field element that define the curve equation

SEED 160*2-bits, optimal string for randomly generated curve

572*2*2-bits, generating point, (x _G , VG) of prime order

G

on the curve

n 572-bits, order of the point G

32-bits, cofactor, equal to the order of the curve divided h

by n

AlgorithmlD CFV-Definition

Signature.

DigestKey Exmpl.: 7453 FDC5 AE52 063D AC4F ...

Table 59: Example of an eMint issued currency batch-production-certificate of type CERT-TYPE- VII. 1.4.19.2.13 CRL for eMint Batch Production Certificates (Type-VII)

This style of certification revocation list CRL-TYPE-VII is self-released from the respective eMint for everybody. This revocation-mechanism is used to invalidate previously self-issued eMint batch production certificates. There is only a single CRL for eMint batch production certificates per eMint. This revocation causes all eCoins originating from the revoked production-batches get invalidated. All eCoins of that batch will lose their transferability. Such revocation will be a standard procedure for the eMint, to be executed once all eCoins of that batch have lost their transferability over time. An exemplary CRL for eMint batch production certificates is shown in Table 60.

Name Name of a CRL file, max. 20 characters

Type CRL-TYPE-Vn [revocation list for CERT-TYPE- VII]

Version Version number [16-bit unsigned integer describing the data object version]

YYMMDDHHMMSSZ [UTCTIME as Date & Time stamp for the time of

DTStamp

generation]

CRLFormat

Version number 3

Version

CRLSerial Number Serial number [128-bit size]

http://www.eMint.de [WebSiteAddress, 64

URL=

CRL. Chars, ISO 646 String]

Cash@eMint.de [EmailAddress, 64 Chars,

Email=

ISO 646 String]

X509.

eMint.de.rootxustomer [DNS Network

DNS=

name]

IssuerX500 Name.

2001 :0db8:85a3:08d3: 1319:8a2e:0370:7334

IP=

[IPv6]

DE [ISO 3166 country code]

SP= Hessen [State or Province]

o= eMint AG [Organization, 64 Chars, ISO 646 String]

eMint Headquarter

OU= [OrganizationalUnitName, 64 Chars, ISO 646

String]

Chair of Supervisory Board [CommonName,

CN=

64 Chars, ISO 646 String]

60325 Frankfurt am Main [Locality, 64

L=

Chars, ISO 646 String]

Taunusanlage 12 [StreetAddress, 64 Chars,

ST=

ISO 646 String]

Today YYMMDDHHMMSSZ [UTCTIME]

UpdateTimes.

NextTime YYMMDDHHMMSSZ [UTCTIME]

Serial number 12345678 [128-bit size,

RevokedCERTSerialNumber

reference to the revoked certificate]

Serial number 12345678 [128-bit size,

RevokedCERTSerialNumber

reference to the revoked certificate]

Serial number 12345678 [128-bit size,

RevokedCERTSerialNumber

reference to the revoked certificate]

Serial number 12345678 [128-bit size,

RevokedCERTSerialNumber

reference to the revoked certificate]

Serial number 12345678 [128-bit size,

RevokedCERTSerialNumber

reference to the revoked certificate]

AlgorithmlD CFV-Definition

Signature.

DigestKey Exmpl.: 7453 FDC5 AE52 063D AC4F

Table 60: Example of an eMint issued batch-production revocation-list of type CRL-TYPE-VII. 1.4.19.3 Electronic Coins

The eCoins in the transaction system described herein may be provided in form of a (shortened) certificate according to X.509 (version 3). Please note that the certificate of an eCoin may be shortened in that it may not contain all non-optional elements of a X.509-compliant certificate (version 3) as will be shown below. An eCoin respectively the certificate should comprise at least an identifying descriptor item (e.g. serial number) (e.g. in form of a Globally Unique Identifier (GUID)) and the value of the eCoin, and a signature on these two pieces of information by the issuing authority (eMint). Furthermore, in a multi-currency transaction system, the eCoin may further indicate a currency identifier (e.g. in form of a three character code) indicating the currency of the eCoin.

Further, the eCoins may also contain additional information facilitating the eCoin administration in the transaction system, such as for example an indication of the identifying descriptor item (e.g. serial number) of a batch production certificate (Type-VII), a version number or a type-code (Type-VOT) claiming the certificate structure being an eCoin. Furthermore, each eCoin may have a validity period (i.e. a date (and time) when it is expiring). In some embodiments of the invention, each eCoin has both a validity period and a transferability period (both indicated by the date and time of its respective expiry). The eCoins may be transferred freely from device to device within the transferability period. After expiry of the transferability period, the eCoin needs to be cleared with the issuing authority, prior to the expiry of its validity period. In one embodiment, the validity period and the transferability period are indicated in the batch production certificate (Type-VII) of the batch production of eCoins to which the respective eCoin belongs. As indicated above, each eCoin may comprise a reference to its batch production certificate (Type-VH) so that the CASTOR can obtain the validity period and the transferability period for each eCoin from its batch production certificate (Type-VII).

1.4.19.3.1 eCoin Certificate (Type-Vni)

An exemplary eCoin in form of an eCoin certificate (Type-VHT) according to an exemplary embodiment of the invention is shown in Table 61.

Table 61: Example of a digital eCoin used in the eCash system presented here.

1.4.19.3.2 CRL for eCoin Certificates (Type-VIII)

The issuing authority (eMint) may invalidate individual eCoins by including them in a CRL for eCoins. An exem lary CRL for eCoins is shown in Table 62.

Table 62: Example of an eCoin revocation list of type CRL-TYPE-VIII.

An eCoin revocation CRL of Type-VIII is self-released from the respective issuing authority. This revocation mechanism is used to invalidate previously self-issued eCoins. There may be only one single CRL-file per currency edition issued by an issuing authority. The effect of this revocation is that all eCoins concerned by this list become invalidated (they lose their purpose). 1.4.19.4 Directory - "List of Files"

Within the CASTOR Product Certificate (Type-V), the URL to the directory containing all "List of Files" is supplied. It is referenced under CERT-TYPE-V.X509.RootDirectoryPtr. The supplied files are presented below.

1.4.19.4.1 List of RCAs

To help a CASTOR find the RCA(s), the eCash organization supplies a "List of RCAs" file database repository. It comprises a single list (file) containing in principle all accredited RCA organizations available to the public in the whole eCash system (however, in most cases there is only a single one). A CASTOR user has to contact a listed RCA to find the CRL-TYPE-III, CRL-TYPE-V, CRL-TYPE- IV Certificate Revocation Lists or other supplied materials. This single list (file) is maintained by the eCash organization.

Table 63: Example of an eCash organization issued 'List of RCA' database repository.

1.4.19.4.2 List of CAs

To help a CASTOR to find its relevant CA, the RCA organization supplies a 'List of CAs' database repository. It comprises a single list (file) containing all accredited CA organizations in the whole eCash system available to the public. The user of a CASTOR has to choose his national CA to obtain a user certificate Type-Ι/Π and the respective CRLs in the next step. This single list (file) is maintained by the RCA.

Table 64: Example of an RCA issued 'List of CAs' database repository.

1.4.19.4.3 List of eMints

To help a CASTOR to find his relevant eMint, the RCA organization supplies a 'List of eMints' database repository. It comprises a single list (file) containing all accredited eMint organizations in the whole eCash system available to the public. The user of a CASTOR has to choose his eMint(s) to obtain the 'List of Currency Editions' file, the eMint batch production certificates, the desired currency (or currencies), and their respective CRLs in the next step. This single list (file) is maintained by the RCA.

The currencies issued by an eMint are NOT indicated within this list because that is a 'local eMint' decision taken by that authority without the need to ask or inform other authorities for/about cooperation.

Name The name of this LIST-OF-EMINTs-FILE

LIST-OF-EMINTs [global list of all accredited eMint organizations

Type

available]

Version number [16-bit unsigned integer describing the data object

Version

version]

YYMMDDHHMMSSZ [UTCTIME as Date & Time stamp for the time of

DTStamp

generation]

C= US [ISO 3166 country code]

http://www.FED.us [WebSiteAddress, 64 Chars, ISO 646

[0001] URL=

String]

DNS= FED.us.rootxustomer [DNS Network name]

List of

eMints. C= AE [ISO 3166 country code]

http://www. HSBC.ae [WebSiteAddress, 64 Chars, ISO

[0002] URL=

646 String]

DNS= HSBC.ae.root.customer [DNS Network name]

C= DE [ISO 3166 country code]

http://www.EZB.de [WebSiteAddress, 64 Chars, ISO 646

[0003] URL=

String]

DNS= EZB.de.root.customer [DNS Network name]

AlgorithmID CFV-Definition

Signature.

DigestKey Exmpl.: 7453 FDC5 AE52 063D AC4F ...

Table 65: Example of an ICA issued 'List of eMints' database repository. 1.4.19.4.4 List of Currency Editions

To help a CASTOR find the currency of interest, every eMint supplies a 'List of Currency Editions' database repository. This single list (file) contains all currencies minted by this eMint available to the public. A CASTOR user has to choose the desired currencies by loading the eMint batch-production- certificate Type-VII (and their corresponding eCoins) in the next step. Such single list (file) is maintained by every eMint-organization. It is possible to have more than one currency batch simultaneously active under the same currency ID.

Name The name of this LIST-OF-CURRENCY-EDITIONs-FILE

LIST-OF-CURRENCIE-EDITIONs [global list of all available currencies

Type

available by this eMint]

Version number [16-bit unsigned integer describing the data object

Version

version]

YYMMDDHHMMSSZ [UTCTIME as Date & Time stamp for the time of

DTStamp

generation]

ID Three character code (e.g. EUR)

Name of current eMint batch-production

Name

currency-certificate, max. 20 char.

Identification of an eCoin batch, max. 20

Current batch

Currency characters {optional information}

CertType CERT-TYPE-VII

CertificateSerialNumber Serial number [128-bit size]

YYMMDDHHMMSSZ [UTCTIME as Date &

DTStamp

Time stamp for the first appearance]

ID Three character code (e.g. EUR)

Name of current eMint batch-production

Name

List of currency-certificate, max. 20 characters

Currencies. Identification of an eCoin batch, max. 20

Current batch

Currency characters {optional information}

CertType CERT-TYPE-Vn

CertificateSerialNumber Serial number [128-bit size]

YYMMDDHHMMSSZ [UTCTIME as Date &

DTStamp

Time stamp for the first appearance]

ID Three character code (e.g. USD)

Name of current eMint batch-production

Name

currency-certificate, max. 20 characters

Identification of an eCoin batch, max. 20

Current batch

Currency characters {optional information}

CertType CERT-TYPE-VII

CertificateSerialNumber Serial number [128-bit size]

YYMMDDHHMMSSZ [UTCTIME as Date &

DTStamp

Time stamp for the first appearance]

ID Three character code (e.g. CHF)

Name of current eMint batch-production

Currency Name

currency-certificate, max. 20 characters

Current batch Identification of an eCoin batch, max. 20 characters {optional information}

CertType CERT-TYPE-Vn

CertificateSerialNumber Serial number [128-bit size]

YYMMDDHHMMSSZ [UTCTIME as Date &

DTStamp

Time stamp for the first appearance]

ID Three character code (e.g. GBP)

Name of current eMint batch-production

Name

currency-certificate, max. 20 characters

Identification of an eCoin batch, max. 20

Current batch

Currency characters {optional information}

CertType CERT-TYPE- VII

CertificateSerialNumber Serial number [128-bit size]

YYMMDDHHMMSSZ [UTCTIME as Date &

DTStamp

Time stamp for the first appearance]

AlgorithmID CFV-Definition

Signature.

DigestKey Exmpl.: 7453 FDC5 AE52 063D AC4F ...

Table 66: Example of an e Mint supplied 'List of Currency Editions' database repository.

1.4.19.4.5 List of System Updates

To keep CASTORs up-to-date and as part of the security strategy, the RCA organization supplies a 'List of System Updates' database repository. It is a single list (file) always containing the most recent updates of CASTOR relevant code and data objects available to the public. The user of a CASTOR accesses this list to share the most recent developments and fixes by downloading and auto-installing listed improvements. This single list (file) and the respective binaries are maintained by the RCA- organization.

Table 67: Example of an RCA supplied 'List of System Updates' database repository. 1.4.19.5 Controls

1.4.19.5.1 Control Challenges

Currently, only CRLs are prepared to be distributed.

Table 68: Example of a challenge control object used in the eCash system.

1.4.19.5.2 Control Responses Type 1

Currently, only CRLs are prepared for distribution.

Table 69: Example of a challenge response Type 1 object used in the eCash system.

Control Responses Type 2

Currently, only CRLs are prepared for distribution.

Table 70: Example of a challenge response Type 2 object used in the eCash system. 1.4.19.6 eDoc Type Objects

1.4.19.6.1 eDoc Type [I] Objects

Not all fields are filled for all valid transaction, some of them remain empty. For the case specific view concerning the presented off-line transaction protocol messages please refer to the subtypes of the eDoc[I] container. The following table comprehensively represents the generalized outward pre-flow (complete) super structure form of the eDoc[I] object.

Table 71: Example of the blueprint for the super structure for a complete eDoc[I] format object.

1.4.19.6.1.1 eDoc (Sub) Type [I _Ia ] Objects

The following table comprehensively represents the Matroska pre-flow container structure form of the eDoc Ii _a ] object used in message [5a] and message [6b].

Table 72: Example of the blueprint structure for a container eDoc[Ii _a ] format object.

1.4.19.6.1.2 eDoc (Sub) Type [I _2a ] Objects

The following table comprehensively represents the Matroska pre-flow container structure form of the eDoc[l2a object used in message [6a].

Table 73: Example of the blueprint structure for a container eDoc[I _2a ] format object.

1.4.19.6.2 eDoc Type [II] Objects

Not all fields are filled for every valid transaction, some of them remain empty. For the case specific view concerning with the presented off-line transaction protocol messages please refer to the subtypes of the eDoc[n] container. The following table presents the generalized outward mid-flow (complete) super structure form of the eDoc [II] object.

Table 74: Blueprint example of the super structure for a complete eDoc[II] format object. 1.4.19.6.2.1 eDoc (Sub) Type [II _a ] Objects

The following table comprehensively represents the Matroska mid-flow container structure form of the eDoc IIJ object used in message [7a].

Table 75: Example of the blueprint structure for a container eDoc[II _a ] format object. 1.4.19.6.2.2 eDoc (Sub) Type [II _b ] Objects

The following table comprehensively represents the Matroska mid-flow container structure form of the eDoc II _b ] object used in message [7b].

1.4.19.6.3 eDoc Type [III] Objects

Not all fields are filled for every valid transaction, some of them remain empty. Please refer for the case specific view for a match with the presented off-line transaction protocol messages to the subtypes of the eDoc[III] container. The following table presents the generalized outward post-flow complete) super structure form of the eDoc[ffl] object.

Following the CFV-

AlgorithmlD.

definition.

SignatureFromAlice/Bob.

Exmpl.: 7453 FDC5 AE52

DigestKey.

063D AC4F ...

Following the CFV-

AlgorithmlD.

definition.

SignatureFromBob/Alice.

Exmpl.: 7453 FDC5 AE52

DigestKey.

063D AC4F ...

SourceEntity. Alice or Bob.

SN, SN, SN, SN, SN, SN, ... , SN, SN.

SerialNumbers.

Main Secret Serials.

Following the

AlgorithmlD.

CFV-definition.

SignatureFromAlice Bob. Exmpl.: 7453

DigestKey. FDC5 AE52 063D

AC4F ...

Content, logic and visual presentation of the electronic

HTML5 Script.

eReceipt.

Following the CFV-

AlgorithmlD.

definition.

SignatureFromBob/Alice.

Exmpl.: 7453 FDC5 AE52

DigestKey.

063D AC4F ...

Following the CFV-

AlgorithmlD.

definition.

SignatureFromAlice/Bob.

Exmpl.: 7453 FDC5 AE52

DigestKey.

063D AC4F ...

Entity. | Alice or Bob. (8 bit)

DropoutStateCase. | (Null, Ala, Bla, Alb, Bib, WC).

Affidavit.

AlgorithmlD. Following the CFV-definition.

Signature.

DigestKey. Exmpl.: 7453 FDC5 AE52 063D AC4F

Table 77: Example of the blueprint for the super structure of a complete eDoc[ni] format object.

1.4.19.6.3.1 eDoc (Sub) Type [IIIJ Objects

The following table comprehensively represents the Matroska post-flow container structure form of the eDoc III _a ] object used in message [8a].

SourceEntity. Alice

SN, SN, SN, SN, SN, SN, ... , SN, SN.

Serial Numbers.

(expectancy value 10 * 128 bit)

AlgorithmlD. Following the CFV-definition.

Signature. Exmpl.: 7453 FDC5 AE52 063D

Main Secret Serials. DigestKey.

AC4F ...

Following the CFV-

AlgorithmlD.

definition.

SignatureFromBob.

Exmpl.: 7453 FDC5

DigestKey.

AE52 063D AC4F ..

Content, logic and visual presentation of the electronic

HTML5 Script.

eReceipt.

AlgorithmlD. Following the CFV-definition.

SignatureFromBob. Exmpl. 7453 FDC5 AE52 063D

DigestKey.

AC4F

Entity. ] Alice or Bob. (8 bit)

DropoutStateCase. | (Null, Ala, Bla, Alb, Bib, WC).

Affidavit.

AlgorithmlD. Following the CFV-definition.

Signature.

DigestKey. Exmpl.: 7453 FDC5 AE52 063D AC4F

Table 78: Example of the blueprint structure for a container eDoc[III _a ] format object.

1.4.19.6.3.2 eDoc (Sub) Type [III _b ] Objects

The following table comprehensively represents the Matroska post-flow container structure form of the eDoc III _b ] object used in message [8b].

Serials. value 10 * 128 bit)

AlgorithmlD. Following the CFV-definition.

Signature.

DigestKey. Exmpl.: 7453 FDC5 AE52 063D AC4F ...

AlgorithmlD. Following the CFV-definition.

SignatureFromAlice. Exmpl.: 7453 FDC5 AE52 063D

DigestKey.

AC4F ...

Content, logic and visual presentation of the electronic

HTML5 Script.

eReceipt.

Affidavit.

AlgorithmlD. Following the CFV-definition.

Signature.

DigestKey. Exmpl: 7453 FDC5 AE52 063D AC4F

Table 79: Example of the blueprint structure for a container eDoc[III _b ] format object.

It should be further noted that the individual features of the different embodiments of the invention may individually or in arbitrary combination be subject matter to another invention.

It would be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the present invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.