Abstract:
Disclosed is a method for secure electronically signing a document, which comprises: reading the document to be signed by an application; presenting a graphical representation of said document to a user; and accepting the document to be signed by the user. The method also comprises: at a server, computing a hash function, an extended validation function for the hash and a readable summary function of the to-be-signed document; from the server, sending the hash function and the extended validation function for the hash to the application and to a signing device; from said the server, sending said hash function and the readable summary function of the to-be-signed document to a secondary device.

Description:
TECHNICAL FIELD 
       [0001]    The present invention relates to security in electronic documents. More particularly, the present invention relates to secure electronic signing of documents. 
       DESCRIPTION OF THE PRIOR ART 
       [0002]    Electronic documents are being used on all kind of business now, complementing or replacing paper documents. When those documents are used for any kind of legal transaction they usually require a signature, the same way that paper documents have to be signed. 
         [0003]    Handwritten signature implies the signer&#39;s intent but isn&#39;t linked to a particular document. It&#39;s perfectly possible to ‘lift’ a handwritten signature from a paper document, paste it into another and, barring proving the counterfeit of the signature, the new document would be considered signed. Digital signatures, however, are unique for each signer and document, so signatures are linked to a particular document. If anything changes in the document then the signature would not be valid. 
         [0004]    Digital signatures are composed using encryption algorithms. We can model a simple digital scheme as follows:
       1. Signers have two keys, a Verification (or public) Key (PbK) and a Signature (or private) Key (PvK). PbK is publicly known, and it is computationally unfeasible to get PvK from PbK. Only the signer knows and has access to PvK.   2. There exists a pair of functions S(k, x) (signature function) and V(k, x) (verification function) with the following property:       
 
         [0000]      V(PbK, S(PvK, x))=x       3. There exists a function H(x) (hash function) with the following properties:
           The output for H(x), being x a stream of bits of any length, is a fixed length strength of bytes.   Given x it is computationally efficient to compute H(x)   Given any value h which is a valid output from H(), it is computationally unfeasible to compute any value x such that H(x)=h.   
                 
         [0011]    So given the schema (Pvk, PbK, S(), V(), H()), the algorithm to compute a digital signature of a document D is as follows:
       1. Compute h=H(D).   2. Compute s=S(PvK, h)       
 
         [0014]    While the algorithm to verify a digital signature for a document D is as follows:
       1. Compute h=H(d)   2. Verify that V(PbK, s)=h       
 
         [0017]    With the scheme as defined, digital signatures are linked to a document and do not only imply signer&#39;s consent to the contents but also prevent any tampering with the document. 
         [0018]    Note that for this scheme to work, there must be some way of distributing, verifying and linking PbK to the signer. 
         [0019]    Schematically, the conventional signature process is represented in  FIG. 1 . On  FIG. 1 , Bob is the signer of the document and Alice the recipient/verifier of the signed document. 
         [0020]    A schema detailing the signature process, in which the private key PvK is stored on secure hardware, as implemented usually, is graphically represented in  FIG. 2 .  FIG. 3  represents the same process on a timeline schema, for clarity. The following table summarizes the illustrated process: 
         [0000]    
       
         
               
               
             
           
               
                   
               
             
             
               
                 100 
                 A Signature Application (SA) reads the document to be signed (D) 
               
               
                   
                 from the storage (local or networked) 
               
               
                 110 
                 The application presents a graphical representation of D to Bob, so 
               
               
                   
                 he can review it before signing. This part of the process is required 
               
               
                   
                 by most digital signature legislation. 
               
               
                 120 
                 Bob reads (and understands) the representation of D. 
               
               
                 130 
                 Bob affirms his intention of signing the document. It is possible 
               
               
                   
                 that in this step a PIN (Personal Identification Number) is required. 
               
               
                   
                 This PIN will be used to ‘unlock’ PvK. 
               
               
                 140 
                 SA computes H(D). 
               
               
                 150 
                 SA sends H(D) to the signing device, with the user&#39;s PIN if it is 
               
               
                   
                 required. 
               
               
                 160 
                 The signing device, using the securely stored private key, computes 
               
               
                   
                 and returns S(PvK, H(D)) 
               
               
                   
               
               
                 Note that the presented schema is valid for any triad of functions (S( ), V( ), H( )). 
               
             
          
         
       
     
         [0021]    Digital Signature Standard (DSS) presents a signature schema that, while specifying the concrete hash and encryption functions, follows the general schema just described. This scheme is described with complete detail on the Digital Signature Standard (DSS) 
         [0000]    (http://www.itl.nist.gov/fipspubs/fip186.htm). 
         [0022]    PKCS#7 (RFC-2315 http://tools.ietf.org/html/rfc2315) defines a Message Format for signed data. PKCS stands for Public Key Cryptographic Standards. 
         [0023]    XML-DSig (http://www.w3.org/TR/xmldsig-core/) is a W3C (World Wide Web Consortium) recommendation that defines XML (Extensible Markup Language) syntax for digital signatures. Functionally, it has much in common with PKCS#7 but is more extensible and geared towards signing XML documents. 
         [0024]    European patent application “Method and system for implementing a digital signature” (EP1142194 A1) describes a method to realize digital signatures on a mobile station, but there&#39;s nothing stated on it about the non-repudiation problem. 
         [0025]    Patent application ‘Electronic document processing system and method of forming digital signature’ (U.S. Pat. No. 5,465,299 A) describes a method to create ‘versions’ of a digitally signed document, in which each successive version is signed and includes the signature of the previous version. 
         [0026]    Patent ‘Method and apparatus for an adapted digital signature’ (U.S. Pat. No. 6,615,348 B1) describes an algorithm to generate user identities using a modified digital signature algorithm. 
         [0027]    Patent ‘Method and apparatus for validating a digital signature’ (U.S. Pat. No. 7,178,029 B2) describes a way to verify that a signature that includes a digital certificate is valid even if the digital certificate has been revoked. It&#39;s basically a timestamp service. 
         [0028]    However, current solutions present several problems: According to Ross Anderson, Professor of Security Engineering at the University of Cambridge: ‘I just don&#39;t know how to be confident of a digital signature I make even on my own PC—and I&#39;ve worked in security for over fifteen years. Checking all the software in the critical path between the display and the signature software is way beyond my patience.” And: ‘However, if I were foolish enough to ever accept an advanced electronic signature device, then there would be a presumption of the validity of any signature that appeared to have been made with it. [. . . ] This, coupled with the facts that smartcards don&#39;t have a trusted user interface and that the PCs which most people would use to provide this interface are easily and frequently subverted, made electronic signatures instantly unattractive.’ 
         [0029]    That is so because, on the scheme presented in  FIG. 2 , some other software running on the user&#39;s computer could intercept and change data on steps  100 ,  120 ,  140 ,  150  and  160 . And on step  130  it could capture the user&#39;s PIN and use it to silently sign more documents (automatically doing all the process except steps  110 ,  120  and  130 ). 
         [0030]    In other words, current systems and system definitions enforce severe restrictions on the way that ‘Signature Application’ (see  FIG. 2 ) is built. For example, applications built for the Spanish DNIe (electronic identity document) have to comply with Common Criteria EAL3 (Methodically Tested and checked). So it could be thought that any application that is certified is secure. 
         [0031]    But on the same certification document it is specifically stated that for the whole signature schema to be secure the user&#39;s device (computer) has to be secure. And with current technology it is virtually impossible to attest that any computer does not have malware installed and running. Never mind doing so after some time has passed. Any statement about the security of a user&#39;s computer when a signature was done (possibly several months or even years before) is just a wild guess. 
         [0032]    Thus, the problem is that, while digital signatures are mathematically sound and computationally easy, they are too complex to do or verify by hand, so the users do not have any trusted way to check what they are signing. This means that, effectively, users do not have real control over what they sign. 
         [0033]    The inventors have not found any existing patent document that tries to solve this problem. 
       SUMMARY OF THE INVENTION 
       [0034]    The present invention solves the above-mentioned problems by doing the critical computation (hash of the to-be-signed document) remotely, on a trusted location. 
         [0035]    This disclosure refers to a method and system which, based on the development of specific hardware and software residing on a trusted server, assure the validity of digital signatures realized with it. The method and system avoid or make evident any tampering on the normal digital signature process. 
         [0036]    In a first aspect, a method for secure electronically signing a document is presented. The method comprises: reading a document to be signed by an application; presenting a graphical representation of said document to a user; accepting the document to be signed by said user. The method also comprises: at a server, computing a hash function, an extended validation function for the hash and a readable summary function of the to-be-signed document; from said server, sending said hash function and said extended validation function for the hash to said application and to a signing device; from said server, sending said hash function and said readable summary function of the to-be-signed document to a secondary device. 
         [0037]    Preferably, the method also comprises: verifying by the user that said readable summary function of the to-be-signed document received in the secondary device corresponds to said document; verifying by the user that said hash function received in the secondary device is the same as the one the signing device is presenting to the user for his review; if the data verification is correct, accepting it by the user. Preferably, the step of accepting by the user is done by introducing the user&#39;s PIN in the signing device. 
         [0038]    Preferably, the method also comprises: computing by said signing device a signature function; sending said signature function by said signing device to said application. In a particular embodiment, the signature function is dependent on a securely stored private key, on said hash function and on said extended validation function for the hash. 
         [0039]    In a particular embodiment, the secondary device is a mobile terminal. 
         [0040]    In a particular embodiment, the step of accepting the document to be signed by said user is done without requiring the user&#39;s PIN. 
         [0041]    Once the user has accepted the document to be signed, the application preferably sends to the server some information about said document and about the signing device and the secondary device. Preferably, said information about the signing device and the secondary device is the address of the signing device and the address of the secondary device. 
         [0042]    In another aspect, a system comprising means adapted to perform the above-described method is presented. 
         [0043]    Finally, a computer program comprising computer program code means adapted to perform the above-described method is presented. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0044]    To complete the description and in order to provide for a better understanding of the invention, a set of drawings and a table are provided. Said drawings form an integral part of the description and illustrate a preferred embodiment of the invention, which should not be interpreted as restricting the scope of the invention, but rather as an example of how the invention can be embodied. The drawings comprise the following figures: 
           [0045]      FIG. 1  schematically represents a conventional signature process. 
           [0046]      FIG. 2  represents a schema detailing the conventional signature process, in which the private key PvK is stored on secure hardware, as implemented usually. 
           [0047]      FIG. 3  represents the same process on a timeline schema, for clarity. 
           [0048]      FIG. 4  shows a general scheme of the method and system according to an embodiment of the invention. 
           [0049]      FIG. 5  Shows a detailed scheme of the method according to an embodiment of the invention. 
           [0050]      FIG. 6  shows a timeline of the guaranteed signature process according to an embodiment of the invention. 
       
    
    
       [0051]    Corresponding numerals and symbols in the different figures refer to corresponding parts unless otherwise indicated. 
       DESCRIPTION OF PREFERRED EMBODIMENTS 
       [0052]      FIG. 4  shows a system according to an embodiment of the invention. The system comprises: a signing device  43 , which in the context of this disclosure is also called trusted signing device (TSD); and a server  40 , which in the context of this disclosure is also called trusted server (TS). The system also requires a client signature application (CSA), which is, with respect to the one described in the prior art, a modified client signature application. 
         [0053]    The signing device (TSD)  43  has a trusted user interface (incorporated into the device  43 ). This interface includes, at least, a screen and a numeric keyboard. Preferably, the signing device  43  has also wireless capabilities. Besides, it is configured to only process signature requests that include a correct extended validation (trusted signature) for the to-be-signed hash. The signing device (TSD)  43  has a standard ISO 7816 smartcard interface. The actual key storage can be on an external, pre-existing smartcard (for example, but not limited to, the Spanish DNIe). 
         [0054]    The server (TS)  40  is configured to:
       receive to-be-signed documents D from the users;   compute a hash function H(D) for the to-be-signed documents;   compute an extended validation function for the hash EV(H(D));   compute a readable summary function of document D, RS(D), which is a representation on plain text of the content included in D that will allow a potential signer to recognize D;
           send EV(H(D)) and H(D) to the signing device (TSD)  43 ; and   
           send RS(D) to a secondary device (SD)  42  of the user  41 . This secondary device  42  is preferably a mobile terminal  42 .       
 
         [0061]    The client signature application (CSA), also called modified client signature application, is configured to present D to the user and to send D to the server  40  (also called trusted server TS) to start the signature process, with the connection data for the signing device (TSD)  43  and the secondary device (SD)  42 . 
         [0062]      FIG. 4  shows a simplified schema of the method and signature process of the invention. 
         [0063]    A detailed scheme of the method according to an embodiment of the invention is shown in  FIG. 5 . 
         [0064]    In  FIG. 5 , a system comprising the following elements is shown: a client signature application (CSA)  54 , a user or signer  51 , a graphical user interface  55 , a server or trusted server (TS)  50 , a trusted signing device (TSD) or simply signing device  53  and a secondary device (SD)  52 . The method of secure signing a document D is as follows: 
         [0065]    In a first step  500 , a signature application or client signature application (CSA)  54  reads the document to be signed D from a storage, which can be either local or networked (remote). This step  500  is similar to the conventional method. 
         [0066]    Next, the signature application (CSA)  54  presents  510  through an output device or graphical user interface  55  (for example, a screen) a graphical representation of D to the signer (user  51 ), so he can review it before signing. This part of the process is currently required by most digital signature legislations. 
         [0067]    Afterwards, the signer  51  reads (and understands)  520  the representation of D. This step is neither different from conventional methods. 
         [0068]    Next, the signer  51  affirms  531  his intention of signing the document. This is done through an input device  56  which can be, for example, a keyboard. In this step  531  he is not required to introduce his PIN (Personal Identification Number). This is different from most conventional signatures processes. 
         [0069]    The following steps are also different from conventional signature processes: 
         [0070]    Then  541 , the client signature application (CSA)  54  sends D and the addresses of the secondary device (SD)  52  and the signing device (TSD)  53  to the server (TS)  50 . 
         [0071]    Next  542 , the server (TS)  50  computes H(D), EV(H(D)) and RS(D) (the readable summary of D). 
         [0072]    Afterwards  543 , the server (TS)  50  sends H(D) and EV(H(D)) to the client signature application (CSA)  54 . 
         [0073]    Then  551 , the server (TS)  50  sends H(D) and EV(H(D)) to the signing device (TSD)  53 . The signing device (TSD)  53  verifies EV(H(D)) and, if it is correct, it presents this information—H(D) and EV(H(D))—on its included interface (such as screen). 
         [0074]    Next  552 , the server (TS)  50  sends H(D) RS(D) to the secondary device (SD)  52 . In a preferred embodiment, this secondary device (SD)  52  is a mobile phone, in which case the data are sent by SMS or MMS. 
         [0075]    Afterwards  553 , the signer  51  verifies that RS(D) received in the secondary device (SD)  52  corresponds to the document (D) that he wanted to sign. 
         [0076]    Then  554 , the signer  51  verifies that H(D) received in the secondary device (SD)  52  is the same as the one the signing device (TSD)  53  is presenting for his review on its included screen. 
         [0077]    Next  555 , if the data verification is correct, the signer  51  introduces his PIN on the signing device&#39;s (TSD)  53  keyboard. 
         [0078]    Then  561 , the signing device  53 , using the securely stored private key and the user&#39;s provided PIN (Personal Identification Number), computes a signature function S from PvK and EV(H(D)), S(PνK, EV (H(D))). 
         [0079]    Finally  571 , the signing device sends S(PνK, EV(H(D))) to the client signature application (CSA)  54 . The extended validation function (EV) is included in the signature to attest that the signature was realized used the system described in this document, and to avoid the possibility of repudiation of the signature. 
         [0080]    The corresponding timeline of the inventive signature process is described in  FIG. 6 , wherein corresponding reference signs have been used ( 610  instead of  510  and so on). 
         [0081]    As described, one of the main advantages of this invention is that it prevents the tampering with the signature data, or makes this tampering evident to the signer, thus avoiding possible repudiation problems. 
         [0082]    With current solutions the signer of any digitally signed document can contest (repudiate) any signature done with his private key on the basis that it is impossible to him (even according to experts on the field, like the aforementioned Ross Anderson) to know exactly what he is signing. The signer could repudiate the signature by saying that:
       The document he was shown is not the document that has the signature. It could be done by an application on his own PC.   Some application could have stolen his PIN and used it to sign any number of documents without him being informed.       
 
         [0085]    Since digital signatures are being used on more applications every day (and on the EU will be mandatory for relationships with the government soon), it is mandatory to find a solution to this problem. The invention presented on this document is such a solution.