Why might you want your security system to provide non repudiation?

Increasingly, the Internet is being used to sell things: books, records, clothes, gifts� the list gets longer every day. As the transactions on the web get increasingly common, the need for security increases. One aspect of this is the actual transfer of money or credit card numbers, another is the question of privacy, as some organizations try to map consumer�s behavior and sell their information to advertising agencies. In this paper, we look at a classical security problem � the question of non-repudiation.

2. Introduction

This paper has been written as a part of the course Applied Network Security, given in May 1999 at the Department of Computer Science of Linköping University. We � Karl-Fredrik Blixt and Åsa Hagström � were assigned a project named Web Transactions as part of the examination for the course, and here we report on the work that we have carried out to fulfill the goals of the project.

Mark Vandenwauver has had the role of lecturer, waffle-maker and guru, and a helping hand has been provided by Joris Claessens. Examiner of the course is Nahid Shahmeri. We would like to give our thanks to them all, as well as to our co-students Per and Lin, who have constructed the time-stamping and certification server!

We have divided this paper into three main parts: Background, Solutions and Conclusion. In the first part we define the goals of the project and try to relate it to the whole field of computer security, examining in detail the concepts of non-repudiation and time-stamping. The following section deals with our solution to the problem and how we implemented it. Last come the conclusions that we have made regarding the project and our solution.

3. Background

On the Internet, both sellers and buyers are anonymous in a way that doesn�t resemble any other situation. The web is international � a web shop in India can very well have customers on Iceland � and national consumer laws are not powerful enough to cover the new conditions that arise. Hence, the parties involved have to take security in their own hands and arrange their transactions in a way that makes both sides comfortable and assured of their rights.

When ordering goods from a web shop, the client wants to be sure that the shop commits to the order and doesn�t forget about it. On the other hand, the web shop wants to be sure that the client is serious about the order and will pay for it. These issues are addressed by non-repudiation schemes.

In this section, we will describe the project goals and the related fields in computer security: non-repudiation and time-stamping.

3.1  The Project

Our task was to design and implement a web shop whose transactions with the customers were (reasonably) secure. This meant that some kind of non-repudiation was needed on top of the SSL layer, which is commonly used to secure communications between web browsers and servers. SSL provides confidentiality, entity authentication and data authentication. However, for transactions to be legally valid, they need to be bound in time to the parties involved � non-repudiation is wanted. Since the parties involved should be aware of the procedure, legally binding non-repudiation is not possible to achieve in a layer beneath the application layer such as the SSL layer. Therefore, it has to be provided in the actual application layer. We had access to a CA (Certification Authority) that also served as a time-stamping server (hereafter abbreviated TSS) that could be used in the project. These two services combined will be called a Public Key Infrastructure, or a PKI, although the terminology is a bit shifted.

Hence, our task was to design and implement the web shop and its communication with the client browser, including the communications with the PKI.

3.1.1  Problems

We identified the following problems to be solved:

1. What is a transaction? The data transferred from client (browser) to server has to be of a pre-defined format.
2. Against what do we want to protect ourselves? Which threats are likely to occur? Which threats is the system susceptible to?
3. At what stage in the transaction should the SSL connection be established?
4. Which data should be time-stamped in order for the non-repudiation to be secure?
5. Is there any other way than to use time-stamping to introduce non-repudiation into the system?
6. Which data should be stored during and after the transaction, and by whom?
7. Which cryptographic algorithms should be used? How long should the keys be?
8. Which hash functions should be used? Do we need keyed hash functions? If so, how long should the keys be?
9. How should keys be distributed? Do we need to exchange keys during the transaction, or could it be done off-line?
10. How will the browser and server synchronize their time with the TSS?
11. In case disputes arise, how should they be resolved?
12. What technology should be used to implement our solution?

3.2  Non-Repudiation

Before talking about non-repudiation, we will take a look at the repudiation that we want protection against. In a communications scenario, e.g. a negotiation of a contract, there is the possibility that one of the users later denies either the terms of the deal, or even that the communication took place at all. More precisely, we can separate the repudiation scenario into four distinct cases [1]:

• Repudiation of origin:
The parties disagree as to whether a particular party originated a particular data item (possibly including the time the origination occurred). In the context of the web shop, this could correspond to the buyer denying that he has placed a particular order.
• Repudiation of submission:
The sender and the Internet Service Provider (or the like) disagree as to whether the sender has submitted a particular message (possibly including the time that the submission occurred). This case corresponds to the buyer�s ISP denying that the buyer has actually sent the order.
• Repudiation of delivery:
There is disagreement as to whether a particular data item was delivered to a particular party (possibly including the time that the delivery occurred). In the web shop example, this could mean that the web shop denies having received an order (not specifying what the order is for) from a particular customer.
• Repudiation of receipt:
The parties disagree on the contents of the received message (possibly including the time at which it was received). For the web shop and customer, this corresponds to the shop denying the contents of an order.

These cases of repudiation give cause to the same number of corresponding non-repudiation services:

• Non-repudiation of origin:
The web shop gets a proof that the customer is the originator of a particular message at a particular time.
• Non-repudiation of submission:
The customer gets a proof that the order has been sent.
• Non-repudiation of delivery:
The customer gets a proof that the order has been received.
• Non-repudiation of receipt:
The customer gets a proof that the order has been received correctly.

In all the services above, it is essential that a trusted third party (TTP) be involved in the process. This can be used both for providing the proofs and for storing them so they can be retrieved at a later time.

The non-repudiation process involves a number of steps or phases [2]:

• Service request:
Since both parties have to participate actively in the non-repudiation process, they must agree to apply non-repudiation before starting the critical part of the communication. This could be done either by an explicit request from one of the parties, or by a standing arrangement.
• Evidence generation:
This phase occurs when a proof is needed for one of the above cases of non-repudiation. The party that might later deny an action participates in generating this evidence, often in collaboration with a TTP.
• Evidence transfer and storage:
When the evidence has been produced, it is transferred to the recipient and stored by the TTP.
• Evidence verification:
In order to be confident that the evidence is correct, the recipient verifies it, possibly in collaboration with the TTP.
• Dispute Resolution:
This phase is not part of the normal order of steps, but might be needed if one of the parties tries to deny part of the communication. In this case, the evidence has to be re-examined and the dispute is resolved based on this (either by the parties themselves or by a TTP).

In the above description of non-repudiation processes, we have chosen to express ourselves rather vaguely. This is because there are a number of different models for obtaining non-repudiation, and the one we have chosen is not necessarily the most obvious or even the best one. In the following, we will take a look at some different approaches to non-repudiation in practice.

3.2.1  Models for Non-Repudiation

Non-repudiation always needs to depend on the use of a TTP, because whoever will arbitrate when a dispute occurs needs evidence from an impartial source. Trusted third parties are used in a number of ways in non-repudiation schemes, e.g. key certification, identity certification, time-stamping, evidence storage, delivery agent and arbitration.

The simplest way to obtain non-repudiation of origin is simply by using regular digital signatures. The sender signs the data with his/her private signature key, and the signature itself constitutes the evidence of the origin. A TTP is needed for the checking and retaining of public-key certificates. Key revocation causes a problem for data that has been signed for non-repudiation causes earlier. Evidence that has been produced before the revocation should still be considered valid, even though the private key of the sender may be publicly known. This calls for either time-stamping or storage of signed data at the TTP, so that the validity of the signature can be verified even after revocation.

Another way to achieve non-repudiation without using time-stamping is to send the data items to a TTP, which signs them and thus vouches for the identity of the sender. The communication between sender and TTP must then be protected for integrity and data origin authentication, so that the TTP doesn�t sign illegitimate data. The transmission from TTP to sender does not need this kind of protection, as the sender can check the TTP�s signature for himself. An advantage of this scheme over the earlier one is that the need for digital certificates is greatly reduced. Since the non-repudiation is based on the TTP�s signature, which is more protected and thus more secure than the sender�s, the problems with key revocation are greatly diminished. A variant is to add a time-stamp in the signature.

An even more elaborate scheme is to let the TTP sign a hash of the message instead of the message itself. This way, data volume is reduced at the same time that data confidentiality is automatically obtained in the communication between sender and TTP. Also, the TTP does not have to be trusted for confidentiality issues but only for signing purposes.

Yet another way to achieve non-repudiation is to use a trusted third party token scheme. Instead of using the asymmetric public-key signature, the TTP seals the hash (or the actual data) with a symmetric algorithm and a key only known to the TTP, thus producing a token. In this scheme, the recipient cannot verify the evidence himself, but must send it back to the TTP for verification.

There are numerous other variants of non-repudiation schemes; the chosen ones are just samples of the choices available. However, time-stamping is one of the more powerful methods and this is why we have chosen to use it in our design. For a complete walk-through of the time-stamping process, please refer to section 5.

3.3  Time-stamping

A time-stamp is generated by a time-stamping service, which is a TTP considered reliable as a timekeeper. In many non-repudiation services, such as this one, time is an important factor, even a fundamental requirement for the mechanism.

Time-stamping by a TTP protects against deliberate publication of a private key in the cause of making old signatures invalid, for example. Also, time-stamping provides good protection against replay attacks.

The classical example of time-stamping is the researcher that wants to win the Nobel Prize � in order to prevent some other researchers of publishing their results first, he can have it time-stamped by a TTP. This arrangement lets the researcher keep his work confidential while providing a proof of the time of his breakthrough.

The requirements on the time-stamping server are mainly the following:

• The server must have a long key if the time-stamps should be reliable for a long time (maybe several decades)
• This private key must be stored very securely or else the whole system will collapse
• The time of the time-stamping server must also be stored very securely, the clock must not be resetable and should keep accurate time for many years
• It must be impossible to create time-stamps without access to the time-stamping server�s private key and clock (which are extremely securely stored)

4. Solutions

We used our knowledge of time-stamping to design the non-repudiation scheme. It consists of a sequence of steps where the client, the web shop server and the PKI in turn send data to each other.

Following this phase, we implemented our design using a Java Web Server, Java and Java Script. Some parts of the design could not be adequately implemented because of the complexity involved but in these cases, we have provided a surrogate routine.

5. Design

A scheme such as this one, involving a PKI, bases its security on the secure distribution of keys and certificates, before the actual transactions take place. The following items are supposed to be distributed off-line in a non-specified, secure way (for example by certified mail):

• The client gets his/her own certificate which validates the client�s public key PKC

• The server gets a server certificate which validates the server�s public key PKS
• Both client and server get the PKI�s certificate signature key PKPKI1, so that they can validate each other�s certificates
• Both client and server get the PKI�s time-stamping signature key PKPKI2, so that they can validate the time-stamps

Figure 1. Off-line key and certificate distribution

Assuming that this distribution has been taken care of, we now look at what happens when the client comes to the web shop. Establishing an SSL connection does cause a bit of trouble for the clients and might thus scare them off. Therefore, in order for the web shop to attract as many customers as possible, the SSL connection should be established late in the transaction scheme. Before switching to SSL, the connection is just ordinary HTTP requests and responses:

Figure 2. Normal browsing mode

At the critical point in the browsing � when the client decides to make a purchase � an SSL connection is established, and the server sends an order form to the client. This form is filled in (forming the entity O) and signed by the client; O�= O, sign(PKC-1)(O). Now, everyone who has O� and the client�s public key can verify that O was actually created by the client; the signature gives non-repudiation of origin.

Figure 3. Establishing the SSL connection

After signing O, the client calculates a hash of the message, Oh. For maximum security, this hash should involve the use of a secret key shared between the client, the web shop and the PKI. However, the main reason to use the hash function here is data authenticity (and fewer data blocks), so we content ourselves with an MDC (Manipulation Detection Code) such as RIPEMD-160 or SHA-1.

Figure 4. The order is signed by the client

After constructing the MDC Oh the client sends it to the PKI, which time-stamps it and signs the result with its private time-stamping key: Oh� = Oh, TS1, sign(PKPKI2-1)(TS1, Oh)

Note that the PKI is unable to draw any conclusions as to the doings of the client: neither the web shop�s identity nor the contents of the order are revealed in the hash Oh. All that the PKI sees is an anonymous piece of data. This is due to the fact that the actual order only is needed in order to verify the time-stamp.

Note also that the identity of the client never needs to be verified by the PKI, since it really doesn�t matter for whom the PKI time-stamps the data in this scheme. It is only the client that has the actual order, and thus the only person that can send a valid order/time-stamp pair to the web shop.

The PKI stores the resulting data Oh� for possible later use and sends it back to the client:

Figure 5. The order is time-stamped

The client forwards the signed and time-stamped order together with his/her signature certificate to the web shop, which then verifies the client�s signature of the order and the PKI�s signature of the time-stamp. The time-stamp is checked for validity � as stated in [1], time-stamps should be "recent, fresh, unique and timely" (the question of synchronization of time is addressed in section 7 below). Also, the web shop must verify that no order has been received earlier with an identical time-stamp, because that would indicate either replay or a mistake on behalf of the client.

In addition, the web shop needs to verify that the hash that was time-stamped corresponds to the actual order. This is done by simply calculating the hash of the order and comparing it to the time-stamped hash. If all verifications so far have been successful, the web shop finally verifies the actual contents of the order, so that the data itself is valid:

Figure 6. The web shop verifies the validity of the order

If all the verifications are successful, the web shop accepts the order and creates a receipt for it. This is signed with the private key of the web shop server and a hash is computed and transferred to the PKI, just like with the order:

Figure 7. A receipt is created and signed

In the same way as with the order, the PKI time-stamps and signs the hash of the receipt and sends it back to the web shop, saving a copy of it for storage:

Figure 8. The receipt is time-stamped

Finally, the web shop sends the time-stamped and signed receipt to the client together with the web shop�s signature certificate. When the data is received at the client side, non-repudiation of delivery (and actually non-repudiation of submission too, but it�s a little late at this point) is obtained. Since the web shop wouldn�t send any data if it hadn�t received the order from the client, this is the proof that the order was actually received.

Figure 9. The client verifies the validity of the receipt

Now the client verifies the validity of the receipt, just like the web shop verified the validity of the order. The verification of the contents of the receipt is (for natural reasons) not automatic, but merely consists of displaying the receipt to the client. If everything is found to be in order, non-repudiation of receipt is obtained.

Figure 10. The results of the transaction

The result of the specified activity chain is that the web shop has a non-reputable order and the client has a non-reputable receipt for it.

5.1  Analysis of the design

In this section, we will take a closer look at some of the aspects of the above scheme, using the five phases of a non-repudiation process as specified above.

• Service request:
It is the web shop that initiates the non-repudiation process. When the client has signaled that he/she wants to place an order, the web shop requests that non-repudiation be used. If the client does not want to participate in the scheme, the web shop refuses to accept the order.
• Evidence generation:
Both the processes of signing and time-stamping are part of the evidence generation. The latter activity involves the PKI.
• Evidence transfer and storage:
When the evidence has been produced, it is transferred to the recipient and stored by the PKI.
• Evidence verification:
As specified in the steps above, the recipient of an evidence verifies it on delivery (and stores it for possible later use).
• Dispute Resolution:
This phase was not specified in the steps above, since it is not part of a normal transaction. However, if a dispute should occur (and this might happen some time after the exchange of order and receipt), the PKI should be called in to arbitrate between the parties, who must produce the evidence they claim to be valid. The PKI can check all signatures, verify that the time-stamps are the same as it had stored earlier, and then decide who is right. If one of the parties doesn�t agree with the decision, some higher instance such as a court of law needs to be involved.

6. Implementation

In this section we will discuss the implementation for adding non-repudiation to a web shop. The client is a web browser, e.g. Netscape, connected to an HTTP server, in our case the Java Web Server.

The implementation is made in Java 2, also known as JDK1.2. This choice was made because Java 2 includes the Java Cryptography Extension (JCE) which contains a number of useful cryptography functions. The IAIK JCE 2.5 is the implementation of the JCE that we use, since it has no restrictions on the algorithms (no key length or algorithm type restrictions).

In order to provide the best possibilities for us to complete the implementation on time we decided to use the Java Web Server. We could then implement most of the functionality in JavaServlets, which we have used before, without having to learn a new language or means of implementing server side functionality. Unfortunately, the implementation has not run smoothly. The certificate for establishing an SSL connection has not been possible to import into the server (just recently an explanation was found and it required that we had to request a new certificate). The lack of knowledge of JavaScript has made the client side implementation consume a lot of effort. Very untimely, the time-stamping server was taken down for system upgrade, and that made it impossible to test how it was going to be used. Finally, having to learn how to use the JCE also took some time. A more detailed look at the problems is provided in the following sections.

All these factors proved to be too much. Therefore, the implementation has not been completed to date. An initial implementation has been made, but testing and verifying that the implementation works has not been possible to do and further implementation has been suspended in order to complete this report on time.

6.1  SSL connection

For minimum protection we need data integrity, data confidentiality and entity authentication. The Secure Sockets Layer, adding encryption to the HTTP protocol provides this. The "https" prefix is used when SSL encryption is added (e.g. https://hostname/).

6.1.1  Design

The SSL connection is set up by requesting a server certificate from the PKI, installing it in the server and setting up a specific port number to accept SSL connections (443 is the default number used if none is given). As soon as a connection to that port is made, the web browser and web server handle the SLL connection transparently for both the client and server side non-repudiation implementation.

6.1.2  Problems

The server certificate that was requested could not be imported into the Java Web Server because it was binary encoded. A test certificate was requested from VeriSign but it also proved to be encoded in the wrong way. Only recently was the explanation found, that the certificate had to have JavaSoft and not Sun Microsystems as the provider of the web server to make VeriSign encode it correctly. Because of the problems the SSL connection requirement was skipped during the rest of the implementation.

6.2  Time-stamping service

The time-stamping service works as a simple HTTP request/response service. The data that is going to be time-stamped is sent as an HTTP POST request. The response is 64-base encoded with textual delimiters between the different parts (the original data, the timestamp and the signature).

6.2.1  Problems

When the implementation started the main problem was how to connect to the time-stamping service in JavaScript. When trying to test this, the time-stamping server was down for a system upgrade and both persons responsible for the PKI where unreachable at the time. Instead effort was put on the rest of the implementation, and the time stamping has not been tested yet.

6.3  Client

The client is a standard web browser, capable of running JavaScript and Java. Also, it must be able to connect via SSL to the server.

6.3.1  Design

The client side implementation is designed as follows

1. The client browser requests a specific page containing the form that the user is going to fill out. The page is referred to with the "https" prefix, thus transparently setting up the SSL connection.
2. The user fills out the form and clicks the submit button.
3. The JavaScript code in the page intercepts the button click in order to process the form and add non-repudiation data to it before it is send to the server. It includes the following steps:
   
   • First, the form is converted into a readable text that is signed by the user, using the signText function. The function displays the text to the user and lets him or her select which certificate to sign it with (assuming the user has a certificate for signing data).
   • The signed form is then hashed (using SHA-1, possibly in an applet called from JavaScript).
   • After that the hash is sent to the time-stamping service, as a separate HTTP POST request, using java.net.URL and java.net.URLConnection.
   • The response of the call is the time-stamp. It contains the original hash, the time and the signature of the time-stamping service. The time in the time-stamp is also used to synchronize the time on the client.
   • Finally, the form is processed and the time-stamp (separated into its different parts), the client signature and the client certificate is included in fields that were hidden from the user.
4. The form is sent to the server by the web browser as an HTTP POST request.
5. The server processes the form (see section 6.4.1).
6. In response to the HTTP POST request, the server returns an order receipt. It is an HTML page containing a readable receipt message, the server�s signature, a time-stamp and the server�s certificate.
7. The server certificate and server signature are verified.
8. The time-stamp time is verified as being within specified boundaries, along with a verification of the time-stamping service signature.
9. The receipt message is shown to user by the browser.
10. Optionally, there is an acknowledgement sent to server to let it know that the receipt was received correctly.

Although the page originates from the server it contains JavaScript code to verify the server certificate, the server signature and the time-stamp. One might argue that this is insecure, and that for example the PKI should be used to verify the data. However, in this project it would give the PKI implementers a lot of responsibility for data verification, and the user can be thought of as having enough trust in the web shop to also trust its JavaScript code to verify the receipt. Also, the user has the receipt stored for future reference if a dispute should arise. For a real world implementation on a large scale there should however, in our opinion, be a TTP that can verify the signature and time-stamp.

6.3..2  Solution

The implementation could be done in a number of different ways. For simplicity (we thought) JavaScript was chosen on the client side. Optionally, there could have been an applet present on the page that was called from JavaScript code. Another possibility would have been to use another scripting language, such as Visual Basic Script, but since none of us had any experience with it, it was not an option we chose.

6.3.3  Problems

The biggest problem with the client side implementation was that the JavaScript language knowledge was quite rudimentary. Therefore the implementation included a lot of trial-and-error, searching for documentation and examples and trying out different alternatives before discovering how it should really be done.

If an applet is used for providing the functionality needed (called from JavaScript code) it imposes some restrictions since an applet is not allowed to connect to any other server than the one it was downloaded from. This could be avoided if the applet is signed and the user approves of the connection.

Since JCE code has been used to implement the hash function and signature verification on the client machine it has to be installed on the client. This can be avoided if it is included in an applet, in which case it loads from server, but that would on the other hand require that the browser can run Java 2 applets (e.g. using a plug-in).

6.4  Server

The server is basically any server capable of running JavaServlets, or in our case JHTML pages that are compiled into JavaServlets. Since we have used it before the Java Web Server was a natural choice. Unfortunately it only very recently came in a beta version supporting Java 2. Also, the SSL server certificate had to be encoded in a specific way that created some problems.

6.4.1  Design

The server side implementation is designed as follows

1. The client request for the order page is received and an SSL connection is set up transparently by the server and client browser. The order page is sent to the client browser.
2. The user fills out the form and the client processes it (see section 6.3.1).
3. An HTTP POST request is received from the client, containing the order, which consists of the filled out form, the client signature, the time-stamp and the client certificate.
4. The order form is verified to ensure that the user fills out the order correctly.
5. The client certificate and client signature is verified.
6. The time-stamp time is verified as being within specified boundaries, along with a verification of the time-stamping service signature.
7. A receipt message is created on the order made.
8. The receipt is signed.
9. A hash is created on the signed receipt, using SHA-1.
10. The hash is sent to the time-stamp service as an HTTP POST request.
11. The response is the time-stamp. It contains the original hash, the time and the signature of the time-stamping service. The time in the time-stamp is also used to synchronize the time on the server.
12. The receipt is sent to the client as a response to the HTTP POST request. The receipt includes the receipt message, the server signature, the time-stamp and the server certificate.
13. The client processes the receipt and shows it to the user (see section 6.3.1).
14. Optionally, an acknowledgement is received from client to indicate that the receipt has been received and understood.

6.4.2  Solution

The server side is implemented in JHTML code (HTML with Java code withintags). The JHTML pages are compiled by the web server into JavaServlets and then executed. They could also have been implemented as JavaServlets directly, but would require a bit more coding for the HTML parts of the responses.

Another option would have been to use server side JavaScript or other scripting language, but it was not chosen due to limited knowledge. Also, JHTML had been used before and was proved to be a very nice tool for creating server side code without making the pages too complex.

6.4.3  Problems

The major problem with the Java Web Server was that it included the JRE1.1.6 (run-time version of JDK1.1.6) and in order to use JCE we needed JRE1.2. The beta version that supports Java 2 came out only a few days ago. The format of the HTTP POST data was also a problem before we knew how to manipulate the data on the client side.

6.5  Things left to do

The implementation is quite a long way from finished, and it has not been possible to test it. If necessary, we will complete the implementation as best we can. Most obstacles should be possible to overcome, the only question is how long it will take.

7. Conclusion

As help for the evaluation of our solution, we will review the questions stated in the beginning of the text above and see how we have answered them:

1. What is a transaction? The data transferred from client (browser) to server has to be of a pre-defined format.

We have specified an order form, which the client must use to place an order. This makes it easy to automate the verification of the contents of an order. Also, the format used in the transfers, i.e. the data followed by a signature followed by a time-stamp etc, has been specified.

2. Against what do we want to protect ourselves? Which threats are likely to occur? Which threats is the system susceptible to?

The introduction of non-repudiation in the transaction scheme protects against one of the parties trying to get out of a deal that has been made. However, it does not protect against outside parties trying to sabotage the transaction, get information about one or both of the parties, get access to their private keys etc. Indeed, the non-repudiation scheme might even make the transaction more sensitive to such threats � the more complex a system is, the harder it is to get an overview of it, and the more probable it is that one introduces flaws somewhere. Not saying that this is true in all cases, let us state that security problems may arise in our system.

A problem with time-stamping is that time becomes a security issue. The system clock is used in the verification of evidences and must thus be protected from tampering. This problem has not been addressed in the design, other than the assumption that the web shop server is well protected in general.

Another problem with time itself is the synchronization between the parties. If the clocks drift sufficiently, the time window may be too small and the availability of the system is threatened.

In addition to this, the storage of messages is also a sensitive area. This holds especially for the PKI, of course, but the parties themselves also need to protect their data. Otherwise, the other party might tamper with old messages in order to be able to repudiate them. There is also a considerable amount of data to store � especially for the web shop � something that may cause trouble after a while.

3. At what stage in the transaction should the SSL connection be established?

We decided to start the SSL connection as late as possible in the transaction process � at the point when the client decides to actually make a purchase. The reason for this was to avoid scaring customers away before they have seen the goods for sale. A secure connection is a service for the customers as well as it is good for the web shop itself, and should be used as such. The average Internet shopper wants security, but not any trouble obtaining it�

4. Which data should be time-stamped in order for the non-repudiation to be secure?

Since we want non-repudiation both for the client and for the web shop, both the order and the receipt must be time-stamped. Exactly what data is time-stamped � if it is the order or the receipt itself, or a hash of it � does not matter for the non-repudiation itself. However, the PKI should not get any information about the nature of the transactions. Even though the PKI itself is trusted, there is no need for it to know about the transaction, and there is always the risk of an evil intruder breaking into the PKI. Also, time-stamping a hash of a message is faster and the resulting data takes up less place, both on servers and travelling on the Internet.

5. Is there any other way than to use time-stamping to introduce non-repudiation into the system?

As stated in the section about non-repudiation above, there are numerous ways to achieve non-repudiation. The method we have chosen is the most common and the most immediate choice. The main advantage is that the time of a transaction becomes a factor in determining the validity of an order/receipt, which means that no one can resend an old order. Using the time as a factor is also a disadvantage because of the synchronization needed between the PKI, the client and the web shop.

6. Which data should be stored during and after the transaction, and by whom?

This question is answered in figure 10 above. After a transaction, these data objects are stored by the respective parties:

• The PKI has the time-stamped hashes of the order and the receipt
• The web shop has the time-stamped and signed order (and a copy of the time-stamped and signed receipt)
• The client has the time-stamped and signed receipt (and a copy of the time-stamped and signed order)
7. Which cryptographic algorithms should be used? How long should the keys be?
• For the SSL connection, digital certificates are used with RSA asymmetric keys of 512 bits
• For signing documents, digital certificates with RSA asymmetric 512 bit keys are used

The key length should be considered adequate, but could be longer. Unfortunately, the PKI only supplied keys of this length.

8. Which hash functions should be used? Do we need keyed hash functions? If so, how long should the keys be?

We decided to use unkeyed hash functions. Of course, it is important that they are one-way and collision-free, but that is a satisfactory level of security.

9. How should keys be distributed? Do we need to exchange keys during the transaction, or could it be done off-line?

We decided not to bother about key distribution protocols, but to assume that all keys and protocols necessary for our transaction are distributed off-line before the transactions take place. This is basically what happens in real life too, so it is not too big a simplification.

The client and server do exchange signature certificates on-line. However, there is no security problem in showing your public key to an adversary, and this certificate exchange is performed during the SSL connection.

10. How will the browser and server synchronize their time with the TSS?

This is an interesting question, and crucial to the functionality of our system. Since time is used for non-repudiation, all system clocks must be synchronized or the whole scheme will fail.

We have decided to let the web shop connect to the PKI once every hour and get the correct time. The time should be signed by the PKI, or someone could impersonate the PKI and give the web shop an incorrect time.

The client is probably a "normal" person sitting at home shopping, so a regular connection to the PKI won�t do in that case. Instead, the client can take the time from the time-stamp of the order when it is returned from the PKI and set its clock depending on that time. The time that it takes to apply and verify the signature on the time-stamp, as well as an estimated time for the transmission of the data from the PKI to the client, must be added to the time-stamp time before setting the system clock.

A related question is the width of the time window that the server and client will allow the time-stamps to be considered valid. We think somewhere between 30 seconds and two minutes might be appropriate � if the answer takes longer than that to arrive, most people will either have closed their browser or tried transmitting the order again. Also, in that way, the time doesn�t have to be very precisely synchronized, but can vary slightly between the two parties.

11. In case disputes arise, how should they be resolved?

This question has been addressed in section 5.1 about design analysis above.

12. What technology should be used to implement our solution?

This question has been addressed in section 6 about implementation above.

7.1  Other remarks

Finally, some assorted thoughts on some other aspects of the system�

There is no non-repudiation of submission in this scheme unless you consider the receipt as a proof that the order was submitted. However, this is not enough, because the web shop might very well ignore the order and never make a receipt. This is indeed a flaw in the design, but one that hopefully can be eliminated by asking the ISP of the client for some proof that the order was submitted. Another solution to the "reluctant recipient problem" is to use a delivery agent, a TTP that assures that the message is indeed delivered [2].

Problems might arise if the receipt takes too long to produce for some reason. The client, waiting for a receipt that never arrives, might retransmit the order, or even fill in a new order with the same contents. To avoid some of this, some check of the contents of the order should be made at the server side so that duplicates of an order are filtered away. A more advanced solution, but also more powerful, would be to introduce non-repudiation of receipt of the receipt itself, having the client transmit a confirmation that the receipt was indeed received (and on and on for eternity�). In this way, the web shop would know that the receipt for the first order wasn�t received and assume that the second order was a duplicate.

8. What did we learn?

We have spent many days and nights growing gray hairs over this project, but what it all comes down to in the end is what we have learned from it.

The most important lesson was to see how hard it can be to do things in practice that seem simple enough in theory. We never imagined from the beginning that the implementation would cause us so much trouble.

Naturally, we have learned a great deal about non-repudiation and time-stamping and what they can be used for. It was interesting to learn that time-stamping can be used for other security problems than non-repudiation.

JCE, the cryptography extension to Java, is a nice and straightforward API to use. We have also found some literature � notably Mark�s book and Warwick Ford�s Computer Communications Security � that was invaluable to us during the writing of this report, as well as the design of the non-repudiation scheme itself.

So, were the gray hairs worth the trouble? Probably, but now it�s time to go to the hairdresser.

9. References

We have not written out our references very clear in this paper. However, the following texts are the ones that we have used in order to learn about the areas of non-repudiation and time-stamping:

Is non

What does repudiation mean in security?

What is most commonly used for the goal of non

How can we protect from repudiation?