Systems and methods for secure key management using distributed ledger technology

Abstract

The present disclosure is directed to systems and methods for securely managing and governing encryption / decryption keys using distributed ledger technology (DLT). In some examples, a client may own a data attribute (or a data set of data attributes). The client may receive tokenization parameters to apply to the data attribute, thereby encrypting the data attribute. After tokenizing the data attribute, the client may then request the creation of an encryption key to apply to the token. A third-party key management system (KMS) may create an encryption key and a salt value. The salt value may be applied to the token, and then the salted token may be encrypted. In addition, a decryption key may be created and securely stored at a third-party KMS. The client may transmit the encrypted token to a third-party integration platform, where the integration platform requests access to the decryption key to reveal the underlying token.

Description

[0001] Cross-reference to related applications

[0002] U.S. patent application Ser. No. 17 / 103,751, entitled “SYSTEMS AND METHODS FOR UNIVERSAL REFERENCE SOURCE CREATION AND ACCURATE SECURE MATCHING”; U.S. patent application Ser. No. 16 / 844,927, entitled “CONTEXT DRIVEN DATA PROFILING”; and U.S. patent application Ser. No. 16 / 776,293, entitled “SYSTEMS AND METHOD OF CONTEXTUAL DATA MASKING FOR PRIVATE AND SECURE DATA LINKAGE” are incorporated herein by reference in their entirety. Technical Field

[0003] The present disclosure relates to a distributed key management system and the use of distributed ledger technology (DLT).

[0004] Overview

[0005] Encryption schemes are used to protect the data assets of the owner / source while sharing certain data assets with various parties / suppliers in order to purchase services from the parties / suppliers. Therefore, there are inherent vulnerabilities for external hackers or abuse by bad actors who may have access to encrypted data assets. However, data owners want to gain the benefits of third-party services without compromising access to the underlying data (e.g., exposing the original data). To address this problem, the present application proposes a distributed mechanism for creating, hosting, and managing encryption and decryption keys, wherein no two parties can access each key (or secret) to unlock the data. Such a structure of separating keys at runtime allows the creation of secure and trusted data exchanges in a third-party environment. In addition, the use of blockchains when storing keys and access logs provides immutability to avoid any erroneous behavior of third-party management platforms. In terms of authorizing access to certain keys to certain stakeholders, DLT is used to keep the distribution of keys between key management platforms reliable and accountable.

[0006] Another consideration includes processing data. In order to better utilize data to obtain the maximum value of services provided by third-party suppliers, the basic data needs to be processed. However, providing blanket permissions to certain applications via service contracts will create potential vulnerabilities in sensitive data assets within the organization. In addition, as the organization grows and operates, certain data assets that were previously allowed to be used may become unlicensed. To address this problem, the present application utilizes smart contracts (an aspect of DLT) to create a runtime approval tool for authorizing or revoking access to certain data assets. Background Art

[0007] In order to receive and decrypt encrypted data from a sender using asymmetric or symmetric encryption (e.g., RSA algorithm), the sender usually needs to access the recipient's key before encryption so that when the recipient receives the encrypted data, the recipient can use the key (private key in the case of asymmetric encryption) to decrypt the data. In order to provide the recipient's encryption key, the sender (or intermediary) usually has to request the encryption key from the recipient and wait for the recipient to deliver the key. The process of manually requesting an encryption key is cumbersome and time-consuming. In addition, waiting for the recipient to send and / or authorize access to the encryption key causes unnecessary delays in the communication process between the sender and the recipient. Therefore, there is a need to more efficiently transmit public keys between entities while maintaining a high level of security.

[0008] As background, public key cryptography (or asymmetric cryptography) is a cryptographic system that uses a key pair: a public key that can be widely disseminated; and a private key that is known only to the owner of the private key. In an asymmetric cryptographic system, an entity can encrypt a message using the recipient's public key, but the encrypted message can only be decrypted using the recipient's private key.

[0009] Transport Layer Security (TLS) is an Internet standard that relies on public key cryptography for communicating over computer networks. Before a client and server can begin exchanging information protected by TLS, the client and server must securely exchange or agree upon encryption keys and ciphers to use when encrypting data. One such example of an encryption algorithm is the Advanced Encryption Standard (AES), which is a subset of block ciphers.

[0010] Related to symmetric cryptography is a "salt," which is random data used as an additional input to a one-way function that hashes data, passwords, passphrases, keys, tokens, etc. The salt is used to protect passwords in storage. A new salt can be randomly generated for each password. In a typical setup, the salt and password (or a version of it after key expansion) are concatenated and processed using a cryptographic hash function, and the output hash value (but not the original password) is stored in a database along with the salt. This allows for authentication at a later time without retaining the plaintext password and thus risking exposure of the plaintext password in the event that the authentication data store is compromised. One such hashing algorithm that can be used is SHA-2 (Secure Hash Algorithm 2), which is a family of cryptographic hash functions.

[0011] Another aspect of the present application is blockchain-based technology. A blockchain is a growing list of records, called blocks, that are linked and protected using cryptography. Each block may contain a hash pointer (as a link to the previous block), a timestamp, and transaction data (e.g., each block may include many transactions). By design, a blockchain is inherently resistant to modification of transaction data. A blockchain may be managed by a peer-to-peer network of nodes (e.g., devices) that collectively adhere to a consensus protocol for validating new blocks. Once recorded, the transaction data in a given block cannot be retroactively changed without changing all previous blocks, which requires the collusion of a majority of the network nodes. Typically, a blockchain is a type of "distributed ledger." A distributed ledger uses independent computers (e.g., nodes) to record, share, and synchronize transactions in their respective electronic ledgers (rather than keeping data centralized as in a traditional ledger).

[0012] A blockchain is an append-only data structure maintained by a network of nodes that do not fully trust each other. A permissioned blockchain is a type of blockchain in which access to the network of nodes is controlled in some way (e.g., by a central authority and / or other nodes of the network). All nodes in a blockchain network agree on a set of ordered blocks, and each block can contain one or more transactions. Therefore, a blockchain can be viewed as a log of ordered transactions. A specific type of blockchain (e.g., Bitcoin) stores coins as a system state shared by all nodes of the network. Bitcoin-based nodes implement a simple replicated state machine model of moving coins from one node address to another, where each node can include multiple addresses. In addition, a public blockchain can include full nodes, where a full node can include an entire transaction history (e.g., a transaction log), and a node may not include an entire transaction history. For example, Bitcoin includes thousands of full nodes among all nodes connected to Bitcoin.

[0013] With the advent of decentralized blockchains, decentralized finance or "DeFi" came into being. DeFi is a general term for centralized permissionless financial infrastructure, where various cryptocurrency-based financial applications run. What makes these applications decentralized is that they are not managed by a central authority, but instead, the rules of these applications are written in code, and the code is open to the public for anyone to audit. These rules written in code are called "smart contracts", which are programs running on the blockchain that automatically execute when certain conditions are met. DeFi applications are built using smart contracts. DeFi applications can be considered as a cluster of second-layer applications running on top of the blockchain.

[0014] Currently, accessing and sharing data between entities requires manual requests to each entity, and the sharing of data is often insecure (e.g., using symmetric cryptography, such as simple passwords) or intermediaries (e.g., transmitting data directly to the requesting party over an insecure channel). Therefore, there is a need to share data more efficiently and securely between entities.

[0015] It is with respect to these and other general considerations that the various aspects disclosed herein have been made.In addition, although relatively specific problems may be discussed, it should be understood that the examples should not be limited to solving specific problems identified in the background of this disclosure or elsewhere. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Non-limiting and non-exhaustive examples are described with reference to the accompanying figures.

[0017] Figure 1 An example of a distributed system for managing access keys using a distributed ledger is shown.

[0018] Figure 2 An example distributed blockchain architecture for managing access keys is shown.

[0019] Figure 3 An example input processing system for implementing systems and methods for managing access keys using a distributed ledger is shown.

[0020] Figure 4 An example method for managing access keys using a distributed ledger from the perspective of a third-party integration platform is shown.

[0021] Figure 5 An example method for managing access keys using a distributed ledger is shown.

[0022] Figure 6 An example method for managing access keys using a distributed ledger from the perspective of a requestor or an application of the requestor is shown.

[0023] Figure 7 An example environment for implementing systems and methods for managing access keys using a distributed ledger is shown.

[0024] Figure 8 An example of a suitable operating environment is shown in which one or more of the present embodiments may be implemented. DETAILED DESCRIPTION

[0025] Various aspects of the present disclosure are described more fully below with reference to the accompanying drawings, which form a part of this document and illustrate specific exemplary aspects. However, different aspects of the present disclosure can be implemented in many different forms and should not be construed as being limited to the aspects described herein; rather, these aspects are provided so that the present disclosure will be thorough and complete and the scope of these aspects will be fully conveyed to those skilled in the art. Various aspects can be practiced as methods, systems, or devices. Therefore, various aspects can take the form of hardware implementation, completely software implementation, or a combination of software and hardware implementation. Therefore, the following detailed description should not be taken as limiting.

[0026] Embodiments of the present application are directed to systems and methods for managing keys (or "secrets") using distributed ledger technology (DLT). Specifically, in an example environment, a client (who wishes to share data) can interface with a third-party integration platform (i.e., an intermediary). The third-party integration platform can provide remote software / applications to the client, which requires configuration parameters, client-specific user authentication, and salt value hashing, etc. The client-side application can then apply encryption to hashed (secretly salted by a third-party) client data, which functions similarly to a private key in a public-private key infrastructure. In an example, the client can obtain a secret key from different third-party platforms that are providing a DLT key management system (KMS). By utilizing a DLT KMS, the client is able to receive an authentication key for further encrypting its data. The third-party KMS provider also holds the client's key / secret and can share the key with the third-party integration platform according to instructions from the client. Once the encryption key / secret is generated by the client, the third-party KMS provider can then transmit the encrypted key / secret to a distributed ledger (e.g., blockchain). The encrypted key may be stored on the distributed ledger for future access by remote applications awaiting permission from the client (owner of the access key). The remote application may also tokenize and encrypt at least one attribute (e.g., a data attribute such as name, address, phone number, social security number, business entity, product identifier, etc.) using the client's secret / key and a third-party secret / key to create an "encrypted token". This encrypted token / data may be transmitted to a third-party integration platform. In order to access the underlying token / data represented by the token, the token needs to be decrypted using the client's key as input (i.e., double encryption of the data attributes).

[0027] When the requester expects to access the client's secret / key, the client must first indicate permission to the requester. Such permission authorization can be recorded as a block on the blockchain. Once the permission is authorized, the third-party integration platform can then access the client's secret / key on the blockchain and apply a decryption algorithm (e.g., encrypted token / data decryption), so the client's secret / key can be used by the requester to then access the basic token / data attributes. The requester can then access the identification token / data by using the decryption key as input. In other words, in order for the requester to access the basic identification token / data stored on the third-party integration platform, the secret / key is used to decrypt the token. Once the token / data is decrypted and accessed by the requester for the following similar use cases, it is compared with the token / data for the purpose of matching the trusted source data owned by the requester. For example, the requester can use the basic token / data to support the completion of a data attribute (e.g., a phone number) related to a data entity that the client did not previously own.

[0028] In this example, it is important to note that the third party integration platform does not have access to the underlying data that is part of the encrypted or decrypted token. Only the client has access to the underlying data.

[0029] Figure 1 An example of a distributed system for managing secrets / keys using a distributed ledger is shown. The example system 100 presented is a combination of interdependent components that interact to form an integrated whole for automatically transferring assets based on smart contracts. The components of the system can be hardware components or software implemented on and / or executed by the hardware components of the system. For example, the system 100 includes client devices 102, 104, and 106, local databases 110, 112, and 114, a network 108, and server devices 116, 118, and / or 120. In some examples, the client device and / or server device can be a distributed ledger node. In other examples, if each client device and / or server device in the network has a copy of the distributed ledger and is running a distributed ledger software application, the client device and / or server device can be considered a distributed ledger node.

[0030] Client devices 102, 104, and / or 106 may be configured to receive and transmit secrets / keys, cryptographic algorithms, and tokens. They may also be configured to communicate within the blockchain network, and to locally host a copy of the blockchain in a local database 110, 112, and / or 114. On top of the blockchain may reside a DeFi application that client devices 102, 104, and / or 106 are configured to run. In one example, client device 102 may be a mobile phone, client device 104 may be a tablet, and client device 106 may be a laptop / personal computer.

[0031] In some example aspects, client devices 102, 104, and / or 106 may be configured to communicate with a satellite (e.g., satellite 122). Satellite 122 may be a satellite (or multiple satellites) within a cellular system. Client devices 102, 104, and / or 106 may receive data from satellite 122 via a cellular protocol. Cellular data received by client devices 102, 104, and / or 106 may be stored in local databases 110, 112, and / or 114. Additionally, such cellular data may be stored remotely at remote servers 116, 118, and / or 120. In other examples, client devices 102, 104, and / or 106 may be configured to communicate with each other via a short-range communication protocol (e.g., Bluetooth).

[0032] The client device 102, 104, and / or 106 may also be configured to run software that implements a blockchain with at least one DeFi application for receiving secrets / keys (encrypted) and reading requests for access to secrets / keys and transaction histories between the client owner of the secrets / keys and the requesting party. In addition, the client device 102, 104, and / or 106 may be configured to run software provided by a third-party integration platform that allows encryption (e.g., using a salt value) of secrets / keys.

[0033] For example, during initial setup, the client may authorize access to the third-party integration platform to receive data via client devices 102, 104, and / or 106. The system may then begin receiving encrypted data (i.e., data attributes + salt + secret / key) in the form of an encrypted token from the client. The token may be transmitted from the client to the third-party integration platform, where the token may be stored remotely on servers 116, 118, and / or 120. In other instances, a copy of the token may be stored locally at databases 110, 112, and / or 114. In some examples, the encrypted key (e.g., public key + salt) may be stored as a block on the blockchain. The secret / key may be transmitted from the client device via network 108 or satellite 122.

[0034] In other examples, the salt hash (i.e., global salt), token encryption key, and object ID encryption key may be stored on a private blockchain hosted by a distributed ledger host server (e.g., servers 116, 118, and / or 120).

[0035] Smart contracts (e.g., SLAs between service providers and consumers) may also reside on the blockchain network. Smart contracts may be smart contracts executed between a client and a requestor, between a client and a third-party integration platform, between a requestor and a third-party integration platform, and / or a combination of the foregoing. Copies of smart contracts may be stored locally at local databases 110, 112, and / or 114, and remotely at servers 116, 118, and / or 120. Smart contracts may determine which entities have access to the client's secrets / keys. For example, a smart contract may be established to allow a certain requestor to access the client's secrets / keys so as to then access a specific identification token / data encrypted within an encrypted token / token previously transmitted by the client to the third-party integration platform. Smart contracts may contain provisions for which entities have access to the client's keys and how long and which token / data can be accessed using the keys. In addition, smart contracts may indicate when a certain access is revoked.

[0036] In some example aspects, client devices 102, 104, and / or 106 may be equipped to receive signals from an input device. Signals may be received on client devices 102, 104, and / or 106 via Bluetooth, Wi-Fi, infrared, optical signals, binary, and other media and protocols for transmitting / receiving signals. For example, a user may use mobile device 102 to query the blockchain to transmit access keys and / or grant or revoke permissions for access keys. A graphical user interface may be displayed on mobile device 102 to allow the user to perform actions on the blockchain.

[0037] In other example aspects, devices 116, 118, and / or 120 may be a database for storing encrypted tokens in the system. As previously described, an encrypted token is an encrypted and hashed data attribute that is double-encrypted using a key and a salt value. The data attribute may include any feasible data attribute about a person, a business, a product, a location, etc. The data attribute may include personal identification information (P||) of an individual, or in other examples, certain product identification information for a specific product in a supply chain. For example, one database may store tokens associated with certain domains (e.g., individuals), and another database may store tokens associated with other domains (e.g., businesses). Contextual indicators may be used to store and organize tokens received by a third-party integration platform. For example, a subdomain may be applied to a token. For example, a subdomain may be an industry (e.g., automotive) within a broader domain (e.g., business).

[0038] Figure 2 An example distributed blockchain architecture for managing secrets / keys is shown. Figure 2 is like Figure 1 An alternative diagram of the same distributed system. Figure 2 In a blockchain, each of the network devices is interconnected and communicates with each other. In some examples, each device in the network has a copy of the blockchain because the blockchain is not controlled by any single entity but is a distributed system. In other examples, the blockchain can be a permissioned blockchain that includes an access control layer, thereby preventing and allowing some devices to read and write certain information to the blockchain.

[0039] Specifically, in Figure 2In the embodiment of the present invention, mobile devices 202, tablets 204, and 208, laptop computer 206, satellite 210, and server nodes 212-218 are all connected and communicate with each other in a blockchain network. Each node can store a local copy of the blockchain or at least a portion of the blockchain. For example, laptop computer 206 can query the blockchain in the blockchain network, and server 214 can receive the query and generate a block from the copy of the blockchain stored on server 214. Laptop computer 206 can receive information located in the block (e.g., secrets / keys, authorization, revocation of permissions, etc.). In short, the systems and methods described herein can be used in applications such as Figure 2 The invention is implemented in the distributed architecture shown in , and in some examples, is implemented on a single node within a distributed blockchain network.

[0040] Figure 3 An example input processing system for implementing systems and methods for managing access keys using a distributed ledger is shown. The input processing system (e.g., one or more data processors) is capable of executing algorithms, software routines, and / or instructions based on processing data provided by various sources related to managing secrets / keys and / or encryption algorithms. The input processing system can be a general purpose computer or a specialized special purpose computer. Figure 3 In the illustrated embodiment, the disclosed system may include a memory 305, one or more processors 310, a data acquisition module 315, a smart contract module 320, an encryption module 325, and a communication module 330. Other embodiments of the present technology may include some, all, or none of these modules and components, as well as other modules, applications, data, and / or components. However, some embodiments may combine two or more of these modules and components into a single module and / or associate a portion of the functionality of one or more of these modules with different modules.

[0041] The memory 305 may store instructions for running one or more applications or modules on the processor 310. For example, the memory 305 may be used in one or more embodiments to hold all or part of the instructions required to perform the functions of the data acquisition module 315, the smart contract module 320, the encryption module 325, and the communication module 330. In general, the memory 305 may include any device, mechanism, or populated data structure (including a local copy of the blockchain data structure) for storing information. According to some embodiments of the present disclosure, the memory 305 may cover but is not limited to any type of volatile memory, non-volatile memory, and dynamic memory. For example, the memory 305 may be a random access memory, a memory storage device, an optical storage device, a magnetic medium, a floppy disk, a tape, a hard drive, a SIMM, a SDRAM, a RDRAM, a DDR, a RAM, a SODIMM, an EPROM, an EEPROM, an optical disk, a DVD, and / or the like. According to some embodiments, the memory 305 may include one or more disk drives, a flash drive, one or more databases, one or more tables, one or more files, a local cache memory, a processor cache memory, a relational database, a flat database, and / or the like. In addition, one of ordinary skill in the art will appreciate that many additional devices and techniques for storing information can be used as memory 305. In some example aspects, memory 305 can store at least one database containing tokens, token encryption keys, object identifier encryption keys, and other encryption keys, etc. In other example aspects, memory 305 can store at least one copy of a blockchain with at least one DeFi application, which runs on the blockchain. In some further example aspects, memory 305 can store assets (e.g., access keys) that can be submitted to the blockchain via a DeFi application. Any of the data, programs, and databases that can be stored in memory 305 can be applied to the data collected by the data collection module 315.

[0042] The data collection module 315 can be configured to collect data related to secrets / keys and tokens. For example, the data collection module 315 can be configured to receive secrets / keys from the client and transmit the secrets / keys to the smart contract module 320 for writing to the blockchain. In other examples, the data collection module 315 can receive an encrypted token / token from the client, which can include encrypted token / data attributes.

[0043] Alternatively, the data collection module 315 may query or otherwise solicit data from one or more data sources (e.g., client devices, distributed ledgers, requesters, third-party integration platforms, etc.) that include such information. For example, the data collection module 315 may have access to client configurations, encryption, and / or decryption keys, etc. The data collection module 315 may use a set of APIs or similar interfaces to communicate requests to such data sources and receive response data from such data sources. In at least one example, in response to a specific user request to collect data (e.g., certain data attributes are hashed and encrypted and transmitted to a third-party integration platform as an encrypted token) or in response to satisfying one or more criteria (e.g., the requester has been authorized to access the client's key, so the client now transmits the encrypted token to the third-party integration platform to be decrypted by the requester), the data collection process of the data collection module 315 can be triggered according to a preset schedule. The data collection module 315 can also be configured to receive data related to the terms of the smart contract negotiated and executed between the client, the requester, and the third-party integration platform.

[0044] The smart contract module 320 may be configured to receive data from the data acquisition module 315. The data received by the smart contract module 320 may allow the smart contract module 320 to construct at least one smart contract on the blockchain. For example, if access is authorized from the client to the requester, the smart contract may be configured to specify that the requester is allowed to access the client's key as long as the access is authorized. The smart contract module 320 may also be configured to receive a secret / key (i.e., an encrypted key) and store it on the blockchain for access by a requester with permission to access the key. In addition, a request from the requester (e.g., a read request for the access key) may be stored on the blockchain via the smart contract module 320.

[0045] In other example aspects, the smart contract module 320 can be configured to receive data related to a smart contract between a client, a third-party KMS platform, and a third-party integration platform. For example, the smart contract can specify that the third-party integration platform can receive a decryption key belonging to the client from the third-party KMS platform (which stores the client's decryption key). The decryption key can allow the third-party integration platform to decrypt the token in order to perform processing (e.g., trusted source data matching).

[0046] The encryption module 325 can be configured to apply an encryption algorithm to a piece of data. For example, the encryption module 325 can be configured to apply a salt value during the hashing of the data to create a "token". In another example, the encryption module 325 can be configured to apply an encryption algorithm to data attributes (e.g., salt value + key + data attributes) to create an encrypted token. The encryption module 325 can also be configured to store and control access to decryption keys (e.g., token decryption keys and object identifier (ID) decryption keys). The encryption module 325 can use other hashing and encryption methods, including but not limited to SHA2348, SHA3, triple DES, Pisces encryption algorithm, Blowfish encryption algorithm, Advanced Encryption Standard (AEs), IDEA encryption algorithm, MD5 encryption algorithm, and / or RSA security encryption algorithm.

[0047] The communication module 330 is associated with sending / receiving information (e.g., collected by the data collection module 315, the smart contract module 320, and the encryption module 325) with a remote server or with one or more client devices. These communications can use any suitable technology type, such as Bluetooth, WiFi, WiMax, cellular, single-hop communication, multi-hop communication, dedicated short-range communication (DSRC), or a proprietary communication protocol. In some embodiments, the communication module 330 sends information collected by the data collection module 315 and processed by the smart contract module 320 and the encryption module 325. In addition, the communication module 330 can be configured to communicate certain terms of the smart contract from the smart contract module 320 and encrypt or decrypt certain data to the client device via the encryption module 325. In addition, the communication module 330 can be configured to communicate updated status messages between the client and the requester, such as granting or revoking an access key, for authorized permissions or denied permissions.

[0048] Figure 4An example method for managing secrets / keys using a distributed ledger from the perspective of a third-party integration platform is shown. Method 400 is from the perspective of a third-party integration platform. For example, a third-party integration platform can act as an intermediary between a client (owner of a secret / key) and a requester. Method 400 begins by receiving a request for access to a client key from a requester at 402. At 404, the request is then stored on a distributed ledger (e.g., blockchain). At 406, the request can then be transmitted to the client, where the client can determine whether to authorize or reject the request. If the client accepts the request, the client can transmit the access key to be stored on the distributed ledger. In another example, step 406 can be a transmission request to a third-party KMS provider that is hosting the client's secret / key. For example, based on a previously established smart contract, if the client has previously authorized a third-party integration platform to receive permission for a secret / key, the third-party KMS provider can provide the client key to the third-party integration platform. In such an architecture, the client may not own the secret / key because the third-party KMS system is hosting and managing the client's secret / key.

[0049] The third-party integration platform may receive the client secret / key at 408 and store the client secret / key on the distributed ledger at 410. At this point, the requester may request access to the secret / key via a read function. However, if the requester does not have permission to access the secret / key on the distributed ledger, the requester will be denied access to the secret / key.

[0050] At 412, a read request may be received from a requestor. At 414, the read request may be stored on a distributed ledger. At 416, the third-party integration platform may check the record on the distributed ledger to determine whether the requestor has permission to access the client's secrets / keys. At decision block 418, if permission exists, then access to the client's secrets / keys is granted to the requestor at 420. If permission does not exist, then access to the client's secrets is denied.

[0051] Figure 5An example method for managing secrets / keys using a distributed ledger is shown. Method 500 begins with creating and managing encryption keys for a client. In an example, a third-party key management system (KMS) may receive from a client a request to generate a key that may be applied to a specific token or data attribute that the client wishes to share with a third-party integration platform. The key may be created by a third-party KMS entity and stored on a private permissioned blockchain. In addition, a salt value may be applied to the data attribute before encryption to add an additional encryption layer to the data attribute. This application of the salt value to the data attribute may occur at step 504. "Salt value" is random data attached to the data used as an additional input to a one-way hash function. The salt value may be received from a distributed ledger node. These encryption keys received from a KMS entity (e.g., a DLT dedicated node (host server)) may also act as multiple random data to be combined with a key or data attribute to further encrypt the token and / or data attribute. In some examples, the key may include a token salt value (AES256) and an object ID encryption key (AES256). The output of the encryption, namely the salted data attribute, is an encrypted token "EToken" (data attribute + salt value + key = EToken). EToken is what can ultimately be provided to a third-party integration platform.

[0052] At step 506, the client may apply a salt value and at least one encryption key to the data attribute to create an EToken. An EToken is a hashed data attribute encrypted by input of a salt value and at least one encryption key. At step 508, the third-party integration platform may request an EToken decryption key from a third-party KMS entity. Based on previously established rules (e.g., smart contracts), the third-party KMS may authorize or deny access to the EToken decryption key for the third-party integration platform. For example, a smart contract stored on a blockchain may indicate that the third-party integration platform has access to the EToken decryption key for only certain data attributes or only within a certain time period. Otherwise, the EToken decryption key is not accessible by the third-party integration platform. In some instances, a client may have multiple EToken decryption keys corresponding to a particular EToken.

[0053] At step 510, the third-party integration platform may receive an EToken from the client. It is important to note that the third-party integration platform cannot decrypt the EToken without the EToken decryption key that the third-party integration platform may receive from the third-party KMS entity. The client may also have a copy of the client decryption key, but to reduce vulnerabilities, the third-party KMS management system may create and store the client decryption key, thereby controlling access to the key. Furthermore, the EToken decryption key only decrypts the Etoken to reveal the token itself, not the underlying data. In other words, the third-party data integration platform is never exposed to the raw underlying data that makes up the token. The third-party integration platform is equipped to process the token for purposes of, for example, data matching, trusted source reference matching, and the like.

[0054] At step 512, after the third-party integration platform receives the token decryption key from the KMS management system, the Etoken can be decrypted by the third-party integration platform. Processing can be completed on the decrypted token, and the results of the processing can be transmitted back to the edge node at the client (see Figure 7 ).

[0055] Figure 6 An example method for managing secrets / keys using a distributed ledger from the perspective of a requester is shown. Method 600 is from the perspective of a requester that interfaces with a third-party integration platform. Method 600 begins by transmitting a request for access to a client key at step 602. The request is received and stored on a distributed ledger. If permission is granted, then at step 604, the requester will receive an indication that permission to access the client key has been granted. After access has been granted, at step 606, a read request may be transmitted. The read request may indicate an intention to read a token / data attribute currently encrypted within an EToken / token. Since access to the client key has been granted, the system automatically provides the decryption key to the requester at step 608. Therefore, the requester can simply reference a block in the blockchain (or other distributed ledger) that proves that the requester has permission to access the client key, rather than having to ping the client every time the requester expects to access the token / data provided by the client. This removes inefficiencies and delays in sharing data between the client and the requester.

[0056] Once the decryption key is provided to the requester at 608, the decryption key may be used to decrypt the EToken / token where the token / data attributes are present. The decryption key may be used as an input to the encryption function of the token at step 610. After decrypting the EToken / token, the decrypted token / data attributes may be used for access at step 612. The requester may then perform data analysis (e.g., trusted source matching) at step 614.

[0057] Figure 7 An example environment for implementing a system and method for managing secrets / keys using a distributed ledger is shown. Environment 700 depicts a client node 702, a third-party KMS entity 704, and a third-party integration platform 706. In the example, a client can request the creation of an encryption / decryption key (e.g., a public / private key, a secret key, etc.) from a KMS entity 704. The KMS entity creates an encryption key for the client and stores the key on a distributed ledger (e.g., a blockchain). The ledger can be a permissioned ledger that is accessible only to those with permission. The encryption key can be used to further encrypt the client's token. The token is a data attribute that has been hashed using configuration parameters provided to the client by a third-party integration platform. In other words, the encrypted token is a data attribute with at least two encryption layers-(i) the data attribute is hashed to become a token by applying a tokenization parameter from a third-party integration platform; and (ii) the token is further encrypted by applying an encryption key from a third-party KMS platform. Such a dual distributed encryption scheme protects privacy and enhances the security of the underlying data attributes.

[0058] In other examples, the third-party KMS system may provide a salt value in addition to the encryption key. For example, a token - before being encrypted by an encryption key from the KMS system - may be "salted". This may mean, for example, that a random string of data (e.g., numbers, letters, bits, etc.) is appended to the token before being encrypted. Salting of the token provides another layer of security to the underlying data attributes.

[0059] Both the salt value and the token encryption key can be created, stored, and managed by a third-party KMS system. In other examples, the client can receive the salt value and the token encryption key for management. Once the encryption key is created by the third-party KMS system, the encryption key can be provided to the client to be applied to the token. The encryption key and salt value can be applied to the token to create an EToken that can ultimately be transmitted to a third-party integration platform for processing (e.g., data matching).

[0060] In one example, a client may have a data set of data attributes that the client wishes to match with other data sets it owns. Therefore, the client solicits services from a third-party integration platform for data matching. The third-party integration platform may provide the client with certain configuration parameters and tokenization software for the client to apply to its token so that the underlying data attributes are hashed / encrypted and hidden from the perspective of the third-party integration platform. After the data attributes are tokenized, the client may then choose to create an encryption key to apply to the token to further protect the underlying data. The encryption key may be created by the client using the services of a third-party KMS system. The encryption mechanism applied to the token may consist of first applying a salt value to the token and then applying encryption to the salted token to create an "EToken". The EToken may then be transmitted to the third-party integration platform 706 for processing.

[0061] In order for the third-party integration platform 706 to process an EToken for a certain use case / application, it must first decrypt the EToken so that it can access the underlying token (rather than the underlying data attributes). Based on the previously established smart contract between the client and the third-party integration platform, the third-party KMS system can provide the token decryption key to the third-party integration platform. It can be configured so that the smart contract exists on a permissioned ledger (e.g., blockchain) hosted by the third-party KMS system 704. Therefore, when the third-party integration platform 706 requests a token decryption key from the third-party KMS system 704, the third-party KMS system 704 can simply check the rules of the hosted smart contract to see if the request meets the requirements of the smart contract. For example, the smart contract may have certain requirements and inputs that the third-party integration platform may need to meet before the token decryption key can be transmitted, such as the time range for access, the type of token that can be decrypted, etc. If the smart contract rules are met (e.g., the client 702 has given the third-party integration platform 706 permission to decrypt a specific EToken), the token decryption key can be shared from the third-party KMS system 704 to the third-party integration platform 706. Once received by the integration platform 706, the token decryption key can be applied to the Etoken to reveal the underlying token. The integration platform can then proceed to run processing actions on the token, such as trusted source data matching.

[0062] Figure 8An example of a suitable operating environment in which one or more embodiments of the present embodiment can be implemented is shown. This is only an example of a suitable operating environment and is not intended to limit the scope of use or functionality. Other well-known computing systems, environments, and / or configurations that may be suitable for use include, but are not limited to, personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics (e.g., smartphones), network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, and the like.

[0063] In its most basic configuration, the operating environment 800 typically includes at least one processing unit 802 and memory 804. Depending on the exact configuration and type of computing device, the memory 804 (which stores information related to the device, the blockchain network, encryption algorithms, public keys, salt values, and instructions for executing the methods disclosed herein, etc.) can be volatile (e.g., RAM), non-volatile (e.g., ROM, flash memory, etc.), or some combination of the two. Figure 8 806. In addition, the environment 800 may also include storage devices (removable 808 and / or non-removable 810), including but not limited to disks or optical disks or tapes. Similarly, the environment 800 may also have input devices 814, such as keyboards, mice, pens, voice input, etc., and / or output devices 816, such as displays, speakers, printers, etc. The environment may also include one or more communication connections, 812, such as Bluetooth, WiFi, WiMax, LAN, WAN, point-to-point, etc.

[0064] The operating environment 800 typically includes at least some form of computer-readable media. Computer-readable media can be any available media that can be accessed by the processing unit 802 or other devices that include the operating environment. By way of example, and not limitation, computer-readable media can include computer storage media and communication media. Computer storage media include volatile and non-volatile removable and non-removable media implemented in any method or technology for storing information such as computer-readable instructions, data structures (e.g., blockchains), program modules, or other data. Computer storage media include RAM, ROM, EEPROM, flash memory, or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, cassettes, magnetic tape, disk storage, or other magnetic storage devices, or any other tangible media that can be used to store the desired information. Computer storage media do not include communication media.

[0065] Communication media embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" refers to a signal that has one or more of its characteristics set or changed in a manner that encodes the information in the signal. By way of example, and not limitation, communication media include wired media, such as a wired network or a direct wired connection, and wireless media, such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

[0066] Operating environment 800 can be a single computer operating in a networked environment using a logical connection to one or more remote computers. The remote computer can be a personal computer, a server, a router, a network PC, a peer device, a distributed ledger node, or other public network node, and typically includes many or all of the above elements and other elements not mentioned as such. The logical connection can include any method supported by the available communication medium. Such a networked environment is often located in an office, an enterprise-wide computer network, an intranet, and the Internet.

[0067] For example, the above text describes various aspects of the present disclosure with reference to block diagrams and / or operational diagrams of methods, systems, and computer program products according to various aspects of the present disclosure. The functions / actions marked in the blocks may not occur in the order shown in any flow chart. For example, two blocks shown in succession may in fact be substantially executed concurrently, or the blocks may sometimes be executed in reverse order, depending on the functions / actions involved.

[0068] The description and illustration of one or more aspects provided in this application are not intended to limit or restrict the scope of the disclosure claimed for protection in any way. The multiple aspects, examples, and details provided in this application are considered to be sufficient to convey the possession thereof, and enable others to make and use the best mode of the disclosure claimed for protection. The disclosure claimed for protection should not be interpreted as being limited to any aspect, example, or detail provided in this application. Whether shown and described in combination or individually, various features (structures and methods) are intended to be selectively included or omitted to produce an embodiment with a specific feature set. After providing the description and illustration of this application, those skilled in the art can envision changes, modifications, and alternative aspects that fall within the spirit of the broader aspects of the general inventive concept embodied in this application, without departing from the broader scope of the disclosure claimed for protection.

[0069] In summary, it should be understood that specific embodiments of the present invention have been described herein for illustrative purposes, but that various modifications may be made without departing from the scope of the present invention. Therefore, the present invention is not limited except by the appended claims.

Claims

1. A system comprising: at least one processor; as well as a memory coupled to the at least one processor, the memory comprising computer executable instructions that, when executed by the at least one processor, perform a method comprising: receiving at least one encrypted token, wherein the at least one encrypted token comprises at least one encrypted data attribute, at least one encrypted token salt value, and at least one encrypted object ID encryption key; requesting at least one decryption key associated with the at least one encrypted token, wherein the at least one decryption key is configured to decrypt the at least one encrypted token salt value and the at least one encrypted object ID encryption key; analyzing at least one smart contract on a blockchain, wherein the at least one smart contract manages access to the at least one decryption key; Based on an analysis of the at least one smart contract on the blockchain, determining that access to the at least one decryption key is authorized; receiving the at least one decryption key; applying the at least one decryption key to the at least one encrypted token; receiving at least one decrypted token; processing the at least one decrypted token, wherein processing the at least one decrypted token comprises comparing trusted source data to the at least one decrypted token to identify one or more missing data attributes; and Results from the processing of the at least one decrypted token are communicated to at least one owner of the at least one encrypted token.

2. The system according to claim 1, wherein: The at least one encrypted token is encrypted using at least one salt value and at least one 256-bit encryption algorithm.

3. The system according to claim 1, wherein: The at least one decryption key is stored on at least one permissioned blockchain.

4. The system according to claim 1, further comprising: At least one revocation notification is received to revoke access to the at least one decryption key.

5. The system of claim 1, wherein access to the at least one decryption key is temporary.

6. The system of claim 1, wherein access to the at least one decryption key is based on a classification of the at least one encrypted token.

7. A method for securely managing access to a key using distributed ledger technology, comprising: The third-party key management system receives a request to create at least one encrypted token, wherein the at least one encrypted token includes at least one encrypted data attribute, at least one encrypted token salt value, and at least one encrypted object ID encryption key; a third party key management system generating a decryption key associated with the at least one encrypted token, wherein the decryption key is configured to decrypt the at least one encrypted token salt value and the at least one encrypted object ID encryption key; A third-party key management system generates a smart contract, wherein the smart contract manages access to the decryption key; A third-party key management system stores the decryption key and a smart contract that manages access to the decryption key on a permissioned blockchain; The third party integration platform requests at least one decryption key associated with the at least one encrypted token; The third-party integration platform receives the at least one decryption key based on the smart contract; The third party integration platform applies the at least one decryption key to the at least one encrypted token; The requestor receives at least one decrypted token; and The requestor processes the at least one decrypted token, wherein processing the at least one decrypted token includes comparing trusted source data to the at least one decrypted token to identify one or more missing data attributes.

8. The method according to claim 7, wherein: The at least one decrypted token is encrypted using at least one AES 256-bit encryption algorithm.

9. The method according to claim 7, further comprising: The client receives at least one request for access to the decryption key.

10. The method according to claim 9, further comprising: A client queries the smart contract on the permissioned blockchain to analyze at least one rule governing access to the decryption key.

11. The method of claim 10, the client authorizing access to the decryption key based on the analysis of the at least one rule governing access to the decryption key.

12. The method of claim 11, further comprising the client recording access authorization to the decryption key on the permissioned blockchain.

13. The method of claim 10, wherein the client denies access to the decryption key based on an analysis of at least one rule governing access to the decryption key.

14. The method according to claim 13, further comprising: The client records the denial of access to the decryption key on the permissioned blockchain.

15. The method of claim 9, wherein a client stores at least one request for access to the decryption key on the permissioned blockchain.

16. A computer readable medium storing non-transitory computer executable instructions which, when executed, cause a computing system to perform a method for securely managing cryptographic keys in a distributed ledger technology (DLT) environment, the method comprising: The third-party key management system receives a request to create at least one encrypted token, wherein the at least one encrypted token includes at least one encrypted data attribute, at least one encrypted token salt value, and at least one encrypted object ID encryption key; a third party key management system generating a decryption key associated with the at least one encrypted token; The third-party key management system generates a smart contract, wherein the smart contract includes at least one rule governing access to the at least one decryption key; The third-party key management system stores the smart contract and the decryption key on a permissioned blockchain; The client receives at least one request for access to the decryption key; The client determines whether to authorize access to the decryption key based on the at least one rule governing access to the decryption key; The client authorizes access to the decryption key based on the determination; The third-party integration platform applies the decryption key to at least one encrypted token; The requestor receives at least one decrypted token; and The requestor processes the at least one decrypted token, wherein processing the at least one decrypted token includes comparing trusted source data to the at least one decrypted token to identify one or more missing data attributes.

Images