DECENTRALIZED COMPUTING SYSTEMS AND METHODS FOR PERFORMING ACTIONS USING STORED PRIVATE DATA

Abstract

A distributed computing system is used to form a login network to perform an action for a user, using private data. The login network executes the verification using blockchain computing architecture, which is decentralized. The private data is stored on the blockchain in an obfuscated form. In order to compute the private data from the obfuscated form, multiple distributed private key shares are required to generate multiple decryption shares, which are combined to compute a One Time Pad (OTP). In turn, the OTP is used to obtain the private data from the obfuscated form.

Description

TECHNICAL FIELD

The following generally relates to decentralized computing systems and methods for performing actions using stored private data. The decentralized computing systems includes a blockchain network of nodes.

DESCRIPTION OF THE RELATED ART

People interact with computing platforms over the Internet to perform actions that use private data, including and not limited to personal identifiable information. There are other types of data that people or even computing systems wish to keep private, and for which they desire another party's computing system to use to perform some action. For example, through a web browser on a user device, private data is transmitted to the other party's computing system so that the other party's computing system can use the private data to perform an action as desired by the user.

People or their user devices, or both, can repeatedly provide the private data to the other party's computing system each time the action is desired to be taken. However, it is herein recognized that this is a time-consuming process for the user and the other party, and also makes the private data more vulnerable to theft by an adversary.

Private data can also be stored by the other party's computing system and then locally retrieved each time the action is desired to be taken. However, it is herein recognized that this is a large burden of responsibility to the other party's computing system to securely store private data. If a data breach occurs at the other party's computing system, then the private data can be obtained by an adversary.

Private data can be stored on a blockchain, which in many cases supports an immutable ledger of data. While the data can be encrypted, it is herein recognized that there is a desire to delete data so that other parties on the blockchain network (e.g. such as a public blockchain network) cannot access or recreate the private data. However, deleting the private data is technically difficult given the immutable nature of blockchains.

It is therefore herein recognized that storing private data in a secure manner, later securely and automatically retrieving this private data for use by the other party's computing system, and later deleting the private data from the computing systems, are technically difficult.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments will now be described by way of example only with reference to the appended drawings wherein:

FIG. 1 is a schematic diagram of an example of user devices, trusted nodes, relying party systems and a blockchain network of nodes in communication with each other over a data network.

FIGS. 2, 3, 4 and 5 are schematic diagrams showing different example embodiments of the computing systems, including a secure execution and secure storage environment.

FIG. 6 is a flow diagram of computer executable or processor implemented instructions for generating distributed keys, according an example embodiment.

FIG. 7 is a flow diagram of computer executable or processor implemented instructions for generating multiple sets of distributed keys, according to another example embodiment.

FIG. 8 is a flow diagram of computer executable or processor implemented instructions for encrypting private data, according to an example embodiment.

FIG. 9A is a flow diagram of computer executable or processor implemented instructions for decrypting private data, according to an example embodiment.

FIG. 9B is a flow diagram of computer executable or processor implemented instructions for decrypting private data, according to an example embodiment that is in alternative to the embodiment in FIG. 9A.

FIG. 10 is a flow diagram of computer executable or processor implemented instructions for deleting the subject data from the computing system.

FIG. 11 is a flow diagram of computer executable or processor implemented instructions for reading and subsequently deleting the subject data from the computing system.

FIG. 12 is a flow diagram of computer executable or processor implemented instructions for reading and deleting the subject data from the computing system, as well as adding new subject data to the computing system.

FIG. 13 is a flow diagram of computer executable or processor implemented instructions for encrypting private data using a native application, according to an example embodiment.

DETAILED DESCRIPTION

It will be appreciated that for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth in order to provide a thorough understanding of the example embodiments described herein. However, it will be understood by those of ordinary skill in the art that the example embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the example embodiments described herein. Also, the description is not to be considered as limiting the scope of the example embodiments described herein.

It an example aspect, an improved login system is provided that satisfies related regulatory standards. For instance, the European Union has introduced the General Data Protection Regulation (GDPR) to protect consumer's private information, which requires organizations and companies to provide consumers certain rights that relates to their private information, including specifically the right to be forgotten. Private Identifiable information (PII) will need to be deleted from the data network system. It is herein recognized that deleting data from a blockchain network, which in many embodiments is decentralized and has an immutable ledger, is technically challenging. The improved login system herein facilitates usage of the blockchain network, while still being able to delete the private data at a later time as desired.

In another example aspect, the login network is simple and easy for users to use, and to do provide a system that is massively scalable. By contrast, common existing approaches that requires the user to download software, use, special browsers, or install plugins are filled with friction and create significant drop-off in usage by customers. To that end, in another example aspect of the login network, the user is not required to manually download and install any special software, while at the same time, the improved login system provides the users with the benefits achievable by the blockchain when compared to a centralized solution.

In an example aspect, the login network is a more secure, frictionless, and decentralized computer platform than what currently exists today for both blockchain applications (smart contracts) and traditional web applications.

In another example aspect, the login network is a trusted source for identity, while also providing capabilities to maintain privacy.

Below are example aspects of the login network, which will be discussed in greater detail in this document.

In an example aspect of the system, decentralization is provided. architecture that can provide authentication and privacy without dependencies on centralized trust anchors. Additionally, for those users seeking a frictionless experience that do not desire to install any additional software, the login network architecture diffuses the private data amongst multiple nodes and encrypts the data with a threshold encryption scheme will also be described.

In an example aspect of the system, privacy is provided. The data subject is able to assert their privacy rights regarding their data, while still enjoying the benefits of using a blockchain when compared to a centralized solution.

In an example aspect of the system, regulatory compliance is provided. The system enables using a decentralized architecture, while at the same time adhering to regulatory standards designed to protect people's data.

Turning to FIG. 1, the computing architecture includes one or more users 101 and their user devices 102, having web browsers 103 for accessing websites of relying party systems 104. Examples of a relying party system are servers that belong to companies, merchants, organizations, government bodies, institutions, etc. In an example aspect, the user devices include one or more biometric scanner systems 111, such as, but not limited to, a fingerprint scanner, a camera system, and an infrared dot projector. These systems can be used for biometric authentication (e.g. thumbprint identification, facial identification, eyes identification, etc.).

There are also one or more trusted nodes 105 and a blockchain network of nodes 106. It will be appreciated that these nodes, systems, and user devices are computing devices (e.g. including one or more of desktop computers, mobile devices, server machines, cloud computing servers, virtual machines on cloud computing servers, etc.). These computing devices or computing systems, or both, interact with each other via the data network 100. For example, the data network is the Internet. These computing devices or computing systems, or both, include a processor system, memory, and a communication system.

In another example embodiment, a company, merchant, organization, etc. that operates the relying party system alternatively (or in addition) has a native application or app 110 that resides on the user device 102, and the native app 110 has a trusted node SDK that facilitates the native app to communicate with a trusted node 105. In other words, the principles of securely storing and accessing private data can be used in a browser environment or in a native app environment, or both.

In an example embodiment, the blockchain network of nodes 106 includes blockchain compute nodes that execute distributed applications (DApps) 107 and blockchain storage nodes 108 that store data in a distributed ledger.

A non-limiting example embodiment of a blockchain network of nodes is the Ethereum network, in which there are multiple computing devices (e.g. nodes) that form the blockchain network. It is appreciated that there are other blockchain network of nodes that are applicable to the principles described herein.

In an example embodiment, the blockchain compute DApp nodes 107 are part of a first blockchain network, and the blockchain storage nodes 108 are part of a second blockchain network, which together form the network 106. In an example embodiment, the blockchains 107 and 108 are part of the same network.

In another example embodiment, the blockchain 107 is the Ethereum network and the blockchain 108 is the Interplanetary File System database. It will be appreciated that this is just an example and that other currently known networks and future-known networks can be used according to the principles described herein.

FIGS. 2 to 5 show different example embodiments of the decentralized computing architecture, where a secure execution and secure storage environment 109 resides on different hardware environments. It will be appreciated that a secure execution and secure storage environment can be established using one or more of specific computing hardware and specific software. For example, a secure execution and secure storage environment can be established using one or more of: a Trusted Execution Environment (TEE); a firewall; a software layer; a secure enclave; a Hardware Secure Module (HSM); etc. It will be appreciated that a TEE is a computing chip that, for example, exists on a processor device. It will be appreciated that a HSM is a separated computing appliance.

FIGS. 2 to 5 show that the user device 102 interacting with a relying party system 104, and that the relying party system interacts with one or more trusted nodes 105. The one or more trusted nodes (herein called “trusted node” to refer to one or multiple ones of these nodes). The trusted node and the blockchain compute DApps 107 exchange data with each other. The blockchain compute DApps 107 coordinate storage and retrieval from the blockchain storage 108.

In some example embodiments, the user device 102 and the trusted node 105 communicate with each other. In some example embodiments, the relying party system 104 and the blockchain compute DApps 107 communicate with each other.

FIG. 2 shows that the secure execution and secure storage environment 109 resides on the nodes in the blockchain compute DApps 107. FIG. 3 shows that the secure execution and secure storage environment 109 resides on the nodes of the blockchain storage 108. FIG. 4 shows that the secure execution and secure storage environment 109 resides on nodes of one or more relying party systems 104. FIG. 5 shows that the secure execution and secure storage environment 109 is separate and accessible by the blockchain compute DApps 107.

The computations for distributed key generation and the distributed private key storage, which are discussed in more detail below, take place in the secure execution and secure storage environment 109. It will be appreciated that these computations and storage can therefore reside on different computing devices. It will also be appreciated that the blockchain computing DApps direct the generation of the distributed keys to take place in the specified environment 109.

Turning to FIG. 6, at block 601, the blockchain network of nodes 106 generates distributed key set, including a public key, multiple private key shares, and a threshold number t. This computation takes place in a distributed manner across multiple computing devices, each in a secure execution and secure storage environment 109. The private keys shares are stored in the environment 109 of the respective computing devices.

In an example embodiment, a distributed key generation algorithm outputs a threshold public key PUB_th and multiple corresponding private key shares PRIV_th_{1 . . . N}. N is the number of private key shares that are outputted, where each private key share is respectively generated and stored on a different node or a different computing device. In other words, there are multiple private key shares that correspond to one public key. A threshold number t is also provided, where t≤N. In this way, it is possible that a smaller number of private keys shares (e.g. smaller than the total number N created) are required to execute a decryption. In an example aspect, the specific key shares, and the corresponding nodes on which the key shares are stored, that form the reconstruction group of key shares are not known at the time of the key generation and can be determined when decryption occurs.

For example, t is a smaller number than N, so that in case one or more nodes of the set N are unavailable, the decryption process can still take place so long as at least t nodes with the private key shares are available.

As will be described in further detail, as part of the decryption process, the t nodes will send a decryption share (e.g. a partial plaintext) to a combiner module, and the combiner module will in turn obtain the complete plaintext. For example, the relying party system 104 includes or is the combiner module.

The blockchain network of nodes 106 provides the public key to one or both of the trusted node 105 and the replying party system 104. The trusted node 105 and the relying party system 104 obtain the public key (blocks 603, 604).

FIG. 7 shows an alternative embodiment to FIG. 6 for distributed key generation. In particular, the blockchain network of nodes 106 generates multiple distributed key sets (block 701). Each distributed key set includes a public key, multiple private key shares on stored on separate nodes, and a threshold number t. Each of these distributed key sets have attributes associated with them, and the values of these attributes can vary amongst the different sets. The attributes for example, include one or more of the following: the number of nodes and private key shares N; the number t; the cost of performing decryption operations with the given set of nodes; the security or reliability, or both, of the nodes that store the private key shares; a rating; etc.

At block 702, for each distributed key set, the blockchain network of nodes provides the public key and attributes associated with the given distributed key set to one or both of the trusted node and the relying party system.

At blocks 703, 704, this data is obtained by the trusted node and the relying party system.

In this way, the trusted node or the relying party system, or both, can use the attributes to determine which distributed key set, and accordingly which corresponding public key, should be used to encrypt the private data.

Turning to FIG. 8, after the distributed keys are generated, an encryption process of the private data takes place.

In particular, at block 801, the user 101 (via the browser 103) visits a website of the relying party system (block 801). The browser 801 of the user's device 102 sends a page request to the relying party system (block 802). The relying party system then provides a webpage to the browser, which includes login ID compute data (block 803).

In an example embodiment, this login ID compute data includes executable code for computing encryption of data that is to be locally run on the browser 103, as well as the threshold public key PUB_th. In an example embodiment, the executable code is Java Script.

In another example embodiment, this login ID compute data includes executable code that points to one or more trusted nodes 105, such as via an iframe (e.g. also called an inline frame), and the threshold public key PUB_th. The login ID, via the iframe which is part of the webpage of the relying party system, allows for encryption computations to be made by both the browser 103 and the trusted node 105.

The operations in blocks 804 and onwards, for example are executed based on the login ID compute data sent by the relying party system to the browser.

At block 804, the browser obtains the subject data (SD) that will be later used by the relying party system to perform the desired subject actions. The subject data is data that is desired to be kept private and stored on the blockchain network of nodes, so that the user or the browser does not need to repeatedly obtain the subject data every time the subject action takes place. In other words, the user or the browser, or both, only obtains the subject data one time. For example, the subject data is PII.

At block 805, the browser generates a One Time Pad (OTP).

At block 806, the browser computes SD′ using OTP and SD. For example, SD′=SD⊕OTP. The xor function is an example process that is computationally efficient. However, other processes for obfuscating SD using OTP are applicable to the principles described herein.

At block 807, the browser encrypts OTP to get the cipher C_OTP. For example, the encryption is done using the threshold public key PUB_th. This can be expressed as C_OTP=E_{PUB_th}(OTP).

At block 808, the browser encrypts SD′ to get the cipher C_SD. For example, the encryption is done using a public key of the trusted node, referred to as PUB_trusted_node. This can be expressed as C_SD=E_{PUB_loginID}(SD′).

In an alternative embodiment, the user enters in SD, which can be plain text (block 804) via the browser. The browser sends SD to the trusted node. The trusted node computes 805, 806, 807, 808. Then trusted node then deletes SD.

At block 809, the browser sends the ciphers C_SD and C_OTP to the trusted node.

At block 810, the trusted node generates and sends a challenge to the browser. In an example embodiment, the challenge is a function of C_SD and C_OTP.

At block 811, responsive to the challenge, the browser performs authentication, and includes obtaining data from the user. This could be user ID data or other data to authenticate the user. User ID data could include a password, biometric data (e.g. fingerprint, eye scan, etc.), a secret code, credentials, etc.

At block 812, the authentication data is sent to the trusted node, which then verifies the authentication data (block 813).

If the authentication data is verified, then the trusted node computes and stores SD′ (block 814). In particular, the trusted node decrypts C_SD using the trusted node private key PRIV_trusted_node that corresponds to the public key PUB_trusted_node, which outputs SD′.

At block 815, the cipher C_OTP is sent to the blockchain network of nodes for storage (block 816).

In an example embodiment, the authentication process at block 811 adheres to the FIDO process, which is developed by the FIDO Alliance (www.fidoalliance.com) and World Wide Web Consortium (W3C). FIDO stands for Fast Identity Online. For example, as part of the authentication process, the user touches their finger to a fingerprint scanner on their user device 102, or places their face in front of a camera or another scanner on the user device for facial identification, or looks into one or more cameras on the user device for eye identification. Other types of authentication can also be used. In an example embodiment, the challenge at block 810 is a FIDO challenge and is computed by hashing (random∥C_SD∥C_OTP). In the blocks 814, 815 and 816, a FIDO public key is also transmitted amongst the entities and stored on both the trusted node and on the blockchain network of nodes.

After the subject data (SD) is stored in an encrypted form on the blockchain, the retrieval and decryption process can occur repeatedly at different later times. In other words, the user does not need to re-enter the SD in order for the relying party system to execute some action that uses the SD. The relying party system is able to retrieve the SD′ and decrypt it to get SD and perform one or more subject actions that uses the SD.

In an example aspect, the OTP at blocks 805 and 806 is a cryptographic key. In this way, the data stored on a (permission) blockchain is not some variant of SD, but a cryptographic key that is independent of SD.

Turning to FIG. 9A, the decryption process is shown.

At block 901, the relying party system sends the webpage to the browser, including the login ID compute data. For example, this login ID compute data includes Java Script code.

At block 902, the browser generates a request for one or more subject action, which uses the SD. This request is sent to the relying party system at block 903.

At block 904, the relying party system generates and sends a request for authentication to the browser 103.

At block 905, the browser (e.g. with the user 101) performs the authentication. For example, the authentication using biometrics. In another example embodiment, the biometrics are used as part of the FIDO authentication process.

At block 906, the browser sends the authentication data to the trusted node, either directly or via the relying party system.

At block 907, the trusted node verifies the authentication data. If the authentication data has been verified, then the trusted node retrieves SD′ from local memory storage (block 908).

In parallel or in sequence to operations 907-908, the trusted node also sends the authentication data and sends a request for decryption shares to the blockchain network of nodes (block 909).

Following block 909, the blockchain network of nodes then request the relevant nodes for private key shares (block 910). For example, the request is attempted to be sent to the N nodes that respectively possess the private key shares PRIV_th_{1 . . . N}.

At block 911, at least t number of nodes verify the authentication data.

If the t number of nodes each verify the authentication data, then at block 912 the t number of nodes generate decryption shares using the private key shares and the cipher C_OTP.

In an example aspect, each node i in the Reconstruction Set R will verify the authentication data. It is appreciated that |R|=t≤N. After verification, each node i generates a decryption share DS_i, where DS_i is a function of C_OTP and the private key share PRIV_th_i.

At block 913, each node i in the Reconstruction Set R sends their respective decryption share DS_i to the relying party system. In an example aspect, each decryption share is encrypted using the trusted node's public key (e.g. PUB_trusted_node).

After receiving the trusted node receives the decryption shares from the different block chain nodes, it decrypts this data using the corresponding trusted node's private key (e.g. PRIV_trusted_node).

At block 914, the trusted node computes the OTP using all the decryption key shares. For example, the relying party system combines the different instances of DS_i.

At block 915, the trusted node computes SD. For example, SD=SD′⊕OTP. The xor function is an example. Another function that is able to retrieve SD from SD′, where SD′ was previously obtained by obfuscating SD using OTP, is applicable to the principles described herein.

At block 916, the trusted node encrypts SD, for example using the relying party's public key, thereby forming the encrypted value SD_RP.

At block 917, the trusted node sends SD_RP to the relying party.

At block 918, the relying party obtains SD_RP and decrypts the same using its private key, to get SD.

At block 919, the relying party system performs one or more subject actions using the SD.

At block 920, after using the SD, the relying party system deletes SD and SD_RP.

In an example embodiment, the cipher C_OTP is retrieved by using an identifier from the authentication data. In other words, when the C_OTP was initially stored during the encryption process on the blockchain, it was stored in association with an identifier from the authentication data. In a further example aspect where the authentication process adheres to the FIDO Alliance, the identifier is a FIDO public key. It will be appreciated that there are other ways to retrieve the C_OTP from the blockchain network of nodes.

In other example embodiments, after the subject data SD has been obfuscated and stored on the decentralized computing system (e.g. the trusted node), which is part of the encryption process described in FIG. 8, it may be desirable to delete the obfuscated data SD′. The deletion process can occur after a decryption process (e.g. as described in FIG. 9A).

FIG. 9B is similar to FIG. 9A, but the SD is computed by the relying party system instead of the trusted node. Following block 905, the authentication data is sent from the browser to the relying party system (block 906′). The relying party sends the authentication data and a request for decryption shares to the blockchain network of nodes (block 909′). The relying party system also sends the authentication data and a request for SD′ from the trusted node.

Blocks 907 and 908 are executed by the trusted node. At block 931, SD′ is sent to the relying party system.

Following blocks 910, 911, 912, the decryption shares are sent from the blockchain network of nodes to the relying party system (block 913). In an example embodiment, each of the decryption shares are encrypted with the relying party's public key. Upon receipt of the decryption shares at relying party system, the relying party system uses is private key to decrypt each of the decryption key shares.

At block 914′, the relying party system computes the OTP using all the decryption key shares. For example, the relying party system combines the different instances of DS_i.

At block 915′, the relying party system computes SD. For example, SD=SD′⊕OTP. The xor function is an example. Another function that is able to retrieve SD from SD′, where SD′ was previously obtained by obfuscating SD using OTP, is applicable to the principles described herein.

Block 919 is then executed. The SD, SD′ and the OTP are deleted (block 932).

The example embodiments in FIGS. 10 to 12 show different computations for deleting the subject data from the decentralized computing system, including the trusted node 105. For example, this can be used by a user to execute their right to be forgotten should the subject data include personal identifiable information, or the like.

In FIG. 10, the browser 103 (e.g. with the initiation of the user 101) accesses the trusted node and sends a request to delete SD′ (block 1001). At block 1002, the browser also perform authentication. At block 1003, authentication data is sent from the browser to the trusted node. The trusted node verifies the authentication data (block 1004) and then deletes SD′ (block 1005).

By deleting SD′, other parties (e.g. adversary entities) cannot reproduce SD even from the other data stored on the blockchain network of nodes.

In an example aspect, the trusted node requests that the blockchain network of nodes deletes C_OTP from the blockchain. However, as many blockchains implement an immutable ledger, the deletion of C_OTP would be recorded. In some cases, it is desirable to record the deletion of C_OTP. In other cases, it is undesirable to delete C_OTP, as this could notify the blockchain network that SD′ has been deleted, which could potentially be used in an adversarial way. Therefore, there are embodiments in which C_OTP is deleted from the blockchain, and there are embodiments where C_OTP is not deleted from the blockchain.

FIG. 11 is similar to FIG. 10 and includes the blocks 1001 to 10004. After block 1004, the trusted node retrieves SD′ locally from memory (block 1101).

At block 1102, the trusted node computes SD from SD′. This is done by the trusted node requesting decryption shares from the blockchain network of nodes, which then in response executes blocks 910, 911, 912. The decryption shares are provided to the trusted node, and the trusted node uses this information to compute OTP (similar to block 916 but on the trusted node) and then to compute the SD.

At block 1103, the trusted node sends the SD to the browser.

At block 1104, the browser and the user read the SD, and the browser sends a confirmation to delete the SD (block 1105). At block 1106, the trusted node deletes SD and SD′. In other words, the user can first read the subject data SD before confirming its deletion.

FIG. 12 shows a similar embodiment to FIG. 11, including the operations up to block 1104.

After block 1104, the browser deletes SD and adds new subject data SD2 (block 1201). This operation of deleting the initial SD and the adding new subject data SD2 is like a modification operation. This then causes the trusted node to delete SD and SD′ (block 1202).

The new subject data SD2 is then locally encrypted (block 1203). In particular, the process is similar to the encryption process described in FIG. 8 for obfuscating SD, but now SD2 is obfuscated to output SD2′.

It will be appreciated that, using the above computations, the user deletes SD′ which then makes the subject data SD safe. In other words, an adversary cannot recoup SD. The remaining shards of information on the blockchain cannot be used to recover SD. Furthermore, the shards of information on the blockchain becomes irrecoverable. This guarantees that the login system provided herein provides compliance with privacy regulations such as GDPR (e.g. the right to be forgotten).

In another example embodiment, the subject data SD is encrypted using a native application 110 that resides on the user device 102, instead of a browser. For example, a merchant or a company has a native application 110 (also herein called an app) that includes the trusted node's software developer kit. Turning to FIG. 13, the app 110 sends a request to the blockchain network of nodes for the public key PUB_th associated with the threshold crypto scheme (block 1301).

It will be appreciated that the blockchain network of nodes generates a distributed key generation (DKG) key set where PUB_th is a public key and the corresponding private key shares are {PRIV_th_{1 . . . N}}. N is the number of private key shares that are outputted, where each private key share is respectively generated and stored on a different node or a different computing device on the blockchain network. In other words, there are multiple private key shares that correspond to one public key. A threshold number t is also provided, where t≤N. In this way, it is possible that a smaller number of private keys shares (e.g. smaller than the total number N created) are required to execute a decryption.

At block 1302, the user visits the app 110 (e.g. by selecting the app on their user device).

At block 1303, the app 110 obtains the subject data SD for one or more subject actions. For example, the user inputs SD.

At block 1304, the app obtains PUB_th.

At block 1305, the app generates an OTP. For example, the OTP is a random value.

At block 1306, the app computes SD′ using the OTP and SD. For example, SD′=SD⊕OTP.

At block 1307, the app securely stores SD′ on the user device 102.

At block 1308, the app encrypts the OTP using the PUB_th, to output C_OTP. For example, C_OTP=E_{PUB_Threshold}(OTP)

At block 1309, the app sends C_OTP to the trusted node.

At block 1310, the trusted node computes a challenge that is a function of a random value and C_OTP. For example, challenge=F(random, C_OTP).

At block 1311, the challenge is transmitted from the trusted node to the app.

At block 1312, the app performs an authentication process with the user. For example, the authentication process includes obtaining user data from the user. For example, the user data is biometric data from the user. In another example embodiment, the authentication process is a FIDO authentication process that uses biometric data, such as a fingerprint scan. For example, the user touches a fingerprint scanner on their user device to perform authentication.

At block 1313, the authentication data is sent from the app to the trusted node. For example, the authentication data includes the authentication public key. An example of the authentication public key is the FIDO public key, where the FIDO authentication process is used.

At block 1314, the trusted node verifies the authentication data.

At block 1315, the trusted node computes D=(C_OTP∥authentication public key). In the example of using the FIDO authentication process, then D=(C_OTP∥FIDO public key).

At block 1316, the value D is transmitted to the blockchain network of nodes.

At block 1317, the blockchain network of nodes stores C_OTP in association with the authentication public key.

To request the SD, the app 110 makes a request for the decryption key shares. The app sends authentication data to the blockchain network of nodes, and the blockchain network of nodes verify the authentication data. For example, in a FIDO authentication process, the blockchain network of nodes verify the FIDO authorization signature. After verification, the blockchain network of nodes then send the decryption key shares to the trusted node. The decryption key shares are then used by the trusted node to rebuild the OTP. In other words, principles in FIGS. 9A and 9B can be generally applied to the native application.

Below are general example embodiments and example aspects.

In a general example embodiment, a computing system designated as a trusted node, includes a communication system that is in communication with a user device, a relying party system and a blockhain network of nodes. The computing system that is the trusted node also includes a memory that stores at least a threshold public key that corresponds to multiple private key shares, wherein the trusted node receives the threshold public key from the blockhain network of nodes. The computing system that is the trusted node also includes a processor system that executes at least: computing a challenge using a cipher C_SD of a subject data (SD) and a cipher C_OTP of a One Time Pad (OTP) from the user device; transmitting the challenge to the user device to initiate an authentication process; after receiving authentication data from the user device, verifying the authentication data; and, if the authentication data is verified, decrypting the cipher C_SD using the trusted node's private key to output and locally store SD′ in the memory, and transmitting the cipher C_OTP to the blockchain network of nodes.

In an example aspect, the challenge is a Fast Identity Online (FIDO) challenge that is computed by hashing (a random value∥the cipher C_SD∥the cipher C_OTP).

In another example aspect, the memory further stores a FIDO public key.

In another example aspect, the OTP is a cryptographic key.

In another example aspect, after receiving and verifying a later instance of authentication data, the processor system at least further executes: retrieving the SD′ from the memory; obtaining decryption key shares that corresponds to some or all of the multiple private key shares from the blockchain network of nodes; computing the OTP using the decryption key shares; computing the SD from the OTP and SD′; encrypting the SD with the relying party system's public key to output SD_RP; and initiating transmitting SD_RP to the relying party system.

In another example aspect, there are N private key shares that comprise the multiple private key shares, and t number of decryption key shares are each one generated as function of a corresponding one oft private key shares and the cipher C_OTP, wherein t≤N.

In another example aspect, each one of the decryption key shares is initially encrypted using a public key of the trusted node, and the computing system decrypts each one of the decryption key shares using a private key of the trusted node, which corresponds to the public key of the trusted node.

In another example aspect, the processor combines the decryption keys shares to compute the OTP.

In another example aspect, computing the SD from the OTP and the SD′ comprises SD=SD′⊕OTP.

In another general example embodiment, a method for encrypting and later deleting subject data from a decentralized computing system is provided. The method includes an encryption process, and encryption process includes: a web browser on a user device obtaining the subject data; the web browser computing a One Time Pad (OTP), an obfuscation SD′ of the subject data, a cipher C_OTP of the OTP using a threshold public key, and a cipher C_SD of the SD′ using a public key of a trusted node; the web browser sending the C_SD and the C_OTP to the trusted node, wherein the trusted node stores a private key corresponding to the public key of the trusted node for decrypting C_SD to get the SD′; and wherein the trusted node is in communication with a blockchain network that stores multiple private keys shares corresponding to the threshold public key. The method also includes a deletion process, and the deletion process includes: the web browser sending a delete command to the trusted node to delete the C_SD and SD′.

In another general example embodiment, a method is provided for a computing system to perform one or more subject actions using subject data. The method includes an encryption process and a decryption process. The encryption process includes: the computing system receiving a threshold public key that has been computed by a blockchain network, and where multiple private key shares correspond to the threshold public key, and the multiple private key shares are respectively distributed across multiple nodes that form part of the blockchain network. The encryption process also includes: the computing system transmitting a webpage with login compute data to a web browser, the login compute data comprising the threshold public key and executable instructions for the browser to execute to generate a cipher C_OTP of a One Time Pad (OTP) and a cipher C_SD of the subject data, and for the browser to initiate storage of C_SD on a trusted node and initiate storage of the C_OTP on the blockchain network.

The decryption process includes: the computing system receiving a request from the browser to request the one or more subject actions, which uses the subject data; the computing system obtaining an obfuscation of the subject data from the trusted node, wherein the obfuscation of the subject data is a function of the subject data and the OTP; the computing system obtaining multiple decryption shares from the multiple nodes that respectively store the multiple private key shares; the computing system computing the OTP from the multiple decryption shares; the computing system computing the subject data, which is a function of the obfuscation of the subject data and the OTP; and, the computing system using the subject data to execute the one or more subject actions.

In an example aspect, the method further includes the computing system deleting the subject data, the obfuscation of the subject data and the OTP from local memory of the computing system.

In another example aspect, the decryption process further includes the computing system receiving authentication data from the browser, and the computing system sends the authentication data to the trusted node to obtain obfuscation of the subject data.

In another example aspect, the decryption process further includes the computing system receiving authentication data from the browser, and the computing system sends the authentication data to the multiple nodes in the blockchain network to obtain the multiple decryption shares.

In another example aspect, each one of the multiple decryption shares is a function of the C_OTP and a given one of the multiple private key shares residing on a given one of the multiple nodes.

In another example aspect, the computing system receives at least a threshold number t of decryption key shares, where t≤N, and wherein N is the number of the multiple private key shares that correspond to the threshold public key.

In another example aspect, the computing system computes: the subject data=the obfuscation of the subject data⊕the OTP.

In another example aspect, in the decryption process, the computing system receives an encrypted form of the multiple decryption shares, and the computing system decrypts the encrypted form using a public key associated with the computing system.

In another example aspect, the OTP is a cryptographic key.

In another general example embodiment, a computing system is provided that includes one or more computing nodes that are in data communication with each other, and the computing nodes have a secure execution and secure storage environment (SESSE). The computing system is configured to execute an encryption process that includes:

generating a threshold public key and multiple private key shares correspond to the threshold public key, and the multiple private key shares are respectively stored across the multiple computing nodes in the SESSE; and

the computing system transmitting a webpage with login compute data to a web browser, the login compute data comprising the threshold public key and executable instructions for the browser to execute to generate a cipher C_OTP of a One Time Pad (OTP) and a cipher C_SD of the subject data, and for the browser to initiate storage of C_SD on a trusted node and initiate storage of the C_OTP on the blockchain network.

The computing system is configured to execute a decryption process that comprises:

receiving a request from the browser to request the one or more subject actions, which uses the subject data;

obtaining an obfuscation of the subject data from the trusted node, wherein the obfuscation of the subject data is a function of the subject data and the OTP;

obtaining multiple decryption shares via a blockchain network that is communication with the multiple computing nodes that respectively store the multiple private key shares;

computing the OTP from the multiple decryption shares; and

the computing system configured to compute the subject data, which is a function of the obfuscation of the subject data and the OTP, and then use the subject data to execute one or more subject actions.

It will be appreciated that any module or component exemplified herein that executes instructions may include or otherwise have access to computer readable media such as storage media, computer storage media, or data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Examples of computer storage media include RAM, EEPROM, flash memory or other memory technology, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by an application, module, or both. Any such computer storage media may be part of the servers or computing devices or nodes, or accessible or connectable thereto. Any application or module herein described may be implemented using computer readable/executable instructions that may be stored or otherwise held by such computer readable media.

It will be appreciated that different features of the example embodiments of the system and methods, as described herein, may be combined with each other in different ways. In other words, different devices, modules, operations, functionality and components may be used together according to other example embodiments, although not specifically stated.

The steps or operations in the flow diagrams described herein are just for example. There may be many variations to these steps or operations according to the principles described herein. For instance, the steps may be performed in a differing order, or steps may be added, deleted, or modified.

It will also be appreciated that the examples and corresponding system diagrams used herein are for illustrative purposes only. Different configurations and terminology can be used without departing from the principles expressed herein. For instance, components and modules can be added, deleted, modified, or arranged with differing connections without departing from these principles.

Although the above has been described with reference to certain specific embodiments, various modifications thereof will be apparent to those skilled in the art without departing from the scope of the claims appended hereto.

Claims

1. A computing system designated as a trusted node, comprising: a communication system that is in communication with a user device, a relying party system and a blockhain network of nodes;a memory that stores at least a threshold public key that corresponds to multiple private key shares, wherein the trusted node receives the threshold public key from the blockhain network of nodes; anda processor system that executes at least: computing a challenge using a cipher CSD of a subject data (SD) and a cipher COTP of a One Time Pad (OTP) from the user device; transmitting the challenge to the user device to initiate an authentication process; after receiving authentication data from the user device, verifying the authentication data; and, if the authentication data is verified, decrypting the cipher CSD using a trusted node's private key to output and locally store SD′ in the memory, and transmitting the cipher COTP to the blockchain network of nodes.

2. The computing system of claim 1 wherein the challenge is a Fast Identity Online (FIDO) challenge that is computed by hashing (a random value∥the cipher CSD∥the cipher COTP).

3. The computing system of claim 2 wherein the memory further stores a FIDO public key.

4. The computing system of claim 1 wherein the OTP is a cryptographic key.

5. The computing system of claim 1 wherein, after receiving and verifying a later instance of authentication data, the processor system at least further executes: retrieving the SD′ from the memory; obtaining decryption key shares that corresponds to some or all of the multiple private key shares from the blockchain network of nodes; computing the OTP using the decryption key shares; computing the SD from the OTP and SD′; encrypting the SD with the relying party system's public key to output SDRP; and initiating transmitting SDRP to the relying party system.

6. The computing system of claim 5 wherein there are N private key shares that comprise the multiple private key shares, and t number of decryption key shares are each one generated as function of a corresponding one of t private key shares and the cipher COTP, wherein t≤N.

7. The computing system of claim 5 wherein each one of the decryption key shares is initially encrypted using a public key of the trusted node, and the computing system decrypts each one of the decryption key shares using a private key of the trusted node, which corresponds to the public key of the trusted node.

8. The computing system of claim 5 wherein processor combines the decryption keys shares to compute the OTP.

9. The computing system of claim 5 wherein computing the SD from the OTP and the SD′ comprises SD=SD′⊕OTP.

10. A method for encrypting and later deleting subject data from a decentralized computing system, comprising: an encryption process that comprises: a web browser on a user device obtaining the subject data; the web browser computing a One Time Pad (OTP), an obfuscation SD′ of the subject data, a cipher COTP of the OTP using a threshold public key, and a cipher CSD of the SD′ using a public key of a trusted node; the web browser sending the CSD and the COTP to the trusted node, wherein the trusted node stores a private key corresponding to the public key of the trusted node for decrypting CSD to get the SD′; and wherein the trusted node is in communication with a blockchain network that stores multiple private keys shares corresponding to the threshold public key;a deletion process that comprises: the web browser sending a delete command to the trusted node to delete the CSD and SD′.

11. A method for a computing system to perform one or more subject actions using subject data, comprising: an encryption process that comprises: the computing system receiving a threshold public key that has been computed by a blockchain network, and where multiple private key shares correspond to the threshold public key, and the multiple private key shares are respectively distributed across multiple nodes that form part of the blockchain network;the computing system transmitting a webpage with login compute data to a web browser, the login compute data comprising the threshold public key and executable instructions for the browser to execute to generate a cipher COTP of a One Time Pad (OTP) and a cipher CSD of the subject data, and for the browser to initiate storage of CSD on a trusted node and initiate storage of the COTP on the blockchain network;a decryption process that comprises: the computing system receiving a request from the browser to request the one or more subject actions, which uses the subject data;the computing system obtaining an obfuscation of the subject data from the trusted node, wherein the obfuscation of the subject data is a function of the subject data and the OTP;the computing system obtaining multiple decryption shares from the multiple nodes that respectively store the multiple private key shares;the computing system computing the OTP from the multiple decryption shares;the computing system computing the subject data, which is a function of the obfuscation of the subject data and the OTP; andthe computing system using the subject data to execute the one or more subject actions.

12. The method of claim 11 further comprising the computing system deleting the subject data, the obfuscation of the subject data and the OTP from local memory of the computing system.

13. The method of claim 11, wherein the decryption process further comprises the computing system receiving authentication data from the browser, and the computing system sends the authentication data to the trusted node to obtain obfuscation of the subject data.

14. The method of claim 11, wherein the decryption process further comprises the computing system receiving authentication data from the browser, and the computing system sends the authentication data to the multiple nodes in the blockchain network to obtain the multiple decryption shares.

15. The method of claim 11, wherein each one of the multiple decryption shares is a function of the COTP and a given one of the multiple private key shares residing on a given one of the multiple nodes.

16. The method of claim 11, wherein the computing system receives at least a threshold number t of decryption key shares, where t≤N, and wherein N is the number of the multiple private key shares that correspond to the threshold public key.

17. The method of claim 11, wherein the computing system computes: the subject data=the obfuscation of the subject data⊕the OTP.

18. The method of claim 11, wherein in the decryption process, the computing system receives an encrypted form of the multiple decryption shares, and the computing system decrypts the encrypted form using a public key associated with the computing system.

19. The method of claim 11 wherein the OTP is a cryptographic key.

20. A computing system comprising one or more computing nodes that are in data communicate with each other, and the computing nodes have a secure execution and secure storage environment (SESSE) and wherein the computing system is configured to execute an encryption process that comprises: generating a threshold public key and multiple private key shares correspond to the threshold public key, and the multiple private key shares are respectively stored across the multiple computing nodes in the SESSE;the computing system transmitting a webpage with login compute data to a web browser, the login compute data comprising the threshold public key and executable instructions for the browser to execute to generate a cipher COTP of a One Time Pad (OTP) and a cipher CSD of the subject data, and for the browser to initiate storage of CSD on a trusted node and initiate storage of the COTP on the blockchain network;