IES20011070A2 - Biometrically protected electronic signatures - Google Patents

Abstract

The invention describes electronic signatures and methods and apparatus adapted to associate electronic signatures with biometric identifiers. By associating an electronic signature with a biometric identifier the invention provides for an authentication of the user of the signature and allows for assurance that the applied signature is representative of the stated user.

Description

The invention relates to electronic (e-) signatures and in particular to a method and apparatus for utilising biometric techniques with such signatures.

The term electronic signature is used throughout to indicate both symmetric key based electronic signatures and asymmetric (public key) digital signatures.

Background to the Invention Electronic signatures are well known for the protection and authentication of electronic documents. They may be thought of as electronic code attached to (or associated with) a document which a) verifies the identity of the signer of the document and b) verifies that the document as signed by the signer has not been changed since the signing took place.

One common example of electronic signatures, commonly known as a digital signature, relies on public-key cryptography and hash functions to provide this verification. It will be appreciated that within this specification that the term electronic signature refers to any signature process including symmetric and asymmetric signatures, whereas the term digital signature typically refers to an asymmetric signature.

Figure 1 shows an example of a signing process that is utilised for the application of such electronic signatures. The document to be signed is sent to a one-way hash function (Step 1) that computes a small hash that is (practically) unique to the document (Step 2). This hash the ni,, j, ......

| OPEN TO PUBLIC INSPECTION j UNDER SECTION 1« AMD RULE 23 j JNL No....13..4.S............op d has 2 key properties; firstly leeDoi® contents of the document and any change in the contents will cause a completely different hash to be generated (good hash functions result in a completely different number being generated for even a single bit change within the document), and secondly the hash is practically unique. In other words, the probability of two documents generating the same hash is extremely unlikely. This probability is a function of the size of the output hash and the distribution of the algorithm across the bits in the hash.

The hash itself is usually much smaller than the document itself. This is to allow public key encryption of it to be as fast as possible (given the processing power of some terminals and smart cards it is not currently practical to asymmetrically encrypt large documents (e.g. 1 MB of data). For a given hash algorithm, the hash output is the same size regardless of the size of the original document.

Next, the hash is sent to a signing function (Step 3). This is effectively an asymmetric encryption routine that uses the signer's private key to encrypt the hash. It should be noted that for non-repudiation, there are certain requirements for the management of the private key.

The document and the signature (which may be embedded in the document or linked to it in some fashion) are then sent to the recipient or stored (Step 4).

Figure 2 shows an example of how a signature on a document may then be verified. The signed document package comprising the document and the document signature is presented for verification (Step 20). The hash values associated with both the document and the document signature are then computed. In the case of the document signature this computation uses the public key of the signer to decrypt the signature. This decryption produces the original document hash (Step 21). The two computed hash values are then compared (Step 22). If the hash values are found to be equivalent then the document is verified as having a valid signature (Step 23) If the values are not equivalent then the signature is found invalid (Step 24).

Although these techniques are satisfactory in that they allow a level of security to be applied to documents that are transferred between two or more persons or institutions, the protected documents are still vulnerable to attack by unscrupulous persons. It will be appreciated from the explanation of how the signature is applied to a document (Figure 1) and how a document with a signature is then verified that all that is required for an unscrupulous person to impersonate the user's signature is to gain access to the private key. Furthermore, the signature is only tested against the keys themselves, there is no recourse back to ascertain the actual identity of the. user who created or owns the signature. There, therefore, exists a need for a modified technique for use in the protection of electronic documents.

Object of the Invention It is an object of the present invention to provide a method and apparatus for an improved control of electronic signature systems.

Summary of the Invention Accordingly the present invention provides for the use of biometric technologies to provide a secure layer on top of electronic signature algorithms.

The present invention enables the incorporation of a biometric identifier with a specific user's electronic signature by enabling the association of that specific identifier with the signature at the time of creation of the signature. The invention may also allow for the association of a biometric identifier with a previously created signature.

Typically a biometric identifier is based on a biometric sample presented by a user. This sample may be used as the biometric identifier itself, or may be subjected to a processing wherein specific features of the actual sample are extracted and processed so as to form a biometric template which is linkable to the originating sample. Within the present specification the term biometric identifier is intended to cover both biometric samples and templates formed from such samples.

Accordingly the present invention provides a method of associating at least one cryptographic key with at least one biometric identifier of that user as detailed in the appended claims.

The invention additionally provides a method of retrieving an electronic document as detailed in the appended claims.

The method may additionally require the additional step of requiring a new user that is presenting a biometric to be associated with a prior registered user prior to any storage of personal identifiers for the new user. In effect, the prior existing user signs the biometric enrolment of the new user using the prior user's biometric to authenticate themselves.

The present invention may optionally provide for an additional component, a biometric identifier, to be associated with the document. This it will be appreciated may be achieved by embedding a transformed biometric identifier, a biometric identifier that has undergone one or more transformations, into the document. Examples of such transformations include but are not limited to encryption using one or more keys and/or the application of a one-way function to the biometric identifier. Accordingly it will be appreciated that in this embodiment the present invention provides for the incorporation of one or more biometric identifiers within an electronic signature so as to effect an increase in security associated with that electronic signature.

It will be appreciated that the present invention, in addition to associating the electronic signature with the biometric identifier, also enables the association of the biometric identifier with the owner of the biometric identifier. To this end, a record will be retained of the nature of proof of identity provided at the time of enrolment of the biometric identifier. This will typically be implemented in a similar manner to that currently known for the provision of public key infrastructure services wherein individuals are identified at the time that they are assigned asymmetric key pairs.

It will be appreciated that the biometric identifier can be any one of a plurality of identifier types including but not limited to finger, iris, hand, face, voice and retina samples. Alternatively, as detailed above the biometric identifier may be a compact summary representation of the actual biometric sample, based on pertinent features of the particular sample. Such a summary is typically referred to as a biometric template.

These and other features of the present invention will be better understood with reference to the following drawings.

Brief Description of the Drawings Figure 1 outlines the steps associated with a traditional form of electronic signature application.

Figure 2 shows a known process for the verification of document signatures.

Figure 3 shows an enrolment process for associating a biometric identifier with a key or keys according to the present invention.

Figure 4 is a modification to the enrolment process outlined in Figure 3, in accordance with another aspect of the present invention.

Figure 5 outlines a generation process for the application of a biometrically protected electronic signature in accordance with the present invention, Figure 6 shows a process flow for a system where the document repository is not fully integrated with the authentication engine in accordance with a modification to the present invention, and Figure 7 shows a process flow for verification of a signature in applications where the key trust does not want to send key material to the verifier in accordance with an embodiment of the present invention.

Detailed Description of the Drawings Figures 1 and 2 have been previously described with reference to the prior art so as to describe the traditional mode of application of a digital or electronic signature to a document.

The present invention provides for the association of a biometric identifier with a key or keys, typically a private and public key so as to effect more secure generation and association of electronic signatures with documents.

To understand the functionality of the type of network architecture that may be realised in an implementation of a system of the present invention some of the typical components will· now be defined. These definitions are not intended to limit the present invention to the presence or otherwise of the specific components and are intended for illustrative and explanatory purposes only.

Client A client is the client software resident on the biometric device and any associated computing devices such as Personal Computers, Personal Digital Assistants (PDAs), mobile phones etc.

Authentication Engine An Authentication Engine (AE) is the entity responsible for capturing enrolments and asserting an individual's identity based on a presented biometric. The AE typically works in three modes. 1. Verification - where both a unique claim and a biometric are presented. 2. Identification - where only a biometric is presented. 3. Segregated Identification - where a partial claim (e.g. non unique claim such as date of birth or PIN) and a biometric are presented.

Biometric Reader A biometric reader is a biometric capture device. The term reader is intended to include devices suitable for reading various biometric modalities including finger, iris, voice, face etc.

Key Trust A Key Trust is a highly secure component tasked with managing the private keys of the individual enrolees. The Key Trust carries out the signing of the documents on behalf of the signers - once their identity has been properly asserted by a recognised AE. Typically, for security purposes, all signing operations are carried out in secure hardware, although it will be appreciated that this is not intended to limit the key trust application to such hardware configurations as alternatives may be apparent to those skilled in the art (for example, implementing the cryptographic routines in software).

Document A document is an object that can be signed. Documents can include traditional electronic documents in a variety of formats (e.g. text, Adobe PDF etc.) or can include items such as images, binary files etc.

Document Repository A document repository manages the documents that are being signed and optionally stores the resulting signatures.

Certificate Authority The Certificate Authority (CA) is responsible for signing the public keys for all enrolees within the scheme. A CA is also usually required to issue and sign keys used by the various components (e.g. AE) which sign responses.

It should be noted that a separate CA is not required in the scheme, and this is particularly applicable in certain applications of the method of the present invention where the issuance of a certificate may not be required. It is generally used if there are further applications which want to carry out verification of the biometrically protected digital signatures. In many cases, if the system outlined here is the only system required to validate the signatures, then the external CA may not be required - the authenticity of the keys being asserted by the Key Trust itself.

Enrolment Application An application that captures the enrolment information for a new enrolee. This may be a separate component related to the authentication engine or it may be a callable component integrated with a trusted partner application (for example a document management engine).

Utilising such architecture components it is possible for a user to be enrolled to use such a system according to the present invention, although it will be appreciated that such illustrated components are exemplary of the type of system architecture that may be utilised. The present invention provides a method of associating an electronic signature with a specific user. By storing a set having one or more personal identifiers associated with the user, the identifiers including at least one biometric sample, and linking the set of personal identifiers with a key or keys generated for that user, it is possible to subsequently create a digital signature by providing at least one biometric sample. It will be appreciated that this set of personal identifiers typically includes information that conforms in large part to the data elements of x.500 addressing, although as will be appreciated by those skilled in the art this is not intended to limit the application of the present invention to such addressing.

In the case of x.500, such data includes: 1. Common Name 2. Distinguished name 3. Email 4. Organisation . Organisational Unit 6. Address etc.

An example of the enrolment process is shown in Figure 3 wherein the following steps are identified. These steps are shown for illustrative purposes only and it will be appreciated that the skilled person will not limit the present invention to any exact replication of such steps.

Step 1, the person being enrolled (An enrolee 300) connects over a network (305) to an enrolment application (310). The connection to the network (305) typically involves the supply of a biometric sample to the system, the biometric sample being provided to the system by the enrolee (300) utilising a biometric capture device (301). It will be understood that the network can be a wide area, local area or even a personal area network.

Step 2, the enrolment application (310) captures enrolment data on the individual (for example, name, address, date of birth etc.). It will be appreciated that this enrolment data could be input on the basis of a prompt for specific information from the enrolment application and could be implemented over a locally installed application or for example using a web based server. This enrolment may also include one or more user identity claims. The amount and nature of this information can vary depending on the required information for the specific installation of the system and it will be understood that such information may vary depending on the installation environment where the system of the present invention is intended for use. On capture of the specific identifiers by the enrolment application, the captured samples are then forwarded to a biometric authentication engine (315) which may (depending on its configuration) carry out a uniqueness check on the biometric samples taken at enrolment. The uniqueness check will typically be implemented where the system is configured to only associate a single biometric identifier with a single user identifier whereas in other implementations a user may have two or more suitable user identifiers associated therewith, each user identifier being associated with the same biometric sample.

Step 3, if a user successfully enrols, their enrolment data including the biometric samples are stored in a persistent data store (shown as a biometric database (320)).

Step 4, based on data requested at step 2, an administrator decision or a configuration parameter, the enrolee (300) will be designated as one entitled to create electronic signatures .

Once designated, in Step 5, this results in a request being sent to an electronic signature application (325) to cause it to generate the necessary public and private keys. It will be appreciated that using a system according to the present invention that a biometric identifier is used to identify a user of the system and to cause it to generate a key or keys for that user or to associated that user with a key or keys. Once these keys have been generated and associated with a biometric identifier they can then be accessed by presentation of the biometric identifier without any subsequent enrolment or alternative traditional access methodology.

The e-signature application requests a public-private key pair to be generated by a Key Trust (330). The Key Trust typically uses a HSM (Hardware Security Module) to generate this key. The HSM is a tamper-resistant device that contains cryptographic capabilities, and it will be appreciated that alternatives (such as a software implementation) that offer suitable equivalent capabilities may be equally applicable.

The request to the HSM is typically signed by the component generating the request (the e-signature Application (325)) . This signature may optionally include in the signing data the signature generated by the Authentication Engine (315) in step 4 when making the request of the e-signature application. The invention allows for and recognises a situation where all parties in the communication from the user to the key trust can sign (and optionally encrypt) messages. Each of these signatures can then be checked by the key trust before allowing the signature key or keys associated with the user to sign a document.

The HSM generates the keys and optionally exports the public key. In accordance with known principles, the private key is stored in a key store database within the key trust (330). Each private key stored in the database is encrypted or wrapped under a separate cryptographic key known only to (and stored on board) the HSM. Strong cryptographic techniques (e.g. AES, 3DES) should be used to encrypt the private keys.

Step 6, the HSM component of the Key Trust (330) exports the public key component to the e-signature Application (325) Step 7, the received public key component is then forwarded together with the necessary registration/enrolment details to a Certificate Authority (340) for signing. It will be appreciated that a variety of methods can be used to export the key, including both off-line and on-line. A variety of protocols can also be used - for example, Public Key Cryptographic Standard number 10 (PKCS#10).

The Certificate Authority (340) then signs the public key using its private key. The resulting certificate can then be stored in a directory service -- for example, an LDAP (Lightweight Directory Access Protocol) (345) compliant directory (step 8a).

Step 8b, a success (or failure) status dependant on the generation of the certificate is returned to the Esignature application (.325) . This status can be returned in an on-line or off-line mode depending on the CA configuration. In the case of a success status code, the digital certificate can also be returned if required. The certificate may be in X.509 format, amongst others.

In step 9, the E-signature application returns a success or failure code to the authentication engine (315). This status code, again, can be returned using an on-line or ΙΕΟ 1101 8 off-line protocol. Upon receipt of a successful status code, the authentication engine (315) registers that enrolee as enrolled for the E-signature application. The enrolment application and enrolee may optionally also be notified of the success/failure of the operation (through steps 10 and 11).

It will be appreciated that steps 7 through 8b are carried out where an external certificate authority is being used. The invention is also designed to work in a situation where the key-pair authenticity is self asserted or asserted by the key trust. In this case, the steps outlined above for interacting with an external CA are not required.

It will be appreciated that although above components of the system have been described with reference to discrete modules such as a Authentication Engine (315) etc., that this has been done for ease of explanation and that two or more applications could be implemented on the same hardware or software platforms. It will be further understood that the communication between the individual components could be effected over a local or wide area network.

Message Integrity It will be appreciated that as the above described steps relate to the formation of a specific security identifier associated with a specific user that it is typical that secure communication protocols should be utilised such that all messages in the scheme (in particular messages identified in Steps 2,4,5,6,7,8b,9) have integrity guarantees in place. This could typically include a signing and/or an encryption of these messages by the originating parties, but it will be appreciated that alternative methodologies could be envisaged which require only some or none of techniques to be utilised.

Enrolment with Enroler Signature It will be appreciated that the above flow steps outline a process for the generation of a digital certificate for a specific user that does not require any specific enroler signature. The present invention may provide in an alternative embodiment a variant to the process hereinbefore described wherein the enrolment data request is also biometrically signed by an enroler. This process is very similar to the simpler enrolment outlined above and can be seen in the Figure 4. The same reference numerals will be used for similar components or process flow steps.

In this modification to the process flow outlined above, Steps 1 and 2 (the connection and submission of enrolment data) are broken into 2 parts (la,b and 2a,b). Steps la and 2a are the same as in the configuration shown in Figure 3. Step lb involves an enroler (401) connecting to the enrolment application which is typically on the same interface and network connection. The enroler is also usually in the same physical location as the enrolee, although it will be appreciated that alternatives techniques such as using voice recognition may allow the enroler to be in a remote location to the enrolee, yet still be able to enrol the enrolee with the system. Step 2b involves the enroler (401) supplying a biometric sample and signing the enrolment request of the enrolee (300). This signature will then be included in the message payload to both the authentication engine and the e-signature application. It will be appreciated that this signature may be selected from one of a number of different signature types including those generated using a key of the enroler, a key of the server application or a key which is associated with a biometric identifier of the enroler.

One or both of these systems may then use a privilege management database to ensure that the enroler was entitled to enrol the enrolee, although it will be appreciated that it is not intended to limit the present invention to such hierarchical management systems.

It will be appreciated that in the enrolment process outlined in Figures 3 and 4 that typically a separate enrolment checking procedure is implemented in either the e-signature application (325) or the Authentication engine (315) to verify the accuracy of the enrolment prior to the generation and signing of the keys (steps 5 onwards). This is not shown in the diagram for simplicity, but will be appreciated by the skilled person as forming part of the invention.

Once an enrolee (300) has successfully enrolled in the system of the present invention, he now adopts the persona of a client to the system and is now free to generate biometrically protected signatures for application to specific documents, and may be able to act as an enroler for additional persons or users (if so authorised). A typical generation process is shown in Figure 5, and will be described with reference to a document repository (DR) as a partner application, although it will be appreciated that such an example is not intended to limit the present invention to interface only with document repositories. Again, the same reference numerals will be used to describe similar components to the system.

The following steps are followed to sign a document: A client (300) connects to a document management engine or document repository (505) and provides an identity claim and a biometric sample (Step 1). The biometric sample is encrypted under a key known to the Authentication Engine (AE) (315) (e.g. the AE's public key) . This ensures that the partner applications such as document repositories (DR) do not gain access to the biometric information.

Client ·> DR: claim, Eae(biometric sample) Optionally, to increase user privacy, the claim may be specific to the DR, and the mapping between the DR-specific claim and the user's AE claim may be encrypted along with the biometric sample, and only visible to the AE. This would prevent DRs colluding to compare claims. In additio, by including the claim (DR-specific or otherwise) encrypted with the biometric sample, a dishonest DR is prevented from attempting to find other claims, through repeated requests to the AE, that falsely match the submitted biometric sample.

The document repository (505) forwards the claim of identity and the biometric sample to the Authentication Engine (315) (Step 2). The message also includes an application identifier (id). This message may be signed by the document repository also.

DR AE: claim, Eae (biometric sample), application id The Authentication Engine (315) verifies the identity of the user, using a biometric matching algorithm, and returns an authentication ticket to the partner application (document repository) (505) (Step 3). This is the user's claim of identity signed by the authentication engine. It typically includes a timestamp, expiry date and application id. This authentication ticket can be passed by the DR (505) to the client to streamline the authentication process to other applications and the AE later. auth_ticket := SAE (claim, application id, timestamp, expiry date) ΆΕ -½ DR: auth_ticket The Document Repository (505) determines (based on the authentication success/failure) and its privilege management engine that the user is entitled to see the document and if this is the case, returns the document to the client (300) along with the authentication ticket (Step 4) .

DR -> Client: document, auth_ticket It will be understood that the method of the present invention may utilise one of a number of methods for returning the authentication ticket to the client including but not limited to the use of cookies.

The auth ticket is ultimately used by the key trust KT (330) and may be optionally encrypted with the KT's public key to increase privacy of communications.

An identifier of the e-signature application may optionally be included in the ticket to prevent it being used by another entity.

The user may modify the document contents. The client calculates the digest (hash) for the document to be signed and encrypts under the public key of the KeyTrust (KT) (330) (Step 5) . enc_digest := EPuKT (digest) It will be appreciated that an alternative implementation of this scheme could be built where symmetric key cryptography is used in some or all messages.

In Step 6 the Client forwards authentication ticket, encrypted digest to the e-signature Application (325) (AE) client -> AE: auth_ticket, enc__digest ΙΕΟ 11 0 7 β The e-signature Application (325) verifies the authentication ticket, previously issued by the authentication engine (315) in step 3. It may optionally go on-line to the authentication engine to do this (steps 7,8). Depending on its policy configuration, it may trust the authentication ticket at this point (it is signed by the AE) or it may request a re-authentication if a) it is configured to do so at each signing or b) the authentication ticket is no longer valid (for example, if the expiry period has elapsed).

It should be noted that should the ticket not be present or a re-authentication required, a formal authentication (biometric, claim) may be carried out by the e-signature application (325) using the authentication engine (AE) (315) .

Once the signer has been authenticated, the e-signature application (325) signs the authentication ticket and encrypted message digest. This is then forwarded to the Key Trust (330) (Step 9) KT_ticket := SesignApp (auth_ticket, enc_digest) eSignApp -> KT: KT_ticket The Key Trust (330) verifies the signature on the KT_ticket so as to ensure it came from a trusted e-signature application. It can then verify the authenticity of the authentication ticket (signed by the AE), decrypt the enc_digest to get the document digest for signing.

It will be appreciated by the skilled person that in most secure operations, all encryption and decryption operations will be carried out by the Key Trust HSM.

It then retrieves the private key from its database and decrypts it using the key corresponding to the claim signed by the AE (Step 10). This key could be symmetric or asymmetric and in the case of a symmetric key could be a single key used across all claims or a derived key - the derivation based on, for example, the claim of identity.

It will be appreciated by the skilled person that the provision of multiple signatures by the various trusted components within the process steps of the present invention adds to improvements in the overall security robustness of the system.

The KT (330) then signs the digest, possibly adding a timestamp if necessary. It will be appreciated that these timestamps may be server assigned timestamps and/or client assigned timestamps.

The Key Trust (330) then sends the resulting signature back to the e-signature application (Step 11).

The e-signature application (325) returns the electronic signature to the client (300) (Step 12).

It will be appreciated that the return of the electronic signature may include such optional steps as the validation of the signature using its own public key from a directory (e.g. LDAP (345))(Step 13) prior to execution of step 14, which is the storage of the electronic signature in the document repository (505) .

It will be appreciated that the process flow outlined above may be differentiated for situations or circumstances wherein the document repository (505) is not fully integrated with the Authentication Engine (315). Such a modification is outlined in Figure 6. Again, as was utilised previously similar reference numerals will be used for equivalent components to the system. In this scenario, the flows are very similar, however the document repository has no direct link or association with the authentication engine. This scenario may exist in situations such as: 1. A customer or client has deployed the esignature product with a document repository which has not yet been associated with the storage biometric identifiers or; 2. The e-signature signing service is a service offered over for example the internet, with no integration with local repositories.

In this case, the Document Repository has its own authentication mechanism (e.g. user name and password) for authenticating the user. This is shown in step 2. The document is returned to the client in step 3 and the digest (as in the previous scenario) is calculated in step 4. Step 5 is similar to that outline in Step 6 of Figure 3 wherein the Client forwards the authentication ticket and encrypted digest to the e-signature Application (325) (AE) Steps 6 and 7 show the e-signature application determining that it does not have a valid authentication ticket. This may occur in situations where the biometric identifier has not yet been presented to the system or the ticket has expired. It then requests a biometric and claim and forwards these to the AE for authentication (steps 6,7,8,9).

The operation of the AE including the data in the authentication ticket is as outlined previously.

It will be appreciated that in case of user identification, the claim is not present in data flows 7 or 8 - but is determined by the AE and returned in data flow 9.

Steps 10 through 15 correspond with steps 9 through 14 in the previous (integrated document repository) scenario outlined in Figure 5.

To verify an asymmetric signature, a verifier usually obtains the signer's digital certificate, and uses this to verify the signature. Where a Certificate Authority is not used, other methods to verify the signature can be applied. The verifier may request, through an optional arbitrator application, that the KT send the key material necessary to verify the signature directly to the verifier. In the case of asymmetric signatures this will be the public key corresponding to the private key that signed the document. Using traditional cryptographic techniques and protocols, the KT may securely send the key to the verifier, and prove that this key originated from the KT.

However, for cases where the KT does not wish to send key material to the verifier, the protocol illustrated in Figure 7 may be followed to verify the signature. Such cases may include where a symmetric key signature is used, where the KT does not want to release . either symmetric or asymmetric key material, or where the verifier cannot perform signature verification.

If a verifier (707) does not already have the document and/or the signature, then it may obtain these from a document repository (steps 1 and 2). The verifier then generates a hash of the document, and sends this along with the signature to the e-signature verification application (step 3). Both the signature and hash may be encrypted with the public-key of the KT, who will perform the actual verification, in order to prevent other entities accessing it. The verifier may be required to authenticate themselves or the request, biometrically or otherwise, to the signature verification application and/or the KT. In the 1E8 0®T® case of biometric authentication, the authentication engine verifies the verifier's biometric, returning the result to the verification application (optional steps 4-7) If the verification application is prepared to verify the signature for the requesting verifier, then the signature and corresponding hash are forwarded onto the KT (step 8).

The KT infers from the signature, the identifier of the key or keys necessary to verify the signature. The key or keys are then retrieved from a HSM or other secure storage (step 9). The signature is verified using the appropriate keys, and an indication of whether a valid signature was present is returned to the verification application (step 10). This outcome is then forwarded on to the requesting verifier (step 11). All messages may be encrypted and signed for security.

It will be appreciated that the implementation of the method of the present invention has involved authentication of a user at the authentication engine, based on a claim and their biometric identifier. The authentication engine uses the claim to retrieve one or more enrolled biometric identifiers for the user, against which the submitted biometric is compared (a process referred to as verification). However, it will be appreciated that a user may be identified by submitting a biometric identifier alone, without a specific claim. In this case the authentication engine will compare the submitted biometric identifier against a multiplicity of enrolled biometric identifiers (a process referred to as identification) . When the AE finds the enrolled biometric identifier that best matches the submitted one, it will return the corresponding identity claim. An application receiving this verified claim, can then be assured that this user has been authenticated. It will be appreciated that such a method of identification without a claim, may be used within the method and system of the present invention in situations where verification has been described.

It will be appreciated that although the present invention has been described with reference to the application of a digital or electronic signature to documents that the word document is intended to cover any electronic object such as but not limited to text, pdf, source code, object code, binaries, images, multimedia files, transaction data, email, messages etc.).

Once a document has been signed it may later be verified using conventional techniques such as that shown in Figure 2, and it will be appreciated that no specific biometric technologies are required to verify a signature (for example if a CA has been used to certify the public keys). However, the KT (and perhaps the e-signature application) can be configured to store the signed digests generated for audit trail purposes.

It will also be appreciated that if the biometric identifier is incorporated into the electronic signature, as was described above according to an aspect of the present invention, that a modification to this conventional technique will be required to decipher the biometric identifier from the document signature and confirm that it is an authentic identifier.

It will be appreciated that although an exemplary embodiment of the present invention has been described for illustrative purposes as using public key digital signatures, that this is not intended to limit the present invention to such embodiments and varying implementations such as those using a symmetric key algorithm may be found suitable for specific applications.

The words comprises/comprising and the words having/including when used herein with reference to the present invention are used to specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.

It will be appreciated that in all steps security techniques are typically applied to protect the integrity of the communications channels and to guarantee freshness of the messages.

Claims (37)

1. A method of associating at least one cryptographic key with a specific user comprising the steps of: a) storing a set having one or more personal identifiers associated with the user, b) linking the set of personal identifiers with at least one cryptographic key generated for that user, and wherein the set of personal identifiers associated with the user includes at least one biometric identifier, and at least one cryptographic key may subsequently be accessed by providing at least one biometric identifier.

2. The method as claimed in claim 1 wherein at least one cryptographic key comprises a set of cryptographic keys.

3. The method as claimed in claim 2 wherein the set of keys includes a pair of public and private keys.

4. The method as claimed in 2 or 3 above wherein the set of cryptographic keys includes a symmetric key.

5. The method as claimed in claim 1 wherein at least one cryptographic key includes an asymmetric key.

6. The method as claimed in any preceding claim wherein the step of storing a set of personal identifiers with the user includes the steps of: a) electronically registering the user, b) capturing a set of identifiers presented by the user, and c) storing the set of identifiers in a datastore.

7. The method as claimed in claim 6 comprising the additional steps of: a) comparing the captured set of identifiers with previously stored identifiers in said datastore, and b) accepting the captured set of identifiers where the step of comparing the captured set of identifiers does not find a matching previously stored identifier.

8. The method as claimed in any preceding claim further comprising the steps of: a) associating the specific user with a pre-existing user, b) authenticating the identity of the pre-existing user, and c) storing the set of identifiers for the specific user after authentication of the pre-existing user.

9. The method according to any preceding claim further comprising the step of requesting a cryptographic key or keys for a specific user be generated after the biometric identifiers have been associated with and stored for that user.

10. The method as claimed in claim 9 wherein the request for a cryptographic key or keys to be generated is a signed request.

11. A method of returning at least one cryptographic key for a user, the user having been associated with the cryptographic key in accordance with any one of claims 1 to 10, the method comprising the steps of: a) receiving a biometric identifier from the user, b) comparing the biometric identifier with a datastore of previously stored· identifiers, and c) on matching an'identifier in the datastore with the supplied biometric identifier, returning at least one cryptographic key previously associated with the stored identifier to the user.

12. A method of providing a user with access to an electronically stored document, the method comprising the steps of: a) receiving a request from a user for a specific document, the request including at least one biometric identifier for that user, b) comparing the supplied biometric identifier with a set of pre-stored identifiers so as to authenticate the user, and wherein access is provided to the electronic document by forwarding a copy of the requested document to the user if the step of comparing the supplied biometric identifier authenticates the user.

13. The method of claim 12 wherein the biometric identifier is received at a document repository, the biometric identifier being encrypted prior to receipt at the repository, and wherein the repository forwards the encrypted identifier to an authentication engine where it is decrypted and compared with the set of pre-stored identifiers so as to authenticate the user. ι Ε ο υ ο 7 8

14. The method as claimed in claim 13 wherein the authentication engine, on authentication of the identity of the user, returns an authentication ticket to the document repository, the authentication ticket indicating whether the user is authenticated or not.

15. The method as claimed in claim 14 wherein on authentication of the user and receipt of said ticket at the document repository, the repository confirms that the authenticated user is entitled to retrieve the requested document and, on confirmation of same, returns the requested document and authentication ticket to the user.

16. The method as claimed in claim 14 or claim 15 wherein the authentication ticket is returned to the user by means of a cookie forwarded by the repository to the user.

17. A method of applying an electronic signature to a document, the method comprising the steps of: a) receiving an encrypted digest of a document and an authentication ticket of a user from said user, the document and authentication ticket having being forwarded to the user according to the method steps of any one of claims 12 to 16, b) applying an electronic signature to the verified authentication ticket and encrypted digest, and forwarding said signed combination to a key trust, the key trust being adapted to verify the authenticity of the applied signature and the authentication ticket, c) on verification of said applied signature and authentication ticket obtaining a cryptographic key from a datastore associated with the key trust, the cryptographic key selected being associated with the biometric identifier detailed in the authentication ticket, and d) signing the digest using the cryptographic key, 5 the signed digest forming an electronic signature for the document linkable to the user.

18. The method as claimed in claim 17 comprising the additional step of verifying the authentication ticket received from the user prior to forwarding the ticket 10 to the key trust.

19. The method as claimed in claim 17 or 18 comprising the further steps of: a) receiving the electronic signature from the key trust and returning the electronic signature to 15 the user, and b) storing the electronic signature.

20. The method as claimed in any one of claims 17 to 19 wherein the key trust decrypts the cryptographic key, the decryption being effected using a key 20 corresponding to the claim identity signed by the authentication engine.

21. The method as claimed any one of claims 17 to 19 wherein the key trust decrypts the cryptographic key, the decryption being effected using a key 25 corresponding to one or more claims.

22. The method as claimed in claim 20 or 21 wherein the key used to decrypt the selected cryptographic key is a symmetric key.

23. The method as claimed in claim 20 or 21 wherein the key used to decrypt the selected cryptographic key is an asymmetric key.

24. The method as claimed in any preceding claim wherein the biometric identifier is selected from one or more of the following biometric types: a) iris, b) voice, c) finger, d) blood, e) DNA, f) Retina, g) Face, h) Hand geometry. 15

25. The method as claimed in any one of claims 17 to 24 wherein a signing of a document includes the application of a time stamp to that signature.

26. A system adapted to provide for the encryption of one or more electronic documents, said system having: 20 a) a first datastore adapted to store a plurality of identifiers associated with one or more users, b) means for associating an electronic document a specified user, with 25 c) means for encrypting the associated document an encryption based on the one or more identifiers associated with that user and with wherein the one or more identifiers include at least one biometric identifier linkable to that user.

27. A system adapted to provide for the signing of one or more electronic documents, said system having: a) a datastore adapted to store a plurality of identifiers associated with one or more users, b) means for associating an electronic document with a specified user, c) means for signing the associated document with an electronic signature based on the one or more identifiers associated with that user and wherein the one or more identifiers include at least one biometric identifier linkable to that user.

28. A security system adapted for use with at least one associated key trust, the system comprising: a) a datastore adapted to store a plurality of sets of personal identifiers, each set having one or more biometric identifiers, b) means for associating at least one cryptographic key from the key trust with a specific user, c) means for accepting the associated at least one cryptographic key from the key trust, d) means for linking the set of personal identifiers with the requested at least one cryptographic key.

29. The method as claimed in claim 28 wherein the means for associating at least one cryptographic key comprises the steps of requesting the generation of at least one cryptographic key from the key trust.

30. The method as claimed in claim 28 wherein the means for associating at least one cryptographic key comprises the steps of providing the key trust with at least one cryptographic key.

31. The method as claimed in any one of claims 28 to 30 wherein the at least one cryptographic key is at least one pair of keys.

32. The method as claimed in claim 31 wherein one key from the at least one pair of keys is requested from the key trust.

33. The system as claimed in claim 28 wherein at least one cryptographic key is a cryptographic key previously associated with the specific user.

34. The system as claimed in any one of claims 28 to 33 further including means for electronically signing the request for requesting at least one cryptographic key from the key trust.

35. A security access system for providing a user with access to an electronically stored document, the system comprising: a) means for receiving a request from a user for a specific document, the request including at least one biometric identifier for that user, b) means for comparing the supplied biometric identifier with a set of pre-stored identifiers so as to authenticate the user, and c) means for forwarding a copy of the requested document to the user if the means for comparing the supplied biometric identifier authenticates the user.

36. The system as claimed in claim 35 wherein the biometric identifier is received at a document repository, the biometric identifier being encrypted prior to receipt at the repository, and wherein the repository forwards the encrypted identifier to an

37. 10 38. authentication engine where it is decrypted and compared with the set of pre-stored identifiers so as to authenticate the user. The system as claimed in claim 36 wherein the authentication engine, on authentication of the identity of the user, is adapted to return an authentication ticket to the document repository, the authentication ticket indicating whether the user is authenticated or not. The system as claimed in claim 37 wherein on authentication of the user and receipt of said ticket at the document repository, the repository is adapted to confirm that the authenticated user is entitled to retrieve the requested document and, on confirmation of same, is adapted to return the requested document and authentication ticket to the user. ιε»' ηΐΐ Data Step 1 1 r Compute document hash 5 ' s' Sign document Step 2 Step 3 Signer's private key Step 4 Document Document Signature c o ο υ LL CD > Figure 1 Figure 2 lEOiioi 8 300 _ 305 ο co Figure 3 ο co 300 _ 305 Ο co Figure 4 345 ο co Figure 5 345 ο CO Figure 6 R 7 Ο * fe Γω Ζ3 σ) Li_ ο co