AU759002B2 - Electronic negotiable documents - Google Patents

Description

WO 96/24997 PCT/IB96/00163 1 ELECTRONIC NEGOTIABLE DOCUMENTS This invention relates to methods and devices for the issue and negotiation of electronic negotiable or quasi negotiable documents (END), and is particularly relevant to systems which are sufficiently secure in open environments. The purpose is to replace paper documents such as cash, bank cheques and bills of lading with freely-transmissible electronic data.

The goal to achieve is that an electronic document or rather, an electronic realisation of a document at any particular time can be proved to be the (temporary) property of a particular user. This is clearly required for what is known as negotiable or quasi-negotiable documents. The most interesting examples in trading are Bills of Lading, apart from cash and cheques. The main requirement is thus that these documents be unforgeable.

With ordinary paper documents, the problem is solved by giving the original of a document certain physical attributes that are difficult to reproduce. With this precaution, it makes sense to speak of the original of a document, and define the owner simply as the person holding the original. An electronic (quasi)-negotiable document will in the following be denoted by END.

The important property required is apparently that of uniqueness. The problem is to find a suitable attribute on an electronic document which somehow would give it the property of uniqueness, explicitly or implicitly.

Obviously, the concept of an original does not make sense for electronic documents, and other (e.g.

cryptographic) methods must ensure that the owner of a WO 96/24997 PCT/IB96/00163 2 particular electronic document can be identified. One question is to what extent this will involve a trusted third party (TTP).

Any document of some value must initially be generated by someone, who will guarantee this value. This requires .the proof of, or non-repudiation of, origin service, which is a well known art and realized using digital signatures.

The question now is how to develop a protocol to cover the situation, where an END, once issued, is to change hands. The main problem is to ensure, that the new owner is uniquely identified, or, in other words, that the seller cnannot circumvent the measures and -sell the same END o o tw different entities.

s am It is now generally recognized that this could only be achieved using cryptographic techniques, in the sense that violation will be detected. F i trther, it is necessary to use tamper resistant document carriers, such as smart cards (plastics cards containing an S* integrated circuit) or workstations. "Tamper-proof" or "tamper-resistant" means that the functionality of the device cannot be changed, and that any attempt to do so can be readily detected; in many cases, the device would simply be destroyed by tampering.

One obvious solution would be to introduce a trusted third party (TTP) to register at all times the possession of a particular document, but this would leave the TTP with heavily liability burdens, and is not a popular solution.

Another solution would be to represent each END with a WO 96124997 PCT/IB96/00163 3 *unique chip card, but transfer of the END would necessitate physical transfer of the chip card, which in many cases would be impractical.

The only other way to provide uniqueness is physically to prohibit free copying. This would involve tamper resistance to realize a protected communication with restricted functionality, if possible.

It is known to provide an encryption technique which ensures uniqueness in the transfer of data between two devices. Such a technique is described for example in "New Directions in Cryptography", W. Diffie and M.

SHellman, IEEE IT 22 (1976), 644-654. Briefly, each device stores a unique pair of codes known as the public key and the secret key. These constitute a set of matching keys with an underlying algorithm. Such algorithms include RSA and DSA, which are described respectively in U.S. patents 4 405 829 Rivest, A.

Shamir and L. Adleman) and 5 231 668 ("Digital Signature ".Algorithm", by D. Kraitz). The secret key S can be used to provide in effect a digital signature S(D) on input data D. The corresponding public key P can then be used to verify that the input for S(D) must have been S and D. Data from a seller's document carrier, for example, can be encrypted using the public key P of the buyer' s document carrier, transmitted to the buyer, and then decrypted using the buyer's secret key, if the public key scheme is of encryption type.

The basic principle for achieving uniqueness here is simple but fundamental: A message encrypted under a key known to only one entity is unique, as long as it is encrypted, and establishes undisputable ownership by the mere fact that it will only be useful to the owner of WO 96/24997 PCT/IB96/00163 4 the key. Only the person in possession of the right key can make any use of the document, which in effect is the property of uniqueness.

On the other hand, the only way the rightful owner can verify that the right END has been encrypted by his key is by decrypting it. .But this will give him access to the message and he may subsequently be able to "sell" it to two different persons by encrypting it with their respective keys. A purpose of the invention is to provide a way of avoiding this. This requires tamper resistant hardware, perhaps a chipcard, or a hardware protected PC. ,In the following, this hardware and equivalent hardwarewill be called the DOC-carrier, or D-C when abbreviated. Its properties will be described in detail. below. The invention provides a system with the following properties: .An END ,(or at -least the digital signature component of the END) .is .generated electronically, for instance by .using non-repudiation of origin, .in a tamper resistant unit and then loaded onto a DOC-carrier (if not the As mentioned, ,this requires some care. It is essential that the signature thus appended to provide the non-repudiation is never disclosed. (It would of course suffice to represent the END by a hash value and the generating digital signature inside the DOC-carrier if storage is a problem). The message itself does not need to be protected.

More specifically, an END (or at least the signature component) is transferred from one DOC-carrier to another, through a public unprotected network, in such a 1, 1 I WO 96/24997 PCT/IB96/00163 way that 1. It can only be transferred as a meaningful document to one particular DOC-carrier, which nevertheless can be chosen from any number of registered DOC-carriers 2. Recovery is possible, if the transfer is unsuccessful 3. The protocol cannot be completed by any other device than an authorized DOC.

The system should be completely open to communication between any two DOC-carriers, without bilateral i agreements.

Accordingly, the invention provides a method of issuing an END, as defined in Claim 1 below, and a document carrier suitable for use with such a method.. The invention also provides methods, as defined in Claims 12 and 13, of negotiating an END between a seller and a buyer; and a method as defined in Claim 23 of splitting an END e.g. an electronic cheque or cash.

In order that the invention may be better understood, an embodiment of the invention will now be described, with reference to the accompanying drawings, in which: Figure 1 is a diagram illustrating, by way of an overview, the negotiation of an END between two document carriers, showing the main components of the document carriers; Figure 2 is a schematic flow diagram of the generation of an END; and Figure 3-is a schematic flow diagram of the negotiation of an END.

WO 96/24997 PCT/IB96/00163 6 Each DOC-carrier "possesses" a public key pair. The secret key of this .pair must not even be known to the owner of the DOC-carrier. It would be required to realize this in such a way that not even the system provider knows the DOC-secret keys. Thus the secret key must be generated on the DOC-carrier and never leave it unprotected. The DOC-carrier itself should be freely available, but stationary, and certified by some Certification Authority along the lines of the X. 509 security architecture.

.ooo The END consists of the information as represented in an electronic message, and the corresponding digital signature, calculated by means of the secret key of the issuer and typically a hash value of .the electronic message. The format could for instance be a special EDIFACT message for the electronic message, whereas the signature will be calculated and stored securely on the DOC-carrier. Now, the problem is that this shall only be released through a selling process to another DOC-carrier. So the question is, how can one DOC-carrier identify another? The most attractive solution seems to be the following approach: A trusted party called the Certification Authority CA, authorizes all DOC-carriers in the following manner: The public key of the CA is installed on the DOC-carrier, as well as the secret DOC-carrier key, in a ROM, and in such a way that the secret key cannot be disclosed. Moreover, when a document, or rather the accompanying key protected signature is entered on the DOC-carrier, the DOC-carrier software must ensure that it can only be realised again encrypted WO 96/24997 PCT/IB96/00163 7 under a public key certified by the CA secret key (and verified by means of the corresponding public key on the DOC-carrier). The point behind this is that it will prevent the use of a non-authorized DOC-carrier to get access to the vital signature on an END, which defines that particular negotiable electronic document. In particular this encrypted message is useless excepted when imported into the DOC-carrier holding the corresponding secret key. It is thus important to realize that the value of the negotiable document is represented by the digital signature of the issuer.

Furthermore, and this is an essential property, such an encryption of a particular END on an individual DOC-carrier can take place only once, or rather, once a public key has been selected,, it is impossible at any later stage to go through the same procedure with another public key.

a Such a system would solve, the problem o.f uniqueness in general provided it works in,.practice. The difficult part, which also requires a careful analysis, is to recover from failure. In other words, the problem has been reduced to that of availability.

0 First of all the DOC-carrier may go down. The only way to recover from that is to have the same information on a backup DOC-carrier. This requires that a protocol is developed, which ensures that the back-up card cannot be used to sell the END to.a different entity. Another possibility is to demand that whenever a back-up copy is required, the CA must be contacted.

Secondly, something may go wrong with the encryption in a selling process. This will be easy to recover from, WO 96/24997 PCT/IB96/00163 8 by encrypting once again under the same public key. The use of certificates will ensure with extremely high probability that the public key used for encryption is correct.

Thirdly, something may go wrong in the data transmission from one DOC-carrier to another. But this is handled by re-transmission. The encrypted version of an END needs not be protected. In particular, a totally insecure network may be used to exchange the encrypted END.

Finally, something may go wrong in the receiving DOC-carrier. This may best be handled by a back-up Scard, with special procedures for recovery.

The functionality of the DOC-carrie is explained in Figure 1. With the notation of the discussion above, this gives an overview of the design of a DOC-carrier.

Shhe general principle of the protocol between two DOC-carriers ka and -B is represented in the following sequence, the numerical stages 1 to 6 of which are shown in Figure 1: 1. The certificate of B is forwarded to A 2. A verifies the certificate of B If this. is successful, 3. A encrypts the relevant electronic END (or rather, the defining signature) with the public key of B and 4. forwards this to B B decrypts with its secret key SB and is now WO 96/24997 PCT/IB96/00163 9 the owner of the END 6. B stores the END (or rather, the defining signature) as DOC 1.

The main content of DOC 1 may be transmitted separately from one workstation to another; it does not matter that there may be insufficient memory in the DOC-carrier for the whole of DOC 1, because it is only necessary to store and encrypt the signature portion.

The following is a more detailed description of the generation and negotiation of. an END.

The basic protocol for issuing an END and for negotiating that END from its original document carrier to subsequent document carriers is described in the annexed Tedis II B7 document. This gives examples of a document carrier in the form of a chip card containing memory and a program, -in a tamper-resistant format.

This document also describes the rolie of a Trusted Third Party in the certification of the .document carriers including their original programming with public-secret key pairs, and the tracing of negotiations between ,.document carriers. ,One important benefit of the present invention is that the role of the Trusted Third Party is minimized, in that it is not necessarily involved directly in the performance of a negotiation of an END between buyer and seller. In other words, no third party need be involved in the actual negotiation protocol. It is also an important benefit of the invention that each END can be negotiated only from one document carrier to one other document carrier, and only once (the system is arranged that the seller can, in future, receive the END back again, but only as a result of a genuine transaction: the system achieves this by WO 96/24997 PCT/IB96/00163 counting the number of transactions for each END, and this is described in more detail below).

In this description, the party, such as a bank, which issues the END, is known as the issuer. The issuer has a public-secret key:pair, of which the secret key is used to sign the END. The END consists of a bit string which can be read by conventional coding rules, such as ASCII characters written in English. The END is not complete until it is signed by the issuer. As indicated above, a public-secret key pair consists of a set of matching keys P and S with an underlying algorithm. A Trusted Third Party initializes the document carriers of the system, and each document carrier is initialized with a public-secret key pair for signature generation and verificatiion, and. a public-secret key pair for .encryption and decryption, unique to the device.

However, the two public-secret key pairs can be identical, i.e. can .be used for both purposes. This depends partly on whether the :document-carrier is used for issuing as -well as for negotiation: the public key pair for issuing .can be different from that for negotiation. Each document carrier is identified by a unique device number or identifier, referred to as the No Each document carrier is given to one legal person, called the owner. The buyer of an END is the document carrier in current possession of the END. The seller is the document carrier which is to take position of the END from a buyer through the protocol. The validity period of each END is the interval between the time of issue and the time that the issuer requires it to expire. The time of issue is recorded as a time stamp with the END.

WO 96/24997 PCT/IB96/00O163 11 As indicated above, each document carrier must be tamper resistant, with a limited functionality. It could take the fdorm of a specially designed chip card, or an enhanced work station. The digital signature could typically be stored in an'EEPROM, or some sufficiently protected memory.

The Trusted Third Party (TTP) has its own public-secret key pair, of which the public key P is installed on each document carrier. 'Further, a certificate, consisting of a digital signature 'of the 'device number No and of the public key of the document carriet is installed on the document carrier, for each of its public key pairs.

n the case of bankf.:n chquds fo ipem an eldctronic "water mark "i a i ded to 'each ENI 6upo creatid.

Normally, the dodiiiment carrier upon which the END is issue d. has the electronic waterma rk 'stored *on it, for adiion o tihe ED uiipon i:ssue.

In the detailed dbscription which follows of the issue and negotiation of an END, f6refrice is made to the hash value of data. This refers tbo a technique described for example in ISO/IEC IS 101l8, "In ormatio Technology-Security Techniques-Hash Functions".: The hash function is a representati-ve 'abpreviation of the original data, and it is used where the hardware dictates economy in the use of -storae space. For example, chip cards at present are unable to store much data, and the hash value is used to reduce the amount of encrypted daita to be stored.

Examples of END include electronic cash, in which the issuer is called a "Bank", with special equipment for WO 96/24997 PCT/IB96/00163 12 issuing ENDs; here, the document carriers are used for negotiation, not issue. A further example is electronic bank cheques, in which each document carrier comes.with a watermark of the Trusted Third Party (again called the "Bank") and each document carrier may be an issuer. A further example is the bill of lading, which is similar to the example of bank cheques, but need not necessarily have watermarks. The same applies to bills of exchange.

Various back-up procedures are possible in any instance, and the TTP involved will then have a copy of the keys of the document carriers. As, the buyer always receives the END encrypted under the public key of the device, it will keep copies of the received encrypted information for later recovery by means of the TTP, Thus the negotiation can be recovered later once decryption becomes possible. Alternatively, each document carrier is formed with a duplicate, complete with the unique public-secret. key pair certificate and device number; the device number identifies the device which is being backed up by the duplicate. One possibility for this is to have one chip card with two chips, but a more secure solution is to have two independent chip cards or other work stations. Whenever a negotiation takes place, the protocol is duplicated with the backup document carrier. If the primary document carrier should break down, the back up is authorized to sell to the issuer after the expiration time of the END's which could not be negotiated. In this case, the TTP needs only to keep a copy of the back up device secret key.

A preferred feature for electronic bank cheques is the so-called "splitting" of a purchased cheque. A purchased cheque may be split into two by means of two digital signatures by the buyer. The document carrier WO 96/24997 PCT/IB96/00163 13 "verifies that the total amount of the two split parts adds up to the amount of the original. A digital signature is generated by the document carrier and the two separate parts can then be negotiated individually.

Subsequently, buyers will have to authenticate not only the issuing signature but also the splitting signature.

The split is performed in the following manner: the original END, as represented in the document carrier of the current owner, may be split into two or several numbered versions, the sum-of their values adding up to the value of the original. A split version consists of .00 the original, together with some information such as its *value and sequence number, and this is signed with the secret key of the document carrier. If the document carrier has the Status of an iss.uer, the original issuing signature may be deleted to save space.

Any END could be split, even for example a bill of lading, in which case the information could include attributes such as quantities of goods as well as, or instead of, monetary value. An oil cargo for example could be divided, and the electronic bill of lading *t o e* split accordingly.

With reference how to Figure 1, an END is issued on a document carrier D-Cj. The content of an END is generated freely in an unprotected environment by any issuer, and the certificate of the issuer is contained in the END together with a time stamp indicating the time of issue. A hash value hl of fixed bit length is created from the certificated END plus the time stamp, and this is provided as an input to the document carrier.

WO 96/24997 PCT/IB96/00163 14 In the example of bank cheques given in the Annex "Mandate final report", the document carrier is initialised by one or more banks. The banks personalise the D-C for the user by recording the user's account number etc. and enabling.the user to issue a specific number of electronic cheques drawn on that account these are ENI's (electronic negotiable instruments).

The same D-C can be initialised by several banks for respective accounts, and it is an "electronic cheque book".

To create an ENI, .the user puts his D-C into a f.ee* smart-card reader connected to .his PC, and he fills in details such as value, payee, period of validity, which appear as blank spaces on his PC screen, adjacent the bank. details which appear automatically. The user transfers the message or a hash value of it onto his D-C where it is signed.

At the initiation of the.: user,. therefore, the .4ocument carrier performs certain functions .which are ,beyond the control of the user. Specifically, the document carrier adds its device number which is in one-to-one correspondence with the public key of the device used for verification of digital signatures generated by the device. This device number could form part of the certificate, or it could be for example the upper bits of the public key after the most..significant The document carrier then appends the sequential serial number S(i) for the END. In the case of the END being bank cheques, or if otherwise required, the document carrier also appends the watermark WM, which is a bit sequence identifying a certain party such as a bank.

The concatenation of this data is then, if necessary, WO 96/24997 PCT/IB96/00163 hashed to produce a hash value h2. The data or the hash value of the data are then signed by the secret key of the document carrier, to produce Sj(h2). This signed value is stored adjacent to the other concatenated data. Next, the document carrier appends to this data the value of a serial counter, set to zero; and the value of a one bit flag, set to one, indicative of whether the END is currently negotiable (value 1) or non negotiable (value 0) from the particular document carrier.

The END has thereby been issued, and made ready for negotiation with another document carrier certified as being part of the system.

*The negotiation of this END originating from document carrier D-Cj, between a seller document carrier D-CA and a buyer document carrier D-CB will now be described with reference to Figure 2.

The negotiation involves the seller and the buyer, and S. may involve a TTP as well, but for tracing only. The seller, which may possess many different ENDs, decides to sell this particular END to the buyer Br. The seller first authenticates the buyer, in Stage 1, by receiving from it the certificate CB, corresponding to the unique public key PB of the document D-C

B

It is transmitted over a public channel in an open environment.

The program on the seller's document carrier D-CA checks, in Stage 2, whether the certificate CB is authenticated, and aborts the negotiation if not. It then extracts the public key PB for future encryption. The seller identifies the negotiability status flag of the particular END it wishes to sell, WO 96/24997 PCT/IIB96/00163 16 accessing it, in Stage 3, with the device number D(j) and the END serial number It then checks in Stage 4 that the flag is 1, and if not it aborts the negotiation. If the END is shown to be negotiable, then further action is not denied, and the full END record or message M is encrypted by means of the public key Pg, and sent over the public channel to the buyer.

To ensure that the seller cannot repeat the negotiation of the same END, the negotiability status flag is set to zero, in Stage 6.

On receipt of the encrypted message or ciphertext C corresponding to message M, the buyer decrypts the information using its own secret key SB: this provides the original message M=SB(C). The buyer also requests and receives, in Stage 6, the certificate of the issuer Cer(D-Cj), and the hash value of the original content of the END, and in Stages 7 and 8 it decrypts the message M from the ciphertext C, and it verifies the signature Sj(h2) and the device number D(j) of the issuer. If verification should fail, the buyer informs the issuer and ceases negotiation.

The buyer then checks the timestamp T of the END, and informs the issuer and aborts the negotiation if the timestamp indicates expiration of validity of the END.

The buyer then returns to the seller, through the same open channel, an acknowledgement in the form of a digital signature on the concatenation of the serial number of the END, the generating signature and the counter. It is accompanied by its own certificate

C

B

A copy may also be returned to the issuer for tracing purposes.

WO 96/24997 PCT/IB96/00163 17 The seller D-CB verifies the acknowledgment and then outputs the result for information to the seller. The same thing happens at the issuer, if applicable.

In Stage 10, the received information, i. e. the hash value of the content of the END, the device number of the generating END, the serial number of the END, the generating signature and the counter, which is I incremented by 1 in Stage 11, is then stored in a new record. It is important to increment the counter, so *i that each document carrier can recognize .that the END has undergone a further negotiation, allowing it to return to a previous document carrier.

The negotiability status flag is then set to 1, to indicate that this END, with this particular counter, has become negotiable.

S

After a number of negotiations, the END will be presented to the issuer for settlement, whether it is a cheque or cash or whatever. The settlement involves electronic tracing effectively in the reverse direction back to the original issue.

Whilst a specific example has been given to illustrate the different inventions claimed in the following claims, it will be appreciated that the objects of the invention can be realized in different forms, using different software or different hardware. The various different features which have been described in this specification are not all essential, but we claim separate inventions in all possible combinations, of such features, within the scope of the claims. For example, although the method of issuing an END and then negotiating that END from the issuing document carrier WO 96/24997 PCT/IB96/00163 18 to a buying document carrier is not claimed separately, this is intended to be a separate invention. Further, features such as .the ability to recover from failure, although not claimed specifically, are intended to constitute an invention when combined with other features which are claimed specifically.

*o EDITORIAL NOTE 30107/00 ANNEX 1 AND ANNEX 2 ARE PART OF THE DESCRIPTION AND ARE FOLLOWED BY CLAIM PAGES 19 TO 23.

Poray i.

TEDIS 11 Security in Open Environments A presentation of the main ideas in the report on Security in Open Networks, and related topics.

Security in open env'ironmecnts, TEDIS 11, B7, vcr. 15. Jly 1 994.

Contents I Intro duction 4 1.1I Background 4 1.2 Scope and 1. 3 How 6 2 Security Services in trade and administration 7 .,2.1I 7 Security Services 8 2.3 Trusted parties 3Security services relevant to 1 Z I Non-repudiation it 3. 1.1 11 1.2 1.1.3 12 3 1.4 C onclusion 3 3).2 Claim of origin 14 3.2.1 B ackground 14 3.2.2 D efinition 14 3.2.3 Discussion 14 3.2.4 Practical aspects -3.2.5 Conclusion Claim of ownership 16 Background 16 3).3.2 D efinition 16 3).3.3 16 3.3.4 Practical 24 .3.3.5 Conclusion 24 33.4 Fair exchange of 26 3.4.1 Introducti'on 26 3.4.2 26 3.4.3 26 3.4.4 Practical 27 3.4.5 Conclusion 27 Interactive authentication (with key exchange) 29 3.5.1 Introduction 29 3.5.2 29 3.5.3 .3.5.4 Practical aspects 3.5.5 Conclusion ilonymnity, Or 34 ScceiritY in opl-w Cflvirofllfcfis. TFil AS 11, 137, ver. 15.JAll\ 19 94.

3 .3.6.1 Introduction 34 Definition. 3 3.6.3 Discussion 34 3.6.4 Practical 36 3.6.5 Conclusion 37 4The use of Trusted Third 38 4.1 The various roles of 38 4.2 TTP Support 39 4.3 TTP Notary 41 4.3.1 Time sta 4.3.2 Legal and access 43 4.3.3 Archiving and 43 4.3.4 Witness services 44 Re view of relevant trade 5.1 Review of some documents on 5.2 BIMCO 49 5.2.1 The Bill of Lading 5.2.2 Rights of various parties in connection with the B/L 5 I 5.2.3 The BIM CO B/L p~roject 53 6 Thle wvork of the UN/EDIFACT Security JWG 56 6.1 Recommendations from the EDIFACT Security JWG 56 6.2 Message level security 57 6.3 Integrated message 58 6.3.1 Security headers and trailers 58 6.4 Separated message security 7 Bibliography (partly 61 Annex onl Basic cryptographic concepts 72 A. I Security Services 72 A.2 Access .7 3 A.3 Electronic 74 A.4 Originals and copies 74 A. 5 Cryptographic techniques A.6 76 A.7 Symmetric and asymmetric 77 A.8 Hash 77.

A.9 78 A.l1 Irreversible methods 78 A. I I The principle'of electronic authentication 79 A. 12 Digital signatures 79 Security in open environments, TEDIS 11, B7, 15. July 1994.

A. B Non-repudiation 81 Security in open environments, TEDIS 11, 137. ver. 15. lulY 1994.

1 Introduction 1.1 Background Within the last years, data security has enjoyed increasing attention from all angles: Users, researchers, standardization bodies, national agencies, and governments. One of the more urgent needs for security seems to be in EDI, for which reason the TEDIS programme already at an early stage focussed on security.

An important aspect of the TEDIS programme is quite naturally to analyze security aspects in open multiservice environments. However, security in general is a very broad concept, which covers anything from risk analysis, user needs, etc. at one extreme, to the specification of definite algorithms and protocols at the other.

Once an integrated security system is fully implemented, the interface to the user appears as a range of so-called security services (following the CCITT and ISO terminology), e.g. message authentication, non-repudiation services, confidentiality, to mention but the best known security services. It is therefore of utmost importance at the initial stage to specify exactly which security services (functionality) to implement.

A common feature of almost all security services in an open environment is the fact that realization is only possible through the use of cryptographic techniques. The point is that the security service somehow must connect to the data, which is just a string of bits, and this requires the cryptographic tools, except in very restricted situations, atypical to EDI, where this connection is provided by the use of tamper resistance.

As an example, the relevant security services in EDIFACT, as in use today, are exactly those just mentioned above. With this in place, the next step then is to integrate them in the standard.

This was one of the proposals of the TEDIS I programme in "Digital signatures in EDIFACT".

This study served as one important input to the UN/EDIFACT Security Joint Working Group, which has now taken the next fundamental step and recommended a uniform, versatile solution to security in EDIFACT. All security services, save confidentiality, are realized by appending by means of security headers and trailers a so-called security attribute to the message. We refer to the TEDIS I report for a general presentation of the characteristics of EDIFACT and other important standards related to EDI.

However, there are a number of other fundamental applications of EDI in general, which are not covered by EDIFACT,'at least at this stage. Examples include Interactive EDI, which is not that much of a problem as far as integration of security is concerned, but also much m6re Security in open environments, TEDIS 11, B7, vcr. 15. July 1994.

complicated applications, such as the electronic counterpart of "negotiable or quasi-negotiable documents", most noticeably bills of lading which are a true challenge to cryptography and data security.

It turns out that for these new applications the appropriate security services have not yet been considered by standardization bodies as ISO and CENELEC. The first step therefore is to identify these services, driven by business needs, and explain whether and how they can be realized.

For these reasons, the TEDIS II call in 1991 included the project "Security in Open Environments. The work was carried out by CRYPTOMATHIC and Philips ITS (formerly MBLE). The present report is a more comprehensive presentation of the original work carried out, with the intention of reaching as many non-specialists as possible.

We are happy to report that since we first piesented these new concepts, they gained broad recognition and even made their way into the INFOSEC Green Book, where in fact a few essential parts of our original report have been reproduced, with TEDIS approval of course.

1.2 Scope and purpose One goal of electronic transmission is to replace communication based on paper as much as possible by EDI. To advance further in this direction, two issues must be addressed: S Depending on the application, it is necessary to identify exactly which security senrvices are required to realize that particular application by EDI ina secure manner.

Independently of the need for new services, the question is if they can be achieved with current techniques. As stated above, cryptographic techniques are required although not exclusively. However, the initial questions which need to be answered are: What is -at least in theory possible, and what has already been offered by the advance of research towards new security techniques.

The aim of the following is to try to answer the questions raised above. This requires on one side a strong connection to the users and the applications they hope to realize, and on the other side a perhaps even stronger connection to the scientific world to describe not only what is possible with the new techniques, but also what in fact will never be possible, not by lack of technique, but simply for logical reasons.

Concerning relevance of security services in EDI, it has been argued that so far there is not much of an indication that greater security measures are required in current applications. This is a very shortsighted point of view. It would be a bit like buying a car in broad daylight and then decide not to acquire headlights. In due course (when it gets dark), such a car will be impossible to operate for security reasons, although at the time of purchase, this was not an Sccurity in open environmncts, lE)IS1t 137, vc. 15. .lui. 1994.

issue. With this metaphor in mind, communication in open EDI is like driving at night.

1.3 How to read The report is structured as follows: Chapter 3 is the heart of the report, with a discussion of all the relevant security services, which have been identified, with an extensive discussion. The more technical aspects are presented in special sections, which can be left out by the less inclined readers.

Chapter 4 is an overview of the requirements for Trusted Third Parties with special attention to EDI aspects.

In Chapter 5, we briefly recapitulate some of the most important documents on trade legal aspects and current projects, with a detailed account of the BIMCO project, which could be realized with one or several of the solutions, we present.

One of the most advanced EDI message standards today, as far as security is concerned, is EDIFACT. In Chapter 6, we give a report on its status, followed by a discussion of some of the technical aspects of the realization of the security services in EDI.

On top of this, this briefed version of the original report contains an annex which explains briefly the most fundamental cryptographic concepts, used freely throughout the report.

Security in open environmcnts. TEDIS II, i7, vcr. 15.. ul 1994.

2 Security Services in trade and administration 2.1 Introduction Mankind did not really anticipate any means for transportation or preservation of reliable information other than paper until this century.

Thus one is left with the impression that paper (the carrier) rather than information seems to be the essence of a document, and this is strongly reflected in common understanding and legislation, where the goal is confused with the means: the paper is only there because it was the best way of ensuring a number of security services.

However, the point is of course the information in the document, and its implications, and not the document as such.

It is common to identify information with its accidental representation rather than to focus on the information itself, as seen from the definition of a document. Some representations are more reliable than others. In most situations, people have felt that a document, sealed and signed was the best way of preserving and communicating information. However, this way of representing information is quickly becoming obsolete. Not only is it slow, but the security is too low as well in a number of situations, for instance bills of lading (see [OD1] and [OD6]).

On the other hand with the computer revolution of the last decades in the society, vast amounts of data (personal, financial and commercial) are stored in computer data banks and transferred over computer networks. Therefore we have to rely in future on electronic data information.

One major problem is that of securing integrity. By this we simply mean that nothing of the contents of the information can be changed without detection. In the paper world, this is solved by "original" documents, which in some sense are tamper resistant devices. The information is written in such a way that it is difficult to add or delete information without leaving a trace, and a handwritten signature ensures the originality, all under the assumption of course that the document consists of one page only. The problem with copies, such as photocopies or faxes is not easy to handle.

How do we then ensure the integrity of electronic documents? First of all it makes no sense to speak of "originals" and "copies" (see [OD4] and If a data record is transmitted from one computer to another, which one is then the original,. and which one is the copy? It seems to be a quite general assumption, that the way to ensure the identity of electronic documents, which at any time could be produced based on a data record, is to rely on the Sccurity in opl environmenlts, *1*IS II- B7. er. 15. Julhv 1994.

tamper resistance of the involved hardware and a set of rules of conduct by the involved parties. However, it does not take much insight to realize how fragile this integrity really is. In fact, the same information is not even represented in the same way in different environments: Different codes are used in different machines. But even so, it is practically impossible to guarantee integrity by means of tamper resistant hardware without introducing enormously expensive and impractical solutions. For further discussion, please consult [OD8.

If we still need the concept of"an original electronic document", the only possibility would be to refer to a specific data base containing various data records and then define any "similar" or identical data record outside of that database as a copy.

It is to accommodate all these problems that digital signatures are considered an important tool: it is the only way of transforming some of the most essential security services from the paper world to the electronic world. In fact, it is much more secure than an ordinary handwritten signature. Indeed, a digital signature depends entirely on the content of the information [OD9].

There are, however, other complex security requirements, where a digital signature is not the right solution, although it may be an important ingredient. For example, electronic cash would involve something else than digital signatures, as an essential property of cash is that it is untraceable.

In the following six different types of services, which in our opinion cover all security aspects in EDI in the broadest sense of the word, including interactive EDI, are presented. Four of these services are new in the sense that they have never been identified officially before in standards committees. We suggest this is considered by the appropriate ISO and CEN/CENELEC committees, where new security services have not been considered for quite a while. Common to all of them is the fact that there are, or will be, definite business requirements for them.

2.2 Security Services As mentioned earlier, the terminology security service has been adopted in standardization. This reflects the fact that it is up to the user to decide to use a security service in a communication. In the situation, where the security service is required when a message is forwarded, this is typically realized by appending, or forwarding separately, what could be called a "security attribute" to the message. This would be the situation for the first three classes of services below, but not the rest, where there is no well defined message.

Here, a message is just some structured data, which can be read according to some rules.

Sometimes the term "electronic document" is used as well.

The six categories of security services to be discussed, here are Security in open environments, TEDIS 11, B7. ver 15..ulv 1994 Non-repudiation services Claim of origin (new) Claim of ownership (new) Fair exchange of values (new) Interactive identification with key exchange Anonymity, or untraceability (in databases) (new) Apart from this there is of course an obvious need for confidentiality, but the techniques here are well understood an in principle easy to realize.

It is cleartoanybody, whohas even remotely dealt with security in open environments, that Trusted Third Party Services will be red in uie a number of situations,cept of a Trustedhich certificates is only one. Hence, a preliminary clarification of he concept of a Trusted Third Party (TTP) is necessary. A more detiled discussion is deterred to Chapter 4.

Security in open environments, TEDIS II, B, ver. 15. July 1994.

Security in open\1 2.3 Trusted Darties When a group of users wants to communicate securely using cryptographic methods, some measures must be taken to distribute and update the keys that are needed. Typically, each user must obtain a key from every other user he wants to communicate with, no matter which service is required. For a small, constant user group, this may be a fairly straightforward problem, which can be solved without involving any other parties than the users themselves..

For larger and more open user groups, the problem quickly becomes difficult, however, and one needs to involve a so called Trusted Third Party (TTP).

Although several variants exist, there is a main distinction usually made between two types of TTP's:.fuilcionally Trusted Third Parties and unconditionally Trusted Third Parties.

The first type arises from of the obvious need for reliable registration of users of the system. If public key methods are used, this will usually include certification of public keys as belonging.

to certain users. A TTP trusted to perform this function is called functionally trusted. It is clear that if the registration is not done in a reliable manner, users cannot even be sure with whom they are communicating. So functional trust represents a minimal amount of trust that must be placed in a TTP. Note that this type of TTP does not. need to know the secret key of any user, nor does it need to know any conventional keys used for data Communication between users.

The functionality required in this instance is comparable to the functionality of a phone book: It provides a reliable connection between people, or their residence, rather, and their phone numbers.

The second type of TTP is typically needed in systems that use conventional cryptography only, or systems, where a current registration of the primary messages take place (like securities). In addition to the registration function mentioned above, such an unconditionally trusted TTP will generate keys for data communication and then communicate them securely to the users who need them, or be responsible for the primary messages in the system. This means that the TTP knows and in principle could make use of all the secret information in the system, or be responsible for the information related to a particular user. Thus elaborate measures must be taken to prevent misuse. This usually involves the use of tamper resistant hardware, ensuring that no key will appear in the clear outside of the trusted environment, or provided a waterproof access control within the premises of the TTP.

What we have presented here is but the perhaps must obvious use of TTP's. There are may others, as we shall see in Chapter 4.

Security in open environments, TEDIS II, B7, ver. 15. July 1994.

3 Security services relevant to EDI 3.1 Non-repudiation services 3.1.1 Background These services are well understood and easy to implement using digital signatures. In EDI they consist of non-repudiation or proof of origin and receipt, and have already been described in [OD7]. There is a massive understanding for the demand (see [UNI), although this unfortunately so far has not been reflected by the standardisation efforts. For completeness, we reiterate the descriptions as we want to address some special aspects.

It may be an idea in the following to keep in mind the situation where one business partner (the sender) sends a letter, which he has signed to another business partner (the receiver), who then in return acknowledges receipt in a signed letter.

3.1.2 Definition The point of a non-repudiation service is to provide a proof, to third party, that an entity has participated in or carried out a certain process.

Non-repudiation of origin resp. receipt means that the sender resp. the receiver, cannot successfully repudiate deny) to have signed resp. received a particular electronic document. It does not prove who has actually created the document. We have exactly the same problem with paper documents: the fact that someone puts his signature on a handwritten transcript of music does not mean he is the composer.

Coming back to non-repudiation of origin and receipt, the important point is that the services prove, or intend to prove, the actual involvement of the end users. In bank clearing terminology, these are the originator and the beneficiary of the message in question.

Non-repudiation of submission resp. delivery corresponds to the services required when a registered letter is mailed. In particular these services may only prove that a (some) electronic document was send at a particular time, but not exactly which document. These services requires the interference of a Trusted Third Party, but not the end-users.

Strangely enough this basic distinction has not yet made into the ISO security framework (ISO 7498-2) Security in open en\ironments, TEDIS II, B7, ver. 15. July 1994.

3.1.3 Discussion In an open environment, a non-repudiation service would imply the use of public key techniques. Each entity (user) possesses a public key pair, consisting of a public key P, which can be made known to everybody, and a matching secret key, S. The secret key is used to create a digital signature on a message, and the corresponding public key is used to verify the digital signature as been created by means of that particular secret key only.

The business requirements are obvious. In the paper world, there is a massive demand for handwritten signatures, for legal reasons. If similar functionality cannot be provided, or even requested in the electronic world, why not give up handwritten signatures as well? At least, this would be consistent. Another point is that the digital signature must be personal, and express a personal will. Thus the introduction ofa TTP to provide non-repudiation on behalf of an entity, as sometimes suggested, seems odd and artificial.

Realization of non-repudiation services in an open environment would typically furthermore requirethe implementation of the so-called CCITT X.509 architecture, which is described in [OD7]. This involves a Certification Authority a functionally TTP, which is responsible for the registration of all entities (users). To achieve this, the CA has a public key pair and P is then the only non-personal key, which must be known to any user in the system.

When a user A has generated his public key pair (PA,SA) and wants to register, his identity is established according to the declared security policy of the CA, and in return, the CA issues a so called Certificate, Cert(A), which is a digital signature computed by means of S on the message consisting of A's identification in the system and PA. Whenever A wants to send a digital signed message to another user B, whom he may in fact never have met, he forwards his certificate together with the message and his own digital signature on the message. The receiver only knows P, by which he can verify the certificate. From this he will retrieve the public key PA of A, which he. can subsequemly use to verify the signature of A.

This type of system would provide the gateway to what is known as open EDI, where by definition the communication cannot be based on bilateral agreements.

It should be noted though, that in order to build an operational and more importantly acceptable system, other TTP services must be provided. This is discussed in Chapter 5. Here it suffices to mention that the system would require easy access to information on the status of any certificate, which must be provided by another TTP, the Directory. However, and this is very important, if implemented in a sufficiently clever way, which allows for a certain period of clearing, just as we know it from the paper world, it will not be necessary to always inquire about the validity of a certificate in the directory.

Security in open environments, TEDIS II, B7, ver. 15. July 1994.

'i3 X E 509 Achitecture Certification Authority Reg istral Facility Registration Fadcility Ide-ntification of B d(B) Identification of A Id(A) User B User-A A Doc, SA(Doc), Cert(A)

B

only needs 3.1.4 Conclusion Non-repudiations services are precisely the services which in electronic communication can cover all legal functionalities of a handwritten signature, but in a much more secure way: The main difference is that the digital signature which supports the non-repudiation provides a logical connection to the message, as opposed to the handwritten signature. For a very thorough discussion of all the legal aspects, we refer to the TEDIS II report on "Legal aspects of authentication, storage and coding".

Security in open environments, TEDIS II, B7, ver. 15. July 1994.

3.2 Claim of origin 3.2.1 Background Copyright is a very important security service in the electronic handling of a document. The major problem with enforcing copyright of, say, a software program, is that of two different versions it is difficult to decide which one is the original. This problem is of course not restricted to electronic documents only. In fact, one runs into exactly the same kind of problems as in the paper world.

3.2.2 Definition The service required here is "claim of origin". This is the counterpart to nonrepudiation in the sense that the point is to allow the dreator to prove who created the document, as opposed to non-repudiation. of origin, which provides everybody with the means to prove that someone has signed a particular document (which typically commits him to something). The difference is that with non-repudiation services, the receiver is able to prove something, whereas claim of origin pertains to the transmitter.

3.2.3 Discussion It is possible to prove that claim of origin can only be achieved by using a trusted center, where the electronic documents are registered or authenticated, i.e. a Notary Service provided by a TTP (unconditional trust), or having the document, or a hash value thereof, timestamped and digitally signed by a TTP (functional trust). The point is that in order to establish the origin, we need a digital signature. Of course, anybody can apply his own digital signature to the document, but this will not imply proprietary rights. Hence the only solution is either some kind of registration or some notary service. One way of realizing this is by use of a TTP to provide a timestamp. This is further discussed in Chapter 4. In particular, cryptographic techniques have nothing useful to offer in any other way than to apply non-repudiation services to prove that a document was registered or timestamped at a certain time, or by using encryption to protect the content of a document. When such as center has been established, it will be trivial to integrate security.

If a document has an intellectual value, claim of origin is required. If a document commits someone, proof of origin is required.

Another problem is of course how to enforce copyright on electronic documents. This is not discussed here.

Security in open environments, TEDIS II, B7, ver. 15. July 1994.

3.2.4 Practical aspects As explained this service requires a TTP, one way or the other, and the primary cryptographic mechanism is a digital signature. The technical requirements as far as security services are concerned are hence very limited and do not present any problems.

3.2.5 Conclusion To achieve this service, there is no other possibility than to use a trusted center to serve either as a registry or a notary (unconditional trust), or to provide a timestamp (functional trust). This is not due to shortcoming of research, but to the very nature of the service.

Once the registry or timestamp center is established, classical services, such as non-repudiation services may of course be used. The techniques are in place and the integration in EDI has already been described. The next step before specification and design is of purely political and commercial nature.

Security in open environments, TEDIS II, B7, \er. 15. July 1994.

3.3 Claim of ownership 3.3.1 Background The goal to achieve here is that an electronic document at any particular time can be proved to be the (temporary) property of a particular user.

This is clearly required for negotiable or quasi-negotiable documents. The most interesting examples in trading are Bills of Lading apart from electronic cash, alreadymentioned in the introduction. For further explanation, we refer to Chapter With ordinary paper documents, the problem is solved by giving the original of a document certain physical attributes that are difficult to reproduce. With this precaution, it makes sense to speak of the original of a document, and define the owner simply as the person holding the original.

3.3.2 Definition The important property we have to focus on, is sometimes described as that of uniqueness. So the question is if we can find a suitable attribute on an electronic document which somehow would give it the property of uniqueness, explicitly or implicitly.

Even though is not clear at all if and how this can be realized, it is fairly straightforward to identify the service: Claim of ownership will allow a user to prove that he is the owner of a particular electronic document (even though there may be several copies around.

As mentioned, the coicept of an original does not make sense for electronic documents, and we must therefore employ other cryptographic) methods to make sure that the owner of a generic electronic document can be identified. The main question is to what extent this will involve a trusted third party.

3.3.3 Discussion Any document of some value must initially be generated by someone, who will guarantee this value. This requires the proof of, or non-repudiation of, origin service (one example is electronic cash, which is issued by a bank using digital signatures).

The question now is what should be done when an electronic document, once issued, is to chanue hands.

Security in open environments, TEDIS II, B7. 15. July 1994.

The use of tamper resistance to achieve ownership (or uniqueness) It is in fact possible to achieve uniqueness by cryptographic techniques, in the sense that violation will be detected. This is discussed further below. However, in the following we shall see how this may be greatly simplified by the use of tamper resistant units (such as a chipcard).

We point out that this problem, to realize freely negotiable electronic documents has not been analyzed so far in the literature. A detailed discussion will appear in a research journal (see In the following we merely give an overview.

The perhaps most obvious solution (see Ch. 5) is to introduce a TTP to register at all time the possession of a particular document (See Fig. But this does not seem to be generally acceptable, and it leaves the TTP with heavy liability burdens.

A tempting solution to consider might be to represent each (semi-)negotiable document by a chipcard. This was suggested in a recent TEDIS report, "Service Infrastruture for EDI Security" [OD15]. There is no doubt that this would prohibit fraud, assuming that the chipcard is tamper resistant. However, it would not provide any improvements concerning the very first reason to replace, say a Bill of Lading, with a corresponding electronic document: To ensure that when the cargo reaches its port of destination, the Bill of Lading has arrived, too, and the owner can claim the shipment. It will be just as difficult to get the chipcard there in time as the paper document! The only other way to provide uniqueness is to physically prohibit free copying. This would involve tamper resistance to realize a protected communication with restricted functionality, if possible.

The basic principle, we make use of for achieving uniqueness here is quite simple: A message encrypted under a key known to only one entity is unique, as long as it is encrypted, and establishes undisputable ownership by the mere fact that it will only be useful to the owner of the key. Only the person in possession of the right key can make any use of the document, which in effect is the property of uniqueness.

On the other hand, the only way the rightful owner can verify that the right B/L has been encrypted by his key is by decrypting it. But this will give him access to the message and he may subsequently be able to "sell" it to two different persons by encrypting it with their respective keys. Hence this must be prevented. This requires tamper resistant hardware, perhaps a chipcard, or a hardware protected PC. In the following this hardware will be called the DOC-carrier.

The DOC-carrier itself should be freely available, but stationary, and certified by some Certification Authority in the X.509 setup. The problem would then be to implement a system with the following properties: Security in open environments, TEDIS 11, B7, ver. 15..ul\" 1994.

a of this document...

0 1 would like to buy a copy -Who should I pay? *t SB made it! ,MeI No, me! Electronic Bills of Lading -The Conventional Solution A B/L is generated electronically, for instance by using non-repudiation of origin, in a tamper resistant unit and then loaded onto a DOC-carrier. This requires some care. It is essential that the signature thus appended to provide the non-repudiation is never disclosed. (It would of course suffice to represent the Bill of Lading by a hash value inside the DOC-carrier if storage is a problem) A B/L is transferred from one DOC-carrier to another, through a public unprotected network, in such a way that a) It can only be transferred as a meaningful document to one particular DOCcarrier b) Recovery is possible, if the transfer is unsuccessful c) The protocol cannot be simulated by any other device than an authorized

DOC.

The system should be completely open, just as any open EDI system, to communication between any two DOC-carriers, without bilateral agreements.

Further specification: (See Fig. 3) Each DOC-carrier "possesses" a public key pair. The secret key of this pair must not even be known to the owner of the DOC-carrier. It would be required to realize this in such a way that not even the system provider knows the DOC-secret keys.

The B/L has the form DOC S,(DOC), where S, is the secret key of the issuer (owner of the carrier of the cargo). Here, DOC denotes the electronic realization of a (quasinegotiable) document, and S(DOC) the digital signature of the issuer on a hash value of the document. The format could for instance be a special EDIFACT B/L message with security according to the proposal by the UN/EDIFACT Recommendation Document.

Now, the problem is that this shall only be released (which is the selling process) to another DOC-carrier. So the question is, how can one DOC-carrier identify another? The most attractive solution seems to be the following well-known approach: A (functionally) trusted party called the Certification Authority CA, authorizes all DOC-carriers in the following manner: The public key of the CA is installed on the DOC-carrier, as well as the secret DOC-carrier key, in a ROM, and in such a way' Security in open environments, TEDIS.11, B7, ver. 15. July 1994.

A0A ROM EEPROM protected against disclosure read only proteRction DOC I Sm (DOCI1) DOC21 Sj (DOC2) Crypto unit

SA

PCA

Cert(A)__ 2.

Verify Cert (B) 3.

Ps (DOC I II SI, (DOCI1) Cert(B), PB Cert(B)

PA

PCA

4.

DOCI1iSH (DOCI) EEPROMRM ROM that the secret key cannot be exported Moreover, when a document, or rather the accompanying key protected signature is entered on the DOC-carrier, the DOCcarrier software must ensure that it can only be released again encrypted under a public key certified by the CA secret key (and verified by means of the corresponding public key on the DOC-carrier). The point behind this is that it will prevent the use of a non-authorized DOC-carrier to get access to the vital signature S,(DOC), which defines the particular negotiable electronic document. In particular this enclypted message is useless excepted when imported in the DOC-carrier holding the corresponding secret key.

Furthermore, and this is an essential assumption, such an encryption of a particular B/L on an individual DOC-carrier can take place only once, or rather, once a public key has been selected, it is impossible at any later stage to go through the same procedure with another public key.

Such a system would solve the problem of uniqueness in general provided it works in practice. The difficult part, which also requires a careful analysis, is to recover from failure. In other words, the problem has been reduced to that of availability.

Even though this may be beyond the scope of this report, we will just briefly discuss this: First of all the DOC-carrier may go down. The only way to recover from that is to have the same information on a backup DOC-carrier. This requires that a protocol is developed, which ensures that the back-up card cannot be used to sell the DOC to a different entity. Another possibility is to demand that whenever a back-up copy is required, the CA must be contacted.

Secondly, something may go wrong with the encryption in a selling process. 7his will be easy to recover from, by encrypting once again under the same public key. 7he use of certificates will ensure with extremely high probability that the public key used for encryption is correct.

Thirdly, something may go wrong in the data transmission from one DOC-carrier to another. But this is handled by re-transmission. The encrypted version of a DOC needs not be protected In particular, a totally insecure network may be used to exchange the encrypted bills of lading.

Finally, something may go wrong in the receiving DOC-carrier. This could best he handled by a back-up card.

It is very important that only the B/L itself and not the digital signature of the issuer, will be available. The signature itself may only appear in a protected area in the DOC-carrier, and exported from one DOC-carrier to another encrypted under the public key of the receiving DOC-carrier.

UsSecurity in open environments, TEDIS II, 87, ver. 15. July 1994.

S

A related approach is to use the idea of electronic cash. The main problem here is that with current solutions, digital cash can only be spent once, whence is not really negotiable.

However, as this is at least a partial solution, we explain in the following the basic principles.

One important mechanism is that of undeniable signatures.

Undeniable signatures Digital signatures are easily verified as authentic by anyone using the corresponding public key. This "self-authenticating" property is quite suitable for some uses, such as broadcast of announcements and public-key certificates. However it is unsuitable for many other applications. Self-authentication makes signatures that are somewhat commercially or personally sensitive, for instance, much more valuable to the industrial spy or extortionist. Thus, self-authenticated signatures contain too much information for many applications. In short, co-operation of the signer should be necessary to convince another party that a particular signature is valid, and a signer, falsely accused of having signed a particular message, should be able to prove his innocence. The relatively newi "undeniable signatures" achieve the.se objectives.

An undeniable signature, like a digital signature, is a number issued by a signer that depends on the signer's secret key and the message signed. Unlike a digital signature, however, an undeniable signature cannot be verified without the signer's co-operation. For the verification, a recipient has to perform a confirmation protocol with the signer. In other words, a recipient of such a signature cannot show the correctness of the signature to other persons without the help of the signer.

Undeniable signatures were introduced in 1989 by Chaum and Van Antwepen To ascertain the validity of an undeniable signature, the recipient issues a challenge to the signer and tests its response. If the test is successful, there is a "very high" probability that the signature is valid. If the test fails, there are two possibilities: the signature is not valid or the signer is giving improper responses; presumably in an effort to falsely deny a valid signature.

But even if the signer has infinite computing power, the challenger can distinguish case from with very high certainty by means of a second challenge.

Undeniable signatures are preferable to digital signatures for many upcoming appli- Security in open environments, TEDIS II, B7, ver. 15. July 1994.

cations.

Applications: Consider, for example, the signature a software supplier may issue on its software, allowing customers to check that the software is genuine and unmodified. With undeniable signatures, only paying customers are able to verify the signature, and they are ensured that the supplier remains accountable for the software.

All manners of inter-organizational messages, such as EDI, are a natural candidate for signatures that provide for dispute resolution.

More recently Chaum presented an undeniable signature based on zero-knlowledge [Ch91a]. Also a disavowal protocol is given which allows a presumed signer to disavow a forged signature.

Boyar, Chaum and Danmgrd introduce in [BCD91] undeniable signatures which have the feature that they can be changed into (conventional) digital signatures by releasing some numbers to the verifier.

We can now explain the concept of Electronic cash (See Fig. 4) The main purpose here is to replace paper money or checks by an electronic version, a so called "electronic wallet", or "electronic cash".

When considering an electronic version some interesting problems immediately appear such as the uniqueness of an electronic coin, the untraceability of electronic cash, in order to guarantee at least the same features as with paper money. or checks.

The idea of electronic cash was introduced by D. Chaum 1985 [Ch85 j and the aspects mentioned above have been studied by others such as Fiat and Naor [CFN88], Okamoto and Ohta [0090]; den Boer et al We will describe in detail an electronic payment transaction which makes use of untraceable payments based on a so called "blind" signature This blind signature is a special extension of a digital signature.

This concept is easily understood by an analogy to carbon paper-lined envelopes. If you put a piece of paper inside such an envelope and a signature mark is later made on the outside of the envelope, the carbon paper in the envelope transfers the signature onto the slip.

Security in open environments, TEDIS II, B7, ver. 15. July 1994.

ELECTRONIC'CASH

co) COM PUTE

DIGITAL

SIGNATURE

USER

4 a,b aID bY

SHOP

aID bY (PECUI SEcu) S

A

Deposit

.SFCU

(number) 1~~-Electronic ECU-note (PECu,.SECU) Consider how you might use such envelopes to make payments. Suppose a bank had a special signature mark that is guaranteed to be worth one dollar, in the sense that the bank would pay one dollar for any piece of paper with that mark on it. You take a carbon-lined envelope containing a plain slip of paper to the bank and ask to withdraw one dollar from your account. The bank then deducts one dollar from your account, makes the signature mark on the outside of your envelope, and returns it to you. The signature is "blind" since the bank cannot see the slip through the envelope.

Upon getting the unopened envelope back, your verify that the proper signature mark has been made on it. When you remove the slip from the envelope, it bears the carbon image of the bank's signature mark. You can then go out and buy something for one dollar from a shop, using the signed slip to make the payment. The shop verifies the carbon image of the bank's signature on the slip before accepting it as payment.

Now consider the position of the bank when a slip is received for deposit from a shop. The bank verifies the signature on the slip submitted for deposit, just as the shop did, and puts a dollar on the shop's account.

Because the signature was verified correctly by the bank, the slip must have been in an envelope previously signed by the bank. But naturally the bank uses exactly the same signature mark to sign many such envelopes each day for all its account holders, and since all slips were hidden by envelopes during signing, the bank cannot know which envelope the slip was in. Therefore it cannot learn which account the funds were from. More generally, the bank cannot determine which withdrawal corresponds with which deposit the payments are untraceable.

In actual computerized systems, the envelopes and slips of paper are replaced by numbers, the bank's signature mark by a digital blind signature, and payments are unconditionally untraceable.

The basic protocol is as follows.

The batk has announced that a certain public key pair, (PEU,SEcu is used to i.sue w ECU-notes. Any user may now proceed as follows: 1. A' chipcard creates a note number n of some standardized format chooses some random number r, and calculates NOTE numberxPEcu(r) using the bank's public key and sends this to the bank.

S Security in open environments, TEDIS II, B7, ver. 15. July 1994.

:77-D 2. The bank deducts one ECU from A's account, and signs the received vahle with his private key to obtain SECU(NOTE) SsEc(number)xr This number is returned to A.

3. A's card checks the returned value (by applying PSEC to get the number NOTE back) and subsequently divides out the random r. In this way A obtains the signed electronic bank note, SECU(number) which A goes to spend in a shop (anonymously).

4. The shop itself checks that what it received is a special signed number (by applying the bank's public key) and forwards a copy to the bank for deposit. 7he bank checks the signature and accepts if this particular note number has not been deposited yet. These numeric notes are unconditionally untraceable if the individuals do not divulge the random numbers r produced by their personal computer card.

The observant reader might think here: This easily lends itself to misuse, unless the shop has an on line connection to the bank: A just copies the electronic banknote and spends it over and over again in different shops. To prevent this, a more elaborate model has been developed for the off line situation. Here the spender engages in an interactive protocol, where he gives away a mathematical equation hiding his identity and the name of the bank, say. The coefficients are random numbers chosen by the shop. This equation is forwarded with the banlkote, and if the same note is spent twice the bank receives two different equations and can solve for the identity of the violator.

Here, the even more observant reader thinks: Well, if enough money is involved who cares about having his identity revealed. By that time, the cheater may already be in South America. To prevent this situation, the protocols have recently been improved with the introduction of tamper resistant devices, called observers, which simply prevents that the electronic cash can be spent twice.

The idea has recently been described by D. Chaum in an article in Scientific American [Ch92] However, one more important step is necessary, to implement electronic versions of negotiable documents: It must be possible to sell the document without the use of a third party, like the bank. The shopkeeper cannot go and spend the electronic cash in another shop. He must cash it in at his bank.

Security in open environments, TEDIS II, B7, ver. 15. July 1994.

For this reason, another approach has to be chosen with electronic versions(. of negotiable documents.

3.3.4 Practical aspects The discussion in 3.3.3 suggests a solution based on a mixture of well-known cryptographic techniques and extensive use of tamper resistance.

We think it might be useful to explain in a diagram the functionality of the chipcard in the latter solution. With the notation of the discussion above, this gives an overview of the design of a DOC-carrier (see illustration) The protocol is the following between two DOC-carriers A and B: 1. The certificate of B is forwarded to A 2. A verifies the certificate of B If this is successful, 3. A encrypts the relevant electronic B/L (DOCI, incl. defining signature S,(DOC I)) with the public key of B and forwards this to B 4. B decrypts with its secret key and is now the owner of DOCl 3.3.5 Conclusion Contrary to electronic cash, we do not find that a satisfactory realization of electronic versions of (quasi-)negotiable documents can be achieved without the extensive use of tamper resistant hardware. The approach to electronic cash is insufficient. In the most efficient implementations of electronic cash, an electronic coin can only be negotiated once. In general it turns out that an untraceable negotiable electronic document must grow in size each time it changes hands, i.e. carry its history so to speak, which is unsatisfactory.

To realize a solution which does not require an unconditionally TTP, we have introduced what we call DOC-carriers, typically a chipcard. Anyway, the main difference between electronic cash and electronic negotiable documents is that cash can only be spent, or sold, once, where as electronic negotiable documents can be sold an indefinite number of times.

The point of a DOC-carrier is that tamper resistance will provide the required attribute of uniqueness: It is possible to develop cryptographic protocols, which will allow each DOC- Security in open environments, TEDIS II, B7, ver. 15. July 1994.

carrier in possession of a B/L to sell that B/L only once, and only to another DOC-carrier.

Moreover, and this is important, this does not require the use of an unconditionally trusted party, only a functionally TTP, namely a CA as described in the well-known X.509 architecture.

Any other realization would either require the use of an unconditionally trusted party, or have the problem that even though fraud can be detected, it may often be too late to catch the criminal.

The integration of security into the electronic version of the Bill of Lading is in principle trivial.

It could be done along the same lines as currently suggested by the UN/EDIFACT Security Joint Working Group, ifEDIFACT format is used for an EDIFACT B/L.

€G

Security in open environments, TEDIS II, B7, ver. 15. July 1994.

3.4 Fair exchange of values 3.4.1 Introduction When negotiable trade documents change hands, they are often handed over in exchange for something else, for example another negotiable document, some form of payment, or simply some piece of information that may be of sufficient value to the receiver.

The party who gives a document away may of course be concerned with the possibility that he may not receive in exchange the object or the information he was supposed to.

If the parties meet physically and exchange ordinary documents, this concern may not be vely serious: an attempt of abuse is likely to be detected early enough to prevent a successful fiaud.

In the world of (interactive) EDI, however, the problem can be more serious: efficient communication is possible over great distances with parties to which there may be little or no existing business relations. Such parties may well be found worthy of less trust than those with which physical meetings can be arranged.

3.4.2 Definition Fortunately, the very fact that the communication takes place digitally provides a basis for a solution to the problem: if a certain piece of information is represented as a string of bits, there is no need to release at once the entire information to an untrusted party. One can in stead release small parts of it, such that each part is released only after receiving something of sufficient value from the other party; this could be a partial payment, or parts of another document. (See Fig. If executed correctly, the above method provides an exchange which is fair in the sense that if one party stops the conversation early, both parties have only received part of what they were supposed to; moreover, we can arrange it such that at any time, both parties have received approximately the same amount of information or value.

3.4.3 Discussion So far we have not said anything about the possibilities of cheating in the above exchange protocol. It is clear that the party sending parts of a bit string may choose to send incorrect, worthless bits in stead of the genuine parts he was supposed to send. The problem is that this may not be detectable for the receiver until the entire information has been received, at which time it may be too late. This is where cryptographic techniques are useful. It turns out to be possible for the sender to compute some extra information which will be sent along with Security in open environments, TEDIS II, B7, vdr. 15. July 1994.

2 7 o Number of bits received_ Reconstruction is: not feasible Grey Area feasible 512 bits NOT ALL BITS ARE NECESSARY TO RECONSTRUCT A DIGITAL SIGNATURE -THERE ARE ONLY TWO POSSIBILITIES FOR EACH

BIT!

L_ every part, and which allows the receiver (directly or by interaction with the sender) to verify that what he received was in fact part of the information he is expecting to get.

This problem is known in cryptologic research as the exchange of secrets probleni. A large number of articles are available on the subject, and it is fair to say that the problem has been solved, both in a theoretical and a practical sense. A typical concrete example of a scenario where exchange of secrets may take place is the following: Suppose party A is the current owner of an electronic (quasi-)negotiable document such as a Bill of Lading, and wants to sell it to party B. A therefore digitally signs a statement to the effect that ownership of the document is now transferred from A to B (see the discussion on Claim of Ownership for details on this). B has in his possession a signature from e.g. a bank.

This represents some value (for example, it may be an electronic bank note of the form described in the sections on Claim of Ownership). B is willing to give this signature as payment to A in exchange for ownership of the Bill of Lading. A is concerned, however, that if he sends his signature to B, he may never receive the payment.

In this scenario, an exchange of secrets protocol can provide methods by which the signatures can be transferred gradually, even down to the level of 1 bit at a time, such that each piece of information sent can be verified as being correct. This ensures that B cannot become capable of producing A's signature, without simultaneously A being able to produce the signature that represents the payment.

The main disadvantage is that, by the very nature of the problem, a number of transmission shifts are required. This is time consuming, but this could be kept within reason. Recent progress in research in fact solves this problem (see [D92]).

3.4.4 Practical aspects The only problem here would be to implement a protocol, which would realize the exchange. As an example, one may have the scenario of bills of lading in mind. If these are realized electronically, one could imagine a situation where two negotiable documents, of equal value, could be exchanged in a fair deal. Any other method might be dangerous, as it might introduce incidents, where we would know the identity of a criminal, but only after the execution of the crime and without any possibility to locate his whereabouts.

It will not make sense to go further into this until electronic documents of value have been realized. However, once this is achieved, fair exchange of values will be indispensable.

3.4.5 Conclusion At i is possible to exchange electronic documents of value, such as unique documelnts or Security in open environments, TEDIS II, B7, ver. 15. July 1994.

commitments with digital signatures in an interactive protocol, which will not allow any participating party to cheat. The framework for this could be the forthcoming UN/EDIFACT recommendation for Interactive EDI, which is sufficiently spacious to integrate the communication required for fair exchange of values.

The integration of this service could be achieved on the basis of the coming I-EDI proposal and the Recommendation Document on Security in UN/EDIFACT. However, at this stage it is premature to take further steps, as the service would assume much more extensive use of digital signatures in open EDI.

Security in open environments, TEDIS II, B7, ver. 15. July 1994.

Interactive authentication (with key exchange) 3.5.1 Introduction As pointed out in [UNIO], all basic security services will be required in Interactive EDI (IEDI). Furthermore, there is a special need to secure message sequence integrity. In most scenarios, there seems to be a need for the involved parties to identify themselves and then exchange a series of messages. The final message might require a digital signature.

I-EDI may involve numerous players. The framework for communication between any two follows the EDIFACT Header-Trailer approach: The communication is initiated with a UNB segment and terminated with a UNZ segment. Each separate transmission will have the EDIFACT format, UNH...data...UNT:

UNB

UNB

UNH.....UNT

UNH.....UNT

UNZ

UNZ

3.5.2 Definition What is needed here is mutual identification of the parties involved, and this identification might also involve an exchange of a key which subsequently could be used for message authentication. Such effective schemes exist based on public key techniques and zeroknowledge protocols. Currently ISO/IEC JTCI/SC 27 is standardizing authentication protocols (CD 9897) and identification based on zero-knowledge techniques is a work item, too. (See Fig. 6 7).

Security in open environments, TEDIS II, B7, ver: 5. 5.July 1994

CE

CARELESS IDENTIFICATION Public key PA Secret key SA 1 Choose r Compute R=PA(r) 2 Send R 3 Compute

X=S,(R)

4 Send X Check X=r ZERC KNOWLEDGE IDENT "ICATION Public key PA Secret key SA Box I r 1 Choose r Compute R=PA(r) 2 Send F 3 Compute

X=S,(R)

Box II X 4 Send r Send key to Box I Check X=r Send key to Box II -b 5 Check X=r 3.5.3 Discussion The idea behind zero-knowledge techniques is the following: Typically, the scheme of an entity authentication is that the verifier sends a so-called random challenge which the prover then signs with his key and returns. The problem with this is that the verifier can use the prover as what is called an oracle: The verifier choose the challenge, and he might be able to build up a (chosen message) attack in such a protocol. The point of zero-knowledge (only with public key techniques) is that the verifier only gets to choose the challenge in such a way that he himself already knows the answer. Typically he chooses a random number, and the challenge he produces is then that random number encrypted with the prover's public key. The result returned by the verifier should be the random number, and thus the verifier has learnt nothing from the protocol, except one thing: That the verifier knows the secret key. Indeed, the verifier was able to produce the random number from the challenge, and this is only possible by means of the secret key. See below for further details.

Such protocols do exist. Typically, an application would be that parties first identify themselves through the protocol, which involves the key exchange. This requires one message in each direction. The subsequent dialogue is then carried out with authentication, which is much less time consuming than producing digital signatures all the time. The last two messages may then contain digital signatures related to the whole dialogue.

Zero-knowledge protocols: In modern computer networks, people often have to possess private iinformation in order to be able to use the services of the net.

This information can be passwords, keys to cryptosystems, etc. One important property we want to enforce is of course that the private information stays private, even though it is used in the interaction between different users.

So, how do we devise ways of talking to each other, i.e. protocols, with the property that we can control exactly how much information is communicated in a conversation? One example showing the need for this is the case where a user is identifying hitself to a host computer by means of a password. The often used solution sending the password in clear-text to the host has the following theoretical problem: From the point of view of the host there are only two possibilities: either the party who wants to log in is who he claims to be, or he is not. In more technical terms, what this means is that the host needs only 1 bit of information from the user, revealing whether he possesses the correct password or not. But the ordinary password protocol in fact communicates many more bits of significant information, namely a// Security in open environments, TEDIS II, B7, ver. 15. July 1994.

the bits representing the password itself This theoreticfault has a very real consequence: anyone can eavesdrop on the lines leading to the host, and after this pretend to be any one of the users, from which they, have picked up passwords.

In the last few years, a large number of so-called zero-lkow-ledge protocols have been developed, together with a mathematical theory enabling us to prove properties of such protocols. The most important characteristic of zero-lkowledge protocols is the fact that they communicate exactly the information they were designed for, and not more. In the user identification example above, this means that the user, by exchanging messages with the host, can prove that he possesses a secret piece of information identifying him uniquely, but without releasing any information whatsoever about this secret.

This clearly makes eavesdropping useless if no information about the secret is released, an enemy cannot learn anything from a conversation that would help him in impersonating the real user.

These ideas fit perfectly well into public-key cryptography. If a public key has been -certified as belonging to a specific user, this user can identify himself by proving il zero-knowledge that he possesses the corresponding secret key. As described earlier in this report, one can even arrange for a key to a conventional cryptosystem to be exchanged simultaneously with the zero-knowledge proof.

To give the reader a feeling for the techniques used in such protocols,. we give a simple intuitive example: Suppose A has secret key S ,and the public key P, is okown to B, who would like to verify that A really possesses SA.

A simple way of doing this is for B to choose a random message M, and send the encryption C= PA(M) to A. A receives C, decrypts it under and sends the result M' to B, who can check ifM=M'. If this holds, A must be in possession of SA, since this is what is required to decrypt ciphertexts encrypted with PA.

Although this is fine from B's point of view, it is unfortunately a very insecure solution for A: ifB does not follow the rules, but in place of PA(M) sends a ciphertext he would like to get decrypted, A will give him the cleartextforfree! something that B could never have computed on his own. For some variants ofRSA, this could even enable B to find S,.

The solution to this is that after receiving PA(M), A will not return his decryption result M' in the clear, but will encrypt it using a special technique called a bit Security in open environments, TEDIS II,B7, ver. 15. July 1994.

commitment. Intuitively, this is equivalent to putting M' in a locked box and sending it to B. B will now have to sendM to convince A that B has followed the rules. Only then will A give B the key to the box. B can then open the box and check that the M' contained in it really equals the M he chose.

The point of all this is that B learns nothing he did not know already: he can only get to open the box in the final stage, if he has demonstrated by sending M that he already knows what is inside! Therefore B is now no closer to finding A's secret key than before the protocol.

On the other hand, A still cannot go through the protocol successfully without knowing SA: he has to decide what to put in the box based only on the encryption By the time he learns Mfrom B it is too late he has already given the box to B and cannot change the contents.

3.5.4 Practical aspects As mentioned earlier, this will be of great use in Interactive EDI. Once standards for I-EDI are developed, it will be very easy to integrate security services based on the philosophy which is currently being used in EDIFACT.

As an example, consider inquiries about air fares. The dialogue would start with an initial identification, requiring one message in each direction, which in complexity would correspond to the computation of a digital signature. Even in software, this would require between 0.25 and 2 sec. for each of the two messages. The subsequent messages would then be authenticated by means of a MAC, which can be computed in virtually real time. The very last steps, in which a ticket is ordered and confirmed, could then involve digital signatures, which again would require additional 0.25-2.0 sec. The details are described in [BDLP88].

Luckily enough, such a protocol is now been standardized within ISO/IEC SC27 as part of the Key Management Standard 11770-3. The protocol has been evaluated in the RACE project RIPE and recommended for use (See [OD9]).

Oblivious transfer This is a cryptographic technique that enables A to send a single bit b (0 or I) to B in a very special way: the protocol used must be specifically designed to make communication of b somewhat "noisy": with probability 50% B will receive b, and with probability 50% he will receive nothing (but he will know which of the cases occurred). On the other hand, A does not find out if B received the bit or not.

~STr"K.

-'2 Secarity in open environments, TEDIS II, B7, ver. 15. July 1994.

it must be the case that none of the parties can get more information than they are supposed to by deviating from the protocol: A cannot get any indication as to whether B received the bit, and B cannot increase his chance of receiving it.

It is not obvious, to say the least, why this would be a useful cryptographic technique. Nevertheless, oblivious transfer can be used to implement e.g. the fair exchange of values service mentioned earlier in this report. In fact theoretical results show that oblivious transfer can be used as a basic primitive to implement a solution to any protocol problem, although not in an efficient way.

It is therefore clearly a very fundamental cryptographic technique that may find new applications in the future.

For more details, we refer to [B181].

3.5.5 Conclusion The presented security service would be the foremost security service required in I- EDI. If the current draft proposals for Interactive EDI is accepted, the general approach to security in EDIFACT could be used to integrate this service without problems, and a proposal will be forwarded to the I-EDI working group for consideration. We refer to Chapter 5 for more details.

~ST,c Security in open environments, TEDIS II, B7, ver. 15. July 1994.

3.6 Anonymity, or untraceability 3.6.1 Introduction As electronic registration and transportation of data becomes more common, there is an increasing number of scenarios where individuals face new threats against their privacy: since many types of personal data can easily be traced to particular individuals, the fact that the data are electronically stored introduces the possibility that someone could efficiently collect comprehensive dossiers on individuals, even without this becoming known to the users themselves.

3.6.2 Definition In its most general form, anonymity or untraceability is a service with the goal of preventing personal data, or data related to a person (like voting) from being traced and collected.

One scenario where anonymity exists in paper-based systems is payments by cash. Whenever a person spends real cash, he is anonymous. It is practically impossible to trace the payment back to that particular person (assuming he wears gloves(!)). Thus anonymity is an important issue when cash is realized digitally. Solutions exist using cryptographic techniques that will ensure untraceability of electronic cash. We already discussed these solutions in the section on claim of ownership, where another aspect of electronic cash, namely uniqueness, was used.

3.6.3 Discussion A number of general solutions to various scenarios demanding anonymity have been proposed in research, using so called "digital pseudonyms". Many different pseudonyms can be associated to each user, but in an untraceable manner to other parties, thus preventing an enemy from linking different transactions or acts made by the same user, and also preventing him from tracing a transaction or an electronic vote to a particular individual, which is what is meant by anonymity.

A second scenario, where anonymity could be important, is in connection with registration of user-related data in a data base.

The difference between anonymity and confidentiality should be clearly understood: Both are properties relating to data, although the data of course may refer to a persons identity, or relate to a person.

i, Security in open enironments, TEDIS II, B7, ver. 15. July 1994.

I--

Confideniiality simply means that the data is not disclosed to an unauthorized person.

Anonymity means that the data may not be traced to a particular person: It is untraceable, practically or, preferably, even logically.

The mere fact that something is encrypted does not necessarily mean that it is untraceable. It simply cannot be read! When we speak of untraceable data, we always mean "meaningful" data, which for some logical or other reason cannot be connected to a particular person.

Let us describe a scenario where anonymity is realized.

Consider a set of institutions D D, collecting information on a large number of individuals.

We want to set up a large common register CR containing all information from all institutions.

This raises some security problems.

Outsiders can get access to a complete set of personal data about anyone, just by breaking into one database.

Any Di can read data about any individual registered in CR, since it has access to CR.

The obvious solution to consider is to have a confidential central database of individuals and their assigned, and in principle traceable pseudonyms. But this would mean that the whole setup depends on the protection on this database. It would require unconditional trust. The difference between this solution and the one to be described in a sense is like the difference between public and conventional cryptographic techniques.

The purpose of anonymous and verifiable registration in databases is to secure CR against unwanted use of the information it contains. Note that the personal information itself is not secret, only the link between names and particular records in CR is confidential.. Thus anonymity is a service different from confidentiality. This has the advantage that all kinds of statistical data can be extracted without compromising any individual. (We are not discussing here the problem of indirect identification. Statistical data that can be extracted should always have a degree of generality, i.e. involve sufficiently many persons to guarantee the anonymity.

To achieve this, each person A is characterized by some unique identification denoted ID(A), which is kept confidential. Data sent to CR relating to A has to be accompanied by an encryption F(ID(A)) of this identification. Thus each record is identified by such an encrypted identity. But how this encryption is achieved is very important. It will not suffice to encrypt by means of a conventional algorithm and a fixed key. (See Fig. 8) The properties required of such a registration to. fully protect the individual are S Anonymity: Security in open environments, TEDIS II, B7, vtr. 15. Jul' 1994.

lnfl(Ay--O,,..

Hospital Inf(A) lnf 2

(A)

.lInf(A) PuMo'MI SUM CAWd

W(ID(A)).

Given an individual registration in CR and an actual person, it is hard to decide whether they match. Even when F(ID(A)) is known and ID(A) and ID(B) are given, it is hard to decide whether ID(A) or ID(B) matches This would imply that we do.not have to keep a well protected database of pseudonyms at each site. The pseudonyms may be left unprotected. And, even more holds: There is no masterkey available, which can provide the connection.

Verifiability: Each individual A can be given access to CR to check that his data are correct, and prove whether or not he is identical to a given person registered in CR. This is achieved by the introduction of a so called witness w(ID(A)) with the property that both ID(A) and F(ID(A)) are easily computable from The witness can only be released by the individual.

Independence: To protect against an enemy who knows the identity of some registered individuals, we require that the anonymity condition holds for each individual A, even if one is given full information (identification and witness) about other persons.

A conventional system would fail to guarantee any single one of these properties.

3.6.4 Practical aspects Based on a number of reactions, we believe these methods could find great use in connection with databases on differeht categories of citizens, such as medical records, criminal records, etc.

We would like to stress that the point is to ensure that any degree of protection of the privacy of the citizen could be achieved, yet having records, from which general information, e.g.

statistical, could easily be established. As an example, one may have HIV-positive people in mind. It would be extremely useful for the patients as well as for the society to have full information, but untraceable to the individual.

To understand better how the system would work, we briefly describe the scenario. Each citizen has a chipcard with his true identity and his "witness" on. From this his pseudonym is produced. Whenever he registers at a doctor or a medical center, his pseudonym is verified by the system to be correct in a zero-knowledge protocol between the card and the center. His record is then updated as the result of an examination, and forwarded to an appropriate database, where it is registered under his pseudonym. If he chooses to reveal his identity to the doctor, which to most people would be quite natural, he may of course do so. The system Security in open environments, TEDIS II, B7, ver 15. July 1994.

Anonymous Registation Witness (the only liaison to A) W(Id(A)) Identity Id(A) F(Id(A)) Pseudonym Database II F(Id(A)) Database I F(Id(A)) Database III F(Id(A)) Only A can provide the connection (the witness) between Id(A) and F(Id(A)).

could easily hide the pseudonym to the doctor. (See Fig. 9) The relevance to EDI is that all sorts of institutions (health care, medical research, etc.) may extract information from the database(s) by means of EDI. What we can promise is that this system can be build in such a way that the individual is completely protected.

However, the first step will be a political decision on the realization of such databases. This is much harder to obtain.

3.6.5 Conclusion Methods have been developed in cryptography, which would allow the implementation of cential data base systems, based on individuals in, say the EEC, which at the same time would provide complete anonymity to the individual, yet be open to extract any reasonable statistical information. The impact would be quite important. It would be possible at the same time to have all data available for statistical evidence, say for HIV-positive persons, who volunteer to register, yet guarantee the protection of the individual, not based on unconditional trust, but on logical protection, which can only be penetrated if some of the hardest known mathematical problems can be solved.

Thus the realization of this service only depends on political decisions. It would be premature to explain in greater details how to integrate the present service.

Security in open environments, TEDIS II, B7, ver' 15. July 1994.

4 The use of Trusted Third Parties Prior to the presentation of the services in the previous chapter, we clarified the concept of and use of Trusted Third Parties. It therefore seems in place to discuss in which situations a TTP is required, and in which role.

Before we argue that a TTP will be needed for a number of services, not by shortcoming of cryptologic research or any other technique, but by nature of the services, we want to recall some fundamental principles: An electronic (version of a) document is just a particular combination of bits, which can be read according to some (agreed) rule. Consequently, there are two methods by which a document can be secured in some way: Either by tamper resistance, which will prohibit any tampering with the electronic document, or by cryptography, which will detect any tampering, or of course any combination thereof In any case it is imperative, that the functionality can be trusted.

4.1 The various roles of TTP's The most obvious need for Trusted Third Parties in data security has already been explained. We would now like to expand on this and discuss a number of other applications.

The role of a TTP is related to one of the following Support services Notary services Support service indicates that the TTP is there to support the user, or entity to make use of security services. This includes registration and certification, service messages related to key management, and possibly even key generation, directory services, and more. Support services roles therefore at least include Registration Authorities Certification Authorities Directories (Key generation) Notary services cover the need for independent third parties to witness certain business acts or certify authorization and socalled user attributes. As examples of this, we mention Security in open environments, TEDIS I1, B7, ver. 15. July 1994.

Independent Time Stamping of documents and signatures Legal attributes of entities Access attributes Archiving and registration (documents, ownership, etc.) Witness services (typically notary functions) A recent INFOSEC study based on interviews discusses various business requirements for trusted third parties See also the Green Book 4.2 TTP Support services A well designed security system is transparent to its users in the daily primary production, apart from the necessary access control to the system, which allows the user to apply the security services.

The security system as such should only become visible in the following situations: 1. The initialization phase 2. A requested or regular service message 3. A cancellation phase In case public key techniques are used, some measures must be taken to provide evidence of the connection between the public key and its owner. This could either be handled directly in a bilateral agreement between the owner and any other partner, or by the use of Functional Trusted Third Parties, called Certification Authorities as described in the CCITT standard X.509, where evidence is conveyed by the use of so-called certificates. A user is identified by his credentials, (some appropriate identification) including his public key, and the certificate is a digital signature of the Certification. Authority on the credentials. Any other registered user in possession of the public key of the CA will then be able to verify the ownership of a public key by means of the certificate.

The first step in this setup is to register the user based on a proper identification. This is handled by a socalled Registration Authority (RA) (as described in [OD Of course, in an actual solution, the RA may be part of the CA setup. But the nature of the two is different.

Typically, a user will use an RA in his neighbourhood, like a local bank branch, or his lawyer, where as the CA is centrally placed and has no physical interaction with.the user it certifies.

(See Fig. The smoothness of the X.509 architecture. relies entirely on the effectiveness of the Directory of all the users of the system. The Directory could be the responsibility of the Certification Authority and maintained at the Certification Center, the physical center operated by the CA, or it could be managed by an independent third party, .which have to establish a business Security in open environments, TEDIS II1, B7, vetr. 15. July 1994.

relation with the CA.

The initialization phase a) Registration: A user is registered on the basis of his credentials. The advanced system would require that a potential user is always geographically close to a "branch office", a local RA, where the registration can take place. This could be further elaborated through an endorsed registration, say carried out by a security officer of users in a particular company. Thus a domain of users (users who are entitled, by the CA, to communicate with security services added) in effect requires a net of local RA's, operated by security officers responsible for the physical recognition, according to some security declared policy.

b) In order to prove to any other user that a particular user is registered with a particular public key, certificates are used. They are but a digital signature of the CA on the credentials of the user, including his public key. However, the certificates are only issued at the Certification Center. (Notice the much broader definition of a:certificate here than in X.509).

Service messages will vary from system to system' In systems based on conventional cryptography, this may involve a key exchange. But the primary security service function of the CA is to verify the current validity of a certificate for an inquiring user.

Likewise, it will be necessary for the CA to currently renew certificates, in order to keep the black lists as short as possible.

Cancellation phase: It is a general misconception that the use of certificates makes the CC superfluous after registration. In an open system, which is not based on bilateral agreements between communicating users, it must be possible for a user to cancel his certificate at the CA.

Of course this requires some secure protocol, which prohibits misuse. But more importantly, the implications of this is that some kind a clearing arrangement will be necessary in many scenarios on transactions based on certificates. This would typically at least imply the maintenance of black lists or even positive lists by the CA.

The meaning of trust should be reiterated here: Any open system requires some trusted party to carry out a number of operations. It may be purely functional, as in the X.509 architecture, where the CA is trusted with registering responsibilities only. Likewise it may be desirableto let the CA be responsible for some certification of the applied soft- and/or hardware. But again this only implies a functional trust, nothing more.

In other systems based on conventional methods, a user has to trust the key distribution center with some secret key or perhaps even to be assigned a secret key generated by. a central key generation facility. If some authority in principle has or.has had access to the user's keys, we speak of unconditional trust, as mentioned earlier.

Security in open environments, TEDIS I1, B7, ver. 15. .luly 1994.

For notary TTPs, this taxonomy may not be so appropriate. However, it would be reasonable to call any TTP, which needs to be consulted in order to provide evidence an unconditional trusted third party. The point we try to make is that by using cryptographic methods, we can reduce the need for UTTPs considerably.

4.3 TTP Notary services 4.3.1 Time stamping One important purpose of independent time stamping is the following: If the certificate of a public key is canceled on the grounds that the corresponding secret key has been compromised, a previously calculated digital signature by the said secret key would retain its legal value, if an independent time stamping had taken place before the cancellation of the certificate.

The user simply collects any number of EDIFACT digital signatures over a period of time (one day, one month,...) and sends it off to the TTP(TS) for time stamping. The TTP(TS) adds the TS and a digital signature and returns the message.

Time stamps What is "time-stamping" an electronic document? Time-stamping an electronib document means time-stamping the data itself, without any reliance on the characteristics of the medium on which the data appears, so that it is impossible to change even one bit without the change being apparent. Timestamping implies as well that is impossible to stamp a document with a time and date different from the actual one.

Let us first describe a bad solution.

Under the assumption that a time-stamping service (TSS) exist, one could propose to simply transmit the document to be time-stamped to the TSS, which would store a copy of it. The main disadvantages of this simple solition are 1. Privacy The dociument can be eavesdropped by a third party before it gets to the TSS, and even if it gets there without being eavesdropped, it is generall V Security in open environments, TEDIS II, B7, ver. 15. July 1994.

available to the TSS itself 2. Bandwidth and storage Sending the entire document could take too much time, and the amount of storage required at the TSS could be too much.

3. Incompetence A document could be corrupted during transmission, could be incorrectly time-stamped, or become corrupted or lost while stored 4. Trust Nothing prevents the TSS from colluding with a client in order to claim to have time-stamped a document for a date and time different from the actual one.

A better solution is the following, which still only assumes that the TSS is functionally trusted.

Instead of sending the entire document, the client computes a hash value of the message, and sends this to the TSS. Then, the TSS appends date and time, signs the document digitally, and sends the result to the client. By checking the signature, the client is assured that the TSS actually did process the request, that the hash was correctly received, and that the correct time is included So problems and are solved, and problem has been considerably reduced.

The following advanced and interesting solution is described in [HS91].

Linking A first solution can be achieved if the TSS includes some bits from the previous sequence in the signed time certificate. Indeed, this guarantees that the document had been created after the previous sequence of client requests, and it constrains as well the time in the other direction since the TSS cannot issue later certificates unless it has the current request in hand. This could be achieved as follows: The TSS will make use of a collision-free hash function H. The time-stamping request consists of a hash result Y and a client identification number ID. Assuming this is the nth request in sequence, the TSS now returns the signed time-stamp certificate, which takes the following form: s S(n, tID, Y,;L) Secority in open environments, TEDIS II, B7, ver. 15. July 1994.

in which denotes the signing procedure, n the sequence number, the time, ID,, the client number, Y, the hash value from the request, and L, the linking information, which comes from the previously issued certificate: L, In addition to this, after the next request has been processed, the TSS sends the identification number to the client.

After receiving s the validity is checked by the client.

If later someone wants to check the validity of the time-stamped document, the challenger checks if the time-stamp ID,L) is of the correct form. In order to make sure that the client has not colluded with the TSS, the challenger can call client ID., and ask him to produce his timestamp certificate and successor identification which includes the signature S(n+1, t.

of a timestamp certificate that contains in its linking information a copy of the client's hash value This linking information is further authenticated by the inclusion ofH(L). If the challenger is especially suspicious, he can call up client and verify the next time-stamp in the sequence, etc. Similarly, the challenger can also follow the chain of time-stamps backward, beginning with client This scheme requires that clients must keep all their timestamp certificates, which is quite reasonable: Otherwise, there is no reason to acquire it. Nevertheless, this can be relaxed if each request is not just linked to the next request but to the next k requests. We refer to the original paper for details.

4.3.2 Legal and access attributes As user related attributed may change quite often, it seems a better idea to define and enhance them in special certificates. Indeed, Public Key Certificates should not be change to often, as this creates a lot of administration overhead. Indeed, if any parameter in a public.key certificate is altered, the certificate is no longer valid.

As for legal attributes, this any way is very much in accordance with what is done in the paper world. Each country has a register of companies and the executive rights of various persons working for the company. This is exactly the situation we want in the electronic world as well.

Likewise access control to e.g. databases can be handled on the basis of access attributes created and digitally signed by appropriate third parties.

Security in open environments, TEDIS II, B7, ver. 15. JuIly 1994.

4.3.3 Archiving and registration As explained, claim of origin presumes the existence of a Trusted Third Party. Other examples of such parties exists as well. For instance, securities (bonds and stocks) are mostly registered electronically, only, in Denmark, in as far as negotiable documents on the stock exchange are concerned. The ownership of the documents is simply registered at all time by the Danish Securities Center, without the use of cryptographic methods, but ensuring the integrity of the whole system by access control and very strict business procedures.

4.3.4 Witness services In certain countries there are great traditions for involving third parties in a number of transactions, socalled notaries. In others, this is hardly used at all. Naturally, as we proceed towards purely electronic handling of a number of business cases, we can replace the traditional notary function with a similar purely electronic function, if the laws of the country will permit that. For more on this, we refer to [OD12].

Security in open environments, TEDIS II, B7, ver. 15. July 1994.

Review of relevant trade documents In the following, we will first briefly mention some of the documents on trade and legal aspects we studied. When appropriate, shorter statements, which have been relevant for this report, are quoted. At the same time this will serve as an indication of the scope of the document.

This is followed by a case study of the BIMCO project, which should serve to illustrate the practical aspects of what we are trying to achieve.

5.1 Review of some documents on trade Quotations after the citation are in italic.

Facilitation measures applicable to particular, selected procedures: Acceptance of Facsimile Signatures on Export Documents. TRADE/WP.4/R.555/August 30, 1988.

Authentication is required for three main purposes, firstly.for National legislation, secondlyfor International legislation and thirdly for Commercial practice.

SITPRO is of the opinion that the present requirements for manual signatures should be replaced wherever practicable by facsimile signatures.

*Implementation of ECE/FAL regommendation no. 12: Measures to Facilitate Maritime Transport Documents Procedures. (Project TRADE/WP.4/-R.605/July 3, 1989.

CMI Uniform rules for Sea waybills: These Rules are intended to apply to contracts of carriage not covered by a negotiable Bill of Lading or similar document of title.

They shall apply when incorporated in any contract of carriage, whether the contract be in writing or not.

Legal aspects of electronic data interchange: Definition of an "Electronic Document".

TRADE/WP.4/R.649 December 22, 1989.

With the possible exception of the paper based function of negotiability, it is generally accepted that an electronic message, especially one interchanged on the basis of the UN/EDIFACT standards and supported by ant interchange agreement based on the Uniform Rules of Conduct for Interchange of Trade Data by Teletransmission (UNCID), is superior to a paper document in respect of cost, speed and Security in open environments, TEDIS II, B7, ver. 15. July 1994.

security, the latter not least thanks to the in-built controls.

Legal aspects of trade data interchange trade/ WP.4/ R.697/ December 27, 1990.

EDI itself produces other versions ofpre-conceptions. Some experts have suggested giving attributes to EDI "documents" that have never been given to the paper equivalents some ideas on security are such that, if thought necessary, one may ask why haven't all documents gone by registered post). Another way of putting this it that in most cases it is the commercial/official function (eg purchase order, import clearance document) that is significant in terms of what level of security is required, not the medium paper, fax, EDI)." Project: Electronic authentication; defining electronic messages and their "signatures".

"Develop, for possible adoption at the national level, uniform definitions of "writing", "document'" "signature" and other appropriate terms which will include messages transmitted by electronic data interchange and related procedures for authenticating, in both legal and commercial contexts, those messages and establishing appropriate security therefore." Trade data interchange protocols: Electronic Bill of Lading. TRADE/ WP.4/ R.710/August 15, 1990.

NCITD has proposed that an implementation goal of EDIFACT be the provision of electronic messages suitable for replacement of current documentation support for operational trade functions. Foremost among these is the negotiable Bill of Lading.

Legal aspects of trade data interchange: Report on Action programme relating to Commercial and Legal Aspects of Trade Facilitation. TRADE/WP.4/R.781 three elements which pose problems with negotiable instruments in general; the need for a written document, the need for a signature and the issues of "uniqueness".

certain commercial transactions will continue to require parties to transfer legal rights to goods in transit. Thus, in the use of EDI, establishing the"guaranty of singularity" which attaches to paper documents seems necessary in certain circumstances.

n dealing with the issue of "negotiability" in EDI, the objective may be to.ensure a series of procedures.

Security in open environments, TEDIS II, B7, ver. 15. July 1994.

same symbolicfunction as that which may be achieved in a paper-based environment by the use of certain words, signatures and related actions the transfer ?of possession).

In the CMI Rules and the NCITD proposal, it was noted that the role of the third party was pivotal.

the essential question is that of establishing or protecting the reliability of the third party.

Economic Commission for Europe Trade Facilitation Working Party 4: EDI Legal Group Work Programme.

"SITPRO, looking at the requirements for a signature on documents used in international trade, identified the law as the basis in respect of 27 documents and commercial practice in afurther 14 documents, concluding that "any further growth in the use of computer systems and electronic communication, including EDI, will be severely restricted if present requirements continue." In passing SITPRO commented that "despite the work that has taken to simplify or eliminate documents, it is interesting to note that within the European Communities seven of the twelve members states require manual signature on commercial invoices. EFTA, on the other hand, has only one country requiring a manual signature. (n respect of signature it has to be remembered that at least two international conventions relating to the all-important transport document provide for its signature to be "in handwriting, printed in facsimile, perforated, stamped, in symbols, or made by any other mechanical or electronic means, if not inconsistent with the Law of the countr where the (document) is sighed." (35) (added emphasis)) "The United Nations Commission on International trade Law, a) recommends to Governments: I) to review the legal rules affecting the use of computer records as evidence in litigation in order to eliminate unnecessary obstacles to their admission, to be assured that the rules are consistent with developments in technology, and to provide appropriate means for a court to evaluate the validity of the data contained in those records; Commission des Communautes Europeennes: Electronic Data Interchange and Negotiable Instruments. Clare Johnson. Brussels, September 5, 1991.

Progress can also be seen in such conventions as the Hamburg convention on th'e Security in open environments, TEDIS II, B7, ver. 15. July 1994.

Carriage of Goods by sea which allows electrical or mechanical signatures on a Bill of Lading "if not inconsistent with the law of the country where the Bill of Lading is issued". Such acceptance is by no means widespread however, and there is a need to review all regulations which continue to require a handwritten signature.

Apart from trade in goods, where a piece of paper gives good title to the merchandise, the question of uniqueness is also central to those Negotiable Instruments which are payment mechanisms. Bank notes, cheque and bank drafts for example, are all unique.

-A distinction should be made however, between uniqueness of documents and documents giving title. Although documents which represent goods and thus give tile to goods must of necessity be unique, the reverse is not necessarily true.

Intertanko: Electronic Data Interchange re: Bills of Lading for Oil Cargoes. Oslo, July 1990.

Since there are no established procedures of any sort for verifying the authenticity of a properly issuedpaper B/L, the risk of fraudulent Bs/L being put into circulation has already been demonstrated It would seem premature to try to examine possible means of secure identification/authentication which would be necessary for the transmission of the many messages required to give effect to the different operations outlined above. For present purposes it is assumed that systems could be modelled on those adopted by Banks in their highly developed EDI operations, for which equally rigorous degree of security obviously has to be maintained.

Security in open environments, TEDIS II, B7, ver. 15. July 1994.

5.2 BIMCO BIMCO is the world's oldest and largest international shipping organization. Its membership comprises shipowners, shipbrokers, shipping agents, protection and indemnity clubs, national associations of shipowners and shipbrokers and other bodies engaged within the maritime field, including entities having a demonstrable interest in the shipping industry, eg.

banks. Today, the organization counts nearly 3,000 members representing the larger share of existing world tonnage.

Through the wide range of services which BIMCO offers its membership, it tries to influence and improve international shipping practice. This applies not least to one of the core activities of BIMCO, which is and always has been to develop standard shipping documentation for worldwide use, such as charter parties, bills of lading, waybills and various other forms.

BIMCO is acknowledged as being non-political, objective and neutral in its documentary work and aims at standardization of documents.

A substantial proportion of the standard shipping documentation used on a global basis today carries BIMCO's name. It is fair to say that.almost anybody who has in some way been involved with the shipping industry will be familiar with well-known documents such as "Gencon", "Baltime 1939" and "Conlinebill", to mention but a few.

The world is now moving towards electronic trading and BIMCO recognizes the pressing business need for cutting down the paper volumes involved in handling international trade.

Basing shipping contracts on exchanges of electronic messages instead of the transfer of paper documents will significantly reduce the error rate and the effort expended on correcting errors, speed up transactions, reduce the administrative overheads and give users comprehensive access to data which would otherwise be too expensive to compile. In addition, the introduction of electronic trade is confidently expected to reduce the risk for maritime fraud.

With transport costs forming a decreasing part of the overall price of goods in international trade. BIMCO's membership, and therefore the organization itself, has a direct interest in achieving the benefits of electronic trading sooner rather than later.

In early 1990, BIMCO set up a standing committee to consider how the organization could best put its expertise and experience in the field of shipping documentation to use in the international development of EDI standards and practice. From the start, the committee has emphasized the importance of not duplicating work being undertaken by other international organizations. Instead, the committee's firmly stated aim is to build its work on internationally agree rules and standards, and equally to make the fruits of its labour available not only to the BIMCO membership, but to the international trade community at large.

Having considered the various fields where the committee's work could be of assistance to international trade, it was agreed that the most relevant area requiring attention is that of the negotiable Bill of Lading. This document, more than almost any other in regular use for "Security in open environments, TEDIS II, B7, ver. 15. July 1994.

1 international trade, creates specific problems for implementors of electronic trading systems. It is used in relatively large numbers, and yet, its overall functionality is so complex, partly due to its role as a (quasi-)negotiable document of title, that no successful electronic replacement has yet been found.

However, several recent developments by other international organizations have pointed theway forward. These include the EDIFACT international EDI standard and the CMI's "Rules for electronic Bills of Lading". By implementing a pilot project built on these foundations and on BIMCO's long experience of shipping documentation, BIMCO will be able to assist specifically in the facilitation of international trade through the introduction of electronic trading practice. It is well known that, if one particular aspect of trade cannot be handled by electronic means, then potential users will steer clear of all introduction of electronic trading practice, until such time as all their requirements can be handled in this manner. Such pilots are now being designed.

I

5.2.1 The Bill of Lading functionalities In UN TRADE/WP./R.710, Trade Data Interchange Protocols, Sec. 1.3, Field of Application, it is stated that "Provision of an electronic Bill of Lading suitable for replacement of the currently used negotiable or non-negotiable (sea waybill) which acknowledges receipt of the goods, contract of carriage and, for negotiable bills, title to the goods." Strictly speaking, some may argue, it is not possible to create an "electronic Bill of Lading", but rather to replicate the functionalities of a negotiable B/L in an electronic environment.

The basic terminology here is the following (Webster's Encycl. Unab. Dictionary) waybill: a list of goods sent by a common carrier, as a railroad, with shipping directions.

air, or sea, waybill: a nonnegotiable shipping document evidencing the contract between shipper and air, or sea, carrier for transportation and delivery of cargo.

0 Bill of Lading: a written receipt given by a carrier for goods accepted for transportation.

Since the Bill of Lading obviously has many functionalities that moreover even differ from one country to another (more specific are there significant differences in the American and European way of distinguishing between a B/L and a sea waybill, for example), the electronic version must be able to cope with all functionalities, which have the common feature that they are documents issued to cover all or part of a voyage which includes waterborne transport. It is of all interest to use the term B/L in the widest possible sense, including e.g. sea waybill.

',Security in open environments, TEDIS II, B7, ver. 15. July 1994.

IJ

In this sense, the B/L is used: To prove the existence and contents of a contract of carriage S To prove the condition of the goods at the time they were received for carriage (or shipped on board) To give rights of disposal to the holder of a full set of originals S To identify, the person to whom the cargo should be delivered at the point of destination, namely the holder of one original The parties to B/L are the Carrier, who issues the document to the Shipper, who then becomes the first Holder and can transfer it to subsequent holders. The last in the chain presents the document to the Carrier and is referred to as the Consignee.

The B/L is an evidence of existence and contents of the contract of carriage. If the B/L has been transferred to a new Holder and property in the goods to which it refers has also passed, then the effect is that the new Holder takes over the same contractual rights and obligations as the previous Holder had, which means that the B/L is not a negotiable document but only a quasi-negotiable one. Moreover, this is only the case if it has been made so by being issued to "bearer" or "Z or order", or in blank, or if it has been endorsed in that manner.

The rights of disposal in transit belong to the Holder, who however doesn't have absolute rights of disposing over the cargo where this would change the terms of the contract of carriage. Where the buyer of cargo becomes insolvent, the Shipper still holding the B/L with the intention of retaining the right of stoppage in transit may exercise this right, but all costs involved in this action are for his account.

The Carrier is entitled to deliver the goods to whoever first presents a correctly transferred B/L (document of title functionality), so the B/L acts as a symbol of the goods, so that possession of the B/L equals possession of the goods themselves. The actual ownership however passes with the contract of sale.

It happens quite frequently that Bs/L do not arrive in time for the Consignee to present them at the arrival of the ship. In such cases the Consignee presents a letter of indemnity whereby in return for release of the goods without production of the B/L he promises to hold the Carrier harmless for any consequences of this action. This situation should not arise in a fully electronic scenario.

5.2.2 Rights of various parties in connection with the B/L Security in open environments, TEDIS II, B7 ver. 15. July 1994.

5.2.2.1 Right of ownership The transfer ofa B/L may have evidential weight in a dispute over ownership, but no more than the transfer of possession of the actual goods does.

5.2.2.2 Right of possession S Right of possession for use In all realistic circumstances this right ultimately follows the ownership of the goods.

This right is transferred from the Shipper to any subsequent Holder actually paying for the goods (as opposed to lending money on them).

Right of possession as security: awaiting payment The Shipper may retain the B/L as security for payment from the Consignee, even though under the contract of sale, the rights of ownership have already passed.

Right of possession as security: for commercial credit Chattels cannot normally be pledged as security for a loan without transfer of possession to the pledgee. However, cargo held by a Carrier can be so pledged, and this is normal practice in documentary credit transactions. The transfer of the B/L is a necessity for such an arrangement to become effective.

Right of possession as security: for freight The Carrier has a lien for freight on goods in his possession. This right obviously follows possession of the goods.

There can be different claims to the right of possession and ownership. The transfer and possession of the B/L is useful evidence in a dispute over better right, but does not actually determine it.

5.2.2.3 Right to sue under the contract of carriage S Right to sue the Carrier This right follows ownership where transferred together with the B/L. But where the right of ownership and the B/L are not with the. same person, the Shipper, as the Security in open environments, TEDIS II, B7, ver. 15. .uly 1994.

A

J.;

original party to the contract, retains this right. This right can however also be transferred on its own.

Right to sue the Shipper/Holder This right naturally belongs to the Carrier. Where freight is not pre-paid, the Holder/Consignee can be sued for freight. The Shipper can be sued for damage from goods, and maybe also the Holder.

5.2.3 The BIMCO B/L project 5.2.3.1 Overview of the project Since it appears impossible simply to capture the negotiable B/L as a single electronic document, it seems obvious to make use of the CMI rules, which describe a scenario of several different messages, exchanged in a logical sequence, which together achieve the functionality of a negotiable B/L. Together with those CMI rules, the project builds on EDIFACT messages and UNCID rules. The EDIFACT messages to be used are the IFTM set of transport messages.

The way in which the CMI rules were originally intended to deliver B/L functionality was, although the final version does not expressly state this, through the Carrier maintaining a register of Holders to the rights under all electronic replicas of Bs/L issued by him. Any transfer of the rights would have to be notified to the Carrier, thus in a sense changing the nature of the concept from quasi-negotiability to assignability. When this solution was first proposed, it was received coolly, both by the Carriers, who had no wish to be forced into yet further systems development, and by the cargo interests, who felt that it would be inappropriate for the Carrier to contrbl access to their goods in this way. In order to overcome the difficulties raised with the original version of the CMI rules, the concept of a central register, operating with BIMCO's approval, will be used.

To cope with security problems (authentication), the concept of digital signatures will be used.

The technological means for creating digital signatures is envisaged by chipcards, by which the following security advantages are achieved: Secure identification of the individual responsible for sending the message Protection against attempts to tamper with the message contents after signature Efficient administration of security, based on a star-shape of one-to-one relationships with a central register acting as administrator Multilevel security not dependent on one single means of communication Security in open environments, TEDIS II, B7, ver. 15. July 1994.

Ac c- How does this solution relate to our discussion in Chapter First of all, the sketched BIMCO solution is based on the traditional use of non-repudiation services. Moreover, the central register would have be what we have identified as an Unconditionally Trusted Center, as the Central Register would have to register all ownerships.

Chapter 2.5 explains how to replace this unconditionally trusted center by merely functional trust.

5.2.3.2 Overview of the message scenario The message scenario begins with the shipping instruction (fnmctional code SHIPIN).

This is a;n IFTMIN message containing the basic consignment data and is created by the Shipper and transmitted (via the central register BIMCO) to the Carrier.

On receipt of the cargo, the Carrier issues a receipt message (RECEIP) to the Shipper (via register BIMCO). The data content is the same as for the SHIPIN message, except that any clauses as to the condition of the goods may have been added by the Carrier. This is the most important message in the scenario.

If the Shipper (or later Holder of rights) wishes to transfer his rights to the cargo. he sends a transfer request (TRANRQ) to the register (a very abbreviated IFTMIN message) holding sufficient detail to identify the consignment in respect of which action is to be taken and details explaining the desired action. This message is called IFTMSV. The TRANRQ indicates the identity of the person to whom the rights are to be transferred as well as exactly which rights are to be transferred.

When the register receives this message, it issues a copy receipt message (RECEII) to the intended transferee toformally notify him of the rights it is acquiring and to request a confirmation that this is in order.

The intended transferee returns an acceptance message (ACCEPT) (also an IFTMSV), indicating whether or not the transfer is accepted. If so, the register updates its registers and sends a transfer notification (TRANNT) (also an IFTMSV) to the transferor, indicating that the transfer has been effected as instructed.

The message sequence from TRANRQ to TRANNT can be repeated an arbitrary number of times, asrequired by the trading pattern.

When the cargo has arrived at the port of destination, the Carrier sends an arrival notice (ARRINT) via the register to the notify party. This is an IFTMAN message, simply indicating the arrival of goods and requesting delivery instructions as Security in open environments, TEDIS II, B7, ver. 15. July 1994.

required.

The Holder of the right to delivery can now send a delivery instruction (DELIlN) (via the register) to the Carrier (an IFTMIN message giving instructions for delivery and creating the authorityfor the Carrier to deliver the goods to a named party.) After the delivery has been effected, the Carrier notifies BIMCO of this fact in a notification of delivery message (DELINT). This is an IFTMSV, the effect of which is to block any further transactions concerning the rights to the consignment.

At this point, the scenario ends. In order to preserve compatibility with trading partners not yet using electronic trading, there is a pair of messages concerned with the transfer from the electronic scenario to a traditional process.

The Holder of rights can at any time request the Carrier to issue a paper B.-L (PAPRRQ) (an IFTMSV message). On receipt, the Carrier issues a traditional B/L and then notifies BIMCO of this fact with a PAPRNT message (also IFTMSV).

Finally, the holder of rights can at any time request BIMCO to send a copy RECEIP message to a third party (customs (COPYRQ message, also IFTMSV forma).

5.2.3.3 The user manual The second cornerstone of the project building is the user manual. The central section of it contains technical implementation rules for the 12 functional messages of the scenario, but also a complete set of legal rules explaining and defining the effect of these messages. The project's aim of replicating the functionality of a paper B/L in an electronic environment will be reached through the successful interaction of these rules with the logical sequence of transmitted electronic messages. In addition, the user manual contains various support information, such as error recovery procedures, participant directory information and so forth.

/7l~ c~LI Security in open environments, TEDIS II, B7, ver. 15. July 1994.

6 The work of the UN/EDIFACT Security JWG As explained in Chapter 1, this report is a discussion of security services, which go beyond services already identified in established applications, such as EDIFACT.

However, there is still quite a way to go at least if the requested service is to be integrated in an international standard or draft standard.

It seems relevant at this stage, how integration of message authentication, non-repudiation of origin and receipt, and confidentiality in to EDIFACT standard is progressing.

After several proposals had been made, one by EDIFACT MD4 and one by TEDIS, which in their philosophy of approach concurred on all essential accounts, it was decided directly by the G UN/EDIFACT board to form a Security Joint Working Group (SJWG). This group was asked to suggest a solution based on these two proposals, taking the best from both approaches.

During the past year, phase one of this task has been carried out as planned. This has resulted -in a Recommendation for Security which explains the principles behind the solutions, and Implementation Guidelines, which explains how actually to implement this in existing standards, with examples. These documents have official status, and are available for comments. Moreover, a proposal has been made for a special message, the AUTACK-message to realize the required security services. For completeness, we present the philosophy of the current approach of the SJWG below.

Given the conditions, under which UN/EDIFACT standards are created, there is no discussion however, that it will be quite a while before we have an actual standard. We predict though that once it is there, it will only vary.from the current proposal in minor details. It would therefore make sense, in applications with a great need for some security, to implement on the basis of the existing proposals. Very recently, it was decided outside of the SJWG that security measures are to be considered as service elements rather than data elements, in contrast to earlier decisions. This slows the process further down, and forces it through the ISOmachinery.

As for the services presented in the present report, there are not really any internationally standards, to which they apply. In the following we will briefly comment on the practical aspects of each individual service.

6.1 Recommendations from the EDIFACT Security JWG The Recommendation for UN/EDIFACT message level security Security in open environments, TEDIS II, B7, ver. 15. July 1994.

o allows security services to be implemented by trading partners themselves, end to end, transparent to underlying communications protocols, which may themselves provide security services.

o is independent of, and transparent to, the communications medium used.

o is an open standard which supports the use of all existing security mechanisms compatible with the identified security services.

o does not involve changes to individual messages. Rather, a global approach is adopted which can be applied to any message irrespective of business application.

Extensions to interchange and segment level security, as well as corresponding service messages will be addressed in later phases.

A message may be secured by several entities (for example a message may have multiple digital signatures)and so the security related information may be repeated to allow the identification of several signing or authenticating entities and correspondingly to include several digital signatures or control values.

The security services which may be integrated with this approach are the following Message sequence integrity Message content integrity Message origin authentication Non-repudiation of origin Non-repudiation of receipt Confidentiality of content Confidentiality is being addressed in a separate document, CIPHER, for the reason that the approach by nature is quite different. Indeed, by encrypting, the EDIFACT syntax and structure can no longer be verified.

For a brief presentation of these services we refer to the annex.

6.2 Message level security We briefly explain the approach of EDIFACT message level security. The security services can either be integrated into the message itself or provided by a separate message.

Security in open environments, TEDIS II, B7, ver: 15. July 1994.

6.3 Integrated message security All services except non-repudiation of receipt and confidentiality are provided by the inclusion of generic security header and trailer segment groups after the UNH and before the UNT, in a way which may be applied to any existing message.

Typically, a message security header/trailer pair is required for each security service.

6.3.1 Security headers and trailers The receiver of a message needs to be able to identify and check the security attributes associated with the message received. This implies that the parties involved need to know: the security services involved; the mechanisms and parametersused; the scope of application of the mechanisms.

This information is conveyed in special security segments.

The structure of an interchange containing a secured message is sketched overleaf.

The purpose of the Message Security Header is to specify th6 security methods applied to the message and to hold the associated data necessary to carry out the validation calculations. A special segment contains details of the security algorithms, other segments may contain the relevant public key certificates.

The Message Security Trailer is used to hold the security result corresponding to the security functions specified in the associated Message Security Header. The Message Security Header and Message Security Trailer are repeated for each set of service and originator. This approach allows for maximum flexibility in future work.

The complete branching diagram, as well as a specification of the segments, may be found in EDIFACT security Implementation Guidelines.

The computation of each of the integrity and authentication values and of the-digital signatures starts with and includes the associated Message Security Header and the message body itself; and ends with the last character of the message (just before the first appearing Message Security Trailer).

Thus the order in which security services other than confidentiality are performed, is not Security in open environments, TEDIS II, B7, ver. 15. July 1994.

A- I prescribed. They are completely independent of each other.

PI>

Security in open envirornents, TEDIS 11,. B7, v'er. 15. July 1994.

I Interchange Header UNB I I p I Functional Group Header I I

UNG

UNH i I Message Header

I

I Security Message Header I e n I 2 1 1 I Security Message Header I I i Security Message Header I I UNSM Message SSecurity Message Trailer Serity Message Trailer I Security Message Trailer 1 2 I Security Message Trailer ,1 Security in open environments, TEDIS II, B7, ver. 15. July 1994.

I Message Trailer UNT I UNE- I IFunctional Group Trailer I A IInterchange Trailer UNZ I iN ecurity in open envirornents, TEDIS 11, B7, ver. 15. July 1994.

6.4 Separated message security There are two business requirements for this feature, namely 1) to provide security for one or more messages in a single separate message forwarded to the receiver, 2) to provide secured acknowledgement for having received a message, without returning the message itself This requirements can be provided for by the introduction of a special functional acknowledgement, AUTACK.

More generally, the AUTACK may be used as a secured acknowledgement sent by the receiver of a message to the sender of the message. The criteria and means by which a AUTACK is generated, provide the sender of the original message Wvith assurance that it was received by the intended party.

The initial scope of the AUTACK is to provide secured acknowledgement of receipt of messages at the message level only. Extensions to interchange, functional group and segment levels will be addressed in the near future.

AA

Security in open environments, TEDIS II, B7, ver. 15. July 1994.

7 Bibliography (partly annotated) Secure EDI a mianagement overview, CEC, Eur 13794.

L. Elias and J. Gerard, La formation des contrats par echange de donnees informatiques, Tedis report, 1991.

L. Hawkes and J. Montijn, Trusted third parties and similar services, Tedis report, 1991.

A. Nilson, An introduction to the BIMCO BIL project, report by Marinade Ltd.

A. Nilson, Bill of Lading functionalities, report by Marinade Ltd.

ISO/IEC 9796 Digital signature scheme giving message recovery, 1991.

ISO/IEC 9797 Data cryptographic techniques Data integrity mechanism using a cryptographic check function; Employing a block cipher algorithm, 1998.

ISO/IEC 9798-1: Information Technology Security Techniques Entity Authentication mechanisms Part General model, 1991.

ISO/IEC 9798-2: Information Technology Security Techniques Entity Authentication mechanisms Part 2 Entity authentication using symmetric techniques, CD: 1992.

ISO/IEC 9798-3: Information Technology Security Techniques Entity Authentication mechanisms Part 3 Entity authentication using a public key algorithm, DIS: 1992.

CCITT Data Communicaiton Networks Directory, Recommendation X.509, The Directory Authentication Framework.

UNITED NATIONS Economic and Social Council [UNI] FACILITATION MEASURES APPLICABLE TO PARTICULAR, SELECTED PROCEDURES: Acceptance of Facsimile Signatures on Export Documents.

Security in open environments, TEDIS II, B7, ver. 15. July 1994.

TRADE/WP.4/R.555/August 30, 1988.

[UN2] IMPLEMENTATION OF ECE/FAL RECOMMENDATION NO.12: Measures to Facilitate Maritime Transport Documents Procedures. (Project 4.1).

TRADE/WP.4/R.605/July 3, 1989.

[UN3] LEGAL ASPECTS OF ELECTRONIC DATA INTERCHANGE: Definition of an "Electronic Document". TRADE/WP.4/R.649/December 22, 1989.

[UN4] LEGAL ASPECTS OF TRADE DATA INTERCHANGE TRADE/ WP.4/- R.697/December 27, 1990.

ELECTRONIC DATA INTERCHANGE IN FOREIGN TRADE: German Law Requirements Concerning Written Form and Signature.

TRADE /WP.4/ R.709/ August 14, 1990.

[UN6] TRADE DATA INTERCHANGE PROTOCOLS: Electronic Bill of Lading.

TRADE/WP.4/R.710/August 15, 1990.

[UN7] LEGAL ASPECTS OF TRADE DATA INTERCHANGE: Report on Action Programme relating to Commercial and Legal Aspects of Trade Facilitation.

TRADE/WP.4/R.781.

[UN8] TRADE FACILITATION INFORMATION: Adoption of the CMI Uniform Rules for Sea Waybills. TRADE/WP.4/INF 116/July 9 1991.

[UN9] Aspects juridiques de l'echange des donnees commerciales en transport international ferroviaire, note d'information de 'OCTI et du CIT.

Recommendations to UN/ECE WP.4/GE. 1 on Interactive EDIFACT. Interim Report, Ver. 1.1.

[UN 11] Legal aspects of trade data interchange Action Programme relating to Commercial and Legal aspects of Trade Facilitation. TRADE/WP.4/R. 1818, February 17, 1992.

[UN 12] Legal aspects of trade data interchange Review of definitions of "Writing", "Signature" and "Document" Employed in Multilateral Conventions and Agreements Relating to International Trade. TRADE/WP.4/R.819/March 9, 1992.

OTHER DOCUMENTS OF GENERAL NATURE [OD1] AN INTRODUCTION TO THE BIMCO B/L PROJECT.

Security in open environments, TEDIS II, B7, ver. 15. July 1994.

Xe. 's 66 [OD2] ECONOMIC COMMISSION FOR EUROPE TRADE FACILITATION WORKING PARTY 4: EDI Legal Group Workprogramme.

[OD3] EDI: The Proliferation of "Model" Interchange Agreements. Amelia H. Boss, Temple University School of Law, Philadelphia, Pennsylvania, USA. 1991.

[OD4] COMMISSION DES COMMUNAUTES EUROPEENNES: Electronic Data Interchange and Negotiable Instruments. Clare Johnson. Brussels, September 5,1991.

IATA: Meeting Announcement, Interactive EDI meeting 19-21 February 1992, Atlanta.

[OD6] INTERTANKO: Electronic Data Interchange re: Bills of Lading for Oil Cargoes.

Oslo, July 5, 1990.

[OD7]. Digital Signatures in EDIFACT report prepared for the TEDIS programme by CRYPTOMATHIC A/S, final version, Nov. 29, 1990.

[OD8]. Protecting your EDI Message. Peter Landrock. Presented at the 3rd International Congress of EDI Users, Bruxelles, Sept. 1991. EDI Europe, vol.1, no.2; Hermes, Paris, 1992.

[OD9] RIPE integrity primitives. Final Report of RACE 1040.

The Green Book, INFOSEC, ver. [OD 11] TEDIS II B5, Legal aspects of Authentication, storage and coding, Wilde Sapte et.

al., 1994.

[OD12] Trusted Third Parties and Similar Services, Barents, Gasille Mout et.al., TEDIS 1991.

[OD13] EDIRA, Memorandum of Understanding, For the Operation of EDI Registration Authorities, TEDIS, 1993.

[OD14] Trusted Third Parties, INFOSEC report, 1993.

Service Infrastructure for EDI Security, NCC Consultancy, TEDIS. 1993.

SCIENTIFIC PAPERS [B181] M. Blum, Three applications of oblivious transfer; Department of EECS, University of Security in open environments, TEDIS II, B7, ver. 15. July 1994.

California, Berkeley, 1981.

[B183] M. Blum, How to Exchange (Secret) Keys, ACM Transactions on Computer Systems, Vol. 1, 1983, 175-193.

[BCD91] J. Boyar, D. Chaum and I. Damgard, Convertible undeniable signatures, Advances in Cryptology Proceedings of Crypto '90, Lect. Notes Comp. Science 537, Springer Verlag 1991, 189-205.

[BDL88] J. Brandt, I-B DamgArd and P. Landrock, Anonymous and verifiable registration in databases, Advances in Cryptology Proceedings of Eurocrypt '88, Lect. Notes Comp. Science 330.

Springer Verlag 1988.

[BDLP88] J. Brandt, I.B. Damgird, P. Landrock and T.P. Pedersen, Zero-knowledge authentication scheme with secret key exchange, Proceedings of Crypto '88.

[BChDG87] E. Brickell, D. Chaum, I. Damgard and J. van de Graaf, Gradual and Verifiable Release of a Secret, Proceedings of Crypto '87.

[Ch81] D. Chaum, Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms, Communications of ACM, Vol. 24 nr. 2 (1981), 84-88.

D. Chaum, Security without identification: Transaction Systems to Make Big Brother Obsolete, Communications of ACM, Vol.28 no. 10 (1985), 1030-1044.

[Ch88] D. Chaum, The Dining Cryptographers Problem: Unconditional Sender and Recipient Unraceability, J. of Cryptology, Vol. 1 nr.1 (1988), 65-75.

[Ch91a] D. Chaum, Zero-Knowledge Undeniable Signatures, Advances in Cryptology Proceedings of Eurocrypt '90, ed. I. B. Damgird, Lect. Notes Comp. Science 473, Springer Verlag 1991, 458-464.

[Ch91b] D. Chaum, Some Weaknesses of "Wealokesses of Undeniable Signatures", Advances in Cryptology Proceedings of Eurocrypt '91, ed. D. Davies, Lect. Notes Comp. Science 547, Security in open environments, TEDIS II, B7, ver. 15. July 1994.

i Springer Verlag 1991, 554-556.

[Ch91c] D. Chaum, Numbers can be a better form of cash than paper, Smart Card 2000, ed. D.

Chaum, Elsevier Science Publishers B.V. 1991, 151-156.

[Ch92] D. Chaum, Achieving Electronic Privacy, Scientific American, August 1992, 96-101.

D. Chaum and H. van Antwerpen, Undeniable signatures, Advances in Cryptology Proceedings of Crypto '89, ed. G. Brassard, Lect. Notes in Comp. Science 435, Springer Verlag 1990, 212-216.

D. Chaum, B. den Boer, E. van Heyst, S. Mjolsnes and A. Steenbeek, Efficient Offline Electronic Checks, Advances in Cryptology Proceedings of Eurocrypt '89, ed. Quisquater and J. Vandewalle, Lect. Notes Comp. Science 434, Springer Verlag 1990, 294-301.

[ChFN88] D. Chaum, A. Fiat and M. Naor, Untraceable Electronic Cash, Advances in Cryptology Proceedings of Crypto '88, ed. S. Goldwasser, Lect. Notes Comp. Science 403, Springer Verlag 1988, 319-327.

[ChvHP92] D. Chaum, E. van Heyst and B. Pfitzmann, Cryptographically Strong Undeniable Signatures, Unconditionally Securefor the Signer, Proceedings Crypto '91, ed. J. Feigenbaum, Lect.

Notes Comp. Science 576, Springer Verlag 1992, 470-484.

[ChP92] D. Chaum and T.P. Pedersen, Transferred cash grows in size, Proceedings of Eurocrypt '92, to appear.

[C190] R. Cleve, Controlled Gradual Dislosure Schemes for Random Bits and Their Applications, Proceedings of Crypto '89, ed. G. Brassard, Lect. Notes Comp. Science 435, Springer Verlag 1990.

[D92] I. Damglrd: Practical and Provably Secure Exchange of Digital Signatures, to appear.

[DS81] D. E. Denning and G. M. Sacco, Time stamps in Key Distribution Protocols, Communications of ACM, Vol.24 nr.8 (1981), 533-536.

Security in open environments, TEDIS II, B7, ver: 15. July 1994.

S- [DY91] Y. Desmedt and M. Yung, Wealknesses of Undeniable Signature Schemes, Advances in Cryptology Proceedings of Eurocrypt '91, ed. D. Davies, Lect. Notes Comp. Science 547, Springer Verlag 1991, 205-220.

[EGL86] S. Even, O. Goldreich and Lempel, A Randomized Protocol for Signing Contracts, Proceedings of Crypto '86, Plenum Press.

S. Even and Jacobi, Relations among Public Key Signature Systems, Computer Science Department, Technion, Haifa Israel, March 1980.

[HS91] S. Haber and W. Stornetta, How to Time-Stamp a Digital Document, J. of Cryptology, Vol.3 nr.2 (1991), 99-112.

[HS83] J. Histad and A. Shamir, The Cryptographic Security of Truncated Linearly Related Variables, Proceedings of the ACM Symposium on the Theory of Computing, 1983, 356-361.

[L92].

P. Landrock, How to obtain mock uniqueness of electronic documents, to appear.

[LMR83] M. Luby, S. Micali and C. Rackoff, How to simultaneously Exchange a Secret Bit by Flipping a Symmetrically-Biased Coin, Proceedings of the IEEE conference of the Foundations of Computer Science 1983.

[0090] T. Okamoto and K. Ohta, Disposable Zero-Knowledge Authentications and their Applications to Untraceable Electronic Cash, Advances in Cryptology Proceedings of Crypto '89, ed. G.

Brassard, Lect. Notes Comp. Science 435, Springer Verlag 1990, 481-496.

[Ra81] M. Rabin, How to Exchange Secrets by Oblivious Transfer, Technical Memo, TR-81, Aiken Comp. Lab., Harvard University, 1981.

[Te83] Tedrick, How to Exchange Halfa Bit, Proceedings of Crypto '83, Plenum Press, 147-151.

[Te84] Tedrick, Fair Exchange of Secrets, Proceedings of Crypto '84, Lecture Notes in Computer Security in open environments, TEDIS II, B7, ver. 15. Julv 1994.

Science, Springer Verlag, 434-438.

[VV83] Vazirani and Vazirani, Trapdoor Pseudorandom Number Generators With Applications to Cryptographic Protocol Design, Proceedings of the IEEE Conference on the Foundations of Computer Science 1983, 23-30.

M. Waidner, Unconditional Sender and Recipient Untraceability in Spite of Active Attacks, Advances in Cryptology Proceedings of Eurocrypt '89, Lect. Notes Comp. Science 434, Springer Verlag 1990, 302-319.

[Ya86] Yao, How to Generate and Exchange Secrets, Proceedings of the IEEE Conference on the Foundations of Computer Science 1986.

LIST OF PAPERS ON EXCHANGE OF SECRETS [B181] Blum: Three Applications of the Oblivious Transfer, Department of EECS, University of California, Berkeley, 1981.

One of the three applications shows how to exchange secrets using oblivious transfer. Requires many executions of the transfer subprotocol per bit exchanged, hence not practical.

[B183] Blum: How to Exchange (Secret) Keys, ACM Transactions on Computer Systems, Vol. 1, 1983, pp. 1 7 5 19 3 Shows a special-purpose, and quite practical protocol for exchange of factorizations. Has been partly broken, however, in Hastad and Shamir [BCDvdG87] Brickell, Chaum, Damgird and Van de Graaf: Gradual and Verifiable Release of a Secret, Proceedings of Crypto '87, Lecture Notes in Computer Science, Springer Verlag.

Presents a protocol for gradual release of a discrete log. The protocol in its basic form requires many sequential rounds for each part of the secret, so is only semi-practical. There is an efficiency improvement presented, however, which means that after an initial phase requiring interaction, the parts of the secret can be released non-interactively. In this form, the protocol is really practical.

[C190] Cleve: Controlled Gradual Disclosure Schemes for Random Bits and Their Applications, Proceedings of Crypto '89, Lecture Notes in Computer Science, Springer Verlag.

Improves on Lubi, Micali and Rackoff [LMR83], in that the amount of information released S Security in open environments, TEDIS II, B7. ver. 15. July 1994.

'4 per round can be controlled. But since the purpose still is to exchange "parts" of a single bit, this is still not a practical protocol.

[EGL86] Even, Goldreich and Lempel: A Randomized Protocolfor Signing Contracts, Proceedings of Crypto '86, Plenum Press.

Shows a protocol for exchange of signatures. Is only semi-practical, since it requires many oblivious transfers, and uses a non-standard definition of RSA signatures, where a signature is said to be valid if it contains enough ordinary RSA signatures on different variants of the original message.

Even and Jacobi: Relations Among Public Key Signature Systems, Computer Science Department, Technion, Haifa Israel, March 1980.

Shows that no deterministic protocol can implement exchange of secrets properly. This means that a source of randomness (typically a pseudorandom bit generator, or a hardware source) is definitely needed to implement exchange of secrets.

[HS91] Hastad and Shamir: The Cryptographic Security of Truncated Linearly Related Variables, Proceedings of the ACM Symposium on the Theory of Computing, 1983, pp.356-362.

Partially breaks Blum's protocol [B183], in that they show how to compute the entire secret at an earlier stage in the protocol than what Blum expected.

[LMR83] Luby, Micali and Rackoff: How to Simultaneously Exchange a Secret Bit by Flipping a Symmetrically-Biased Coin, Proceedings of the IEEE Conference of the Foundations of Computer Science 1983.

Probabilistic protocol for exchanging "parts" of a single bit. This is done by transferring increasing degrees of certainty about the bits in.question. The protocol is set up such that if each party in each round learns exactly the same amount of probabilistic information about the other party's bit. Not a practical protocol, since a lot of interaction is required to exchange a single bit.

[Ra81] Rabin: How to Exchange Secrets by Oblivious Transfer, Technical Memo, TR-81, Aiken Comp. Lab., Harvard University, 1981.

Shows how to exchange secrets using oblivious transfer. Requires many executions of the transfer subprotocol, hence not practical.

[Te83] Tedrick: How to Exchange Halfa Bit, Proceedings of Crypto '83, Plenum Press, pp. 147-151.

Improves on Blum [B183] by showing how to overcome the problem that one participant may be ahead of the other by 1 bit.

Security in open environments, TEDIS II, B7, ver. 15. July 1994.

v :3 [Te84] Tedrick: Fair Exchange of Secrets, Proceedings of Crypto '84, pp.434-438, Lecture Notes in Computer Science, Springer Verlag.

Improves (by a better method than Tedrick [Te83] on [B183] by showing how to overcome the problem that one participant may be ahead of the other by 1 bit.

[VV83] Vazirani and Vazirani: Trapdoor Pseudorandom Number Generators With Applications to Cryptographic Protocol Design, Proceedings of the IEEE conference on the Foundations of Computer Science 1983, pp.23-30.

Probabilistic protocol for exchanging single bits. Not a practical protocol. A lot of interaction required to exchange a single bit.

[Ya86] Yao: How to Generate and Exchange Secrets, Proceedings of the IEEE conference on the Foundations Of Computer Science 1986.

Theoretical, very general solution to the exchange of secrets problem, based on the factoring assumption. Not a practical protocol.

LIST OF PAPERS ON CLAIM OF OWNERSHIP [BCD91] Boyar, Chaum and Damgird: Convertible undeniable signatures, Proceedings of Crypto Lecture Notes in Computer Science 537, Springer Verlag 1991, pp. 189-205.

An efficient scheme for undeniable signatures that afterwards can be converted to ordinary digital signatures are given. Practical, zero-knowledge protocols for verifying and denying are given. It should be investigated whether this protocol is not too complicated, since it requires a lot of communication due to its being zero-knowledge.

[Ch81] Chaum: Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms, Comm. of ACM, Vol.24 nr.2, 1981, pp.84-88.

Presents an electronic mail system based on public key cryptography where no trusted authority is needed, in such a way that the receiver of a message is hidden as well as the content of the communication. Also the sendercan be anonymous, if required. The system might be useful whenever the anonymity of the communication entities is required, but has the drawback that the computers processing mail items have to be trusted.

Chaum: Security without identification: Transaction Systems to make Big Brother Obsolete, Comm. of ACM, Vol.28 nt.10, 1985, pp.

10 3 0 -1 0 4 4 Solutions are presented for two major problems: the uncertainty of the security of the data Security in open environments, TEDIS II, B7, ver. 15. July 1994.

A which is handled, and the vulnerability of organisations to abuses by individuals. Each individual must have a personal card computer it owns and trusts. Very theoretical; Okamoto and Ohta [0090] propose better solutions.

[Ch91a] Chaum: Zero-Knowledge Undeniable Signatures, Proceedings of Eurocrypt '90, Lecture Notes in Computer Science 473, Springer Verlag 1991, pp.458-464.

This zero-knowledge protocol requires four passes, instead of the two in his previous paper which was not zero-knowledge. This can make it inconvenient for EDI applications.

It introduces a disavowal protocol, which requires many calculations and exchanges and is therefore also impractical.

[Ch91c] Chaum: Numbers can be a better form of cash than paper, Smart Card 2000, ed. D. Chaum, Elsevier Science Publishers B.V. 1991, pp. 15 1-156.

A good, but only theoretical overview on general principles of untraceable electronic cash and electronic credentials.

Chaum and Van Antwerpen: Undeniable Signatures, Proceedings of Crypto '89, Lecture Notes in Computer Science 435, Springer Verlag 1990, pp.

2 12 2 16 A practical, interactive protocol which only needs two verifications to verify a signature is presented. Based on the discrete log problem.

Chaum, Den Boer, Van Heyst, Mjolsnes and Steenbeek: Efficient Offline Electronic Cash, Proceedings of Eurocrypt '89, Lecture Notes in Computer Science 434, Springer Verlag 1990, pp.294-301.

A practical offline RSA-based electronic check system is presented, consisting of three parties (bank, user, and shop) and treating four transactions (withdrawal, payment, deposit and refund). Improvement of Chaum, Fiat and Naor [CFN88].

[CFN88] Chaum, Fiat and Naor: Untraceable Electronic Cash, Proceedings of Crypto '88, Lecture Notes in Computer Science 403, Springer Verlag 1990, pp.

3 19 3 2 7 Presents an improved version of unconditionally untraceable electronic cash where a shop keeper does no longer have to contact the bank during every transaction. Also guaranteed untraceable electronic checks, and a method to blacklist withdrawals are presented. Since no trusted party is required, the systems might be practical. However, fraud detection is only detected afterwards and a 2-argument collision-free one-way function is required. The major drawback is the efficiency, and the fact that formal proves for the security are missing.

[CvHP92] Chaum, Van Heyst and Pfitzmann: Cryptographically Strong Undeniable Signatures, S Secnrity in open environments, TEDIS II, B7, ver. 15. July 1994.

j'.

Unconditionally Secure for the Signer, Proceedings of Crypto '91, Lecture Notes in Computer Science 576, Springer Verlag 1992, pp.

4 7 0 4 8 4 The scheme proposed is based on the discrete log scheme. It is zero-knowledge and uses failstop signatures. A collision-free hash function is given as a subprotocol. It should be investigated if an unconditional security for the signer is worth the complexity of the protocol for use within EDI.

[CP92] Chaum and Pedersen: Transferred cash grows in size, Proceedings of Eurocrypt '92, to be published.

Shows that the number of bits to represent the money after each payment must increase in an offline electronic payment system. When k bits are needed to uniquely identify a user, it is shown that the money has to grow by at least k and k/2 bits to achieve unconditional and computational untraceability respectively. Furthermore is argued that an unlimited powerful user can always recognize his money later (forward traceability).

[DS81] Denning and Sacco: Time stamps in Key Distribution Protocols, Comm. of ACM, Vol.24 nr.8, 1981, pp.

53 3 5 3 6 Time stamps are added in the distribution protocols for as well conventional communication keys as public keys to protect against replay of compromised keys. They also replace the twostep handshake. A trusted third party generates them and appends them to the message containing the key(s). The ideas are very practical, and some of them are employed in the entity authentication standard ISO/IEC 9798.

[HS91] Haber and Stornetta: How to Time Stamp a Digital Document, J. of Cryptology, Vol.3 nr.2, 1991, pp.

99 1 12.

Procedures are proposed such that it is impossible for a user to date his document incorrect, even with the collusion of the time stamping service (TTS). The documents are confidential w.r.t. the TTS, and no record-keeping by the TTS is required. Then two schemes are presented, both using hash functions and digital signatures. They only differ in the way unforgeability is achieved. The first is based on a centralized but untrustworthy TTS, and uses a linking technique. It appears to be very practical. The second one does not need a central TTS, and relies upon distributed trust among the users. It is less practical, since it makes a great technological demand on the system.

[0090] Okamoto and Ohta: Disposable Zero-Knowledge Authentications and their Applications to Untraceable Electronic Cash, Proceedings of Crypto '89, Lecture Notes in Computer Science 435, Springer Verlag 1990, pp.

4 8 1 4 9 6 A useful, concrete electronic cash system (untraceable, unreuseable, transferable) is presented.

Improvement of Chaum, Fiat and Naor [CFN88].

Security in open environments, TEDIS II, B7, ver. 15. July 1994.

A Annex on Basic cryptographic concepts The following presentation of basic concepts in data security and cryptography is based on Vol. I of the TEDIS II project, Legal aspects of authentication, storage and coding.

A.1 Security Services Just as in the paper world, a number of security services, reflecting the requirements of the users, have been identified. The list is not static, and more and more services are identified, as the technology and known techniques improve. The standard source is ISO International Standard 7498-2: Open Systems Interconnection Reference Model Part 2: Security Architecture, 1989.

Appending a hand-written signature to a document, mailing a registered letter, etc. are corresponding examples of applications of security services which are essential in the paper world.

Traditionally, auditors divide risks of information into 3 categories, namely Availability: The property of being accessible and useable upon demand by an authorized entity.

Integrity: Detection in the broadest sense of any kind of alteration or destruction, including possibly authentication and or identification of involved entities.

Confidentiality: Protection of content against the unauthorized reading, copying or disclosure.

(see for instance CEC SOGITS, working document no. 303, "Security in Open Networks") Thus the concept of integrity here is much broader than in data security, where integrity is further classified into message integrity, authentication and non-repudiation. We briefly explain the terminology.

data integrity: The property that data has not been altered or destroyed in an unauthorized manner.

data, or message (origin) authentication: The corroboration that the source of data received is as claimed.

iSecurity in open environments; TEDIS II, B7, ver. 15. July 1994.

I

4 (peer) entity authentication: The corroboration that a peer entity in an association is the one claimed.

non-repudiation services: Prevents denial by one of the entities involved in a communication of having participated in all or part of the communication.

confidentiality: The property that information is not made available of disclosed to unauthorized individuals, entities, or processes.

The point of these services is of course that they reflect the users needs, regardless in principle of whether he uses paper or EDI to communicate information.

All but the last deal with integrity in the broad sense of the word stated above. in the following, only authentication will be discussed, which implies the involvement of a person or entity. The legal aspects of confidentiality seem very limited.

For completeness, the framework definition of the tvo most important mechanisms invoked to obtain these services is included: digital signature: Data appended to, or a cryptographic transformation (see Cryptography) of, a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery e.g. by the recipient. (For non-repudiation services) manipulation detection: A mechanism which is used to detect whether a data unit has been modified (either accidently or intentionally). (For data integrity and authentication) A service, which is not directly relevant in EDI, is A.2 Access control Access control gives a user access to certain rights. This is typically the situation with magnetic credit cards. Indeed, when a credit card is used, there is not provable connection between the user and the data, only a presumed, or indicated connection, which in fact would not be detected, even if the data was replaced, unless the POS-terminal where the card is used, offers additional protection, such as cryptography (see below).

Of course, access control may be relevant in connection with. supporting services in EDI, such as storage of EDI-messages.

It is a common misconcepfion that access control methods such as PIN-codes and biometrics recognition provide some degree of message authentication. Access control provides an Security in open environments, TEDIS H, B7, ver. 15. July 1994.

identification of an entity, but does not in itself establish a connection between an entity and electronic data. More is needed.

1. Pincodes or passwords are examples of access control or identification mechanisms. It may for instance give a person access to information on a chipcard (or smartcard) or a computer.

However, if in fact they are used to encrypt an electronic document or create a fingerprint of a document, they provide authentication, but not a digital signature.

2. Biometrics can only provide identification (of an entity) and never authentication of electronic data. There is no connecting element, such as a key (see below)! In conclusion, any kind of authentication in EDI has to involve some tied connection between the entity and the data, which requires the use ofcryptographic techniques. There is no other way. Access control mechanisms, such as PIN-codes, biometrics identification etc. can not provide this. They may be part of the whole procedure: A PIN-code may give access to a chipcard which contains the secret key by which a digital signature may be created.

A.3 Electronic signatures Authentication always indicates some connection between an entity (typically a legal person) and a message.

This is.very essential to the understanding of the whole problem. In EDI, data leaves one computer and is transmitted into another. On its way, it is out of the hands of-the end-users.

This is the reason why any kind of protection can only be realized through the very form in which the data appears.

Whichever method is used, the whole point is of course that the receiver must be able to recover the message cieated by the sender and/or verify the authentication data, which may be appended, whichever form it has. Depending on the precise method, the verification process may actually result in the recovering of the message.

There seems to be an evolving tendency to use the general concept "electronic signature" to cover all methods involving some degree of authentication. Electronic signatures is a much broader concept than digital signatures (explained below). The term electronic signature is used whenever some degree of electronic authentication of a message or even just an individual takes place.

A.4 Originals and copies Security in open environments, TEDIS II, B7, vet. 15. July 1994.

r With electronic data, it makes no sense to speak of"originals" and "copies". If a message is transmitted from one computer to another, which bit string is then the original, and which one is the copy? The point is to focus on the information, or data, itself, and not "the representation" in some medium. Besides, the same information is not even represented in the same way in different environments as explained above.

However, for a great number of documents, this differentiation between originals and copies is of no practical implication. In most situations, an original is only required because this is the easiest way of providing integrity, and most important, a connection between ihe content and the signor. It may happen to be required by law to provide an original (legal formalism), but this is only to prevent forgery, not because it by nature is an imposed request (legal functionalism).

There are of course other situations, where originals are essential. This is for instance the case with negotiable and quasi-negotiable documents.

The main problem in EDI therefore is: How can measures be provided to add al these security features? As already mentioned, there is only one possibility: Cryptography. The point is that since in EDI electronic information is transported in an open network from one party to the other, in the form of an electronic (counterpart of a) document, this bit-stream must have a form which does not render it vulnerable to any kind of manipulation whatsoever. This is what is meant in general by integrity of data in the broadest sense.

CryvDtographic techniques Any authentication of an electronic document requires the use of what is called cryptographic techniques (which does not rule out other assisting techniques, such as tamper resistance, which will restrict the user to perform certain manipulations only), explained below.

Again, the reason is simply that this is the only way to ensure that not everyone could have generated, or altered, the data. In EDI, there is nothing else to rely on, as all data are let out in the free, so to speak.

The only possibility is to individualize the message itself in some manner, e.g. by cryptographic techniques.

The strength and the implications of this authentication depends entirely on the nature and the properties of these techniques. It is therefore necessary to understand some fundamental principles of cryptography.

cryptography: The discipline which embodies principles, means, and methods for the 'Security in open environments, TEDIS II, B7,'ver. 15. July 1994.

:I

transformation of data in order to hide its information content, prevent its undetected modification and/or prevent its unauthorized use.

As an example, cryptography might be applied by appending a so-called "fingerprint", to an electronic message, with the essential property that it depends on the original electronic document and something else, related to the identity of the originator of the document, called a key.

A technical alternative is to replace the message with the fingerprint. In any case the essential property of the fingerprint is that every bit in the fingerprint depends on every bit in the message. Ifjust one bit is changed in the message, this will result in the change of an unpredictable number of bits (on average half of them) in the fingerprint. This will be further explained below.

Whichever method is used, the whole point is of course that the receiver must be able to recover the message the electronic document produced by the sender and verify the fingerprint.:. Depending on the precise method, the verification may actually result in the recovering of the message.

The classical and best known cryptographic technique is A.6 Encryption/decryption This always involves a transformation of the message, called the plaintext, by a process that can be reversed. The encryption is done. according to an individually chosen rule (secret) rule, called the key, which transforms the message into a so-called ciphertext. As an example, if the electronic document is written in ordinary English, the rule could be to replace each letter by the letter which is a fixed number of steps (say three) to the right in the alphabet.

This number (three) is called the key and the encryption is to replace each letter as indicated by the key.

The inverse process is called decryption. In the example here, the key would be the same, but the decryption would of course require to take three steps to the left in the alphabet.

In principle, the difference between coding and encryption is that the latter requires that the key used for decryption is kept secret. With coding all rules are public.

Transformation of an ordinary message into an electronic document is a coding, as is the transformation of an electronic document into an EDIFACT-message. It is not an encryption, as all rules are public. Exactly which rules are being used is of no importance as long as everybody agrees to them, and there are no questions of interpretation, nor ambiguity.

SSecurity in open environments, TEDIS II, B7, ver. 15. July 1994.

V_

A.7 Symmetric and asymmetric systems Systems as Caesar substitution explained above, where the key for encryption and decryption is the same, are called symmetric, or conventional, systems.

There are other systems, where there is no obvious connection between the key used for encryption and the key used for decryption in spite of the fact that the two processes are the inverse of each other. As an illustrative example of such a system, consider translation of English into Chinese. The key to this encryption would be an English-Chinese dictionary. The inverse process, decryption, would require a Chinese-English dictionary, and the two keys are not easily derived from one another. In fact the only way to create one from the other is by exhaustive search.) Such systems are called asymmetric, or public key, systems.

In real systems, this principle is used, but base entirely on mathematics. One might say that each user develops his own language with two matching keys as above. The only input required is a sufficiently large random number.

In symmetric cryptosystems, the (one common) key is kept secret, while in asymmetric systems, one key is kept secret and the other is made public (hence the name, public key system).

A.8 Hash functions There is one other cryptographic technique which is very essential and is being used extensively: Hash functions. The point of these is the following: As explained, an electronic message a string of bits, which can be read by means of agreed codes. A hash value of a string of electronic data is a typically much shorter bit-string (64 or 128 bits) computed from the original bit string by a publicly known method in such a way that it is infeasible to find two different documents with the same hash value (collision-free). This hash value has in so to speak the same relation to the original document as a finger print has to a person.

As for the length of the hash value, it should be as short as possible (for speed and smaller storage requirements) but on the other hand sufficiently long to avoid collisions with "overwhelming probability".

If the computation of a hash value on a message requires the use of a secret key, the hash value is called a MAC (Message Authentication Code). This is a very common way of achieving Message authentication, using extensively in the banking world. This can only be computed by someone in possession of that key.

If the computation does not involve a key, the hash valued is called an MDC (Manipulation Security in open environments, TEDIS II, B7, ver. 15. July 1994.

'i Detection Code).

With these concepts and techniques, it is possible to explain electronic authentication in much greater detail (see 2.11.) A.9 Timeliness The timeliness of a particular message requires that some kind of time stamp be appended to the message, followed by some suitable cryptographic mechanism applied to this message concatenated with the timestamp. This time stamp could either be of global nature, i.e. to be used by anyone in principle, or of a special type, indicating some restricted use, provided encryption is used to create the time stamp. This encryption would have to be provided by a trusted third party.

If a person is free to decide the content of a message to be encrypted, this would allow him to use any previously used time global time stamp, no matter how it was created. Hence the time stamp must be restricted in some way to provide global timeliness, and as pointed out in the report, this requires the use of a trusted third party.

For many applications it is essential to append a date/time stamp,.or sequence number, to the electronic document to indicate when it was transmitted, or created. This prevents against replay an intruder cannot send the same message at a later stage to somebody and claim that it originated then), and it can be used as a proof that the document can be placed in time, and perhaps even more important, it ensures that the content is unique: No two messages will look the same.

The time stamp is either of global nature, like a date and time, or of a special type, for example the sequence number of the message in the sequence of all messages sent.

The timeliness of a particular message can only be achieved by adding some kind of time stamp or sequence number to the message, followed by an encryption.

Irreversible methods An encryption-decryption scheme as described above has the feature, that it readily lent itself to concealment. Anything encrypted with the common secret key of a symmetric system, or the public key of an asymmetric system, can only be decrypted by a person in the secret key.

In a number of countries, the law is quite prohibitive as far as encryption is concerned, most noticeably USA, UK, Germany, Holland and France, where data Security is considered a a Security in open environments, TEDIS II, B7, ver. 15. July 1994.

4/9 national matter and handled by the ministry of defense. Therefore, other systems have been developed, most recently the so-called DSA or DSS (Digital Signature Algorithm/Scheme), by the NSA (National Security Agency), USA, which are not easily (mis)used for concealment.

The method used here is that of "fingerprinting", based on the use of hash functions (MDC).

Again the technique is a public key technique, with a secret and a public key. Do distinguish between the techniques one could speak of encryption and verification.

A.11 The DrinciDle of electronic authentication Electronic authentication involves the encryption of a message or a hash value of it, using a secret key. This of course only proves that anybody with access to the secret key could have achieved that particular encryption.

In particular, if a symmetric System is used and only two entities, the transmitter, or prover, and the receiver, or verifier, have access to that key, the verifier will know if the document was encrypted by the other entity. However, a third party will not be able to distinguish between the transmitter and the receiver. This does not prohibit the distinction between the entities by other means. For instance if there is evidence that the said message was sent through a network between parties distant apart.

The strongest form of electronic authentication is that of a digital signature: It proves that one particular entity has generated an electronic message. This requires the use of asymmetric encryption explained above where the (public) key used for decryption or verification is different from the (secret) key used for encryption. Only the person with access to that particular secret key could have generated that particular encryption.

A.12 Digital si2natures The most typical, and standardized, way of applying a digital signature is the following: Each entity has created his own key pair consisting of a secret and a public key. The public key is distributed in Some secure way (in the sense that it cannot be replaced by another) to all other users. There are standards (CCITT X.509) describing how to do this. When an electronic document has to be authenticated by a particular entity, a hash value of the entire electronic document is calculated and encrypted (signed) by the secret key of its owner. This digital signature is then appended to the document.

The verification-process involves the decryption back to a hash value (MDC) by means of the public key or any other verification of the fact that-the secret. key must have been involved SSecurity in open environments, TEDIS II, B7, ver. 15. July 1994.

This value is then compared to the hash value calculated by the verifier on the electronic document using the same (publicly known) hash function.

In thisway a signed electronic document reminds very much of a signed paper document: First the document and then the signature. But a fundamental difference is that in the electronic version, the signature depends on the document. A different document will always result in a different signature. By always adding a time stamp before signing, no two messages look alike, and hence no two digital signatures look alike. Yet, the public key can be used to prove that only somebody with access to the secret key could have created the digital signature. If a different signature had been used, or the message had been changed, the verification process would have failed.

It only makes sense to speak of a digital signature, if the message (or a hashvalue representing it) to be signed has some structure, or redundancy. Coming back to the English-Chinese dictionary, only somebody in possession of the English-Chinese dictionary can produce meaningful sentences in Chinese. But anybody in possession of a Chinese-English dictionary can produce meaningless sentences in Chinese.

Another important point is the following: Recall that a digital signature in principle is a mathematical function applied to a number. Using so-called binary representation, each bit combination corresponds in a unique way to a message, just as each combination of decimals corresponds to a unique number.

Typically, the length of a digital -signature is hundreds of bits. As an example, current implementations typically result in a 512 bit (or more) RSA-digital signature. What happens if just a single bit is altered? It does not matter (a bit!) whether one or several or many are changed. The signature is wrong and the verification will fail. For this reason, the network used has to be very reliable. If this is not the case, the technique of error-correction codes are used.

They have exactly the same effect as a spell-checker, except that most of the times, there will always only be one possible solution. This, incidently, is also the techniques used on compact discs. The way this is done is by adding redundancy, i.e. extra information, which depend on the original information. This idea was introduced by Hamming in 1948, to reduce functional errors in computer calculationl A natural question then is: Since a signature may be altered (slightly) on its way to the receiver and then automatically be corrected by the network, is this of any legal consequence? The answer is of course The errors will only be corrected if mathematics imply a unique solution.

On the other hand, this also implies that if a few bits are missing or altered, it is possible on the basis of pure mathematics to correct this. Assume for instance'that a digital signature of 512 bits is being transmitted, and after successful transmission of 508 bits the line is cut. It is then an easy exercise for the receiver to "guess" the missing four bits. Indeed, there are exactly 16 possibilities for those missing. He may then try all 16 possibilities, until the verification returns i N Security in open environments, TEDIS II, B7, ver. 15. July 1994.

"true".

This procedure will work as long as there are not too may possibilities to check. If 64 bits were missing, say, it would be practically infeasible. Hence this does not present any threat to digital signatures. It merely reflects that fact, that anybody, or any algorithm, which can produce a substantial part of a digital signature, in fact can produce the whole signature. This is a very important aspect of "fair exchange of secrets".

A.13 Non-repudiation services Non-repudiation services always ensure that a particular user cannot deny responsibility. For instance non-repudiation of origin, or receipt, always require either a digital signature or message authentication by symmetric encryption AND the use of an Unconditionally Trusted Third Party (UTTP).

The point is that if symmetric methods are used, it is impossible for a third party (a judge) to distinguish between the sender and the receiver. Thus other techniques are required. The most common solutions are either to always communicate through a UTTP, which provides the distinction, or to have a UTTP install tamper resistant hardware at both users, enforcing the use of "control vectors" (an IBM-concept). This is a technique which ensures that even though the sender is using the same key as the receiver, the hardware will only allow the sender to encrypt, and the receiver to decrypt. In particular the key used is unknown to the sender and the receiver. It is protected inside the hardware, under the sole control of the UTTP.

Security in open environments, TEDIS II, B7, ver. 15. July 1994.

Annev. Mandate 6. 0* f inal report Report for the TEDIS programme By Marinade Limited all rights reserved, except those which belong to others.

Draft version 1.1 15! <5 -7 .q 3 v

'AV

Marinade Limited 2 Draft Final Report 07/02/95 Contents 1 In tro d u ctio n 3 1.1. The TEDIS programme 3 1.2. Project Mandate 3 1.3. Background research 4 1.3.1. Negotiable documents in general 4 1.3.2. Contractual solutions 4 1.3.3. Trusted third parties 1.3.4. Security in open environments 2. Requirements on a negotiable document 6 2.1. N ego tiab ility 6 2.1.1. Bills of 2.1.2. Voidness of 7 2.1.3. Permanent 2.1.4. Debt settlement obvious from 7 2.2. U n iqu en ess 7 2.2.1. Signature 8 2.3. Embodiment of rights and separation from underlying co n tract 8 2.4. Functions of identification and presentation Statu tory definition 9 3. L egal solu tion 3.1. Fram ew ork 3.1.1. Identity of central party 3.1.2. Format of framework contract 11 3.1.3. Contents of a framework 3.2. Changes of 3.3. International 4 T echn ical solu tio n 4 D O C 4.1.1. Creation of an electronic negotiable 4.1.2. Transfer 4.1.3. Presentation and 4.2. Functionally trusted third 4.3. Functionality from a user point-of-view 17 4.3.1. The user receives a blank 4.3.2. The DOC-carrier is initialised by the bank 17 4.3.3. The user issues an 17 4.3.4. Transfer of 17 4.3.5. Sp lit of E N 18 4.3.6. Cashing the 4.3.7. Back-up and disaster recovery 18 Notes on a commercial solution 21 6. Fit with requirements 22 6.1. Negotiability 22 6.2. U niqueness 22 S i Mandate Final Report c<.

Marinade Limited Draft Final Report 07102195 6.3. Embodiment of rights and separation from underlying co n tra ct 2 2 6.4. Functions of identification and presentation 22 Statutory 4~"i; i Mandate Final Report Marinade Limited 4 Draft Final Report 07102195 1. Introduction 1.1. The TEDIS programme There is an increasing integration of business operations across Europe, following the introduction of the Single Market (and eventually, the EES agreement) and the free movement of people, capital, goods, services and information. This inevitably results in increased complexity and changed demands on the administration of business, both for the commercial enterprises themselves and for the governmental and other administrative bodies with a responsibility for trade.

In order to cope with these increased and changed demands, while at the same time making business administration more efficient, EDI and related techniques are being adopted at an accelerating pace throughout the Member States. Such techniques effectivise business administration, partly through replacing the massive volumes of paper required for trade transactions.

The Commission of the EC recognised at an early stage the potential of EDI for making the aims of the Single Market a reality. It was clear from the outset that, in order to achieve the fullest possible uptake of EDI within the Member States, it would be necessary to review the legal implications of the changed business practice. In establishing the second phase of the TEDIS programme (Decision 22nd July 1991 91/385/EEC), the Council of the EC specifically included in the list of measures to be taken the tasks to: ensure, from a legal aspect that functions accomplished by EDI messages are also valid in order to carry out functions of a legal and reglementary nature analyse the impact of EDI messages on the traditional functions of negotiability 1.2. Project Mandate The development of electronic business practice has shown that, in order to produce electronic alternatives to paper based trading, it is neither necessary nor desirable to produce exact replicas of the paper documents to be replaced. What is necessary, however, is to develop electronic trading solutions such that the full functionality of those documents can be replicated.

For most trading scenarios using paper documents, this presents few problems. However, paper documents achieve their functionality not only through carrying written information, but in certain instances, the physical presence of the paper itself achieves a vital business function. In other words, there is a difference between the paper as information-carrier and the paper as a token.

S"Mandate- Final Report Marinade Limited Draft Final Report 07102195 This difference is particularly visible in the field of negotiable instruments, which, in order to achieve their functionality, must be unique, since they are traded as a token representing a specific value. It is not immediately apparent how this functionality can be achieved by electronic messages, since such messages have no physical presence, nor can their uniqueness easily be guaranteed.

One way of guaranteeing uniqueness in an electronic environment is to make use of an Unconditionally Trusted Third Party (TTP) to act as a registrar of successive holders of rights under the equivalent of a negotiable document.

However, such solutions may have commercial drawbacks in that the expense involved in implementing UTTP operations may be high, and the commercial integrity and neutrality of the UTTP may be difficult to guarantee to the users.

The overall objective of MANDATE is to establish the commercially most acceptable electronic alternative to negotiable documents, which also satisfies all requirements of the legal systems prevalent in the Member States.

Such a solution will require a combination of legal and technical features. It will have to be commercially acceptable, both through low expense and through trustworthiness. The user of the MANDATE solution will have to accept three concepts which vary from the paper-based scenario. These three concepts must be considered separately: The technical process The TTP element for validation and authentication purposes Contractual responsibilities 1.3. Background research The legal research was carried out by a team of legal experts concentrating on English, Belgian and French and Swedish jurisdictions, with the German Bundesnotarkammer considering the German jurisdiction and the role of the notary.

1.3.1. Negotiable documents in general The first task of the legal panel was to research and report on the principles of law for negotiable instruments in the three types of jurisdiction and to examine to what extent mandatory law (sometimes. of a. non-commercial nature) restricts the development or usage of such electronic alternatives. The Bundesnotarkammer prepared a paper on the role of the Notary in electronic transactions.

Mandate- Final Report Marinade Limited Draft Final Report 07102195 1.3.2. Contractual solutions The study on the principles of law for negotiability highlighted the fact that electronic negotiability is certainly not catered for under present law in the different jurisdictions. Until the law is amended it appears that parties wishing to carry out the functions of negotiability would have to enter into some type of contractual relationship. The second task of the legal panel was to find out if this was acceptable in the different jurisdictions, and what type of contractual arrangement would be most suitable.

1.3.3. Trusted third parties As part of the background research, a paper was drafted, discussed and revised which described the functionality of the TTP and described how this could be achieved technically 1.3.4. Security in open environments An earlier TEDIS II study (B7 Security in Open Environments) dealt with the concept of uniqueness in relation to electronic versions of negotiable documents. Based on an exhaustive review of scientific literature, it concluded that methods are available, which do not depend on an Unconditionally TTP to register these rights. Such methods would be based on cryptographic techniques and tamper-resistant hardware. The technical solution presented in this study is to form the basis of the MANDATE solution.

/~4 7 Mandate Final Report Marinade Limited Draft Final Report 07102195 2. Requirements on a negotiable document This chapter presents an overview of the legal environment within which traditional negotiable instruments exist. It is, however, of necessity, only an overview and not a detailed description. To produce a correct and concise detailed definition would present almost insurmountable difficulties. Rules on specific negotiable instruments, for example transport documents and payment instruments, contain small subsets of very wide and general rules, together forming the backbone of the whole commercial legal system. If detailed rules are isolated from the system as a whole, the risk of misunderstandings and unclearness is very great.

Furthermore, traditional rules assume an infrastructure dating, in some cases, back to mediaeval times and based on paperbased mail services and long sea voyages. The infrastructure required for the Mandate solution is one of computers and data networks, which demands quite different solutions. For instance, if traditional rules require a holographic signature (which in any event is not a very effective method of authentication), this does not mean that the same requirement is valid for today's infrastructure.

Clearly, a detailed and full review of all traditional rules would not necessarily be an efficient use of time for the computerised solution proposed in this report; but instead, the report must concentrate on the functions required for the electronic infrastructure. The report is based on this premise, and the description below of traditional rules should be read in the light of this.

2.1. Negotiability The very essence of negotiability is that a transfer of negotiable rights conveys upon the transferee in good faith exactly those rights which the evidence of transfer would seem to imply. In other words, when a negotiable document is transferred, it is exactly the rights evidenced by the document which are transferred, even if the transferor did not in fact have good title to those rights.

This is an exception from the normal rule in European legal systems, which says that a transferor cannot convey better title than he himself has.

Of course, there are exceptions to this rule. The cases where the transfer of a negotiable document does not convey rights can be divided into two categories: those which have a general validity and which can always be raised as a defence (real defences), and those which are personal to the transaction between a specific transferor and transferee (personal defences).

Under Scandinavian Law the latter type of defences cannot be raised against a transferee in good faith, (but they can be raised against a transferee who is ,in bad faith, i.e. one who knows about the defect in title) and include for ;,7U "instance that the document was not validly delivered to the transferee but Mandate Final Report Marinade Limited Draft Final Report 07102195 stolen or obtained by fraud, that the document was issued under mild duress, or that the underlying debt has been cancelled through payment, agreement, offset or court order. The precise rules vary between the jurisdictions studied (for instance, English Law limits the defences available far more strictly), but the principles remain the same.

The other exceptions are, perhaps, more interesting.

2.1.1. Bills of lading Bs/L do not convey better title to the transferee than the transferor had. They are therefore known as quasi-negotiable documents, since they have all the other characteristics of negotiable documents.

2.1.2. Voidness of document If the document was not validly issued, for instance does not conform to the form requirements for certain documents, o was issued by someone who did not intend to issue a negotiable document, or by somebody who was not capable of issuing such documents (being, for instance, a minor); if the document was forged or some other major illegality affects it; in such cases, the document was never a proper negotiable document in the first place.

This defence can always be raised by the debtor.

2.1.3. Permanent cancellation If the debt of the document (not the underlying debt) has been permanently cancelled in a way which is public knowledge, for instance because the document has been "mortified" by a public procedure, or because the value of the debt has been paid into court, then this constitutes a real defence in continental and Scandinavian jurisdictions, but not under common law.

Indeed, the procedure of "mortification" does not appear to exist in the UK, but is closely mirrored by the concept of accord and satisfaction.

2.1.4. Debt settlement obvious from document If the document itself evidences that the debt, or part of it, has been settled, or is likely to have been settled, for instance if it includes an amortisation plan, then this is also a real defence.

2.2. Uniqueness Since a negotiable document embodies a value of some kind, it is of course -:extremely important that the document is and remains unique. This is clear 'w'ere the document relates specifically to some unique right, for instance a Mandate-Final Report Marinade Limited Draft Final Report 07102195 B/L, which embodies the right to take possession of a specific cargo consignment; but is equally true for more generic documents, for instance a bank note, which at least in theory embodies a small part of the national debt.

It is in the interest of the document debtor that his obligation does not become multiplied while the document is current. Therefore, document debtors of various kinds have taken great care to ensure the uniqueness of the documents they issue. Protection against duplication normally takes the form of affixing the issuer's holographic or otherwise difficult to forge signature to the document. For bank notes, special paper, watermarks, printing and other technology is applied, coupled with severe criminal legislation to deter potential forgers.

2.2.1. Signature The requirement for a signature varies somewhat between the legislations investigated. Under Belgian and French law, a signature is normally required. It does not normally have to be holographic, but can be printed or stamped. However, under Belgian law, the signature on checks has to be hand-written. French law was amended specifically on this point, to allow for facsimile signatures.

In German law, any document which must by law be in written form, must either be signed by the issuer's own hand, or by a sign authenticated by a notary. Facsimile signatures may be acceptable, for instance on share certificates, but on bonds and debentures, whilst a signature produced by "mechanical reproduction" may be acceptable, it has been suggested in the literature that a signature "produced by ordinary printing" would not be acceptable.

Under Swedish law, a signature is required by custom, but not by law. The signature can be produced by any means.

Finally, in the UK, signatures are rarely required by law, except for negotiable instruments. However, there is no definition of a signature so facsimiles are acceptable.

A great deal of work on the subject of electronic replacements for signatures, and their acceptability in different countries, has already been carried out within the TEDIS and other programmes, and we refer to those reports for further reading.

2.3. Embodiment of rights and separation from underlying contract An essential characteristic of the negotiable document is that it embodies one or more rights, and becomes both the symbol of those rights, and the means by which they can be traded. These rights may have arisen out of some other ,contract, for instance, a cheque may have been issued in payment of a debt Mandate Final Report Marinade Limited Draft Final Report 07/02/95 arising under a contract of dry cleaning, but when the rights have been expressed in the form of a negotiable instrument, they become separated from the original contract. Thus the cheque issuer can not use any defects in the performance of the underlying contract to dispute the validity of the cheque. An exception to this would be "fundamental failure of consideration" under English Law.

2.4. Functions of identification and presentation The negotiable document can be transferred without notification to the document debtor. This is an exception from the normal rule, which says that the transfer of rights against a third party can only be effected if the debtor is notified prior to payment.

As a result of this rule, the holder of a negotiable document is certain of receiving payment, and equally, the debtor knows that he can validly discharge his debt by paying the person presenting the document itself.

However, the debtor must check that the presenter is the rightful holder. In the case of a bearer document, no particular checks are required. Most negotiable documents, however, are order documents, which means that they can only be transferred by endorsement. In such a case, the debtor must check that there is a valid endorsement chain leading to the presenter.

There are also instruments transferable by registration, for instance, under French and Belgian law, a share certificate is only validly transferred when the transfer has been registered in the share register held by the company.

Statutory definition Negotiable documents are usually defined in separate statutes. This is essential in English and German law because they incorporate several exceptions from the normal legal rules, as described above.

In general, in the jurisdictions reviewed, new negotiable documents can be created by practice, in the same way as the existing negotiable documents have established themselves through long periods of commercial use, but this will take a long time, and is not a practical way ahead. For the foreseeable future, any rules relating to such a new negotiable document would have to be fixed in a contractual arrangement. Under German Law negotiable documents can only be created through a covering law.

Mandate Final Report Marinade Limited Draft Final Report 07102195 3. Legal solution 3.1. Framework contract In most jurisdictions studied, negotiable instruments are only those defined by law, and it is not possible for parties to create new such instruments by agreement. However, it does seem that the law does not explicitly prevent new equivalents of negotiable instruments from being created by trade custom; and it is proposed that, in practice, it would be possible, eventually, to establish equivalents to negotiable instruments in most European legislations.

To achieve some sort of legal certainty, it would be necessary for the parties wishing to trade using some electronic alternative to traditional negotiable documents to enter into some sort of contractual relationship, which creates the same legal relations between them, as would have applied, had a negotiable document been issued and traded. However, the problem is that there are legal relationships between all the parties involved in issuing, trading and presenting negotiable documents. To arrange the same by bilateral contracts would require an exponentially growing and quite unwieldy number of contracts.

There are two possible solutions, firstly a horizontal solution which would involve establishing a contract between the two interested parties each time a transaction is entered into and the second solution, which is perhaps less time-intensive, whereby each interested party makes a separate contract with a central entity prior to being able to trade with other parties.

Therefore, the preferred proposed solution is to create a framework contract involving each party wishing to trade in the electronic environment. This contract should be established between each party wishing to join the system and some central party. It appears that, in all jurisdictions reviewed, such an arrangement would be sufficient to create binding contractual relationships not just between the users and the central party, but also between all users.

The essence of this framework contract is to guarantee that the all users have accepted the technical concept, the identity of the TTP or TTPs (several may be required to perform different duties, e.g. validation, authentication and registration), and the commercial contractual responsibilities which follow from the use of the system.

This framework contract should be as generic as possible, in an attempt to cover different types of negotiable documents, but it may be necessary to introduce a technical annex for different types of electronic negotiable instruments.

Mandate Final Report Marinade Limited Draft Final Report 07102195 3.1.1. Identity of central party The question then arising is: who should be this central party? It could either be a TTP of some description, or else a "club" consisting of all the users.

English law does not appear to have a problem in defining a very loose group of users as a club, as long as the obligations between them are very clear, but in other jurisdictions, difficult questions may arise over the ability of such a loose group to enter into any form of contract. Therefore, the preferred solution would be to institute a formal legal party, for instance a Societe Cooperative under Belgian law or a Company Limited by Guarantee under English law, which could be owned by all users. In such a case, the framework contract forms part of the constitution of the legal entity, which absolutely binds the members to its rules.

Alternatively, one could make (one of) the functionally TTP described below enter into the framework contract with each user; this would then be a type of service provider contract.

Whilst the legal entity owned by the userscould carry out some of the TTPfunctions, this could conceivably lead to conflicts of interest. Therefore, it would be preferable for the user association to be a completely separate entity, perhaps buying in all TTP services from suitable organisations on behalf of the membership.

3.1.2. Format of framework contract It is proposed to draft the framework contract in the form of a "rule book", in much the same way as, for instance, P&I clubs present the content of their insurance arrangements to the members. Rule books have the advantage of being more readily acceptable to the layman (who eventually may become quite an important player in any scenario involving electronic replacements for negotiable documents) than the usual format of contracts in international trade practice. In addition, they can more easily accommodate rules of a disparate nature (in particular, rules covering the relationship between different users, as well as rules for the relationship between the central party and the individual user).

3.1.3. Contents of a framework contract It is tentatively proposed to refer to the rules in the framework contract as the ENITERMS, for Electronic Negotiable Instrument Terms. As a minimum, such a contract would need to include rules on: 3.1.3.1. All parties to be members of the club So that the parties to the electronic equivalent of a negotiable ~instrument will be liable on the electronic instrument as if it were in K writing it will be necessary for there to be a watertight express Mandate- Final Report Marinade Limited Draft Final Report 07102195 prohibition preventing anyone from becoming a party to the process either a drawer, a drawee, an acceptor, a payee or a holder) unless that party has agreed by prior binding contractual obligation to comply with the rules of the club.

Because the paying bank must be a party to the electronic negotiable instrument, ENITERMS must be accepted by any bank involved in the process. As a result, an electronic negotiable instrument must win support of major Clearing Banks for them to be generally effective.

Such support will only be forthcoming if the Banks are satisfied both about resolution of technical security considerations and commercial risks.

3.1.3.2. Rules regarding non-members It should be possible under the framework contract to transfer the rights, but not the obligations, embodied in the electronic negotiable instrument on to someone who is not a member. The non-member will, however, not be able to transfer on these rights until he himself becomes a member.

3.1.3.3. Same responsibilities as with paper instruments These specifically are performance on presentation and waiver on defences.

It will also be very important for all such parties to agree to accept exactly the same responsibilities in relation to the electronic negotiable instrument as they would have accepted had they been a similar party to a paper based negotiable instrument.

All parties acquiring liability under an electronic negotiable instrument must accept that they have the same liability on the electronic negotiable instrument as they would have had it been in written form and complying with traditional requirements of statutes and case law. Such liability will be joint and several so as to place all endorsers of the electronic negotiability in precisely the same position as they would be in a paper version.

It would be desirable to create the framework contract in such a way that it could apply to all possible versions of electronic negotiable instruments, and that those rules which need to be different for the different implementations are kept in a separate technical annex.

3.1.3.4. No paper to be issued Because of the problem of duplication between electronic negotiable instruments and traditional paper negotiable instruments and because of the uniqueness of the real manifestation of the paper negotiable r_ instrument, it will be necessary for the issuer of all electronic Mandate Final Report Marinade Limited Draft Final Report 07102195 negotiable instruments to undertake that once an electronic negotiable instrument has been issued, there will be a promise not to issue any alternative to that electronic negotiable instrument in paper form.

3.1.3.5. Acceptance of electronic evidence of title There must be an obligation on the payee (the person entitled to receive payment) and all subsequent endorsee of that payee (the holders and holders in due course for value) that upon accepting an electronic negotiable instrument they agree that they accept the previously agreed level of electronic evidence of title without challenge.

There must be an obligation on the payer under an electronic negotiable instrument to pay in accordance with the electronic evidence of title. This electronic evidence of title will, depending upon the solution used, either be encrypted within the electronic process itself or will be by reference to the identified beneficial owner in the register held by a trusted third party., 3.1.3.6. Definition of parties ENITERMS will have to define the identity of the various parties, including if appropriate, the trusted third party. The process of electronic endorsement of the negotiable instrument must be agreed on terms prohibiting any party from objecting to any endorsement as long as that endorsement complies with the definition of endorsement in ENITERMS for the electronic negotiable instrument.

3.1.3.7. Equivalent of Deemed delivery In order to comply with the requirements of English law (and possibly other jurisdictions as well) which demand that a negotiable instrument must be delivered, i.e. physically passed to the person currently having the benefit of the negotiable instrument after negotiation, it will be necessary for ENITERMS to specify that all parties agree that there will be "deemed delivery" of the electronic negotiable instrument 3.1.3.8. Equivalent of no defence of inadequacy of protest There must be agreement by all parties to the electronic negotiable instrument that they will raise no defence alleging inadequacy of protest of a dishonoured negotiable instrument.

3.1.3.9. No defence of inadequacy of consideration in underlying contract In the same manner all parties must agree not to raise any defence based upon inadequacy of consideration in the underlying contractual 7 Mandate Final Report Marinade Limited Draft Final Report 07102195 relationship which has given rise to the electronic negotiable instrument other than a defence based on total failure of consideration.

3.1.3.10. Law and jurisdiction The parties will also have to agree on the proper law to be applied to ENITERMS with a mechanism for dispute resolution, i.e. arbitration, and standard contract terms covering non-assignment of the obligations under the rules, notice provisions and provisions for amendment of ENITERMS as appropriate. There will also have to be a provision preventing repudiation of ENITERMS for as long as any electronic negotiable instrument remains uncollected.

There is also the possibility of creating an arbitration service, to be offered to the users for resolving disputes out of court.

An outline framework contract, based on a user association in the form of a Socigtj Cooperative under Belgian law can be found at the end of this report as Appendix 1 3.2. Changes of statute It is acknowledged that, ultimately, it would be preferable to regulate the relationship between users of an electronic alternative to negotiable instruments by statute, rather than by somewhat more cumbersome contractual arrangements. However, the legislators are unlikely even to take notice of developments in this field, before their use has become quite widespread. Even then, it may take several years of drafting and agreeing through parliamentary committees, before a suitable set of statutes may be adopted in the major trading nations.

It would also be necessary to guide the legislators quite carefully, to avoid any new law being tied to specific technology or cryptographic algorithms, while ensuring that only sufficiently strong methods for digital signatures etc. gain recognition by the law.

The process could clearly be speeded up through an EC directive, which would also have the benefit of ensuring harmonisation between regulations in the different EU countries. But it is not in anybody's interest to start drafting statutory rules, until some experience of actual usage has been gathered.

3.3. International acceptance Another way of achieving legal certainty without having to rely on _multilateral contracts would be to get a suitable international body to agree a coriention for the use of electronic alternatives to negotiable documents.

S Sighificant parts of the law in force concerning negotiable instruments have Mandate Final Report Marinade Limited Draft Final Report 07102195 been created in this way, so it would be a "natural" mode of progress.

Another advantage would be that the international convention would very quickly count as normal practice, and so it would not be necessary to get all trading nations to change their statutory law immediately.

The question here would be: which international body? There are several possible candidates, including UNCITRAL, UN/ECE and the ICC. All these bodies are quite happy to get well thought-through proposals to debate. One potential field for further research would be to draft a proposal, perhaps even with draft convention text appended, and decide where and how to submit it.

But this lies beyond the scope of the current Mandate project.

7 IMandate nalport Mandate -Final Report Marinade Limited Draft Final Report 07102195 4. Technical solution The technical solution is independent of the message structures chosen.

4.1. DOC-carrier The DOC-carrier is described in detail in the TEDIS report "Security in open environments", to which the reader is referred for further study. See Appendix 2.

The most important distinguishing feature of the DOC-carrier is that it must be tamper-resistant. It must therefore be implemented in some special hardware. The most likely type of hardware would be a smart-card, but other solutions are possible. (However, the storage capabilities of current smartcards are somewhat limited, and it may be that the definitive solution will require a new generation of smart-cards to be developed. It is also possible to store only a small summary of each document, a so-called hash value, on the DOC-carrier, which reduces storage requirements significantly.) The DOC-carrier needs to store, in such a way that it cannot be disclosed, a secret key, unique to the DOC-carrier. In addition, it needs to carry, in a readonly manner, its own corresponding public key, the public key of a Certification Authority, and a certificate by the C.A. of its own public key.

4.1.1. Creation of an electronic negotiable right The right to be handled by the DOC-carrier system is created as an electronic message containing all the relevant data. This is digitally signed by the issuer, and the resulting data string DOC Si(DOC) (where DOC is the electronic message, and Si(DOC) denotes the issuer's digital signature on that message) is transferred in a secure manner onto the issuer's DOC-carrier. It is vital that Si(DOC) does not get disclosed, since it is this data which carries the value and therefore needs to remain unique. However, it is in the issuer's interest not to have to perform twice for the same obligation, so this presents no logical problem.

4.1.2. Transfer The system is built on the assumption that transfers of the DOC Si(DOC-) string can only be carried out between authorised DOC-carriers. This is achieved by the software on one DOC-carrier only accepting a transfer to another DOC-carrier; and it can recognise the presence of another DOCcarrier from its certificate.

Thus, when DOC-carrier A is supposed to transfer a DOC Si(DOC) string to DOC-carrier B, it first requests B to send over its public key PB, together with L the relevant certificate from the C.A. Since DOC-carrier A has the public key Mandate Final Report Ilk Marinade Limited Draft Final Report 07102195 of the C.A. in its memory, it can verify that B's certificate indeed refers to another DOC-carrier. A then encrypts the DOC Si(DOC) string with B's public key PB, and sends the result (PB(DOC Si(DOC))) over to B.

In this way, the valuable issuer's signature Si(DOC) never gets disclosed, since it only ever travels encrypted under the recipient's public key, and is therefore not readable by anybody other than the receiving DOC-carrier. This means that a totally insecure network can be used for the transfers. It also does not matter if there is a transmission problem so the PB(DOC Si(DOC)) string is not full received by B; A can always re-transmit the string as many times as may be required.

4.1.2.1. Certainty of message content There needs to be a secure way of showing the operator of a DOCcarrier exactly what it is he is signing, to ensure that only such rights as he would want to transfer are actually transmitted by the DOCcarrier. But as there will be no way of comparing the message DOC with the data string being passed from DOG-carrier A to DOC-carrier B (since this is encrypted with public key PB), this does require a good deal of trust in the system. This, it might be added, is a problem for all security systems based on the sending of encrypted data.

This effect could be ameliorated if the string to be sent from A to B 'takes the form DOC PB(Si(DOC)) instead if only the signature part is sent in an encrypted form). (It would, of course, still be possible to encrypt the entire message for the purposes of securing it during transmission; the difference being that, when the message is encrypted under the recipient's public key PB, it can only be decrypted by the recipient's DOC-carrier, where the corresponding secret key SB resides.) Nonetheless, the question of whether the signature actually matches the message remains; but there is always going to come a point where the user has to rely on the quality of the system implemented.

4.1.3. Presentation and accomplishment This is achieved in much the same way as any other transfer, except that the issuer's DOC-carrier will of course recognise its own signature on the original message, and can therefore be instructed to consider its receipt as a conclusion of the overall transaction.

4.2. Functionally trusted third party For the technical solution to work, two functions of an FTTP are required: firstly, it is necessary to have a certification authority to produce certificates S.for all the public keys used by the DOC-carriers; and secondly, an FTTP must Mandate Final Report Marinade Limited Draft Final Report 07102195 produce the DOC-carriers themselves in such a way that they each possess a secret key which is not known even to the owner of the DOC-carrier.

Clearly, these two functions could be carried out by the same party, but equally, they could be split up on organisations of somewhat different nature: the CA needs to be a globally reputable organisation, but can (perhaps should) keep a significant distance from the world of practical commercial realities; whereas the DOG-carrier producer needs some technical infrastructure to produce the DOC-carriers (which are likely to be implemented as smart-cards), as well as access to a physical distribution chain.

4.3. Functionality from a user point-of-view In the demonstration model accompanying this report, the negotiable document to be replicated is the cheque.

The implementation works as follows: 4.3.1. The user receives a blank DOC-carrier.

At this stage, the DOG-carrier has been programmed with its own secret key, the public key of the TTP creating DOG-carriers, and a public key certificate for its own public key. The TTP creating DOG-carriers may be the user association, or perhaps another TTP employed specifically for this task. This TTP acts as Certification Authority for the DOG-carrier's security domain.

4.3.2. The DOC-carrier is initialised by the bank The DOG-carrier will then be initialised by one or more banks. The banks "personalise" the DOG-carrier for the user, by recording the user's account number and other bank data, and enabling the user to issue a specific number of electronic cheques drawn on that bank. These are known as ENIs (Electronic Negotiable Instrument). The same DOG-carrier may be initialised by several banks where the user has accounts. The DOG-carrier has now become "an electronic cheque-book".

4.3.3. The user issues an ENI To create an ENI the user puts his DOG-Carrier into a smart-card reader, which is connected to his PC. He fills in a message which appears as a blank cheque on his PC screen. Data such as bank, account details, account holder will appear automatically, having been initialised by the bank. The user will fill in the relevant data (value, period of validity, payee or made out to bearer). The user transfers the message on to the DOG-carrier, where it is S 9 igitally signed.

adt- J k !Mandate Final Report Marinade Limited Drft Final Report 07102195 4.3.4. Transfer of ENI An ENI can only be transferred to another authorised DOG-Carrier. When the issuer or transferor wishes to send the ENI he has created to the proposed transferee, he establishes a telecommunications link via the Internet) and requests the transferee to send over the public key certificate resident on his DOG-carrier. This is verified automatically (the issuer's or transferor's DOCcarrier is programmed with the Certification Authority's public key). The issuer/transferor then encrypts the data with the transferee's public key and sends the result to the transferee, who becomes the next holder of the ENI.

If the transfer fails, the ENI data can simply be re-sent as many times as required, because the receiving DOG-carrier will only handle the same ENI once. As soon as a successful transfer has been achieved, the DOC-carrier will not accept further imports of the same ENI.

The ENI is freely transferable among DOG-carriers, so the same ENI can be active for a long period. This leads to a problem, for what if a certain ENI, perhaps after many transfers, is to be transferred back to a DOG-carrier which already has appeared in the trading chain? This could happen for instance with ENIs representing Bs/L in the commodity trades, or where the same "electronic cheque" is used in settlement of a series of unrelated transactions (here, the ENI is effectively acting as cash).

However, if the ENI has been transferred as an "order document", in other words, the intermediate holders have endorsed the ENI, then the addition of these endorsements changes the total data content of the ENI, so the DOGcarrier will be capable of recognising it as a new instance of the same ENI. In addition, the system implements a counter, which is updated each time the ENI is transferred. Therefore, even if it is being transferred as a "bearer document", its new manifestation will have changed in that the transfer counter will have a higher value.

If the receiver does not wish to accept the ENI for some reason (it may not be of the agreed value, for instance), he will repeat the transfer process back to the transferor, adding a message as to why he is rejecting it.

4.3.5. Split of ENI One advantage of the electronic cheque over its paper counterpart is that the user, if he holds an ENI for a certain value, but wishes to use only part of this value to pay somebody, then the ENI can be split into two parts. The demo software incorporates this function. The splitting DOG-carrier will append its own digital signature to both parts of the split ENI, so a complete audit trail can be provided.

Mandat- Finl Repo "'Mandate -Final Report Marinade Limited Draft Final Report 07102195 4.3.6. Cashing the ENI If the holder wants to 'cash' the ENI he will carry out the transfer process to the bank which initialised the DOC-carrier which originally issued the ENI, and therefore carries the user's account. Two different scenarios are now possible: either the bank has a special DOC-carrier, which is programmed only to receive ENIs for payment, or else the ENI ends its travels by being transferred a final time from the bank back to the account holder, which gives him the opportunity to verify that all issued ENIs are being correctly paid from his account.

4.3.7. Back-up and disaster recovery If something goes wrong with the DOC-carrier, the rights stored on that hardware will become frozen and inaccessible for trading. This is because any back-up copies of data sent to the DOC-carrier will be encrypted under the DOC-carrier's public key, and, if the DOC-carrier can no longer decrypt this data, it is useless.

There are several different ways in which back-up systems can be achieved, each with advantages and disadvantages. Which system to select will depend on the value and type of ENIs to be handled.

4.3.7.1. Transfer back to issuer from back-up DOC-carrier The first system proposed is that each user should have a back-up DOC-carrier, programmed with the same secret key as the normal DOC-carrier, but also programmed so that it will only transfer an ENI back to the original issuer. If the normal DOC-carrier breaks down, the user can import the ENI (using back-up data from his message handling system) into the back-up DOC-carrier, and transfer the ENI back to the original issuer. The issuer would be contractually bound to issue a replacement ENI under these circumstances.

This system can be enhanced by the user returning the ENI to the issuer and asking for a replacement also providing a bank guarantee for the value of the ENI, to safeguard against a fraudulent demand for a replacement ENI. However, in order to avoid open-ended bank guarantees, it would be necessary to put a time limit on the validity of an ENI, so the issuer could relinquish the guarantee at some fixed point in time, when the original ENI would in any event become invalid. The period of validity would vary depending on the type of instrument being implemented, from perhaps a few months for an electronic cheques up to several years for certificates of deposit and other long-term instruments.

The disadvantage of this system is that a bank guarantee is required, ,which may be difficult and/or expensive to obtain.

Mandate Final Report Mandate -Final Rport Marinade Limited Draft Final Report 0710 2195 4.3.7.2. TTP re-issues ENI This system is also based on a back-up DOG-carrier, but here, the back-up is programmed only to transferan ENI back to the C.A., which is authorised to re-issue ENIs in these circumstances. In case of dispute, the C.A. will always be able to identify where the process has failed and whether there are any fraudulent dealings.

As with the previous system, a bank guarantee and time limit would enhance the security.

4.3.7.3. Insurance With this variation of either of the above solutions, the risk of fraudulent dealing is simply insured, and no bank guarantee is required (the insurance replaces the comfort of the bank guarantee).

The viability of this solution obviously depends on the premium level required by underwriters for such a scheme.

4.3.7.4. Double DOC-carriers In this system, each user is issued with two DOG-carriers, each with a different secret key and belonging to two different series of DOCcarriers, say Series A and Series B (this could easily be identified by the CA using a different secret key with which to issue certificates for each series). To effect a valid transfer, the ENI data must be transmitted twice, once from the transferor's A type DOC-carrier to the transferee's A type DOG-carrier, and once between the B type DOCcarriers.

If one DOC-carrier breaks down, the user can transfer the ENI back to the issuer, using only the functioning DOG-carrier. The issuer can safely issue a new ENI on receipt of such a single transfer, because even if the other DOG-carrier is in fact operational, nobody in the system will accept a transfer from just a single DOG-carrier. By returning one of the two "copies" of the ENI to the issuer, the whole is effectively disabled.

No bank guarantee or insurance is required, but the system does of course incur extra overheads in that hardware, software and communications all are doubled.

SI., Mandate Final Report Marinade Limited Draft Final Report 07102195 Notes on a commercial solution It is worth noting that the Mandate project is strictly theoretical and, therefore, the commercial solution to be adopted lies beyond the scope of the project as defined. However, the following can be considered to be some preliminary views on the commercial viability of any implementation of the Mandate solution.

The solution needs to be reasonably cheap, but, depending on the market selected, this cheapness need not be too severe a restriction, since it only needs to be cheap in comparison to the values it is supposed to protect.

The C.A. needs to be some commercially neutral party with an undoubted record for impartiality. It does not need very much by way of technical infrastructure, though. This role would seem well suited for a notary.

It is appropriate to sound a note of caution with regard to the commercial need for electronic negotiability. The reason why negotiable instruments were such a successful commercial tool for many centuries was because there was an essential commercial need for them. The crucial function which they provided was that of supplying credit. The need for that function has almost entirely disappeared because of the availability of credit in other forms. It was also the case that, although there was never any certainty that a negotiable instrument would be honoured, it was the case that dishonour was always vigorously enforced by the Courts. It was normally enforced against a party who would suffer considerable embarrassment in the event of dishonour.

The advent of the credit card providing a means for international payment on a secure basis supported by the reputation of international organisations such as American Express, Visa and Access has made the traditional paper based negotiable instrument far less essential to international trade, except for the maritime Bill of Lading. This latter instrument is, for reasons already discussed, not in any event truly negotiable.

However, the Bill of Exchange certainly continues to figure in international trade and it is interesting to note that, in another project, the banking user group have expressed particular interest in achieving an electronic equivalent for the Bill of Exchange.

7 Mandate- Final Report .N Mandate Final Report Marinade Limited Draft Final Report 07102195 6. Fit with requirements 6.1. Negotiability Negotiability cannot, in general, be established other than by statute. To replicate this function by contractual means is not easy, and may require different techniques in different jurisdictions. The generic response by the Mandate proposed solution is to achieve the same effects by contractual means. Various concepts may be adopted to achieve this; under common law those of agency, bailment, attornment and various estoppels may be required.

6.2. Uniqueness In the proposed solution, the uniqueness of each right being handled with the electronic alternative to negotiability is guaranteed by the design of the DOCcarrier. The rights cannot be copied, except possibly by the issuer, who of course has no interest in this happening.

6.3. Embodiment of rights and separation from underlying contract The separation from the underlying contract is achieved by contractual means and presents no great difficulties. The fact that the parties may have to give up certain grounds for contesting a claim (namely those related to the underlying contract) is compensated by each party in turn receiving this benefit from all other parties.

The embodiment of rights does of course not actually happen, since electronic messages are not physical entities. But the aim is to achieve the same effect for all involved parties.

6.4. Functions of identification and presentation These functions are covered by the technical design of the DOC-carrier, which is specifically oriented towards fulfilling these functions in a highly secure manner.

Statutory definition With reference to sections 3.2 and 3.3 above, it is unlikely that the proposed solution will reach a stage of statutory definition for quite some time to come.

However, this does not seem to be entirely necessary, partly because much the same effects can be achieved by contractual means, and partly because, once practical implementations based on the proposed solution have been in operation for some time, the solution may gain legal standing simply by force 7of custom.

A Mandate Final Report Marinade Limited Draft Final Report 07102195 Appendix 1. Outline framework contract Part I. Articles of Association of the Mandate User Association Chapter 1: Name, Incorporation, Registered Office, Objects and Life Article 1: The name of the Company shall be "The Mandate User Association a co-operative company of limited liability.

Article 2: The Company shall be incorporated in the Kingdom of Belgium and its Registered Office shall be situated...

Article 3: The objects of the Company are for the collective benefit of the Members of the Company, to research, promote, utilise, develop and operate systems for the electronic transfer of rights...

The Company may take whatever steps are necessary, useful or supportive of its objects, including....

Article 4: The life of the Company is for an unlimited term.

Chapter 2: Capital and Shares Article 5: The capital of the Company is divided into shares with a nominal value of 5,000 Belgian Francs each. The minimum capital of the Company shall be 750,000 Belgian Francs.

The Board of Directors may, from time to time, make calls upon the Members in respect of any moneys unpaid on their shares...

Article 6: The Register of the Company shall provide exclusive evidence of membership, and no certificate of shares will be issued.

Chapter 3: Liability Article 7: The liability of the Members towards third parties shall be restricted to their obligation to pay up their shares in the capital of the Company.

'-7Mandate- Final Report Manate- Final Report Marinade Limited Draft Final Report 07102195 Marinade Limited Draft Final Report 07/02/95 Chapter 4: Membership, Shareholding and Participants Article 8: Article 9: Article 10: Article 11: Any person, physical or legal, may be considered for admission to membership if, in the opinion of the Board of Directors, it...

No Member may own more than one share in the Company. If a Member inherits, or acquires through a merger, any additional shares, he shall be considered to hold these shares in trust for future Members of the Company and shall be obliged to sell these at their nominal value to new Members, as instructed by the Board of Directors.

The Board of Directors shall have powers to carry out, in the name and on behalf of the Member, the formalities relating to the registration of shareholding in the Company.

Any transfer of shares other than as per these Rules shall be null and void.

Chapter 5: Loss of Membership Article 12: Any Member may resign from the Company provided he gives notice in writing to the Board of Directors...

Membership shall be lost if a Member ceases to trade, is declared bankrupt, is placed under receivership...

The Board of Directors may expel a Member from the Company in cases of non-observance of the Rules, attempts at defrauding the Company or other Members...

Chapter 6: Board of Directors Article 13: The Directors shall be elected by the Members in General Meeting and shall hold office until immediately after the next Annual General Meeting. They shall be eligible for reelection.

The number of Directors shall not be less than five, nor more than....

A Director may be proposed for election by a group of not less than ten Members...

Article 14: i-.

Article 15: t. A Director shall cease to be a Director if...

Mandate- Final Report Marinade Limited 27 Draft Final Report 07102195 Article 16: Article 17: Article 18: Article 19: Article 20: Article 21: Article 22: Chapter 7: Article 23: The Board of Directors shall elect a Chairman...

The Board of Directors shall meet at least four times annually...

The quorum necessary for meeting sof the Board of Directors...

Resolution at any meeting of the Board of Directors shall be decided by a majority of votes. Each Director shall have one vote...

Minutes...

The Board of Directors shall have power [appoint managers to run the day-to-day business of the Company] [amend Part III of these Rules]...

The Company shall be bound towards third parties by the signatures of...

Auditors The General Meeting shall appoint one or more auditors...

Chapter 8: General Meeting Article 24: Article 25: Article 26: Article 27: Article 28: Article 29: Article 30: The Annual General Meeting of the Company shall be held at...

An Extraordinary General Meeting of the Company shall be held at the request of...

At least thirty days' notice shall be given [in writing??] to the Members...

The quorum necessary for a General Meeting shall be...

Any Member may appoint such person as he thinks fit to act as his representative...

The Chairman of the Board of Directors shall act as Chairman of the General Meeting...

Minutes...

Mandate- Final Report Marinade Limited Draft Final Report 07/02/95 Chapter 9: Financial year and Balance Sheet Article 31: Article 32: The financial year of the Company shall commence on...

At the close of each financial year, the Board of Directors shall prepare a balance.sheet and such other financial statements as may be required by law...

Chapter 10: Winding up Article 33: In the case of the Company being wound up, the General meeting shall determine...

Part II. General contractual terms for Electronic Negotiable Instruments Chapter 11: Definitions Article 34: In these Rules, the parties to an Electronic negotiable Instrument are defined as follows: Issuer: Drawee: Payee: Endorser: Endorsee: Certification Authority: Chapter 12: Paramount rules Article 35: Article 36: All Members agree to accept the same responsibilities, jointly and severally, in relation to any ENI as they would have accepted, had they been similar parties to a corresponding paper based negotiab!e instrument.

No Member shall permit any non-Member to become a party to any ENI, except as expressly provided for in Part III of these Rules, nor shall any Member assign any of his obligations under these Rules to any other party.

Mandate- Final Report Marinade Limited 29 Draft Final Report 07102195 Chapter 13: Electronic evidence of title Article 37: Article 38: Article 39: Any Member accepting an ENI as Payee or Endorsee agrees to accept the previously agreed level of electronic evidence of title without challenge.

Any Member being a Payer under an ENI agrees to pay in accordance with the electronic evidence of title without challenge.

All Members agree not to challenge the admissibility of electronic evidence of ENIs in any court proceedings.

Chapter 14: No paper to be issued Article 40: Any Member being an Issuer of an ENI agrees not to issue any alternative to that ENI in paper or any other form.

Chapter 15: Defences not to be raised Article 41: Article 42: All Members agree not to raise, in the case of dispute, any defence based on inadequacy of protest of a dishonoured

ENI.

All Members agree not to raise, in the case of dipute, any defence based on inadequacy of consideration in the underlying contractual relationship giving rise to the ENI, other than a defence based on total failure of consideration.

Chapter 16: Deemed delivery Article 43: All Members party to any ENI agree that completed transfer of the ENI in accordance with the Mandate Operating Procedure constitutes deemed delivery of the

ENI.

Chapter 17: Law and Jurisdiction Article 44: Article 45: These Rules are subject to the laws of Belgium.

All Members agree to submit any disputes not resolved amicably between the parties to arbitration by three arbitrators selected by...

F'

7 7 Mandate Final Report Marinade Limited Drft Final Report 07102195 Part III. Specific rules relating to ENI implementations [Section A: The electronic cheque] Clause 1: In this scenario, the role of the Certification Authority shall be limited to the production of blank DOC-carriers, provided with a private/public key pair, a public key certificate signed by the C.A. with a key used solely for electronic cheque DOC-carriers, and the corresponding public key of the C.A.

The liability of the C.A. shall be limited to the value of a blank replacement DOC-carrier.

Clause 2: Any Member wishing to operate electronic cheques shall request the C.A. to issue a blank DOC-carrier and shall pay the administrative charge agreed...

Clause 3: The owner of a blank DOdC-carrier may use this to receive, store, split and transfer previously issued ENIs. However, if he also wishes to issue ENIs, the DOC-carrier must be initialised by a Member Bank.

If the owner of a DOC-carrier wishes to issue ENIs, he shall take the blank DOC-carrier to a Member Bank where he has an account and request the Bank to initialise the DOC-carrier with its own details, the account details, and a maximum number of ENIs to be issued.

Clause 4: The owner of an initialised DOC-carrier may issue ENIs up to a value agreed with the account-holding bank.

Clause 5: In this scenario, ENIs have a maximum period of validity of three months after date of issue.

Clause 6: Previously issued ENIs may only be transferred to the DOC-carriers of other Members, except as provided in Clause 7.

An ENI may be transferred as an "order instrument" or as a "bearer instrument".

If the transferee does not wish to accept the ENI, he shall advise the transferor of the rejection and shall transfer the ENI back to the original transferor. The original transferor is obliged to accept such a re-transmission, provided that notice of the rejection was given within [24 hours?] Mandate Final Report Marinade Limited Draft Final Report 07102195 Marinade Limited Draft Final Report 07/02/95 Clause 7: Clause 8: Clause 9: Clause 10: If a Member wishes to transfer an ENI to-a non-member, the non-member shall apply for a non-Member DOCcarrier from the C.A. The non-member may not transfer or present the ENI for payment until he has become a Member.

The Holder of an ENI may split the old ENI into two new ENIs, with an aggregated value equal to that of the old ENI. Except for their value, the new ENIs shall have exactly the same effect and validity as the old ENI. The period of validity is not extended, but continues to run from the date of issue of the original ENI.

The Holder of an ENI may present this to the Drawee for payment, through transferring it to the Drawee in accordance with Clause 5. The Drawee shall account to the Issuer for all ENIs paid from his account.

If a DOC-carrier becomes inoperational, the back-up procedure shall be initiated...

Mandate Final Report Marinade Limited 32 'Draft Final Report 07/02/95 Appendix 2. Technical description of the DOC-carrier 'J

A

r Mandate Final Report

Claims (27)

1. A method of issuing an electronic negotiable document (END) comprising: creating as data an END and storing this in a tamper-resistant document carrier, the document carrier containing a unique public-secret key pair for signing and verifying and a unique document carrier identifier; signing the unique document-carrier identifier, the END and an END identifier using the secret key of the public-secret key pair and storing the result in the document carrier. S 10

2. A method according to Claim 1 of issuing an END, further comprising generating a time stamp representing the time of issue and storing this with the END in the tamper-resistant document carrier before the signing step. S

3. A method according to Claim 1 or 2 of issuing an END, including the step of calculating a hash value of the END and/or the time stamp value and storing this hash value instead of the full END in the tamper-resistant document carrier, before the said signing step.

4. A method according to any preceding claim of issuing an END, in which the 20 document carrier identifier is a device number, and the END identifier is a serial number.

A method according to any preceding claim of issuing an END, in which the END identifier is supplemented with data representing a water mark unique to the issuer.

6. A method according to any preceding claim of issuing an END, comprising the step of calculating a hash value of the data to be encrypted by the said secret key, in place of the full data.

7. A method according to any preceding claim of issuing an END, in which the /4 R cument carrier stores a negotiability status flag indicative of whether the END K.I stored therein is negotiable or non-negotiable, and including the step of setting the flag to "negotiable" after the result of the signing has been stored in the document carrier.

8. A method according to any preceding claim of issuing an END, in which the document carrier includes a counter for counting a serial number, indicative of the number of times that the END has been negotiated since issue, and comprising the step of setting the counter to zero after the result of the signing has been stored in the document carrier. I

9. A tamper-resistant document carrier adapted to store an END in accordance Swith the method of any preceding claim, the document carrier having a memory containing a unique public-secret key pair for signing and verifying and a unique document carrier identifier; said document carrier further including read only software for controlling the steps of storing the END, encrypting the END and other data with the pre-stored secret key of the public-secret key pair, and storing the result in the memory.

10. A document carrier according to Claim 9, in which the memory includes a negotiability status flag capable of being set either to "negotiable" or to "non- negotiable".

11. A document carrier according to Claim 9 or 10, in which the memory includes a counter for storing a serial number representative of the number of times the END has been negotiated.

12. A method of negotiating an END between a seller and a buyer each possessing a tamper-resistant document carrier having its own public-secret key pair, in which the END is stored in the seller s document carrier in the form of END data, and a signature generated by a secret signing-key of a document carrier of the issuer of the END, together with a negotiability status flag indicative of whether the END is S T ,wurrently negotiable from the document carrier on which it is stored, comprising establishing mutual recognition between the seller and buyer using a predetermined protocol between the respective document carriers, verifying in the seller' s document carrier that the negotiability status flag is "negotiable" and aborting the negotiation if not, sending a public encryption key of the buyer s document carrier to the seller s document carrier, and using it to encrypt the message comprising the END together with the negotiability status flag, sending that encrypted message to the buyer, decrypting that message using the buyer s secret decryption key, and setting the negotiability status flag for that END of the buyer' s and seller s document carriers respectively to "negotiable" and "non-negotiable". S *000

13. A method of negotiating an END between a seller and a buyer each possessing a tamper-resistant document carrier having its own public secret key pair, S. in which the END is stored in the seller s document carrier in the form of END data, and a signature generated by a secret signing key of a document carrier of the issuer of the END, together with a serial number counter indicative of the number of times that the END has been negotiated since issue, comprising establishing mutual recognition between seller and buyer using a predetermined protocol between their respective document carriers, verifying in the seller s document carrier that the END, if it has been stored previously in that document. carrier, has a different counter value 20 this time and is therefore negotiable, but aborting the negotiation if it is not *•000 negotiable, sending a public encryption key of the buyers document carrier to the seller s document carrier, and using it to encrypt the message comprising the END together with the counter, sending that encrypted message to the buyer, decrypting that message using the buyer's secret decryption key, and incrementing the counter by one.

14. A method according to Claim 12 or 13, in which each document carrier is installed originally with a certificate comprising a digital signature of its unique identifier and of its public key.

A method according to Claim 14, in which the certificate unique to the document carrier on which the END was originally issued is stored with the END in the seller' s document carrier.

16. A method according to Claim 14 or 15, in which the certificate of the buyer's document carrier is sent to the seller's document carrier in which it is authenticated and the negotiation is aborted if authentication fails.

17. A method according to any of Claims 12 to 16, in which the buyer' s document carrier, after decrypting the message using its secret key, verifies the signature of the issuer on the END, and informs the issuer in the event that authentification fails.

18. A method according to any of Claims 1 to 8 of issuing an END on a document- carrier followed by a method of negotiating the END as claimed in any of Claims 12 to 17.

19. A method according to Claim 18 as appendant to Claim 2, in which the buyer's i" document carrier, after decrypting the message with its secret key, verifies that the END is still valid by taking its time stamp, and, if it has expired, informs the issuer of 20 this, and aborts the negotiation before incrementing the counter or setting the negotiation status flag.

A method according to any of Claims 12 to 19 including recovering the negotiation of an END which has previously broken down, by providing the buyer' s document-carrier with the necessary secret key which has been reproduced by the issuer or by a trusted third party.

21. A method according to any of Claims 12 to 19 including recovering an END lost from a primary document-carrier, by activating a back-up document-carrier which has previously been provided with back-up data reproduced from the primary ^__-document-carrier.

22. A method according to Claim 20 or 21, comprising inhibiting the recovery until the expiry of the predetermined period of validity of the END.

23. A method of negotiating an END, sold by a seller to a buyer, the method including creating as data an END and storing this in a tamper-resistant document carrier, the document carrier containing a unique public-secret key pair for signing and verifying and a unique document carrier identifier; signing the unique document- carrier identifier, the END and an END identifier using the secret key of the public- secret key pair and storing the result in the document carrier; and, wherein the buyer splits the END electronically into two or more parts and then negotiates those parts separately to one or more further buyers. 0

24. A method according to Claim 23, in which each part is subjected to a digital signature of a document carrier of the said buyer's which effects the splitting. A method of issuing an electronic negotiable document (END) as hereinbefore described and/or illustrated in the accompanying drawings.

C

26. A method of negotiating an END between a seller and a buyer as hereinbefore 20 described and/or illustrated in tle accompanying drawings. Co..

27. A tamper-resistant document carrier adapted to store an END as hereinbefore described and/or illustrated in the accompanying drawings. DATED THIS TWENTY-THIRD DAY OF JANUARY 2003. CRYPTOMATHIC ANS BY PIZZEYS PATENT TRADE MARK ATTORNEYS