[go: up one dir, main page]

WO2021160981A1 - Methods and apparatus for controlling access to personal data - Google Patents

Methods and apparatus for controlling access to personal data Download PDF

Info

Publication number
WO2021160981A1
WO2021160981A1 PCT/GB2020/052724 GB2020052724W WO2021160981A1 WO 2021160981 A1 WO2021160981 A1 WO 2021160981A1 GB 2020052724 W GB2020052724 W GB 2020052724W WO 2021160981 A1 WO2021160981 A1 WO 2021160981A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
computing system
requested
access
data fields
Prior art date
Application number
PCT/GB2020/052724
Other languages
French (fr)
Inventor
William Alan WILLIAMS
Original Assignee
Cufflink.IO Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cufflink.IO Ltd filed Critical Cufflink.IO Ltd
Publication of WO2021160981A1 publication Critical patent/WO2021160981A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • C—CHEMISTRY; METALLURGY
    • C10—PETROLEUM, GAS OR COKE INDUSTRIES; TECHNICAL GASES CONTAINING CARBON MONOXIDE; FUELS; LUBRICANTS; PEAT
    • C10J—PRODUCTION OF PRODUCER GAS, WATER-GAS, SYNTHESIS GAS FROM SOLID CARBONACEOUS MATERIAL, OR MIXTURES CONTAINING THESE GASES; CARBURETTING AIR OR OTHER GASES
    • C10J3/00—Production of combustible gases containing carbon monoxide from solid carbonaceous fuels
    • C10J3/72—Other features
    • C10J3/725—Redox processes
    • C—CHEMISTRY; METALLURGY
    • C10—PETROLEUM, GAS OR COKE INDUSTRIES; TECHNICAL GASES CONTAINING CARBON MONOXIDE; FUELS; LUBRICANTS; PEAT
    • C10K—PURIFYING OR MODIFYING THE CHEMICAL COMPOSITION OF COMBUSTIBLE GASES CONTAINING CARBON MONOXIDE
    • C10K3/00—Modifying the chemical composition of combustible gases containing carbon monoxide to produce an improved fuel, e.g. one of different calorific value, which may be free from carbon monoxide
    • C10K3/02—Modifying the chemical composition of combustible gases containing carbon monoxide to produce an improved fuel, e.g. one of different calorific value, which may be free from carbon monoxide by catalytic treatment
    • C10K3/04—Modifying the chemical composition of combustible gases containing carbon monoxide to produce an improved fuel, e.g. one of different calorific value, which may be free from carbon monoxide by catalytic treatment reducing the carbon monoxide content, e.g. water-gas shift [WGS]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • C—CHEMISTRY; METALLURGY
    • C10—PETROLEUM, GAS OR COKE INDUSTRIES; TECHNICAL GASES CONTAINING CARBON MONOXIDE; FUELS; LUBRICANTS; PEAT
    • C10J—PRODUCTION OF PRODUCER GAS, WATER-GAS, SYNTHESIS GAS FROM SOLID CARBONACEOUS MATERIAL, OR MIXTURES CONTAINING THESE GASES; CARBURETTING AIR OR OTHER GASES
    • C10J2300/00—Details of gasification processes
    • C10J2300/09—Details of the feed, e.g. feeding of spent catalyst, inert gas or halogens
    • C10J2300/0953—Gasifying agents
    • C10J2300/0956—Air or oxygen enriched air
    • C—CHEMISTRY; METALLURGY
    • C10—PETROLEUM, GAS OR COKE INDUSTRIES; TECHNICAL GASES CONTAINING CARBON MONOXIDE; FUELS; LUBRICANTS; PEAT
    • C10J—PRODUCTION OF PRODUCER GAS, WATER-GAS, SYNTHESIS GAS FROM SOLID CARBONACEOUS MATERIAL, OR MIXTURES CONTAINING THESE GASES; CARBURETTING AIR OR OTHER GASES
    • C10J2300/00—Details of gasification processes
    • C10J2300/09—Details of the feed, e.g. feeding of spent catalyst, inert gas or halogens
    • C10J2300/0953—Gasifying agents
    • C10J2300/0973—Water
    • C—CHEMISTRY; METALLURGY
    • C10—PETROLEUM, GAS OR COKE INDUSTRIES; TECHNICAL GASES CONTAINING CARBON MONOXIDE; FUELS; LUBRICANTS; PEAT
    • C10J—PRODUCTION OF PRODUCER GAS, WATER-GAS, SYNTHESIS GAS FROM SOLID CARBONACEOUS MATERIAL, OR MIXTURES CONTAINING THESE GASES; CARBURETTING AIR OR OTHER GASES
    • C10J2300/00—Details of gasification processes
    • C10J2300/09—Details of the feed, e.g. feeding of spent catalyst, inert gas or halogens
    • C10J2300/0983—Additives
    • C10J2300/0996—Calcium-containing inorganic materials, e.g. lime
    • C—CHEMISTRY; METALLURGY
    • C10—PETROLEUM, GAS OR COKE INDUSTRIES; TECHNICAL GASES CONTAINING CARBON MONOXIDE; FUELS; LUBRICANTS; PEAT
    • C10J—PRODUCTION OF PRODUCER GAS, WATER-GAS, SYNTHESIS GAS FROM SOLID CARBONACEOUS MATERIAL, OR MIXTURES CONTAINING THESE GASES; CARBURETTING AIR OR OTHER GASES
    • C10J2300/00—Details of gasification processes
    • C10J2300/16—Integration of gasification processes with another plant or parts within the plant
    • C10J2300/164—Integration of gasification processes with another plant or parts within the plant with conversion of synthesis gas
    • C10J2300/1656—Conversion of synthesis gas to chemicals
    • C10J2300/1659—Conversion of synthesis gas to chemicals to liquid hydrocarbons
    • C—CHEMISTRY; METALLURGY
    • C10—PETROLEUM, GAS OR COKE INDUSTRIES; TECHNICAL GASES CONTAINING CARBON MONOXIDE; FUELS; LUBRICANTS; PEAT
    • C10J—PRODUCTION OF PRODUCER GAS, WATER-GAS, SYNTHESIS GAS FROM SOLID CARBONACEOUS MATERIAL, OR MIXTURES CONTAINING THESE GASES; CARBURETTING AIR OR OTHER GASES
    • C10J2300/00—Details of gasification processes
    • C10J2300/18—Details of the gasification process, e.g. loops, autothermal operation
    • C10J2300/1861—Heat exchange between at least two process streams
    • C10J2300/1884—Heat exchange between at least two process streams with one stream being synthesis gas
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Definitions

  • This invention relates to methods and apparatus for controlling access to personal data.
  • the present invention seeks to provide a new approach that can help to mitigate this concern.
  • 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 user device; a computing system requesting access to at least a portion of the personal data stored on the user device by sending an access request to the user device over a network connection, wherein the access request specifies: one or more requested user data fields of the personal data, and a period of time during which the computing system may access the requested user data fields; the user device receiving an input from the first user indicating acceptance of the access request; after the access request is accepted by the first user, the user device sending an encrypted representation of the requested user data fields over a communication link to a remote server, encrypted using a first encryption key; the user device sending an encrypted copy of the first encryption key, or a corresponding decryption key, to the computing system, encrypted using a public key of a public/private key pair; the user device sending an instruction to a distributed blockchain computer system, instruct
  • the invention provides a system for controlling access to personal data, the system comprising: an electronic user device; and a computing system, wherein the user device is configured: to receive, from a first user, personal data comprising one or more user data fields; to store the personal data in a memory of the user device; to receive an access request from the computing system over a network connection, requesting access to at least a portion of the personal data stored on the user device, wherein the access request specifies: one or more requested user data fields of the personal data, and a period of time during which the computing system may access the requested user data fields; to receive an input from the first user indicating acceptance or rejection of the access request; if the access request is accepted by the first user, to send an encrypted representation of the requested user data fields over a communication link to a remote server, encrypted using a first encryption key, and to send an encrypted copy of the first encryption key, or a corresponding decryption key, to the computing system, encrypted using a public key of a public/private key pair; and to
  • a time-limited access request to one or more fields of a user when a time-limited access request to one or more fields of a user’s personal data, which is stored encrypted in a remote server, is received from a computing system (which could be a device or system operated by a company such as a bank, for example), a corresponding smart contract is first stored in a blockchain of a distributed blockchain computer system, and an encrypted copy of a key for accessing the requested fields is sent to the computing system. Then, at a time when the computing system desires to retrieve the personal data, it instructs the distributed blockchain computer system to ask the remote server to send it the encrypted data.
  • a computing system which could be a device or system operated by a company such as a bank, for example
  • This approach enables the distributed blockchain computer system to check that any access conditions in the smart contract have been met, including checking that the request has been made within the specified time limit, and to instruct the server to release the encrypted data only when the access conditions are met.
  • the personal data is “pushed” securely from the remote server to the computing system, rather than being available to be “pulled” by the computing system, thereby ensuring a high level of security.
  • the remote server is preferably part of a distributed storage system.
  • the system may comprise the distributed storage system.
  • the distributed storage system may store a plurality of instances (i.e. copies) of the encrypted representation of the requested user data fields in a respective plurality of locations — e.g. in different towns, districts or countries.
  • Use of a distributed storage system can help to ensure reliable availability to the user’s data. Having multiple copies of the data stored across a plurality of locations improves the reliability of data access.
  • a single failure e.g. a local power outage or data corruption on one server. Having a plurality of distributed copies can mitigate this risk.
  • a distributed storage system means that there is not a central point of failure.
  • a centralised network e.g. owned and operated by a single business, can be subject to complete failure as a result of, for example, power outages, hardware failures, or if the business goes bankrupt.
  • Distributed storage can also provide speed benefits due to the pooling of resources between different storage areas (e.g. servers) of the distributed storage system. Further, decentralised storage can assist with interoperability, as multiple copies of a given piece of data may be stored in different formats usable by different operating systems.
  • the distributed blockchain computer system is preferably a public distributed blockchain computer system accessible over the Internet, such as an Ethereum blockchain. This can help to ensure user trust in the enforcement of the smart contract.
  • the distributed blockchain computer system may store a plurality of instances (i.e. copies) of the smart contract at a respective plurality of locations — e.g. in different towns, districts or countries. This can ensure good availability to the smart contract.
  • the access request may further specify a reason for accessing the requested data and/or a purpose for which the requested data may be used.
  • the access request may comprise a license agreement.
  • a licence agreement may specify at least the period of time for which the personal data is accessible by the second user.
  • the license agreement may also specify a legal basis for which the personal data will be used, e.g. completion of a contract, marketing to customers, tax law compliance etc. Specifying the legal basis or bases and the time period in the license agreement can ensure the method and system comply with applicable privacy laws, such as the European Union’s General Data Protection Regulation (GDPR) that governs the handling of personal data.
  • GDPR General Data Protection Regulation
  • the licence agreement may optionally include data identifying the second user including one or more of: an IP address, an organisation (second user) location, an access key or code belonging to the second user, pre-payment codes (e.g. in the case that the personal data is being used as part of a commercial/financial transaction), or expiry of a subscription by the second user.
  • data identifying the second user including one or more of: an IP address, an organisation (second user) location, an access key or code belonging to the second user, pre-payment codes (e.g. in the case that the personal data is being used as part of a commercial/financial transaction), or expiry of a subscription by the second user.
  • the distributed blockchain computer system may use or process the smart contract to verify that the time of the request from the computing system is within the period of time. Having the smart contract executed by the blockchain keeps the control of the personal data away from the second user. This reduces the possibility of, for example, the second user hacking the smart contract. This is because the smart contract itself is not stored upon/run using computers within the control of the second user.
  • the terms of the smart contract may be visible to all parties (i.e. public information) to encourage transparency in the terms of exchange of personal data as well as providing evidence of the terms in case of a (later) dispute.
  • the smart contract may comprise the data representative of the period of time during which the computing system may access the requested user data fields, or the smart contract may comprise data — e.g. a link, address or identifier — for accessing the data representative of the period of time.
  • data representative of the accepted access request e.g. a copy of the licence agreement
  • the smart contract may be able to obtain data representative of the period of time from the access-request data stored on the server or distributed storage system.
  • the smart contract may optionally comprise further access conditions.
  • the smart contract may comprise data representative of a reason for accessing the requested data and/or a purpose for which the requested data may be used.
  • the request from the computing system to the distributed blockchain computer system may specify a reason for the computing system to access the requested data or a purpose for which the data requested by the computing system will be used. This can ensure compliance with applicable privacy laws, such as the GDPR, and can provide at least part of a record showing that the data was handled in compliance with the applicable privacy laws in case of a dispute.
  • applicable privacy laws such as the GDPR
  • the distributed blockchain computer system may process the smart contract to verify that the received data representative of a reason or a purpose satisfies the smart contract.
  • the first user may modify at least one of the requested user data fields, or a purpose for which the requested data may be used, in the access request received by the user device.
  • the input received from the first user may then indicate acceptance of the modified access request. This can allow users to reject certain conditions that are optional (i.e. not essential for the primary purpose of the sharing of personal data).
  • a second user may request a first set of data fields for, say, completion of an online order, but may also request a second set of data fields (which may be distinct from, or may intersect, the first set) for the purposes of marketing to the first user.
  • the first user may choose to refuse access to the data field required for marketing as this is irrelevant to the online order, while accepting those parts of the agreement required for completion of the online order (e.g. name, delivery address, payment details).
  • provision of the personal data may have a financial cost, e.g. paid by the second user when the second user accesses the personal data.
  • the financial cost of the personal data may be adjusted based on the data fields provided by the first user, i.e.
  • the personal data may be more valuable to the second user if the licence agreement allows use of the personal data for marketing and, optionally, contains additional data fields that are useful for marketing (e.g. date of birth).
  • the second user may be willing to pay a higher price (some of which may be paid to the first user) for the personal data if it includes marketing authorisation.
  • the higher cost of some personal data can encourage data minimisation, i.e. second users not requesting more data than they require.
  • the first user may use the user device to amend the personal data, including amending at least one of the one or more requested user data fields; and the user device may then encrypt and send the amended one or more requested user data fields to the remote server.
  • the first user may update the relevant data fields using the user device. This update may then be “pushed” to the distributed storage such that any subsequent retrieval of the personal data by a second user (duly authorised by the smart contract) will retrieve the most up-to-date data for that data field.
  • This allows the first user to update their personal data in one place and any/all second users to receive the most up-to-date data.
  • second users store their own copies of personal data
  • the data can easily become incorrect/out of data if the first user forgets to inform that specific second user. For example, the first user may remember to update their address after a house move with some online retailers, but may forget others that are less frequently used. This may lead to misdirected marketing materials (e.g. to the old address) or misdirected packages.
  • the computing system may later delete the received personal data. This can ensure that data is even more secure by deleting the data, for example, after the time period has elapsed. Thus, there is not a copy of the data left “lying around” after it is no longer needed, where it may remain vulnerable to, e.g. hacking attacks on the computing system. This can reduce the potential liability for the second user that operates the computing system, i.e. by reducing the amount of data that could potentially be stolen in a data breach. This can also reduce costs for the second user by reducing the storage space needed for storing data from a plurality of first users (e.g. a plurality of customers for a business). This can help the second user comply with applicable laws, such as the “right to be forgotten”.
  • the computing system may be configured to automatically delete the received personal data at a given time/under given conditions (such as those specified in the licence agreement) to assist in compliance with applicable data protection laws.
  • the computing system may use the decrypted personal data, and the deleting may then occur in response to the computing system finishing using the decrypted personal data or in response to the period of time specified by the access request elapsing. As above, this may reduce the potential liability for the second user and reduce data storage costs. This may also reduce the transfer costs to the second user (e.g. smaller data packets) with a respective single second user — i.e. not shared between multiple users (N.B. in the case where the second user is an organisation, multiple natural people within that organisation may be permitted access to the personal data).
  • the time periods for accessing certain data fields of the personal data may expire at different times. For example, some data fields may be necessary for completion of a contract and may be needed for, say, 60 days, while data relating solely to marketing may be needed (requested) for 20 days. Individual data fields may be removed from the encrypted personal data stored on the distributed storage once the time period specified for that data field has elapsed, while other data fields may remain if they have a longer associated time period.
  • access to the personal data is dependent upon the smart contract’s approval.
  • approval of access to the personal information is executed prior to, and separately from, the retrieval of the encrypted personal data. This ensures there are no data access charges or data processing until the terms of the license agreement have been satisfied.
  • the system may comprise at least one node of the distributed blockchain computer system, wherein the distributed blockchain computer system is configured to: receive the instruction from the user device to store the smart contract in the blockchain and, in response, to store the smart contract in the blockchain; and receive the request from the computing system to instruct the remote server to transmit the encrypted representation of the requested user data fields to the computing system and, in response, to send an instruction to the remote server to transmit the encrypted representation of the requested user data fields to the computing system.
  • the system may further comprise the remote server, wherein the server is configured to: receive the encrypted representation of the requested user data fields from the user device and to store the encrypted representation in a memory of the server; and receive an instruction from the distributed blockchain computer system to transmit the encrypted representation of the requested user data fields to the computing system and, in response, to transmit the encrypted representation to the computing system.
  • the server is configured to: receive the encrypted representation of the requested user data fields from the user device and to store the encrypted representation in a memory of the server; and receive an instruction from the distributed blockchain computer system to transmit the encrypted representation of the requested user data fields to the computing system and, in response, to transmit the encrypted representation to the computing system.
  • the remote server may be configured not to transmit the encrypted representation of the requested user data fields to the computing system unless instructed to do so by the distributed blockchain computer system.
  • the system may comprise a distributed data storage system, wherein the distributed data storage system comprises the remote server.
  • the distributed data storage system may be configured to store a plurality of instances (i.e. copies) of the encrypted representation of the requested user data fields distributed across a plurality of respective locations.
  • the license agreement may expire or change independently of the encrypted personal data.
  • the license may thus be the "Terms" of access and these may be assessed (e.g. by the second user) prior to accessing the personal data. If the terms are acceptable, then the second user may obtain the encrypted personal data. Notably, the terms may change after the initial action of storing the encrypted personal data and the license agreement on the distributed storage. This ensures that the processed for updating the terms of the license agreement (e.g. to extend the period of time, or to revoke a particular permission, such as “marketing”) is entirely separate from the process of updating the encrypted personal data. Updating of the encrypted personal data does not necessarily involve the smart contract on the blockchain.
  • the license agreement may also contain information regarding the freshness of the personal information (i.e. when that personal information was last updated). Some personal data does not change (e.g. date of birth), but other data can change frequently (e.g. home address). Some second users may be less interested in old data due to the increased possibility that said data is now incorrect. These aspects of the personal data may be checked prior to the access of the personal data (which can incur a financial cost from the distributed storage). A multi-day “clearing period” may also be implemented in the smart contract for the purposes of dispute resolution. In this event, all access to the personal data can be temporarily "suspended" without deleting the entire licence agreement and/or smart contract by the data owner (the first user) while a dispute is resolved.
  • the first encryption key may be a symmetric key (e.g. AES) or an asymmetric key (e.g. RSA).
  • the first encryption key may also be a decryption key, or it may have a corresponding decryption key, e.g. as part of a public/private key pair.
  • the encrypted copy of the first encryption key, or a corresponding decryption key may be encrypted using a public key of any appropriate public/private key pair, such as an RSA key pair, or an elliptic-curve key pair.
  • the public/private key pair may be associated with the computing system — e.g. being a public key of an entity which owns or controls the computing system. It may be certified by a certificate authority of a public key infrastructure (PKI).
  • PKI public key infrastructure
  • the electronic user device may be a smart phone, a personal computer, a laptop computer, an in-car infotainment system, or any other suitable device. It may comprise a processor and a memory for storing software instructions for execution by the processor. Any of the user-device operations disclosed herein may be performed by software executing on the device and/or by dedicated hardware logic in the user device and/or a combination of both.
  • the computing system may be a single device, e.g. a single server, or it may comprise a plurality of computing devices, which may be on a single physical site or may be distributed geographically. It may comprise a network — e.g. a corporate local area network (LAN) or wide area network (WAN) — linking multiple computing devices.
  • the computing system may comprise one or more processors and a memory for storing software instructions for execution by the one or more processors. Any of the operations disclosed herein that are carried out by the computing system may be performed by software executing on the computing system and/or by dedicated hardware logic in the computing system and/or a combination of both.
  • Any of the communications disclosed herein may be sent over any combination of wired links (e.g. metal wires or fibre optic cables) and/or wireless links (e.g. using a radio protocol such as WiFiTM or 4G, or optical or microwave links). They may be sent over private and/or public network connections, which may include the public Internet. Links may be secured, e.g. using encryption. Devices may be configured to perform cryptographic authentication of other devices disclosed herein before communicating indicated data.
  • wired links e.g. metal wires or fibre optic cables
  • wireless links e.g. using a radio protocol such as WiFiTM or 4G, or optical or microwave links. They may be sent over private and/or public network connections, which may include the public Internet. Links may be secured, e.g. using encryption.
  • Devices may be configured to perform cryptographic authentication of other devices disclosed herein before communicating indicated data.
  • Data and messages such as "access requests”, “personal data”, “instructions”, “keys”, “the period of time”, etc. disclosed herein may each be encoded and/or modulated in any appropriate way.
  • the same data may be encoded differently at different times (e.g. being encoded in a first way for communication and encoded in a second way for storage).
  • 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.
  • Figure 1 shows an exemplary computing system embodying the invention.
  • the system generally comprises a 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.
  • the data fields may be “Name”, “Postal Address”, “Banking Address”, “Date of Birth” etc.
  • a second user 20 wishes to obtain some of the personal data from the first user.
  • the second user 20 may be a natural person or may be a legal person, such as a business or government.
  • the second user 20 uses an associated computing device or computing system (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.
  • some of personal data of the first user is sent from the user device 10 and is stored in encrypted form in a distributed storage system 40. Subsequent access to this encrypted personal data (e.g. by the second user 20) is managed by a smart contract running on a blockchain 30.
  • the second user 20 has sent a licence agreement (an access request) to the first user’s device 10, e.g. via the internet or phone network, which indicates personal data that the second user wishes to access (i.e. which fields of data, such as “Name”, “Postal Address” etc.) and the purposes for which the second user 20 intends to use that personal data.
  • the first user reviews the license agreement on the user device 10 and either modifies it, rejects it, or accepts it.
  • the licence agreement specifies at least a period of time during which the second user 20 is allowed access to the personal data — e.g. a week, a month or a year, or between a pair of specified dates, or from now until a specified future date.
  • the data fields specified in the license agreement may be a subset of the full set of personal data that the first user has entered into the first device 10. That is, the second user may only require some pieces of personal data and the license agreement may specify them accordingly.
  • the requested personal data on the user device 10 is encrypted using an encryption key 14 to form encrypted personal data 12 and is sent to the distributed storage 40.
  • a copy of the accepted licence agreement is also stored on the distributed storage with a datum indicating the storage location of the encrypted personal data within the distributed storage 40.
  • a server 16 may optionally be used to distribute the encrypted personal data and the encryption key 14, as well as to set up the smart contract to be stored on the blockchain 30.
  • the server 12 sends the encryption key 14 to the second user 20.
  • the encryption key 14 (or, equivalently, a corresponding decryption key 14) may be sent in encrypted form to the second user 20.
  • the server also passes the encrypted personal data 12 to the distributed storage 40.
  • the server sets up a smart contract and stores this on the blockchain 30. Thereafter, the smart contract, in cooperation with the license agreement stored in the distributed storage 40, mediates access to the encrypted personal data 12 by the second user 20.
  • the smart contract comprises executable code that is run on the blockchain.
  • the smart contract checks whether the request meets predetermined access conditions. This may be done by the smart contract checking the terms set out in license agreement in the distributed storage 40. At least one of the access conditions that the smart contract checks is that the request from the second user 20 is within the predetermined period of time (i.e. the period also specified in the license agreement).
  • the smart contract may also check a location from which the request comes (e.g. IP address), optionally along with other data, in order to confirm that it is indeed the second user 20 making the request and not a (malicious) third party.
  • the access conditions may also relate to a transaction cost — e.g. granting access only if the second user 20 has sufficient money in a blockchain account to pay a required fee for the transaction.
  • the smart contract sends a release request to the distributed storage.
  • the release request either causes the distributed storage to send the encrypted personal data 12 to the second user, or instructs the distributed storage to allow the second user 20 to download the encrypted personal data 12.
  • the second user 20 then decrypts the encrypted personal data 12 using the encryption key 14 (or using a private key corresponding to the public key used to encrypt the personal information stored on the distributed storage) and thereby gains access to the personal data.
  • the smart contract may be implemented as a "request process" that checks the license agreement on the distributed storage 40 to determine if the access request meets the access requirements. If the access requirements are met, then the location of the encrypted personal data 12 in the distributed storage 40 is passed to the smart contract.
  • the location may be distributed to the second user has a hash.
  • the hash may be public on the distributed storage but, in view of the encryption of the personal data, public knowledge of the hash does not make the personal data public.
  • the smart contract only has access to the encrypted personal data upon successful evaluation, i.e. upon determining that the access conditions are met.
  • the smart contract is public so the location of the encrypted personal data will be made available (visible) only after the access conditions have been approved.
  • the personal data may be encrypted using a public key owned by the second user (having an associated private key).
  • Figure 2 shows a flow diagram of a method 100 for securely providing a first user’s personal data to a second user (which may be a natural or legal entity).
  • the four main entities involved are the first user’s device 10, the second user’s computing system 20 (referred to as the second user 20 for convenience), a distributed blockchain computing system (referred to as blockchain 30 for convenience), and a distributed storage system 40. These entities may communicate over a network, e.g. the internet.
  • the first user device 10 may be a smartphone.
  • the second user system 20 may be a corporate network or server.
  • the blockchain 30 may be a public Ethereum blockchain.
  • the distributed storage 40 may be a server farm distributed across multiple geographical locations within one country or across multiple countries.
  • the first user enters personal data on his/her device 10 by filling in appropriate data fields.
  • the completed data fields, which then make up the personal data may include, for example, the first user’s name, postal address, date of birth, bank account details, billing address, medical history etc.
  • the second user 20 wishes to gain access to a portion of the first user’s personal data.
  • the second user 20 sends a License Agreement to the user device 10 (i.e. to the first user).
  • the License Agreement contains at least the following information:
  • the requested data fields • The legal bases for processing the personal data;
  • the above Legal Bases are defined under the European Union General Data Protection Regulation (GDPR), that has been implemented in EU states.
  • GDPR European Union General Data Protection Regulation
  • the GDPR groups the over-arching 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.
  • the device 10 obtains a public key from the second user 20 at step 106.
  • This public key is one part of a public/private key pair.
  • the operation of public key cryptography using public/private key pairs, such as RSA or elliptic-curve cryptography, is well- known in the field.
  • obtaining the public key is depicted as the second user 20 sending the public key to the device 10 (e.g. along with the license agreement).
  • step 106 could alternatively involve the device 10 looking up the public key associated with the second user 20, e.g. on a webpage operated by the second user or a key server.
  • the first user accepts the license agreement on the device 10, e.g. by interacting with a graphical user interface.
  • the user may modify the license agreement in some manner, e.g. to deselect the provision of personal data that the first user does not wish to share with the second user, before accepting it.
  • the device 10 encrypts the requested personal data, i.e. encrypts the first user’s personal data corresponding to the requested data fields that were specified in the license agreement.
  • the device encrypts the requested personal data using an encryption key, Key1, that is generated by or has been stored on the device 10.
  • the device 10 sends the encrypted personal data to the distributed storage 40 along with a copy of the licence agreement, which stores the encrypted data and license agreement for later retrieval.
  • the device encrypts the encryption key (Key1) using the second user’s public key to produce an encrypted encryption key (eKeyl).
  • Key1 is a symmetric key, e.g. an AES key, so the same key can both encrypt and decrypt.
  • the decryption key could be different from the encryption key, Key1, in which case the decryption key is encrypted to form eKeyl,
  • the encrypted key (eKeyl) is sent to the second user 20.
  • the second user 20 has the corresponding private key of the public/private key pair, the second user 20 can now decrypt the encrypted encryption key (eKeyl) at any point.
  • the decryption of the encrypted key (eKeyl) is performed at step 128 (i.e. just before the key is required) but this order of steps is purely exemplary.
  • the device 10 sends a smart contract to the blockchain 30.
  • the smart contract contains at least the access conditions that must be met before access to the personal data is permitted.
  • the smart contract may either contain a copy of the access conditions itself, or the smart contract may be configured to check the access conditions stored in the license agreement in the distributed storage 40.
  • the second user 20 then sends a request (at step 120) to the smart contract on the blockchain 30 to access the encrypted personal data (and license agreement) stored on the distributed storage 40.
  • the smart contract checks that the access request meets the access conditions at step 122. For example, the smart contract checks the current date to see if the date is within the time period specified in the license agreement that was agreed to by the first user.
  • the smart contract sends an approval signal to the distributed storage, at step 124, to provide the encrypted personal data (and license agreement) to the second user 20.
  • the encrypted personal data (and license agreement) are provided to the second user 20 at step 126.
  • the second user now has both the encrypted personal data and license agreement and the encryption key (possibly still in encrypted form, encrypted with the second user’s public key).
  • the second user then decrypts the encryption key at step 128, if not already done, and then, at step 130, uses the encryption key to decrypt the personal data.
  • the second user system 20 is operated by an online business and the first user is a customer trying to purchase an item from the online business.
  • the first user has browsed for and selected the desired item and now wishes to checkout.
  • 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 20 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.
  • the first user has already entered personal data into their device 10, i.e. performed step 102.
  • the online business sends a licence agreement to the first user (i.e. step 104) requesting access to the following data fields: name, postal address, bank account details, billing address.
  • the personal data may encompass other fields, such as date of birth or medical history.
  • the second user does not request this data.
  • the License Agreement may contain:
  • this 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)
  • the customer may accept the License Agreement as it is.
  • 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 device 10 then encrypts the requested personal data (name, postal address, bank account details etc.) using an encryption key and sends this to the distributed storage 40.
  • the device 10 then encrypts the encryption key and sends the encrypted encryption key to the online business (i.e. second user 20).
  • the device 10 also sends a smart contract to the blockchain 30 indicating the access conditions for accessing the personal data.
  • the access conditions specify at least the time period of 60 days during which the online business may access the encrypted personal information.
  • the access conditions also contain information for identifying the online business, so that the smart contract can check that the access request comes from the online business and not some other party.
  • the online business sends an access request to the smart contract.
  • the smart contract checks that the access conditions are indeed fulfilled by the access request.
  • the smart contract then contacts the distributed storage which then sends the encrypted data to the online business.
  • the online business then decrypts the encrypted encryption key, using the private key of the public/private key pair, and then uses the encryption key to decrypt the personal data.
  • the online business then fulfils the order by taking payment using the customer’s bank details, and ships the item to the customer’s address.
  • the online business may then delete the personal information immediately or may store the personal information for the length of time specified in the license agreement. If the personal information is required again, within the time limit specified in the smart contract, the online business can re-request access (i.e. repeat steps 120 onwards in Figure 2) by contacting the smart contract and obtaining the information again.
  • re-request access i.e. repeat steps 120 onwards in Figure 2
  • the device 10 may update the personal information in all of the user’s encrypted personal data sets stored on the blockchain. As the device 10 knows all of the encrypted personal data sets that it has sent to the blockchain, these may all be updated by only a single effort by the user, i.e. updating the address on their device 10.
  • the user can decide to refuse further access to their data on the blockchain, e.g. by updating the access conditions on any/all of the user’s smart contracts on the blockchain 30. This gives users control over their own personal data.
  • 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.
  • first users’ data e.g. customers’ data

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Chemical & Material Sciences (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Combustion & Propulsion (AREA)
  • Organic Chemistry (AREA)
  • Oil, Petroleum & Natural Gas (AREA)
  • General Chemical & Material Sciences (AREA)
  • Chemical Kinetics & Catalysis (AREA)
  • Medical Informatics (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)

Abstract

An electronic user device stores personal data, relating to a first user, comprising one or more user data fields, in a memory of the user device. A computing system requests access to at least a portion of the personal data by sending an access request to the user device, which specifies one or more requested user data fields, and a period of time during which the computing system may access the requested user data fields. If the first user accepts the access request, the user device sends an encrypted representation of the requested user data fields to a remote server, encrypted using a first encryption key. It sends an encrypted copy of the first encryption key to the computing system, encrypted using a public key of a public/private key pair. It sends an instruction to a distributed blockchain computer system, instructing the blockchain system to store a smart contract, in a blockchain, comprising data representative of said period of time. The computing system then sends, at a time within said period of time, a request to the distributed blockchain computer system to instruct the remote server to transmit the encrypted representation of the requested user data fields to the computing system. The computing system then uses a private key of the public/private key pair to decrypt the first encryption key which it uses to decrypt the requested user data fields, thus gaining access to the personal data.

Description

Methods and Apparatus for Controlling Access to Personal Data
BACKGROUND OF THE INVENTION
This invention relates to methods and apparatus for controlling access to personal data.
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 provide 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 user device; a computing system requesting access to at least a portion of the personal data stored on the user device by sending an access request to the user device over a network connection, wherein the access request specifies: one or more requested user data fields of the personal data, and a period of time during which the computing system may access the requested user data fields; the user device receiving an input from the first user indicating acceptance of the access request; after the access request is accepted by the first user, the user device sending an encrypted representation of the requested user data fields over a communication link to a remote server, encrypted using a first encryption key; the user device sending an encrypted copy of the first encryption key, or a corresponding decryption key, to the computing system, encrypted using a public key of a public/private key pair; the user device sending an instruction to a distributed blockchain computer system, instructing the distributed blockchain computer system to store a smart contract in a blockchain, wherein the smart contract comprises, or has access to, data representative of said period of time during which the computing system may access the requested user data fields; the computing system sending, at a time within said period of time, a request to the distributed blockchain computer system, requesting the distributed blockchain computer system to instruct the remote server to transmit the encrypted representation of the requested user data fields to the computing system; the computing system receiving the encrypted representation of the requested user data fields from the remote server; the computing system using a private key of the public/private key pair to decrypt the first encryption key or corresponding decryption key; and the computing system using the decrypted first encryption key, or corresponding decryption key, to decrypt the requested user data fields.
From a second aspect, the invention provides a system for controlling access to personal data, the system comprising: an electronic user device; and a computing system, wherein the user device is configured: to receive, from a first user, personal data comprising one or more user data fields; to store the personal data in a memory of the user device; to receive an access request from the computing system over a network connection, requesting access to at least a portion of the personal data stored on the user device, wherein the access request specifies: one or more requested user data fields of the personal data, and a period of time during which the computing system may access the requested user data fields; to receive an input from the first user indicating acceptance or rejection of the access request; if the access request is accepted by the first user, to send an encrypted representation of the requested user data fields over a communication link to a remote server, encrypted using a first encryption key, and to send an encrypted copy of the first encryption key, or a corresponding decryption key, to the computing system, encrypted using a public key of a public/private key pair; and to send an instruction to a distributed blockchain computer system, instructing the distributed blockchain computer system to store a smart contract in a blockchain, wherein the smart contract comprises, or has access to, data representative of said period of time during which the computing system may access the requested user data fields, and wherein the second electronic device is configured: to send said access request to the user device; to send a request to the distributed blockchain computer system, requesting the distributed blockchain computer system to instruct the remote server to transmit the encrypted representation of the requested user data fields to the computing system; to receive the encrypted representation of the requested user data fields from the remote server; to use a private key of the public/private key pair to decrypt the first encryption key, or corresponding decryption key; and to use the decrypted first encryption key, or corresponding decryption key, to decrypt the requested user data fields.
Thus it will be seen that, in accordance with the invention, when a time-limited access request to one or more fields of a user’s personal data, which is stored encrypted in a remote server, is received from a computing system (which could be a device or system operated by a company such as a bank, for example), a corresponding smart contract is first stored in a blockchain of a distributed blockchain computer system, and an encrypted copy of a key for accessing the requested fields is sent to the computing system. Then, at a time when the computing system desires to retrieve the personal data, it instructs the distributed blockchain computer system to ask the remote server to send it the encrypted data. This approach enables the distributed blockchain computer system to check that any access conditions in the smart contract have been met, including checking that the request has been made within the specified time limit, and to instruct the server to release the encrypted data only when the access conditions are met. In this way, the personal data is “pushed” securely from the remote server to the computing system, rather than being available to be “pulled” by the computing system, thereby ensuring a high level of security.
The remote server is preferably part of a distributed storage system. The system may comprise the distributed storage system. The distributed storage system may store a plurality of instances (i.e. copies) of the encrypted representation of the requested user data fields in a respective plurality of locations — e.g. in different towns, districts or countries. Use of a distributed storage system can help to ensure reliable availability to the user’s data. Having multiple copies of the data stored across a plurality of locations improves the reliability of data access. When data is stored in a single location, there is a risk of data loss from a single failure e.g. a local power outage or data corruption on one server. Having a plurality of distributed copies can mitigate this risk. In particular, using a distributed storage system means that there is not a central point of failure. By contrast, a centralised network, e.g. owned and operated by a single business, can be subject to complete failure as a result of, for example, power outages, hardware failures, or if the business goes bankrupt. Distributed storage can also provide speed benefits due to the pooling of resources between different storage areas (e.g. servers) of the distributed storage system. Further, decentralised storage can assist with interoperability, as multiple copies of a given piece of data may be stored in different formats usable by different operating systems.
The distributed blockchain computer system is preferably a public distributed blockchain computer system accessible over the Internet, such as an Ethereum blockchain. This can help to ensure user trust in the enforcement of the smart contract. The distributed blockchain computer system may store a plurality of instances (i.e. copies) of the smart contract at a respective plurality of locations — e.g. in different towns, districts or countries. This can ensure good availability to the smart contract.
The access request may further specify a reason for accessing the requested data and/or a purpose for which the requested data may be used. The access request may comprise a license agreement. A licence agreement may specify at least the period of time for which the personal data is accessible by the second user. The license agreement may also specify a legal basis for which the personal data will be used, e.g. completion of a contract, marketing to customers, tax law compliance etc. Specifying the legal basis or bases and the time period in the license agreement can ensure the method and system comply with applicable privacy laws, such as the European Union’s General Data Protection Regulation (GDPR) that governs the handling of personal data. The licence agreement may optionally include data identifying the second user including one or more of: an IP address, an organisation (second user) location, an access key or code belonging to the second user, pre-payment codes (e.g. in the case that the personal data is being used as part of a commercial/financial transaction), or expiry of a subscription by the second user.
The distributed blockchain computer system may use or process the smart contract to verify that the time of the request from the computing system is within the period of time. Having the smart contract executed by the blockchain keeps the control of the personal data away from the second user. This reduces the possibility of, for example, the second user hacking the smart contract. This is because the smart contract itself is not stored upon/run using computers within the control of the second user. The terms of the smart contract may be visible to all parties (i.e. public information) to encourage transparency in the terms of exchange of personal data as well as providing evidence of the terms in case of a (later) dispute.
The smart contract may comprise the data representative of the period of time during which the computing system may access the requested user data fields, or the smart contract may comprise data — e.g. a link, address or identifier — for accessing the data representative of the period of time. In some embodiments, data representative of the accepted access request (e.g. a copy of the licence agreement) is stored on the server or distributed storage system. In such embodiments, the smart contract may be able to obtain data representative of the period of time from the access-request data stored on the server or distributed storage system. The smart contract may optionally comprise further access conditions. The smart contract may comprise data representative of a reason for accessing the requested data and/or a purpose for which the requested data may be used. The request from the computing system to the distributed blockchain computer system may specify a reason for the computing system to access the requested data or a purpose for which the data requested by the computing system will be used. This can ensure compliance with applicable privacy laws, such as the GDPR, and can provide at least part of a record showing that the data was handled in compliance with the applicable privacy laws in case of a dispute.
The distributed blockchain computer system may process the smart contract to verify that the received data representative of a reason or a purpose satisfies the smart contract.
The first user may modify at least one of the requested user data fields, or a purpose for which the requested data may be used, in the access request received by the user device. The input received from the first user may then indicate acceptance of the modified access request. This can allow users to reject certain conditions that are optional (i.e. not essential for the primary purpose of the sharing of personal data).
For example, a second user may request a first set of data fields for, say, completion of an online order, but may also request a second set of data fields (which may be distinct from, or may intersect, the first set) for the purposes of marketing to the first user. The first user may choose to refuse access to the data field required for marketing as this is irrelevant to the online order, while accepting those parts of the agreement required for completion of the online order (e.g. name, delivery address, payment details). In some cases, provision of the personal data may have a financial cost, e.g. paid by the second user when the second user accesses the personal data. The financial cost of the personal data may be adjusted based on the data fields provided by the first user, i.e. accepted by the first user in the licence agreement For example, the personal data may be more valuable to the second user if the licence agreement allows use of the personal data for marketing and, optionally, contains additional data fields that are useful for marketing (e.g. date of birth). In this case the second user may be willing to pay a higher price (some of which may be paid to the first user) for the personal data if it includes marketing authorisation. The higher cost of some personal data can encourage data minimisation, i.e. second users not requesting more data than they require. The first user may use the user device to amend the personal data, including amending at least one of the one or more requested user data fields; and the user device may then encrypt and send the amended one or more requested user data fields to the remote server. If the first user’s data changes over time, for example, if the first user moves house, moves business address, changes phone number, changes marital status, etc., the first user may update the relevant data fields using the user device. This update may then be “pushed” to the distributed storage such that any subsequent retrieval of the personal data by a second user (duly authorised by the smart contract) will retrieve the most up-to-date data for that data field. This allows the first user to update their personal data in one place and any/all second users to receive the most up-to-date data. By contrast, in arrangements where second users store their own copies of personal data, the data can easily become incorrect/out of data if the first user forgets to inform that specific second user. For example, the first user may remember to update their address after a house move with some online retailers, but may forget others that are less frequently used. This may lead to misdirected marketing materials (e.g. to the old address) or misdirected packages.
The computing system may later delete the received personal data. This can ensure that data is even more secure by deleting the data, for example, after the time period has elapsed. Thus, there is not a copy of the data left “lying around” after it is no longer needed, where it may remain vulnerable to, e.g. hacking attacks on the computing system. This can reduce the potential liability for the second user that operates the computing system, i.e. by reducing the amount of data that could potentially be stolen in a data breach. This can also reduce costs for the second user by reducing the storage space needed for storing data from a plurality of first users (e.g. a plurality of customers for a business). This can help the second user comply with applicable laws, such as the “right to be forgotten”. The computing system may be configured to automatically delete the received personal data at a given time/under given conditions (such as those specified in the licence agreement) to assist in compliance with applicable data protection laws.
The computing system may use the decrypted personal data, and the deleting may then occur in response to the computing system finishing using the decrypted personal data or in response to the period of time specified by the access request elapsing. As above, this may reduce the potential liability for the second user and reduce data storage costs. This may also reduce the transfer costs to the second user (e.g. smaller data packets) with a respective single second user — i.e. not shared between multiple users (N.B. in the case where the second user is an organisation, multiple natural people within that organisation may be permitted access to the personal data).
The time periods for accessing certain data fields of the personal data may expire at different times. For example, some data fields may be necessary for completion of a contract and may be needed for, say, 60 days, while data relating solely to marketing may be needed (requested) for 20 days. Individual data fields may be removed from the encrypted personal data stored on the distributed storage once the time period specified for that data field has elapsed, while other data fields may remain if they have a longer associated time period.
At least in a preferred set of embodiments, access to the personal data is dependent upon the smart contract’s approval.
At least in a preferred set of embodiments, approval of access to the personal information is executed prior to, and separately from, the retrieval of the encrypted personal data. This ensures there are no data access charges or data processing until the terms of the license agreement have been satisfied.
The system may comprise at least one node of the distributed blockchain computer system, wherein the distributed blockchain computer system is configured to: receive the instruction from the user device to store the smart contract in the blockchain and, in response, to store the smart contract in the blockchain; and receive the request from the computing system to instruct the remote server to transmit the encrypted representation of the requested user data fields to the computing system and, in response, to send an instruction to the remote server to transmit the encrypted representation of the requested user data fields to the computing system.
The system may further comprise the remote server, wherein the server is configured to: receive the encrypted representation of the requested user data fields from the user device and to store the encrypted representation in a memory of the server; and receive an instruction from the distributed blockchain computer system to transmit the encrypted representation of the requested user data fields to the computing system and, in response, to transmit the encrypted representation to the computing system.
The remote server may be configured not to transmit the encrypted representation of the requested user data fields to the computing system unless instructed to do so by the distributed blockchain computer system.
The system may comprise a distributed data storage system, wherein the distributed data storage system comprises the remote server. The distributed data storage system may be configured to store a plurality of instances (i.e. copies) of the encrypted representation of the requested user data fields distributed across a plurality of respective locations.
The license agreement may expire or change independently of the encrypted personal data. The license may thus be the "Terms" of access and these may be assessed (e.g. by the second user) prior to accessing the personal data. If the terms are acceptable, then the second user may obtain the encrypted personal data. Notably, the terms may change after the initial action of storing the encrypted personal data and the license agreement on the distributed storage. This ensures that the processed for updating the terms of the license agreement (e.g. to extend the period of time, or to revoke a particular permission, such as “marketing”) is entirely separate from the process of updating the encrypted personal data. Updating of the encrypted personal data does not necessarily involve the smart contract on the blockchain.
The license agreement may also contain information regarding the freshness of the personal information (i.e. when that personal information was last updated). Some personal data does not change (e.g. date of birth), but other data can change frequently (e.g. home address). Some second users may be less interested in old data due to the increased possibility that said data is now incorrect. These aspects of the personal data may be checked prior to the access of the personal data (which can incur a financial cost from the distributed storage). A multi-day “clearing period” may also be implemented in the smart contract for the purposes of dispute resolution. In this event, all access to the personal data can be temporarily "suspended" without deleting the entire licence agreement and/or smart contract by the data owner (the first user) while a dispute is resolved.
The first encryption key may be a symmetric key (e.g. AES) or an asymmetric key (e.g. RSA). The first encryption key may also be a decryption key, or it may have a corresponding decryption key, e.g. as part of a public/private key pair. The encrypted copy of the first encryption key, or a corresponding decryption key, may be encrypted using a public key of any appropriate public/private key pair, such as an RSA key pair, or an elliptic-curve key pair. The public/private key pair may be associated with the computing system — e.g. being a public key of an entity which owns or controls the computing system. It may be certified by a certificate authority of a public key infrastructure (PKI).
The electronic user device may be a smart phone, a personal computer, a laptop computer, an in-car infotainment system, or any other suitable device. It may comprise a processor and a memory for storing software instructions for execution by the processor. Any of the user-device operations disclosed herein may be performed by software executing on the device and/or by dedicated hardware logic in the user device and/or a combination of both.
The computing system may be a single device, e.g. a single server, or it may comprise a plurality of computing devices, which may be on a single physical site or may be distributed geographically. It may comprise a network — e.g. a corporate local area network (LAN) or wide area network (WAN) — linking multiple computing devices. The computing system may comprise one or more processors and a memory for storing software instructions for execution by the one or more processors. Any of the operations disclosed herein that are carried out by the computing system may be performed by software executing on the computing system and/or by dedicated hardware logic in the computing system and/or a combination of both.
Any of the communications disclosed herein may be sent over any combination of wired links (e.g. metal wires or fibre optic cables) and/or wireless links (e.g. using a radio protocol such as WiFi™ or 4G, or optical or microwave links). They may be sent over private and/or public network connections, which may include the public Internet. Links may be secured, e.g. using encryption. Devices may be configured to perform cryptographic authentication of other devices disclosed herein before communicating indicated data.
Data and messages such as "access requests", "personal data", "instructions", "keys", "the period of time", etc. disclosed herein may each be encoded and/or modulated in any appropriate way. The same data may be encoded differently at different times (e.g. being encoded in a first way for communication and encoded in a second way for storage).
Features of any aspect or embodiment described herein may, wherever appropriate, be applied to any other aspect or embodiment described herein. Where reference is made to different embodiments or sets of embodiments, it should be understood that these are not necessarily distinct but may overlap.
BRIEF DESCRIPTION OF THE DRAWINGS
Certain preferred embodiments of the invention will now be described, byway of example only, with reference to the accompanying drawings, in which:
Figure 1 is a schematic view of a computing system embodying the invention; and
Figure 2 is a sequence diagram of a 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 a 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 20 wishes to obtain some of the personal data from the first user. The second user 20 may be a natural person or may be a legal person, such as a business or government. The second user 20 uses an associated computing device or computing system (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 user device 10 and is stored in encrypted form in a distributed storage system 40. Subsequent access to this encrypted personal data (e.g. by the second user 20) is managed by a smart contract running on a blockchain 30.
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.
Prior to the flows depicted in Figure 1, the second user 20 has sent a licence agreement (an access request) to the first user’s device 10, e.g. via the internet or phone network, which indicates personal data that the second user wishes to access (i.e. which fields of data, such as “Name”, “Postal Address” etc.) and the purposes for which the second user 20 intends to use that personal data. The first user then reviews the license agreement on the user device 10 and either modifies it, rejects it, or accepts it. The licence agreement specifies at least a period of time during which the second user 20 is allowed access to the personal data — e.g. a week, a month or a year, or between a pair of specified dates, or from now until a specified future date.
The data fields specified in the license agreement may be a subset of the full set of personal data that the first user has entered into the first device 10. That is, the second user may only require some pieces of personal data and the license agreement may specify them accordingly.
The requested personal data on the user device 10 is encrypted using an encryption key 14 to form encrypted personal data 12 and is sent to the distributed storage 40. A copy of the accepted licence agreement is also stored on the distributed storage with a datum indicating the storage location of the encrypted personal data within the distributed storage 40.
A server 16 may optionally be used to distribute the encrypted personal data and the encryption key 14, as well as to set up the smart contract to be stored on the blockchain 30. The server 12 sends the encryption key 14 to the second user 20. The encryption key 14 (or, equivalently, a corresponding decryption key 14) may be sent in encrypted form to the second user 20. The server also passes the encrypted personal data 12 to the distributed storage 40. The server sets up a smart contract and stores this on the blockchain 30. Thereafter, the smart contract, in cooperation with the license agreement stored in the distributed storage 40, mediates access to the encrypted personal data 12 by the second user 20. Alternatively, in some such embodiments, there may be no server 16 and the user device 10 may instead perform the steps described hereinabove as being performed by the server 16.
When the second user 20 wishes to access the personal data, the second user 20 sends a request to the smart contract on the blockchain. The smart contract comprises executable code that is run on the blockchain. The smart contract checks whether the request meets predetermined access conditions. This may be done by the smart contract checking the terms set out in license agreement in the distributed storage 40. At least one of the access conditions that the smart contract checks is that the request from the second user 20 is within the predetermined period of time (i.e. the period also specified in the license agreement). The smart contract may also check a location from which the request comes (e.g. IP address), optionally along with other data, in order to confirm that it is indeed the second user 20 making the request and not a (malicious) third party. The access conditions may also relate to a transaction cost — e.g. granting access only if the second user 20 has sufficient money in a blockchain account to pay a required fee for the transaction.
When the access conditions are satisfied, the smart contract sends a release request to the distributed storage. The release request either causes the distributed storage to send the encrypted personal data 12 to the second user, or instructs the distributed storage to allow the second user 20 to download the encrypted personal data 12.
The second user 20 then decrypts the encrypted personal data 12 using the encryption key 14 (or using a private key corresponding to the public key used to encrypt the personal information stored on the distributed storage) and thereby gains access to the personal data.
The smart contract may be implemented as a "request process" that checks the license agreement on the distributed storage 40 to determine if the access request meets the access requirements. If the access requirements are met, then the location of the encrypted personal data 12 in the distributed storage 40 is passed to the smart contract. The location may be distributed to the second user has a hash. The hash may be public on the distributed storage but, in view of the encryption of the personal data, public knowledge of the hash does not make the personal data public. In this example, the smart contract only has access to the encrypted personal data upon successful evaluation, i.e. upon determining that the access conditions are met. The smart contract is public so the location of the encrypted personal data will be made available (visible) only after the access conditions have been approved. The personal data may be encrypted using a public key owned by the second user (having an associated private key).
Figure 2 shows a flow diagram of a method 100 for securely providing a first user’s personal data to a second user (which may be a natural or legal entity). The four main entities involved are the first user’s device 10, the second user’s computing system 20 (referred to as the second user 20 for convenience), a distributed blockchain computing system (referred to as blockchain 30 for convenience), and a distributed storage system 40. These entities may communicate over a network, e.g. the internet.
The first user device 10 may be a smartphone. The second user system 20 may be a corporate network or server. The blockchain 30 may be a public Ethereum blockchain. The distributed storage 40 may be a server farm distributed across multiple geographical locations within one country or across multiple countries.
At step 102, the first user enters personal data on his/her device 10 by filling in appropriate data fields. The completed data fields, which then make up the personal data, may include, for example, the first user’s name, postal address, date of birth, bank account details, billing address, medical history etc.
The second user 20 wishes to gain access to a portion of the first user’s personal data.
To do this, at step 104, the second user 20 sends a License Agreement to the user device 10 (i.e. to the first user). The License Agreement contains at least the following information:
The requested data fields; • The legal bases for processing the personal data;
• The purpose(s) for which the personal data may be used;
• The period of time during which the second user may access the personal data.
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 over-arching 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.
The device 10 obtains a public key from the second user 20 at step 106. This public key is one part of a public/private key pair. The operation of public key cryptography using public/private key pairs, such as RSA or elliptic-curve cryptography, is well- known in the field. In Figure 2, obtaining the public key is depicted as the second user 20 sending the public key to the device 10 (e.g. along with the license agreement). However, step 106 could alternatively involve the device 10 looking up the public key associated with the second user 20, e.g. on a webpage operated by the second user or a key server. At step 108, the first user accepts the license agreement on the device 10, e.g. by interacting with a graphical user interface. Alternatively, the user may modify the license agreement in some manner, e.g. to deselect the provision of personal data that the first user does not wish to share with the second user, before accepting it.
At step 110, the device 10 encrypts the requested personal data, i.e. encrypts the first user’s personal data corresponding to the requested data fields that were specified in the license agreement.. The device encrypts the requested personal data using an encryption key, Key1, that is generated by or has been stored on the device 10.
At step 112, the device 10 sends the encrypted personal data to the distributed storage 40 along with a copy of the licence agreement, which stores the encrypted data and license agreement for later retrieval.
At step 114, the device encrypts the encryption key (Key1) using the second user’s public key to produce an encrypted encryption key (eKeyl). In this case, Key1 is a symmetric key, e.g. an AES key, so the same key can both encrypt and decrypt. However, in other embodiments, the decryption key could be different from the encryption key, Key1, in which case the decryption key is encrypted to form eKeyl,
At step 116, the encrypted key (eKeyl) is sent to the second user 20. As the second user 20 has the corresponding private key of the public/private key pair, the second user 20 can now decrypt the encrypted encryption key (eKeyl) at any point. In Figure 2, the decryption of the encrypted key (eKeyl) is performed at step 128 (i.e. just before the key is required) but this order of steps is purely exemplary.
At step 118, the device 10 sends a smart contract to the blockchain 30. The smart contract contains at least the access conditions that must be met before access to the personal data is permitted. The smart contract may either contain a copy of the access conditions itself, or the smart contract may be configured to check the access conditions stored in the license agreement in the distributed storage 40.
The second user 20 then sends a request (at step 120) to the smart contract on the blockchain 30 to access the encrypted personal data (and license agreement) stored on the distributed storage 40. The smart contract checks that the access request meets the access conditions at step 122. For example, the smart contract checks the current date to see if the date is within the time period specified in the license agreement that was agreed to by the first user.
If the access conditions are met, then the smart contract sends an approval signal to the distributed storage, at step 124, to provide the encrypted personal data (and license agreement) to the second user 20. The encrypted personal data (and license agreement) are provided to the second user 20 at step 126.
The second user now has both the encrypted personal data and license agreement and the encryption key (possibly still in encrypted form, encrypted with the second user’s public key).
The second user then decrypts the encryption key at step 128, if not already done, and then, at step 130, uses the encryption key to decrypt the personal data.
The above-described process will now be described by way of a specific example in which the second user 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 20 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 device 10, i.e. performed step 102.
To complete the transaction, the online business sends a licence agreement to the first user (i.e. step 104) requesting access to the following data fields: name, postal address, bank account details, billing address. As mentioned above, the personal data 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 this example, the License Agreement may contain:
• "name", "postal address", "bank account details", "billing address", "telephone number".
• Contract (i.e. this License Agreement allows processing of the first user’s personal data so that a contract may be completed).
N.B. this 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)
• "Fulfilling an order", "taking payment", "marketing", and "customer support".
• "60 days" (N.B. this 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 device 10 then encrypts the requested personal data (name, postal address, bank account details etc.) using an encryption key and sends this to the distributed storage 40.
The device 10 then encrypts the encryption key and sends the encrypted encryption key to the online business (i.e. second user 20).
The device 10 also sends a smart contract to the blockchain 30 indicating the access conditions for accessing the personal data. The access conditions specify at least the time period of 60 days during which the online business may access the encrypted personal information. In this case, the access conditions also contain information for identifying the online business, so that the smart contract can check that the access request comes from the online business and not some other party. The online business sends an access request to the smart contract. The smart contract checks that the access conditions are indeed fulfilled by the access request. The smart contract then contacts the distributed storage which then sends the encrypted data to the online business.
The online business then decrypts the encrypted encryption key, using the private key of the public/private key pair, and then uses the encryption key to decrypt the personal data.
The online business then fulfils the order by taking payment using the customer’s bank details, and ships the item to the customer’s address.
The online business may then delete the personal information immediately or may store the personal information for the length of time specified in the license agreement. If the personal information is required again, within the time limit specified in the smart contract, the online business can re-request access (i.e. repeat steps 120 onwards in Figure 2) by contacting the smart contract and obtaining the information again.
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 user’s personal data is updated, say they change address, the device 10 may update the personal information in all of the user’s encrypted personal data sets stored on the blockchain. As the device 10 knows all of the encrypted personal data sets that it has sent to the blockchain, these may all be updated by only a single effort by the user, i.e. updating the address on their device 10.
• The user can decide to refuse further access to their data on the blockchain, e.g. by updating the access conditions on any/all of the user’s smart contracts on the blockchain 30. This gives users control over their own personal data.
• 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 co puter(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.
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

1. 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 user device; a computing system requesting access to at least a portion of the personal data stored on the user device by sending an access request to the user device over a network connection, wherein the access request specifies: one or more requested user data fields of the personal data, and a period of time during which the computing system may access the requested user data fields; the user device receiving an input from the first user indicating acceptance of the access request; after the access request is accepted by the first user, the user device sending an encrypted representation of the requested user data fields over a communication link to a remote server, encrypted using a first encryption key; the user device sending an encrypted copy of the first encryption key, or a corresponding decryption key, to the computing system, encrypted using a public key of a public/private key pair; the user device sending an instruction to a distributed blockchain computer system, instructing the distributed blockchain computer system to store a smart contract in a blockchain, wherein the smart contract comprises, or has access to, data representative of said period of time during which the computing system may access the requested user data fields; the computing system sending, at a time within said period of time, a request to the distributed blockchain computer system, requesting the distributed blockchain computer system to instruct the remote server to transmit the encrypted representation of the requested user data fields to the computing system; the computing system receiving the encrypted representation of the requested user data fields from the remote server; the computing system using a private key of the public/private key pair to decrypt the first encryption key or corresponding decryption key; and the computing system using the decrypted first encryption key, or corresponding decryption key, to decrypt the requested user data fields.
2. The method of claim 1 , wherein the access request further specifies a reason for accessing the requested data and/or a purpose for which the requested data may be used.
3. The method of claim 1 or 2, wherein the access request comprises a license agreement.
4. The method of any preceding claim, wherein the remote server 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.
5. The method of any preceding claim, further comprising the distributed blockchain computer system using the smart contract to verify that the time of the request from the computing system is within said period of time.
6. The method of any preceding claim, wherein the smart contract comprises, or has access to, data representative of a reason for accessing the requested data and/or a purpose for which the requested data may be used, and wherein the request from the computing system to the distributed blockchain computer system specifies a reason for the computing system to access the requested data or a purpose for which the data requested by the computing system will be used.
7. The method of claim 6, further comprising the distributed blockchain computer system using the smart contract to verify that the received data representative of a reason or a purpose satisfies the smart contract.
8. The method of any preceding claim, further comprising the first user modifying at least one of the requested user data fields, or a purpose for which the requested data may be used, in the access request received by the user device, wherein the input received from the first user then indicates acceptance of the modified access request.
9. The method of any preceding claim, further comprising: the first user using the user device to amend the personal data, including amending at least one of the one or more requested user data fields; and the user device encrypting and sending the amended one or more requested user data fields to the remote server.
10. The method of any preceding claim, further comprising the computing system deleting the received personal data.
11. The method of claim 10, wherein the computing system uses the decrypted personal data, and wherein the deleting occurs in response to the computing system finishing using the decrypted personal data or in response to the period of time specified by the access request elapsing.
12. The method of any preceding claim, wherein the step of the user device sending an encrypted representation of the requested user data fields comprises the user device sending an encrypted representation of the requested user data fields and a representation of the access request for storage by the remote server.
13. The method of any preceding claim, wherein the smart contract comprises an access log for recording each request for access to the requested user data fields, and for recording whether access was approved or not by the distributed blockchain computer system.
14. The method of claim 13, comprising the distributed blockchain computer system sending data representative of the access log to the user device.
15. The method of any preceding claim, wherein the first user is a natural person.
16. The method of any preceding claim, wherein the computing system is operated by a second user, and wherein the second user is a natural person or a legal person.
17. The method of any preceding claim, wherein the distributed blockchain computer system is a public distributed blockchain computer system accessible over the Internet.
18. A system for controlling access to personal data, the system comprising: an electronic user device; and a computing system, wherein the user device is configured: to receive, from a first user, personal data comprising one or more user data fields; to store the personal data in a memory of the user device; to receive an access request from the computing system over a network connection, requesting access to at least a portion of the personal data stored on the user device, wherein the access request specifies: one or more requested user data fields of the personal data, and a period of time during which the computing system may access the requested user data fields; to receive an input from the first user indicating acceptance or rejection of the access request; if the access request is accepted by the first user, to send an encrypted representation of the requested user data fields over a communication link to a remote server, encrypted using a first encryption key, and to send an encrypted copy of the first encryption key, or a corresponding decryption key, to the computing system, encrypted using a public key of a public/private key pair; and to send an instruction to a distributed blockchain computer system, instructing the distributed blockchain computer system to store a smart contract in a blockchain, wherein the smart contract comprises, or has access to, data representative of said period of time during which the computing system may access the requested user data fields, and wherein the second electronic device is configured: to send said access request to the user device; to send a request to the distributed blockchain computer system, requesting the distributed blockchain computer system to instruct the remote server to transmit the encrypted representation of the requested user data fields to the computing system; to receive the encrypted representation of the requested user data fields from the remote server; to use a private key of the public/private key pair to decrypt the first encryption key, or corresponding decryption key; and to use the decrypted first encryption key, or corresponding decryption key, to decrypt the requested user data fields.
19. The system of claim 18, further comprising at least one node of the distributed blockchain computer system, wherein the distributed blockchain computer system is configured to: receive the instruction from the user device to store the smart contract in the blockchain and, in response, to store the smart contract in the blockchain; and receive the request from the computing system to instruct the remote server to transmit the encrypted representation of the requested user data fields to the computing system and, in response, to send an instruction to the remote server to transmit the encrypted representation of the requested user data fields to the computing system.
20. The system of claim 18 or 19, wherein the distributed blockchain computer system is a public distributed blockchain computer system accessible over the Internet.
21. The system of any of claims 18 to 20, further comprising the remote server, wherein the server is configured to: receive the encrypted representation of the requested user data fields from the user device and to store the encrypted representation in a memory of the server; and receive an instruction from the distributed blockchain computer system to transmit the encrypted representation of the requested user data fields to the computing system and, in response, to transmit the encrypted representation to the computing system.
22. The system of claim 21 , wherein the remote server is configured not to transmit the encrypted representation of the requested user data fields to the computing system unless instructed to do so by the distributed blockchain computer system.
23. The system of claim 21 or 22, comprising a distributed data storage system, wherein the distributed data storage system comprises the remote server, and wherein the distributed data storage system is configured to store a plurality of instances of the encrypted representation of the requested user data fields distributed across a plurality of respective locations.
PCT/GB2020/052724 2020-02-12 2020-10-28 Methods and apparatus for controlling access to personal data WO2021160981A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB2001900.6A GB2592024A (en) 2020-02-12 2020-02-12 Methods and apparatus for controlling access to personal data
GB2001900.6 2020-02-12

Publications (1)

Publication Number Publication Date
WO2021160981A1 true WO2021160981A1 (en) 2021-08-19

Family

ID=69897229

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2020/052724 WO2021160981A1 (en) 2020-02-12 2020-10-28 Methods and apparatus for controlling access to personal data

Country Status (2)

Country Link
GB (1) GB2592024A (en)
WO (1) WO2021160981A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114880630A (en) * 2022-05-16 2022-08-09 北京百度网讯科技有限公司 Method and device for acquiring software use permission
CN115098251A (en) * 2022-06-16 2022-09-23 德德市界(深圳)科技有限公司 Method and system for multi-user and multi-batch computing and storage processing based on weight distribution

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4250145A1 (en) * 2022-03-25 2023-09-27 Amadeus S.A.S. Data management system and method

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180343114A1 (en) * 2015-11-24 2018-11-29 Adi BEN-ARI A system and method for blockchain smart contract data privacy
EP3422221A1 (en) * 2017-06-29 2019-01-02 Nokia Technologies Oy Electronic health data access control
EP3477891A1 (en) * 2017-10-26 2019-05-01 Gemalto Sa Methods for recording and sharing a digital identity of a user using distributed ledgers
US10474834B1 (en) * 2019-06-04 2019-11-12 Capital One Services, Llc Data sharing via distributed ledgers

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109120639B (en) * 2018-09-26 2021-03-16 众安信息技术服务有限公司 Data cloud storage encryption method and system based on block chain
CN109741803A (en) * 2019-01-14 2019-05-10 南京大学 Blockchain-based medical data security collaboration system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180343114A1 (en) * 2015-11-24 2018-11-29 Adi BEN-ARI A system and method for blockchain smart contract data privacy
EP3422221A1 (en) * 2017-06-29 2019-01-02 Nokia Technologies Oy Electronic health data access control
EP3477891A1 (en) * 2017-10-26 2019-05-01 Gemalto Sa Methods for recording and sharing a digital identity of a user using distributed ledgers
US10474834B1 (en) * 2019-06-04 2019-11-12 Capital One Services, Llc Data sharing via distributed ledgers

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114880630A (en) * 2022-05-16 2022-08-09 北京百度网讯科技有限公司 Method and device for acquiring software use permission
CN115098251A (en) * 2022-06-16 2022-09-23 德德市界(深圳)科技有限公司 Method and system for multi-user and multi-batch computing and storage processing based on weight distribution

Also Published As

Publication number Publication date
GB2592024A (en) 2021-08-18
GB202001900D0 (en) 2020-03-25

Similar Documents

Publication Publication Date Title
US11196569B2 (en) Systems and methods for accuracy and attestation of validity of data shared in a secure distributed environment
US20190362342A1 (en) Encryption and tokenization architectures
US7587366B2 (en) Secure information vault, exchange and processing system and method
CN109274652B (en) Identity information verification system, method and device and computer storage medium
US9419841B1 (en) Token-based secure data management
US9092494B1 (en) Information vault, data format conversion services system and method
JP2020528222A (en) Handling of transaction activities based on smart contracts in blockchain Caution Methods and devices for protecting data
US11841960B1 (en) Systems and processes for providing secure client controlled and managed exchange of data between parties
EP3867849B1 (en) Secure digital wallet processing system
CN117150581A (en) Secure identity and profile management system
EP3298532A1 (en) Encryption and decryption system and method
US20140150080A1 (en) Authorizing access to digital content
KR20070120125A (en) Online transaction authorization methods, systems and devices
CN110611657A (en) A method, device and system for file stream processing based on blockchain
WO2021160981A1 (en) Methods and apparatus for controlling access to personal data
US20230418979A1 (en) Data resolution using user domain names
WO2019175427A1 (en) Method, device and medium for protecting work based on blockchain
WO2019165091A1 (en) System and method for maintaining the security and confidentiality of consumer information
TW201947406A (en) Data exchange group system and a method thereof
CN110602075A (en) File stream processing method, device and system for encryption access control
CN110914826A (en) System and method for distributed data mapping
CN115017489B (en) Subject authority management method in bond issuance alliance chain and bond issuance alliance chain system
EP4521326A1 (en) Data management in a distributed system
US12432061B2 (en) Content protection system
CN114666119B (en) Data processing method, device, electronic equipment and medium

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20801362

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20801362

Country of ref document: EP

Kind code of ref document: A1