Method and system for implementing a privacy preserving, face-based protected public key infrastructure

Abstract

A computer-implemented method of issuing a public key certificate in a public key infrastructure is provided. The public key infrastructure comprises a user device, a trusted server comprising a public key registry, and a third-party device operated by a third party. The method includes the steps: the user device obtaining biometric data comprising a facial image of the user; the user device or the trusted server generating a privacy preserving data structure using the biometric data; the user device receiving a purpose ID from the third-party device; the user device obtaining subsequently acquired biometric data comprising the facial image of the user; the user device or the trusted server generating a public key from the privacy preserving data structure using the subsequently acquired biometric data and the purpose ID, wherein a private key corresponding to the public key can be generated from the privacy preserving data structure using the purpose ID and further subsequently acquired biometric data comprising the facial image of the user; and the trusted server obtaining a public key certificate from an issuer, the public key certificate comprising the public key and a digital signature of the issuer, and the trusted server storing the public key certificate in the public key registry.

Description

[0001] METHOD AND SYSTEM FOR IMPLEMENTING A PRIVACY PRESERVING, FACEBASED PROTECTED PUBLIC KEY INFRASTRUCTURE

[0002] Field of the Invention

[0003]

[0001] The present invention relates to computer-implemented methods, devices, and systems for facebased authentication of a user in a public key infrastructure.

[0004] Background

[0005]

[0002] Public Key Infrastructure is common in scenarios where information must be signed or encrypted with non-repudiation and authenticity in mind. In such scenarios, there is typically a trusted root Certificate Authority (CA) that can generate a certificate vouching for the identity (and public key) of an end-user.

[0006]

[0003] Documents can then be signed with end-user’s private key, and the signature can be verified by validating it against the signed public key contained in the certificate issued by the root CA.

[0007]

[0004] Since the root CA is trusted, and its public key is known (via a self-signed certificate), certificates issued by the CA can be verified using the CA’s root certificate, and since they contain identity information of the end-user, the end-user’s identity information can be safely associated with their public key by virtue of the certificate issued to them by the root CA.

[0008]

[0005] Present document signing systems typically employ e-signatures where documents are annotated with visible signatures in signing fields. Such methods typically send the document via email and maintain an audit trail of when events occurred. Documents can typically be opened from emails and users can either draw, or adopt a signature based on available fonts. Once the document is e-signed by all parties, the signing platform may add the audit trail page and cryptographically sign the document as completed by using its own private key.

[0009]

[0006] However, such documents can be contested in court under the clause of plausible deniability. Plausible deniability is the ability of people, typically senior officials in a formal or informal chain of command, to deny knowledge of or responsibility for actions by members of their organizational hierarchy. Since, in many situations, executives have secretaries with access to their email, the e-signing regime can be easily contested in court by an executive claiming that the secretary signed the document and not them.

[0010]

[0007] Facial recognition-based user authentication methods identify users by their unique biological features. Secure websites can use such methods for signing in its users, providing an effective means of user authentication without requiring the users to recall a password. Typically, users sign up on the website by supplying a biometric sample of their facial features to generate a feature template which is stored in a database as biometric data. Later, when the user presents another biometric sample, a new feature template is generated and compared with the previously stored template. If the respective feature templates are found to be sufficiently similar, the system deems that the same person supplied each sample. In this regard, the feature templates are ‘linkable’. The ability to compare feature templates with one another is also what makes the stored data biometric in nature. However, in the context of data protection, this is an undesirable property of biometric data because it is possible to identify the user from their biometric data.

[0011]

[0008] Another concern with traditional facial recognition-based user authentication methods is that only one feature template can be generated from a single biometric sample. Therefore, if the feature template is compromised, the user cannot generate a new feature template as a replacement. This is analogous to having a password that cannot be changed.

[0012]

[0009] Therefore, there is a need to enable third parties to authenticate users while maintaining the privacy and security of biometric information of users, e.g. for verifying a user sign-in attempt or a digital signature.

[0013]

[0010] The present invention has been devised in light of the above considerations.

[0014] Summary of the Invention

[0015]

[0011] Broadly, the present invention relates to systems and methods for face-based authentication of a user in a public key infrastructure. In particular, biometric data comprising a facial image of a user is used to generate a public key and a privacy preserving data structure which can be used to generate a corresponding private key. The corresponding private key can only be generated from the privacy preserving data structure using subsequently acquired biometric data comprising the facial image of the user that was used to generate the privacy preserving data structure. Therefore, the privacy preserving data structure enables the user to protect the private key using their biometric data by ensuring that the corresponding private key can only be generated at run time from the user’s face. The privacy preserving data structure may store entropy which is used in conjunction with the subsequently acquired biometric data to generate the private key. The privacy preserving data structure may contain encrypted metadata relating to the user which can only be decrypted using the corresponding private key. Although an ‘incorrect’ private key may be generated using a different facial image, the incorrect private key would not be able to decrypt the encrypted metadata stored in the privacy preserving data structure. Thus, the act of decrypting the encrypted metadata successfully is an act of biometric authentication of the user using the subsequently acquired facial image.

[0016]

[0012] There are multiple known ways to generate such a privacy preserving data structure having these properties. For example, some common approaches are set out in international standard ISO / IEC 30136:2018 the contents of which is incorporated herein by reference. Commercial offerings are available for practitioners in the field to utilise such privacy preserving data structures for achieving the purpose of this invention.

[0013] Presented below are different aspects of the present invention, each aspect having different optional features. These aspects and optional features are combinable in any combination unless the context demands otherwise.

[0017]

[0014] In a first aspect there is provided a computer-implemented method of issuing a public key certificate in a public key infrastructure, the public key infrastructure comprising a user device, a trusted server comprising a public key registry, and a third-party device, the method including: the user device obtaining biometric data comprising a facial image of the user; the user device or the trusted server generating a privacy preserving data structure using the biometric data; the user device receiving a purpose ID from the third-party device; the user device obtaining subsequently acquired biometric data comprising the facial image of the user; the user device or the trusted server generating a public key from the privacy preserving data structure using the subsequently acquired biometric data and the purpose ID, wherein a private key corresponding to the public key can be generated from the privacy preserving data structure using the purpose ID and further subsequently acquired biometric data comprising the facial image of the user; the trusted server obtaining a public key certificate from an issuer, the public key certificate comprising the public key and a digital signature of the issuer, and the trusted server storing the public key certificate in the public key registry.

[0018]

[0015] By using the privacy preserving data structure to protect the private key with the biometric data of the user, only the user is able to generate their private key - i.e. the private key corresponding to the public key. Since the identity of the user is authenticated by the trusted server in advance of issuing public key certificate, the public key certificate is sufficient to authenticate the user and therefore the trusted server is not required to be involved in future transactions. This enables third parties to authenticate users while maintaining the privacy and security of the biometric data of users. Additionally, due to the non-biometric nature of the privacy preserving data structure, the trusted server is never required to store facial images or unencrypted user attributes of the user. Therefore, the method preserves the user’s privacy and improves data security.

[0019]

[0016] As the same purpose ID used to generate the public key is also required to generate the corresponding private key, the method ensures that each public key certificate is issued for a specific purpose. Hence, the purpose ID may serve as a pairwise functional ID which avoids the user having to present a foundational ID across different systems. In so doing, the purpose ID facilitates privacy preservation by preventing other parties from being able to observing the same public key or ID across different databases to track the activities of the user.

[0020]

[0017] Biometric data comprising the facial image of the user may refer to an image of the user’s face or data which is derived from an image of the user’s face. While the use of biometric data comprising the facial image of the user is preferred, other types of biometric data are contemplated. For example, the biometric data may comprise, in any combination, one or more of: a fingerprint scan, a palm-print scan, an iris scan, a retina scan, and a voice recording.

[0021]

[0018] The user device may be a mobile device, e.g. a smartphone or tablet. The user device may communicate with the trusted server via an app installed on the user device. Upon each start of the app, the app may use security methods such as device integrity checks to ensure that the user device is uncompromised. If a spurious device is detected, the app may cease to function and / or delete data associated with the app. This can reduce the risk of injection attacks in which a video or high-resolution image is presented to the user device instead of a live biometric presentation.

[0022]

[0019] The trusted server may be controlled by the issuer. The issuer may be a government organization acting as a root certificate authority. In other words, the trusted server may be the root certificate authority. The trusted server may include a network interface for exchanging data with the user device and the third-party device. The trusted server may include a processor and a memory, the memory comprising the public key registry for storing a plurality of public key certificates. The trusted server may comprise one or more of: an attribute registry for storing one or more user attributes; a third party registry for storing a third-party public key certificate; a privacy preserving data structure (PPDS) registry for storing the privacy preserving data structure; and a certificate revocation list.

[0023]

[0020] Obtaining the biometric data and / or the subsequently acquired biometric data may include the user device recording the biometric data using a biometric sensor on the user device. The user device may prompt the user to input their biometric data using the biometric sensor, e.g. in response to receiving the purpose ID.

[0024]

[0021] Where the trusted server comprises the attribute registry, the method may include storing one or more attributes in the attribute registry. Each of the one or more attributes may be indexed by reference to the user. For example, the user reference may be the user’s name or a unique national identity / insurance number issued by the government organization. The one or more attributes stored in the attribute registry may correspond to attribute values associated with the user. Additionally, or alternatively, the attribute registry may store IDs / codes for different types of attributes. These IDs may be specified on third-party public key certificates issued by the trusted server as requestable attributes such that it may be determined whether or not the third-party device has been approved by the trusted server for requesting the requestable attributes.

[0025]

[0022] Where the trusted server comprises the PPDS registry, the method may include storing the privacy preserving data structure in the PPDS registry. The privacy preserving data structure may be indexed in the PPDS registry by reference to the user. For example, the user reference may be the user’s name or a unique national identity / insurance number issued by the government organization. Alternatively, the privacy preserving data structure may be indexed using a hash value of the user reference, e.g. obtained using a SHA256 hashing algorithm. The hashed index protects the user’s identity in the PPDS registry thereby improving security.

[0023] Where the user device generates the privacy preserving data structure, the method may include the user device forwarding the privacy preserving data structure to the trusted server. The user device may store a local copy of the privacy preserving data structure in the memory, e.g. in a cache. Alternatively, where the trusted server generates the privacy preserving data structure, the method may include the user device forwarding the biometric data (e.g. and the password) to the trusted server for generating the privacy preserving data structure. The trusted server may provide the copy of the privacy preserving data structure to the user device.

[0026]

[0024] The privacy preserving data structure may store one or more user attributes as encrypted metadata. For example, the method may include retrieving the one or more user attributes from the attribute registry. The method may include generating a public key from the privacy preserving data structure using the biometric data, encrypting the one or more user attributes using the public key, and storing the encrypted one or more user attributes as metadata in the privacy preserving data structure. A private key corresponding to the public key can be generated from the privacy preserving data structure using subsequently acquired biometric data comprising the facial image of the user. The public key or the public-private key pair may be generated by the user device or the trusted server using the biometric data.

[0027]

[0025] The method may include discarding the public key after generating the privacy preserving data structure. Generating the public key may include generating a public-private key pair and discarding the private key. The public key or the public-private key pair may be generated using a password (i.e. in addition to using the biometric data). The password may be inputted into the user device by the user. The method may require the same password to be used again to generate the private key corresponding to the public key from the privacy preserving data structure.

[0028]

[0026] Where the trusted server comprises a third party registry, the method may include storing a third- party public key certificate in the third party registry. The method may include the third-party device providing a third-party public key to the trusted server, for example, via a certificate signing request (CSR). The third-party public key corresponds to a private key held by the third party. Additionally, the third-party device may provide a set of one or more requestable attributes and / or a submission end-point URL to the trusted server. The requestable user attributes are types of user attributes to which the third party requires access for operations involving its users. The submission end-point URL is a URL address for users to submit data to the third party.

[0029]

[0027] The method may include the trusted server assigning a purpose ID to the third party. The purpose ID may be assigned in response to the trusted server approving the set of one or more requestable attributes. Although it is preferred that the trusted server generates the purpose ID, it is contemplated that the purpose ID may be generated by the third-party device and shared with the trusted server, e.g. the purpose ID may be randomly generated. However, in all cases, the purpose ID must be unique and the same purpose ID may not be linked to third-party public key certificates issued to different third parties. The user device may receive the purpose ID from the third-party device by scanning a QR code displayed by the third-party device, e.g. on a website.

[0028] The method may include the trusted server obtaining the third-party public key certificate from the issuer, the third-party public key certificate comprising the third-party public key. Where the third-party device provides the set of one or more requestable attributes and / or the submission end-point URL to the trusted server, the third-party public key certificate may comprise the set of one or more requestable attributes and / or the submission end-point URL. The method may include the trusted server signing the third-party public key certificate using a private key of the issuer. This enables the authenticity of the third-party public key certificate to be verified using a corresponding public key root certificate of the issuer.

[0030]

[0029] The third-party public key certificate may be indexed in the third party registry by the purpose ID. Therefore, the third-party public key certificate may be retrieved by reference to the purpose ID. The third-party public key certificate may additionally be indexed in the third party registry by a user ID. This may restrict users from being able to retrieve third-party public key certificates intended for other users. For example, third-party public key certificate may be user-specific to allow the third party to receive encrypted data from the user, where the data is encrypted using a public key only available to the user. The index may be a hash value of the purpose ID and / or a pseudonymised user ID in order to protect personally identifiable information of the user. For example, the method may include the third-party device obtaining a hash value of the purpose ID and / or pseudonymising the user ID before providing the hash value of the purpose ID and / or the pseudonymised user ID to the trusted server with the public key.

[0031]

[0030] The method may include the user device receiving a request from the third-party device for one or more user attributes. For example, these attributes may include one or more of the user’s name, address, date of birth, or qualifications. The user device may receive the request by scanning a QR code displayed by the third-party device, e.g. on a website. The same QR code may include the purpose ID and the request for the one or more user attributes. The user device may require the user to provide their consent for providing the one or more user attributes to the third-party device. The user may indicate their consent via a user interface on the user device. Therefore, the method may include the user device receiving an input from the user indicating the user’s consent to share the requested user attributes with the third-party device.

[0032]

[0031] The user may provide their consent based on whether or not the third party has been issued with a third-party public key certificate. Therefore, the method may include the user device retrieving the third- party certificate from the third party registry (i.e. using the purpose ID and user ID, or the hash value of the purpose ID and the pseudonymised user ID). The method may include the user device blocking the request for one or more user attributes if a third-party public key certificate cannot be retrieved. The method may include the user device checking that the requested user attribute(s) are requestable based on the requestable user attribute(s) specified on the third-party public key certificate. The user device may block the request if the one or more of the requested user attribute(s) is not requestable according to the third-party public key certificate.

[0032] The method may include the user device forwarding the request for the one or more user attributes to the trusted server, e.g. in response to receiving the input from the user indicating the user’s consent.

[0033]

[0033] The public key certificate may comprise the one or more user attributes requested by the third- party device. As such, the method may include the trusted server adding the one or more user attributes to the public key certificate. The method may include the trusted server encrypting the one or more user attributes using a third-party public key (i.e. a public key issued to the third party). By encrypting the user attribute(s) on the public key certificate, the personally identifiable information of the user may be protected. The user attribute(s) may be decrypted by the third-party device using a corresponding third- party private key. Where the trusted server comprises the third party registry, the method may include the trusted server retrieving the third-party public key certificate from the third party registry and encrypting the one or more user attributes using the third-party public key from the third-party public key certificate.

[0034]

[0034] The public key certificate may comprise the privacy preserving data structure. As such, the method may include the trusted server adding the privacy preserving data structure (e.g. in a QR code) to the public key certificate. The trusted server may retrieve the privacy preserving data structure from the PPDS registry e.g. by reference to the user reference or the hash value of the user reference.

[0035]

[0035] The method may include generating a private key from the privacy preserving data structure using the subsequently acquired biometric data and decrypting the encrypted user attribute(s) stored in the privacy preserving data structure using the private key. The private key may be discarded after decrypting the encrypted user attribute(s). The one or more user attributes requested by the third-party device may be selected from the decrypted user attribute(s) before generating the public key certificate comprising the one or more user attributes requested by the third-party device.

[0036]

[0036] Preferably, the public key certificate and / or the third-party public key certificate may be generated using the standard X.509v3 format. The additional contents of the public key certificate and / or the third- party public key certificate (e.g. the user attribute(s)) may be included, for example, in the X.509v3 certificate via an extension field that permits any number of additional fields to be added to the certificate.

[0037]

[0037] Where the user device generates the public key, the method may include the user device forwarding the public key to the trusted server with the purpose ID or the hash value of the purpose ID. Alternatively, where the trusted server generates the public key, the method may include the user device forwarding the purpose ID to the trusted server for generating the public key from the privacy preserving data structure.

[0038]

[0038] The public key certificate may be stored in the public key registry using the purpose ID and a user ID as an index. This pairwise combination of purpose ID and the user ID ensures that one and only one public key certificate exists representing a relationship between the user and a particular purpose for the public key certificate. Preferably, the public key certificate may be stored in the public key registry using a hash value of the purpose ID and a pseudonymised user ID as the index. For example, the method may include the user device obtaining a hash value of the purpose ID and pseudonymising the user ID before providing the hash value of the purpose ID and the pseudonymised user ID to the trusted server with the public key. By using a hash value and a pseudonymised ID as the index, the personally identifiable information of the user may be protected.

[0039]

[0039] The steps of obtaining biometric data comprising a facial image of the user and generating the privacy preserving data structure may be performed before the step of receiving the purpose ID generated by the third-party device. Therefore, the method may include the user device retrieving the privacy preserving data structure in response to the user device receiving the purpose ID. For example, the user device may retrieve the local copy of the privacy preserving data structure stored on the user device. Alternatively, the trusted server may retrieve the privacy preserving data structure from the PPDS registry in response to receiving the purpose ID or a hash value of the purpose ID, e.g. by reference to the user reference or the hash value of the user reference.

[0040]

[0040] The method may include the third-party device requesting the public key certificate from the trusted server. The public key registry may store multiple public key certificates (i.e. for different users) indexed by the same purpose ID assigned to the third party. The third-party device may request one or more public key certificates (e.g. including the public key certificate issued to the user) by providing the purpose ID or the hash value of the purpose ID. Therefore, the method may include the trusted server retrieving a plurality of public key certificates (for all users pairwise for the purpose ID) from the public key registry. The third-party device may store a local public key registry for storing the retrieved public key certificates.

[0041]

[0041] The step of obtaining the public key certificate from the issuer may include the trusted server generating the public key certificate. The method may include the trusted server digitally signing the public key certificate using a private key of the issuer. This enables the authenticity of the public key certificate to be verified using a corresponding public key root certificate of the issuer.

[0042]

[0042] The public key certificate may comprise an expiry date. Additionally, or alternatively, the public key certificate may comprise a uniform resource locator (URL) address of a certificate revocation list. This allows the third party to determine whether or not the public key certificate has been revoked. The certificate revocation list may be stored by the trusted server in a certificate revocation list registry.

[0043]

[0043] In a second aspect there is provided a computer-implemented method of authenticating a user using a public key certificate issued according to the method of the first aspect, the method including: the user device receiving data generated by the third-party device and obtaining subsequently acquired biometric data comprising the facial image of the user; the user device or the trusted server generating the private key from the privacy preserving data structure using the subsequently acquired biometric data and the purpose ID; the user device or the trusted server generating a digital signature by signing the generated data using the private key; the third-party device receiving the digital signature and the public key certificate and verifying the digital signature using the generated data and the public key from the public key certificate.

[0044] By signing the generated data using the private key, the user can prove their identity to the third party because the correct private key can only be generated by the user using their biometric data (and the purpose ID). Since the public key certificate is accessible by the third-party device, the third-party device can verify the digital signature using the public key certificate. Effectively, the third party is able to authenticate the user biometrically without handling any biometric information.

[0044]

[0045] Additionally, the trusted server is not required to perform the steps of authenticating the user once the public key certificate has already been issued. Provided that the third-party device has a copy of the public key certificate, and the user device has a copy of the privacy preserving data structure, the method of the second aspect can be performed without the assistance of the trusted server. This may allow the third-party device to authenticate the user more efficiently.

[0045]

[0046] The generated data may be a random challenge or a session ID generated by the third-party device. The user device may receive the generated data from the third-party device by scanning a QR code displayed by the third-party device, e.g. on a website. The same QR code may include the purpose ID and / or the request for the one or more user attributes as described above in the method of the first aspect. The generated data may be an alphanumeric code.

[0046]

[0047] The third-party device may enter a verification mode for displaying the QR code. This may be controlled by the third party operating the third-party device. In the verification mode, the third party may input the one or more user attributes to be requested. Alternatively, the one or more user attributes to be requested may be pre-configured.

[0047]

[0048] Where the third-party public key certificate includes the submission end-point URL, the method may include the user device retrieving the third-party public key certificate. Where the third-party public key certificate is stored in the third party registry, the user device may retrieve the third-party public key certificate via the trusted server by reference to the purpose ID and the user ID, or the hash value of the purpose ID and the pseudonymised user ID. If the third-party public key certificate cannot be retrieved then the user device may return an error indicating that the third-party public key certificate does not exist.

[0048]

[0049] The method may include the user device or the trusted server submitting the digital signature to the submission end-point URL. Therefore, the third-party device may receive the digital signature via the submission end-point URL.

[0049]

[0050] The method of the second aspect may include the user device receiving the purpose ID. The user device may receive the purpose ID by scanning a QR code displayed by the third-party device, e.g. on a website. The same QR code may include the challenge as described above.

[0050]

[0051] The method may include the user device obtaining a hash value of the generated data, e.g. using a SHA256 hashing algorithm. Therefore, the step of generating the digital signature may comprise signing hash value of the generated data. The method may include the third-party device obtaining the hash value of the generated data, i.e. using the same hashing algorithm. Therefore, the step of verifying the digital signature may include the third-party device using the hash value of the generated data and the public key.

[0052] Obtaining the subsequently acquired biometric data may include the user device recording the subsequently acquired biometric data using the biometric sensor on the user device. The user device may prompt the user to input their biometric data using the biometric sensor, e.g. in response to receiving the generated data and / or the purpose ID.

[0051]

[0053] In some examples, the method may include the user device retrieving its local copy of the privacy preserving data structure, e.g. in response to receiving the generated data and / or the purpose ID. The private key may be generated from the local copy of the privacy preserving data structure.

[0052]

[0054] In other examples, the method may include the user device requesting the privacy preserving data structure from the trusted server, e.g. in response to receiving the generated data and / or the purpose ID. The user device may request the privacy preserving data structure by providing the user reference or the hash value of the user reference. Therefore, the method may include the trusted server retrieving the privacy preserving data structure from the privacy preserving data structure registry, e.g. using the user reference or the hash value of the user reference.

[0053]

[0055] In some examples, where the private key is generated by the trusted server, the method may include the user device providing the subsequently acquired biometric data to the trusted server with the generated data or the hash value of the generated data. Subsequently, the trusted server may sign the generated data or the hash value of the generated data using the private key. The method may further include the trusted server providing the digital signature to the user device or providing the digital signature to the third-party device.

[0054]

[0056] The third-party device may receive the digital signature from the user device or from the trusted server. The user device may display a QR code encoding the digital signature. The QR code may be displayed on a screen of the user device. The third-party device may receive the digital signature by scanning the QR code displayed by the user device.

[0055]

[0057] In some examples, the method may include the third-party device retrieving its copy of the public key certificate (for the user), e.g. in response to receiving the digital signature. The public key certificate may be retrieved from the local public key registry stored by the third-party device.

[0056]

[0058] In other examples, the method of the second aspect may include the third-party device requesting the public key certificate from the trusted server, e.g. in response to receiving the digital signature. The third-party device may request the public key certificate by providing the purpose ID and user ID, or by providing the hash value of the purpose ID and the pseudonymised user ID. Therefore, the method may include the trusted server retrieving the public key certificate from the public key registry, e.g. using the purpose ID and the user ID, or using the hash value of the purpose ID and the pseudonymised user ID.

[0057]

[0059] Where the public key certificate comprises the one or more user attributes requested by the third- party device in the method of the first aspect, the method of the second aspect may include the third-party device decrypting the one or more user attributes from the public key certificate using the third-party private key. The third party may determine that the user has the requested user attribute(s) based on the one or more user attributes specified on the public key certificate.

[0058]

[0060] In some examples, the method may include the user device attempting to access a service provided by the third party, e.g. a sign-in page of a website controlled by the third party. The third-party device may provide the generated data (i.e. the session ID) to the user device in response to the user device attempting to access the sign-in page. The method may include the third-party device granting the user access to the service (e.g. signing the user into the website), in response to verifying that the digital signature belongs to the user. The method may include the third-party device refusing the user access to the service, in response to being unable to verify that the digital signature belongs to the user.

[0059]

[0061] In some examples, the method may include the user device receiving a document or file from the third-party device. For example, the method may be performed by providing a document or file to be signed by the user as the generated data. Thus, the digital signature may function as an acknowledgement and / or approval of the document or file by the user. The third-party may be a bank or other financial institution, wherein the document or file indicates a transaction to be approved by the user.

[0060]

[0062] In other examples, the third-party device may be a third-party server and the method may be used to establish a mutual Transport Layer Security (TLS) connection between the user device and the third-party server, e.g. using a standard Client-authenticated TLS handshake (RFC 5246 - 7.3, 7.4). For example, the user (client) device and the third-party server may first exchange hello messages, e.g. the user device and the third-party server may agree on algorithms to be used in the method via the hello messages. The third-party server may hold a server public key certificate (e.g. the third-party public key certificate) which specifies the third-party server (i.e. a URL address), a server public key, and a digital signature of an issuer (e.g. the trusted server) created using the issuer’s private key. Therefore, the method may include the third-party server sending the server public key certificate to the user device via a server certificate message. The method may include the user device verifying the digital signature using a public key from a root certificate of the issuer corresponding to the issuer’s private key. Therefore, the user can authenticate the third-party server from the server public key certificate.

[0061]

[0063] The third-party server may send a client certificate request message to the user device. In response to receiving the client certificate request message, the user device may send the public key certificate of the user to the third-party server via a client certificate message. The method may include the third-party server verifying the digital signature in the public key certificate using the public key in the root certificate of the issuer.

[0062]

[0064] The public key certificate may include the privacy preserving data structure (i.e. as an additional X.509 v3 extension). This would be in addition to the public key. Where the public key certificate includes the privacy preserving data structure, the user device may retrieve the privacy preserving data structure from the public key certificate. Alternatively, the user device may retrieve the privacy preserving data structure from the PPDS registry via the trusted server or the user device may retrieve a local copy of the privacy preserving data structure stored on the user device.

[0065] The user device may receive the purpose ID from the third-party server, e.g. via the hello message, the server certificate message, or the client certificate request message. Generating the digital signature may include the user device signing one or more previous messages exchanged between the user device and the third-party server. The generated data may therefore comprise one or more of: the hello messages; the server certificate message; and the client certificate request message. Preferably, the user device signs all previous messages between the user device and the third-party server (i.e. in the handshake protocol).

[0063]

[0066] The user device may send the digital signature to the third-party server via a certificate verify message. The method may include the third-party device verifying the digital signature using the public key from the public key certificate.

[0064]

[0067] The user device and the third-party server may agree on a session key, e.g. the session key being computed based on the server public key from the server public key certificate and the user’s public key from the user’s public key certificate. For example, the session key may be computed using the Diffie Hellman (DH) or the Elliptic Curve Diffie Hellman (ECDH) algorithms. After verifying the digital signature in the certificate verify message, the user device and the third-party server may exchange messages encrypted using the session key. The session key may be a symmetric key for decrypting messages encrypted using the session key.

[0065]

[0068] By using the public key certificate issued by the trusted server to verify the digital signature provided by the user device, the third-party server is able to authenticate the user biometrically because the private key can only be generated from the user’s biometric data.

[0066]

[0069] In a third aspect there is provided a computer-implemented method of encrypted data communication using a public key certificate issued according to the method of the first aspect, the method including an encryption phase performed by the third-party device and a decryption phase performed by the user device, wherein the encryption phase includes the steps of: generating data to be viewed by the user device; receiving the public key certificate; and encrypting the generated data using the public key from the public key certificate, wherein the decryption phase includes the steps of: receiving the encrypted data; obtaining subsequently acquired biometric data comprising the facial image of the user; generating the private key from the privacy preserving data structure using the subsequently acquired biometric data and the purpose ID; and decrypting the encrypted data using the private key.

[0067]

[0070] By encrypting the generated data using the public key, the data can be protected from other parties while sending the data the user. Only the user is able to decrypt the encrypted data because the private key required to do so can only be generated by the user using their biometric data. Since the public key certificate is accessible by the third-party device, the third-party device can send data to the user device securely using the public key certificate. Effectively, the third party can ensure that only the user can receive the unencrypted data without handling any biometric information of the user.

[0068]

[0071] Additionally, the trusted server is not required to perform the steps of encrypting and decrypting the data once the public key certificate has already been issued. Provided that the third-party device has a copy of the public key certificate, and the user device has a copy of the privacy preserving data structure, the method of the third aspect can be performed without the assistance of the trusted server. This may allow the third-party device to communicate securely with the user device more efficiently.

[0069]

[0072] The method of the third aspect may include the third-party device providing a digital signature by signing the data using a third-party private key. The method may include the third-party device obtaining a hash value of the data and providing the digital signature by signing the hash value of the data using the third-party private key. The signature may be subsequently combined with the generated data. Encrypting the generated data may therefore include encrypting the data and the digital signature.

[0070] Therefore, the method may further include the user device retrieving the third-party public key certificate using the purpose ID, and verifying the digital signature using the decrypted data and the third-party public key from the third-party public key certificate.

[0071]

[0073] In a fourth aspect there is provided a computer-implemented method of data communication using a third-party public key certificate issued according to the method of the first aspect, the method including the third-party device: generating data to be viewed by the user device; providing a digital signature from the data using a third-party private key; and sending the data and the digital signature to the user device with the purpose ID, wherein the method further includes the user device: receiving the data with the digital signature and the purpose ID; retrieving the third-party public key certificate using the purpose ID; and verifying the digital signature using the data and the third-party public key from the third-party public key certificate.

[0072]

[0074] By providing the digital signature for the user to verify, the user is able to verify that the data originates from the third party. The data may be a message from the third party to the user. Additionally, provided that the user device has a copy of the third-party public key certificate, the method of the fourth aspect can be performed without the assistance of the trusted server. This may allow the third-party device to communicate with the user device more efficiently.

[0073]

[0075] In some examples, the method of the fourth aspect may include the third-party device receiving the public key certificate and encrypting the data and the digital signature using the public key from the public key certificate. Therefore, the method may further include the user device: receiving the encrypted data; obtaining subsequently acquired biometric data comprising the facial image of the user; generating the private key from the privacy preserving data structure using the subsequently acquired biometric data and the purpose ID; and decrypting the encrypted data using the private key to obtain the unencrypted data and the digital signature.

[0076] Optional features of the third and fourth aspects are described below.

[0074]

[0077] In some examples, the method of the third or fourth aspect may include the third-party device retrieving its copy of the public key certificate. The public key certificate may be retrieved from the local public key registry stored by the third-party device.

[0075]

[0078] In other examples, the method of the third or fourth aspect may include the third-party device requesting the public key certificate from the trusted server. The third-party device may request the public key certificate by providing the purpose ID and the user ID, or by providing the hash value of the purpose ID and the pseudonymised user ID. Therefore, the method may include the trusted server retrieving the public key certificate from the public key registry, e.g. using the purpose ID and the user ID, or using the hash value of the purpose ID and the pseudonymised user ID.

[0076]

[0079] The encrypted data may be received along with the purpose ID. The method may include the third-party device transmitting the encrypted data (e.g. and the purpose ID) to the user device. Alternatively, the encrypted data (e.g. and the purpose ID) may be encoded in a QR code displayed by the third party, e.g. on a website. The user device may scan the QR code to receive the encrypted data (e.g. and the purpose ID). Alternatively, the encrypted data (e.g. and the purpose ID) may be sent to the user via email or another communications channel. The data may be a message from the third party to the user.

[0077]

[0080] Obtaining the subsequently acquired biometric data may include the user device recording the subsequently acquired biometric data using the biometric sensor on the user device. The user device may prompt the user to input their biometric data using the biometric sensor, e.g. in response to receiving the encrypted data and / or the purpose ID.

[0078]

[0081] In some examples, the method may include the user device retrieving its local copy of the privacy preserving data structure, e.g. in response to receiving the encrypted data and / or the purpose ID. The private key may be generated from the local copy of the privacy preserving data structure.

[0079]

[0082] In other examples, the method may include the user device requesting the privacy preserving data structure from the trusted server, e.g. in response to receiving the encrypted data and / or the purpose ID. The user device may request the privacy preserving data structure by providing the user reference or the hash value of the user reference. Therefore, the method may include the trusted server retrieving the privacy preserving data structure from the privacy preserving data structure registry, e.g. using the user reference or the hash value of the user reference.

[0080]

[0083] In some examples, where the private key is generated by the trusted server, the method may include the user device providing the subsequently acquired biometric data to the trusted server with the encrypted data. Subsequently, the trusted server may decrypt the encrypted data using the private key. The method may further include the trusted server providing the unencrypted data to the user device.

[0081]

[0084] In a fifth aspect, there is provided a computer-implemented method of peer-to-peer verification between a user device and a third-party device, the method including: the third-party device requesting one or more user attributes from the user device; the user device obtaining a privacy preserving data structure storing the requested one or more user attributes as encrypted metadata, wherein the privacy preserving data structure was generated using biometric data comprising a facial image of the user and the metadata was encrypted using a public key generated from the privacy preserving data structure using the biometric data; the third-party device receiving the privacy preserving data structure from the user device; the third-party device obtaining subsequently acquired biometric data comprising the facial image of the user, generating a private key from the privacy preserving data structure using the subsequently acquired biometric data, and decrypting the encrypted metadata using the private key to obtain the requested one or more user attributes.

[0082]

[0085] By obtaining the requested user attribute(s) directly from the privacy preserving data structure, the third-party device is able to authenticate the user as the owner of the user attribute(s).

[0083]

[0086] The method may include obtaining the biometric data comprising the facial image of the user and generating the privacy preserving data structure using the biometric data. The method may further include generating the public key from the privacy preserving data structure using the biometric data, encrypting the requested one or more user attributes and storing the requested one or more user attributes in the privacy preserving data structure as the encrypted metadata.

[0084]

[0087] Before generating the privacy preserving data structure, the method may include retrieving another privacy preserving data structure, e.g. from a PPDS registry stored by a trusted server. The PPDS registry may be the PPDS registry as described above in the first aspect.

[0085]

[0088] The other privacy preserving data structure may store a plurality of user attributes as encrypted metadata. The other privacy preserving data structure was generated using previously acquired biometric data comprising the facial image of the user and the metadata was encrypted using another public key generated from the other privacy preserving data structure using the previously acquired biometric data. The other privacy preserving data structure may be the privacy preserving data structure as described in the first aspect.

[0086]

[0089] The method may include generating another private key from the other privacy preserving data structure using the biometric data, decrypting the plurality of user attributes and selecting the requested one or more user attributes from the decrypted plurality of user attributes.

[0087]

[0090] In a sixth aspect there is provided a public key infrastructure system for issuing a public key certificate, the system comprising a user device, a trusted server comprising a public key registry, and a third-party device operated by a third party, wherein the user device is configured to: obtain biometric data comprising a facial image of the user; and receive a purpose ID from the third-party device, wherein the user device and / or the trusted server is / are configured to generate a privacy preserving data structure using the biometric data, wherein the user device and / or the trusted server is / are configured to generate a public key from the privacy preserving data structure using the biometric data and the purpose ID, wherein a private key corresponding to the public key can be generated from the privacy preserving data structure using the purpose ID and subsequently acquired biometric data comprising the facial image of the user, and wherein the trusted server is configured to: obtain a public key certificate from an issuer, the public key certificate comprising the public key and a digital signature of the issuer; and store the public key certificate in the public key registry.

[0088]

[0091] In an seventh aspect there is provided a user device comprising: a user interface, a biometric sensor, a communications interface, one or more processors, and a memory containing machine executable instructions which, when executed on the one or more processors, cause the one or more processors to: receive a purpose ID; obtain biometric data comprising a facial image of the user, generate a privacy preserving data structure using the biometric data, generate a public key from the privacy preserving data structure using the biometric data and the purpose ID, wherein a private key corresponding to the public key can be generated from the privacy preserving data structure using the purpose ID and subsequently acquired biometric data comprising the facial image of the user.

[0089]

[0092] In an eighth aspect, there is provided a trusted server comprising: a network interface, one or more processors, and a memory storing a public key registry and containing machine executable instructions which, when executed on the one or more processors, cause the one or more processors to: receive a purpose ID and biometric data comprising a facial image of the user, generate a privacy preserving data structure using the biometric data, generate a public key from the privacy preserving data structure using the biometric data and the purpose ID, wherein a private key corresponding to the public key can be generated from the privacy preserving data structure using the purpose ID and subsequently acquired biometric data comprising the facial image of the user; obtain a public key certificate from an issuer, the public key certificate comprising the public key and a digital signature of the issuer; and store the public key certificate in the public key registry.

[0090]

[0093] In a ninth aspect, there is provided a third-party device comprising: a communications interface, one or more processors, and a memory containing machine executable instructions which, when executed on the one or more processors, cause the one or more processors to: generate data; provide the generated data to a user device operated by a user; receive a digital signature from the user device, the digital signature obtaining by signing the generated data using a private key, wherein the private key was generated from a privacy preserving data structure using a purpose ID and biometric data comprising a facial image of the user, wherein the privacy preserving data structure was generated using the biometric data; receive a public key certificate comprising a public key corresponding to the private key, wherein the public key was generated from the privacy preserving data structure using the purpose ID and subsequently acquired biometric data comprising the facial image of the user; and verify the digital signature using the generated data and the public key from the public key certificate.

[0091]

[0094] Further aspects provide: a computer program comprising code which, when run on a computer, causes the computer to perform any combination of the steps of at least one of the first aspect, the second aspect, the third aspect, the fourth aspect, and / or the fifth aspect; and / or a computer readable medium storing a computer program comprising code which, when run on a computer, causes the computer to perform any combination of the steps of at least one of the first aspect, the second aspect, the third aspect, the fourth aspect, and / or the fifth aspect.

[0092] Brief Description of the Figures

[0093]

[0095] Embodiments of the invention will now be discussed by way of example with reference to the accompanying figures in which:

[0094] Figure 1 shows a schematic representation of a public key infrastructure system.

[0095] Figure 2 shows a schematic representation of a user device of the public key infrastructure system.

[0096] Figure 3 shows a schematic representation of a trusted server of the public key infrastructure system.

[0097] Figure 4 shows a schematic representation of a third-party device of the public key infrastructure system.

[0098] Figure 5 shows a flow chart of the steps of a method of enrolling a set of user attributes in an attribute registry stored by the trusted server of Figure 3.

[0099] Figure 6 shows a flow chart of the steps of a method of enrolling the user in a privacy preserving data structure registry stored by the trusted server of Figure 3.

[0100] Figure 7 shows a flow chart of the steps of a method of registering a third-party public key certificate in a third party registry stored by the trusted server of Figure 3.

[0101] Figure 8 shows an example of a public key certificate which may be issued using the public key infrastructure system.

[0102] Figure 9 shows a flow chart of the steps of a method of registering the public key certificate of Figure 5 in the public key infrastructure system of Figure 1 .

[0103] Figure 10 shows a flow chart of the initial steps of providing a digital signature in a method of authenticating a user in the public key infrastructure system of Figure 1. Figure 11 shows a flow chart of the subsequent steps of verifying the digital signature provided by the method of Figure 10.

[0104] Figure 12 shows a flow chart of the initial steps of a method of offline peer-to-peer verification between the user device of Figure 2 and the third-party device of Figure 4.

[0105] Figure 13 shows a flow chart of the subsequent steps of the method of offline peer-to-peer verification from Figure 12.

[0106] Figure 14 shows a flow chart of the initial steps of a method of online peer-to-peer verification between the user device of Figure 2 and the third-party device of Figure 4.

[0107] Figure 15 shows a flow chart of the subsequent steps of the method of online peer-to-peer verification from Figure 14.

[0108] Figure 16 shows a flow chart of the steps of a method of data communication in the public key infrastructure system of Figure 1.

[0109] Figure 17 shows a flow chart of the main steps of an encryption phase in a method of encrypted data communication in the public key infrastructure system of Figure 1 .

[0110] Figure 18 shows a flow chart illustrating the main steps of a decryption phase in the method of encrypted data communication.

[0111] Detailed Description of the Embodiments

[0112]

[0096] Aspects and embodiments of the present invention will now be discussed with reference to the accompanying figures. Further aspects and embodiments will be apparent to those skilled in the art. All documents mentioned in this text are incorporated herein by reference.

[0113]

[0097] Figure 1 shows a schematic representation of a public key infrastructure system 100. The public key infrastructure system 100 includes a user device 120, a trusted server 140, and a third-party device 160 operated by a third-party. Preferably, the trusted server 140 is controlled by an issuer which is usually a government organization having control over civil registers, population registers, and national IDs. As such, the issuer may act as a root certificate authority for issuing foundational IDs. A foundational ID refers to a unique legal ID issued to a person which enables that person to prove their identity using credentials recognized by law. Alternatively, it is contemplated that the trusted server 140 acts as a trusted mediator between an issuer device (not shown) controlled by the issuer, the user device 120 and third-party device 140.

[0114]

[0098] Figure 2 shows a schematic representation of the user device 120, which is typically a smartphone belonging to a user. As such, the user device 120 has a user interface 122 for receiving information entered by the user. The user device 120 also includes a biometric sensor 124 which can be used to obtain a facial image of the user. A built-in camera, such as a front-facing camera, can be used as the biometric sensor 124. The user device 120 also has a communications interface 126 which is configured to transmit data to the trusted server 140, as discussed in detail below. The user device 120 also has a processor 128 for running software stored in a memory 130 of the user device 120.

[0115] Preferably, the software is installed as a mobile app for controlling a digital wallet.

[0116]

[0099] Figure 3 shows a schematic representation of the trusted server 140 of the public key infrastructure system 100. The trusted server 140 includes a network interface 142 for exchanging data with the user device 120 and the third-party device 160, a processor 144, and a memory 146. The memory 146 stores a public key registry 148 for storing public key certificates issued by the issuer. Optionally, as discussed in detail below, the memory 146 stores one or more of: an attribute registry 149, a third party registry 150, a privacy preserving data structure (PPDS) registry 151 , and a certificate revocation list 152.

[0117]

[0100] Figure 4 shows a schematic representation of the third-party device 160 of the public key infrastructure system 100. The third-party device 160 includes a communications interface 162 configured to exchange data with the trusted server 140, as discussed in detail below. The third-party device 160 also has a processor 164 for running software stored in a memory 166 of the third-party device 160. Optionally, the third-party device 160 stores a local public key registry 168 in the memory 166. In some examples, the software is installed as a mobile app for controlling a digital wallet. Optionally, the third-party device 160 may also include a user interface 170 and a biometric sensor 172. As described below, the user interface 170 and biometric sensor 172 may be used by the third party during peer-to-peer communication with the user device 120. In other examples, the third-party device 160 is a server hosting a website for exchanging data with the user device 120, e.g. using a cloud wallet.

[0118]

[0101] Figure 5 shows a flow chart of the steps of a method of enrolling a set of user attributes in the attribute registry 149 stored by the trusted server 140. These user attributes are to be registered with a digital ID (i.e. a foundational elD) issued to the user in the public key infrastructure system 100. Therefore, in a first step S1 , it is determined which user attributes are to be enrolled. The attributes may include information available at the time of the user’s birth such as date of birth, location of birth, or the identities of the user’s birthparents, in addition to information which may change over the user’s lifetime such as the user’s name, address, or legal guardians.

[0119]

[0102] Subsequently, each of the determined attributes is stored in the attribute registry 149 in step S2. The stored attributes may be indexed by reference to the user. For example, the user reference may be the user’s name or a unique national identity / insurance number. Following the enrolment of the user’s attributes, the trusted server 140 is able to retrieve the user’s attributes upon request.

[0120]

[0103] Figure 6 shows a flow chart of the steps of a method of enrolling the user in a privacy preserving data structure registry stored by the trusted server of Figure 3. In step S3, the user device 120 obtains biometric data comprising the facial image of the user via the biometric sensor 124. The user may be prompted by the mobile app to scan or photograph their face using the built-in phone camera.

[0121]

[0104] In step S4, the biometric data is used to generate a public key and a corresponding private key. Preferably, the public-private key pair is generated by the trusted server 140, in which case the user device 120 provides the biometric data to the trusted server 140 before step S4. Alternatively, the publicprivate key pair may be generated by the user device 120 and forwarded to the trusted server 140.

[0122]

[0105] Optionally, the user may input a password for generating the public-private key pair. Specifically, the trusted server 140 may receive the password from the user device 120, the password being inputted by the user via the user interface 122. Accordingly, in step S4, the public-private key pair may be generated using the password in addition to the biometric data. This allows the user to additionally protect the generation of the private key from the PPDS by requiring a password to do so in addition to their facial image.

[0123]

[0106] Next, in step S5, the trusted server 140 retrieves the user’s attributes from the attribute registry 149. In step S6, the retrieved attributes are encrypted using the public key generated in step S4. As such, the encrypted attributes can only be decrypted using the corresponding private key. Once, the public key has been used for encrypting the user attributes, the public key is discarded in step S7. The private key generated in step S4 is also discarded. The private key can be discarded immediately after generating the public-private key pair or it can be discarded when the public key is discarded.

[0124]

[0107] In step S8, a privacy preserving data structure is generated. The privacy preserving data structure functions as the digital ID (i.e. the foundational elD) of the user in the public key infrastructure system 100. The encrypted attributes are stored in the privacy preserving data structure as metadata. By storing the encrypted metadata, it can later be determined whether or not the correct private key has been generated because only the correct private key is able to decrypt the encrypted metadata. That is, if the biometric data used to create the privacy preserving data structure is from the same person as the subsequently acquired biometric data used to generate (i.e. regenerate) the private key, then the private key corresponds to the public key which was used to encrypt the user attributes in step S6. If the password was also used to generate the public-private key pair in step S4, then the password is required in addition to the subsequently acquired biometric data to generate the correct private key from the privacy preserving data structure.

[0125]

[0108] In step S9, the trusted server 140 stores the privacy preserving data structure in the PPDS registry 151 . The privacy preserving data structure may be indexed by reference to the user. For example, the user reference may be the user’s name or a unique national identity / insurance number. Alternatively, the privacy preserving data structure may be indexed using a hash value to protect the user’s identity in the PPDS registry 151 for improved security. For example, the hash value may be a hash value of the user’s name, obtained using a SHA256 hashing algorithm.

[0126]

[0109] Following the enrolment of the privacy preserving data structure, the trusted server 140 is able to retrieve the privacy preserving data structure upon request by reference to the index. For example, the user device 120 may provide the user reference to the trusted server 140 for retrieving the privacy preserving data structure. This may be for accessing the user attributes stored as metadata in the privacy preserving data structure. Additionally, the trusted server 140 may return a copy of the privacy preserving data structure to the user device 120. Thus, the user device 120 may store a local copy of the privacy preserving data structure in the memory 130.

[0110] Figure 7 shows a flow chart of the steps of a method of registering a third-party public key certificate in the third party registry 150 stored by the trusted server 140. In a first step S10, the third- party device 160 submits a third-party public key (this may be in the form of a Certificate Signing Request), a set of requestable user attributes, and preferably a submission end-point URL to the trusted server 140. The third-party public key corresponds to a private key held by the third party. The requestable user attributes are types of user attributes which the third party requires access to for its operations involving its users. For example, a bank may need to check the user’s address in order to set up a new bank account for the user. The submission end-point URL is a URL address controlled by the third-party device 160 and intended for its users to submit data to the third party directly, as discussed in detail below.

[0127]

[0111] In step S11 , the trusted server 140 approves the requestable user attributes before assigning a purpose ID to the third party in step S12. The purpose ID is unique to the third party and optionally a particular type of transaction between the user and the third party. Accordingly, the issuer which controls the trusted server 140 issues a third-party public key certificate to the third party which can be made available to the user as described in the following methods.

[0128]

[0112] In step S13, the third-party public key certificate is generated by the trusted server 140. The third-party public key certificate specifies the third-party public key submitted by the third-party device 160 in step S10 as well as the requestable user attributes approved by the trusted server 140 in step S11. Optionally, the submission end-point URL is also specified on the third-party public key certificate if it was submitted by the third-party device 160.

[0129]

[0113] In step S14, the trusted server 140 provides a digital signature of the issuer by signing the third- party public key certificate with the issuer’s private key. This digital signature can be verified by the user device 120 using the issuer’s public key which can be obtained from the root certificate self-signed by the issuer.

[0130]

[0114] Preferably, the third party registry 150 is indexed by hash values of respective purpose IDs for each third party with a third-party public key certificate. Therefore, in step S15, the trusted server 140 obtains a hash value of the purpose ID assigned to the third party in step S12, and in step S16 the trusted server 140 stores the third-party public key certificate indexed by the hash value of the purpose ID.

[0131]

[0115] Following the registration of the third-party public key certificate, the trusted server 140 is able to retrieve the third-party public key certificate upon request by reference to the hash value of the corresponding purpose ID. For example, the user device 120 may provide the purpose ID or its hash value to the trusted server 140 for retrieving the third-party public key certificate.

[0132]

[0116] In another embodiment, instead of having a single certificate corresponding to a purpose ID, a plurality of third-party public key certificates may be created on a per user basis and for each of a pair of a purpose ID and a user ID. In such an embodiment, the third-party public key certificates would be stored in the third party registry 150 and indexed by both purpose ID and user ID (e.g. a hash value of the purpose ID and / or a pseudonymised user ID).

[0117] Figure 8 shows an example of a public key certificate 180 which may be issued to a user using the public key infrastructure system 100. A method of registering the public key certificate 180 in the public key infrastructure 100 will now be described in relation to the interactions between the user device 120, the trusted server 140 and the third-party device 160.

[0133]

[0118] Figure 9 shows a flow chart illustrating the main steps of the method. In a first step S17, the user device 120 receives the purpose ID which is unique to the purpose of the interaction between the user and the third party. The user device 120 also receives a request for one or more user attributes. For example, the third party may request the user’s name 184, address 186, and date of birth 188. In some examples, the purpose ID and the request are encoded in a QR code by the third party and received by the user device 120 by scanning the QR code. The QR code is preferably displayed on the website hosted by the third-party server 160. The purpose ID and the request are then forwarded to the trusted server 140.

[0134]

[0119] In step S18, the trusted server 140 retrieves the third-party public key certificate from the third party registry 150 by reference to the purpose ID. Specifically, the trusted server 140 obtains the hash value of the purpose ID which is used as the index for storing the third-party public key certificate. The third-party public key or the third-party public key certificate is then transmitted to the user device 120. The requestable attributes specified on the third-party public key certificate are checked by the trusted server 140 and / or the user device 120 to determine whether or not the third party was pre-approved for accessing the requested user attributes, when the third-party public key certificate was issued in the method of Figure 7. Upon receiving the purpose ID and the request, in step S19, the user device 120 requires the user to provide their consent for sending the requested user attribute(s) to the third-party device 160. This may be inputted via the user interface 122 and forwarded to the trusted server 140.

[0135]

[0120] In step S20, the privacy preserving data structure of the user is retrieved. For example, the privacy preserving data structure may be retrieved by the trusted server 140 from the PPDS registry 151 or the user device 120 may retrieve its local copy of the privacy preserving data structure.

[0136]

[0121] In step S21 , the user device 120 obtains subsequently acquired biometric data comprising the facial image of the user via the biometric sensor 124. The user may be prompted by the mobile app to scan or photograph their face using the built-in phone camera after receiving the privacy preserving data structure.

[0137]

[0122] In step S22, the subsequently acquired biometric data is used to generate a new private key from the privacy preserving data structure. Preferably, this step is performed by the trusted server 140, but it is contemplated that the private key may be generated by the user device 120 using a locally cached privacy preserving data structure. Where the privacy preserving data structure is generated by the trusted server 140, the user device 120 first sends the subsequently acquired biometric data to the trusted server 140 via the communications interface 126 by connecting to the network interface 142 of the trusted server 140.

[0123] In step S23, the encrypted user attributes stored as metadata in the privacy preserving data structure are decrypted using the new private key generated in step S22. The user attributes requested by the third party are then selected from the decrypted user attributes and the new private key is discarded.

[0138]

[0124] In step S24, the trusted server 140 generates a new public key from the privacy preserving data structure using the purpose ID and the subsequently acquired biometric data. A corresponding private key can be generated later from the privacy preserving data structure using the same purpose ID and (other) subsequently acquired biometric data. Additional public keys can be generated from the same privacy preserving data structure using the biometric data and respective purpose IDs. Specifically, each purpose ID is used as a unique string to generate a different public key, thereby ensuring that each generated public key can only be used for a specific purpose. As such, the purpose ID serves as a pairwise functional ID which avoids the user having to present their (linkable) foundational ID across different systems. In so doing, the purpose ID facilitates privacy preservation by preventing other parties from being able to track the user’s activities by observing the same public key or ID across different databases.

[0139]

[0125] Next, the user attributes selected from the decrypted user attributes based on the request from the third party are re-encrypted using the third-party public key from the third-party public key certificate retrieved in step S18. In step S25, a public key certificate 180 specifying the user’s public key 182 and the re-encrypted user attributes 184, 186, 188 is generated. The specified user attribute(s) 184, 186, 188 can be decrypted by the third-party device 160 using the third-party private key corresponding to the third- party public key. This protects the user’s privacy by preventing other parties from extracting the user’s personal information from the public key certificate 180. Where the trusted server 140 is controlled by the issuer, the public key certificate 180 is generated by the trusted server 140. Alternatively, where the trusted server 140 acts as a mediator on behalf of the issuer, the trusted server 140 may send a request to the issuer device to generate the public key certificate 180. The public key certificate may be generated using the standard X.509(v3) format.

[0140]

[0126] The public key certificate 180 may be referred to as a ‘face certificate’ because the private key corresponding to the public key 182 can only be generated using subsequently acquired biometric data comprising a facial image of the user. The user is not required to share their biometric data with the third party since the user can be authenticated instead using the public key 182 specified in the public key certificate 180. The issuer is trusted by the third party to authenticate the user biometrically before issuing the public key certificate 180.

[0141]

[0127] Preferably, the trusted server 140 (or issuer device) provides a digital signature 194 of the issuer by signing the public key certificate 180 with the issuer’s private key. This digital signature 194 can be verified by the third party using the issuer’s public key which can be obtained from the root certificate selfsigned by the issuer.

[0142]

[0128] The public key certificate 180 may further specify an expiry date 190, which can be used by the third party to determine whether or not the public key certificate 180 is still valid. Additionally, or alternatively, the public key certificate may include a URL address 192 of the certificate revocation list 152 stored by the trusted server 140. The third-party device 160 can look for the public key certificate 180 on the certificate revocation list 152 to determine whether or not the public key certificate 180 has been revoked, e.g. prior to the expiry date 190.

[0143]

[0129] Next, in step S26, the trusted server 140 stores the public key certificate 180 in the public key registry 148, indexed using hash value of the purpose ID and the pseudonymised user ID.

[0144]

[0130] The user device 120 and / or the third-party device 160 may retrieve the public key certificate 180 from the trusted server 140. In response to receiving a request for the public key certificate 180 by reference to the corresponding purpose ID and user ID, the trusted server 120 may retrieve the public key certificate 180 from the public key registry 148 and return a copy of the public key certificate 180. Where the third-party device 160 includes the local public key registry 168, the method may include the third- party device 160 caching a copy of the public key certificate 180 in the local public key registry 168. This allows the third-party device 160 to authenticate the user without involving the trusted server 140 in future transactions.

[0145]

[0131] A method of authenticating the user in the public key infrastructure 100 will now be described in relation to the interactions between the user device 120, the third-party device 160, and optionally the trusted server 140. Figure 10 shows a flow chart of the initial steps of providing a digital signature and Figure 11 shows a flow chart of the subsequent steps of verifying the digital signature. These methods follow the method of registering the public key certificate 180 shown in Figure 9.

[0146]

[0132] In step S27, the user attempts to access a service provided by the third party. For example, this may be a website hosted by the third-party server 160.

[0147]

[0133] In step S28, the user device 120 receives a session ID generated by the third-party device 160. The session ID functions as a random challenge which is presented by the third-party device 160 to the user device 120 for the user to prove their identity. The user device 120 also receives the purpose ID and may be requested for one or more user attributes. The session ID, the purpose ID, and the request may be received by the user device 120 by scanning a QR code displayed on the website hosted by the third- party server 160. Alternatively, the session ID and the purpose ID may be alphanumeric codes which can be input to the user device 120 manually by the user via the user interface 122.

[0148]

[0134] In step S29, the user device 120 retrieves the third-party public key certificate issued to the third party. Where the third-party public key certificate is stored in the third-party registry using the hash value of the purpose ID as an index, the user device 120 retrieves the third-party public key certificate via the trusted server 140 by reference to the hash value of the purpose ID. If a third-party public key certificate associated with the purpose ID cannot be found then the user device 120 returns an error informing the user that such a third-party public key certificate does not exist.

[0149]

[0135] It is contemplated that in another embodiment, the third-party certificate may be user specific in which case it would be retrieved via supplying both the hash value of the purpose ID and a, possibly, pseudonymised user ID.

[0136] Next, the user device 120 obtains the public key certificate issued to the user for the purpose ID. Specifically, in step S30, the user device determines whether or not the public key certificate has been issued for the purpose ID received in step S28. If the public key certificate is recognised, e.g. by matching the hash value of the purpose ID and the pseudonymised user ID to an index in the public key registry 148, then the user device 120 retrieves the public key certificate 180 in step S31. The public key certificate 180 may be retrieved from the public key registry 148 stored by the trusted server 140, or using a local copy of the public key certificate 180 stored on the user device 120. Alternatively, if the public key certificate 180 is not recognised, then the public key certificate 180 may be registered according to the method shown in Figure 9.

[0150]

[0137] Once the public key certificate 180 of the user corresponding to the purpose ID has been obtained, in step S33, the user device 120 obtains subsequently acquired biometric data comprising the facial image of the user via the biometric sensor 124. The subsequently acquired biometric data corresponds to the same biometric data used to generate the privacy preserving data structure in step S8. As such, upon receiving the session ID and the purpose ID, the user device 120 may prompt the user on the mobile app to scan or photograph their face again using the built-in phone camera. If the public key certificate 180 is registered in step S32, then the subsequently acquired biometric data may have already been obtained as part of the method of registering the public key certificate 180.

[0151]

[0138] In step S34, the subsequently acquired biometric data and the purpose ID are used to generate a new private key from the privacy preserving data structure. Step S34 may be performed by the user device 120 or the trusted server 140, as described below.

[0152]

[0139] Where the new private key is generated by the trusted server 140, the user device 120 sends the subsequently acquired biometric data to the trusted server 140 via the communications interface 126 by connecting to the network interface 142 of the trusted server 140. The trusted server 140 then retrieves the privacy preserving data structure from the PPDS registry 151 and generates the new private key from the privacy preserving data structure using the subsequently acquired biometric data and the purpose ID.

[0153]

[0140] Alternatively, where the private key is generated by the user device 120, the user device 120 retrieves its local copy of the privacy preserving data structure and generates the new private key from the privacy preserving data structure using the subsequently acquired biometric data and the purpose ID.

[0154]

[0141] In step S35, the user device 120 or the trusted server 140 signs a hash value of the session ID using the new private key to obtain a digital signature of the user corresponding to the purpose ID. The signed hash value (i.e. the digital signature) is then provided to the third-party device 160. For example, the user device 120 may submit the signed session ID to the submission end-point URL specified on the third-party public key certificate. Where the third party requests one or more user attributes, the requested user attributes may also be submitted via the submission end-point URL. The third-party device may also receive the requested user attributes from the user’s public key certificate for the specified purpose ID. The third-party device may decrypt the user attributes using the third-party private key held by the third party.

[0142] In step S37, the third-party device 160 receives the digital signature and the requested user attributes from the user device 120. Accordingly, in step S38, the third-party device 160 retrieves the public key certificate 180 from the public key registry 148 stored by the trusted server 140, or from its own local public key registry 168. Accordingly, it is possible to perform the authentication method shown in Figures 10 and 11 with or without the involvement of the trusted server 140.

[0155]

[0143] In step S39, the digital signature is verified by the third-party device 160 using the public key 182 which is specified on the public key certificate 180 and using the hash value of the session ID. In step S40, if the identity of the user is verified and the user presents the requested user attributes, the third party may grant the user access to the service which the user attempted to access initially in step S27. Equally, if the identity of the user cannot be verified and / or the user does not present the requested user attributes, the third party may refuse the user access to the service which the user attempted to access initially in step S27.

[0156]

[0144] Therefore, the user authentication method has broad applicability. For example, the third-party device 160 may provide the session ID to the user device 120 in response to the user device 120 attempting to access a sign-in page. Thus, the user can prove their identity using biometric authentication for signing in to a website. By using a public key certificate, neither the user device 120 nor the third-party device 160 is reliant on the trusted server 140 for authenticating the user once the public key certificate (i.e. the face certificate) has been issued.

[0157]

[0145] Instead of using the session ID as a random challenge, the same method may be performed in other examples to verify a digital signature on an electronic document or file. Specifically, instead of signing the hash value of the session ID, the user may sign a hash value of the document received from the third party. This would allow the user to approve a transaction by the third party, e.g. the third party being a bank or other financial institution.

[0158]

[0146] A method of offline peer-to-peer verification between the user device 120 and the third-party device 160 will now be described. This method follows the method of registering the public key certificate 180 shown in Figure 9. Figure 12 shows the initial steps of the method which involves the user device 120 encrypting one or more requested user attributes. Figure 13 shows the subsequent steps of the method which involves the third-party device 160 decrypting the encrypted user attributes.

[0159]

[0147] First, the third-party device 160 enters a verification mode. This can be set by the third party (i.e. a verifier) operating the third-party device 160, e.g. by selecting verify digital ID. The third party may also select which user attributes need to be verified or this may be pre-configured on the third-party device 160. Accordingly, in step S27’, the third-party device 160 requests one or more user attributes from the user device 120. Preferably, the third-party device 160 displays a QR code on its user interface 170, the QR code encoding the request for the one or more user attributes.

[0160]

[0148] In step S28’, the user device 120 receives the request by scanning QR code displayed by the third-party device 160. In step S29’, upon receiving the request, the user device 120 requires the user to provide their consent for sending the requested user attribute(s) to the third-party device 160. This may be inputted by the user via the user interface 122.

[0161]

[0149] Next, in step S30’, the user device 120 retrieves the privacy preserving data structure generated in step S8. The user device 120 may retrieve the privacy preserving data structure from the PPDS registry 151 via the trusted server 140, or it may retrieve a local copy of the privacy preserving data structure stored in the memory 130.

[0162]

[0150] In step S31’, the user device 120 obtains subsequently acquired biometric data comprising the facial image of the user via the biometric sensor 124. The user may be prompted by the mobile app to scan or photograph their face using the built-in phone camera after receiving the privacy preserving data structure. The user device generates (regenerates) the private key from the privacy preserving data structure in step S32’ using the subsequently acquired biometric data.

[0163]

[0151] In step S33’, the user device 120 uses the private key to decrypt the encrypted user attributes stored as metadata in the privacy preserving data structure. The decrypted user attributes correspond to the original unencrypted user attributes stored in the attribute registry 149.

[0164]

[0152] In step S34’, a new public key is generated from the privacy preserving data structure by the user device 120 using the subsequently acquired biometric data. After selecting the user attributes requested by the third party from the decrypted user attributes, the requested user attributes are re-encrypted using the new public key in step S35’ and stored in a new privacy preserving data structure generated using the subsequently acquired biometric data in step S36’.

[0165]

[0153] This new privacy preserving data structure is provided to the third-party device 160. Preferably, the user device 120 displays a QR code on its user interface 122, the QR code encoding the new privacy preserving data structure. In step S38’, the third-party device 160 receives the new privacy preserving data structure by scanning QR code displayed by the user device 120.

[0166]

[0154] In step S39’, the third-party device 160 obtains subsequently acquired biometric data comprising the facial image of the user via the biometric sensor 172. The third party may be prompted by the mobile app to scan or photograph the user’s face using biometric sensor 172 after receiving the new privacy preserving data structure.

[0167]

[0155] The third-party device 160 generates (regenerates) a new private key from the new privacy preserving data structure in step S40’ using the subsequently acquired biometric data. The new private key corresponds to the new public key used in step S35’ to encrypt the requested user attributes.

[0168] Therefore, in step S41’, the third-party device 160 uses the new private key to decrypt the encrypted user attributes stored in the new privacy preserving data structure. Accordingly, the third party is provided with the requested user attributes while authenticating the user as the owner of the attributes.

[0169]

[0156] Figure 14 shows a flow chart of the steps of a method of online peer-to-peer verification between the user device 120 and the third-party device 160. The method of online peer-to-peer verification differs from the method of offline peer-to-peer verification in that the third-party device 160 is not permitted to obtain the biometric data of the user and therefore it must rely on the public key certificate 180 issued by the trusted server 140. This method is particularly useful when a user may have their face covered (e.g. for religious or personal reasons) as it allows the user to authenticate themselves with their face (in private) and then share the results of the authentication with the third party.

[0170]

[0157] First, the third-party device 160 enters a verification mode. This can be set by the third party (i.e. a verifier) operating the third-party device 160, e.g. by selecting verify digital ID. The third party may also select which user attributes need to be verified or this may be pre-configured on the third-party device 160. Accordingly, in step S27”, the third-party device 160 displays a QR code on its user interface 170, the QR code encoding a request for the one or more user attributes. Additionally, the QR code includes the purpose ID and a random challenge for the user. The challenge refers to a unique cryptographic challenge generated by the third-party device 160 which the user can respond to by providing a digital signature obtained from signing the challenge. As the challenge is set by the third party, the third party can be certain that the user has signed their challenge allowing the digital signature to be verified.

[0171]

[0158] In step S28”, the user device 120 receives the request, the purpose ID and the random challenge, by scanning the QR code displayed by the third-party device 160. Upon receiving the request, the user device 120 may require the user to provide their consent for sending the requested user attribute(s) to the third-party device 160. This may be inputted by the user via the user interface 122.

[0172]

[0159] In step S29”, the user device 120 retrieves the third-party public key certificate issued to the third party. Where the third-party public key certificate is stored in the third-party registry 150 using the hash value of the purpose ID as an index, the user device 120 retrieves the third-party public key certificate via the trusted server 140 by reference to the hash value of the purpose ID. If a third-party public key certificate associated with the purpose ID cannot be found then the user device 120 returns an error informing the user that such a third-party public key certificate does not exist.

[0173]

[0160] Next, the user device 120 obtains the public key certificate issued to the user for the purpose ID. Specifically, in step S30”, the user device determines whether or not the public key certificate has been issued for the purpose ID received in step S28”. If the public key certificate is recognised, e.g. by matching the hash value of the purpose ID to an index in the public key registry 148, then the user device 120 retrieves the public key certificate 180 in step S31 ”. The public key certificate 180 may be retrieved from the public key registry 148 stored by the trusted server 140, or by using a local copy of the public key certificate 180 stored on the user device 120. Alternatively, if the public key certificate 180 is not recognised, then the public key certificate 180 may be registered according to the method shown in Figure 9.

[0174]

[0161] Once the public key certificate 180 of the user corresponding to the purpose ID has been obtained, in step S33”, the user device 120 obtains subsequently acquired biometric data comprising the facial image of the user via the biometric sensor 124. The subsequently acquired biometric data corresponds to the same person’s biometric data which was used to generate the privacy preserving data structure in step S8. As such, upon receiving the challenge and the purpose ID, the user device 120 may prompt the user on the mobile app to scan or photograph their face again using the built-in phone camera. If the public key certificate 180 is registered in step S32”, then the subsequently acquired biometric data may have already been obtained as part of the method of registering the public key certificate 180.

[0175]

[0162] In step S34”, the subsequently acquired biometric data and the purpose ID are used to generate a new private key from the privacy preserving data structure. Step S34” may be performed by the user device 120 or the trusted server 140, as described below.

[0176]

[0163] Where the new private key is generated by the trusted server 140, the user device 120 sends the subsequently acquired biometric data to the trusted server 140 via the communications interface 126 by connecting to the network interface 142 of the trusted server 140. The trusted server 140 then retrieves the privacy preserving data structure from the PPDS registry 151 and generates the new private key from the privacy preserving data structure using the subsequently acquired biometric data and the purpose ID.

[0177]

[0164] Alternatively, where the private key is generated by the user device 120, the user device 120 retrieves its local copy of the privacy preserving data structure and generates the new private key from the privacy preserving data structure using the subsequently acquired biometric data and the purpose ID.

[0178]

[0165] In step S35”, the user device 120 or the trusted server 140 signs the challenge using the new private key to obtain a digital signature of the user corresponding to the purpose ID.

[0179]

[0166] In step S36”, the user device encodes the signed challenge (i.e. the digital signature) in another QR code which is displayed on the user device 120 for the third-party device 160. Accordingly, the third- party device 160 scans the QR code on the user device 120 in step S37” to receive the signed challenge.

[0180]

[0167] In step S38” the third-party device 160 retrieves the public key certificate 180 from the public key registry 148 stored by the trusted server 140, or from its own local public key registry 168. Accordingly, it is possible to perform the authentication method shown in Figures 14 and 15 with or without the involvement of the trusted server 140.

[0181]

[0168] In step S39”, the digital signature is verified by the third-party device 160 using the public key 182 which is specified on the public key certificate 180 and using the challenge set for the user device 120.

[0182] By verifying that the digital signature and therefore the private key used to sign the challenge belongs to the user, the third party is able to authenticate the identity of the user against the public key certificate 180. Hence, in step S40”, the third party determines that the user has the requested user attributes based on the user attributes specified on the public key certificate 180. The third party may decrypt the attributes specified in the public key certificate 180 using its own private key.

[0183]

[0169] A method of data communication in the public key infrastructure 100 will now be described in relation to the interactions between the user device 120, the third-party device 160, and optionally the trusted server 140. Figure 16 shows a flow chart illustrating the main steps of the method, which follows the method of registering the public key certificate 180 in Figure 9.

[0184]

[0170] In step S27’”, the third-party device 160 generates a message for sending to the user device 120. It is important for the user to be able to determine that the message originates from the third party. This is enabled by the third party providing its digital signature with the message for the user to verify. Specifically, in step 28”’, the third-party device 160 generates a hash value of the message and signs the hash value using its held third-party private key. The corresponding third-party public key was enrolled in the third party registry 150 by the trusted server 140 in the method of Figure 7.

[0185]

[0171] In step S29’”, the third-party device 160 provides the signed message to the user device 120 along with the purpose ID. For example, the third-party device 160 may transmit the signed message via its communications interface 162 by connecting to the communications interface 126 of the user device 120. Alternatively, the signed message may be sent via email or another communications channel, to be received by the user device 120.

[0186]

[0172] In step S30’”, the user device 120 thus receives the message, the digital signature, and the purpose ID provided by the third-party device 160. The authenticity of the digital signature can be verified by the user device 120 using the third-party public key. Therefore, in step S31’”, the user device 120 retrieves the third-party public key certificate. For example, the user device 120 may request a copy of the third-party public key certificate stored in the third party registry 150 from the trusted server 140, or the user device 120 may retrieve a local copy of the third-party public key certificate stored in the memory 130 of the user device 120.

[0187]

[0173] In step S32’”, the user device 120 obtains the hash value of the message and verifies the digital signature using the hash value and the third-party public key from the third-party public key certificate. Having verified that the digital signature belongs to the third party, the user device 120 determines that the message originates from the third party in step S33’”. If the digital signature does not correspond to the third-party public key, then the user device 120 cannot determine whether the message originates from the third party. The user device may return an error message to the user, indicating the message could not be authenticated.

[0188]

[0174] A method of encrypted data communication in the public key infrastructure 100 will now be described in relation to the interactions between the user device 120, the third-party device 160, and optionally the trusted server 140.

[0189]

[0175] The method includes an encryption phase including steps S27”” to S31”” which are performed by the third-party device 160, and a decryption phase including steps S32”” to S39”” which are performed by the user device 120. Figure 17 shows a flow chart illustrating the main steps of the encryption phase, which follows the method of registering the public key certificate 180 in Figure 9. Figure 18 shows a flow chart illustrating the main steps of the decryption phase, which follows the encryption phase in Figure 17.

[0190]

[0176] In step S27””, the third-party device 160 generates a message for sending to the user. The message may include private and confidential information and therefore it is desirable to protect the message from being viewed by other parties. This objective is achieved by the public key infrastructure system 100 by providing the user’s public key 182 and private key which can be used to encrypt and decrypt the message, respectively. It is also important for the user to be able to determine that the message originates from the third party. This is enabled by the third party providing its digital signature with the message for the user to verify. Specifically, in step 28””, the third-party device 160 generates a hash value of the message and signs the hash value using its held third-party private key. The corresponding third-party public key was enrolled in the third party registry 150 by the trusted server 140 in the method of Figure 7.

[0191]

[0177] In step S29”” the third-party device 160 retrieves the public key certificate 180 using the purpose ID and the recipient’s user ID either directly from the public key registry 148 stored by the trusted server 140, or from its own local public key registry 168. Accordingly, it is possible to perform the data communication method shown in Figure 9 without the involvement of the trusted server 140.

[0192]

[0178] The public key 182 is specified on the public key certificate 180 and therefore the third-party device 160 uses the public key 182 to encrypt the signed message in step S30””.

[0193]

[0179] The encrypted signed message is then provided to the user device along with the purpose ID in step S31””. For example, the third-party device 160 may transmit the encrypted signed message via its communications interface 162 by connecting to the communications interface 126 of the user device 120. Alternatively, the encrypted signed message may be displayed on the website hosted by the third-party server 160, e.g. by encoding the encrypted signed message in a QR code. Since the message is encrypted, it can be stored publicly without other parties being able to access the unencrypted message. The user device 120 may scan the QR code to receive the encrypted signed message. Alternatively, the encrypted signed message may be sent via email or another communications channel, to be received by the user device 120.

[0194]

[0180] In the decryption phase, the user device 120 thus receives the encrypted signed message provided by the third-party device 160 in step S32””. In step S33””, the user device 120 retrieves its local copy of the privacy preserving data structure or retrieves the privacy preserving data structure from the PPDS registry 151 via the trusted server 140.

[0195]

[0181] Next, the user device 120 obtains subsequently acquired biometric data comprising the facial image of the user via the biometric sensor 124 in step S34””. The subsequently acquired biometric data corresponds to the same biometric data used to generate the privacy preserving data structure in step S8. In response to receiving the encrypted signed message, the user device 120 may prompt the user on the mobile app to scan or photograph their face again using the built-in phone camera.

[0196]

[0182] In step S35””, the user device 120 generates the private key from the privacy preserving data structure using the subsequently acquired biometric data and the purpose ID. This allows the signed message to be decrypted using the private key in step S36””.

[0197]

[0183] The authenticity of the digital signature can be verified by the user device 120 using the third- party public key. Therefore, in step S37””, the user device 120 retrieves the third-party public key certificate. For example, the user device 120 may request a copy of the third-party public key certificate stored in the third party registry 150 from the trusted server 140, or the user device 120 may retrieve a local copy of the third-party public key certificate stored in the memory 130 of the user device 120 based on the purpose ID.

[0184] In step S38””, the user device 120 obtains the hash value of the message and verifies the digital signature using the hash value and the third-party public key from the third-party public key certificate. Having verified that the digital signature belongs to the third party, the user device 120 determines that the message originates from the third party in step S39””. If the digital signature does not correspond to the third-party public key, then the user device 120 cannot determine whether the message originates from the third party. The user device may return an error message to the user, indicating the message could not be authenticated.

[0198]

[0185] Accordingly, the present encrypted data communication method allows a user to receive data from a third-party securely. Even if another party obtained the encrypted data, it would not be possible for anyone other than the user to generate the private key which is required for decryption of the data.

[0199]

[0186] Correspondingly, it is also contemplated that the user device 120 can send an encrypted message to the third-party device 160. In this case, the user device 120 retrieves the privacy preserving data structure from the PPDS registry or the cache stored on the user device 120 and obtains subsequently acquired biometric data. Next, the user device 120 generates the private key from the privacy preserving data structure using subsequently acquired biometric data and the purpose ID and signs the message using the private key. The user device 120 also retrieves the third-party public key certificate and encrypts the signed message using the third-party public key from the third-party public key certificate. The encrypted signed message is then provided to the third-party device, which decrypts the message using its held private key and verifies the signature using the user’s public key from the public key certificate.

[0200]

[0187] While the methods described above relate to a third-party public key certificate which is retrievable using a purpose ID alone, it is also contemplated that the third party may also have a pairwise certificate - i.e. the third party will have not only one public-private key pair but a public-private key pair for each of its users. Then, just as public key certificates are retrieved using the purpose ID and the user ID, the third-party public key certificates can be generated and subsequently retrieved pairwise for a user ID and purpose ID. Then, the user attributes included in the public key certificate would be encrypted not by a single public key attributed to the third party, but by the public key attributed to the (third party, user ID) pair. Consequently, the third-party device may store a private key registry for its user-specific private keys. Each user-specific private key may be used to decrypt the user attributes in a particular user’s public key certificate corresponding to the user-specific private key.

[0201]

[0188] It is also contemplated that Face Certificates can be used in a standard mutual transport layer security (mTLS) flow using a standard Client-authenticated TLS handshake (RFC 5246 - 7.3, 7.4), as described below.

[0202]

[0189] The user (client) device and the third-party server exchange hello messages to agree on algorithms to be used in the handshake. The server then sends its server public key certificate to the user device via a server certificate message. The server public key certificate specifies the name of the third-party server (i.e. the URL address) and is signed by an issuer (e.g. the trusted server) using the issuer’s private key. The user device is able to verify the signature using the public key in the root certificate of the issuer. Therefore, the user can authenticate the third-party server from the server public key certificate.

[0203]

[0190] Next, the third-party server sends a client certificate request message to the user device. In response to receiving the client certificate request, the user device sends the public key certificate of the user to the third-party server via a client certificate message. The third-party server can verify the client certificate using the public key in the root certificate of the issuer. The public key certificate may contain the PPDS as an additional X.509 v3 extension - i.e. this would be in addition to the public key and user attributes discussed previously. Where the public key certificate includes the privacy preserving data structure, the user device may retrieve the privacy preserving data structure from the public key certificate. Alternatively, the user device may retrieve the privacy preserving data structure from the PPDS registry via the trusted server or the user device may retrieve a local copy of the privacy preserving data structure stored on the user device. The user device obtains subsequently acquired biometric data comprising the facial image of the user and generates the private key from the privacy preserving data structure using the subsequently acquired biometric data and the purpose ID. The user device may receive the purpose ID from the third-party server, e.g. via the hello message, the server certificate message, or the client certificate request message.

[0204]

[0191] The user device obtains a digital signature of the user by signing all previous messages in the TLS handshake protocol and sends the digital signature to the third-party server via a certificate verify message. The third-party device verifies the digital signature using the public key from the public key certificate.

[0205]

[0192] The user device and the third-party server may agree on a session key, e.g. using the Diffie Hellman (DH) or the Elliptic Curve Diffie Hellman (ECDH) algorithms. The session key is a symmetric key for encrypting data and subsequently decrypting the data encrypted by the session key.

[0206]

[0193] The systems and methods of the above embodiments may be implemented in a computer system (in particular in computer hardware or in computer software) in addition to the structural components and user interactions described.

[0207]

[0194] The term “computer system” includes the hardware, software and data storage devices for embodying a system or carrying out a method according to the above-described embodiments. For example, a computer system may comprise a central processing unit (CPU), input means, output means and data storage. The computer system may have a monitor to provide a visual output display. The data storage may comprise RAM, disk drives or other computer readable media. The computer system may include a plurality of computing devices connected by a network and able to communicate with each other over that network.

[0208]

[0195] The methods of the above embodiments may be provided as computer programs or as computer program products or computer readable media carrying a computer program which is arranged, when run on a computer, to perform the method(s) described above.

[0196] The term “computer readable media” includes, without limitation, any non-transitory medium or media which can be read and accessed directly by a computer or computer system. The media can include, but are not limited to, magnetic storage media such as floppy discs, hard disc storage media and magnetic tape; optical storage media such as optical discs or CD-ROMs; electrical storage media such as memory, including RAM, ROM and flash memory; and hybrids and combinations of the above such as magnetic / optical storage media.

[0209]

[0197] The features disclosed in the foregoing description, or in the following claims, or in the accompanying drawings, expressed in their specific forms or in terms of a means for performing the disclosed function, or a method or process for obtaining the disclosed results, as appropriate, may, separately, or in any combination of such features, be utilised for realising the invention in diverse forms thereof.

[0210]

[0198] While the invention has been described in conjunction with the exemplary embodiments described above, many equivalent modifications and variations will be apparent to those skilled in the art when given this disclosure. Accordingly, the exemplary embodiments of the invention set forth above are considered to be illustrative and not limiting. Various changes to the described embodiments may be made without departing from the spirit and scope of the invention.

[0211]

[0199] For the avoidance of any doubt, any theoretical explanations provided herein are provided for the purposes of improving the understanding of a reader. The inventors do not wish to be bound by any of these theoretical explanations.

[0212]

[0200] Any section headings used herein are for organizational purposes only and are not to be construed as limiting the subject matter described.

[0213]

[0201] Throughout this specification, including the claims which follow, unless the context requires otherwise, the word “comprise” and “include”, and variations such as “comprises”, “comprising”, and “including” will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

[0214]

[0202] It must be noted that, as used in the specification and the appended claims, the singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise. Ranges may be expressed herein as from “about” one particular value, and / or to “about” another particular value. When such a range is expressed, another embodiment includes from the one particular value and / or to the other particular value. Similarly, when values are expressed as approximations, by the use of the antecedent “about,” it will be understood that the particular value forms another embodiment. The term “about” in relation to a numerical value is optional and means for example + / - 10%.

Claims

1. 35Claims:

1. A computer-implemented method of issuing a public key certificate in a public key infrastructure, the public key infrastructure comprising a user device, a trusted server comprising a public key registry, and a third-party device operated by a third party, the method including: the user device obtaining biometric data comprising a facial image of the user; the user device or the trusted server generating a privacy preserving data structure using the biometric data; the user device receiving a purpose ID from the third-party device; the user device obtaining subsequently acquired biometric data comprising the facial image of the user; the user device or the trusted server generating a public key from the privacy preserving data structure using the subsequently acquired biometric data and the purpose ID, wherein a private key corresponding to the public key can be generated from the privacy preserving data structure using the purpose ID and further subsequently acquired biometric data comprising the facial image of the user; the trusted server obtaining a public key certificate from an issuer, the public key certificate comprising the public key and a digital signature of the issuer, and the trusted server storing the public key certificate in the public key registry.

2. The computer-implemented method of claim 1 , wherein the method further includes: the third-party device requesting one or more user attributes from the user device; the user device forwarding the request for the one or more user attributes to the trusted server; and the trusted server adding the one or more user attributes to the public key certificate.

3. The computer-implemented method of claim 2, wherein the method further includes: the trusted server encrypting the one or more user attributes using a third-party public key, such that the one or more user attributes added to the public key certificate are encrypted.

4. The computer-implemented method according to any preceding claim, wherein the method further includes the trusted server storing the public key certificate in the public key registry using the purpose ID and a user ID as an index.

5. The computer-implemented method according to any preceding claim, wherein the method further includes: the user device storing a local copy of the privacy preserving data structure; and the third-party device storing a local copy of the public key certificate in a local public key registry.

6. A computer-implemented method of authenticating a user using a public key certificate issued according to the method of any preceding claim, the method including: the user device receiving data generated by the third-party device and obtaining subsequently acquired biometric data comprising the facial image of the user;36 the user device or the trusted server generating the private key from the privacy preserving data structure using the subsequently acquired biometric data and the purpose ID; the user device or the trusted server generating a digital signature by signing the generated data using the private key; the third-party device receiving the digital signature and the public key certificate and verifying the digital signature using the generated data and the public key from the public key certificate.

7. The computer-implemented method of claim 6, wherein the third-party device stores a local copy of the public key certificate in a local public key registry, wherein the method further includes: the third-party device retrieving the local copy of the public key certificate and verifying the digital signature using the public key from the local copy of the public key certificate.

8. The computer-implemented method of claim 6 or claim 7, wherein the method further includes: the user device attempting to access a service provided by the third party; the third-party device providing the generated data to the user device in response to the user device attempting to access the service; and the third-party device granting the user access to the service, in response to verifying that the digital signature belongs to the user.

9. The computer-implemented method of claim 6, wherein the third-party device is a third-party server and the method of authenticating the user is for establishing a mutual Transport Layer Security (TLS) connection between the user device and the third-party server, wherein the method further includes: the user device receiving a client certificate request message from the third-party server; the user device sending the public key certificate of the user to the third-party server via a client certificate message; the user device generating the private key from the privacy preserving data structure using the subsequently acquired biometric data and the purpose ID; the user device generating the digital signature by signing the generated data using the private key, wherein the generated data comprises the client certificate request message.

10. A computer-implemented method of data communication using a public key certificate issued according to the method of any one of claims 1 to 5, the method including an encryption phase performed by the third-party device and a decryption phase performed by the user device, wherein the encryption phase includes the steps of: generating data to be viewed by the user device; receiving the public key certificate; and encrypting the generated data using the public key from the public key certificate, wherein the decryption phase includes the steps of: receiving the encrypted data; obtaining subsequently acquired biometric data comprising the facial image of the user;generating the private key from the privacy preserving data structure using the subsequently acquired biometric data and the purpose ID; and decrypting the encrypted data using the private key.

11. The computer-implemented method of claim 10, wherein the method further includes: the third-party device providing a digital signature of the third party by signing the data using a third-party private key; and the user device verifying the digital signature of the third party using a third-party public key corresponding to the third-party private key.

12. A computer-implemented method of data communication using a third-party public key certificate issued according to the method of any one of claims 1 to 5, the method including the third-party device: generating data to be viewed by the user device; providing a digital signature from the data using a third-party private key; and sending the data and the digital signature to the user device with the purpose ID, wherein the method further includes the user device: receiving the data with the digital signature and the purpose ID; retrieving the third-party public key certificate using the purpose ID; and verifying the digital signature using the data and the third-party public key from the third-party public key certificate.

13. The computer-implemented method of claim 12, wherein the method further includes: the third-party device receiving the public key certificate and encrypting the data and the digital signature using the public key from the public key certificate; and the user device receiving the encrypted data, obtaining subsequently acquired biometric data comprising the facial image of the user; generating the private key from the privacy preserving data structure using the subsequently acquired biometric data and the purpose ID; and decrypting the encrypted data using the private key to obtain the unencrypted data and the digital signature.

14. The computer-implemented method of any one of claims 10, 11 or 13, wherein the third-party device stores a local copy of the public key certificate in a local public key registry, wherein the method further includes: the third-party device retrieving the local copy of the public key certificate and encrypting the generated data using the public key from the local copy of the public key certificate.

15. The computer-implemented method of any one of claims 10, 11 or 13 to 14, wherein the user device stores a local copy of the privacy preserving data structure, wherein the method further includes: the user device retrieving the local copy of the privacy preserving data structure and generating the private key from the local copy of the privacy preserving data structure.

16. A computer-implemented method of peer-to-peer verification between a user device and a third- party device, the method including: the third-party device requesting one or more user attributes from the user device; the user device obtaining a privacy preserving data structure storing the requested one or more user attributes as encrypted metadata, wherein the privacy preserving data structure was generated using biometric data comprising a facial image of the user and the metadata was encrypted using a public key generated from the privacy preserving data structure using the biometric data; the third-party device receiving the privacy preserving data structure from the user device; the third-party device obtaining subsequently acquired biometric data comprising the facial image of the user, generating a private key from the privacy preserving data structure using the subsequently acquired biometric data, and decrypting the encrypted metadata using the private key to obtain the requested one or more user attributes.

17. A public key infrastructure system for issuing a public key certificate, the system comprising a user device, a trusted server comprising a public key registry, and a third-party device operated by a third party, wherein the user device is configured to: obtain biometric data comprising a facial image of the user; and receive a purpose ID from the third-party device, wherein the user device and / or the trusted server is / are configured to generate a privacy preserving data structure using the biometric data, wherein the user device and / or the trusted server is / are configured to generate a public key from the privacy preserving data structure using the biometric data and the purpose ID, wherein a private key corresponding to the public key can be generated from the privacy preserving data structure using the purpose ID and subsequently acquired biometric data comprising the facial image of the user, and wherein the trusted server is configured to: obtain a public key certificate from an issuer, the public key certificate comprising the public key and a digital signature of the issuer; and store the public key certificate in the public key registry.

18. A trusted server comprising a network interface, one or more processors, and a memory storing a public key registry and containing machine executable instructions which, when executed on the one or more processors, cause the one or more processors to: receive a purpose ID and biometric data comprising a facial image of the user, generate a privacy preserving data structure using the biometric data, generate a public key from the privacy preserving data structure using the biometric data and the purpose ID, wherein a private key corresponding to the public key can be generated from the privacy preserving data structure using the purpose ID and subsequently acquired biometric data comprising the facial image of the user; obtain a public key certificate from an issuer, the public key certificate comprising the public key and a digital signature of the issuer; and39 store the public key certificate in the public key registry.

19. The public key infrastructure system of claim 17 or the trusted server of claim 18, wherein the trusted server comprises one or more of: an attribute registry for storing one or more user attributes; a third party registry for storing a third-party public key certificate; a privacy preserving data structure registry for storing the privacy preserving data structure; and a certificate revocation list.

20. A user device comprising: a user interface, a biometric sensor, a communications interface, one or more processors, and a memory containing machine executable instructions which, when executed on the one or more processors, cause the one or more processors to: receive a purpose ID; obtain biometric data comprising a facial image of the user, generate a privacy preserving data structure using the biometric data, generate a public key from the privacy preserving data structure using the biometric data and the purpose ID, wherein a private key corresponding to the public key can be generated from the privacy preserving data structure using the purpose ID and subsequently acquired biometric data comprising the facial image of the user.

21. A third-party device comprising: a communications interface, one or more processors, and a memory containing machine executable instructions which, when executed on the one or more processors, cause the one or more processors to: generate data; provide the generated data to a user device operated by a user; receive a digital signature from the user device, the digital signature obtaining by signing the generated data using a private key, wherein the private key was generated from a privacy preserving data structure using a purpose ID and biometric data comprising a facial image of the user, wherein the privacy preserving data structure was generated using the biometric data; receive a public key certificate comprising a public key corresponding to the private key, wherein the public key was generated from the privacy preserving data structure using the purpose ID and subsequently acquired biometric data comprising the facial image of the user; and verify the digital signature using the generated data and the public key from the public key certificate.

Images