Patent Application
20220309490
If an Application Data Sheet (ADS) has been filed on the filing date of this application, it is incorporated by reference herein. Any applications claimed on the ADS for priority under 35 U.S.C. § § 119, 120, 121, or 365(c), and any and all parent, grandparent, great-grandparent, etc. applications of such applications, are also incorporated by reference, including any priority claims made in those applications and any material incorporated by reference, to the extent such subject matter is not inconsistent herewith.
The present application is related to and/or claims the benefit of the earliest available effective filing date(s) from the following listed application(s) (the “Priority Applications”), if any, listed below (e.g., claims earliest available priority dates for other than provisional patent applications or claims benefits under 35 USC § 119(e) for provisional patent applications, for any and all parent, grandparent, great-grandparent, etc. applications of the Priority Application(s)). In addition, the present application is related to the “Related Applications,” if any, listed below.
The present invention is in the technical field of cloud computing. More particularly, the present invention is in the technical field of blockchain platform. More particularly, the present invention is in the technical field of proxy re-encryption, multiple signatures and passwordless login or authentication using split keys on a blockchain platform.
Internet is a global computer network providing a variety of information and communication facilities, consisting of interconnected networks using standardized communication protocols. Internet is not owned by a single entity and it operates without a central governing body. The same principles of distributed governance were applied to digital currencies by providing ability to perform digital transactions that existed without support from any underlying institution. The digital ledger that records the transactions in a chain using a mathematical hierarchy is called a blockchain. The following paragraphs describe different scenarios that exist today in the context of cloud computing and blockchain environments and systems.
As a background, a proxy server acts as a gateway or an intermediary server separating end users from the websites they browse. Using a proxy server helps with controlling internet usage of employees and children, bandwidth savings, improved speeds, privacy benefits, improved security and access to blocked resources by pretending to be at another geographical location. Proxy Re-Encryption is a specialized cryptographic primitive that facilitates a user to share his encrypted file with another user without decrypting the file using a specialized key called Re-Encryption Key (ReKey). Proxy controls which ciphertext of the user needs to be translated or re-encrypted. There are no mechanisms known in the industry that allow flexible user control to proxy reencryption.
The current model of cloud storage is operated through centralized authorities, which makes such a system susceptible to single point failures and permanent loss of data. Blockchain technology, initially designed as a financial ledger has attracted the attention of researchers in a wide range of applications requiring accountable computing and auditability. Blockchain enabled distributed peer-to-peer cloud storage solutions are steadily replacing its centralized counterpart. A blockchain provides multiple parties to agree upon transactions and contracts in an immutable and auditable way. Decentralized applications such as dApp providers make use of this capability to provide services that are transacted in a publicly verifiable manner. When the service provided by the dApp is not directly from the dApp owner itself but from other third parties, it brings up additional challenges. How would the end user using the dApp trust that the unknown third party service provides used by the dApp are trust worthy? The current approaches in the industry use a combination of unencrypted to cumbersome ways.
While there are policies in the industry that provide end-to-end user flexibility in securing content from authoring to distribution, none of them offer flexibility in a blockchain setup where there is no single entity on the cloud controlling access. While most systems offer securing content, they may fall short of providing an independently verifiable audit capability. In a world of increasing cyber crime and digital fraud, when something goes wrong, it requires a lot of time and effort to do digital forensic investigation. Blockchains can help reduce this burden by ensuring tamper-proof auditability is part of the enterprise workflows.
While there are means to enable shared smart contracts, a wallet is typically assigned to a single person or entity. For an entity hosting a smart wallet, there may be more than one person who has the access rights to make decisions of spending or buying on that smart wallet. In such a situation, the entity smart wallet authentication system is vulnerable if passwords are shared by two or more people. Such a vulnerability could also exist for a smart wallet associated with a household that has two or more members with access privileges.
Most of the existing and prevalent authentication methods rely on password-based authentication. Enterprises already use a single-sign on to make it easy for their employees to login to their various internal applications that each require login. Some require changing the password every few weeks or months. Some even prevent reusing the previous 10 passwords, making it extremely painful to employees. While this improves the security, it imposes unnecessary burden on the employees. There is no simple, seamless and effortless method to provide access without compromising on the level of security provided. With cybersecurity and privacy laws, enterprises have a higher need to provide a higher level security.
The present invention is systems and methods on a blockchain platform for one or more intermediaries comprising: receiving a ciphertext from a first user with condition parameters that has been encrypted with a dynamically selected encryption algorithm; receiving a re-encryption key for a second user from the first user; identifying whether the ciphertext is valid; re-encrypting the ciphertext; outputting the re-encrypted ciphertext only if the ciphertext is valid; and achieving security against chosen ciphertext attack and distributed denial-of-service attack; sending the re-encrypted ciphertext to the second user for decryption.
The system and method for intermediaries, wherein the intermediary does not have the ability to decrypt the received ciphertext.
The system and method for intermediaries, further comprising: skipping outputting the re-encrypted ciphertext based on one or more condition parameters.
The system and method for intermediaries, further comprising: sending the re-encrypted ciphertext to a second intermediary for second hop re-encryption.
A system and method of a blockchain platform for an intermediary, comprising: receiving an encrypted file from a user for storage on the blockchain platform; mapping the user to be the owner of the encrypted file; receiving one or more security policy parameters for the encrypted file from the owner; enforcing the security policy parameters for all access requests to the file on the blockchain platform; and optionally providing audit report of the encrypted file storage and access.
The system and method for intermediaries, wherein the owner is established using past read or write transactions performed directly on the blockchain platform.
The system and method for intermediaries, further comprising: dividing the encrypted file into two or more parts before sending for storage on the blockchain platform.
A system and method of a blockchain platform for a smart wallet, comprising: assigning a total number of two or more public-private key pairs for users associated with the smart wallet; allocating a threshold number for approval on transaction on the smart wallet wherein the threshold number is less than or equal to the total number; creating a group key from the total number of public-private keys and the threshold number for approvals; using the group key to register the smart wallet on the blockchain; receiving for a transaction a shared signature based on the group key from two or more users; validating and finalizing the transaction when the received signatures are more than the threshold number.
The system and method of the smart wallet, wherein: the smart wallet with the group key supports all the functions of a single user wallet.
A system and method of blockchain platform for authenticating clients, comprising of: creating a public and private key at a client device; splitting the private key into two or more parts; assigning the split private key part to two or more client devices; signing to authenticate a challenge using a partial key part at one of the client devices; sending the challenge to the remaining client devices who sequentially sign using short range wireless network connection; responding back to the challenge to login without a password.
The embodiments of this invention are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
The systems and methods on a blockchain platform for intermediaries and passwordless login allow for intermediary proxy re-encryption, independent audits, secure multiple persons controlled smart contract or smart wallet, and split-keys short-range wireless device-based and passwordless client authentication. One or more entities (or service providers) that help or manage the self-regulation on the blockchain platform are miners. A client is an end-user with two or more computing devices who initiates the requests and wants to commit transactions on the blockchain platform. An intermediary may be a blobber or a sharder who uses a computing device that processes the applications on the blockchain platform.
Different embodiments described herein include components or structures to perform the described functionality. A “component” or a “module” as used in this invention disclosure, includes a dedicated or shared processor and, typically, firmware or software modules executed by the processor. Depending upon implementation-specific or other considerations, a module can be centralized or its functionality distributed. A component or a module can include special purpose hardware, firmware, or software embodied in a computer-readable medium for execution by the processor.
In one embodiment,
The intermediary provides enforcement to parameters set with flexibility by a client including security policies on an encrypted file owned by a client. The intermediaries operate securely on the blockchain platform. The clients can delegate reencryption and use intermediaries as proxies. The intermediary can be providing proxy services, audit reporting server, enforcing multiple signatures on a smart contract or a smart wallet, provider of server-side passwordless authentication.
The service provides provide the underlying blockchain platform basic operations functionality. The blockchain platform may operate on a token-based transaction system. For example, in one embodiment, the service providers manage tokens when using a resource on the blockchain or when providing service.
Network 140 can be different wireless and wired networks available to connect different computer devices including client and server systems. In an implementation, network 140 is publicly accessible on the internet. In an implementation, network 140 is inside a secure corporate wide area network. In an implementation, network 140 allows connectivity of different systems and devices using a computer-readable medium. In an implementation, the blockchain platform allows users on the client system, the blobber, the sharder or the miner to have customized applications and operational framework.
The messaging and notification between different components can be implemented using application programming interface (API) calls, extensible markup language (“XML”) interfaces between different interfaces, Java/C++ object oriented programming or simple web-based tools. Different components may also implement authentication and encryption to keep the data and the requests secure.
The recent explosion of data volumes and demand for computing resources have prompted individuals and organizations to outsource their storage and computation needs to online data centers, such as cloud storage. While data security is enforced by standard public-key encryption mechanisms in the cloud, secure data sharing is enabled by efficient cryptographic primitives such as proxy re-encryption (PRE). PRE enables re-encryption of ciphertexts from one public key into another via a semi-trusted third party termed proxy, who does not learn any information about the underlying plaintext. A user can delegate access to his files by constructing a special key, termed as re-encryption key, using which the proxy performs the ciphertext transformation towards a legitimate delegatee. PRE systems can be classified into unidirectional and bidirectional schemes based on the direction of delegation. They can also be classified into single-hop and multi-hop schemes based on the number of re-encryptions permitted. In this work, we focus on unidirectional and single-hop PRE schemes.
Using dApp called OBox, a storage dApp allows any user to upload and share their files to their friends and families similar to many other popular storage services. However, most existing services trust the service provider and upload the content without any encryption. But Obox strives to provide zero-knowledge storage such that the third-party storage providers will not know the uploaded content. This is achieved using an efficient CCA-secure proxy re-encryption scheme, outlined in this paper. When a user shares the encrypted content with a trusted party, he provides the reencryption keys using the public key of the trusted party so that only that party is able to decrypt the content. By facilitating the associated transactions on the blockchain, this scheme provides an end-to-end transparency and security for end users to procure storage services at highly competitive prices without worrying about the reputation of the storage providers. We first propose a novel self-encryption (SE) scheme, which is much more efficient than the standard CPA secure El-Gamal encryption scheme. This work is further extended to design a CCA-secure proxy re-encryption scheme (SE-PRE) that adds re-encryption functionality to self-encryption. Our PRE design is much more efficient than the schemes known in the industry.
We give the definitions of various assumptions adopted for proving the security of the proposed schemes, the general and security model of SE and SE-PRE schemes. (1) Definition 1. Discrete Logarithm Problem (DLP): The discrete logarithm problem in a cyclic group G of order q is, given (q; P; Y) such that q is a large prime, P; Y∈ G, find a∈Z*q such that Y=aP. (2) Definition 2. Computation Diffie Hellman Problem (CDH): The Computation Diffie Hellman Problem in a cyclic group G of order q is, given (q; P; aP; bP) such that q is a large prime, P; aP; bP∈G, find Q such that Q=abP, where a∈Z*q.
The self encryption (SE) is a novel primitive that allows a user to store their files securely with minimal computation overhead. This primitive is different from the traditional public key encryption approach as encryption can be done only by the owner of the file who possess the private key related to the public key which is used for encrypting the file. It has the following algorithms: (1) Setup, (2) KeyGen, (3) Self-Encrypt, and (4) Self-Decrypt. Setup(k) algorithm is run by the trusted entity. On input of a security parameter k, the Setup algorithm will output the system parameters Params. KeyGen(Ui, Params) algorithm is run by the user Ui. This is used to generate a public and private key pair (PKi; SKi) for the user Ui. Self-Encrypt(m, tw, SKi, PKi, Params) is an encryption algorithm is run only by the user Ui. This algorithm requires the knowledge of the private key SK, corresponding to the public key PKi of user Ui. This takes as input the message m, the tag tw, the private key SKi and public key PKi of user Ui. It will output a ciphertext C which is the encryption of message m under the public key PKi and tag tw. This approach different from the traditional public key encryption where the encrypt algorithm can be run by any user. Self-Decrypt(C, SKi, PKi, Params): The decryption algorithm is run by the user Ui. On input of the ciphertext C, the private key SKi and the public key PKi of user Ui, this will output the message m if C is a valid self encryption of m under PKi, SKi and tw. Otherwise, it returns ⊥. In one embodiment, the generic model of Self Encryption algorithms consists of the algorithms described in this paragraph.
The SE-PRE is a proxy re-encryption primitive that uses a self encryption scheme as the base algorithm and provides a mechanism to delegate the self-encrypted ciphertext. The SE-PRE scheme consists of the following algorithms: 1. Setup(k):The setup algorithm takes as input a security parameter k. This will output the system parameters Params. This algorithm is run by a trusted party. 2. KeyGen(Ui, Params): The key generation algorithm generates a public and private key pair (PKi; SKi) of user Ui. This algorithm is run by a user Ui. 3. ReKeyGen(SKi; PKi; PKj; cw; Params): The re-encryption key generation algorithm takes as input a private key SKi of delegator Ui, public key PKi of delegator Ui, public key RKj of delegatee Uj and condition cw under which proxy can re-encrypt. It outputs a re-encryption key RKi->j. This is executed by the user Ui. 4. Self-Encrypt(m, tw, SKi, PKi, Params): The self encryption algorithm takes as input the message m, the tag tw, the private key SKi of user Ui and public key PKi of the user Ui. It outputs a ciphertext C which is the encryption of message m under the public key PKi, private key SKi and tag tw. This algorithm is executed by the user Ui. 5. Re-Encrypt(C; PKi; PKj; cw; RKi->j; Params): The re-encryption algorithm takes as input a self-encrypted ciphertext C, the delegator's public key PKi, the delegatee's public key PKj, the condition cw and a re-encryption key RKi->j corresponding to cw. It outputs a ciphertext D which is the encryption of same m under public key PKj of user Uj. This is run by a proxy who is provided with the re-encryption key RKi->j. 6. Self-Decrypt(C, SKi, PKi, Params): The self decryption algorithm is run by the user Ui. This will take as input the ciphertext C, the private key SKi of user Ui and public key PKi of user Ui. It will output the message m if C is a valid encryption of m under PKi and Ski of user Ui and tag tw. If C is not valid, this algorithm returns ⊥. 7. Re-Decrypt(D, SKj, Params): The re-decryption algorithm takes as input a re-encrypted ciphertext D and a private key SKj of user Uj. It outputs a message m∈M, if D is a valid re-encrypted ciphertext of message m or the error symbol ⊥ if D is invalid. This algorithm is run by the user Uj. In one embodiment, the generic model of proxy re-encryption with self-encryption (SE-PRE) includes algorithms described in this paragraph.
The security model gives details about the restrictions and oracle accesses given to the adversary. It is modelled as a game between a challenger C and an adversary A. The security of Self-Encryption (SE) scheme against chosen ciphertext attacks (IND-SE-CCA) is demonstrated as a game between an adversary A and a challenger C. The game is as follows: (1) Setup: C takes a security parameter k and runs the Setup(k) algorithm to generate the system parameters Params. It provides Params to A. C then runs KeyGen(U; Params) to generate a private and public key pair SK; PK of user U and provides PK to A. SK is kept by A. (2) Phase-1: A can adaptively issues queries to the following oracles provided by C: Self-Encrypt(m; tw) Oracle: C runs the Self-Encrypt(m, tw, SK, PK, Params) algorithm to generate the ciphertext C and returns it to A. Self-Decrypt(C, PK) Oracle: C runs the Self-Decrypt(C, SK, PK, Params) and returns the output to A. (3) Challenge: After getting sufficient training, A submits two messages m0 and m1 from M of equal length and a tag tw* to C. C picks a random bit δ∈{0; 1} and outputs the ciphertext C*=Self-Encrypt(mδ; tw*, SK; PK). (4) Phase-2: On receiving the challenge C*, A is allowed to access the various oracles provided in Phase-1 with the restrictions given below: (i). Self-Decrypt(C*) query is not allowed. (ii) Self-Encrypt(mδ; tw*) query is not allowed.(5) Guess : After getting sufficient training, A will output its guess . A wins the game if δ=δ′. In one embodiment, the security model for self-encryption includes algorithms described in this paragraph.
Security model for the SE-PRE scheme is described below. The model involves the security of original ciphertext as well as transformed ciphertext. The ciphertext that can be re-encrypted is called the original ciphertext and the output of the re-encryption is called the transformed ciphertext. Security of Original Ciphertext: The security of Proxy Re-Encryption with Self-Encryption (SE-PRE) schemes against chosen ciphertext attacks (IND-SE-PRE-CCAO) for the original ciphertext is modelled as a game between an adversary A and a challenger C. The security game is described below: (1) Setup: C takes a security parameter k and runs the Setup(k) algorithm to generate the system parameters Params. The Params is then given to A. (2) Phase-1: On receiving the system parameters, a target public key PKT and tag tw*, A is allowed to access Keygen, Self-Encrypt, Self-Decrypt, Rekey, Re-Encrypt, Re-Decrypt algorithms. A simulates the algorithms as oracles and A can adaptively issue queries to these oracles. The various oracles provided by C are: (a) Corrupted KeyGen(Ui): C runs the KeyGen(Ui; Params) to obtain the public and private key pair (PKi; SKi). C returns both SKi and PKi to A. (b) Uncorrupted KeyGen(Ui): C runs the KeyGen(Ui; Params) to obtain the public and private key pair (PKi; SKi) and returns PKi to A. SKi is not provided to A. (c) ReKeyGen(Ui; Uj): C runs the ReKeyGen(SKi; PKi; PKj; cw; Params) to obtain the re-encryption key RKi!j and returns it to A. (d) Self-Encrypt(m; tw; PKi) : C runs the Self Encrypt(m, tw, SKi, PKi, Params) to obtain the ciphertext C and returns it to A. (e) Re-Encrypt(C, PKi, PKj, cw): C runs the Re-Encrypt(C; PKi; cw; RKi!j; Params) to obtain the ciphertext D and returns it to A. Here, RKi!j is the re-encryption key from PKi to PKj under the condition cw. (f) Self-Decrypt(C, PKi): C runs the Self-Decrypt(C, SKi, PKi, Params) and returns the output to A. (g) Re-Decrypt(D, PKj): C runs the Re-Decrypt(D, SKj, PKj, Params) and returns the output to A. For the ReKey, Encrypt, Re-Encrypt, Decrypt, Re-Decrypt oracle queries it is required that public keys PKi and PKj are generated beforehand. (3) Challenge : On getting sufficient training, A will output two equal-length plaintexts m0 , m1 2 M. Here, the constraint is: PKT is generated using Uncorrupted Keygen and Rekey(PKT, PKj, cw); is not queried in Phase-1 for cw=tw*C flips a random coinf0; 1 g, and sets the challenge ciphertext C*=Self-Encrypt(m, tw*, SKT, PKT, Params). C then provide C* as challenge to A. (4) Phase-2: A can adaptively query as in Phase-1 with the following restrictions: 1. A cannot issue Corrupted KeyGen(UT) query. 2. A cannot issue Self-Decrypt(C*, PKT, tw*) query. 3. A cannot issue Re-Encrypt(C*, PKT; PKj) query on C* from PKT to PKj if PKj is Corrupted. 4. A cannot issue ReKey(PKT, PKj; cw) query if cw=tw*. 5. A cannot issue Re-Decrypt query on D*; PKj if D* is the output of Re-Encrypt(C*, PKT, PKj, cw) and cw=tw* (5) Guess : Finally, A outputs a guess δ∈{0; 1} and wins the game if δ′=δ.
The security of transformed of Proxy Re-Encryption with Self-Encryption(SE-PRE) scheme against chosen ciphertext attacks(IND-SE-PRE-CCAT) is modelled as a game between an adversary A and a challenger C. This is achieved by: (1) Setup: C takes a security parameter k and runs the Setup(k) algorithm and gives the resulting system parameters Params, a target public key PKT and tag tw* to A. (2) Phase-1: This phase is similar to the Phase-1 of IND-SE-PRE-CCAO. We do not provide Re-Encrypt oracle as we are providing all the re-encryption keys for the adversary. (3) Challenge: Once A decides Phase-1 is over, it outputs two equal-length plaintexts m0, m1∈M. C flips a random coin δ ϵ {0; 1}, and sets the challenge ciphertext as follows: (a) Compute C*=Self-Encrypt(m, tw*, SKi, PKi, Params), (PKi; SKi be the public, private key pair of user Ui and Ui can be honest or corrupt. (b) Sets D*=Re-Encrypt(C*; RKi->T) which is then sent to A. (3) Phase-2: A adaptively issues queries as in Phase-1, and C answers them as before with the following restrictions: (i). A cannot issue Corrupted KeyGen(UT) query. (ii) A cannot issue Re-Decrypt(D*; PKT) query. (4) Guess: Finally, A outputs a guess δ′∈{0; 1} and wins the game if δ′=δ.
Self-Encrypt scheme is a special kind of encryption primitive that allows a user to store file securely in cloud or any distributed storage. In this approach the owner of the file uses his/her private key to encrypt the file. This significantly reduces the computation involved in storing the file. We provide the self encryption scheme and the prove its CCA security in the random oracle model.
The SE scheme consist of the following algorithms: (1) Setup(K): Let G be an additive cyclic group of prime order q. Let P be a generator of group G. Let Δ=Sym.Encrypt, Sym.Decrypt be any symmetric key encryption scheme. We may assume that Δ is a symmetric key encryption algorithm that uses messages of block size k. Choose the hash functions,
Here lt is the size of the tag, lm is the size of the message and lk is the size of the symmetric key used by the symmetric key encryption scheme Δ. Also, l3 is dependent on the security parameter κ. Output Params=(q; G; P; H1( ); H2( ); H3( ), Δ). KeyGen(U, Params): The KeyGen algorithm generates the public and private key of the user U by performing the following steps: (i) Choose a random integer x←q* (ii) Output PK={X=Xp} and SK=<x>. Self-Encrypt(m, tw, SK, PK, Params): On input of message m, tag tw, private key SK=x of user U, public key PK=xP of user U and the public parameters Params this algorithm will generate the self encryption as follows:
Self-Decrypt(C, SKi, Params): Self decryption algorithm is used to decrypt the files that are previously encrypted by the user U using his/her private key. This algorithm does the following:
The Security Proof can be given as follows:
ϵ′≥ϵ
Proof: In this section we formally prove the security of SE scheme in the random oracle model. The IND-SE-CCA security of the SE scheme is reduced to the discrete logarithm problem(DLP). The challenger A is given with the instance of DLP (i.e. given (q, P, Y) such that q is a large prime, P, Y∈G, find a such that Y=ap.) If there exist an adversary A that can break the IND-SE-CCA security of the SE scheme, then C can make use of A to solve the discrete logarithm problem, which is assumed to be hard. Thus the existence of such adversary is not possible.
The challenger C sets the public key PK=Y (PK=aP) and the corresponding private key SK=x=a (which is not know to C). C then provides PK to A. A then has access to various algorithms of SE and the hash functions as oracles. C simulates the hash functions and the Self-Encrypt, Self-Decrypt algorithms as described below.
The Self-Encrypt and Self-Decrypt as well as Challenge Phase, Phase-2 and Guess, according to one embodiment, can be described as follows:
In one embodiment, the proxy re-encryption with self-encryption scheme is described as follows. The SE scheme is modified such a way that it allows verifiability of ciphertext by proxy during re-encryption without knowing the message. It helps in achieving CCA security of SE-PRE. This also helps in avoiding the DDOS attack being launched on Proxy's service. The proxy is equipped with a method to identify invalid ciphertext so that it will serve its functionality only to valid input. Also, the SE-PRE algorithm can be deployed in a simple and efficient manner than using the traditional PRE schemes available till date. In one embodiment, the SE-PRE uses private encryption algorithm.
The setup algorithm is described as follows:
The KeyGen and RekeyGen can be described as follows:
RekeyGen(SKi, PKi, PKj, cw, Params): This algorithm generates the re-encryption key required to translate a ciphertext of user Ui into a ciphertext of user Uj. This is run by the user Ui. The ciphertext to be re-encrypted is encrypted under the public key PKi of user Ui and with the condition cw, which are specified by user Ui. This algorithm works as follows:
Self-Encrypt(m, tw, SKi, PKi, Params): On input of message m, tag tw, private key SKi, public key PKi of user Ui and the public parameters Params
Re-Encrypt(C, PKi, PKj, cw, RKi→j, Params): This algorithm is run by the proxy which is given with the re-encryption key RKi→j by user Ui. This generates the re-encryption of a ciphertext encrypted under public key PKi of user Ui under the condition cw into a ciphertext encrypted under public key PKj of user Uj. This algorithm does not perform any complex computation and this greatly reduces the computational overhead on the entity that performs the role of a proxy. This algorithm does the following computations
Self-Decrypt(C, SKi, Params): Self-Decrypt algorithm is used to decrypt the self-encrypted ciphertext C of a user that is stored by him in the cloud. This algorithm performs the following:
Re-Decrypt(D, SKj, Params): The Re-Decrypt algorithm is used to decrypt the re-encrypted ciphertext D. This algorithm does the following:
A similar Correctness algorithm can be applied, in one embodiment, for example, as described below:
The Security Proof of the SE-PRE model can be given as below. The original ciphertext and the transformed ciphertext security in the random oracle model are consistent.
Theorem 2. If a (γ, ϵ) adversary with an advantage ϵ breaks the IND-SE-PRE-CCAO security of the SE-PRE scheme in time γ, then C can solve the discrete log problem or CDH with advantage ϵ′ where,
Here, qt is the number of queries to H6 oracle.
Proof: We formally prove the original ciphertext security IND-SE-PRE-CCAO of SE-PRE scheme in the random oracle model. The IND-SE-PRE-CCAO security of the SE-PRE scheme is reduced to the discrete algorithm problem(DLP) or the Computational Diffie Hellman Problem(CDH). The challenger is given with the instance of CDH q, P, Y=αP, YI=α2P, Z=bP) such that q is a large prime, P, Y, Y′, Z ϵ G. Now, we show that if there exists an adversary A that can break IND-SE-PRE-CCAO security of the SE-PRE scheme then C can make use of that adversary A to solve the discrete logarithm problem or the CDH problem, which are assumed to be hard. Hence the existence of such an adversary A is not possible. Now, adversary A is provided the access to various Self-Encrypt, Self-Decrypt, ReKey, Re-Encrypt, Re-Decrypt algorithms and the hash function as oracles. C provides PKT=Y AND tw* to A. The game is demonstrated below.
Phase-1. interacts with C adhering to the restrictions given in the security model IND-SE-PRE-CCAO.
submits the target condition tw* to C. C answers the queries made to various Corrupted KeyGen, Uncorrupted Keygen, Self-Encrypt, Self-Decrypt, ReKey, Re-Encrypt, Re-Decrypt oracles and the hash oracles as given below:
In one embodiment, H7 Oracle, H8 Oracle, H9 Oracle can be described, for example, as below. A person of ordinary skill in the art would understand the results are consistent.
RekeyGen Oracle, in one embodiment, can be described as follows. On input of (cw, PKi, PKj), C does the following to generate the re-encryption key.
Self-Encrypt Oracle: On input of (m, tw, PKi), C does the following:
Re-Encrypt Oracle: On input C=(C1, C2, C3, C4, C5, PKi, PKj), C does the following:
Self-Decrypt Oracle: On input C={C1, C2, C3, C4, C5, tw, PKi}. C does the following:
Re-Decrypt Oracle: On input D=(D1, D2, D3, D4, D5, tw, PKj), C does the following:
Challenge Phase: Once the training is over, provides m0, m1∈
such that (m0, tw*) or (m1, tw*) was not queried to Self-Encrypt oracle during Phase-1 and provides to C. C generates the challenge ciphertext C*=Self-Encrypt (mδ, tw*) and δ∈R {0, 1}
Phase-2 and Guess algorithms, can be described as follows, for example in one embodiment.
Phase-2: can interact with the oracles provided in Phase-1 with the following restrictions,
Guess: After getting sufficient training, output the guess δ′.
wins the game if δ=δ′. C now picks randomly γ from LH
Theorem 3. If α (t, ϵ) adversary with an advantage ϵ breaks the IND-SE-PRE-CCAT security of the SE-PRE scheme, then C can solve the Computational Diffie Hellman (CDH) problem with advantage ϵ′ where,
Here, qi is the number of queries to H6 oracle.
All the oracles are similar to that of IND-SE-PRE-CCAO. The challenge ciphertext issued will be a transformed ciphertext. has much more access than IND-SE-PRE-CCAO:
Challenge: After getting sufficient training provides two messages m0, m1 and gives to C. C generates the ciphertext as,
In Phase-2. is now allowed to access all the oracles except Re-Decrypt(D*, PKT). The rest of the proof is similar to IND-SE-PRE-CCAO. □
Experimental Analysis provides the implementation results and time taken by various algorithms in SE and SE-PRE scheme. We compare the efficiency of our CCA secure SE scheme with the traditional CPA secure El-Gamal scheme (Weaker security than CCA) and report the same in FIG. 2 Table.1. Also, we have compared our SE-PRE scheme with the only non-pairing unidirectional CCA secure PRE scheme by others available. This is reported in
From the above results it is evident that our SE encryption scheme is practical and suitable for cloud based scenarios where the user themselves store their files. Also, the SE-PRE scheme provides a very efficient approach to share encrypted files mainly in block-chain.
We have given a self encryption scheme SE based on discrete logarithm (DLP) assumption and then extended it to a Proxy Re-Encryption(SE-PRE) scheme suitable for blockchain and distributed storage. First, we formally prove the CCA security of the SE and then the security of SE-PRE scheme in the random oracle model. We have also implemented our SE-PRE scheme using GO language. From the results of our implementation, it is evident that our SE-PRE scheme is much efficient than the techniques available in literature and industry till date. This makes it more suitable for distributed applications. A person of ordinary skill in the art would understand that one can design a multi-recipient or broadcast PRE based on the self encryption approach that will provide high efficiency gain in decentralized platforms.
We provide a fast finality blockchain with cost effective solution that allows for independent verifiable audit capability along with providing end to end security for content from authoring to distribution.
In one embodiment, there is integration at the storage level for enterprises. There are cases where the enterprise prefers to have a zero-knowledge storage system. In this model, the storage of the data is done in a decentralized manner by storage providers and each has access to only a partial content that is also further secured via encryption. The end user controls the keys to the content and distribute it to users of their choice via proxy re-encryption keys.
The computing device 700 may represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and/or other appropriate computers. The computing device 700 may represent various forms of mobile devices, such as smartphones, camera phones, personal digital assistants, cellular telephones, and other similar mobile devices. The components shown here, their connections, couples, and relationships, and their functions, are meant to be exemplary only, and are not meant to limit the embodiments described and/or claimed.
The computer 705 interfaces to external systems through the communications interface 725, which may include a modem or network interface. It will be appreciated that the communications interface 725 can be considered to be part of the computing device 700 or a part of the computer 705. The communications interface 725 can be an analog modem, integrated services for digital networks (“ISDN”) modem, cable modem, token ring interface, satellite transmission interface (e.g.
“direct personal computer” also known as “direct PC”), or other interfaces for coupling a computer system to other computer systems.
The processor 720 may be, for example, a conventional microprocessor such as an Intel Pentium microprocessor or Motorola power PC microprocessor. The memory 730 is coupled to the processor 720 by a bus 750. The memory 730 can be Dynamic Random Access Memory (DRAM) and can also include Static RAM (SRAM). The bus 750 couples the processor 720 to the memory 730, also to the non-volatile storage 740, to the display controller 735, and to the I/O controller 745.
The I/O devices 710 can include a keyboard, disk drives, printers, a scanner, and other input and output devices, including a mouse or other pointing device. The display controller 735 may control in the conventional manner a display on the display device 715, which can be, for example, a cathode ray tube (CRT) or liquid crystal display (LCD). The display controller 735 and the I/O controller 745 can be implemented with conventional well-known technology.
The non-volatile storage 740 is often a magnetic hard disk, an optical disk, or another form of storage for large amounts of data. Some of this data is often written, by a direct memory access process, into memory 730 during execution of software in the computer 705. One of skill in the art will immediately recognize that the terms “machine-readable medium” or “computer-readable medium” includes any type of storage device that is accessible by the processor 720 and also encompasses a carrier wave that encodes a data signal.
The computing device 700 is one example of many possible computer systems that have different architectures. For example, personal computers based on an Intel microprocessor often have multiple buses, one of which can be an I/O bus for the peripherals and one that directly connects the processor 720 and the memory 730 (often referred to as a memory bus). The buses are connected together through bridge components that perform any necessary translation due to differing bus protocols.
Network computers are another type of computer system that can be used in conjunction with the teachings described here. Network computers do not usually include a hard disk or other mass storage, and the executable programs are loaded from a network connection into the memory 730 for execution by the processor 720. A Web TV system, which is known in the art, is also considered to be a computer system, but it may lack some of the components shown in
Though
The memory can include, by way of example but not limitation, random access memory (RAM), such as dynamic RAM (DRAM) and static RAM (SRAM). The memory can be local, remote, or distributed. As used here, the term “computer-readable storage medium” is intended to include only physical media, such as memory. As used here, a computer-readable medium is intended to include all mediums that are statutory (e.g., in the United States, under 35 U.S.C. 101), and to specifically exclude all mediums that are non-statutory in nature to the extent that the exclusion is necessary for a claim that includes the computer-readable medium to be valid. Known statutory computer-readable mediums include hardware (e.g., registers, random access memory (RAM), non-volatile (NV) storage, to name a few), but may or may not be limited to hardware.
The bus can also couple the processor to the non-volatile storage. The non-volatile storage is often a magnetic floppy or hard disk, a magnetic-optical disk, an optical disk, a read-only memory (ROM), such as a CD-ROM, EPROM, or EEPROM, a magnetic or optical card, or another form of storage for large amounts of data. Some of this data is often written, by a direct memory access process, into memory during execution of software on the computer system. The non-volatile storage can be local, remote, or distributed. The non-volatile storage is optional because systems can be created with all applicable data available in memory.
Software is typically stored in the non-volatile storage. Indeed, for large programs, it may not even be possible to store the entire program in the memory. Nevertheless, it should be understood that for software to run, if necessary, it is moved to a computer-readable location appropriate for processing, and for illustrative purposes, that location is referred to as the memory here. Even when software is moved to the memory for execution, the processor will typically make use of hardware registers to store values associated with the software, and local cache that, ideally, serves to speed up execution. As used here, a software program is assumed to be stored at an applicable known or convenient location (from non-volatile storage to hardware registers) when the software program is referred to as “implemented in a computer-readable storage medium.” A processor is considered to be “configured to execute a program” when at least one value associated with the program is stored in a register readable by the processor.
In one example of operation, a computer system can be controlled by operating system software, which is a software program that includes a file management system, such as a disk operating system. One example of operating system software with associated file management system software is the family of operating systems known as Windows® from Microsoft Corporation of Redmond, Wash., and their associated file management systems. Another example of operating system software with its associated file management system software is the Linux operating system and its associated file management system. The file management system is typically stored in the non-volatile storage and causes the processor to execute the various acts required by the operating system to input and output data and to store data in the memory, including storing files on the non-volatile storage.
The bus can also couple the processor to the interface. The interface can include one or more input and/or output (I/O) devices. The I/O devices can include, by way of example but not limitation, a keyboard, a mouse or other pointing device, disk drives, printers, a scanner, and other I/O devices, including a display device. The display device can include, by way of example but not limitation, a cathode ray tube (CRT), liquid crystal display (LCD), or some other applicable known or convenient display device. The interface can include one or more of a modem or network interface. It will be appreciated that a modem or network interface can be considered to be part of the computer system. The interface can include an analog modem, isdn modem, cable modem, token ring interface, satellite transmission interface (e.g. “direct PC”), or other interfaces for coupling a computer system to other computer systems. Interfaces enable computer systems and other devices to be coupled together in a network.
Several components described here, including clients, servers, and engines, can be compatible with or implemented using a cloud-based computing system. As used here, a cloud-based computing system is a system that provides computing resources, software, and/or information to client systems by maintaining centralized services and resources that the client systems can access over a communications interface, such as a network. The cloud-based computing system can involve a subscription for services or use a utility pricing model. Users can access the protocols of the cloud-based computing system through a web browser or other container application located on their client system.
The invention disclosure describes techniques that those of skill in the art can implement in numerous ways. For instance, those of skill in the art can implement the techniques described here using a process, an apparatus, a system, a composition of matter, a computer program product embodied on a computer-readable storage medium, and/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor. Unless stated otherwise, a component such as a processor or a memory described as being configured to perform a task may be implemented as a general component that is configured to perform the task at a given time or a specific component that is manufactured to perform the task. As used here, the term ‘processor’ refers to one or more devices, circuits, and/or processing cores configured to process data, such as computer program instructions.
A detailed description of one or more implementations of the invention is provided here along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such implementations, but the invention is not limited to any implementation. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.
Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
Techniques described here relate to apparatus for performing the operations. The apparatus can be specially constructed for the required purposes, or it can comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer-readable storage medium, such as, but is not limited to, read-only memories (ROMs), random access memories (RAMS), EPROMs, EEPROMs, magnetic or optical cards, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. Although the foregoing implementations have been described in some detail for purposes of clarity of understanding, implementations are not necessarily limited to the details provided.
In one embodiment, a smart wallet is made of Modern Portfolio Theory (MPT) wallet. Users can add T-of-N multi-sig capabilities to standard MPT wallets. Votes to send tokens must arrive one-per-transaction and are stored in public blockchain state. A group signature on a description of transfer is recovered from the votes. Validation of the signature happens outside of the smart contract. State may be pruned safely, allowing amnesiac property of miners is preserved without loss of security.
In one embodiment, a single, shared smart contract collects votes for proposals to send tokens between wallets. In one embodiment, the wallet associated with the smart contract is not used and multiple-signatures (“multi-sig”) are sent directly on standard modern portfolio theory (“MPT”) based wallets. This removes the support for non-token-transfer operations guarded by a multi-sig, meaning in one embodiment, this design will not support data transactions or arbitrary smart contract calls. The policy of multi-sig is enforced automatically. In one embodiment, threshold cryptography will be utilized to create signatures for the exchange/corporate MPT wallet. In one embodiment, Shamir's secret sharing is used as a simple way to create keys capable of this feature. New transactions will not be dynamically created inside the smart contract.
The benefits of implementing multiple signatures on a smart wallet include creation of multi-signature wallets, voting for transfers and pruning of old proposed transfers and votes. Any implementation has to consider the following before finalizing transactions on the smart wallet: querying whether multi-signature capabilities already exist; updating the list of signers and/or required number of votes; deletion of multi-signature capabilities for a wallet.
Allow creation of a multiple signature wallet context for a wallet. The transaction containing this request must be send from the target wallet's client. It must include a list of voter public keys and the minimum number of votes that must be collected before funds may be sent from the wallet. If a wallet with this multi-sig wallet context already exists, it is an error. Don't disallow normal TxnTypeSend from a wallet for which a multi-sig wallet context exists. Allow creation of multi-sig transfer votes for a wallet. The votes must contain a proposal ID value to differentiate between multiple transfers of the same value to the same client. Different multi-sig wallet contexts may have proposals with the same ID. When a vote is sent with an ID not currently in the database, a proposal object is created in state. A vote must contain an inner signature produced by the vote's sender. This signature is on a message similar to the following:
Add chaincore/chain/state_context.go#AddSignedTransfer( ) call that is similar to AddTransfer( ) but which also takes a signature and may send from any wallet. This AddSignedTransfer call reconstructs the message above and validates the passed signature against it and from the wallet's public key. If the signature is invalid, the call fails and the transfer is rejected.
When the required number of votes are collected on a multi-sig send proposal, it is executed. If the wallet does not have enough balance to complete the transaction, the vote transaction succeeds (so as to eligible to be included in a block) but does not count the vote toward the proposal and a transaction output message that there aren't enough funds. Because the vote is not counted, it allows the last voter to try again later. If the transfer succeeds, the proposal object that was allocated for this transfer is not deleted yet. This allows us to tell additional votes that come in soon after that their proposal was already executed.
Multi-sig proposals are assigned an expiration date by the smart contract. When the expiration date is past, a proposal is eligible for deletion.
When a vote comes in, the blockchain checks the oldest proposal it knows of (across all multi-sig wallets, not just the one being voted on) to see if it is expired. If so, it is deleted (“pruned”) and the ID value that the proposal held is free to be re-used by the originating multi-sig wallet. Only one proposal may be deleted per incoming vote to protect against any single vote transaction performing a large amount of IO. This will help to future-proof this multi-sig wallet scheme from any IO quota policy the blockchain might decide to one day start implementing.
If a vote comes in for a proposal that is past expiry but which has not been pruned yet, the proposal is immediately deleted (“pruned”) and a new proposal with the same ID is instantiated. This presents a consistent behavior between an expired-deleted and an expired-not-yet-deleted proposal.
In one embodiment, multiple signature smart wallet is implemented as follows. First a user needs to do threshold signature setup. As part of this setup, the user creates a desired number of t-of-n private/public keys. Then the user recovers the group private/public key. This group key is used to register a group wallet on the blockchain and the token balance is stored against this group client. Whenever the tokens in this group wallet needs to be withdrawn, individual clients submit their share of the transaction as a regular blockchain transaction. These individual transactions contains a shared signature for a given transaction payload which authorizes transfer of certain amount of tokens to a specific client for a given context. When enough such signatures (t) are recovered, then the group signature is recovered. This group signature is presented to withdraw the funds. The blockchain fund transfer API doesn't need to be aware of all this additional setup. As far as it is concerned, it is transferring the funds based on a signature of a wallet. This provides a secure multi-sig capability.
In one embodiment, the use of group key and receipt of signatures is implemented without smart contract voting. The scheme seamlessly achieves all the functions of a single signature wallet. It can be replace a single signature wallet without any additional changes required to API or blockchain platform environment.
Blockchain platform with a novel split-key1 mechanism is used to provide more secure authentication and password-less login. Interestingly the same scheme can also be used in an enterprise SSO setting by replacing the traditional password based login with a more secure authentication using only digital keys and just using the laptop/desktop and mobile app and no special hardware.
The value proposition for this approach is a higher security and an easier password-less login flow, without the need for hardware devices, fingerprint, or face recognition schemes as this approach has a built-in higher level of security. The latter methods can still be added as an add-on to further bolster the security of the login process.
Enterprises already use SSO to make it easy for their employees to login to their various internal application that each require login. Existing solutions rely on password based authentication. And some require changing the password every few weeks or months. Some even prevent reusing the previous 10 passwords, making it extremely painful to employees. While this improves the security, it imposes unnecessary burden on the employees.
In one embodiment, a novel split key based signature scheme is used that requires two separate signatures from two split keys (of the primary key) to create the combined signature. These partial signatures are constructed on two separate devices to enhance the security. Compromise of one key doesn't result in the compromise of the primary key. This technique can be used to provide authentication service to existing SSO servers.
Below is the outline of the first-time registration and subsequent login processes. Registration: 1) User accesses the SSO login page in the browser. 2) User is presented with the familiar login form. 3) User does the login by entering username and password. 4) At this time, the SSO server will work with blockchain IDP server and identify the user needs to register into the split key IDP service. 5) Blockchain IDP provides a session ID and a challenge tracking that the SSO server sends to the User. 6) User's browser redirects and opens a desktop app. 7) The desktop app has the ability to connect to a mobile device via a short range wireless connection, for example, a bluetooth protocol or near field communications protocols. 8) The desktop will sign the challenge partial key and send the signature to the mobile. 9) The mobile will sign the challenge with its own partial key, combine the signatures and respond back to the blockchain IDP server along with the primary public key. 10) The blockchain IDP server confirms that the signature is valid with respect to the public key and registers the phone and the public key against the user. 11) Blockchain IDP server responds to SSO of the successful registration. 12) SSO server redirects the user to the application.
Password-less Login: 1) User accesses the SSO login page in the browser. 2) User is presented with the familiar login form. In addition, there will be a link to use the split key based authentication (note that this extra step of clicking the link can be bypassed if there is a cookie information from a prior session that user is already setup for split key authentication). 3) SSO server works with blockchain IDP server and provides a challenge. This will happen either directly as a response to step 1 or after user explicitly clicks the link to use split key authentication in step 2 (that depends on the cookie information). 4) Browser redirects and opens the desktop app. 5) The flow from here is same as the Registration process from step 7.
Note that the desktop app is only required at this time because of the local communication with the mobile phone. As Web Bluetooth API becomes widely adopted, the desktop app can be completely eliminated and the communication will happen directly between the browser and the mobile phone.
Also, in the above description, the SSO server and blockchain IDP service are mentioned as two separate servers. However, it is also possible to make blockchain IDP service available as a pluggable module into existing SSO solutions.
In broad embodiment, the invention is systems and methods of a blockchain platform for intermediaries to provide different services including proxy re-encryption, independent audit services, multi-sig smart wallet and split-key based passwordless login.
A number of embodiments have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the claimed invention. In addition, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Accordingly, other embodiments are within the scope of the following claims.
It may be appreciated that the various systems, methods, and apparatus disclosed herein may be embodied in a machine-readable medium and/or a machine accessible medium compatible with a data processing system (e.g., a computer system), and/or may be performed in any order.
The structures and modules in the figures may be shown as distinct and communicating with only a few specific structures and not others. The structures may be merged with each other, may perform overlapping functions, and may communicate with other structures not shown to be connected in the figures.
The above-described functions and components may be comprised of instructions that are stored on a storage medium such as a computer readable medium. The instructions may be retrieved and executed by a processor. Some examples of instructions are software, program code, and firmware. Some examples of storage medium are memory devices, tapes, disks, integrated circuits, and servers. The instructions are operational when executed by the processor to direct the processor to operate in accord with some embodiments. Those skilled in the art are familiar with instructions, processor(s), and storage medium.
While the foregoing written description of the invention enables one of ordinary skill to make and use what is considered presently to be the best mode thereof, those of ordinary skill will understand and appreciate the existence of variations, combinations, and equivalents of the specific embodiment, method, and examples herein. The invention should therefore not be limited by the above described embodiment, method, and examples, but by all embodiments and methods within the scope and spirit of the invention.
A detailed description of one or more implementations of the invention is provided here along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such implementations, but the invention is not limited to any implementation. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.
The structures and modules in the figures may be shown as distinct and communicating with only a few specific structures and not others. The structures may be merged with each other, may perform overlapping functions, and may communicate with other structures not shown to be connected in the figures.
This application is related to co-pending patent application Ser. No. 16/247,994 filed on Jan. 15, 2019.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16369656 | Mar 2019 | US |
| Child | 17228152 | US |
