Patent Application
20080016357
The present invention will become more fully understood from the detailed description and the accompanying drawings, wherein:
The method of the present invention relates to digital signatures, more particularly to a method of securing a digital signature by use of a short-lived private key.
Referring now to the drawings, in which like numerals represent like components throughout the several views, the preferred embodiments of the present invention are next described. The following description of the preferred embodiment(s) is merely exemplary in nature and is in no way intended to limit the invention, its application, or uses.
The CA 40 then hashes the user information and the public key of the user 15 with a one-way hash algorithm. Hashing is the transformation of a string of characters into a numeric or other value that represents the original string. The hashing algorithm is called a hash function.
The CA 40 uses its private key to encrypt the “hash.” The encrypted hash may be in any number of file formats including, but not limited to, ASCII, base 64 encoding, PEM encoding or others. The CA 40 attaches the encrypted hash to the user information and user public key and also attaches the public key of the CA 40 forming the digital certificate. The digital certificate is sent from the CA 40 to the user 15 via a web session, email, floppy disk, or other means and resides on the machine 20 of the user 15.
A digital certificate can be tied to biometric data or information. Examples of biometric data include, but are not limited to, finger print, voice, handwriting, and facial recognition. Biometric information can be captured in the case that an electronic signature pad or other biometric device is used as a portion of the signing ceremony. The biometrics with the digital signature could be used together to provide forensics if a signature is repudiated. Biometric information is typically added into the artifact before the hash is completed. This type of information may be helpful for the purposes of legal non-repudiation to tie the user to the act of signing.
In accordance with the method of the present invention, when a user 15 wants to sign an artifact or when a user is presented with an artifact for signing by the webserver 30, for example, the user 15 uses it private key to digitally sign the artifact. The user 15 takes an overt action showing the intention to sign. For example, the user could perform the signing action by any number of methods including, but not limited to, signing with a pen on a tablet, clicking with a computer mouse on the sign-here field, selecting the sign-here box, and pressing a key that would instruct the computer to perform the signing. The artifact is hashed using a hashing algorithm. An example of a hashing algorithm includes, but is not limited to, SHA, SHA1, and MD5. Hashing may occur on the user machine or the webserver. The hash is then encrypted by the private key of the user. The act of signing comprises hashing the artifact using the hashing algorithm and encrypting the hash with the user private key. The encrypted hash becomes the digital signature of the user 15 and is attached to the artifact to be verified later. The digital certificate of the user 15 is attached to the artifact. Thus, once the signing ceremony is complete, the private key is programmatically destroyed. The term “programmatically” as used herein refers to programmed instructions to destroy the user private key after the signing ceremony is complete. For example, these instructions may be programmed in the code of the user machine or may be sent to the user machine by the webserver. Hence, since the user private key is programmatically destroyed, it is “short-lived.” Once destroyed, the private key is unable to sign any more artifacts.
Upon completion of the signing ceremony and once the private key has been programmatically destroyed, the event could be logged and audited in a “secure log.” A “secure log” would comprise an audit of all events where any tampering would be evident. The log could be signed and/or encrypted. Also, a copy of the signed artifact could be printed as proof of the transaction.
It is preferred but not required that the private key is both created and destroyed at the machine 20 of the user 15. The private key of the user 15 may get to the webserver 30 where document is “presented” from the computer screen of the user 15 but could not be compromised at that server because only the user could use the private key at that server. The artifact may get signed at the user machine 20. Thus, the webserver 30 may get access to the private key of the user 15.
Only the public key corresponding to the associated private key can be used to decrypt the hash and to check, for example, for data integrity and for technical non-repudiation. Technical non-repudiation refers to the ability to prove that the private key of the user signed the artifact. This is in contrast with legal non-repudiation in which one has to prove that it was really the user who actually signed the artifact with the private key of the user.
There are numerous methods that may be employed to programmatically destroy the private key of the user in accordance with the method of the present invention. The public and private keys, for example, may be created in memory in the web browser of the user machine. Thus, the memory can be cleared in the browser (temporary memory). The user may hit the “finish” or “end” button, for example, and trigger automatic destruction of the private key.
Another method for programmatically destroying the private key may involve placing the private key in an operating system (such as a Windows registry) in the computer or other electronic device of the user. During signing, computer code is accepted and the code issues instructions to destroy the private key. The code knows whether the private key is resident on the browser or whether resident on the user computer. Examples of code include, but are not limited to, Java, C, C++, and NET. The private key is typically more permanent in workstation with registry because to delete the private key an entry needs to be made in the operating system.
Another alternative method of programmatically destroying the private key in the case of a USB token, smart card or other electronic device, for example, is that the manufacturer for the respective device may provide an application program interface (API) that facilitates destruction of the private key. Examples of available programs include, but are not limited to, Token Management System (TMS) from Alladin Inc., Gemsafe from Gemplus Inc., and Affina by the Datacard Group.
Thus, there are numerous advantages associated with the method of the present invention. The present invention would eliminate the need for life cycle management of the digital certificate. The private key that needs to be secured would be programmatically destroyed and the digital certificate that was valid at the time of the signing ceremony would be captured with the artifact for verification at any time in the future. As a further safeguard, the digital certificate could be revoked and listed on a Certificate Revocation List (CRL) or Online Certificate Status Protocol (OSCP) server or any other form of certificate revocation. However, with the method of the present invention, the digital certificate itself would not need to be short-lived because the private key would be short-lived and not be able to sign any more artifacts after destruction. Therefore, the expiration date may be of any duration but at a minimum the length of the signing ceremony.
The following is a prophetic example in accordance with the present invention illustrating a method to programmatically destroy a private key from a key container using Microsoft.NET software for Windows and its respective terminology. It is merely exemplary in nature and is in no way intended to limit the invention, its application, or uses.
In step 1, a new instance of a CspParameters (Cryptographic service provider) class is created and the name for the key container is passed to the CspParameters.KeyContainerName field. In step 2, using an asymmetric algorithm to construct the key container to hold the asymmetric key, the name and parameters are passed to the key container (i.e. a new instance of a class that derives from the AsymmetricAlgorithm class usually RSACryptoServiceProvider or DSACryptoServiceProvider is created and the previously created CspParameters object are passed to its constructor. In step 3, set from persistent to non-persistent by setting to false. Persistent means remains or persists even if rebooted (need to take out of protected memory to volatile memory). The PersistKeyInCSP property of the class that derives from AsymmetricAlgorithm is set to false (False in Visual Basic). In step 4, the private key is deleted by calling the clear command (i.e. make it non-persistent to call the clear). Call the Clear method of the class that derives from AsymmetricAlgorithm. This method releases all resources of the class and clears the key container.
In non-programming terminology, the developer creates an asymmetric key in memory on the client or server computer, making sure that it does not live beyond a reboot (is non-persistent). After the key is used, it is cleared or erased.
Other methods can be coded for programmatically destroying the private key. Examples include, but are not limited to, Active X and Windows DLL. The key pair and associated digital certificate may have any arbitrary valid from, valid to dates (i.e. life). The life of the digital certificate should be long enough to provide for the completion of the signing ceremony of the artifact but not so long that if the destruction of the private key were not performed, there would be an unreasonable amount of time for compromise.
It will therefore be readily understood by those persons skilled in the art that the present invention is susceptible of broad utility and application. Many embodiments and adaptations of the present invention other than those herein described, as well as many variations, modifications and equivalent arrangements, will be apparent from or reasonably suggested by the present invention and the foregoing description thereof, without departing from the substance or scope of the present invention. Accordingly, while the present invention has been described herein in detail in relation to its preferred embodiment, it is to be understood that this disclosure is only illustrative and exemplary of the present invention and is made merely for purposes of providing a full and enabling disclosure of the invention. The foregoing disclosure is not intended or to be construed to limit the present invention or otherwise to exclude any such other embodiments, adaptations, variations, modifications and equivalent arrangements.
