Efficient long-term validation of digital signatures

Efficient long-term validation of digital signatures Arne Ansper1 , Ahto Buldas1 , Meelis Roos2 , and Jan Willemson2 1 2

Cybernetica; Akadeemia 21, Tallinn, Estonia Cybernetica, Tartu Lab; Lai 36, Tartu, Estonia {arne,ahtbu,mroos,jan}@cyber.ee

Abstract. Digitally signed documents (e.g. contracts) would quickly lose their validity if the signing keys were revoked or the signature scheme was broken. The conventional validation techniques have been designed just for ephemeral use of signatures and are impractical for long-term validation. We present a new scheme that: (1) provides fast revocation while giving no extra power to on-line service providers; (2) supports long-term validation; (3) is lightweight and scalable.

1

Introduction

Bob lends Alice $100. Alice signs a promissory note stating that she owes Bob $100. It is in Bob’s interest that Alice’s digital signature is sufficient to convince a judge that she really owes Bob the money. A dispute in court, however, may take place long after the promissory note was signed. Alice’s public key certificate may already be revoked. Therefore, it is necessary to ensure that electronic documents retain provable authenticity long after their creation. The evidentiary function is one of the essential properties of handwritten signatures and thereby it may seem natural to assume that digital signatures have this property as well. However, no human being is able to compute digital signatures by heart and it is also hard (if not impossible), with today’s technology, to create a signature device which (from the signer’s point of view) is absolutely safe to use. On the one hand, it seems unfair to make the owner of a signature device (Alice) liable for everything ever signed with that device. On the other hand, if the burden of proof is completely on the side of the interested party (Bob), no one would trust digital signatures. The best we can do today is to minimize the technological risks and to define some reasonable (as fair as possible) rules for solving disputes on digital signatures, rules that all parties involved in a dispute are aware of. Among many other things, these rules must define what kind of digital information is considered to be admissible evidence in a court of law. Secure signature devices, fair rules of liability, and up-to-date public key information are the basic problems to be solved before we can seriously speak about the evidentiary function of digital signatures. In this paper, we address 0

All authors were supported by the Estonian SF, grant no. 4150

the last issue, i.e. the problem of efficient distribution and storage of public key information for long-term use. The secure signature devices and the liability problems are not discussed, though, we do not claim they are unimportant or easy to solve. The first solution in the area of public-key distribution was proposed as early as in 1976. In a pioneering paper [6], the fathers of public-key cryptography – Diffie and Hellman – proposed a modified (on-line) telephone book listing public keys instead of telephone numbers. However, this idea was despised two years later by Loren Kohnfelder [11], the father of public key certificates, due to concern that managing such a telephone book would cause a communication bottleneck. The idea of individually signed certificates seemed far more attractive because the public networks were far from their today’s overall availability. Recently Gassko, Gemmell and MacKenzie [8] took a step towards reviving the modified telephone-book idea proposed by Diffie and Hellman. They showed that for long-term validation it is more efficient to manage public key databases rather than to use individually signed certificates. In this paper, we will take another step by showing that (using modern cryptographic techniques) we can improve both the efficiency and reliability of on-line validation techniques. We introduce a new notary service which confirms the validity of the certificate at the time when the relevant digital signature was created. Instead of indicating the specific time, the notary confirmation (signed by the notary) provides a direct (one-way) link between the certificate and the signature. In order to avoid the need to use computationally expensive digital signatures extensively, the notary uses Merkle authentication trees [12, 13] to compress answers to questions which clients have submitted during each minute (or some other unit) of time. After each minute, the notary signs the root of the tree. This trick (used already in time-stamping [9, 3] and certification [8]) significantly reduces the number of signature creations. We also propose methods how to reduce the role of Trusted Third Parties in long-term validation and thereby improve the reliability of these services. In Section 2, we describe our model of signature validation scheme including the list of involved parties. We also describe the main goals of this paper. In Section 3, we give a brief overview of the basic principles of public key validation techniques and discuss the main advantages and drawbacks of the on-line validation techniques. In Section 4, we outline a new on-line validation protocol that supports both fast revocation and long-term validation. In Section 5, we discuss how to increase the reliability of on-line validation schemes and present a new scheme with lower trust assumptions.

2

Statement of the problem

In this section, we give a brief overview of the problems we try to solve and, in order to avoid misunderstandings, also emphasize some problems we are not trying to address in this paper. There are five parties involved in our model of signature validation:

– Certification Authority (CA) issues public key certificates that bind public keys to identities of their owners. – Signer (Alice, A) is a person who, after obtaining a public-key certificate from the CA, creates a digital signature. – Prover (Bob, B) or Interested party is a party who receives a digital signature from the signer and who is interested in preserving the evidentiary function of this signature. – Confirmer (or Notary, N ) represents a service for obtaining a confirmation that the certificate was valid at the moment the signature was created. – Verifier (or Judge) is a party who needs to be convinced (using the signature, the certificate, and the confirmation) about the validity of the signature (possibly, long after the signature was created).  CA



   Validity information - Confirmer    6 Signature,

Certificate

Confirmation Certificate

? Signer



Signature 

Signature,

 ? Certificate,  - Prover - Verifier Confirmation   

 

Fig. 1. Our model of signature validation.

We consider that the signature device used by the signer (Alice) is never absolutely secure and may leak the key or be stolen by an adversary. Thereby, the system we use must allow the signer to revoke the certificate immediately when the key or device is suspected of being compromised. Moreover, the Public Key Infrastructure we will develop should guarantee that the revocation notice is (timely) distributed (or made available) to all potential verifiers. We assume that a signature is considered to be valid if it is proved to be created before the corresponding certificate was revoked. That is what we call long-term validation in this paper. We neither discuss how to develop secure signature devices nor give any hints for the signer how to notice the compromise of these devices. At the same time, we agree that both of these are important practical issues. The problems we are going to address are 1) how to revoke the certificate timely if its compromise has been noticed or even suspected; and 2) how to prove that the certificate was not revoked. We do not claim that answering to these questions is sufficient to support (or even come close to) non-repudiation – the ability to prove (in undeniable manner) to a third party (e.g. a judge) that a document which was received via a public

network was, in fact, written and sent by the claimed originator. This property is never assumed to hold even in the case of “true” signatures. The more specific questions we address in this paper are 1) efficient measures for obtaining and preserving the proofs of validity (compactness of proofs, etc.); 2) computational complexity of obtaining the proofs which has a considerable influence on the prime cost of the validation service; 3) reliability of the service.

3 3.1

Existing solutions and their shortcomings Traditional off-line PKI solutions

use public directory (that plays the role of the Confirmer) to store the public key information. The directory is updated by the CA in a regular basis (say, daily). The content of the directory is protected with the CA’s signature and also with a time stamp in order to guarantee the freshness of the content. The Prover downloads the most recent data from the directory and uses this data later as a part of the validity proof. The verifier checks that the signer’s public key certificate is not expired and is not included in the list of revoked certificates. Note that it is necessary to check whether the signature itself was formed at the time the public key information was considered as valid. Therefore, also the signature must be provided with a time stamp in order to prevent back-dating attacks. The main advantage of this approach is that the Confirmer is a passive intermediary that has no power to modify the validity information. Therefore, only the CA must be assumed to be trusted. The main shortcoming of this approach, considering the long-term validation, is that if the private key is suspected of being compromised Alice is unable to revoke her certificate immediately, because nobody would know about the revocation until the next update of the directory is issued. On the one hand, it is unfair (from the Alice’s point) to consider as valid all the signatures given before the next update. Alice should not be liable for events it has no control of. On the other hand, if they are considered as invalid, it would be dangerous (for Bob) to accept any signature before the next update is issued. Another shortcoming is that if the number of certificates grows, the size of a confirmation (as a linear function of the number of certificates issued by the CA) may become impractically large. 3.2

On-line methods

use an intermediary that, having received a request containing the certificate, replies with a validity confirmation. The integrity and content of the confirmation is protected with the signature of the Confirmer. As in traditional solutions,

the confirmation comprises the date of validity. Generally, a on-line validation protocol runs as follows: 1. A → B: CertA , SigA {X} 2. B → N : CertA 3. N → B: Valid(CertA ), [t0 , t1 ], SigN {StatusA } | {z }

(1)

StatusA

where t0 and t1 denote the bounds of the validity period of the confirmation (not the certificate), and Valid(·) denotes the validity statement. For example, the status of the certificate may be confirmed as valid, revoked, not revoked, suspended, etc. Obviously, the validity statement should directly point to the certificate it confirms. The On-line Certificate Status Protocol (OCSP) [14] developed by the PKIX working group is a typical example of an on-line validation protocol. The short-lived certificate approach [7] is almost equivalent. For the persistent use of the validity confirmation we need a time stamp t on SigA {X}, issued by a trusted Time-Stamping Authority (TSA) [2, 9, 3, 5], such that t0 ≤ t ≤ t1 . Therefore, provided that the public keys of CA, N and TSA are obtained authentically, the verifier should check that: – – – – – –

SigA {X} is properly verifiable using the public key written in CertA ; CertA is signed by the CA; StatusA confirms the validity of CertA at [t0 , t1 ]; StatusA is signed by N; the time stamp confirms that SigA {X} was created at t, where t0 ≤ t ≤ t1 ; the time stamp is signed by the TSA.

The main advantage of this approach over the off-line approach is that the validity information is always up-to-date. We are able to overcome the inconvenient trade-off between the latency of revocation and the service time, because revocation messages can be sent directly to the Confirmer. An example of using secure revocation notes is given by Rivest [15]. However, there are also several shortcomings in this approach. First, the Confirmer must extensively use a digital signature scheme, which is time-consuming and may require special hardware accelerators when the number of requests becomes large. Second, we introduce two additional trusted parties: (1) the Confirmer, and (2) the TSA. Both parties are, in principle, able (without cooperation) to cheat clients. 3.3

Notary protocols

eliminate the need for a trusted TSA and, therefore, reduce the number of additional third parties to one. Instead of using time stamps, notary protocols give a direct (one-way) link between the signature to be confirmed and the confirmation. Notary protocols are similar to the conventional validation protocols.

The main difference is that the notary confirmation comprises the signature the confirmation is about. The protocol itself goes through the following steps: 1. A → B: CertA , SigA {X} 2. B → N : CertA , SigA {X} 3. N → B: Valid(CertA ), SigA {X}, SigN {StatusA } | {z }

(2)

StatusA

Note that the Notary does not check the validity of users’ signatures. A party who verifies the signature would check for the correctness anyway. Thereby, the signature verification by the Notary would give no additional assurance. This fact was noticed by Roos [16]. Provided that the public keys of CA and N are obtained authentically, the verifier should check that: – – – –

SigA {X} is properly verifiable using the public key written in CertA ; CertA is signed by the CA; StatusA confirms the validity of CertA and comprises the signature SigA {X}; StatusA is signed by N;

Time stamps are unnecessary because StatusA directly points to the signature SigA {X} to be confirmed. Thereby, we have a proof that SigA {X} was created before N signed the confirmation. Most notary protocols proposed to date are computationally expensive. For example, in the Data Validation and Certification Service (DVCS) [1] (PKIX Working Group) the service provider validates users’ signatures and checks the full certification path from the certificate’s issuer to a trusted point. Thereby, the processing of requests requires large amount of computation. The notary protocol (2) described in this section is much less expensive because request processing does not require extensive computations. However, each request still needs a signed reply. Therefore, we still have the same efficiency concerns as in the case of OCSP. Our main goal is to develop a signature validation scheme capable of supporting (1) long-term validation, (2) scalability of services and (3) accountability (trust elimination). In the next sections, we discuss some hints that help us to achieve these goals.

4

A new efficient notary protocol

As noticed above, in conventional on-line validation protocols, the server must create one signature per request. Hence, it must be as powerful as all the signers altogether. This can constitute a serious computational bottleneck if the users community grows large. To avoid this problem, we could give one signature to several responses at a time. The server collects all requests obtained during some time interval (referred to as round ). It then prepares the set S of the corresponding response statements and organizes it as a certain data structure.

Instead of signing all the statements independently, the server signs only a short digest d = D(S) of the whole data structure. Note that it is impractical to sign a plain list of all requests because this list must be sent back to all clients, which may cause undesirable communication costs. Merkle authentication tree described in the next subsection turns out to be a suitable data structure for this purpose. 4.1

Merkle authentication trees

The Merkle authentication tree [12, 13] is one example of a suitable data structure. The Merkle authentication tree for a set S of data items is a labeled tree the leaves of which are labeled with the elements of S and each non-leaf of which is labeled with a hash of the labels of its child-vertices (Figure 2). The digest d = D(S) is defined to be equal to the label of the root vertex.

d = h(d1 kd2 )

s  I @ @ d2 = h(h3 kh4 ) h(h1 kh2 ) = d1 s @s ]  S

7 J  o   J

S    h1

h2

h3

h4

    Fig. 2. Merkle tree for S = {S1 , S2 , S3 , S4 }. Here hi = h(Si ) for i = 1...4.

Each element Si ∈ S can be provided with a succinct membership proof P (Si , S) of the statement Si ∈ S. Each proof is a formal expression of one variable x. For example (Figure 2), P (S2 , S)(x) := h(h(h1 , x), d2 ), where h denotes the hash function used. For verifying the statement Si ∈ S one needs to check the equation P (Si , S)(h(Si )) = d = D(S). The most important property of Merkle authentication trees is that the size of a proof is O(log | S |). 4.2

Notary protocol with Merkle trees

The notary server works in rounds. Suppose that the duration of these rounds is set to one minute. Instead of answering the requests immediately the server collects the requests submitted during the round. It then organizes the corresponding confirmations as a Merkle tree and signs the root hash of this tree. The protocol with Merkle tree runs as follows: 1. A → B: CertA , SigA {X} 2. B → N : CertA , SigA {X} 3. N → B: Valid(CertA ), SigA {X}, P (StatusA , S), SigN {D(S)} | {z } StatusA

(3)

Hence, a replay to a request is a triple (StatusA , P (StatusA , S), Sig{D(S)}). No matter how many requests we have, only one signature per round is required. Such an approach was first used in time-stamping [4, 3]. The verification procedure is almost the same as in Protocol (2), except that instead of the final signature verification the verifier – checks the equation P (StatusA , S)(h(StatusA )) = D(S); – checks that D(S) is signed by N. Note that this approach has sense only if the request processing itself is computationally much cheaper than signing. This is certainly the case for the PKIX time-stamping and OCSP protocols (though, they do not use this approach!), but is not true for DVCS because each request requires several signature verifications. 4.3

Efficiency calculations.

Let Th and Ts denote the time needed for hashing and for signing, respectively. Let Tp denote the time which is needed to find an answer to a request. In conventional on-line protocols (OCSP, TSP etc.), serving R requests requires R · (Tp + Ts ) time-units (Figure 3). In the hash-tree protocol (Figure 4), if there R · Tp Request1..R

R · Ts Sig{Status1 }, ..., Sig{StatusR }

Status1..R

-

Processing

-

Signing

-

Fig. 3. Computations of the Notary in the conventional protocol.

are R requests in one round, we need R · Tp time units to find the corresponding answers, R · Th time units to compute the hash-tree and find the digest d and proofs P (Statusi , S), and finally, Ts time units to sign the digest D(S). Assuming R · Tp Request1

R · Th

-

Processing

Ts D(S)

Status1

-

Hash-tree

...

Sig{D(S)} Signing P (Status1 , S)

-

computation RequestR

...

StatusR

-

Processing

-

P (StatusR , S)

-

Fig. 4. Computations of the Notary in the protocol with hash-tree.

-

that hashing is K times faster than signing (Ts = K · Th ) and request processing is P times faster than signing (Ts = P · Tp ), we get that the hash-tree scheme is λ=

R · Tp + R · Ts = R · Tp + R · Th + Ts

1 P

1 + P1 1 +K +

1 R

(4)

times faster. If the processing is much faster than signing (i.e. Tp  Ts ), we have that λ ≈ KR/(K + R). In OCSP, TSP and the notary protocol, this is indeed the case. Chosen values of λ in that case are shown in Figure 5. For example, if K = 10, 000 [8] and R = 1000, we get that our scheme is nine hundred times faster and if R = 100, it is still about one hundred times faster (Fig.5). For example, in OpenSSL (ver 0.94) library 1024-bit RSA with private

λ K K K K K

=1 = 10 = 100 = 1, 000 = 10, 000

R = 1 R = 10 R = 100 R = 1, 000 R = 10, 000 0.5 0.91 0.99 ≈1 ≈1 0.91 5.0 9.1 9.9 ≈10 0.99 9.1 50 91 99 ≈1 9.9 91 500 910 ≈1 ≈10 99 910 5000

Fig. 5. Chosen values of λ, provided that Tp  Ts .

exponent is about 3300 times slower than the hash function SHA-1 with a single 512-bit input block. We see (Figure 5) that the main advantage of our scheme – lower computational cost – is obvious when the number of requests per round becomes large. Therefore, using longer rounds would lower the prime costs of validation services. However, duration of rounds should not exceed the limits of a reasonable service delay. 4.4

Practical remark: signatures with hash chains.

Regardless of the fact that the notary protocol (3) with Merkle trees may increase the efficiency of numerous existing on-line protocols (OCSP, TSP etc.), the standards describing these protocols would be changed in order to use this advantage in practice. A way to overcome such a concern is to define new Object Identifiers (OID) for signatures with hash chains. Indeed, in the protocol (3) the proof P (StatusA , S) and the “ordinary” signature SigN {D(S)} may be viewed as a new type of signature on the message StatusA , i.e. Sig0N (StatusA ) := (P (StatusA , S), SigN {D(S)}).

(5)

If these new signature schemes are supported by the cryptographic libraries, the protocols (2) and (3) are identical from the software engineer’s point of view.

4.5

Notary protocols in multi-level PKI.

Notary protocols (3) with hash-trees and also the signatures with hash-chains (5) allow using on-line validation in the hierarchical multi-level Public Key Infrastructures. The signatures of a Notary service provider (N ) on the validity ¯ ). Such a hierarconfirmations may be confirmed by a higher level Notary (N chical validation scheme allows us to reduce the question of the validity of a certificate to the question of the reliability of a single top-level notary server (“supervised” by a top-level CA). The confirmation protocol runs as follows: 1. A → B: CertA , SigA {X} 2. B → N : CertA , SigA {X} 3. N finds: Valid(CertA ), SigA {X} | {z } StatusA

¯ : CertN , SigN {StatusA } 4. N → N ¯ → N : Valid(CertN ), SigA {StatusA }, SigN¯ {StatusN } 5. N | {z }

(6)

StatusN

6. N → B: StatusA , SigN {StatusA } StatusN , SigN¯ {StatusN }

Note that using ordinary signature schemes in this protocol would create a communication bottleneck on the top of the hierarchy. The top-level notary server would need as much communication as the leaf-servers altogether. Using hashchain-signatures (5) in protocol (6) is crucial for preventing such a bottleneck. Indeed, no matter how many requests the notary N obtains from its clients during a round, only one signature is created and needs to be confirmed by ¯ . Note also that the total service delay in a hierarchithe higher-level notary N cal on-line validation scheme is equal to the sum of delays on a path from the leaf-CA to the top-CA. This fact should be taken into account when developing client-friendly on-line validation services.

5

Reliability issues.

As we mentioned above, one of the main advantages of the traditional (off-line) PKI is that it does not give any extra powers to on-line service providers. In online validation protocols, however, we can notice two kinds of reliability concerns: 1) Private key of the Confirmer is used in a device connected to a public network and is therefore a potential target of attacks by network hackers. 2) On-line Confirmers are able to abuse their power to declare a certificate as valid, even if they know it is not. Though, Confirmers can be made accountable for their actions there may exist no effective ways to detect or prove their misbehavior. On the one hand, we need fast on-line revocation/validation protocols in order to lower the risk of possible abuses of a stolen signature key. On the other

hand, on-line services are less secure because of the abovementioned concerns of reliability. If the value of a digitally signed document is relatively small, a confirmation signed by an on-line service provider may be considered as a sufficient proof. In this case, on-line validation service is a tool that helps to make fast decisions less riskier for the interested party. However, if the value of a signed document is high, for some cases only the CA itself may be reliable enough for confirming the validity of a certificate. But, if the CA updates the validity information once a day (which is a typical practice) the interested party would wait (in the worst case) the whole day before it becomes safe for him/her to accept the signature. Therefore, it seems we have a fundamental trade-off between reliability and service time. In the following, we discuss several techniques how to increase the reliability of on-line validation services. 5.1

A protocol with short-lived certificates.

Attacks where the on-line Confirmer (Notary) declares revoked certificates as valid are easily avoidable if the certificates issued by the CA have a short validity period (say one day). Using hash-tree signatures (5) it is relatively easy for the CA to re-issue all the certificates daily [8] and to send these certificates to the Notary. The Notary removes a certificate from its database (of valid certificates) once it has received a suitable revocation note. A verifier of the notary confirmation must check that the certificate confirmed was “fresh” at the moment of confirmation. The message flow in such a protocol would be as follows: (daily) CA → N : (IDA , PKA , date), SigCA {IDA , PKA , date} | {z } CertA (date)

1. 2. 3.

A → B: B → N: N → B:

SigA {X} IDA , SigA {X} Valid(CertA (date)), SigA {X}, SigN {StatusA } | {z }

(7)

StatusA

Suppose that each morning (say 8 am) the CA issues for each client A a new certificate CertA (date) which is valid only for a day (denoted as date). The certificate contains the identity IDA and the public key PKA of A. In order to obtain a confirmation for a message SigA {X} signed by A, the interested party B sends this signature together with the identity IDA of A to the Confirmer N . If the certificate of A is in the database of valid certificates, the Confirmer signs a confirmation and sends it back to B. In this protocol, we must assume that the signature SigA {X} is also provided with a reliable time stamp t issued by a trusted Time-Stamping Authority (TSA). Each verifier of the signature must always check that the time stamp t belongs to date (i.e. was obtained when date was current). Provided that the public keys of the CA, N and the TSA were authentically obtained, the verifier should check that

– – – – – –

SigA {X} is properly verifiable using the public key written in CertA (date); CertA (date) is signed by the CA; StatusA confirms the validity of CertA (date) and comprises SigA {X}; StatusA is signed by N ; the time stamp confirms that SigA {X} was created at t, where t ∈ date; the time stamp is signed by the TSA.

In such a scheme, the Notary is able to revoke certificates but is unable to declare a certificate as valid if actually the certificate was revoked a day before (or earlier). The most harmful attack the Notary is able to perform is being ignorant to the revocation notes sent by clients. However, using several Notary servers reduces the probability of even this attack. As we mentioned above, a trusted Time-Stamping Authority is necessary for reliable validity proofs because incorrect time stamps may affect the results of validation. Time-stamping (as the Notary) is an on-line service and suffers thereby from the reliability concerns mentioned at the beginning of this section. Therefore, any advantage of protocol (7) over the previous protocols may seem questionable. In the next paragraph we present a better (though, more complex) solution which does not use trusted on-line parties. 5.2

A protocol with off-line time stamps.

In order to overcome the need for a trusted on-line Time-Stamping Authority we may use a protocol where the CA itself issues time stamps once a day. Each certificate CertA,i (issued by the CA for the i-th day) comprises a certain nonce value d−1 which is a digest D(Σi−1 ) of the set Σi−1 of all the signatures submitted during the previous day. This digest is computed using the Merkle authentication tree. If A wants to sign a message X she adds her certificate to the message to be signed. If the i-th day is over, the Notary sends the CA the digest di = D(Σi ) of the set of all signatures submitted during the day. The CA then issues a time stamp SigCA {datei , di } and sends it back to the Notary. The protocol runs as follows: (dayi )

CA → N : (IDA , PKA , datei , di−1 ), SigCA {bindingA,i } | {z } bindingA,i

1. 2. 3.

A → B: B → N: N → B:

|

{z

CertA,i

σA = SigA {X, CertA,i } IDA , σA Valid(CertA,i ), σA , SigN {StatusA } | {z }

} (8)

StatusA

N adds σA into Σi . (dayi+1 ) N → CA: di := D(Σi ) CA → N : SigCA {datei , di }

In this protocol we do not need additional time-stamping services because the one-way links between the time-stamps and the signatures give an undeniable

proof that the A’s signature was in fact created at the i-th day. Indeed, we have a one-way relationship di−1 −→ CertA,i −→ SigA {X, CertA,i } −→ di . Moreover, if we do not want to take risk of accepting the signatures using online notary confirmations we can always wait till the next morning and obtain a one-way link SigA {X} −→ di −→ CertA,i+1 which proves the validity of the signature entirely independent of any on-line validation services. Thus, a verifier who has authentic copies of the public keys of the CA and N must check that – – – – – –

σA = SigA {X, CertA,i } is properly verifiable with PKA written in CertA,i ; CertA,i is signed by the CA; StatusA confirms the validity of CertA,i and comprises σA ; StatusA is signed by N ; the equation P (σA , Σi )(h(σA )) = di holds; SigCA {datei , di } is properly verifiable using the public key of the CA.

A verifier who does not trust N completely may also obtain the next certificate CertA,i+1 = SigCA (IDA , PKA , datei+1 , di ) and check that – CertA,i+1 comprises di and PKA , which confirms the validity of the signature independent of N because if A’s certificate is revoked during datei the CA does not issue CertA,i+1 .

6

Conclusions

We presented a long-term digital signature validation scheme that does not suffer from the main disadvantages often associated with on-line techniques. Our scheme supports fast revocation while giving no extra power to on-line validation services. Due to the efficient hash-chain-signatures our protocol is efficient and scalable. One advantage over the previous schemes is that our scheme does not require additional trusted parties.

References 1. Adams, Sylvester, Zolotarev, and Zuccherato. Data Validation and Certification Server Protocols. Technical report, PKIX Working Group, October 1999. 2. Carlisle Adams and Robert Zuccherato. Time stamp protocols. Technical report, PKIX Working Group, 1999. 3. Dave Bayer, Stuart Haber, and W. Scott Stornetta. Improving the efficiency and reliability of digital time-stamping. In Methods in Communication, Security, and Computer Science – Sequences’91, pages 329–334, 1992.

4. Josh Benaloh and Michael de Mare. Efficient broadcast time-stamping. Technical Report 1, Clarkson University Department of Mathematics and Computer Science, August 1991. 5. Ahto Buldas, Peeter Laud, Helger Lipmaa, and Jan Villemson. Time-stamping with binary linking schemes. In Advances in Cryptology – CRYPTO’98, volume 1462 of LNCS, pages 486–501, Santa Barbara, 1998. Springer-Verlag. 6. Whitfield Diffie and Martin Hellman. New directions in cryptography. IEEE Transactions on Information Theory, 22:644–654, 1976. 7. Barbara Fox and Brian LaMacchia. Online certificate status checking in financial transactions: the case for re-issuance. In Financial Cryptography – FC’99, volume 1648 of LNCS, pages 104–117, Anguilla, February 1999. 8. Irene Gassko, Peter S. Gemmell, and Philip MacKenzie. Efficient and fresh certification. In Public Key Cryptography – PKC’2000, volume 1751 of LNCS, pages 342–353, Melbourne, Australia, January 2000. Springer-Verlag. 9. Stuart Haber and W.Scott Stornetta. How to time-stamp a digital document. Journal of Cryptology, 3(2):99–111, 1991. 10. Paul C. Kocher. On certificate revocation and validation. In Financial Cryptography: FC’98, volume 1465 of LNCS, pages 172–177, Anguilla, February 1998. Springer-Verlag. 11. Loren M. Kohnfelder. Toward a practical public-key cryptosystem. 1978. 12. Ralph C. Merkle. Protocols for public key cryptosystems. In Proceedings of the 1980 IEEE Symposium on Security and Privacy, pages 122–134, 1980. 13. Ralph C. Merkle. A certified digital signature. In Advances in Cryptology – CRYPTO’89, volume 435 of LNCS, pages 218–238, Santa Barbara, 1989. SpringerVerlag. 14. Michael Myers, R. Ankney, A. Malpani, S. Galperin, and Carlisle Adams. RFC2560: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. June 1999. 15. Ronald Rivest. Can we eliminate certificate revocation lists? In Financial Cryptography: FC’98, volume 1465 of LNCS, pages 178–183, Anguilla, February 1998. Springer-Verlag. 16. Meelis Roos. Integrating time-stamping and notarization. MSc Thesis, Tartu University, http://home.cyber.ee/mroos/thesis/. May 1999.