WO2019229257A1 - Système et procédé de fourniture à un tiers autorisé d'un accès, avec la mise en dépôt de clé sécurisée sur un grand livre, à un secret - Google Patents

Système et procédé de fourniture à un tiers autorisé d'un accès, avec la mise en dépôt de clé sécurisée sur un grand livre, à un secret Download PDF

Info

Publication number
WO2019229257A1
WO2019229257A1 PCT/EP2019/064227 EP2019064227W WO2019229257A1 WO 2019229257 A1 WO2019229257 A1 WO 2019229257A1 EP 2019064227 W EP2019064227 W EP 2019064227W WO 2019229257 A1 WO2019229257 A1 WO 2019229257A1
Authority
WO
WIPO (PCT)
Prior art keywords
secret
validation
party
party system
key
Prior art date
Application number
PCT/EP2019/064227
Other languages
English (en)
Inventor
Roland TEGEDER
Richard Sharp
Original Assignee
Tegeder Roland
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
Priority claimed from US15/996,336 external-priority patent/US20190372765A1/en
Priority claimed from EP18175515.8A external-priority patent/EP3576000B1/fr
Application filed by Tegeder Roland filed Critical Tegeder Roland
Priority to CN201980050667.3A priority Critical patent/CN112673591B/zh
Priority to SG11202011475RA priority patent/SG11202011475RA/en
Publication of WO2019229257A1 publication Critical patent/WO2019229257A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • 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/085—Secret sharing or secret splitting, e.g. threshold schemes
    • 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

Definitions

  • encryption Since at least Ancient Egyptian times, encryption has been used to enable secret communication between parties, and it is now widely used to protect information and control access to data of all kinds, whether such data are held by a single party or transmitted between parties.
  • encryption can be used to secure data held on a hard disk such that only a party with knowledge of the encryption key can access the data, or to secure messages that are transmitted over the internet between two parties such that a third party, without access to the encryption key, cannot learn the contents of the messages even if they have access to the data that were transmitted between the parties.
  • a key escrow system is a system in which the keys that are required to decrypt some encrypted data are held in escrow so that an authorised or designated third party may gain access to those keys under certain conditions. Verifying that any such conditions are met poses several problems.
  • Existing key escrow systems rely on the correct functioning of some social linkage, such as a court order together with its verification and technical enforcement, or a connected individual or institutional body charged with controlling access to the key. As such, these systems still require an element of socially or institutionally founded trust in order to function correctly.
  • the limitations and drawbacks of existing key escrow mechanisms are described in more detail in“ The risks of key recovery, key escrow, and trusted third-party encryption” Hal Abelson et al. (1997), World Wide Web J. 2, 3 (June 1997), 241 -257.
  • a system for providing access to a designated third party system to a secret comprises a plurality of trustee systems, and each trustee system is configured to receive a secret share of the secret from a first party system and store the secret share. Either the secret or the secret share is encrypted such that only a designated third party system can access the secret.
  • Each trustee system is also configured to monitor published requests for the secret shares, validate that a given request for the secret shares was made by the designated third party system and, if the validation is successful, publish the secret share in response to the validated request for the secret shares.
  • Each published request for the secret shares may comprise a validation token and an encrypted validation token
  • each trustee system may be further configured to receive a second key of a validation key pair from the first party system along with the secret share and store the second key of the validation key pair, validate that the request for the secret shares was made by the designated third party system by decrypting the encrypted validation token using the second key of the validation key pair and comparing the decrypted validation token with the validation token and, if the validation token of the validation message matches the decrypted validation token, publish the associated secret share.
  • each request for the secret shares may comprise an encrypted validation token
  • each trustee system may be further configured to receive a second key of a validation key pair from the first party system along with the secret share and store the second key of the validation key pair, receive a validation token from the first party system and store the validation token, and validate that the request for the secret shares was made by the designated third party system by decrypting the encrypted validation token using the second key of the validation key pair and comparing the decrypted validation token with the validation token that was received from the first party system.
  • Each secret share may also pertain to a share of an identifier associated with the third party system such that the identifier can be derived from the secret shares.
  • each trustee system may be further configured to receive an identifier associated with the third party system from the first party system along with the secret share and publish the identifier associated with the third party system along with the secret share.
  • the system may further comprise the first party system, and the first party system may be configured to encrypt the secret, generate the secret shares of the encrypted secret, and transmit the secret shares to the plurality of trustee systems.
  • the first party system may be configured to generate the secret shares of the secret, encrypt the secret shares, and transmit the encrypted secret shares to the plurality of trustee systems.
  • the first party system may be configured to encrypt the secret or secret shares using a public encryption key associated with the third party system, or the first party system may be configured to encrypt the secret or secret shares using the second validation key of the validation key pair, such that the key required to decrypt the encrypted secret or encrypted secret shares is the first validation key of the validation key pair.
  • the secret itself may be a second object key of an object key pair
  • the first party system may be further configured to encrypt data using the first object key of the object key pair, and transmit the encrypted data to the third party system.
  • the first party system may be further configured to generate a validation token, transmit the validation token to the plurality of trustee systems and transmit the validation token to the third party system.
  • the first party system may be further configured to select the plurality of trustee systems from a group of available trustee systems, such that the plurality of trustee systems is a subset of the larger group of available trustee systems.
  • the first party system may be further configured to analyse a request for secret shares by decrypting the encrypted validation token using the second key of the validation key pair and comparing the decrypted validation token with the validation token of the validation message and, if the validation token of the validation message matches the decrypted validation token, determine that the request for the secret shares was published by the designated third party system.
  • the first party system may be further configured to analyse the request for secret shares by decrypting the encrypted validation token using the second key of the validation key pair and comparing the decrypted validation token with the shared validation token held by the first party system. If the validation token held by the first party system matches the decrypted validation token, the first party determines that the request for the secret shares was published by the designated third party system.
  • the system may further comprise a third party system, which is configured to publish the request for the secret shares, monitor the plurality of published secret shares, validate the secret shares published by the plurality of trustee systems in response to the request for the secret shares, reassemble the encrypted secret from the published secret shares, and decrypt the encrypted secret.
  • a third party system which is configured to publish the request for the secret shares, monitor the plurality of published secret shares, validate the secret shares published by the plurality of trustee systems in response to the request for the secret shares, reassemble the encrypted secret from the published secret shares, and decrypt the encrypted secret.
  • the third party system may be configured to publish the request for the secret shares, monitor the plurality of published secret shares, validate the secret shares published by the plurality of trustee systems in response to the request for the secret shares, decrypt the encrypted secret shares from the published secret shares, and reassemble the secret from the decrypted secret shares.
  • the third party system may be further configured to decrypt the encrypted secret or secret shares using the private key of the key pair associated with the third party system or, when the secret is encrypted with second key of the validation key pair, decrypt the encrypted secret or secret shares with the first validation key of the validation key pair.
  • the third party system is further configured to receive the encrypted data from the first party system, and decrypt the encrypted data using the decrypted second object key of the object key pair.
  • the third party system may be further configured to validate the secret shares published in response to the request for the secret shares by comparing the decrypted second validation token published with the secret shares to a local copy of the second validation token, such that when the decrypted second validation token matches the local copy of the second validation token, the third party system retrieves the associated secret share.
  • Each trustee system may be further configured to generate a second validation token, encrypt the second validation token using the second validation key of the validation key pair to generate an encrypted second validation token, and publish the second validation token and the encrypted second validation token with the secret share.
  • the third party system is further configured to validate the secret shares published in response to the request for the secret shares by decrypting the encrypted second validation token using the first validation key of the validation key pair, comparing the decrypted second validation token with the second validation token and retrieving the associated secret share when the decrypted second validation token matches the second validation token.
  • a method for giving to a designated third party system access to a secret comprises receiving, at a trustee system, a secret share of the secret from a first party system and storing the secret share, wherein the secret or the secret share is encrypted such that only a designated third party system can access the secret, monitoring published requests for the secret shares, validating that a request for the secret shares was made by the designated third party system, and if the validation is successful, publishing the secret share in response to the validated request for the secret shares.
  • the method may also include steps corresponding to all of the claimed features of the trustee, first party and third party systems set out above.
  • a computer-readable medium comprises instructions which, when executed by a computer, cause the computer to carry out the method described above.
  • FIG. 1 is a high-level depiction of the system of the present invention.
  • FIG. 2 shows a flow diagram depicting a method in accordance with the present invention.
  • FIG. 3 depicts the overall system and method of the present invention in more detail.
  • the system and method of the present invention enable a first party to provide overt ledger secured key escrow (“OLSKE”) access to a secret p, controlled by the first party, to a designated third party.
  • OLSKE overt ledger secured key escrow
  • “overt ledger secured key escrow access” means that access to the secret p is provided such that apart from the first party only the designated third party can access the secret p, and such that the designated third party’s access is necessarily visible to the first party, i.e. that the third party’s access to the secret p is necessarily overtly recorded with the effect that the first party, at least, is able to determine that the third party has accessed the secret p.
  • the term“designated third party” or“designated third party system” means that the third party or the third party system has overtly recorded access to the encryption keys required to successfully request and obtain access to the secret p.
  • Figure 1 shows an overall depiction of the system 100 of the present invention, which is capable of providing this OLSKE access to an encrypted secret to a third party that has been designated for such access by the first party, i.e. the original owner/creator/controller of the secret p.
  • Figure 3 also shows an overall depiction of the system 100, in more detail, and in accordance with a preferred embodiment of the invention.
  • the notation AvB indicates that either A or B may be used
  • the notation C indicates that feature C (and elements that C operates on) is optional.
  • the secret p is encrypted using a first key y of an asymmetric key pair, y, y * , referred to as the object key pair.
  • the second key y * of the object key pair y, y * can be used to decrypt the encrypted secret y(p) in order to reveal the secret p.
  • Secret p may be, for example, a password, encryption key, or indeed any other data that the first party wishes to keep secret.
  • the secret p is an encryption key or password
  • the secret p may be used to encrypt or otherwise control access to further data, such as a user account for an online service for accessing an electronic device such as a personal computer.
  • the process set out herein may be automatically repeated whenever the secret p changes, for example if p is a password or encryption key used to access an account or some other data, in order to maintain the ability of the designated third party to access the data if necessary.
  • the first party may either use the system voluntarily and for personal reasons, or may be required to do so by law, by the configuration of a device/software, or by terms and conditions of the use of a service, for example.
  • the system 100 includes a plurality of trustee systems 102, each of which may be a server or other general purpose computer system, a virtual machine, or any other hardware or software element capable of performing the functions described herein.
  • Some or all of the trustee systems 102a-d comprise a memory in which a secret share s ⁇ , pertaining to the second object key y * , which can be used to decrypt the secret p, is stored.
  • the secret s can be recovered from the secret shares s, by combining a minimum number k of the secret shares s,, where k £ n.
  • the secret s cannot be recovered from fewer than k secret shares s,. Examples of secret sharing schemes can be found in“Secret sharing scheme realizing general access structure’’, Ito, M., Saito, A. and Nishizeki, T. (1989), Electron. Comm. Jpn. Pt. Ill, 72: 56-64, and “How to share a secret', Shamir, A. (1979) Communication of the ACM, 22, pp. 612-613.
  • the secret s that is split into the secret shares s includes at least the second object key y * , or an encrypted version of the second object key y * , as described in more detail below.
  • the secret shares s may also include further data relating to the second object key y * , such as an identifier associated with the third party, also described in more detail below.
  • Each trustee system 102a-d monitors a ledger 104 for request messages 1 13 that indicate a request for access to the second object key y * .
  • the system 100 may be used by more than one first party and more than one third party to provide OLSKE access to different secrets, and that each trustee system 102a-d may hold multiple secret shares, each pertaining to a share of a different object key corresponding to different secrets.
  • each trustee system 102a-d attempts to validate the request messages published to the ledger in order to find request messages that are relevant to the secret shares that the trustee system 102a-d holds. If the validation is successful, the trustee system 102a-d publishes a response message 1 14 that includes its secret share s,.
  • the response messages 1 14 may be published to the same ledger 104 to which the request message 1 13 was published. Alternatively, the response messages 1 14 may be published to a different ledger.
  • the k published secret shares s can be combined so that the party which filed the request message 1 13 gains access to the second object key y * .
  • the second object key y * may therefore be encrypted using a public key o3 ⁇ 4r* that is associated with the third party.
  • the second object key y * may be encrypted with the second validation key b * of the validation key pair b, b * (described in more detail below) by the first party system 101 before the encrypted second object key, i.e. b * ⁇ g * ), is split into the secret shares s, and the secret shares s, and second validation key b * are transmitted to the trustee system 102.
  • the trustee systems are unable to access the second object key y * in the event of collusion since they do not hold the first validation key b that is required to decrypt either the second object key y * , as the case may be.
  • the secret shares s may be encrypted using either the third party’s public key o3 ⁇ 4r* or the second validation key b * .
  • the designated third party would be able to reassemble the secret shares s, to reveal the second object key y * since they must be decrypted using either the third party’s public key o3 ⁇ 4r or the first validation key b first.
  • each secret share s, of p will also be large in many secret sharing schemes. Indeed, in a k, n secret sharing scheme, each of the n secret shares s, is generally at least the size of the secret p itself.
  • the size of each secret share s ⁇ , and thus the amount of storage space occupied by the secrets shares in the memory of the trustee systems is reduced.
  • the use of the object key pair y, y * also offers a layer of protection against collusion by the trustee systems in case the third party’s private key or 3 p is compromised.
  • collusion amongst the trustee systems may reveal the second object key y * , but since the trustee systems do not also have access to the encrypted secret y ⁇ p), the secret p remains secure.
  • new object keys y, y * are generated for each secret p, even if a given object key pair y, y* is compromised, only the associated secret p is affected.
  • FIG. 1 Also depicted in Figure 1 is a first party system 101 and a third party system 103 that is designated by a first party to be provided with OLSKE access to the secret p.
  • the function of the first party system and third party system is explained in more detail below with respect to Figures 2 and 3, which show a flow chart of a method 200 in accordance with the present invention and an overall system diagram 300 in accordance with the present invention respectively.
  • Figures 2 and 3 show a flow chart of a method 200 in accordance with the present invention and an overall system diagram 300 in accordance with the present invention respectively.
  • the core of the present invention is provided by the trustee systems 102.
  • These features of the first party system 101 and third party system 103 are therefore exemplary and need not be implemented in order for the system and method of the invention to function.
  • the first party system 101 At step 201 of the method 200 shown in Figure 2, the first party system 101 generates two pairs of asymmetric encryption keys: the object key pair y, y* and a validation key pair b, b*.
  • the first party system 101 may be a personal computer, laptop, tablet, or indeed any other electronic device capable of carrying out the functions set out below.
  • the first party system encrypts the secret p using the first object key y of the object key pair to generate the encrypted secret y(p). Controlling access to the secret p via the object key pair y, y * has numerous advantages; however, as explained above, the present system also functions when the secret p is directly split into the secret shares s,.
  • the first party system 101 securely sends a message 1 1 1 to the third party system 103.
  • the message includes a first validation key b of the validation key pair b, b * and the encrypted secret y(p).
  • the third party system 103 stores this message 1 1 1 securely for future use.
  • the third party system 103 does not have access to the first party’s secret p since it remains encrypted by the first object key y.
  • the secret p itself is split into the secret shares s,, rather than the second object key y * , it will be appreciated that the secret p should not form part of the message 1 1 1 that is transmitted to the third party.
  • the message 1 1 1 that is transmitted to the third party may further include an indication of the secret sharing scheme that has been used by the first party to generate the secret shares s, that are transmitted to the trustee systems, along with any other relevant meta-information.
  • a particular secret sharing scheme may be mandated by the system or method itself.
  • the message 1 1 1 may also comprise an identifier associated with the first party such that the third party is able to determine the identity of the first party from the message.
  • the message 1 1 1 may be sent over a communication channel to the third party that necessarily identifies the first party to the third party, or may be posted to the ledger 104, which is described in more detail below.
  • the message 1 1 1 is transmitted over a secure communication channel, e.g. in order to ensure that the message 1 1 1 is not tampered with in transit, and to ensure that only the designated third party (and the first party) has access to the first validation key b. This ensures that other than the first party system 101 itself only the third party system 103 can create a valid request message 1 13 for the secret shares s, as described in more detail below.
  • the message 1 1 1 may also contain data that have been encrypted according to the secret p, an indication of where an account can be accessed using secret p, and/or any other indication of where further data secured by secret p can be obtained.
  • the ability to add meta-information about the secret p is not limited to the case where p corresponds to a password or an encryption key.
  • the first party may wish to have the third party understand that the secret relates to business accounts of one business and not another etc.
  • the first party system 101 generates a plurality of secret shares s, in a k, n secret sharing scheme, as described above with respect to Figure 1 , such that each secret share s ⁇ , includes an element of the second object key y * , i.e. the key that can be used to decrypt the encrypted secret y(p).
  • the second object key y * may be encrypted using the third party’s public key, or 3p * , or the second validation key b * , which is provided to the trustee system before being split into the secret shares s, by the first party system 101 .
  • the secret shares s themselves can be encrypted, using the second validation key b * or the third party’s public key or 3p * , as explained above.
  • the third party’s public key a 3p * is used to encrypt either the second object key y * or the secret shares s
  • the third party’s private key or 3p which can be used to decrypt the second object key y * or the secret shares s, is held securely by the third party system 103. This ensures that only the third party can access the second object key y * from the reassembled secret shares s,.
  • the secret shares s may also include an identifier associated with the third party, such as a hash of the third party’s public key #(or 3 P * ), which can be used to identify the third party from the reassembled secret shares s,.
  • the third party’s public key or 3p * and/or a hash of the public key #(or 3 p * ) may be publicly associated with the third party, for example via a key server, in order to identify the third party. In this way, the third party is held publicly accountable for their requests for OLSKE access.
  • the first party 101 chooses n trustee systems 102a, 102c, 102d from among the available trustee systems 102 to hold a single secret share s ⁇ , each.
  • the n trustee systems chosen by the first party may be selected randomly, or deliberately chosen for any reason, such as for financial reasons (e.g. lower charges for providing the trustee service) or legal reasons (e.g. mandated by governments or differences in local data protection legislation).
  • the first party system 101 securely transmits a message (b * , s ⁇ ,) 1 12 including the second validation key b * , which is the counterpart of the first validation key b transmitted to the third party, and one of the secret shares s, to each of the n selected trustee systems 102a, 102c, 102d.
  • each of the trustee systems 102a, 102c, 102d securely stores the message ⁇ b * , s,) as a record for later use, for example in a database.
  • the messages (/3 * , s,) 1 12 are transmitted over a secure communication channel by the first party system
  • steps 202/203 and 204/205 are carried out is not important, since it is unlikely that the third party will immediately request access to the second object key y * after receiving the message 1 1 1 from the first party system 101.
  • the third party system 103 When the third party wishes to gain access to second object key y * in order to access the secret p, the third party system 103 creates a request message 1 13, as described above.
  • the request message 1 13 includes an arbitrary token T and b(T), a copy of the same token T that has been encrypted using the first validation key b of the validation key pair b, b * that is securely held by the third party system 103.
  • a copy of the second validation key b * is held by each of the trustee systems 102a, 102c, 102d that were selected by the first party to hold the secret shares s,.
  • Request messages 1 13 are published to a ledger 104a, which is at least accessible by the trustee systems 102 and the first party system 101.
  • each trustee system 102 monitors the ledger 104a on an ongoing basis for request messages 1 13 that correspond to secret shares s held by the trustee system.
  • the third party system 103 publishes the request message 1 13 to a ledger 104a, which is at least accessible by the trustee systems 102 and the first party system 101 .
  • each trustee system 102 may maintain a large number of records, each comprising a different validation key and secret share that has been transmitted to the trustee system 102 from various first parties.
  • each trustee system attempts to validate the request messages published to the ledger in order to determine whether each request published to the ledger 104a is a request for a secret share that the given trustee system 102 holds.
  • the trustee system 102 attempts to decrypt the encrypted token b(T) of the request message using the validation key held in that record, i.e. performing the operation jS * (/3(T)).
  • the output of the operation b * (b(T)) is then compared with the unencrypted token T of the request message. If the second validation key b * held in the given record is the counterpart of the first validation key b that was used by the third party to encrypt the token T when generating the request message 1 13, then the decrypted token b * (b(T)) will be identical to the unencrypted token T of the request message. In this way, each trustee system 102 is able to determine whether a record that it holds is associated with the request published to the ledger 104a by the third party system 103.
  • the trustee system 102 moves onto and tests the validation key of the next record against the encrypted and unencrypted tokens provided in the request message. If the decrypted token does match the unencrypted token, i.e. the message is validated at step 208 of the method 200, the trustee system 102 publishes the secret share s ⁇ , held in the relevant record matching the request message 1 13 at step 210 of the method 200.
  • the validation process employed by the trustee systems 102 may be employed by the first party system 101 in order to determine that the third party system 103 is attempting to access the second object key y * and thus the secret p.
  • the first party may retain a record of the association of the validation key pair b, b * with the third party.
  • the first party system 101 can determine that a request was published by the third party system 103 to which it sent the first validation key b.
  • the third party system 103 After publishing anonymously the request message 1 13 at step 207 to the ledger 104a, the third party system 103 monitors the ledger 104b for a response message 1 14 at step 209. The third party system uses validation means contained in the response messages 1 14 to determine whether each response message 1 14 is associated with the request message 1 13, as described below.
  • a trustee system 102 determines a match between a request message 1 13 and record held by that trustee system, as described above, the trustee system publishes a response message 1 14, which includes the secret share s,, to a ledger 104b. If the secret shares , were not encrypted using the second validation key b * by the first party system 101 prior to providing the secret shares to the trustee systems 102, then the secret share s ⁇ , that is published in the response message 1 14 may be further encrypted by the trustee system using the second validation key b * that is held by the trustee system 102. In this way, only the third party is able to decrypt the secret shares s, in order to reveal the (encrypted) second object key y * .
  • the ledger 104b to which the response message 1 14 is published may be the same ledger as the ledger 104a to which the request message 1 13 was posted. Alternatively, the ledger 104b to which the response message 1 14 is published may be a different ledger, as long as the ledger 104b is accessible to the third party system 103 - in order to retrieve the secret shares s, - and accessible to the first party system 101 - in order to determine that the secret shares s, have been published.
  • the trustee system 102 may also notify the first party system 101 , if the identity of the first party is known to the trustee systems 102.
  • the trustee systems 102 cannot know the identity of the third party, even if the trustee systems 102 know the secret sharing scheme that has been used, since the third party’s identifier #(o3 ⁇ 4r * ) may also be part of the secret shares s,. Indeed, by validating the request messages using the validation key pair b, b * , the trustee systems 102 are able to identify and validate the messages posted to the ledger without requiring knowledge of the third party’s true identity. This prevents the trustee systems 102 from discriminating against a third party, for any reason, and ensures consistent processing of each of the request messages and records.
  • the trustee systems 102 may indeed be aware of the identity of the third party, or may at least be aware of a public key or 3p * , or a hash of it #(or 3 p * ), associated with the third party.
  • the first party system 101 may transmit the whole public key associated with the third party, or a hash thereof, to the trustee systems 102 as part of or along with message 1 12.
  • each trustee system 102 may also publish the whole public key or other identifier associated with the third party.
  • the response message 1 14 posted by each trustee system comprises at least the secret share s ⁇ , held by the trustee system and the validation means that enables the third party system 103 to identify and validate response messages 1 14 that are associated with the third party system’s 103 request message 1 13.
  • the validation means may also include an encrypted version of the secret share b * (s ⁇ i ), or an encrypted hash of the secret share b * (#(s ⁇ ,)).
  • the third party system 103 both determines that the response message 1 14 is associated with its request message 1 13 and validates that the trustee system 102 holds the second validation key b * by comparing the result of the operation b(b * (s ⁇ ,)) with the secret share s,, or the operation b(b * (#(s ⁇ ,))) with a hash of the secret share #(s,).
  • the third party can be sure that the trustee system 102 that published the response message 1 14 holds the second validation key b * that is the counterpart of the first validation key b held by the third party system 103, and that the response message 1 14 was legitimately published in response to the third party system’s request message 1 13.
  • the specific hash function e.g. MD5 or SHA-1/2/3, is therefore pre- agreed, e.g. as part of the protocol specification, or alternatively may be specified in the response message.
  • the response message 1 14 may instead comprise a second arbitrary token V and an encrypted version of the second token /3*(V). These are then used by the third party system 103 to validate the response message by comparing the result of the operation /3(/3*(V)) with the unencrypted token V, in a similar manner to the token T and encrypted token b(T) discussed above with respect to validation of the request message 1 13.
  • the token V used by a given trustee system 102 in its response message is a unique token, i.e. different to other tokens V used by other trustee systems 102 in their response messages.
  • the token V could be a hash of a public key associated with the individual trustee system 102, i.e. # ⁇ a s * ) ⁇
  • the present system and method prevent spoofing of response messages by trustee systems 102, or other actors with access to the ledger, who do not have access to the second validation key b * .
  • both tokens T and V used to validate the request and response messages respectively, may be replaced by a single token W that is generated by the first party system 101 and transmitted securely to the third party system 103 along with the encrypted secret p and first validation key b, and transmitted securely to the selected trustee system 102 along with the secret shares and the second validation key b * .
  • Each trustee system 102 is then configured to compare the token W received in the request message 1 13 with its own copy of the token W in order to determine that the request message 1 13 corresponds to the secret share that the trustee system holds.
  • the validation keys b, b * are used in the same manner as described above to validate the request, i.e.
  • the third party system 103 is then configured to compare the token W in the response message 1 14 with its own copy of the token W in order to determine that the response message 1 14 corresponds to its request.
  • the third party system can be configured to restrict the validation means of the request message 1 13 to comprise only the encrypted token b( ⁇ N), using the first validation key b, rather than including the unencrypted token W too.
  • Each trustee system is then configured to compare the decryption of such encrypted token, using the second validation key b * , to the token W stored securely in its memory and in this way determine that the request message 1 13 corresponds to the secret share that the trustee systems holds and at the same time validate that the request message 1 13 had been posted by the designated first party.
  • the request message 1 13 published by the third party system 103 may also include an identifier that is to be published with each response message 1 14 in order for other parties to determine which response messages are related and hence which of the published secret shares s, are related.
  • the request message and 1 13 and related response messages 1 14 may be identifiable through the layout configuration of the ledger, e.g. by forcing the messages to be bundled together on the ledger. In this way, any interested party with access to the ledger 104b can re-assemble the published secret shares s,, assuming that the secret sharing scheme is generally known, to reveal the identity of the third party #(a3p) without requiring access to the validation keys b, b * .
  • the ledger 104b is publicly accessible, this arrangement makes the actions of the third party publicly accountable.
  • the identity of the requesting third party may be revealed, i.e. not as part of the secret share s,, with every response message 1 14, for example by including the third party’s identity hash within the response message 1 14. Doing so, however, would allow trustee systems to discriminate against request messages to process based on the requesting party. While this is generally not preferable, it may be advantageous in scenarios where complete transparency is required.
  • each trustee system may optionally mark the record comprising the published secret share s ⁇ , as closed, or may even delete the record. This reduces the computational burden on the trustee systems 102 of validating future request messages 1 13 since old records that have already been published will be excluded from the validation process set out above.
  • steps 206, 208 and 210, as well as the additional functions of the trustee systems described above, will generally be carried out individually by each of the trustee systems.
  • the third party system 103 reassembles the secret shares s, to reveal the encrypted second object key, i.e. a 3R * (k * ) or b * ⁇ g * ). If the second object key y * was encrypted using the third party’s public key a 3P * , the third party system 103 uses its private key Gf3 P to obtain the second object key y * after obtaining the encrypted second object key a 3r * (k * ) from the published secret shares s, of the response messages.
  • the third party system 103 uses the first validation key b to decrypt the second object key y * or the secret shares s, at the appropriate time.
  • the third party system 103 uses the revealed second object key y * to decrypt the encrypted secret (p), which it previously received from the first party system 101.
  • the third party may close the original request message 1 13 or post a further message to the ledger 104a/104b to indicate that the request message 1 13 is closed.
  • the trustee systems 102 know not to attempt to validate the closed request message in future, thereby reducing the computational burden of the validation process.
  • the system can mandate that response messages 1 14 needs to be posted within a set time period or within a particular number of ‘blocks’ on the ledger. If the time period expires with an insufficient number of published responses, i.e. fewer than k out of n, the third party will need to publish a further request message 1 13. In this manner, there is an incentive for responses to published in a timely manner, since any given trustee system can determine that other trustee systems (but fewer than k) have published responses to the request and may therefore post their secret share s ⁇ , within the time limit in order to avoid wasted work or financial disincentives.
  • the ledger(s) 104a, 104b can be checked at any time by the first party system 101 , or indeed may be monitored continuously by the first party system 101 .
  • the first party system can use the validation key pair b, b* to verify the legitimacy of any published request messages 1 13 for OLSKE access.
  • any trustee system 102 may inform or notify the first party system 101 of request messages 1 13 once they have been validated using the second validation key b * held by the trustee system 102.
  • the first party system 101 Since the first party system 101 retains the association between the validation key pair b, b* and the identity of the third party to whom the first party has provided OLSKE access, the first party can deduce the identity of the third party from the request message 1 13, assuming the request message 1 13 is valid.
  • the first party system 101 may also publish a request message to the ledger 104a in order to obtain the second object key y* as long as the first party system
  • the first party system 101 retains the first validation key b after transmitting it to the third party system 103. In this manner, the first party system 101 may be able to recover access to the secret p in the event that its original copy of p was lost. If the secret p itself is encrypted and split into the secret shares s, that were transmitted to the trustee systems 102, the first party system 101 need only retain the first validation key b in order to recover the secret. If the second object key y * is encrypted and split into the secret shares s then the first party system 101 must also retain a copy of the encrypted secret y(p). Thus, the present system may also function as a recovery mechanism for passwords or other secrets p. Indeed, when the system is used as such, the third party system 103 need not be present.
  • the secret p is either encrypted using a public key CHP* associated with the first party, or directly split into secret shares which are encrypted using the public key CHP* associated with the first party.
  • the secret shares are then transmitted securely to the trustee systems, along with a token Y.
  • the trustee systems may either receive a copy of the first party’s public key aip * , or the public key crip * may be retrieved from a key server for storage with the secret share.
  • the first party wishes to recover the secret p, the first party publishes a request message to ledger comprising the encrypted version of the token a-ip(Y), which was encrypted with the first party’s private key.
  • the validation method outlined above may then be performed with the necessary changes to use the first party’s public key a-ir * rather than the second validation key b * .
  • the first party can retrieve the secret shares published in response to the request message and decrypt the secret or secret shares using their private key a-ir.
  • This arrangement, using the first party’s public and private keys, means that the first party needs only to retain access to their private key CHP in order to recover the secret.
  • the first party system 101 sends messages to each of the trustee systems
  • the trustee systems 102 instructing the trustee systems 102 to delete the secret shares s, that they each hold. If the first party system 101 were also to concurrently send a delete message to the third party system 103, the third party may attempt to immediately retrieve the second object key y * from the trustee systems 102. If, for any reason, the third party’s request were processed before the first party’s delete message, then the third party may be able to gain unauthorised (albeit still overt) access to the second object key y * . Thus, the trustee systems 102 may transmit a confirmation message to the first party system 101 to indicate that the secret shares s, have been deleted. Once n - k + 1 confirmations have been received by the first party 101 from the trustee systems 102, i.e.
  • the first party system 101 may also forward the delete message to the third party system.
  • the secret p is a password or key for accessing further data
  • the first party may simply change p in order to prevent the third party from accessing the further data.
  • a computational or financial burden may be imposed upon the posting of a message to the ledger.
  • a trustee system 102 or third party 103 may be required to calculate a hash of existing messages in a block, for example in a blockchain.
  • An example of a blockchain is described in“Bitcoin: A Peer-to-Peer Electronic Cash System", S. Nakamoto ⁇ https://bitcoin.org/bitcoin.pdf> or in“A Next Generation Smart Contract & Decentralized Application Platform", V.
  • Buterin ⁇ http://www.the-blockchain.com/docs/Ethereum_white _paper-a_next_generation_smart_contract_and_decentralized_application_platform- vitalik-buterin.pdf>.
  • distributed ledgers may be used, for example a consensus ledger, as described in “ The Ripple Protocol Consensus Algorithm ", D. Schwartz, N. Youngs, A. Britto, ⁇ https://prod.coss.io/documents/ white-papers/ripple. pdf>, a directed acyclic graph, as described in “The Tangle”, S. Popov, ⁇ https://iota.org/IOTA_Whitepaper.pdf>.
  • the first party In order for OLSKE access to function effectively, the first party much be sufficiently confident that that the third party - or indeed anyone else - cannot gain access to the secret p unless the third party requests such access in a manner that is knowable to the first party as a matter of public record. If the second object key y * were entrusted to a single trustee system, it would be relatively straightforward for the third party to put undue private pressure on the operator of the trustee system to reveal the second object key y * surreptitiously, i.e. without the first party’s knowledge. Indeed, this is a general problem with cryptographic protocols which rely on trusted parties to provide security, such as certificate authorities that issue digital certificates for use in HTTP Secure.
  • the third party would have to identify and then successfully pressure the operators of at least k out of the n chosen trustee systems 102a, 102b, 102c in order to obtain the second object key y * without the first party’s knowledge.
  • the decentralised system described herein therefore forces the third party to use the ledger system 104a, 104b in order to gain access to the second object key y * in a way which enables the first party to know if and when access to the second object key y * has been requested. Furthermore, using a secret sharing scheme to securely decentralise the storage of the second object key y * avoids the creation of obvious honeypots for malicious third parties to attack in an attempt to gain access to the object keys that centralised storage of the object keys would entail.
  • an asterisk * has been used to denote the one key out of a pair of complementary asymmetric encryption keys. While the keys referred to as“public” keys in the present disclosure have been presented with an asterisk, it should be noted that a key denoted by an asterisk is not necessarily published or otherwise publicly available, as the term“public key” would usually connote, and may indeed be held securely and in secret by any parties that hold or receive the key unless otherwise stated.
  • the object key pair y, y * and the validation key pair /3, b * are not used in the conventional public/private manner that is generally associated with asymmetric encryption keys, but are instead provided by the first party system 101 to the trustee systems 102 and third party 103 to control access to the secret p and to allow the trustee systems 102 and third party 103 to validate messages published by each other.
  • the trustee systems 102 and third party 103 to control access to the secret p and to allow the trustee systems 102 and third party 103 to validate messages published by each other.
  • the designation of one key with an asterisk and the other without should be considered to be an arbitrary choice, and the alternate designation could just as easily be used without altering the actual features of the underlying system.
  • a system for providing to a designated third party system access to a secret comprising:
  • each trustee system is configured to:
  • each trustee system is further configured to:
  • each trustee system is further configured to: receive a second key of a validation key pair from the first party system along with the secret share and store the second key of the validation key pair;
  • each secret share further comprises a share of an identifier associated with the third party system such that the identifier can be derived from the secret shares.
  • each trustee system is further configured:
  • each trustee system is further configured to verify that the identity of the third party system has not changed since the plurality of secret shares were generated.
  • each trustee system is further configured to notify the first party system when publishing its secret share.
  • the first party system is further configured to select the plurality of trustee systems from a group of available trustee systems, wherein the plurality of trustee systems is a subset of the group of available trustee systems.
  • each secret share comprising a share of the secret or the encrypted secret such that a subset of k secret shares of the n total secret shares can be used to derive the secret or the encrypted secret.
  • the third party system is further configured to validate the secret shares published in response to the request for the secret shares by comparing the decrypted second validation token published with the secret shares to a local copy of the second validation token, such that when the decrypted second validation token matches the local copy of the second validation token, the third party system retrieves the associated secret share.
  • each trustee system is further configured to:
  • third party system is further configured to:
  • a method for providing to a designated third party system access to a secret comprising:
  • a computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method of embodiment 36.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)

Abstract

La présente invention concerne un protocole cryptographique et un système de mise en oeuvre dudit protocole pour donner accès, y compris la mise en dépôt de clé sécurisée sur un grand livre, à des données chiffrées. L'invention utilise une pluralité de systèmes fiduciaires, le système fiduciaire respectif détenant une part secrète d'un secret, pour valider des requêtes de secret provenant des tiers autorisés. Lorsqu'une requête valide est effectuée, le système fiduciaire respectif publie sa part secrète à un registre. Les parts secrètes peuvent être combinées pour révéler la clé de chiffrement uniquement par le tiers autorisé. Des requêtes de clé de chiffrement et des réponses des systèmes fiduciaires peuvent être accédées par le propriétaire de la clé de chiffrement pour identifier le tiers requérant et pour avoir une preuve que la clé a été révélée au tiers.
PCT/EP2019/064227 2018-06-01 2019-05-31 Système et procédé de fourniture à un tiers autorisé d'un accès, avec la mise en dépôt de clé sécurisée sur un grand livre, à un secret WO2019229257A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201980050667.3A CN112673591B (zh) 2018-06-01 2019-05-31 用于向经授权的第三方提供对秘密的公开分类账安全密钥托管访问的系统和方法
SG11202011475RA SG11202011475RA (en) 2018-06-01 2019-05-31 System and method for providing an authorised third party with overt ledger secured key escrow access to a secret

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
EP18175515.8 2018-06-01
US15/996,336 US20190372765A1 (en) 2018-06-01 2018-06-01 System and Method for Providing an Authorised Third Party with Overt Ledger Secured Key Escrow Access to a Secret
EP18175515.8A EP3576000B1 (fr) 2018-06-01 2018-06-01 Système et procédé pour fournir à un tiers autorisé un accès sécurisé de clés sous seing privé à un secret par registre explicite
US15/996,336 2018-06-01

Publications (1)

Publication Number Publication Date
WO2019229257A1 true WO2019229257A1 (fr) 2019-12-05

Family

ID=66668951

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2019/064227 WO2019229257A1 (fr) 2018-06-01 2019-05-31 Système et procédé de fourniture à un tiers autorisé d'un accès, avec la mise en dépôt de clé sécurisée sur un grand livre, à un secret

Country Status (3)

Country Link
CN (1) CN112673591B (fr)
SG (1) SG11202011475RA (fr)
WO (1) WO2019229257A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021250460A1 (fr) * 2020-06-12 2021-12-16 Nagravision S.A. Système de gestion de chiffrement conforme à anonymisation distribuée

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017151861A1 (fr) * 2016-03-04 2017-09-08 Assured Enterprises, Inc. Utilisation d'une technique de mandataire lors d'une utilisation de clé de cryptage de dépositaire
CN107623569A (zh) * 2017-09-30 2018-01-23 矩阵元技术（深圳）有限公司 基于秘密共享技术的区块链密钥托管和恢复方法、装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101436930A (zh) * 2007-11-16 2009-05-20 华为技术有限公司 一种密钥分发的方法、系统和设备
US8891772B2 (en) * 2011-06-17 2014-11-18 Microsoft Corporation Cloud key escrow system
CN104580250A (zh) * 2015-01-29 2015-04-29 成都卫士通信息产业股份有限公司 一种基于安全芯片进行可信身份认证的系统和方法
CN106603549A (zh) * 2016-12-28 2017-04-26 上海优刻得信息科技有限公司 一种基于密文的数据交换方法和数据交换系统

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017151861A1 (fr) * 2016-03-04 2017-09-08 Assured Enterprises, Inc. Utilisation d'une technique de mandataire lors d'une utilisation de clé de cryptage de dépositaire
CN107623569A (zh) * 2017-09-30 2018-01-23 矩阵元技术（深圳）有限公司 基于秘密共享技术的区块链密钥托管和恢复方法、装置

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
COLIN BOYD ET AL: "Key Recovery: Inert and Public", INTERNATIONAL ASSOCIATION FOR CRYPTOLOGIC RESEARCH,, vol. 20170314:231517, 13 March 2017 (2017-03-13), pages 1 - 20, XP061022963, DOI: 10.1007/978-3-319-61273-7_6 *
HAL ABELSON ET AL.: "The risks of key recovery, key escrow, and trusted third-party encryption", WORLD WIDE WEB J., vol. 2, no. 3, June 1997 (1997-06-01), pages 241 - 257
ITO, M.SAITO, A.NISHIZEKI, T.: "Secret sharing scheme realizing general access structure", ELECTRON. COMM. JPN. PT. III, vol. 72, 1989, pages 56 - 64
PETER LINDER: "DEcryption Contract ENforcement Tool (DECENT): A Practical Alternative to Government Decryption Backdoors", INTERNATIONAL ASSOCIATION FOR CRYPTOLOGIC RESEARCH,, vol. 20160401:160351, 1 April 2016 (2016-04-01), pages 1 - 20, XP061020218 *
SHAMIR, A.: "How to share a secret", COMMUNICATION OF THE ACM, vol. 22, 1979, pages 612 - 613, XP000565227, DOI: doi:10.1145/359168.359176

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021250460A1 (fr) * 2020-06-12 2021-12-16 Nagravision S.A. Système de gestion de chiffrement conforme à anonymisation distribuée
US11777720B2 (en) 2020-06-12 2023-10-03 Nagravision Sàrl Distributed anonymized compliant encryption management system
US11784804B2 (en) 2020-06-12 2023-10-10 Nagravision Sàrl Distributed anonymized compliant encryption management system

Also Published As

Publication number Publication date
CN112673591A (zh) 2021-04-16
SG11202011475RA (en) 2020-12-30
CN112673591B (zh) 2021-12-31

Similar Documents

Publication Publication Date Title
US20190372765A1 (en) System and Method for Providing an Authorised Third Party with Overt Ledger Secured Key Escrow Access to a Secret
US20230299938A9 (en) System for privacy protection during iot secure data sharing and method thereof
US11128471B2 (en) Accessibility controls in distributed data systems
KR102025409B1 (ko) 블록체인을 기반으로 한 데이터 접근 관리 시스템 및 데이터 접근 관리 방법
JP5001299B2 (ja) 暗号鍵を取り替えるための認証および分散システム並びに方法
US8196186B2 (en) Security architecture for peer-to-peer storage system
EP3089399B1 (fr) Procédés et dispositifs permettant de sécuriser des clés pour un environnement réparti non sécurisé et s'appliquant à la virtualisation ainsi qu'à la sécurité et à la gestion de l'informatique du cloud
EP2396922B1 (fr) Cadre de services et informatique en nuage sécurisé
JP2020009500A (ja) データセキュリティサービス
EP2396921B1 (fr) Cadre de services et informatique en nuage sécurisé
CN111800268A (zh) 用于区块链背书的零知识证明
KR102422183B1 (ko) 데이터에 대한 액세스 인에이블링
JP6678457B2 (ja) データセキュリティサービス
US11924332B2 (en) Cryptographic systems and methods using distributed ledgers
EP3785409B1 (fr) Partage de messages de données
CN112673591B (zh) 用于向经授权的第三方提供对秘密的公开分类账安全密钥托管访问的系统和方法
EP3576000B1 (fr) Système et procédé pour fournir à un tiers autorisé un accès sécurisé de clés sous seing privé à un secret par registre explicite
Aljahdali et al. Efficient and Secure Access Control for IoT-based Environmental Monitoring
WO2023131147A1 (fr) Procédé et appareil de génération de données d'utilisateur certifiées
Vrielynck A decentralized access control and resource delegation framework
Shikha Security and Privacy of Identity Information in Cloud Computing
Eichman et al. Secure Information Sharing and Processing (SISAP) Technology

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: 19727028

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: 19727028

Country of ref document: EP

Kind code of ref document: A1