Secure proxy signing device and method of use

[0002] 1. Field of the Invention

[0003] The present invention relates to secure proxy signing devices for forming and supplying digital signatures over a network on behalf of users so that private keys are never extant at user equipment which is not secure, and to methods of using, and systems employing, such devices.

[0004] 2. Description of the Related Art

[0005] Digital signatures are generally produced by encrypting a hash of a document with the private key of a public key/private key pair unique to the user (generated e.g. by RSA or El Gamal algorithms) to manifest the user's approval of the document. The term “document” is used throughout this application to indicate or include any digital data, program, or file or a plurality or combination thereof. A hash is produced by applying a secure hash function (such as SHA-1 or RIPEMD) to reduce such data to a bit string of a fixed predetermined length (e.g. 160 bits if SHA-1 is used). A person having both a document and an associated digital signature can verify these items by comparing the result of decrypting the digital signature using the public key of the user with the result of hashing the document using the secure hash function. Such verification depends on the assumption that the private key is secret and is only known or used by or on behalf of the user. Yet if a private key is stored or even temporarily extant at user equipment such as a personal computer connected to an insecure network such as the Internet, there is the risk that a malicious program could be planted in the PC which would extract keys and send them over the network to an unscrupulous person.

[0006] To avoid this risk, it has been proposed to form the digital signature in a user's smartcard placed in a smartcard reader associated with the user's equipment. The smartcard is a secure proxy signing device because it uses a private key which never leaves the card. However, a hash of the document to be signed has to be presented to the smartcard in order for the smartcard to form the digital signature. This need to present the document hash to the smartcard raises the risk, particularly in systems where there is an insecure link between the process in which the hash is generated and the smartcard, that a phony document hash could be presented to the smartcard by an impersonator for signature on behalf of a user.

[0007] For example, if the document hash is generated by a Java (a trademark of Sun Microsystems Inc.) applet running on user equipment under a browser, such an applet process cannot access local disks or local I/O. Therefore, the smartcard reader cannot be accessed directly from the applet process, and consequently, communication between the applet process and a background process communicating with the smartcard must take place by server echoing via the insecure network. Such communication would thereby be exposed to an eavesdropper monitoring the insecure network, and the smartcard would be vulnerable to being spoofed by presentation to it of a phony document hash, for example in a block replay attack where previous authentic communications to the smartcard, or portions thereof, are replayed.

[0008] Another approach to avoiding the risk of key extraction from insecure user equipment is described in U.S. Pat. No. 5,208,858 wherein the private keys of all users are stored and maintained at a server functioning as a proxy signing device. Therein, a hash of the approved document is sent from the user equipment to the server via the network. At the server, the received hash is encrypted with the user's private key available at the server to form a digital signature which is combined with the user's public key and further data to form a so-called certificate which is transmitted to the user equipment for checking. At the user equipment, the result of decrypting the signature with the user's public key is compared with the document hash which was sent. If the compared items are the same, the document and the signature-containing certificate may be sent directly from the user equipment to the desired recipients.

[0009] The method of U.S. Pat. No. 5,208,858 has the drawback of the need to send the digital signature back to the originator for checking and also that the server must be located in a highly secure place because the private keys are stored therein in the clear (or at least in a form from which they can be derived by the server). It should be noted that the consequences of a person of malevolent intent compromising the server and obtaining the stored private keys are catastrophic, potentially rendering unreliable all digital signatures made with the system at any time. Further, in this known method it appears that the server could be tricked by a block-replay attack or a man-in-the middle attack into signing a document which did not originate from the user on behalf of whom the signature is sought, or signing unauthorized duplicates of authentic documents.

[0010] It is a general object of the present invention to provide a secure proxy signing device, and a system and method for using such a device, to form digital signatures which are supplied over an insecure network, such as the Internet, which provides security measures directed against the possibility that the proxy signing device is presented by an impersonator of the user with an unauthentic document hash for signature via the network. It is a further object of the present invention that the security measures guard against block-replay and man-in-the-middle attacks.

[0011] Briefly, the aforementioned and other objects are satisfied by providing a proxy signing device for forming a digital signature of a document using a private key stored within the signing device and data items supplied to the signing device from which a hash of the document is derived and authenticated by means within the signing device. Said signing device further comprises means for encrypting the document hash with the private key to form the digital signature only if the document hash has been authenticated. The invention is further characterized in that said means for deriving and authenticating the document hash is configured for authenticating a derived document hash on a condition that first data derived at least in part from one of said data items is the same as second data equal to or derived from another of said data items.

[0012] More particularly, the proxy signing device comprises a random number generator, and the first data is derived from a combination of the derived document hash, a number stored in the proxy signing device which was previously generated by the random number generator and communicated to the signing device, and user identifying data stored in the signing device and only obtainable at the user equipment by interaction with a physically present user, such as a password or passphrase entered by the user or biometric data (hash of a fingerprint, voiceprint, retina scan, or face scan) measured or scanned from the physically present user.

[0013] By providing for authentication in the proxy signing device and by making one of the plural data items provided to the signing device depend on a random number previously generated by the signing device solely for use in conjunction with obtaining the current digital signature, high immunity is provided against the signing device being spoofed by a block replay of presentations of variations of previous communications with the signing device, or by a man-in-the-middle attack. Further, the use in the authentication process of user identifying data which could only have been obtained by interaction with a physically present user at the user equipment provides high immunity against impersonation of the user.

[0014] Also, in accordance with the present invention, user apparatus is provided for cooperating with a proxy signing device via a communication path including a network for forming a digital signature of a user to whom is assigned a private key/public key. The user apparatus comprises user interaction means for a user to indicate approval of a document, computation means configured for forming first and second data items to be provided to the signing device via the communication path, said first data item being derived from a hash of the approved document, and said second data item being derived from a combination including said hash of the approved document and a random number computed by the signing device. The apparatus is also characterized in that the user interaction means is further configured for obtaining user identifying information from the user (password or passphrase or biometric information such as fingerprint, voiceprint, retina scan, face scan) and in that the combination from which the second data item is derived further comprises user identifying data derived from the obtained user identifying information. Also, the second data item is derived from said combination by hashing together the items of said combination.

[0015] The present invention also comprises a method for forming and supplying a digital signature of a user of a document comprising generating a random number in a signing device, supplying the random number to user equipment, and forming in the user equipment a first data item derived from a hash of the document and a second data item derived from a combination including said hash of the document and said random number. The inventive method further comprises authenticating in the signing device a hash of the document derived from said first data item if data derived by the signing device from the combination including the derived hash of the approved document and a previously generated random number stored in the signing device equals data derived from said second data item, and if the derived document hash is authenticated, encrypting the derived document hash in the signing device with a private key of the user stored in the signing device and sending the digital signature from the signing device via the network to a recipient device. Another aspect of the inventive method is that user identifying data which is derived from user identifying information obtained from a user physically present at the user equipment forms part of the combination from which the second data is derived, and that the user identifying information is stored in the signing device and used by it in the authentication process.

[0016] Other objects, features and advantages of the present invention will become apparent upon perusal of the following detailed description when taken in conjunction with the appended drawing, wherein:

[0017] FIG. 1 is a schematic diagram of an exemplary system in accordance with the present invention for utilizing a smartcard for digitally signing a document; and

[0018] FIG. 2 is a data flow chart which indicates in three separate columns the method steps performed by different portions of the system of FIG. 2.

[0019] It should be understood that while the present invention is discussed hereinafter in terms of an exemplary system and method for producing digitally signed documents by users over the Internet using a smartcard as a secure proxy signing device for an individual user, the principles of the present invention are equally applicable to use of other proxy signing devices, such as proxy signing servers for producing digital signatures on behalf of a plurality of users, and to the production of digital signatures of a variety of data, programs, or files, or other “documents”, whether originated, modified or merely reviewed by users. In any event, the digital signature may be thought of as manifesting an approval by the user of a document. The principles of the invention are also applicable to various systems and methods requiring encryption in a proxy device in which one or more private keys are maintained.

[0020] In the system described herein, a private key/public key pair, ID (which may be the initials or name of the user, providing they are unique) and user identifying data U consisting of a password, passphrase or a hash thereof, or data derived from biometric information (fingerprint, voiceprint, retina scan, or face scan), such as by hashing, are associated with each user. The public/private key pair for each user is preferably RSA, although these key pairs may be implemented pursuant to any public key cryptosystem including El Gamal and those based on elliptic curve cryptography. The encryption/decryption algorithms employed in such systems are referred to as asymmetric, because different keys are employed for encryption and decryption.

[0021] A passphrase consists of a fanciful series of words. It is very difficult to guess passphrases as opposed to passwords as there are many possible phrases. For example, a particularly good passphrase may concatenate two phrases which are in different languages. Guessing such a passphrase would be extremely difficult using normally available computer power. Similarly, biometric information is quite unique and immune to a guessing attack.

[0022] Referring first to FIG. 1, the exemplary system 10 in accordance with the present invention comprises a plurality of computer stations, terminals or other portable or desktop user computing and/or communication equipment, of which one user equipment 12 is illustrated, which are interconnected to or capable of communicating with a server 14 via a network 16. Server 14 is preferably a web server and network 16 may be the Internet or an intranet supporting TCP/IP. User equipment 12 has user interaction 122 such as a mouse and keyboard for receiving input from a user 20 or provides by biometric information (fingerprint, voiceprint, retina scan, or face scan) by measurement or scanning of a physically present user in order for user identifying data U to be derived. User interaction means 122 communicates with a foreground process or front end 124, in general a web browser carried on by a multitasking processor (not shown) of user equipment 12. Foreground process communicates with network 16 which is not secure, and ultimately server 16, via a wired or wireless link 22 between user equipment 12 and network 16. Further, a smartcard reader 126 associated with user equipment 12 is configured for coupling to the user's smartcard 18 for communication therewith, and is controlled by a background process or back end 128 of the user equipment which also routes communication to and from smartcard 18 to network 16, and ultimately server 14, via link 22.

[0023] Foreground process 124 is controlled by execution of a Java applet which is sent from server 14 to user equipment along with a blank document D₀(which may be integrated in the applet) when the document system of the server is accessed. The applet implements hashing means and encryption means functions 124a,124b,respectively and other mathematical functions necessary to form the data mentioned herein as being formed by foreground process 124, as well as handling the communication with user interaction means 122 as the user 20 fills out or completes the document. When the document has been filled-out and approved by the user so as to constitute an approved document D_f, the applet causes the latter to be sent to server 16.

[0024] As previously mentioned, the Java applet running under a browser cannot access smartcard reader 126 or background process 128, thereby necessitating that all communication between the foreground and background processes 124, 128 take place by server echoing. For example, data is sent from the foreground process to the background process by the circuitous route of the foreground process sending the data to the server and the server sending the data to the background process. Since this insecure route exposes the communication to and from smartcard 18 to being recorded and replayed by a malicious person monitoring the network, security measures are taken including the provision of a random number generator 182 and an authentication means 188 in the smartcard 18 and the generation of a second data item I₂by foreground process 124 which is a function of the generated random number RN and is used by the authentication means 188 of smartcard 18 to determine whether or not a document hash H₀derived from a first data item I₁presented to the smartcard is authentic.

[0025] Random number generator 182 is preferably a true random source using a noisy natural phenomenon. A suitable source is a noisy reverse biased zener diode which produces shot noise in its current flow, and the random number length is preferably chosen to be 256 bits in length, although a length of 128 bits is also usable.

[0026] In the applet controlled foreground process 124, hashing means 124ais used to apply a secure hash function (SHA-1 or RIPEMD) to a filled-in document D_f(or other approved document) to form H₀, which is then encrypted by an asymmetric algorithm such as RSA, with the public key of the user to form the first data item I₁. Hashing means 18 is also used in forming a second data item I₂by hashing together H₀, the random number RN previously generated by random number generator 182 of smartcard 18 and communicated to foreground process 124, and user identifying data U consisting of a password, passphrase (or a hash thereof), or a hash of biometric information. The random number RN had been communicated to foreground process 124 by server echoing in a manner which will be more fully explained later. There are many techniques known to those of ordinary skill in the art for hashing together a plurality of data items to form a data string of fixed length, any of which are suitable. A sufficient technique is applying a hash function to a concatenation of the data items to form a hash of at least 128 bits in length (160 bits if SHA-1 is used).

[0027] Smartcard 18 also includes a memory 184 for storing at least the most recently generated random number RN, and the user's private key and user identifying data U (password or passphrase or hash of biometric information), which has previously been loaded in a secure manner during a setup phase when the smartcard was issued with a generated private key assigned to the user and with the user's identifying data U derived from information entered by the user, in the case of a password or passphrase, or from information scanned or measured with respect to the user, in the case of biometric information. Further, an encryption means 186 is included for forming a digital signature DS in a standard manner by encrypting a document hash H₀with the user's private key, but in accordance with the present invention, only if document hash H₀is authenticated by the authentication means 188.

[0028] Authentication means 188 includes a decryption means 188afor decrypting the received first data item I₁using the private key of the user read from memory section 184bto derive document hash H₀, and a hashing means 188bfor applying the same “hashing together” operations to the derived document hash H₀, and the most recently generated random number RN and the user identifying data U read from memory 184, as were applied by hash means 124a. Authentication means 188 also comprises a comparison means 188cfor comparing the “hashing together” result with the received second data item I₂. If these items are equal, the derived document hash H₀is considered authentic, i.e. having come from the user equipment 12 of the user 20 with the assigned user being physically present, and it is used by encryption means 186 to form the digital signature DS, which is then sent to server 14 via network 16.

[0029] Server 14 comprises an authentication means 142, including, as is typical for authenticating the digital signature DS received from smartcard 18, a decryption means 142afor decrypting DS to compute document hash H₀in one way, hashing means 142bfor applying the same secure hash function used by hashing means 124a to the filled-in document D_freceived from foreground process 124 to compute document hash H₀in another way, and a comparison means for comparing the document hashes computed in these two ways. If they are the same the digital signature DS and filled-in document D_fare considered verified.

[0030] Server 14 comprises a memory 146 which may be or include RAM, ROM, a hard disk, or other memory or media. Memory 146 contains respective sections 146a-d,or fields in a data structure, for storing user IDs, public keys, documents and associated digital signatures DS, respectively, for all users, which are indexed or otherwise addressable or retrievable by ID, and also a section 146efor storing one or more applets. In addition, an echo means 144 of the server 14 is used for enabling communication between the foreground and background processes 124, 128 of user equipment 12.

[0031] The operation of the system shown in FIG. 1 will be best understood by further reference to the flowchart of FIG. 2. As shown, the operation begins at block 40 with the user 20 causing, by input to user interaction means 122, a request to be sent from user equipment 12 to server 14 for access to the document system, and the server responding at block 42 to this request by sending a blank sign-in page to the user equipment. The user then, at block 44, enters his ID in the sign-in page via user interaction means 122 which is sent by the user equipment 12 to the server 16, and the server responds at block 46 by sending a blank document D₀and associated applet to the user equipment for controlling the foreground process 124. Thereafter, the completed document D_fis formed and approved by the user at block 48 via user interaction means 122 and under the control of the applet. The completed document D_fthus formed in the foreground process 124 is hashed at block 50 by the hashing means 124afunctionality of the applet to form H₀.

[0032] At block 52, which may occur earlier than as shown, foreground process 124 requests a random number RN, which request is echoed by the server at block 56 so that it reaches the smartcard 18 via the background process 128. In the smartcard, at block 58, generator 182 generates a random number RN which is stored in memory section 184aand sent to the server via background process 128, and at block 60 is echoed by the server to foreground process 124. Also, at block 54, which may also occur earlier than as shown, the user identifying data U is obtained as a result of interaction of user 20 with user interaction means 122. In particular, the user enters his password or passphrase or the user's biometric information is obtained by measuring or scanning with respect to the physically present user and is then hashed to a fixed length of at least 128 bits (160 bits if SHA-1 is used) so that the user identifying data U is available to foreground process 124.

[0033] The second data item I₂is formed at block 62 by foreground process 124 hashing together document hash H₀, random number RN and user identifying data U to a fixed length of at least 128 bits (160 bits if SHA-1 is used). also the first data item I₁, is formed at block 64, which may occur earlier than as shown, by encrypting document hash H₀using the public key of the user. The public key of the user must be provided to foreground process 124 with a certificate from a trustworthy source in order to counter a man-in-the-middle attack. Preferably, the public key of the user and certificate are sent by the server along with the blank document and applet at block 46, although, alternatively, if the smartcard were configured to supply a certificate from such a source, it could have supplied the public key of the user and certificate along with the generated random number at block 58. The first and second data items I₁, I₂are sent at block 66 by foregound procees 124 to server 14 where they are echoed at block 68 to smartcard 18 via background process 128.

[0034] In smartcard 18, at block 70 first data item I₁is decrypted by decryption means 188awith the private key of the user to obtain the document hash H₀. Then at block 72, the obtained document hash H₀, and the last computed random number RN and user identifying data U read from memory 184 are hashed together by hashing means 188bto form a derived second data item I₂′ which at block 74 is compared by comparison means 188cto the received second data item I₂. If these items are the same, the derived document hash H₀is authenticated and at block 76, it is encrypted with the private key of the user to form the digital signature DS, which is sent to the server 14 via background process 128.

[0035] Further, at some point after the filled-in document D_fis formed in foreground process 128, in block 78 it is sent by the foreground process to server 14.

[0036] At the server, the verification of the digital signature DS and the approved document D_fproceed in a conventional manner. The received approved document is hashed at block 80 by hashing means 142b,and the received digital signature DS is decrypted at block 82 by decryption means 142a,using the public key of the user. Then the results of these operations are compared at block 84 by comparison means 142c.If the compared items are equal the approved document D_fand digital signature DS are verified and are stored at block 86 in timecard storage sections 146c, 146d,respectively, of memory 146.

[0037] It should now be appreciated that the objects of the invention have been satisfied. While the present invention has been described in particular detail, it should also be appreciated that numerous modifications are possible within the intended spirit and scope of the invention.