GB2609651A - Method and apparatus for protecting personal data - Google Patents

Abstract

A method of controlling access to personal data by having a second user’s computing system send a data request that specifies a requested user data field of the personal data and a first period of time when the data may be accessed, accepting the data request to create a signed license agreement and providing it to a control server, then second user then generating keying material to encrypt data, providing a portion of it to a first user, who then encrypts the data and saves the encrypted data to a remote server, then requesting access and the control server checking that the request is valid and is within the specified time, then providing a time limited access token, then the computing system providing the access token and accessing a file path on a remote server, the remote server then providing the encrypted data, and decrypting the data based on the keying material.

Description

Method and Apparatus for Protecting Personal Data

Field of the Invention

The present invention relates to a method and a system for protecting personal data.

Background of the Invention

The control of personal data is a growing concern. It is known to centralise the storage of a user's personal data (name, address, bank details, etc.) and to use encryption to control access to the data so that only organisations and individuals authorised by the user may access relevant fields in the personal data.

However, known systems can still require a high degree of trust by the user in a single service provider, trusting that the service provider will keep the user's personal data safe, while reliably making the personal data available to organisations and individuals as and when required.

The present invention seeks to provide a new approach that can help to mitigate this concern.

Summary of the Invention

From a first aspect, the invention provides a method of controlling access to personal data, the method comprising: an electronic user device storing personal data, relating to a first user, comprising one or more user data fields, in a memory of the electronic user device; a second user's computing system sending a data request, wherein the data request specifies: one or more requested user data fields of the personal data, and a first period of time during which the computing system may access the

requested user data fields;

the electronic user device receiving the data request; accepting the data request at the electronic user device to create a signed License Agreement, and the electronic user device contacting a control server and providing the signed License Agreement to the control server; the control server saving a copy of the signed License Agreement; the second user generating keying material for encrypting data; providing at least a portion of the keying material to the electronic user device; the electronic user device encrypting the one or more requested user data fields of the personal data using the provided keying material to create encrypted user data; saving the encrypted user data to a remote server, using a file path for the remote server and a first access token for the remote server; the computing system requesting access, from the control server, to the encrypted user data saved on the remote server; the control server checking to determine whether the access request is valid, wherein checking the validity of the access request includes at least checking that the request from the computing system is within the first period of time; wherein, if the request is determined to be valid, the control server providing a time-limited second access token and the file path of the encrypted user data on the remote server to the computing system, wherein the time-limited access token is configured to expire either when the first period of time has elapsed or at a second time, where the second time is before the first period of time has elapsed; the computing system providing the second access token and accessing the file path on the remote server; the remote server providing the encrypted user data to the computing system; and the computing system decrypting the encrypted user data based on the keying material.

With this method, access to the encrypted user data is mediated by the control server. The second user's computer system does not need to keep an extensive database of user information (e.g. customer details, bank details etc.), nor does the control server, as this information is instead stored on the remote server. Access to the data is mediated both by the access tokens (which are controlled by the control server) and by the encryption (which is controlled by the computing system). This means there are multiple different computing systems that control access to the data, meaning there is no single point of failure through which an attacker can gain access to the (unencrypted) data. Further, the use of access tokens allows the user greater control over his/her/their personal data, as revocation of the access tokens can prevent future access of the data by the second user. For example, if the License Agreement is for an online purchase, and the user cancels the order, the access token(s) can be revoked by the control server and the second user no longer has access to the first user's data.

The initial data request sent by the computing system may be called a Licence Template. The License Template therefore specifies at least the one or more requested user data fields of the personal data, and the first period of time during which the computing system may access the requested user data fields. Optionally, the License Template may have some fields that are editable by the first user before the first user accepts the data request. For example, the data request may request, inter al/a, a first user's telephone number. The first user may choose to edit the Licence Template to reject access to their telephone number before accepting and signing the License Template to create the signed Licence Agreement. As such, the step of accepting the data request may include amending the one or more requested user data fields of the personal data, or the first period of time, and then accepting the (modified) data request.

The keying material can be implemented in multiple different ways, and some options are discussed below. The keying material may be a batch of pre-keys, a batch of public keys (each one being one of a public/private key pair), or any other suitable encryption method.

For example, the keying material may include a public/private key pair. In this case, the step of providing at least a portion of the keying material to the electronic user device includes the computing system providing the public key to the electronic user device, and the step of the computing system decrypting the encrypted user data includes decrypting the encrypted user data using the private key of the public/private key pair.

The keying material may comprise a plurality of encryption keys, and wherein the step of providing at least a portion of the keying material to the electronic user device includes providing a selected one of the plurality of encryption keys; wherein each of the encryption keys is either a symmetrical encryption key or an asymmetrical encryption key.

If the first user revokes acceptance of the access request before expiration of the first period of time, the electronic user device contacts the control server and the control server rejects future access requests to the encrypted user data and revokes any active second access token(s). "Active" second access tokens are second access tokens that are still within the second period of time associated with that second access token. This allows the first user greater control over their personal data.

The step of the computing system sending the data request may include the computing system sending the data request to the control server; the control server storing the data request, generating a unique ID for the data request, and sending the unique ID to the computing system; the computing system sending the unique ID to the electronic user device; the electronic user device sending the unique ID to the control server; and the control server sending the data request to the electronic user device, such that the step of the electronic user device receiving the data request includes the electronic user device receiving the data request from the control server.

The control server may generate a unique ID for the data request, and provide the unique ID to the computing system. The computing system may then stores the unique ID with the private key of the public/private key pair; wherein for each subsequent data request, the computing system generates a new public-private key pair.

A unique ID may be a smaller data packet than either the Licence Agreement or the License Template. Thus, use of a unique ID may reduce the amount of data that needs to be transmitted and/or stored during various steps of the method. It is envisaged that some second users (e.g. larger businesses or organisations) may provide the unique ID in the form of a numerical code or OR code that the first user can enter into their electronic user device. The QR code may contain sufficient data to provide a unique ID, to identify a given Licence Template, while the License Template may be larger than allowed by the OR code.

The step of the computing system sending the data request may include the computing system sending the data request to the electronic user device.

The step of saving the encrypted user data to the remote server, using the file path and first access token for the remote server may include: the electronic user device sending the encrypted user data to the control server; the control server sending the encrypted data to the remote server along with the first access token; and the remote server saving the encrypted user data.

In this example, the control server is in the loop" of saving the data to the remote server.

Alternatively, the control server may provide the first access token and file path to the electronic user device, and the electronic user device then saves the encrypted user data to the remote server, using the file path and first access token.

The remote server may be part of a distributed data storage system for storing a plurality of instances of the encrypted representation of the requested user data fields, distributed across a plurality of respective locations.

Distributed storage systems may typically be accessed from anywhere in the world, via the Internet. Further, storage of data within the system may be distributed across a number of physical locations. This may make the distributed storage system more resilient than a single server against natural or man-made disasters that affect a single location.

The method may further comprise the step of the computing system deleting the decrypted user data.

This may be beneficial to the second user, as the second user no longer needs to store the data for a long time. This offloads the responsibility of maintaining and updating a large database of first users' data. This also may reduce the legal liability of the second user e.g. in the event of a data breach, as the second user simply does not have (so much) first user data to lose and/or misuse.

The computing system may use the user data, and the deleting may occur in response to the computing system finishing using the user data or in response to the first period of time elapsing The method may further comprise: the first user using the electronic user device to amend the personal data, including amending at least one of the one or more requested user data fields; and the electronic user device encrypting and sending the amended one or more requested user data fields to the remote server, wherein the step of encrypting is performed using the provided keying material.

In this way, the first user's data may be kept up-to-date, such that the second user gets the most up-to-date information when the second user requests access to the encrypted data. If the first user has multiple signed Licence Agreements with a variety of different second users, the first user only needs to update their personal information once, at their electronic user device, and this updated information can be provided to all second users, by updating the data stored on the remote server, when those second users request access to the data.

This is compared to the current reality where a first user may need to update their personal details individually with many different second users (e.g. online businesses/organisations) when some piece of personal data changes. For example, when the first user changes address, the user only needs to update their address once, and all online businesses/organisations that access that data, via the above-described method, will get the up-to-date information. This reduces the hassle to the first user and to the second user(s).

The first access token may be configured to allow write-access to the remote server. The second access token may be configured to allow read-only access to the encrypted user data saved at the remote server.

Allowing read-only access to the encrypted user data via a read-only second access token ensures the second user does not (accidentally or intentionally) alter the user data on the remote server. This can ensure that the data is kept under the control of the first user.

The control server may comprise a whitelist of IP addresses. In this case, the step of the control server checking the access request from the computing system further includes the control server checking an IP address associated with the access request against the whitelist; wherein the access request is rejected if the IP address associated with the access request is not on the whitelist. Optionally, a different whitelist may be associated with each data request and/or each signed License Agreement. That is, each signed License Agreement stored on the control server may have its own whitelist, and only requests from a valid second user (as determined by the IP address from whence the access request comes) are allowed. This is in addition to checking the access request is within the first period of time.

The step of saving the encrypted user data to a remote server may include the control server providing the file path and first access token to the electronic user device and the electronic user device then saving the encrypted user data to the remote server. Alternatively, this step may include the electronic user device sending the encrypted user data to the control server and the control server saving the encrypted user data to the remote server using the file path and the first access token.

From a second aspect, the invention provides a system for controlling access to personal data, the system comprising: a first user's electronic user device; a control server; a second user's computing system; wherein the system is configured to perform the method of the first aspect. That is, the electronic user device may be configured to perform each of the steps performed by the electronic user device as detailed above in the first aspect of the invention; the computing system may be configured to perform each of the steps performed by the computing system as detailed above in the first aspect of the invention; the control server may be configured to perform each of the steps performed by the control system as detailed above in the first aspect of the invention; and the remote server may configured to perform each of the steps performed by the remote server as detailed above in the first aspect of the invention.

The electronic user device may be one of a personal computer, a laptop computer, a tablet computer, and a mobile phone.

Brief Description of the Figures

Certain embodiments of the present disclosure will now be described in greater detail by way of example only and with reference to the accompanying drawings in which: Figure 1 is a schematic view of a computing system embodying the invention; Figure 2 is a sequence diagram of a method, embodying the invention, for providing access to personal user data; and Figure 3 is a sequence diagram of a second method, embodying the invention, for providing access to personal user data.

Detailed Description

Figure 1 shows an exemplary computing system embodying the invention.

The system generally comprises an electronic user device 10, such as a mobile phone or personal computer, that is operated by a first human user. The first user enters personal data into various data fields shown the user device. For example, the data fields may be "Name", "Postal Address", "Banking Address", "Date of Birth" etc. A second user wishes to obtain some of the personal data from the first user. The second user may be a natural person or may be a legal person, such as a business or government. The second user uses a computing device or (second user's) computing system 20, e.g. one or more computers on a LAN which is connected to the Internet, for performing the electronic communication and processing steps described herein. As described in detail below, some of personal data of the first user is sent from the electronic user device 10 and is stored in encrypted form in a remote server 40. The remote server 40 may be part of a distributed data storage system, for storing a plurality of instances of the encrypted representation of the requested user data fields, distributed across a plurality of respective locations.

Subsequent access to this encrypted personal data (e.g. by the second user's computing system 20) is managed by a control server 30. The arrows generally depict one-way or two-way communication channels between the aforementioned components (10,20,30,40) of the system.

The detailed method of controlling access to personal data is described below in relation to Figure 2, while Figure 1 shows the general data flows of the present disclosure but omits some details for simplicity. Further optional details of the method are described below in relation to Figure 3.

At a high level, to access the desired personal data, the (second user's) computing system 20 contacts the control server 30 to register a license template, LT. The license template specifies at least a) which pieces of personal data are required, and b) a period of time for which the data is required. The user, using his/her electronic user device 10, accepts and signs the LT, making it a signed License Agreement. Then the electronic user device 10 encrypts the data and then sends the encrypted data to the distributed storage system 40.

The data is encrypted with keying material. The keying material may be a public key, of a public/private key pair, that has been provided by the computing system 20, however other forms of keying material (and cryptographic methods) are possible and some options are discussed below. When the second user wants to access the data (e.g. to complete an online transaction), the second user's computing system 20 contacts the control server 30 requesting access to the data on the distributed storage system 40. The control server 30 checks the request is valid, e.g. is within the period of time, and, if so, provides an access token and file path to the second user's computing system 20 allowing the second user to retrieve the encrypted data from the distributed storage system 40 at the file path. The second user's computing system 20 then decrypts the data (e.g. using the private key or using keying material).

The second user's computing system 20 may then use the decrypted information, e.g. to complete an online transaction, and may then delete the data from the second user's computer system 20. It is envisaged that, in many cases, the second user may be an online business. In this manner, the second user may no longer need to maintain an extensive database of client details (e.g. personal data from the first user), and consequently may be relieved of the liability of safely storing that personal data (e.g. in the event of a data breach).

The License Agreement contains at least the following information:

* The requested data fields;

* The period of time during which the second user may access the personal data.

In other cases, such as where the Licence Agreement needs to be compliant with the General Data Protection (GDPR), the License Agreement also specifies * The legal bases for processing the personal data; and * The purpose(s) for which the personal data may be used.

Legal Bases for processing the personal data may include: * Vital Interests -where it is necessary to process someone's personal data to protect someone's life.

* Legal Obligation -where it is necessary to process someone's personal data to comply with a common law or statutory obligation.

* Public Task -where it is necessary to process someone's personal data in the exercise of official authority or to perform a task in the public interest.

* Contract -to deliver a service before or after a contract exists between two (or more) parties.

* Legitimate Interest-where there is a compelling justification or reasonable expectation that the personal data will be processed.

* Consent -where there is an open and fair agreement from the person to process their personal data.

The above Legal Bases are defined under the European Union General Data Protection Regulation (GDPR), that has been implemented in EU states. The GDPR groups the overarching purpose for processing personal data under one of 6 specific categories, the Legal Bases. All processing of personal data should be performed under one (or a combination) of the Legal Bases.

In more detail, and with reference to Figure 2, the method comprises the steps of: Step 100 -the user adds his/her personal data onto the electronic user device 10. The personal data may include multiple data fields, such as "first name", "last name", "date of birth", "delivery postal address", "banking address", "bank account details" etc. Step 102 -the second user's computing system 20 sends a License Template, LT, to the control server 30. The License Template specifies at least the specific data fields that are desired, and a first time period during which access is allowed.

Step 104 -the control server 30 stores a copy of the LT and generates a unique identification code, LT-ID, for that LT.

Step 106 -the control server 30 sends the LT-ID to the computing system 20.

Step 108 -the computing system 20 stores a copy of the LT-ID.

Step 110 -the computing system 20 sends the LT-ID to electronic user device 10, e.g. via the Internet and/or a mobile phone network.

Step 112 -the electronic user device 10 sends the LT-ID to the control server 30.

Step 114 -the control server 30 sends a copy of the LT to the electronic user device. The LT may be encrypted at this point, e.g. using a session key or other cryptographic protocol (such as SS[, for example) established between the electronic user device 10 and the control server 30.

Step 116 -the user reviews the [land, assuming the terms are acceptable to the user, the user accepts the LT and electronically signs the LT using the electronic user device 10, creating a signed License Agreement. In some cases, the user may be able to amend the LT before accepting it. For example, the LT may request a piece of user data that is not essential (e.g. not essential to the online transaction taking place) and the first user may choose not to share this information with the second user. In that instance, the first user may reject that option in the LT before signing the revised [Ito make a signed License Agreement. In the event that the user revises the LT before signing it, the control server 30 may take a step of notifying the computing system 20 of the revised terms. Items of the LT that are essential to proper completion of the transaction (e.g. banking details and postal details, for an online purchase) may be non-editable when presented to the first user. In this case, the first user can either accept those items or he/she must reject the entire LT (and e.g. thereby not continue with the transaction).

Step 118 -the electronic user device 10 sends the signed License Agreement to the control server 30 Step 120 -the control server 30 saves a copy of the signed License Agreement, and generates a License Agreement ID, LID. The LID identifies the signed License Agreement, and is distinct from the earlier LT-ID, that identifies the (original and unsigned) License Template.

Step 122 -the control server 30 provides, to the electronic user device 10, the LID, a file path, and a first access token. The file path is the location, on the remote server 40 (e.g. the distributed storage system), where the data will be stored. The file path may take the form of a typical OS file path and may look, for example, like "sj: \\PAuser1 \user1personaldata.csv". The first access token is a token that is required by the remote server 40 to allow someone to save data to the remote server 40. The access token allows write-access to the file path, so that a user may save a file at that file path.

Step 124-the electronic user device 10 contacts the second user's computing system 20, notifying the computing system 20 that the License Agreement has been accepted and providing the LID.

Step 126 -the computing system 20 generates a public/private key pair. This step may alternatively occur at any point before now. For example, the computing system 20 might generate the public/private key pair when first registering the LT at step 102.

Step 128 -the computing system 20 sends the public key to the electronic user device 10.

Step 130 -the electronic user device 10 encrypts the data fields that are specified in the License Agreement using the public key, to create encrypted user data.

Step 132 -the electronic user device 10 sends the encrypted user data to the remote server 40, providing the first access token and saving the encrypted user data to the file path.

Step 134 -when the second user wants to access the user data, the second user's computing system 20 sends a request to the control server 30, where the request contains the LID. As discussed below, the control server 30 may additionally check where the LID comes from, e.g. from what IP address the request comes.

Step 136 -the control server 30 checks to determine whether or not the request is valid. This determination includes at least checking that the request has arrived within the first period of time. Further checks may be made at this step by the control server 30 and some options for further checks are discussed below. If the request is determined to be invalid, the method ends.

Step 138 -if the request is determined to be valid, the control server 30 provides a second access token and the file path to the computing system 20. The second access token is time-limited. The second access token will expire at least when the first period of time expires, i.e. so that the second user cannot use the second access token to retrieve the data after the first period of time has expired. The second access token may be valid for a shorter time than this. The second access token is preferably a read-only token, which means the computing system 20 can read the data from the distributed storage system 40, but cannot edit the data stored at that file path.

By way of non-limiting example, say the first period of time is set as thirty days from the date of acceptance of the LT. If the second user requests access to the data twenty days after the date of acceptance, then the second access token will be valid for, at most, ten days, but this second time period may be shorter. If the second user requests access to the data forty days after acceptance, the control server 30 will reject the request.

Step 140 -the computing system 20 requests the remote server 40 to send the file at the file path (i.e. the encrypted user data) and provides the second access token.

Step 142-the remote server 40 checks the second access token is valid and, if so, sends the (encrypted) data to the computing system 20.

Step 144 -the second user's computing system 20 decrypts the encrypted user data using the private key, to obtain unencrypted user data.

After receiving and using the unencrypted user data, the second user may delete the user data from the second user's computing system 20. This deletion does not affect the data stored on the remote server 40.

As mentioned above, the second access token may be time-limited to a shorter time than the first period. For example, continuing the previous example, if the second user requests access to the data after twenty days, and the first period is thirty days, the second access token that is provided may last, for example, 24 hours.

As such, the second user may request the data multiple times, i.e. Steps 138 to 144 may be performed multiple times. Each time the second user requests access, the control server 30 checks the request against the signed License Agreement, and, if the request is valid, provides a further time-limited access token to the second user.

An alternative method is shown in Figure 3. Many of the steps are the same as the method shown in Figure 2 and, for those steps, identical reference numerals will be used. The method of Figure 3 comprises the steps: Step 300 -the second user's computer system 20 generates a batch of keying materials, KM. These KM may include a large number of encryption keys, or may be a pre-key bundle, e.g. as defined in the Signal cryptographic protocol, developed by Open Whisper Systems.

The encryption keys may variously be symmetric keys or asymmetric encryption keys. Each KM is used only for a single license, as discussed below in relation to Steps 306-314. The KM may be generated and used in the Signal protocol. Optionally, the Signal protocol may be used without the Double Ratchet part of the algorithm.

Step 302 -the second user's computer system 20 sends the KM to the control server 30 which stores the KM. In the case where the KM is asymmetric (e.g. each KM is a public/private key pair), the second user's computer system 20 sends only the public parts (e.g. public keys) to the control server 30 which stores the (public parts of the) KM. The private parts (e.g. private keys) of the KM are kept by the computer system 20 and not sent to the control server 30.

Steps 100 to 108-as detailed above in relation to Figure 2 Step 304 -this replaces Steps 110-114 in the method of Figure 2. In Step 304, the second user's computing system 20 sends the License Template directly to the electronic user device 10 (i.e. rather than the electronic user device 10 fetching this from the control server 30 using the LT-ID) along with the LT-ID.

Step 116-as described above in relation to Figure 2.

Steps 118-132, described above in relation to Figure 2, do not occur in the method of Figure 3. Instead, after step 306, the method of Figure 3 continues: Step 306 -the electronic user device 10 requests keying material from the control server 30.

Step 308 -the control server 30 selects a keying material, KM1, out of the batch of stored KM and sends KM1 to the electronic user device 10. Preferably, each piece of keying material is only used for a single License Agreement/License Template.

Step 310 -the electronic user device 10 encrypts the requested personal data using KM1 to create encrypted personal data.

Step 312 -the electronic user device 10 sends, to the control server 30, the signed License Agreement, the encrypted personal data, and confirms that KM1 was used for the encryption.

Step 314 -the control server 30 stores the signed License Agreement and stores a record that KM1 was used for the encryption.

Step 316 -the control server 30 sends the encrypted personal data to the remote server 40, and stores a file path for the data on the remote server 40.

Step 318 -the control server 30 generates a LID for the signed License Agreement and sends the LID to the computing system 20.

Step 134 and 136-as above. That is, when the second user wants to access the data, the second user's computing system 20 requests the personal data by sending the LID to the control server 30, and the control server checks the LID is valid, e.g. the request is within the first period of time. As above, further aspects may be checked by the control server 30 before the request is determined to be valid.

Step 320 -the same as Step 138, above, except that the control server additionally provides information to the computing system 20 that KM1 was used.

Steps 140-142 -as detailed above in relation to Figure 2.

Step 322-similar to Step 144-in Step 322, the second user decrypts the data using KM1, or using a key that decrypts data encrypted with KM1. That is, if KM1 is a public key, the data may be decrypted using a corresponding private key of a public/private key pair. If KM1 is a symmetrical key, i.e. one used for both encryption and decryption, then the second user may use KM1 to decrypt the data directly. If KM1 is a Signal prekey bundle, the second user's computer system 20 calculates the corresponding decryption key and decrypts the data.

With this alternative method, the public/private key pair is essentially replaced with the keying material, KM. The computing system 20 only needs to provide the batch of KM to the control server 30 once. For each request for personal data from the computing system 20, the control server 30 can use a different one of the keying materials KM (e.g. KM1, KM2, KM3 etc.). This method means the computing system 20 only has to contact the electronic user device 10 once (at Step 110), and does not need to share keys directly with the electronic user device 10. Each KM is used once, i.e. for a single license. Thus, if the second user 20 later on sends a new License Template, LT2, to the first user's electronic device 10, then a different KM, KM2, is used for the encryption of LT2 etc. The above-described process will now be described by way of a specific example in which the second user's computer system 20 is operated by an online business and the first user is a customer trying to purchase an item from the online business. In this example, the first user has browsed for and selected the desired item and now wishes to checkout. To complete the transaction, the second user needs to know the first user's name, postal address (for delivery), and billing address and bank details (to take payment). The second user may also request the first user's telephone number, in case there is a problem and the second user needs to contact the first user. In this example, the first user has already entered personal data into their electronic user device 10, i.e. has performed step 100.

To complete the transaction, the online business prepares a License Template and arranges this to be sent to the first user (i.e. either steps 102-114 in Figure 2 or steps 102, 104, 108, 302, and 304 in Figure 3) requesting access to the following data fields: name, postal address, bank account details, billing address. As mentioned above, the personal data on the electronic user device 10 may encompass other fields, such as date of birth or medical history. As this data is irrelevant to the online transaction, the second user does not request this data in the License Template.

In this example, the License Template may contain: 1. "name", "postal address", "bank account details", "billing address", "telephone number".

2. Contract (i.e. once signed, the License Agreement allows processing of the first user's personal data so that a contract may be completed). i. N.B. the License Agreement could also contain Legal Obligation if, for example, the online business needs to report/justify sales of a specific service/good, e.g. in the case of selling restricted items firearms or explosives) 3. "Fulfilling an order", "taking payment", "marketing", and "customer support" as the purposes for which the data is to be used.

4. "60 days" (N.B. this first period may, for example, be chosen to cover any returns period for the purchased item, so that the first user can be readily identified and linked to a given sale).

The customer (i.e. first user) may accept the License Agreement as it is. Alternatively, the customer may deselect, e.g., "telephone number" from the data fields (item 1) if they do not want this information shared and/or may deselect "marketing" from the list of purposes (item 3) if they do not want the personal data used for marketing.

The user accepts and signs the License Agreement (or the amended License Agreement) using their electronic user device 10-i.e. perform step 116.

The personal data gets encrypted and sent to the remote server 40 (e.g. a distributed storage system). This may be either via steps 118-132 as shown in Figure 2, or via steps 306-318 as shown in Figure 3.

The second user's computer system 20 contacts the control server 30 (i.e. step 134) requesting access. The control server 30 checks whether the request is valid, i.e. within the terms of the signed License Agreement, particularly whether the request is within the first period specified in the Agreement. If the request is valid (including any additional checks made by the control server 30), the control server 30 provides the second access token and file path to the second user 20. The second user then retrieves and then decrypts the data, i.e. either by performing steps 134-144 of Figure 2, or steps 134, 136, 140,142, 320, and 322 of Figure 3. The data is then used to fulfil the online order, i.e. by taking payment from the first user's bank account and arranging posting of the ordered goods using the first user's name and postal address.

As a result of the methods (and system performing the method) described above, the first user has confidence that the second user only has access to the necessary data for fulfilling the transaction, and only has access to the data for a limited time, defined by the first period. Of course, the second user can theoretically permanently save the decrypted data to their own system, i.e. so they have the data longer than the first period of time. However, in view of the potential liability in the event of a data breach, there is a financial/legal incentive to the second user not saving the data for longer than needed. This is particularly true if the second user publically advertised that they do not keep user data after use, as a result of using the above-described method/system.

The above system and method also allows a user to revoke access to their personal data at a later stage. At any point after step 116, the user, via their electronic user device 10, may contact the control server 30 to revoke the signed License Agreement. If this is done, the control server 30 will reject any subsequent requests made for that data by the second user 20. That is, at step 136, the control server 30 will check whether consent has been revoked and, if so, will reject a request from the second user, even if the request arrives within the first period of time.

For this reason, it may be desirable to set the time-limit for the time-limited second access token to less than the remaining time of the first period. For example, it may be desirable to set the time limit of the second access token to 24 hours for all requests received when there is more than 24 hours remaining in the first time period. This ensures that the user can revoke access and be sure that the second user, at most, has only 24 hours or less to access the data. If desired, the time limit on the second access token could be much shorter, for example set as 1 minute, to ensure even quicker response times when access is revoked by the user.

In an alternative implementation, the second access token may be revoked immediately when a user revokes access. This may be done by the control server 30 contacting the distributed storage system 40 to reject the second access token if the second user's computer system 20 later tries to access the file path and provides the second access token. In this manner, the control server 30 does not need to contact the second user 20 to revoke the second access token, nor does the first user need to rely on (i.e. trust) the second user to delete revoked access token(s).

The control server 30 can implement further security measures to help protect the user data. By way of non-limiting example, the control server 30 may have a whitelist, whereby (at Step 134) the control server checks where the LID originates from, e g. by checking an IF address of the requesting party. The control server 30 checks whether the IP address is on the whitelist and the control server 30 is configured to only provide the access token and file path if the request comes from an IF address on the whitelist, i.e. will only provide the access token and file path if the LID appears to come from the second user's computer system 20. This may provide extra security in the event that an attacker has learned the LID from the second user (e.g. in a data break). The attacker can send the LID to the control server 30 (i.e. to request an access token and file path) but, if the request does not originate from the second user's 20 computer system, e.g. as determined via IP address, the request is rejected. In this manner, the attacker will not be granted access token(s) and so will not be able to access the user data. This is the case even with the attacker having breached the second user's security, which may potentially include the attacker having obtained private keys or keying material from the second user.

Several advantages apply to this method of holding data as opposed to the online business (second user) holding the personal data. These advantages include: * If the first user's personal data is updated, say they change address, the user may update the personal data on the electronic user device 10. This updated information will be used for all subsequent online transactions. This is as opposed to the current system where a user may need to update their details on each website where they have an account. In one alternative, the electronic user device 10 may notify the control server 30 when a user updates data fields that are stored in encrypted form on the remote server.

The control server and user device may then act together to update the user data stored on the remote server 40, so that the encrypted data on the remote server 40 is up-to-date.

* The user can decide to refuse further access to their data by contacting the control server 30. This gives users control over their own personal data and reduces the level of control given up to the second user.

* The second user does not need to provide long-term storage for user data, as first users' data (e.g. customers' data) is stored elsewhere. This relieves the second user of the financial and administrative burden of long-term data storage. This may also significantly reduce any legal liability for the second user. If the second user only very briefly stores the first user's data and then securely deletes the data from the second user's computer(s), then the likelihood of any given personal data being stolen from the second user by hackers or, more generally, in case of a data breach, is greatly reduced.

* The issuance of access tokens by the control server gives the user greater control over their data. This also increases the security of the data because only a user with the access token (i.e. the second user) is granted access to the file path on the distributed storage system. Meanwhile, other users who attempt to access the file path without providing the access token will not be given the (encrypted) data.

It will be appreciated by those skilled in the art that the invention has been illustrated by describing one or more specific embodiments thereof, but is not limited to these embodiments; many variations and modifications are possible, within the scope of the accompanying claims.

Claims (17)

1. Claims: 1. A method of controlling access to personal data, the method comprising: an electronic user device (10) storing (100) personal data, relating to a first user, comprising one or more user data fields, in a memory of the electronic user device (100); a second user's computing system (20) sending a data request, wherein the data request specifies: -one or more requested user data fields of the personal data, and a first period of time during which the computing system (20) may accessthe requested user data fields;the electronic user device receiving (114;304) the data request; accepting (116) the data request at the electronic user device (10) to create a signed License Agreement, and the electronic user device (10) contacting (118;312) a control server (30) and providing the signed License Agreement to the control server (30); the control server (30) saving (120;314) a copy of the signed License Agreement; the second user generating (300;126) keying material for encrypting data; providing (128; 308) at least a portion of the keying material to the electronic user device (10); the electronic user device (10) encrypting (130;310) the one or more requested user data fields of the personal data using the provided keying material to create encrypted user data; saving (132;316) the encrypted user data to a remote server (40), using a file path for the remote server (40) and a first access token for the remote server (40); the computing system (20) requesting access (134), from the control server (30), to the encrypted user data saved on the remote server (40); the control server (30) checking (136) to determine whether the access request is valid, wherein checking the validity of the access request includes at least checking that the request from the computing system (20) is within the first period of time; wherein, if the request is determined to be valid, the control server (30) providing (138;320) a time-limited second access token and the file path of the encrypted user data on the remote server (40) to the computing system (20), wherein the time-limited access token is configured to expire either when the first period of time has elapsed or at a second time, where the second time is before the first period of time has elapsed; the computing system providing the second access token and accessing (140) the file path on the remote server (40); the remote server (40) providing (142) the encrypted user data to the computing system; and the computing system (20) decrypting (144;322) the encrypted user data based on the keying material.
2. 2. The method of claim 1, wherein the keying material includes a public/private key pair, and wherein the step of providing at least a portion of the keying material to the electronic user device includes the computing system (20) providing (128) the public key to the electronic user device (10), and wherein the step of the computing system (20) decrypting (144) the encrypted user data based on the keying material includes decrypting the encrypted user data using the private key of the public/private key pair.
3. 3. The method of claim 1, wherein the keying material comprises a plurality of encryption keys, and wherein the step of providing at least a portion of the keying material to the electronic user device includes providing a selected one of the plurality of encryption keys; wherein each of the encryption keys is either a symmetrical encryption key or an asymmetrical encryption key.
4. 4. The method of any preceding claim, wherein, when the first user revokes acceptance of the access request before expiration of the first period of time, the electronic user device contacts the control server and the control server rejects future access requests to the encrypted user data and revokes any active second access token(s).
5. 5. The method of any preceding claim, wherein the step of the computing system sending the data request includes the computing system (20) sending the data request to the control server (30), the control server (30) storing the data request, generating a unique ID for the data request, and sending (104) the unique ID to the computing system (20); the computing system (20) sending (110) the unique ID to the electronic user device (10); the electronic user device (10) sending (112) the unique ID to the control server (30); and the control server (30) sending (114) the data request to the electronic user device (10), such that the step of the electronic user device (10) receiving the data request includes the electronic user device receiving the data request from the control server (30).
6. 6. The method of any preceding claim, wherein the control server (30) generates a unique ID for the data request, and provides the unique ID to the computing system (30); and the computing system (20) stores the unique ID with the private key of the public/private key pair; wherein for each subsequent data request, the computing system generates a new public-private key pair.
7. 7. The method of any of claims 1 to 4, wherein the step of the computing system sending the data request includes the computing system (20) sending (304) the data request to the electronic user device (10).
8. 8. The method of any preceding claim, wherein the step of saving the encrypted user data to the remote server, using the file path and first access token for the remote server (40) includes: the electronic user device (10) sending (312) the encrypted user data to the control server (30); the control server (30) sending (316) the encrypted data to the remote server (40) along with the first access token; and the remote server (40) saving the encrypted user data.
9. 9. The method of any preceding claim, wherein the remote server (40) is part of a distributed data storage system for storing a plurality of instances of the encrypted representation of the requested user data fields, distributed across a plurality of respective locations.
10. 10. The method of any preceding claim, further comprising the step of the computing system deleting the decrypted user data.
11. 11. The method of claim 10, wherein the computing system uses the user data, and wherein the deleting occurs in response to the computing system finishing using the user data or in response to the first period of time elapsing.
12. 12. The method of any preceding claim, further comprising: the first user using the electronic user device (10) to amend the personal data, including amending at least one of the one or more requested user data fields; and the electronic user device encrypting and sending the amended one or more requested user data fields to the remote server (40), wherein the step of encrypting is performed using the provided keying material.
13. 13. The method of any preceding claim, wherein the first access token is configured to allow write-access to the remote server (40), and/or wherein the second access token is configured to allow read-only access to the encrypted user data saved at the remote server (40).
14. 14. The method of any preceding claim, wherein the control server (30) comprises a whitelist of IP addresses, and wherein the step of the control server checking (136) the access request from the computing system (20) further includes the control server (30) checking an IP address associated with the access request against the whitelist; wherein the access request is rejected if the IP address associated with the access request is not on the whitelist; optionally wherein a different whitelist is associated with each data request and/or each signed License Agreement.
15. 15. The method of any preceding claim wherein the step of saving (132;316) the encrypted user data to a remote server (40) includes either a) the control server (30) providing the file path and first access token to the electronic user device (10) and the electronic user device (10) then saving the encrypted user data to the remote server (40); or b) the electronic user device (10) sending the encrypted user data to the control server (30) and the control server saving the encrypted user data to the remote server (40) using the file path and the first access token.
16. 16. A system for controlling access to personal data, the system comprising: a first user's electronic user device (10); a control server (30); a second user's computing system (20); wherein the system is configured to perform the method of any preceding claim.
17. 17. The system according to claim 16 wherein the electronic user device (10) is one of a personal computer, a laptop computer, a tablet computer, and a mobile phone.