Jump to content

Server-based signatures: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
No edit summary
No edit summary
Line 19: Line 19:


2. On-line/off-line Digital Signatures. First proposed in 1989 by Even, Goldreich and Micali <ref> {{Cite doi|10.1007/BF02254791}}</ref> <ref>{{Cite doi|10.1007/0-387-34805-0_24}} </ref> in order to speed up the signature creation procedure, which is usually much more time consuming than verification. In case of RSA it may be one thousand times slower than verification. On-line/off-line digital signatures are created in two phases. The first phase is performed off-line, possibly even before the message to be signed is known. The second (message-dependent) phase is performed on-line and is very fast and involves communication with a server. The main idea is that in the first (off-line) phase, the signer uses a conventional public-key digital signature scheme to sign a public key of the Lamport one-time signature scheme. In the second phase, a message is signed by using the Lamport signature scheme. Some later works
2. On-line/off-line Digital Signatures. First proposed in 1989 by Even, Goldreich and Micali <ref> {{Cite doi|10.1007/BF02254791}}</ref> <ref>{{Cite doi|10.1007/0-387-34805-0_24}} </ref> in order to speed up the signature creation procedure, which is usually much more time consuming than verification. In case of RSA it may be one thousand times slower than verification. On-line/off-line digital signatures are created in two phases. The first phase is performed off-line, possibly even before the message to be signed is known. The second (message-dependent) phase is performed on-line and is very fast and involves communication with a server. The main idea is that in the first (off-line) phase, the signer uses a conventional public-key digital signature scheme to sign a public key of the Lamport one-time signature scheme. In the second phase, a message is signed by using the Lamport signature scheme. Some later works
ShTa01 <ref>{{Cite doi|10.1007/3-540-44647-8_21}}</ref>,
<ref>{{Cite doi|10.1007/3-540-44647-8_21}}</ref>
YuTa07 <ref>{{Cite doi|10.1109/AINAW.2007.89}}</ref>
, YuTa07, YuTa08, Yu08,
<ref> {{Cite doi|10.1007/978-3-540-78440-1_7}}</ref>, Gira92, GiPS06, Joye08 have improved the efficiency of the original solution by Even et al.
YuTa08 <ref>{{Cite doi|10.1007/978-3-540-79263-5_19}}</ref>
<ref> {{Cite doi|10.1007/978-3-540-78440-1_7}}</ref>
GiPS06 <ref>{{Cite doi|10.1007/s00145-006-0224-0}}</ref>
Gira92 <ref>{{Cite doi|10.1007/3-540-46416-6_42}}</ref>
Joye08 <ref>{{Cite doi|10.1007/978-3-540-89641-8_7}}</ref>
have improved the efficiency of the original solution by Even et al.


3. Server-Supported Signatures (SSS). Proposed in 1996 by Asokan, Tsudik and Waidner <ref> {{Cite doi|10.1007/3-540-61770-1_32}}</ref> in order to delegate the use of time-consuming operations of asymmetric cryptography from clients (ordinary users) to a server. For ordinary users the use of asymmetric cryptography is limited to signature verification, i.e. there is no pre-computation phase like in the case of on-line/off-line signatures. The main motivation was the use of mobile phones for creating digital signatures, considering that mobile phones are too slow for creating ordinary public-key digital signatures, such as RSA. Clients use _hash chain_ authentication [Lamp81] to send their messages to a signature server in an authenticated way and the server then creates a digital signature by using an ordinary public-key digital signature scheme. In SSS, signature servers are not assumed to be Trusted Third Parties (TTPs) because the transcript of the hash chain authentication phase can be used for [[Non-repudiation|non repudiation]] purposes. In SSS, servers cannot create signatures in the name of their clients.
3. Server-Supported Signatures (SSS). Proposed in 1996 by Asokan, Tsudik and Waidner <ref> {{Cite doi|10.1007/3-540-61770-1_32}}</ref> in order to delegate the use of time-consuming operations of asymmetric cryptography from clients (ordinary users) to a server. For ordinary users the use of asymmetric cryptography is limited to signature verification, i.e. there is no pre-computation phase like in the case of on-line/off-line signatures. The main motivation was the use of mobile phones for creating digital signatures, considering that mobile phones are too slow for creating ordinary public-key digital signatures, such as RSA. Clients use _hash chain_ authentication [Lamp81] to send their messages to a signature server in an authenticated way and the server then creates a digital signature by using an ordinary public-key digital signature scheme. In SSS, signature servers are not assumed to be Trusted Third Parties (TTPs) because the transcript of the hash chain authentication phase can be used for [[Non-repudiation|non repudiation]] purposes. In SSS, servers cannot create signatures in the name of their clients.
Line 52: Line 57:
* [ShTa01] Shamir, A., Tauman, Y.: Improved online/offline signature schemes. In J. Kilian (Ed.): CRYPTO 2001, LNCS 2139, pp. 355–367. Springer Heidelberg (2001)
* [ShTa01] Shamir, A., Tauman, Y.: Improved online/offline signature schemes. In J. Kilian (Ed.): CRYPTO 2001, LNCS 2139, pp. 355–367. Springer Heidelberg (2001)


* [Yu08] Yu, P.: Direct online/offline digital signature schemes. PhD. Thesis. University of North Texas (2008)

* [YuTa08] Yu, P., Tate, S.R.: Online/offline signature schemes for devices with limited computing capabilities. In RSA Conference 2008, Cryptographers’ Track (CT-RSA), pp. 301–317 (2008)

* [YuTa07] Yu,P., Tate, S.R.: An online/offline signature scheme based on the strong RSA assumption. In AINAW'07, pp. 601--606 (2007)


= Patents =
= Patents =

Revision as of 13:18, 29 April 2013

Server-based Signatures

Server-based signatures are "'electronic signature'" solutions in which a publicly available server participates in the signature creation process. The conventional solutions based on public-key cryptography and public-key infrastructure assume that signers use their personal "'trusted computing bases'" for signing documents and signatures can be created off-line without any communication with servers. There are several motives why server-based signatures are preferable compared to off-line solutions, such as:

  • to reduce the computational cost of creating digital signatures of ordinary users;
  • to reduce possible misuses of cryptographic keys by ordinary users;
  • to have better control over the number of forged signatures in case of malicious abuses of signature keys.


Therefore, many different forms of server-based signatures exist:


1. Lamport One-Time Signatures. Proposed in in 1979 by Leslie Lamport [Lamp79]. Lamport one-time signatures are based on cryptographic one-way (hash) functions. For signing a message, the signer just sends a list of hash values (outputs of a hash function) to a publishing server and therefore the signature process is very fast, though the size of the signature is many times larger compared to ordinary public-key signature schemes.


2. On-line/off-line Digital Signatures. First proposed in 1989 by Even, Goldreich and Micali [1] [2] in order to speed up the signature creation procedure, which is usually much more time consuming than verification. In case of RSA it may be one thousand times slower than verification. On-line/off-line digital signatures are created in two phases. The first phase is performed off-line, possibly even before the message to be signed is known. The second (message-dependent) phase is performed on-line and is very fast and involves communication with a server. The main idea is that in the first (off-line) phase, the signer uses a conventional public-key digital signature scheme to sign a public key of the Lamport one-time signature scheme. In the second phase, a message is signed by using the Lamport signature scheme. Some later works [3] YuTa07 [4] YuTa08 [5] [6] GiPS06 [7] Gira92 [8] Joye08 [9] have improved the efficiency of the original solution by Even et al.

3. Server-Supported Signatures (SSS). Proposed in 1996 by Asokan, Tsudik and Waidner [10] in order to delegate the use of time-consuming operations of asymmetric cryptography from clients (ordinary users) to a server. For ordinary users the use of asymmetric cryptography is limited to signature verification, i.e. there is no pre-computation phase like in the case of on-line/off-line signatures. The main motivation was the use of mobile phones for creating digital signatures, considering that mobile phones are too slow for creating ordinary public-key digital signatures, such as RSA. Clients use _hash chain_ authentication [Lamp81] to send their messages to a signature server in an authenticated way and the server then creates a digital signature by using an ordinary public-key digital signature scheme. In SSS, signature servers are not assumed to be Trusted Third Parties (TTPs) because the transcript of the hash chain authentication phase can be used for non repudiation purposes. In SSS, servers cannot create signatures in the name of their clients.


4. Delegate Servers (DS). Proposed in 2002 by Perrin, Burns, Moreh and Olkin [PBMO02] in order to reduce the problems and costs related to individual private keys. In their solution, clients (ordinary users) delegate their private cryptographic operations to a Delegation Server (DS). Users authenticate to DS and request to sign messages on their behalf by using the server's own private key. The main motivation behind DS was that private keys are difficult for ordinary users to use and easy for attackers to abuse. Private keys are not memorable like passwords or derivable from persons like biometrics, and cannot be entered from keyboards like passwords. Private keys are mostly stored as files in computers or on smartcards, that may be stolen by attackers and abuse off-line. In 2003 Buldas and Saarepera proposed a two-level architecture of delegation servers that addresses the trust issue by replacing trust with threshold trust.

References

  1. ^ Attention: This template ({{cite doi}}) is deprecated. To cite the publication identified by doi:10.1007/BF02254791, please use {{cite journal}} (if it was published in a bona fide academic journal, otherwise {{cite report}} with |doi=10.1007/BF02254791 instead.
  2. ^ Attention: This template ({{cite doi}}) is deprecated. To cite the publication identified by doi:10.1007/0-387-34805-0_24, please use {{cite journal}} (if it was published in a bona fide academic journal, otherwise {{cite report}} with |doi=10.1007/0-387-34805-0_24 instead.
  3. ^ Attention: This template ({{cite doi}}) is deprecated. To cite the publication identified by doi:10.1007/3-540-44647-8_21, please use {{cite journal}} (if it was published in a bona fide academic journal, otherwise {{cite report}} with |doi=10.1007/3-540-44647-8_21 instead.
  4. ^ Attention: This template ({{cite doi}}) is deprecated. To cite the publication identified by doi:10.1109/AINAW.2007.89, please use {{cite journal}} (if it was published in a bona fide academic journal, otherwise {{cite report}} with |doi=10.1109/AINAW.2007.89 instead.
  5. ^ Attention: This template ({{cite doi}}) is deprecated. To cite the publication identified by doi:10.1007/978-3-540-79263-5_19, please use {{cite journal}} (if it was published in a bona fide academic journal, otherwise {{cite report}} with |doi=10.1007/978-3-540-79263-5_19 instead.
  6. ^ Attention: This template ({{cite doi}}) is deprecated. To cite the publication identified by doi:10.1007/978-3-540-78440-1_7, please use {{cite journal}} (if it was published in a bona fide academic journal, otherwise {{cite report}} with |doi=10.1007/978-3-540-78440-1_7 instead.
  7. ^ Attention: This template ({{cite doi}}) is deprecated. To cite the publication identified by doi:10.1007/s00145-006-0224-0, please use {{cite journal}} (if it was published in a bona fide academic journal, otherwise {{cite report}} with |doi=10.1007/s00145-006-0224-0 instead.
  8. ^ Attention: This template ({{cite doi}}) is deprecated. To cite the publication identified by doi:10.1007/3-540-46416-6_42, please use {{cite journal}} (if it was published in a bona fide academic journal, otherwise {{cite report}} with |doi=10.1007/3-540-46416-6_42 instead.
  9. ^ Attention: This template ({{cite doi}}) is deprecated. To cite the publication identified by doi:10.1007/978-3-540-89641-8_7, please use {{cite journal}} (if it was published in a bona fide academic journal, otherwise {{cite report}} with |doi=10.1007/978-3-540-89641-8_7 instead.
  10. ^ Attention: This template ({{cite doi}}) is deprecated. To cite the publication identified by doi:10.1007/3-540-61770-1_32, please use {{cite journal}} (if it was published in a bona fide academic journal, otherwise {{cite report}} with |doi=10.1007/3-540-61770-1_32 instead.
  • [AsTW96] Asokan, N., Tsudik, G., Waidner, M.: Server-supported signatures. J. Computer Security (1996) 5: 131--143.
  • [CRFG08] Catalano, D., Di Raimondo, M., Fiore, D., Gennaro, R.: Off-line/on-line signatures; theoretical aspects and experimental results. In Cramer, R. (Ed.) PKC 2008, LNCS 4939, pp. 101–120. Springer Heidelberg (2008)
  • [Gira92] Girault, M.: Self-certified signatures. In Davies, D.W. (Ed.): EUROCRYPT ’91, LNCS 547, pp. 490–497. Springer Heidelberg (1992)
  • [GiPS06] Girault, M., Poupard, G., Stern, J.: On the fly authentication and signature schemes based on groups of unknown order. J. Cryptology (2006) 19(4): 463–487.
  • [Joye08] Joye, M.: An efficient on-line/off-line signature scheme without random oracles. In Franklin, M.K., Hui, L.C.K., Wong, D.S. (Eds.): CANS 2008, LNCS 5339, pp. 98–107. Springer Heidelberg (2008)
  • [Lamp81] Lamport, L.: Password authentication with insecure communication. Comm. ACM (1981) 24(11): 770--772.
  • [ShTa01] Shamir, A., Tauman, Y.: Improved online/offline signature schemes. In J. Kilian (Ed.): CRYPTO 2001, LNCS 2139, pp. 355–367. Springer Heidelberg (2001)


Patents

  • [US5016274] US Patent #5,016,274. Micali et al. On-line/off-line digital signing. May, 1991.