WO2018211475A1 - Method for the creation of a document provided with a high-security digital signature - Google Patents
Method for the creation of a document provided with a high-security digital signature Download PDFInfo
- Publication number
- WO2018211475A1 WO2018211475A1 PCT/IB2018/053528 IB2018053528W WO2018211475A1 WO 2018211475 A1 WO2018211475 A1 WO 2018211475A1 IB 2018053528 W IB2018053528 W IB 2018053528W WO 2018211475 A1 WO2018211475 A1 WO 2018211475A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- hash
- document
- signature
- signed
- signing
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 63
- 238000012795 verification Methods 0.000 claims description 51
- FGUUSXIOTUKUDN-IBGZPJMESA-N C1(=CC=CC=C1)N1C2=C(NC([C@H](C1)NC=1OC(=NN=1)C1=CC=CC=C1)=O)C=CC=C2 Chemical compound C1(=CC=CC=C1)N1C2=C(NC([C@H](C1)NC=1OC(=NN=1)C1=CC=CC=C1)=O)C=CC=C2 FGUUSXIOTUKUDN-IBGZPJMESA-N 0.000 claims 1
- 238000012546 transfer Methods 0.000 description 14
- 238000010586 diagram Methods 0.000 description 8
- 230000003542 behavioural effect Effects 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 238000003780 insertion Methods 0.000 description 2
- 230000037431 insertion Effects 0.000 description 2
- 241000234282 Allium Species 0.000 description 1
- 235000002732 Allium cepa var. cepa Nutrition 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 238000005242 forging Methods 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
Definitions
- the object of the invention relates to a method for the creation of a document with a high-security digital signature.
- Biometric data is data that codes certain physiological or behavioural characteristics of the user (such as data relating to fingerprint, iris image, handwritten signature). Biometric data is extremely difficult to forge, and a digital signature containing such data can be linked to the signatory user.
- a hash is a compressed data package created by a hash generator algorithm (such as SHA-256) from a digital document, and from which it is impossible to reconstruct the original digital document.
- a unique feature of hash-generating algorithms is that changing any part of the original digital document produces an avalanche-like effect in the hash, due to which it completely changes. As a result, re-generating the hash is suitable for checking if any change has been made in the digital document, in other words it is suitable for ensuring the integrity of the document.
- Patent number US 7,024,562 discloses a digital signing process that combines the use of a biometric identifier and a hash.
- a problem may be presented by the fact that the biometric identifier (fingerprint in the present case) needs to be recorded using a separate hardware device, which, however, does not encrypt the data recorded or create a hash from it.
- the document's hash and the biometric identifier's hash are generated at the same time by the same software component, which, on the one hand, makes the system vulnerable, and on the other hand, it cannot be ensured that the biometric identifier was actually destined for the signed document.
- a further disadvantage is that in the case of the suspicion of unauthorised intervention, the hardware on which the biometric identifier was recorded cannot be subsequently traced.
- high-security digital signature is understood to mean a digital signature that satisfies the following requirements:
- the objective of the invention is the provision of a high-security digital signature that meets the above requirements and that is free of the disadvantages of the solutions according to the state of the art.
- Figure 1 depicts a schematic block diagram of the entities participating in the method according to the invention
- Figures 2 and 3 depict a schematic flow diagram illustrating the steps of placing a digital handwritten signature
- Figure 4 depicts a schematic flow diagram illustrating the signature verification steps
- Figure 5 depicts a schematic flow diagram illustrating the steps of authenticating the signature
- Figure 6 depicts a schematic flow diagram illustrating the steps of providing an organisation seal
- Figure 7 is a schematic flow diagram illustrating the steps of the legalisation of an organisation seal with a timestamp.
- Signature-creating data unique data that the signatory uses to create the digital signature, here this may be broken down into three different subtypes:
- the certificate of the device in the case of a signature created with a signing device, the certificate of the device, with metadata, the associated signature performed with the encrypted key stored in the signing device, the image of the handwritten signature, the biometric data sampled from the handwritten signature, the hash of the signed content, and optionally the current time in the form of a timestamp.
- Biometric data digitally recorded data extracted from a biometric signature coding the physiological or behavioural characteristics of a natural person.
- Biometric signature a digitally recorded sample linked to a natural person carrying the physiological and/or behavioural characteristics of a natural person (such as handwritten signature, fingerprint, iris image, voice sample).
- Biometric identifier a biometric data set extracted from the biometric signature for the identification of the natural person.
- the CRL (Certificate Revocation List) is the offline version of certificate revocation lists
- the OCSP Online Certificate Status Protocol responses contain revocation information relating to the given moment in time downloaded from the online version of the certificate revocation lists.
- Digital signature digital data or document logically associated to a digital document for the purpose of identification and inseparably connected to it.
- the digital signature is characteristically created through processes that include cryptographic methods, therefore it is also referred to as a cryptographic signature (PKI signature).
- PKI signature cryptographic signature
- Digital signature verification comparing the content of a digital document when it was signed with when it was verified, furthermore the identification of the signatory person with the use of signature verification data appearing in the document, or published by a verification service provider, and with the use of the certificate and derived data (e.g. CRL, OCSP responses).
- certificate and derived data e.g. CRL, OCSP responses
- High-security digital signature a digital signature that meets the following requirements:
- Handwritten signature handwritten signature produced by a natural person.
- Certificate a certificate issued by a verification service provider that links the signature verification data to a natural person or organisation, and certifies its validity.
- Figure 1 depicts a block diagram of the entities participating in a preferred embodiment of the method according to the invention. At least three entities take part in the signing process, signing device 10, signing device controller 20 and signatory 30.
- the signatory 30 is the natural person whose signature is recorded with the signing device 10 during the signing process, which signature, in the present case, is a handwritten signature, but in other embodiments it may be a fingerprint or other biometric signature.
- the signing device 10 is a signature pad 10', which preferably has a display 12 and a digital pen 14 serving for inputting the handwritten signature.
- Signotec Omega, Signotec Gamma, or Signotec Delta signature pads 10' can be used, on which the software serving for implementing the processes according to the invention is installed.
- signing device 10 may be used, for example, if instead of a handwritten signature, signing is to take place with a fingerprint then there is no need for a pen 14, however a fingerprint reader will be required.
- a smartphone provided with a fingerprint reader may also be used as fingerprint reader signing device 10.
- the recording of a handwritten signature may take place in other ways, for example the user may use her finger instead of a pen 14 to draw her signature on the display 12 provided in the form of a touch screen.
- the signing device 10 must have hardware and software components that correspond to the biometric signature, therefore its structure may significantly deviate from the structure of the signature pad 10' presented here as an example, as is obvious for a person skilled in the art.
- At least one encryption key and at least one signing key are used in the signing process implemented with the signing device 10.
- Preferably RSA asymmetrical key pairs are used for both encryption and signing.
- the encryption key is preferably a public key 40b of an asymmetric key pair 40, which is stored in a non-volatile data store 15 of the signing device 10, preferably along with the certificate belonging to the public key 40b.
- the asymmetric key pair 40 may be, for example, a 2048-bit RSA key pair, and the certificate belonging to the public key 40b may be an X.509 standard certificate.
- the private key 40a of the asymmetric key pair 40 permitting the decryption may be accessed from a protected, non-volatile external data store 43 (such as a USB drive stored in a safe, in a p12 software container, or in an HSM (Hardware Security Module) preferably in an X.509 v3 compatible format).
- a protected, non-volatile external data store 43 such as a USB drive stored in a safe, in a p12 software container, or in an HSM (Hardware Security Module) preferably in an X.509 v3 compatible format.
- the private key 40a is also present in a verification system 50, or accessible to the verification system 50, which performs the verification of the biometric signatures as will be disclosed later on.
- the signing key is preferably the private key 44a of a second asymmetric key pair 44, which is also stored in the data store 15 of the signing device 10.
- the second asymmetric key pair 44 is preferably generated within the signing device 10, and cannot be extracted from the signing device 10 without causing damage to it.
- the signing device 10 issues the public key 44b of the second asymmetric key pair 44 preferably as a part of the signing certificate used during signing.
- the public key 44b may be stored in any device that may be needed for verifying the signature, or in a location from where the public key 44b required for verification can be accessed.
- the signing device controller 20 is preferably established as a separate hardware device, for example, it may be a personal computer, mobile device or a server on which the software serving for implementing the processes according to the invention is installed.
- the timestamp service provider 60 is preferably an authenticated service provider independent of the organisation, which service provider 60 supplies a data set requiring a timestamp with a precise timestamp and a cryptographic signature in the course of rendering the timestamp service.
- the timestamp protocol may be a protocol in accordance with the RFC 3161 standard, and the cryptographic signature may be, for example, an RSA-2048 or RSA-4096 signature.
- the document provided with a high-security signature is created within the framework of an organisation (such as a firm of solicitors, bank, public utility service provider, telecommunications service provider, etc.).
- the implementation of the method according to the invention also involves the participation of a signature-creation unit 72 and an organisation seal 74.
- the signature-creation unit 72 is a process, or device i.e. the combination of a software program, software application and hardware (such as a server and a program running on it).
- the signature-creation unit 72 handles the document to be signed, and controls the appropriate processes of the cryptographic signature.
- the organisation seal 74 is a software component (or a combination of hardware and software) that is able to provide a hash with a signature using methods that are predefined using a signing key belonging to an organisation certificate.
- the cryptographic signing key of the organisation seal 74 is preferably the private key 76a of a third asymmetric key pair, which is stored by the organisation seal 74, or stored elsewhere, but which is only accessible to the organisation seal 74.
- the private key 76a may be, for example, an RSA-2048 or RSA-4096 key.
- the public key 76b of the third asymmetric key pair 76 may be stored in any device that may be needed for verifying the signature, or in the location from where the public key 76b required for verification is to be made accessible, or it may be embedded in the signed data set upon signing in the form of a signing certificate.
- the signature-creation unit 72 and the organisation seal 74 may even be components of a single computer process, but are preferably separate.
- the timestamp service provider 60 preferably operates within the frame of an independent organisation, thus having separate hardware and software.
- the entities illustrated in figure 1 communicate with each other via data transfer channel 80.
- the data transfer channel 80 may be a fixed-line or wireless (e.g. WiFi, Bluetooth) connection or even a combination of these.
- the data transfer channel 80 is also understood to mean the physical transfer medium, in other words the hardware components participating in the structure of the communication channel (e.g. cables, connectors, signal generators, amplifiers, etc.), and a (typically encrypted) logical channel established in a multiplexed medium (e.g. computer network).
- the data transfer channel 80 may be dynamically established and terminated, for example, the data transfer channel 80 may be logically and/or physically terminated between two entities, then established once again, if several communication steps are required.
- step 100 the signing device controller 20 visible in figure 2 receives a document 90 to be signed as input, preferably in PDF format, but naturally such embodiments are also conceivable wherein the document 90 is created by the signing device controller 20.
- step 102 a cryptographic hash of the document 90 to be signed is created using the signing device controller 20, which henceforward will be referred to as first hash 91 .
- the creation of the first hash 91 may take place with a known algorithm, such as the SHA-256 algorithm, but naturally any other preferably collision resistant, modern (allowing fast execution) hash function algorithm may be used as well.
- step 104 the signing device controller 20 forwards the first hash 91 to the signing device 10. If the signing device controller 20 and the signing device 10 are separate physical devices, then this takes place via the data transfer channel 80 established between the signing device controller 20 and the signing device 10. Simultaneously or at a different time, in step 108 the signing device controller 20 also sends the data set suitable for visually displaying the document 90 to be signed, which may be, for example, the PDF format document 90 itself, but it is also conceivable that instead of the entire document only the image 90' displaying the vicinity of the content to be signed is forwarded.
- the data set suitable for visually displaying the document 90 to be signed which may be, for example, the PDF format document 90 itself, but it is also conceivable that instead of the entire document only the image 90' displaying the vicinity of the content to be signed is forwarded.
- the signing device controller 20 creates the image 90' displaying the vicinity of the content to be signed in step 106, which preferably is of a size and definition corresponding to the display 12 of the signing device 10, therefore the entire content thereof may be displayed on the signing device 10.
- step 1 10 the image 90' of the document 90 is displayed for the signatory
- the signatory 30 provides her biometric signature 32, while in step 1 12 the signatory's 30 biometric signature 32 is recorded using the signing device 10.
- biometric signature 32 In the case of the use of a fingerprint the signing device's 10 fingerprint reader records the fingerprint functioning as the biometric signature 32. In the case of other biometric signatures 32 the sensor corresponding to the biometric signature 32 records the signature. The various types of biometric signature 32 may also be combined.
- the signing process is preferably of a nature that if the signatory so decides, she has the opportunity to interrupt the signing process, and restart it. Furthermore, the system ensures that the signature is not accepted in the case of too little data being entered (such as one or two strokes when recording a handwritten signature).
- a biometric identifier 34 containing biometric data is extracted from the recorded biometric signature 32 using the signing device 10.
- the biometric identifier 34 is a high-resolution (sampled at high frequency) biometric data set produced from the recorded data.
- the biometric data of the biometric identifier 34 may code other information in addition to the image information, such as the speed of the pen strokes with respect to the individual points of the signature, and the pressure exerted.
- the biometric identifier 34 is supplemented with the first hash 91 of the document 90 (marked with a dotted line), in this way the biometric identifier 34 itself is linked to the signed document 90.
- a second data set is produced from the biometric signature 32 using the signing device 10, which is a low-resolution (sampled at low frequency) data set suitable for being displayed as an image, from which a visible signature image 32' of the biometric signature 32 (handwritten signature in the present case) can be produced. If the low-resolution data (i.e.
- the signing device controller 20 uses this visible signature image 32' (or an image generated from it).
- biometric signatures 32 such as handwritten signature, fingerprint
- others such as a voice sample
- the fact of signing can be illustrated in other ways on the document 90, for example the signatory's 30 name is indicated on it.
- the signatory's 30 name is indicated on it.
- Naturally other data in connection with the fact of signing may be placed in the document 90 in legible form, such as the first hash 91 , or its first few characters, or the date, place of signing.
- the biometric identifier 34 is encrypted in step 1 18.
- the public key 40b of the first asymmetric key pair 40 is used for encryption.
- An asymmetric encryption is a very compute intensive task, it is only worthwhile using it for short data sets. In the case of large data sets, such as the biometric identifier 34, symmetric encryption may be used suitably quickly and effectively. Due to this the two types of encryption are preferably combined, and in such a way that the private key 40a of the asymmetric key pair is needed for decryption. This is achieved by generating a temporary symmetric key using the signing device 10 (e.g.
- the biometric identifier 34 is encrypted with this temporary symmetric key.
- the symmetric key is then encrypted with the public key 40b of the first asymmetric key pair 40, and is sent to the signing device controller 20 along with the encrypted biometric identifier 34' (simultaneously or at a separate time) in step 1 19. In this way the encrypted biometric identifier 34' cannot be decoded on the receiving side without the private key 40a of the first asymmetric key pair 40.
- a hash of the encrypted biometric identifier 34' is produced using the signing device 10, which is referred to hereinafter as second hash 82.
- This second hash 82 may only and exclusively be created within the signing device 10 on the basis of the encrypted biometric identifier 34', it cannot enter the process in any other way, which increases the security of the method according to the invention even further.
- step 121 the first hash 91 and the second hash 82 are concatenated using the signing device 10 and then signed in step 122 (figure 3) with the cryptographic signing key stored in the signing device 10, whereby a signed hash 84 is created.
- the signing key is preferably the private key 44a of the second asymmetric key pair 44 generated in the signing device 10.
- step 124 the signed hash 84 created with the signing is forwarded with the help of the signing device 10 to the signing device controller 20 through the data transfer channel 80.
- the forwarding of the signed hash 84 may take place simultaneously with the forwarding of the encrypted biometric identifier 34' (step 1 19), in a joint data package, or separately before or afterwards.
- Step 126 may also take place simultaneously with the other data transferring steps 1 19, 124, or separately from them, in any sequence.
- the encrypted biometric identifier 34' (optionally including the the symmetric key required for decryption, which has been encrypted with the asymmetrical coder) and the signed first and second (optionally concatenated) hash 84 are received by the signing device controller 20.
- step 128 using the signing device controller 20, the document 90 to be signed is concatenated with the encrypted biometric identifier 34' and the signed first and second hash 84, optionally in step 130 also with the signature image 32' of the biometric signature 32 or an image corresponding to other encrypted biometric identifier.
- a signed document 90a provided with a high- security digital signature is created, which may be the final signed document, but, preferably, further steps are performed on it that increase security.
- steps 128, 130 is optional, optionally the two concatenating processes may be carried out in a single step.
- signing takes place according to the following.
- the signing device controller 20 creates a new document version in the PDF document 90 to be signed, then it creates therein a signature container 92 and the visible signature image (signature image 32') in the form of PDF objects.
- the signature container 92 contains data related to encryption, such as the encrypted biometric identifier 34', the hash 84 signed by the signing device 10, as well as numerous data packages serving to satisfy the conditions of LTV (Long Term Validation) support.
- the latter include certificates 45 and certificate chains as well as CRL/OCSP responses 46.
- the biometric identifier 34 is checked with the verification system 50 (figure 4). To allow this, in step 132 the received encrypted biometric identifier 34' is forwarded using the signing device controller 20 through the data transfer channel 80 to the verification system 50.
- the verification system 50 preferably has access to the private key 40a of the asymmetric key pair 40 used for the encryption, with which in step 134 the encrypted biometric identifier 34' is decrypted, or the encrypted biometric identifier 34' may be decrypted with an independent HSM module if the private key 40a is stored there.
- the verification system 50 analyses the biometric identifier 34 for the purpose of extracting one or more biometric signature verification data (for example, it determines various characteristics).
- the verification system 50 compares the result of the analysis, in other words the extracted one or more biometric verification data is compared to one or more biometric verification data extracted from at least one of the alleged signatory's 30 previous biometric identifiers 34. Accordingly, on the basis of the prior data registered in the verification system 50, it can be determined whether or not the signature in question was created by the alleged signatory 30, also, the probability of this may be determined to the extent of the similarity.
- the biometric signature verification data serving as a reference is such that it does not permit the reconstruction of the biometric identifier 34, therefore the user's signature cannot be forged by its unauthorised extraction.
- the one or more signature verification data serving as reference may be created in the verification system 50 from the user's sample signature registered before first use.
- the verification system 50 verifies the identity of the signatory 30 using one or more (biometric) verification data published by a verification service provider and the (biometric) certificate related to it.
- the biometric verification data are unique data extracted from one or more biometric identifiers that the person examining the digital document uses to perform a high-reliability verification of the biometric signature.
- the biometric certificate is a certification issued by the verification service provider that links the biometric verification data to a natural person and certifies its validity.
- the data set containing the result of the comparison is forwarded in step 139 to the signing device controller 20, which in step 140 also links the verification result 36 to the document 90 (preferably to the previously created document 90a containing the signature container 92 and the signature image 32).
- the signing device controller 20 also embeds the verification result 36 into the PDF document 90a as described above, and as a result of this a new document 90b is created, which contains further security elements as compared to the previous document 90a.
- the verification result 36 may contain a cryptographic signature created using a further private key and the associated certificate, which cryptographic signature can only be created by the verification system 50. This can be ensured e.g. such that the verification system 50 stores this private key or such that the private key is stored in an external HSM and the verification system 50 is able to use it.
- the verification system's 50 cryptographic signature may be checked with a public key belonging to the private key in a known way.
- a hash of the signed document 90a is produced by the signing device controller 20, which hereinafter is referred to as third hash 93.
- the signing device controller 20 which hereinafter is referred to as third hash 93.
- the data (previous, protected document version, visible signature image 32', signature container 92, verification result 36, and content changes) inserted in the PDF format document 90b determine a range in the document 90b that serves for the insertion of the cryptographic signature associated with the content of the new document version (so-called byte range data element). The determined ranges will serve as the content basis of the new cryptographic signature.
- the signing device controller 20 calculates the SHA-256 hash, in other words the third hash 93 of the new document version 90b provided with the encrypted biometric identifier 34', the visible signature image 32', the original content, the content changes and the signature metadata.
- step 152 the signing device controller 20 forwards the third hash 93 via the data transfer channel 80 to the signing device 10.
- step 154 using the signing device, the third hash 93 is signed with the cryptographic signing key of the signing device 10, preferably with the private key 44a of the second asymmetric key pair 44, and in step 156 the signed third hash 93' is forwarded to the signing device controller 20, optionally along with the public part of the signing certificate of the signing device 10 (such as signing certificate according to the X.509 (v3) standard).
- step 160 using the signing device controller 20 the signed third hash 93' is concatenated to the document 90b (to the document 90a in absence of verification) provided with the biometric signature, whereby a certified, signed document 90c is created.
- This process is similar to the signing part-process presented previously, in other words a signature container 94 is created, the signature metadata (signed third hash 93', certificates 45, CRL/OCSP responses 46) are inserted therein, and it is embedded in document 90b.
- step 158 the signed third hash 93' and, preferably the certificates 45, and, preferably the CRL/OCSP responses 46 are provided with a timestamp 62.
- the signing device controller 20 sends a hash of the data through the data transfer channel 80 to the authenticated timestamp service provider 60, which creates a timestamp 62 in a known way, and sends this back to the signing device controller 20, which also concatenates the timestamp 62 to the document 90b, for example by placing the returned timestamp 62 into the signature container 94.
- the signing device controller 20 saves the newly created document 90c provided with high-security signature, with which it returns in the case of several signatories 30.
- the presented steps are repeated in such a way that the signed document 90c created as a result of the steps performed with the previous signatory 30 is used as the starting document for creating the subsequent document version contain the high-security digital signature of the subsequent signatory 30.
- absence of verification or certification document 90a or 90b, correspondingly, will be signed by the subsequent signatory 30.
- an organisation seal is applied to the initial document 87 (figure 6) and to the signed document 90a, 90b or 90c.
- the application of the organisation seal includes the application of a certified timestamp (e.g. ETSI.3161 , DocTimeStamp time stamp), as explained in the following.
- the signature-creation unit 72 receives the PDF document 87 given as input and performs the required syntactic examination of the document.
- a hash of the initial document 87 is created using the signature-creation unit 72 (e.g. with an SHA-256 algorithm, or other collision resistant, modern hash function algorithm), which in the following is referred to as hash A.
- the hash A is forwarded to the organisation seal 74 through the data transfer channel 80.
- step 204 the organisation seal 74 signs the hash A with a cryptographic signing key, which is preferably the private key 76a of the third asymmetric key pair 76, and forwards the resulting signed hash A' created in this way to the signature-creation unit 72 through the data transfer channel 80.
- the signature-creation unit 72 may also forward all the data that are required for the verification of the signature (certificates 77, CRL/OCSP responses 78). Another possibility is that the signature-creation unit 72 requests these data from elsewhere.
- step 210 the signed hash A' is concatenated to the document 87 by the the signature-creation unit 72.
- this preferably takes place by the signature-creation unit 72 creating a signature container 88 into which the signed hash A', the certificates 77 and the CRL/OCSP responses 78 are placed, then the signature-creation unit 72 embeds the signature container 88 into the document 87, in this way a new document 89 provided with an organisation seal is created, and if legalisation does not take place then this document 89 is provided with the high-security signature of one or more signatories 30.
- document 89 serves as the starting document 90.
- the hash A is preferably provided with a timestamp in such a way that in step 207 the signature-creation unit 72 sends the hash A to the external, authenticated timestamp service provider 60, which applies a timestamp to the hash A in a known way and sends it back.
- the signature-creation unit 72 receives the timestamp 64, and places this into the signature container 88 as well, then in step 210 when creating the document 89 provided with the organisation seal it concatenates the document 87 with the signature container 88 that also contains the timestamp 64.
- the process may also include legalisation (figure 7), which is performed by the legalisation unit 70.
- the signature-creation unit 72 sends the document 89 provided with the organisation seal to the legalisation unit 70 via the data transfer channel 80.
- the legalisation unit 70 creates a new hash, in the following this hash will be referred to as hash B.
- the legalisation unit 70 forwards the hash B to the timestamp service provider 60, which applies the timestamp 66 to the hash B, and then sends it back.
- the timestamp service provider 60 preferably sends the certificates 66a serving for verifying the authenticity of the timestamp 66, and the CRL/OCSP responses 66b together with the timestamp 66, which were not separately indicated in the case of the previous processes.
- the legalisation unit 70 receives the timestamp 66, and places it in a container 89a next to the hash B.
- the certificates 66a serving for verifying the authenticity of the timestamp 66, and the CRL/OCSP responses 66b are also preferably placed in the container 89a, which the timestamp service provider 60 sends along with the timestamp 66, or the legalisation unit 70 requests these from elsewhere. It was not indicated in the case of the previous timestamp processes, but the certificate chains related to the timestamps 62 and 64 are also preferably embedded along with the timestamps 62 and 64.
- the legalisation unit 70 embeds the container 89a also containing the timestamp 66 into the document 89, thereby creating the document 90 to be signed by the signatory 30, which in this case is a legalised document also provided with an organisation seal.
- the legalisation process described above may also be performed by the signature-creation unit 72 instead of the legalisation unit 70.
- Two-cycle time-stamping is necessary if it is necessary to precisely define the time when the organisation seal was created.
- the document 90c provided with the high-security digital signature of one or more signatories 30 is again provided with an organisation seal (and preferably with a certified timestamp forming a part of it), and is optionally legalised in accordance with the embodiment described in connection with figures 6 and 7.
- an organisation seal and preferably with a certified timestamp forming a part of it
- the document 90a is provided with a further organisation seal.
- the first step is the application of the organisation seal and the one or more timestamps.
- Supplementary content changes are permitted between the individual signatures (e.g. the checking of check boxes, insertion of new content, etc.), but only in such a way that does not interfere with the previously signed content that is protected by the previous signatures. In practice this means that it is possible to create new document objects, and these changes can be definitely indicated by the display programs.
- the process places a further organisation certificate signature and one or more timestamps on the document, thereby ensuring the integrity of the content, and certifying the time of providing the biometric signatures.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Software Systems (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Storage Device Security (AREA)
Abstract
The object of the invention relates to a method for the creation of a document with a high-security digital signature, characterised by that the following steps are performed: a) creating a first hash (91) of a document (89, 90) to be signed with a signature device controller (20), b) forwarding the first hash (91), and data set suitable for visually displaying the document (89, 90) to a signing device (10), c) displaying the image (90') of the document (89, 90) for a signatory (30) using the signing device (10), d) recording the biometric signature (32) of the signatory (30) with the signing device (10), e) extracting a biometric identifier (34) containing biometric data from the biometric signature (32) using the signing device (10), f) encrypting the biometric identifier (34) using the signing device (10) g) producing a second hash (82) from the encrypted biometric identifier (34') using the signing device (10), h) concatenating the first hash (91) and the second hash (82) using the signing device (10), and creating a concatenated hash (83), i) signing the concatenated hash (83) with the cryptographic signing key stored in the signing device (10) using the signing device (10), in this way creating a signed concatenated hash (84), j) forwarding the encrypted biometric identifier (34') and the signed concatenated hash (84) to the signing device controller (20), k) concatenating the document (89, 90), the encrypted biometric identifier (34') and the signed concatenated hash (84) to create a signed document (90a, 90b, 90c) using the signing device controller (20).
Description
Method for the creation of a document provided with a high- security digital signature
The object of the invention relates to a method for the creation of a document with a high-security digital signature.
Today paperless administration and legal transactions are gaining increased importance, an essential condition of this, however, is providing digital documents with digital signatures. High-security digital signatures have to meet numerous security requirements in the interest of preventing signature forging and the subsequent manipulation of the signed digital document. These include ruling out the possibility of others being able to place the signatory's digital signature on the digital document, and the changing of the content of the document after it has been signed in such a way as if the given amendment had been present at the time of signing. A solution for the former is the use of a biometric signature. Biometric data is data that codes certain physiological or behavioural characteristics of the user (such as data relating to fingerprint, iris image, handwritten signature). Biometric data is extremely difficult to forge, and a digital signature containing such data can be linked to the signatory user.
The subsequent amendment of digital documents is usually ruled out by creating a so-called hash. A hash is a compressed data package created by a hash generator algorithm (such as SHA-256) from a digital document, and from which it is impossible to reconstruct the original digital document. A unique feature of hash-generating algorithms is that changing any part of the original digital document produces an avalanche-like effect in the hash, due to which it completely changes. As a result, re-generating the hash is suitable for checking if any change has been made in the digital document, in other words it is suitable for ensuring the integrity of the document.
Patent number US 7,024,562 discloses a digital signing process that combines the use of a biometric identifier and a hash. However, a problem may be presented by the fact that the biometric identifier (fingerprint in the present case) needs to be recorded using a separate hardware device, which, however, does not
encrypt the data recorded or create a hash from it. The document's hash and the biometric identifier's hash are generated at the same time by the same software component, which, on the one hand, makes the system vulnerable, and on the other hand, it cannot be ensured that the biometric identifier was actually destined for the signed document. A further disadvantage is that in the case of the suspicion of unauthorised intervention, the hardware on which the biometric identifier was recorded cannot be subsequently traced.
In the following, in the context of the invention, high-security digital signature is understood to mean a digital signature that satisfies the following requirements:
- it can only be linked to the signatory;
- it can be used for identifying the signatory;
- it is created using data used to generate a digital signature that with great reliability only the signatory herself can use;
- it is linked to the data signed with it in a way that all subsequent changes to the data may be detected.
The objective of the invention is the provision of a high-security digital signature that meets the above requirements and that is free of the disadvantages of the solutions according to the state of the art.
The above objective is achieved by the method according to claim 1 .
The preferred embodiments of the invention are specified in the dependent claims.
Further details of the invention will be explained by way of exemplary embodiments with reference to figures, wherein:
Figure 1 depicts a schematic block diagram of the entities participating in the method according to the invention,
Figures 2 and 3 depict a schematic flow diagram illustrating the steps of placing a digital handwritten signature,
Figure 4 depicts a schematic flow diagram illustrating the signature verification steps,
Figure 5 depicts a schematic flow diagram illustrating the steps of authenticating the signature,
Figure 6 depicts a schematic flow diagram illustrating the steps of providing an organisation seal, and
Figure 7 is a schematic flow diagram illustrating the steps of the legalisation of an organisation seal with a timestamp.
The following terms are understood to mean the following during the presentation of the method according to the invention:
Signature-creating data: unique data that the signatory uses to create the digital signature, here this may be broken down into three different subtypes:
- signing with an organisation's certificate, in other words signing performed with an encrypted key belonging to the organisation's certificate when applying the organisation's stamp, the certificate's metadata (certificate identifier, organisation name, duration of validity, identifier of signing certificate), the current time - using a timestamp - and the hash of the signed content,
- in the case of timestamps the certificate of the timestamp, with metadata, the signature performed with the associated encrypted key, the current time and the hash of the signed content,
- in the case of a signature created with a signing device, the certificate of the device, with metadata, the associated signature performed with the encrypted key stored in the signing device, the image of the handwritten signature, the biometric data sampled from the handwritten signature, the hash of the signed content, and optionally the current time in the form of a timestamp.
Biometric data: digitally recorded data extracted from a biometric signature coding the physiological or behavioural characteristics of a natural person.
Biometric signature: a digitally recorded sample linked to a natural person carrying the physiological and/or behavioural characteristics of a natural person (such as handwritten signature, fingerprint, iris image, voice sample).
Biometric identifier, a biometric data set extracted from the biometric signature for the identification of the natural person.
CRL and OCSP responses: the CRL (Certificate Revocation List) is the offline version of certificate revocation lists, the OCSP (Online Certificate Status
Protocol) responses contain revocation information relating to the given moment in time downloaded from the online version of the certificate revocation lists.
Digital signature: digital data or document logically associated to a digital document for the purpose of identification and inseparably connected to it. The digital signature is characteristically created through processes that include cryptographic methods, therefore it is also referred to as a cryptographic signature (PKI signature).
Digital signature verification: comparing the content of a digital document when it was signed with when it was verified, furthermore the identification of the signatory person with the use of signature verification data appearing in the document, or published by a verification service provider, and with the use of the certificate and derived data (e.g. CRL, OCSP responses).
High-security digital signature: a digital signature that meets the following requirements:
- it can only be linked to the signatory;
- it can be used for identifying the signatory;
- it is created using data used to generate a digital signature that with great reliability only the signatory herself can use;
- it is linked to the data signed with it in a way so that all subsequent changes to the data can be detected.
Handwritten signature: handwritten signature produced by a natural person.
Certificate: a certificate issued by a verification service provider that links the signature verification data to a natural person or organisation, and certifies its validity.
Figure 1 depicts a block diagram of the entities participating in a preferred embodiment of the method according to the invention. At least three entities take part in the signing process, signing device 10, signing device controller 20 and signatory 30.
The signatory 30 is the natural person whose signature is recorded with the signing device 10 during the signing process, which signature, in the present case, is a handwritten signature, but in other embodiments it may be a fingerprint or other biometric signature.
In the case of the present embodiment the signing device 10 is a signature pad 10', which preferably has a display 12 and a digital pen 14 serving for inputting the handwritten signature. For example Signotec Omega, Signotec Gamma, or Signotec Delta signature pads 10' can be used, on which the software serving for implementing the processes according to the invention is installed. Naturally, other types of signing device 10 may be used, for example, if instead of a handwritten signature, signing is to take place with a fingerprint then there is no need for a pen 14, however a fingerprint reader will be required. Optionally a smartphone provided with a fingerprint reader may also be used as fingerprint reader signing device 10. Naturally, the recording of a handwritten signature may take place in other ways, for example the user may use her finger instead of a pen 14 to draw her signature on the display 12 provided in the form of a touch screen. The signing device 10 must have hardware and software components that correspond to the biometric signature, therefore its structure may significantly deviate from the structure of the signature pad 10' presented here as an example, as is obvious for a person skilled in the art.
At least one encryption key and at least one signing key are used in the signing process implemented with the signing device 10. Preferably RSA asymmetrical key pairs are used for both encryption and signing.
Although the present specification discusses the private and public keys of asymmetric key pairs, it is well known that certificates issued by a certification service provider may be linked to these keys. In this case attaching the encryption and the signing certificates are understood to be included in the process of encryption and signing with such keys, in the interest of verifying the identity of the encrypting and signing entities.
The encryption key is preferably a public key 40b of an asymmetric key pair 40, which is stored in a non-volatile data store 15 of the signing device 10, preferably along with the certificate belonging to the public key 40b. The asymmetric key pair 40 may be, for example, a 2048-bit RSA key pair, and the certificate belonging to the public key 40b may be an X.509 standard certificate.
The private key 40a of the asymmetric key pair 40 permitting the decryption may be accessed from a protected, non-volatile external data store 43 (such as a USB drive stored in a safe, in a p12 software container, or in an HSM
(Hardware Security Module) preferably in an X.509 v3 compatible format). In addition the private key 40a is also present in a verification system 50, or accessible to the verification system 50, which performs the verification of the biometric signatures as will be disclosed later on.
The signing key is preferably the private key 44a of a second asymmetric key pair 44, which is also stored in the data store 15 of the signing device 10. The second asymmetric key pair 44 is preferably generated within the signing device 10, and cannot be extracted from the signing device 10 without causing damage to it. The signing device 10 issues the public key 44b of the second asymmetric key pair 44 preferably as a part of the signing certificate used during signing. Another possibility is that the public key 44b may be stored in any device that may be needed for verifying the signature, or in a location from where the public key 44b required for verification can be accessed.
The signing device controller 20 is preferably established as a separate hardware device, for example, it may be a personal computer, mobile device or a server on which the software serving for implementing the processes according to the invention is installed.
An external authenticated timestamp service provider 60 and a legalisation unit 70, to be described later on, also participate in the creation of the document provided with a high-security signature.
The timestamp service provider 60 is preferably an authenticated service provider independent of the organisation, which service provider 60 supplies a data set requiring a timestamp with a precise timestamp and a cryptographic signature in the course of rendering the timestamp service. The timestamp protocol may be a protocol in accordance with the RFC 3161 standard, and the cryptographic signature may be, for example, an RSA-2048 or RSA-4096 signature.
In the case of a possible embodiment of the method according to the invention the document provided with a high-security signature is created within the framework of an organisation (such as a firm of solicitors, bank, public utility service provider, telecommunications service provider, etc.). In this case the implementation of the method according to the invention also involves the participation of a signature-creation unit 72 and an organisation seal 74.
The signature-creation unit 72 is a process, or device i.e. the combination of a software program, software application and hardware (such as a server and a program running on it). The signature-creation unit 72 handles the document to be signed, and controls the appropriate processes of the cryptographic signature.
The organisation seal 74 is a software component (or a combination of hardware and software) that is able to provide a hash with a signature using methods that are predefined using a signing key belonging to an organisation certificate.
The cryptographic signing key of the organisation seal 74 is preferably the private key 76a of a third asymmetric key pair, which is stored by the organisation seal 74, or stored elsewhere, but which is only accessible to the organisation seal 74. The private key 76a may be, for example, an RSA-2048 or RSA-4096 key. The public key 76b of the third asymmetric key pair 76 may be stored in any device that may be needed for verifying the signature, or in the location from where the public key 76b required for verification is to be made accessible, or it may be embedded in the signed data set upon signing in the form of a signing certificate.
The signature-creation unit 72 and the organisation seal 74 may even be components of a single computer process, but are preferably separate.
The timestamp service provider 60 preferably operates within the frame of an independent organisation, thus having separate hardware and software.
The entities illustrated in figure 1 (excluding the signatory) communicate with each other via data transfer channel 80. The data transfer channel 80 may be a fixed-line or wireless (e.g. WiFi, Bluetooth) connection or even a combination of these. The data transfer channel 80 is also understood to mean the physical transfer medium, in other words the hardware components participating in the structure of the communication channel (e.g. cables, connectors, signal generators, amplifiers, etc.), and a (typically encrypted) logical channel established in a multiplexed medium (e.g. computer network). During the method the data transfer channel 80 may be dynamically established and terminated, for example, the data transfer channel 80 may be logically and/or physically terminated between two entities, then established once again, if several communication steps are required.
In the following the method according to the invention is presented with the help of the flow diagrams shown in figures 2 to 7. In the interest of easier comprehension the individual steps have been marked with numbers, the numbers, however, do not represent sequence, in other words the steps with lower numbers do not necessarily precede steps with higher numbers, unless this follows from the nature of the given steps.
In the case of the present embodiment in step 100 the signing device controller 20 visible in figure 2 receives a document 90 to be signed as input, preferably in PDF format, but naturally such embodiments are also conceivable wherein the document 90 is created by the signing device controller 20.
In step 102 a cryptographic hash of the document 90 to be signed is created using the signing device controller 20, which henceforward will be referred to as first hash 91 . The creation of the first hash 91 may take place with a known algorithm, such as the SHA-256 algorithm, but naturally any other preferably collision resistant, modern (allowing fast execution) hash function algorithm may be used as well.
In step 104 the signing device controller 20 forwards the first hash 91 to the signing device 10. If the signing device controller 20 and the signing device 10 are separate physical devices, then this takes place via the data transfer channel 80 established between the signing device controller 20 and the signing device 10. Simultaneously or at a different time, in step 108 the signing device controller 20 also sends the data set suitable for visually displaying the document 90 to be signed, which may be, for example, the PDF format document 90 itself, but it is also conceivable that instead of the entire document only the image 90' displaying the vicinity of the content to be signed is forwarded. In the latter case preferably the signing device controller 20 creates the image 90' displaying the vicinity of the content to be signed in step 106, which preferably is of a size and definition corresponding to the display 12 of the signing device 10, therefore the entire content thereof may be displayed on the signing device 10.
In step 1 10 the image 90' of the document 90 is displayed for the signatory
30 using the signing device 10.
At this point after reading the information appearing on the display 12 of the signing device 10 the signatory 30 provides her biometric signature 32, while in
step 1 12 the signatory's 30 biometric signature 32 is recorded using the signing device 10. In the case of the present embodiment this takes place by the signatory 30 using the pen 14 connected to the signing device 10 to place her handwritten signature on the display 12 of the signing device 10 provided in the form of a touch screen, and this handwritten signature serves as the biometric signature 32.
In the case of the use of a fingerprint the signing device's 10 fingerprint reader records the fingerprint functioning as the biometric signature 32. In the case of other biometric signatures 32 the sensor corresponding to the biometric signature 32 records the signature. The various types of biometric signature 32 may also be combined.
It is preferably made possible to select the vicinity of the signature position on the displayed image 90' on the display 12 of the signing device 10 provided in the form of a signature pad 10' (zooming in, zooming out, displaying suitable information), whereby it becomes possible for the signatory 30 to be aware of the content she is signing at the moment of signing.
The signing process is preferably of a nature that if the signatory so decides, she has the opportunity to interrupt the signing process, and restart it. Furthermore, the system ensures that the signature is not accepted in the case of too little data being entered (such as one or two strokes when recording a handwritten signature).
During the signing process in step 1 14 a biometric identifier 34 containing biometric data is extracted from the recorded biometric signature 32 using the signing device 10. Preferably the biometric identifier 34 is a high-resolution (sampled at high frequency) biometric data set produced from the recorded data. In the case of a handwritten signature the biometric data of the biometric identifier 34 may code other information in addition to the image information, such as the speed of the pen strokes with respect to the individual points of the signature, and the pressure exerted.
In the case of a particularly preferred embodiment the biometric identifier 34 is supplemented with the first hash 91 of the document 90 (marked with a dotted line), in this way the biometric identifier 34 itself is linked to the signed document 90.
Preferably in step 1 16 (figure 3) a second data set is produced from the biometric signature 32 using the signing device 10, which is a low-resolution (sampled at low frequency) data set suitable for being displayed as an image, from which a visible signature image 32' of the biometric signature 32 (handwritten signature in the present case) can be produced. If the low-resolution data (i.e. the signature image 32') serving for displaying the biometric signature 32 as an image is also forwarded, the signing device controller 20 uses this visible signature image 32' (or an image generated from it). It should be noted that certain types of biometric signatures 32 (such as handwritten signature, fingerprint) are suitable for being displayed as an image, and others (such as a voice sample) are not. In the latter case instead of displaying an image of the biometric signature 32, the fact of signing can be illustrated in other ways on the document 90, for example the signatory's 30 name is indicated on it. Naturally other data in connection with the fact of signing may be placed in the document 90 in legible form, such as the first hash 91 , or its first few characters, or the date, place of signing.
After the biometric identifier 34 has been extracted the biometric identifier 34 is encrypted in step 1 18. Preferably the public key 40b of the first asymmetric key pair 40 is used for encryption. An asymmetric encryption is a very compute intensive task, it is only worthwhile using it for short data sets. In the case of large data sets, such as the biometric identifier 34, symmetric encryption may be used suitably quickly and effectively. Due to this the two types of encryption are preferably combined, and in such a way that the private key 40a of the asymmetric key pair is needed for decryption. This is achieved by generating a temporary symmetric key using the signing device 10 (e.g. by using symmetrical code generation according to the AES-256-CBC standard), and then the biometric identifier 34 is encrypted with this temporary symmetric key. The symmetric key is then encrypted with the public key 40b of the first asymmetric key pair 40, and is sent to the signing device controller 20 along with the encrypted biometric identifier 34' (simultaneously or at a separate time) in step 1 19. In this way the encrypted biometric identifier 34' cannot be decoded on the receiving side without the private key 40a of the first asymmetric key pair 40.
In step 120 a hash of the encrypted biometric identifier 34' is produced using the signing device 10, which is referred to hereinafter as second hash 82.
This second hash 82 may only and exclusively be created within the signing device 10 on the basis of the encrypted biometric identifier 34', it cannot enter the process in any other way, which increases the security of the method according to the invention even further.
In step 121 the first hash 91 and the second hash 82 are concatenated using the signing device 10 and then signed in step 122 (figure 3) with the cryptographic signing key stored in the signing device 10, whereby a signed hash 84 is created. The signing key is preferably the private key 44a of the second asymmetric key pair 44 generated in the signing device 10.
In step 124 the signed hash 84 created with the signing is forwarded with the help of the signing device 10 to the signing device controller 20 through the data transfer channel 80. The forwarding of the signed hash 84 may take place simultaneously with the forwarding of the encrypted biometric identifier 34' (step 1 19), in a joint data package, or separately before or afterwards.
If the signing device 10 created a signature image 32' from the biometric signature 32 then in step 126 this signature image 32' is also transmitted to the signing device controller 20. Step 126 may also take place simultaneously with the other data transferring steps 1 19, 124, or separately from them, in any sequence.
The encrypted biometric identifier 34' (optionally including the the symmetric key required for decryption, which has been encrypted with the asymmetrical coder) and the signed first and second (optionally concatenated) hash 84 are received by the signing device controller 20.
In step 128, using the signing device controller 20, the document 90 to be signed is concatenated with the encrypted biometric identifier 34' and the signed first and second hash 84, optionally in step 130 also with the signature image 32' of the biometric signature 32 or an image corresponding to other encrypted biometric identifier. In this way a signed document 90a provided with a high- security digital signature is created, which may be the final signed document, but, preferably, further steps are performed on it that increase security.
It is to be noted that the sequence of steps 128, 130 is optional, optionally the two concatenating processes may be carried out in a single step.
In the case of a PDF document 90, signing takes place according to the following. The signing device controller 20 creates a new document version in the
PDF document 90 to be signed, then it creates therein a signature container 92 and the visible signature image (signature image 32') in the form of PDF objects.
In the case of a preferred embodiment it is permitted to make changes to the content (e.g. checking check boxes, inserting new content) in the document 90 before signing. In this case the content changes are also included in the new document version.
According to the DSS (Digital Signal Standard) the signature container 92 contains data related to encryption, such as the encrypted biometric identifier 34', the hash 84 signed by the signing device 10, as well as numerous data packages serving to satisfy the conditions of LTV (Long Term Validation) support. The latter include certificates 45 and certificate chains as well as CRL/OCSP responses 46.
In the case of a preferred embodiment of the method according to the invention the biometric identifier 34 is checked with the verification system 50 (figure 4). To allow this, in step 132 the received encrypted biometric identifier 34' is forwarded using the signing device controller 20 through the data transfer channel 80 to the verification system 50. The verification system 50 preferably has access to the private key 40a of the asymmetric key pair 40 used for the encryption, with which in step 134 the encrypted biometric identifier 34' is decrypted, or the encrypted biometric identifier 34' may be decrypted with an independent HSM module if the private key 40a is stored there. Following this, in step 136 the verification system 50 analyses the biometric identifier 34 for the purpose of extracting one or more biometric signature verification data (for example, it determines various characteristics). Following this, in step 138, the verification system 50 compares the result of the analysis, in other words the extracted one or more biometric verification data is compared to one or more biometric verification data extracted from at least one of the alleged signatory's 30 previous biometric identifiers 34. Accordingly, on the basis of the prior data registered in the verification system 50, it can be determined whether or not the signature in question was created by the alleged signatory 30, also, the probability of this may be determined to the extent of the similarity. The biometric signature verification data serving as a reference is such that it does not permit the reconstruction of the biometric identifier 34, therefore the user's signature cannot be forged by its unauthorised extraction.
The one or more signature verification data serving as reference may be created in the verification system 50 from the user's sample signature registered before first use. Optionally the verification system 50 verifies the identity of the signatory 30 using one or more (biometric) verification data published by a verification service provider and the (biometric) certificate related to it. In this case also the biometric verification data are unique data extracted from one or more biometric identifiers that the person examining the digital document uses to perform a high-reliability verification of the biometric signature. The biometric certificate is a certification issued by the verification service provider that links the biometric verification data to a natural person and certifies its validity.
Using the verification system 50 the data set containing the result of the comparison, in other words a verification result 36, is forwarded in step 139 to the signing device controller 20, which in step 140 also links the verification result 36 to the document 90 (preferably to the previously created document 90a containing the signature container 92 and the signature image 32). In the case of a preferred embodiment the signing device controller 20 also embeds the verification result 36 into the PDF document 90a as described above, and as a result of this a new document 90b is created, which contains further security elements as compared to the previous document 90a.
In the case of a preferred embodiment the verification result 36 may contain a cryptographic signature created using a further private key and the associated certificate, which cryptographic signature can only be created by the verification system 50. This can be ensured e.g. such that the verification system 50 stores this private key or such that the private key is stored in an external HSM and the verification system 50 is able to use it. The verification system's 50 cryptographic signature may be checked with a public key belonging to the private key in a known way.
In the case of a preferred embodiment in step 150 a hash of the signed document 90a, preferably the signed and verified document 90b, is produced by the signing device controller 20, which hereinafter is referred to as third hash 93. In practice this may take place as follows. The data (previous, protected document version, visible signature image 32', signature container 92, verification result 36, and content changes) inserted in the PDF format document 90b determine a range
in the document 90b that serves for the insertion of the cryptographic signature associated with the content of the new document version (so-called byte range data element). The determined ranges will serve as the content basis of the new cryptographic signature. On the basis of the data of these ranges, the signing device controller 20 calculates the SHA-256 hash, in other words the third hash 93 of the new document version 90b provided with the encrypted biometric identifier 34', the visible signature image 32', the original content, the content changes and the signature metadata.
In step 152 the signing device controller 20 forwards the third hash 93 via the data transfer channel 80 to the signing device 10. In step 154, using the signing device, the third hash 93 is signed with the cryptographic signing key of the signing device 10, preferably with the private key 44a of the second asymmetric key pair 44, and in step 156 the signed third hash 93' is forwarded to the signing device controller 20, optionally along with the public part of the signing certificate of the signing device 10 (such as signing certificate according to the X.509 (v3) standard).
In step 160 using the signing device controller 20 the signed third hash 93' is concatenated to the document 90b (to the document 90a in absence of verification) provided with the biometric signature, whereby a certified, signed document 90c is created. This process is similar to the signing part-process presented previously, in other words a signature container 94 is created, the signature metadata (signed third hash 93', certificates 45, CRL/OCSP responses 46) are inserted therein, and it is embedded in document 90b.
Optionally, in step 158 (marked with a dotted line) before the certified, signed document is created the signed third hash 93' and, preferably the certificates 45, and, preferably the CRL/OCSP responses 46 are provided with a timestamp 62. For this purpose, preferably the signing device controller 20 sends a hash of the data through the data transfer channel 80 to the authenticated timestamp service provider 60, which creates a timestamp 62 in a known way, and sends this back to the signing device controller 20, which also concatenates the timestamp 62 to the document 90b, for example by placing the returned timestamp 62 into the signature container 94.
Finally, the signing device controller 20 saves the newly created document 90c provided with high-security signature, with which it returns in the case of several signatories 30. In this case the presented steps are repeated in such a way that the signed document 90c created as a result of the steps performed with the previous signatory 30 is used as the starting document for creating the subsequent document version contain the high-security digital signature of the subsequent signatory 30. In absence of verification or certification document 90a or 90b, correspondingly, will be signed by the subsequent signatory 30.
In the case of a further preferred embodiment of the method according to the invention, before signing the document 90 by the signatory 30, and, preferably after the signing has taken place, an organisation seal is applied to the initial document 87 (figure 6) and to the signed document 90a, 90b or 90c. Preferably the application of the organisation seal includes the application of a certified timestamp (e.g. ETSI.3161 , DocTimeStamp time stamp), as explained in the following.
Preferably the signature-creation unit 72 receives the PDF document 87 given as input and performs the required syntactic examination of the document.
In step 200 a hash of the initial document 87 is created using the signature-creation unit 72 (e.g. with an SHA-256 algorithm, or other collision resistant, modern hash function algorithm), which in the following is referred to as hash A. In step 202 the hash A is forwarded to the organisation seal 74 through the data transfer channel 80.
In step 204 the organisation seal 74 signs the hash A with a cryptographic signing key, which is preferably the private key 76a of the third asymmetric key pair 76, and forwards the resulting signed hash A' created in this way to the signature-creation unit 72 through the data transfer channel 80. Along with this the signature-creation unit 72 may also forward all the data that are required for the verification of the signature (certificates 77, CRL/OCSP responses 78). Another possibility is that the signature-creation unit 72 requests these data from elsewhere.
In step 210 the signed hash A' is concatenated to the document 87 by the the signature-creation unit 72. In the case of a PDF document 87 this preferably takes place by the signature-creation unit 72 creating a signature container 88 into
which the signed hash A', the certificates 77 and the CRL/OCSP responses 78 are placed, then the signature-creation unit 72 embeds the signature container 88 into the document 87, in this way a new document 89 provided with an organisation seal is created, and if legalisation does not take place then this document 89 is provided with the high-security signature of one or more signatories 30. In this case document 89 serves as the starting document 90.
For a high-security digital signature the hash A is preferably provided with a timestamp in such a way that in step 207 the signature-creation unit 72 sends the hash A to the external, authenticated timestamp service provider 60, which applies a timestamp to the hash A in a known way and sends it back. In step 208 the signature-creation unit 72 receives the timestamp 64, and places this into the signature container 88 as well, then in step 210 when creating the document 89 provided with the organisation seal it concatenates the document 87 with the signature container 88 that also contains the timestamp 64.
The process may also include legalisation (figure 7), which is performed by the legalisation unit 70. In step 212 the signature-creation unit 72 sends the document 89 provided with the organisation seal to the legalisation unit 70 via the data transfer channel 80. In step 214 the legalisation unit 70 creates a new hash, in the following this hash will be referred to as hash B. In step 216 the legalisation unit 70 forwards the hash B to the timestamp service provider 60, which applies the timestamp 66 to the hash B, and then sends it back. The timestamp service provider 60 preferably sends the certificates 66a serving for verifying the authenticity of the timestamp 66, and the CRL/OCSP responses 66b together with the timestamp 66, which were not separately indicated in the case of the previous processes.
In step 218 the legalisation unit 70 receives the timestamp 66, and places it in a container 89a next to the hash B. The certificates 66a serving for verifying the authenticity of the timestamp 66, and the CRL/OCSP responses 66b are also preferably placed in the container 89a, which the timestamp service provider 60 sends along with the timestamp 66, or the legalisation unit 70 requests these from elsewhere. It was not indicated in the case of the previous timestamp processes, but the certificate chains related to the timestamps 62 and 64 are also preferably embedded along with the timestamps 62 and 64.
In step 220 the legalisation unit 70 embeds the container 89a also containing the timestamp 66 into the document 89, thereby creating the document 90 to be signed by the signatory 30, which in this case is a legalised document also provided with an organisation seal.
Optionally the legalisation process described above may also be performed by the signature-creation unit 72 instead of the legalisation unit 70.
Two-cycle time-stamping is necessary if it is necessary to precisely define the time when the organisation seal was created.
In the case of a particularly preferred embodiment of the method according to the invention the document 90c provided with the high-security digital signature of one or more signatories 30 is again provided with an organisation seal (and preferably with a certified timestamp forming a part of it), and is optionally legalised in accordance with the embodiment described in connection with figures 6 and 7. Naturally in absence of certification the document 90, and in absence of verification and certification the document 90a is provided with a further organisation seal. In this way at the beginning of a process aimed at the creation of a document provided with a high-security digital signature an organisation seal and a timestamp are applied, and then this is optionally legalised, then the biometric signature of the one or more signatories is applied to the document, then at the very end a further organisation seal and timestamp are applied, and, optionally, legalisation may also be carried out thereby significantly increasing the security of the signing process.
During the entire signing process the digitised handwritten and the digital cryptographic signatures are applied to the initial document 87 in several steps, by separate sub-processes.
The order of the entire process and of the sub-processes is set, and is as follows:
1 . In the interest of protecting the integrity of the content of the document and linking it to a point in time the first step is the application of the organisation seal and the one or more timestamps.
2. This is followed by the application of the biometric and cryptographic signatures and timestamps in the order of the signatories 30. The process must be repeated as many times as the number of
signatories 30 are required to provide their signatures on the given document.
3. Supplementary content changes are permitted between the individual signatures (e.g. the checking of check boxes, insertion of new content, etc.), but only in such a way that does not interfere with the previously signed content that is protected by the previous signatures. In practice this means that it is possible to create new document objects, and these changes can be definitely indicated by the display programs.
4. As the final, closing step the process places a further organisation certificate signature and one or more timestamps on the document, thereby ensuring the integrity of the content, and certifying the time of providing the biometric signatures.
Accordingly, as a result of the sub-processes following each other the document will contain the results of the previous steps embedded therein, like the layers of an onion.
Various modifications to the above disclosed embodiments will be apparent to a person skilled in the art without departing from the scope of protection determined by the attached claims.
Claims
1. Method for the creation of a document provided with a high-security digital signature, characterised by that the following steps are performed:
a) creating a first hash (91 ) of a document (89, 90) to be signed with a signing device controller (20),
b) forwarding the first hash (91 ), and data set suitable for visually displaying the document (89, 90) to a signing device (10),
c) displaying an image (90') of the document (89, 90) for a signatory (30) with the signing device (10),
d) recording a biometric signature (32) of the signatory (30) with the signing device (10),
e) extracting a biometric identifier (34) containing biometric data from the biometric signature (32) using the signing device (10),
f) encrypting the biometric identifier (34) with the signing device (10), g) creating a second hash (82) from the encrypted biometric identifier (34') with the signing device (10),
h) concatenating the first hash (91 ) and the second hash (82) using the signing device (10), and creating a concatenated hash (83),
i) signing the concatenated hash (83) with a cryptographic signing key stored in the signing device (10) using the signing device (10), thereby creating a signed concatenated hash (84),
j) forwarding the encrypted biometric identifier (34') and the signed concatenated hash (84) to the signing device controller (20),
k) concatenating the document (89, 90), the encrypted biometric identifier
(34') and the signed concatenated hash (84) to create a signed document (90a,
90b, 90c).
2. Method according to claim 1 , characterised by providing an organisation seal on the initial document (87) before the signatories (30) sign the document (89, 90) by
- creating a hash (hash A) of the initial document (87) using a signature- creation unit (72) and forwarding it to an organisation seal (74),
- signing the hash A with the private key (76a) of the organisation seal (74) using the organisation seal (74), and forwarding the signed hash A to the signature-creation unit 72,
- concatenating the signed hash A to the initial document (87) using the signature-creation unit (72), in this way creating a document (89) provided with an organisation seal (74),
and using the document (89) provided with the organisation seal (74) in steps a) to k).
3. Method according to claim 2, characterised by that before the creation of the document (89) provided with the organisation seal (74), providing the hash A with a timestamp (64) using the signature-creation unit (72), preferably by sending the hash A to an attested timestamp service provider (60), then when creating the document (89) provided with the organisation seal concatenating the hash A provided with the timestamp (64) also to the document (87).
4. Method according to claim 2 or 3, characterised by legalising the document (89) provided with the organisation seal using the signature-creation unit (72) or a separate legalisation unit (70), by
- creating a hash (hash B) of the document (89) provided with the organisation seal,
- providing the hash B with a timestamp (64), preferably by sending the hash B to an external, attested timestamp service provider (60), then concatenating the hash B provided with the timestamp (64) to the document (89) provided with the organisation seal, and
- using the document (90) created in this way in steps a) to k).
5. Method according to any of claims 1 to 4, characterised by providing the signed document (90a, 90b, 90c) with an organisation seal by
- creating a hash of the signed document (90a, 90b, 90c) with the signature-creation unit (72) and sending it to the organisation seal (74),
- signing the hash of a signed document (90a, 90b, 90c) with the private key (76a) of the organisation seal (74) using the organisation seal (74), and forwarding the signed hash to the signature-creation unit (72),
- concatenating the signed hash to the signed document (90a, 90b, 90c) using the signature-creation unit (72), in this way creating a signed document provided with an organisation seal.
6. Method according to claim 5, characterised by that before creating the signed document provided with the organisation seal providing the hash of the signed document (90a, 90b, 90c) with a timestamp (64) using the signature- creation unit (72), preferably by sending the hash of the signed document (90a, 90b, 90c) to an external, attested timestamp service provider (60), then when creating the signed document provided with an organisation seal concatenating the hash provided with the timestamp (64) also to the signed document (90a, 90b, 90c).
7. Method according to claim 5 or 6, characterised by legalizing the signed document provided with the organisation seal using the signature-creation unit (72) or a separate legalisation unit (70) by
- creating a hash of the signed document provided with the organisation seal,
- providing the hash created in this way with a timestamp (64), preferably by sending the hash created in this way to an external, attested timestamp service provider (60), and
- concatenating the hash provided with the timestamp (64) to the signed document provided with the organisation seal.
8. Method according to any of claims 1 to 7, characterised by
- forwarding the obtained encrypted biometric identifier (34') to a verification system (50) using the signing device controller (20),
- decrypting the encrypted biometric identifier (34') using the verification system (50) then analysing it for the purpose of extracting biometric signature verification data, comparing the extracted biometric signature verification data to
the biometric signature verification data extracted from at least one of the signatory's (30) previous biometric identifiers (34),
- forwarding data set containing a result of the comparison to the signing device controller (20) using the verification system (50), optionally following signing with the cryptographic signature of the verification system (50),
- concatenating the data set containing the result of the comparison to the signed document (90a) using the signing device controller (20) thereby producing a verified signed document (90b).
9. Method according to any of claims 1 to 8, characterised by
- creating a third hash (93) from the signed document (90a, 90b) using the signing device controller (20) and forwarding it to the signing device(10),
- signing the third hash (93) with the private key (44a) of the second asymmetric key pair (44) using the signing device (10), and forwarding the signed third hash (93') to the signing device controller (20),
- concatenating the signed third hash (93') to the signed document (90a, 90b) using the signing device controller (20), thereby creating a certified signed document (90c).
10. Method according to claim 9, characterised by time-stamping the signed third hash (93') using the signing device controller (20) before creating the certified signed document (90c), preferably by sending the signed third hash (93') to an external, attested timestamp service provider (60), and concatenating the timestamp (62) also to the signed document (90a, 90b).
1 1 . Method according to any of claims 1 to 10, characterised by that in step f) encrypting the biometric identifier with a public key (40b) of the first asymmetric key pair preferably by generating a temporary symmetric key using the signing device (10) during the encryption, encrypting the biometric identifier (34) with the symmetric key, then encrypting the symmetric key with the public key (40b) of the first asymmetric key pair (40), and forwarding the encrypted symmetric key to the signing device controller (20) along with the encrypted biometric identifier (34').
12. Method according to any of claims 1 to 1 1 , characterised by creating the signing key used in step h) using the signing device (10) by generating a second asymmetric key pair (46), the private key (46a) of which is used as the signing key.
13. Method according to any of claims 1 to 12, characterised by
- extracting data set suitable for visually displaying the signature from the biometric signature (32) using the signing device (10), and then forwarding it to the signing device controller (20),
- when creating the signed document (90a, 90b) with the help of the signing device controller (20) concatenating to the document (90) a biometric signature image (32') created from the data set suitable for visually displaying the signature.
14. Method according to any of claims 1 to 13, characterised by that in the case of several signatories (30) repeating the steps per signatory (30) and using the signed document (90a, 90b, 90c) created as a result of the steps performed with the previous signatory (30) when performing the steps a) to k) for the subsequent signatory (30).
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
HUP1700214 | 2017-05-18 | ||
HUP1700214 HUP1700214A2 (en) | 2017-05-18 | 2017-05-18 | Method for creating documents with enhanced security electronic signature |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2018211475A1 true WO2018211475A1 (en) | 2018-11-22 |
Family
ID=89992448
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/IB2018/053528 WO2018211475A1 (en) | 2017-05-18 | 2018-05-18 | Method for the creation of a document provided with a high-security digital signature |
Country Status (2)
Country | Link |
---|---|
HU (1) | HUP1700214A2 (en) |
WO (1) | WO2018211475A1 (en) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
IT201900004201A1 (en) * | 2019-03-22 | 2020-09-22 | Carlo Tenca | Method for creating a register of certified public documents with electronic signature |
EP4152184A1 (en) | 2021-09-17 | 2023-03-22 | Freshape SA | Process of signing documents |
EP3998742A4 (en) * | 2019-07-12 | 2023-08-09 | Muuk Technologies, S. DE R.L. DE C.V. | System for generating a digital handwritten signature using a mobile device |
EP4239509A4 (en) * | 2020-11-02 | 2024-07-24 | Le Techs Inc | Management device and program |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7024562B1 (en) | 2000-06-29 | 2006-04-04 | Optisec Technologies Ltd. | Method for carrying out secure digital signature and a system therefor |
US20110179289A1 (en) * | 2008-09-30 | 2011-07-21 | Stepover Gmbh | Method and device for electronically capturing a handwritten signature using embedding technique |
WO2012049592A2 (en) * | 2010-10-10 | 2012-04-19 | Vpsign, Ltd. | Electronic signature apparatus and method |
DE202012101671U1 (en) * | 2011-05-06 | 2012-05-25 | Signotec Gmbh | Secure electronic signing of information |
-
2017
- 2017-05-18 HU HUP1700214 patent/HUP1700214A2/en unknown
-
2018
- 2018-05-18 WO PCT/IB2018/053528 patent/WO2018211475A1/en active Application Filing
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7024562B1 (en) | 2000-06-29 | 2006-04-04 | Optisec Technologies Ltd. | Method for carrying out secure digital signature and a system therefor |
US20110179289A1 (en) * | 2008-09-30 | 2011-07-21 | Stepover Gmbh | Method and device for electronically capturing a handwritten signature using embedding technique |
WO2012049592A2 (en) * | 2010-10-10 | 2012-04-19 | Vpsign, Ltd. | Electronic signature apparatus and method |
DE202012101671U1 (en) * | 2011-05-06 | 2012-05-25 | Signotec Gmbh | Secure electronic signing of information |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
IT201900004201A1 (en) * | 2019-03-22 | 2020-09-22 | Carlo Tenca | Method for creating a register of certified public documents with electronic signature |
EP3998742A4 (en) * | 2019-07-12 | 2023-08-09 | Muuk Technologies, S. DE R.L. DE C.V. | System for generating a digital handwritten signature using a mobile device |
EP4239509A4 (en) * | 2020-11-02 | 2024-07-24 | Le Techs Inc | Management device and program |
EP4152184A1 (en) | 2021-09-17 | 2023-03-22 | Freshape SA | Process of signing documents |
WO2023041989A1 (en) | 2021-09-17 | 2023-03-23 | Freshape Sa | Process of signing documents |
Also Published As
Publication number | Publication date |
---|---|
HUP1700214A2 (en) | 2019-08-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Feng et al. | Private key generation from on‐line handwritten signatures | |
KR101710032B1 (en) | Apparatus and system for preventing product falsification based on electronic documents content and method thereof | |
EP2490366B1 (en) | A privacy-enhanced E-passport authentication protocol | |
US10547453B2 (en) | Methods for digitally signing an electronic file and authentication method | |
US10559049B2 (en) | Digital passport country entry stamp | |
US6553494B1 (en) | Method and apparatus for applying and verifying a biometric-based digital signature to an electronic document | |
WO2018211475A1 (en) | Method for the creation of a document provided with a high-security digital signature | |
US8959357B2 (en) | Biometric encryption and key generation | |
CN109600228B (en) | Anti-quantum-computation signature method and system based on public key pool | |
US20020186838A1 (en) | System and method of user and data verification | |
US20110126022A1 (en) | Method for generating an advanced electronic signature for an electronic document | |
CN107360002B (en) | Application method of digital certificate | |
CN106330454B (en) | A kind of generation method and verification method of digital certificate | |
GB2487503A (en) | Authentication of digital files and associated identities using biometric information | |
CN106713336A (en) | Electronic data safekeeping system and method based on double and asymmetric encryption technology | |
CN108540470A (en) | Verification System and method based on digital certificate label | |
EP1938505A1 (en) | Method, apparatus and system for generating a digital signature linked to a biometric identifier | |
CN116015945A (en) | Electronic file secure transmission method, system and medium based on electronic signature | |
CN110826109A (en) | Penetrating signature method suitable for PDF document | |
CN108833431A (en) | A kind of method, apparatus, equipment and the storage medium of password resetting | |
US10902242B2 (en) | Binding data to a person's identity | |
CN114329634A (en) | Anti-counterfeiting method for electronic signature document | |
CN108111311B (en) | Method for realizing bank counter electronic signature based on state cryptographic algorithm | |
EP3316162B1 (en) | Method and system for creating an electronic signature of a document associated to a person by means of the voice print of the person, and corresponding method for verifying the electronic signature | |
CN117370952A (en) | Multi-node identity verification method and device based on block chain |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 18731520 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
32PN | Ep: public notification in the ep bulletin as address of the adressee cannot be established |
Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 04.03.2020) |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 18731520 Country of ref document: EP Kind code of ref document: A1 |