US20200313856A1 - Systems and methods of blockchain platform for intermediaries and passwordless login - Google Patents

Abstract

The systems and methods on a blockchain platform for one or more intermediaries for services including proxy re-encryption, independent audit, multiple-signatures based smart wallet associated with a smart contract and split-key authentication to achieve secure passwordless login. Proxy re-encryption by receiving a ciphertext from a first user with condition parameters that has been encrypted with a dynamically selected encryption algorithm. Audit service receiving an encrypted file from a user for storage on the blockchain platform; 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. A smart wallet with a group key using multiple signatures based on receipt of a threshold number of signatures. Split-key authentication by splitting the private key into two or more parts; and assigning the split private key part to two or more client devices.

Description

• 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.
CROSS-REFERENCE TO RELATED APPLICATIONS
• 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.
RELATED APPLICATIONS
• This application is related to co-pending patent application Ser. No. 16/247,994 filed on Jan. 15, 2019.
FIELD OF THE INVENTION
• 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.
BACKGROUND
• 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.
SUMMARY OF THE INVENTION
• 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.
BRIEF DESCRIPTION OF THE DRAWINGS
• 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:
• FIG. 1 shows a diagram illustrating an example of a system and method on a blockchain platform with intermediaries, clients and service providers.
• FIG. 2 shows Table 1 and Table 2. Table 1 discloses Performance Evaluation of the CPA secure El-Gamal Encryption Scheme and disclosed Self-Encryption Scheme. Table 2 discloses Performance Evaluation of the efficient pairing-free unidirectional PRE scheme due to Chow et al., and disclosed Scheme.
• FIG. 3 is an exploded view of an intermediary computing system illustrating different modules and functions, according to one embodiment.
• FIG. 4 discloses an encrypted file access with independent audit service provider work flow illustrating different modules and functions, according to one embodiment.
• FIG. 5 discloses messaging work flow to access an encrypted file and audit reporting on a blockchain platform with server-side integration, according to one embodiment.
• FIG. 6 discloses messaging work flow to access an encrypted file and audit reporting on a blockchain platform with server and client-side integration, according to one embodiment.
• FIG. 7 is a schematic diagram of exemplary computing devices that can be used to implement the methods and systems disclosed herein, according to one embodiment.
• FIG. 8 discloses messaging flow for multiple signatures smart contract implementation, according to one embodiment.
• FIG. 9 discloses messaging flow for multiple signatures smart wallet implementation, according to one embodiment.
• FIG. 10 discloses messaging flow for password less login using split-keys, according to one embodiment.
• FIG. 11 is a flow chart showing different method steps in implementing password less login using split-keys, according to one embodiment.
DETAILED DESCRIPTION OF THE INVENTION
• 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,FIG. 1 depicts a diagram100 illustrating an example on a blockchain platform with intermediaries. In the example ofFIG. 1, the environment includes a first consumer or client system110-1 through an nth client system110-nwherein each client owns two ormore devices1,2,3, . . . n,network140, intermediary system120-1 through an nth intermediary system120-nand a service provider130-1 through an nth system130-n. In an implementation, the client system110 includes components related to requesting services from the blockchain platform. In one implementation, the client system110 requests and uses a storage application for storage, read or write. The client may use a multiple signatures or group-based smart-contract or smart-wallet on the blockchain platform. The client may use passwordless authentication using split keys that are associated with two or more client devices. The client may request audit reporting for any of its transactions including storage read/write requests or adding/deleting of tokens from a smart contract or smart wallet.
• 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.
• Network140 can be different wireless and wired networks available to connect different computer devices including client and server systems. In an implementation,network140 is publicly accessible on the internet. In an implementation,network140 is inside a secure corporate wide area network. In an implementation,network140 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.
• I. Sharing of Encrypted Files on Blockchain Using Pre
• 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 0Box, 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 0box 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*_qsuch 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 (PK_i; SK_i) for the user Ui. Self-Encrypt(m, t_w, SK_i, PK_i, Params) is an encryption algorithm is run only by the user Ui. This algorithm requires the knowledge of the private key SK_icorresponding to the public key PK_iof user Ui. This takes as input the message m, the tag t_w, the private key SK_iand public key PK_iof user Ui. It will output a ciphertext C which is the encryption of message m under the public key PK_iand tag t_w. This approach different from the traditional public key encryption where the encrypt algorithm can be run by any user. Self-Decrypt(C, SK_i, PK_i, Params): The decryption algorithm is run by the user U. On input of the ciphertext C, the private key SK_iand the public key PK_iof user U_i, this will output the message m if C is a valid self encryption of m under PK_i, SK_iand t_w. 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 (PK_i; SK_i) of user Ui. This algorithm is run by a user Ui. 3. ReKeyGen(SK_i; PK_i; PK_j; c_w; Params): The re-encryption key generation algorithm takes as input a private key SK_iof delegator U_i, public key PK_iof delegator U_i, public key PK_jof delegatee U_jand condition c_wunder which proxy can re-encrypt. It outputs a re-encryption key RK_i->j. This is executed by the user U. 4. Self-Encrypt(m, t_w, SK_i, PK_i, Params): The self encryption algorithm takes as input the message m, the tag t_w, the private key SK_iof user U_iand public key PK_iof the user U. It outputs a ciphertext C which is the encryption of message m under the public key PK_i, private key SK_iand tag t_w. This algorithm is executed by the user U_i. 5. Re-Encrypt(C; PK_i; PK_j; c_w; RK_i->j; Params): The re-encryption algorithm takes as input a self-encrypted ciphertext C, the delegator's public key PK_i, the delegatee's public key PK_j, the condition c_wand a re-encryption key RK_i->jcorresponding to c_w. It outputs a ciphertext D which is the encryption of same m under public key PK_jof user U_j. This is run by a proxy who is provided with the re-encryption key RK_i->j. 6. Self-Decrypt(C, SK_i, PK_i, Params): The self decryption algorithm is run by the user U. This will take as input the ciphertext C, the private key SK_iof user U_iand public key PK_iof user U. It will output the message m if C is a valid encryption of m under PK_iand Sk_iof user U_iand tag t_w. If C is not valid, this algorithm returns ⊥. 7. Re-Decrypt(D, SK_j, Params): The re-decryption algorithm takes as input a re-encrypted ciphertext D and a private key SK_jof user U_j. 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 U_j. 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; t_w) Oracle: C runs the Self-Encrypt(m, t_w, 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 t_w* to C. C picks a random bit δϵ{0; 1} and outputs the ciphertext C*=Self-Encrypt(m_δ; t_w*, 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_δ; t_w*) 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 PK_Tand tag t_w*, 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(U_i): C runs the KeyGen(U_i; Params) to obtain the public and private key pair (PK_i; SK_i). C returns both SK_iand PK_ito A. (b) Uncorrupted KeyGen(U_i): C runs the KeyGen(U_i; Params) to obtain the public and private key pair (PK_i; SK_i) and returns PK_ito A. SK_iis not provided to A. (c) ReKeyGen(U_i;U_j): C runs the ReKeyGen(SK_i; PK_i; PK_j; c_w; Params) to obtain the re-encryption key RK_i!_jand returns it to A. (d) Self-Encrypt(m; t_w; PK_i): C runs the Self

  

  Encrypt(m, t_w, SK_i, PK_i, Params) to obtain the ciphertext C and returns it to A. (e) Re-Encrypt(C, PK_i, PK_j, c_w): C runs the Re-Encrypt(C; PK_i; c_w; RK_i!_j; Params) to obtain the ciphertext D and returns it to A. Here, RK_i!_jis the re-encryption key from PK_ito PK_junder the condition c_w. (f) Self-Decrypt(C, PK_i): C runs the Self-Decrypt(C, SK_i, PK_i, Params) and returns the output to A. (g) Re-Decrypt(D, PK_j): C runs the Re-Decrypt(D, SK_j, PK_j, Params) and returns the output to A. For the ReKey, Encrypt, Re-Encrypt, Decrypt, Re-Decrypt oracle queries it is required that public keys PK_iand PK_jare generated beforehand. (3) Challenge: On getting sufficient training, A will output two equal-length plaintexts m0, m1 2 M. Here, the constraint is: PK_Tis generated using Uncorrupted Keygen and Rekey(PK_T, PK_j, c_w); is not queried in Phase-1 for c_w=t_w* C flips a random coinf0; 1 g, and sets the challenge ciphertext C*=Self-Encrypt(m, t_w*, SK_T, PK_T, 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(U_T) query. 2. A cannot issue Self-Decrypt(C*, PKT, t_w*) query. 3. A cannot issue Re-Encrypt(C*, PK_T; PK_j) query on C* from PK_Tto PK_jif PK_jis Corrupted. 4. A cannot issue ReKey(PK_T, PK_j; c_w) query if c_w=t_w*. 5. A cannot issue Re-Decrypt query on D*; PK_jif D* is the output of Re-Encrypt(C*,PK_T, PK_j, c_w) and c_w=t_w* (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 PK_Tand tag t_w* to A. (2) Phase-1: This phase is similar to the Phase-1 of IND-SE-PRE-CCA_O. 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 m₀,m₁ϵM. C flips a random coin δ ϵ{0; 1}, and sets the challenge ciphertext as follows: (a) Compute C*=Self-Encrypt(m, t_w*, SK_i, PK_i, Params), (PK_i; SK_ibe the public, private key pair of user U_iand U_ican be honest or corrupt. (b) Sets D*=Re-Encrypt(C*;RK_i->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(U_T) query. (ii) A cannot issue Re-Decrypt(D*; PK_T) 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 A is a symmetric key encryption algorithm that uses messages of block size k. Choose the hash functions,
• 
  H₁:{0,1}^lt×Z_q*→Z_q
• 
  H₂: Z_q*→{0,1}^lx
• 
  H₃: {0,1}^lm×G→{0,1}^l3
• Here l_tis the size of the tag, l_m, is the size of the message and l_kis the size of the symmetric key used by the symmetric key encryption scheme Δ. Also, l₃is dependent on the security parameter κ. Output Params=(q; G; P; H₁( ); H₂( ); H₃( ), Δ). 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

  

  Z_q* (ii) Output PK={X=Xp} and SK=<x>. Self-Encrypt(m, t_w, SK, PK, Params): On input of message m, tag t_w, 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:

• • Choose random t ∈   q*
  • Set ht= H1(tw, x).
  • Set C1= t + ht.
  • Compute Key = H2(t)
  • C2 = {Ĉi}(for i=1 to l) and Ĉi=Sym.Encrypt (Mi,Key) for all i = 1 to l, l is
  the number of blocks. Assume that m = M1M2... Mlwhere |Mi|=k
  and k is the block size of Δ.
  • C3= H3(m, t)
  • Output the ciphertext C =   C1, C2, C3, tw   .

• Self-Decrypt(C, SK_i, 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:

• 		• ht= H1(tw, SKi).
  		• t = C1− ht
  		• Key = H2(t)
  		• Computer Mi=Sym.Decrypt(Ĉi, Key) for all i=1 to l and
  		construct m = M1M2... Ml.
  		• If C3   H3(m, t) then, output m. Else, Output ⊥.

• $\mathrm{Correctness}\mathrm{of}t\text{:}$$\begin{array}{c}\mathrm{RHS}=C_1-h_t\\ =\left(t+h_t\right)-h_t\\ =t;\\ =\mathrm{LHS}\end{array}$
• The Security Proof can be given as follows:

• 	Theroem 1. If there exist a (γ, ϵ) adversary    with an
  	advantage ϵ that can break theIND-SE-CCA security of
  	the SE scheme, then   can solve the discrete log problem
  	with advantage ϵ′ where,

  ϵ′ ≥ ϵ

• 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.

• Phase-1 :   is given to access all the oracles as defined in the security model IND-SE-CCA.
  Here it should be noted that   which does not have the knowledge of private key SK = α
  provides the functionalities Self-Encrypt, Self-Decrypt algorithm.
  • The hash functions involved in the SE scheme are simulated as random oracles. To
  provide consistent output,   maintains the lists LH1, LH2, and LH3 corresponding to
  the hash function H1, H2, and H3involved in the SE scheme.
  * H1Oracle: When a query with input (tw, x) is made, the tuple (tw, x, ht) is
  retrieved from LH1 and htis returned, if (tw, x) is already there in LH1 list.
  Otherwise,   does the following:
  • If xP = Y, then abort. This is because   obtains the solution to DLP i.e x = α.
  • Pick ht∈   .
  • If htis already present in LH1 list, go to previous step.
  • Store (tw, x, ht) in LH1 list and output ht.
  * H2Oracle: When a query with t is made,   the tuple (t, Key) from LH2list is
  retrieved and will return Key, if (t) is already present in LH2 list. Otherwise,
  does the following:
  • Pick Key ∈ {0,1}lk.
  • If Key is already present in LH2 list, go to previous step.
  • Store (t, Key) in LH2 list and return Key.
  * H3Oracle: When a query with input (m, T) is made,   retrieves the tuple (m, T, α)
  from LH3 list and returns α, if (m, T) is already present in LH3 list. Otherwise,
  does the following;
  • Pick α ∈ {0,1}l3,
  • If α is already present in LH3 list, go to previous step.
  •Store   m, T, α   in LH3 list and return α.

• The Self-Encrypt and Self-Decrypt as well as Challenge Phase, Phase-2 and Guess, according to one embodiment, can be described as follows:

• Self-Encrypt Oracle : When a Self-Encrypt query is made with (m, tw) as input,
  does the following:
  * Choose random t ∈   q*
  * Set ht= H1(tw, x).
  * Set C1= t + ht.
  * Compute Key =H2(t)
  * C2= {Ĉi}(for i=1 to l) and Ĉi=Sym.Encrypt (Mi, Key) for all i = 1 to l, l is the
  number of blocks. Assume the m = M1M2... Miwhere |Mi| = k and k is the
  block size of Δ.
  * C3= H3(m, t)
  * Output the ciphertext C =   C1, C2, C3, tw   .
  * Output the self-encrypted ciphertext C to   .
  Self-Decrypt Oracle: When a Self-Decrypt query is made with C =   C1, C2, C3, tw
  as input,   performs the following:
  * If C is its LEncryptlist, pick m corresponding to C from the tuple   C, m   in
  LEncryptlist and output m.
  * If (tw, —) is present in LH1 list then, retrieve htcorresponding to (tw, —) from
  LH1 list. Else, it returns ⊥
  * T = C1− ht
  * Key = H2(t)
  * Compute Mi= Sym.Decrypt(Ĉi, Key) for all i=1 to l and construct m = M1, M2... Ml.
  * If C3   H3(m, t) then, output m. Else, it output ⊥.
  Challenge Phase: After the first phase of training is over.   provides m0, m1∈   , tw*
  such that (m0, tw*) or (m1, tw*) was not queried to Self-Encrypt oracle during Phase-1
  and provides to   ,   now generates the challenge ciphertext C* = Self-Encrypt(mδ, tw*)
  and δ ∈R{0,1}
  Phase-2:   can interact with all the oracles as in Phase-1 but with the following restrictions.
  •   cannot make the query Self-Decrypt(C*)
  •   cannot make the query Self-Encrypt(mδ, tw*), δ ∈ {0,1}
  Guess : Once Phase-2 is over,   output its guess δ′.   wins the game if δ = δ′.

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

• Setup(κ):
  • Let   be an additive cyclic group of prime order q. Let P be a generator of group    .
  • Let Δ =   Sym.Encrypt, Sym.Decrypt   be any symmetric key encryption scheme. We
  may assume that Δ is a symmetric encryption algorithm wrking on block size k.
  • Choose the hash functions,

  	H0: {0,1}lc → {0,1}l0
  	H1: {0,1}lL ×   q* ×   →   q*
  	H2:   q*→ {0,1}lt
  	H3: {0,1}lm ×   q* → {0,1}l0
  	H4:   q* ×{0,1}(ln+lc+l0) ×   →   q*
  	H5: {0,1}lt ×   q* ×   → {0,1}l0
  	H6: {0,1}lw ×   ×   ×   →   q*
  	H7:   q* ×   →   q*
  	H8:   ×   → {0,1}(lw+ly)
  	H9: {0,1}lu ×   q* →   q*
  	Hκ : {0,1}* →{0,1}lc

  Here ltis the size of the tag, lmis the size of the message, lcis the size of the ciphertext, lpis

  κ and lLis size of the symmetric key used in the encryption scheme Δ. Also, lw, lu, l0,

  l3and l5are dependent on the security paramerter κ.

  Output Params =   q, P,G, P, Hi( )(for i=0 to 9), Hc( ), Δ

• The KeyGen and RekeyGen can be described as follows:

• 	KeyGen(Ui, Params): The KeyGen algorithm generates the public
  	and private key of the use Ui, by performing the following:
  	• Choose a random integer xi     q*
  	• Output PKi=   Xi= xiP) and SK = (xi   ,

• RekeyGen(SK_i, PK_i, PK_i, c_w, Params): This algorithm generates the re-encryption key required to translate a ciphertext of user U_iinto a ciphertext of user U_j. This is run by the user U_i. The ciphertext to be re-encrypted is encrypted under the public key PK_iof user U_iand with the condition c_w, which are specified by user U_i. This algorithm works as follows:

• 		• Choose ω   ∈ {0,1}tw
  		• Compute hc= H1(Cw, xi, Xi) ∈   q*
  		• Compute r = H6(ω, xiXj, Xi, Xj) ∈   q*
  		• Compute s = H7(r, Xj) ∈   q*
  		• Compute γ = rXj
  		• Compute the re-encryption key RKi→j =
  		R1, R2, R3, R4, R5, R6   where,

  			R1= s − hc∈   q*
  			R2= rP ∈
  			R3= (ω||Xi) ⊕ H8(γ, Xj) ∈ {0,1}lw+ly
  			R4= H6(ω, γ, Xi, Xj) ∈   q*
  			R5= H5(tw, xi, Xi) ∈ {0,1}ln
  			R6= H0(tw)

  		• Output the re-encryption key RKi→j =
  		R1, R2, R3, R4, R5, R6

• 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

• • Choose random ω ∈   q*
  • Set ht= H1(tw, xi, Xi) ∈   q*
  • Compute C1= t + ht.
  • Compute Key = H2(t)
  • Comute C2= {Ĉ1}(for i=1 to l) and Ĉi=Sym.Encrypt (Mi,Key)
  for all i = 1 to l. l is the number of blocks. Assume that m =
  M1M2... Mlwhere |Mi|=k and k is the block size of Δ.
  • Set C3= H3(m, t)
  • Find α =H5(tw, xi, Xi) ∈ {0.1}l5
  • C4= H4(C1, C2, C3, α, X)
  • Set C3= H0(tw)
  • Output the ciphertext C =   C1, Hc(C2), C3, C4, C5)   ,

• Re-Encrypt(C, PK_i, PK_j, c_w, RK_i→j, Params): This algorithm is run by the proxy which is given with the re-encryption key RK_i→jby user U_i. This generates the re-encryption of a ciphertext encrypted under public key PK_iof user U_iunder the condition c_winto a ciphertext encrypted under public key PK_jof user U_j. 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

• 	• If C4≠ H4(C1, Hc(C2), C3, R5, tw, X) OR C5≠ R6, then it returns ⊥
  	• Set D2= C2, D3= C3, D4= R2, D5= R3
  	• Choose u ∈ {0,1}lu
  	• Compute β =H9(u, R4) ∈   q*
  	• Compute D1 = β(C1+ R1) ∈   q*
  	• Set D6= u
  	• Output the re-encrypted ciphertext D =   D1, D2, D3, D4, D5, D6

• Self-Decrypt(C, SK_i, 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:

• 	• Find α = H5(tw, xi, Xi) ∈ {0,1}l3
  	• If C4≠ H4(C1, C2, C3, α, tw, X), then it returns ⊥
  	• ht= H1(tw, SKi).
  	• t = C1− ht
  	• Key = H2(t)
  	• Compute M1=Sym.Decrypt(Ĉ1,Key) for all i=1 to l and construct
  	m = M1M2... Ml.
  	• If C3   H3(m, t) then, output m. Else, Output ⊥.

• $\mathrm{Correctness}\mathrm{of}t\text{:}$$\begin{array}{c}\mathrm{RHS}=C_1-h_t\\ =\left(t+h_t\right)-h_t\\ =t\\ =\mathrm{LHS}\end{array}$
• Re-Decrypt(D, SK_j, Params): The Re-Decrypt algorithm is used to decrypt the re-encrypted ciphertext D. This algorithm does the following:

• 	• Compute γ =xjD4
  	• Compute ω||Xi= D5⊕ H8(γ, Xj)
  	• Compute r = H6(ω, xjXi, Xi, Xj) ∈   q*
  	• Compute s = H7(r, Xj) ∈   q*
  	• ρ =H6(ω, γ, Xi, Xj) ∈   q*
  	• Compute β = H9(D6, ρ) ∈   q*
  	• Compute t = β−1 (D1) − s
  	• Find Key = H2(t)
  	• Compute Mi=Sym.Decrypt(Ĉi, Key) for all i=1 to l and construct
  	m = M1, M2... Ml,
  	• If (C3   H3(m, t)) then, output m. Else, it returns ⊥.

• A similar Correctness algorithm can be applied, in one embodiment, for example, as described below:
• $\mathrm{Correctness}\mathrm{of}T\text{:}$$\begin{array}{c}\mathrm{RHS}={\beta }^{-1}D_1-s\\ ={\beta }^{-1}\left[\beta \left({\mathrm{<figure-callout\; label="C"\; filenames="US20200313856A1-20201001-D00002.png,US20200313856A1-20201001-D00005.png"\; state="\{\{state\}\}">C</figure-callout>}}_1+R_1\right)\right]-s\\ =\left[\left(t+h_t\right)+\left(s-h_c\right)\right]-s;\mathrm{Here}h_t=h_c\\ =\left(t+s\right)-s\\ =t\\ =\mathrm{LHS}\end{array}$
• 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.
• Security of the Original Ciphertext

• Theorem 2: if a (γ, ϵ) adversary  with an advantange ϵ breaks the IND-
  SE-PRE-CCAO security of the SE-PRE scheme in time γ, then  can
  solve the discrete log problem or CDH with advantage ϵ′ where,
  ${ϵ}^{\prime }\ge \frac{1}{q_t}ϵ$
  Here, qtis the number of queries to H   oracle.
  indicates data missing or illegible when filed

• Proof: We formally prove the original ciphertext security IND-SE-PRE-CCA_Oof SE-PRE scheme in the random oracle model. The IND-SE-PRE-CCA_Osecurity 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=aP, Y^|=a²p, Z=bP) such that q is a large prime, P, Y, Y′, Z E G. Now, we show that if there exists an adversary A that can break IND-SE-PRE-CCA₀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 PK_T=Y AND t_w* to A. The game is demonstrated below.

• Phase-1:   interacts with   adhering to the restrictions given in the security model IND-
  SK-PRE-CCAO.   submits the target condition tw* to   .   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:
  • The hash functions are modelled as random oracles. In order to provide consistent out-
  put,   maintains various lists LHκ and LH4 (for i = 0 to 9) corresponding to the hash
  function H0and H1, (for i = 0 to 9). Oracles H1, H2and H3are simulated as given in
  the proof of SE scheme. The other hash oracles are simulated as follows;
  * H0Oracle: On input of tw,   checks whether a tuple   tw, h8   corresponding to tw
  is there in LH0 list. If it is already present then return h8, else pick h8∈ {0,1}l0.
  Store   tw, h0   in LH0 list and return h0.
  * HcOracle: On input ofC,   checks whether a tuple   C, hc   corresponding toC is
  already there in LHc list. If it is present then hc is returned, else pick hc∈ {0,1}lc.
  Store (C, hc) in LHc list and return hc.
  * H1Oracle: When a query with input (tw, x, X) is made, the tuple   tw, x, X ht
  is retrieved from LHt and htis returned, if (tw, x, X) is already there in LH1 list.
  Otherwise,   does the following:
  • If X = Xtin LHonestandxtY = X, then abort. This is because   obtains
  the solution to DLP i.ext−1x = a.
  • Pick ht∈   .
  • If htis already present in LH1 list, go to previous step.
  • Store (tw, x, X, ht) in LHt list and output ht.
  * H4Oracle: When H4oracle is queried with (C1, C2, C3, α, tw) as input,
  retrieves the tuple (C1, C2, C3, C4, tw, h4) from LH4 list and returns h4, if an entry
  corresponding to (C1, C2, C3, α, tw) is already there in LH4 list. Otherwise,
  does the following;
  • Pick h4∈   q*.
  • If h4is already present in LH4 list, go to previous step.
  •Store (C1, C2, c3, α, tw, h4) in LH4 list and return h4.
  * H5Oracle: When H5oracle is queried with (tw, x, X) as input,   retrieves the
  tuple (tw, x, X, h5) from LH5 list and returns β, if an entry corresponding to
  (tw, x, X) is already there in LH5 list. Otherwise,   does the following:
  • Pick h5∈   q*.
  • If h5is already present in LH5 list, go to previous step,
  • Store (tw, x, X, h5) in LH5 list and return h5.
  * H6Oracle: When H6oracle is queried with (ω, γ, X, Y) as input,   retrieves the
  tuple   ω, γ, X, Y, h6   from LH6 list and returns h6, if an entry corresponding to
  (ω, γ, X) is there in LH6 list. Otherwise,   does the following:
  • Pick h6∈   q*.
  • If h6is already present in LH6 list, go to previous step.
  • Store (ω, γ, X, Y, h6) in LH6 list and return h6.

• In one embodiment, H₇Oracle, Hs Oracle, H₉Oracle can be described, for example, as below. A person of ordinary skill in the art would understand the results are consistent.

• H7Oracle: When H7oracle is qureried with (r, X) as input,   retrieves the tuple
  (r, X, h7) from LH7 list and returns h7, if an entry corresponding to (r, X) is
  already there in LH7 list. Otherwise,   does the following;
  • Pick h7∈   q*.
  • If h7is already present in LH7 list, go to previous step.
  • Store (r, X, h7) in LH7 list and return h7.
  H8Oracle: When H8oracle is queried with (γ, X) as input,   retrieves the tuple
  γ, X, h8   from LH8 list and returns h8, if an entry corresponding to (γ, X) is
  already there in LH8 list. Otherwise,   does the following:
  • Pick h8∈ {0,1}lw+lp.
  • If h8is already present in LH8 list, go to previous step.
  • Store (γ, X, h8) in LH8 list and return h8.
  H9Oracle: When H9oracle is queried with (u, r) as input,   retrieves the tuple
  u, r, h9   from LH9 list and returns h9, if an entry corresponding to (u, r) is
  already there in LH9 list. Otherwise,   does the following:
  • Pick h9∈   q*.
  • If h9is already present in LH9 list, go to previous step.
  • Store (u, r, h9) in LH9 list and return h9.
  • Corrupted Keygen Oracle : When a query is made with input Ui, the   performs the
  following:
  * Picks a random xi∈   q*.
  * Computes Xi= xiP
  * Sets PKi=   Xi   and SKi=   xi   .
  * Stores   Ui, xi, Xi   in LCorruptlist and returns (SKi, PKi). Here   knows the
  private key SKiof user Ui.
  • Uncorrupted Keygen Oracle :When a query is made with input Ui, the   performs the
  following;
  * Picks a randomxi∈   q*.
  * Computes Xi=xiY =xiaP = xiP, where xi=xia
  * Sets PKi=   Xi   . By definition SKi=   xi=xia   . This is not known to    ; a is
  the discrete log corresponding to Y in the DLP which is given as the challenge to
  .
  * Stores    Ui, —,xi, Xi   in LHonestlist and returns PKi.

• RekeyGen Oracle, in one embodiment, can be described as follows. On input of (c_w, PK_i, PKj), C does the following to generate the re-encryption key.

• * If (PKi∈ LCorrupt)
  • Compute RKi→j = RekeyGen(cw, SKi, PKi, PKj).
  • Store   tw,PKi, PKj,RKi→j   in LReKeylist.
  • Output RKi→j
  * If tw, PKi, PKjhas an entry in LReKeylist, retrieve and return RKi→j
  * If (PKi∈ LHonestthen
  • Choose ω   ∈ {0,1}lω
  • Choose hcin ∈   q* and store   cw, ...., Xi   in LH1 list.
  • If Xjis corrupt r = H6(ω,xixjaP, Xi, Xj) ∈   q*
  • If tw= tw* and PKi= PKTthen set rb = H6(ω,xia2P, Xi, Xj) ∈   q* (Here
  does not know rb)
  • Compute s = H7(—, Xj) ∈   q*
  • By definition γ = rXj= rxjabP
  • Compute the re-encryption key RKi→j =   R1, R2, R3, R4, R5, R6   where,
  R1= s − hc∈   q*
  R2= rbP ∈
  R3= (ω||Xi) ⊕ H8(—, Xj) ∈ {0,1}lw+ly
  R4 = H6(ω, —, Xi, Xj ) ∈   q*
  R5= h5∈ {0,1}l5, Store(tw, —, Xi, h5)inLH5list
  R6= H0(tw)
  • Output the re-encryption key RKi→j =   R1, R2, R3, R4, R5, R6
  • Self-Encrypt Oracle : On input of (m, tw, PKi),   does the following:
  * if PKicorrupt, then run Self-Encrypt(m, tw, SKi, PKi)
  * If PKiis honest, then perform the following
  • Choose random t ∈   q*
  • Choose ht∈   q* and store   tw, —, Xi, ht   in LH1 list.
  • Compute C1= t + ht.
  • Compute Key = H2(t)
  • Compute C2= {Ĉi}(for1=1to l)and Ĉi=Sym.Encrypt (Mi, Key) for all i = 1
  to l, l is the number of blocks. Assume that m = M1M2... Mlwhere |Mi|=k
  and k is the block of size Δ
  • Set C3= H3(m, t)
  • Choose α ∈ {0,1}l5 and store   tw, xi, Xi, h5= α   in LH5 list.
  • C4= H4(C1, C2, C3, α, X)
  • Set C5= H8(tw)
  • Store (C, tw, PKi) in LEncryptlist.
  • Output the ciphertext C =   C1, Hc(C2), C3, C4, C5)   .
  Re-Encrypt Oracle : On input C =   C1, C2, C3, C4, C5, PKi, PKj   ,   does the
  following:
  * Generate the re-encryption key RKi→j = ReKey(PKi, PKj)
  * Run D = Re-Encrypt(C, RKi→j, PKi, PKj) as per the algorithm.
  * Store   C, D, PKi, PKj, tw   in LRe-Encryptlist and output D
  Self-Decrypt Oracle: On input   C1, C2, C3, C4, C5, tw, PKi   .   does the
  following:
  * If an entry for (C, tw, Xi) is there in LEncryptlist, return the corresponding m.
  * if PKicorrupt, then run Self-Decrypt(C, SKi)
  * If PKiis honest, then perform the following:
  • Find   tw, x, X, h5   from LH5 list such that (Xi= xP) OR (X = Xiand x = —).
  Set α = h5. If there is no such entry then query α = H5(tw, —, Xi).
  • If C4≠ H4(C1, C2, C3, α, tw, X), then it returns ⊥ Find   tw, x, X, h1
  from LHt list such that (Xi= xP) OR (X = XiAND x = —). Set α = h5. If
  there is no such entry query α = H5(tw, —, Xi).
  • Find   tw, x, X, h1   from LHt list such that (Xi= xP) OR (X = XiAND
  x = —), then set ht= h1. If there is no such entry then ht= H1(tw,  , Xi).
  • t = C1− ht
  • Key = H2(t)
  • Compute Mi=Sym.Decrypt(Ĉi,Key) for all i=1 to l and construct m = M1
  M2... Ml.
  • If C3   H3(m, t) then, output m. Else, Output ⊥.
  Re-Decrypt Oracle : On input D =   D1, D2, D3, D4, D5, tw, PKj   ,   does the
  following:
  * if PKjcorrupt, then run Re-Decrypt(D, SKj)
  * If PKiand PKjare honest, then perform the following
  1. Pick γ, h8, from   γ, X, h8   LH8 list for X = Xjand
  2. For each γ retrieved from LH8 list: compute ω||Xi= D5⊕ h8and
  r = H6(ω,xjxia2P, Xi, Xj). If γ = rXj, then proceed with next step, else continue
  checking with other γ retrienced from LH8 list. If no such γ is found, then it
  returns ⊥.
  3. Compute s = H7(r, Xj) ∈   q*
  4. ρ = H6(ω, γ, Xi, Xj) ∈   q*
  5. Compute β = H9(D6, ρ) ∈   q*
  6. Compute t = β−1(D1) −s
  7. Find Key = H2(t)
  8. Compute Mi=Sym.Decrypt(Ĉ1, Key) for all i=1 to l and construct M1
  M2... Ml.
  9. If (C3=   H3(m,t) then, output m. Else, it returns ⊥.
  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   .
  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,
  cannot make the query Self-Decrypt(C*)
  cannot make the query Self-Encrypt(m  , tw*), δ ∈ {0, 1}
  cannot make the query Re-Encrypt(C*, PKT, PKj), PKj∈ LCorrupt
  cannot make the query Re-Decrypt(D, PKj), if D = Re-Encrypt(C*, PKT, PKj)
  and PKj∈ L
  cannot make the query ReKey(tw*, PKT, PKj) and PKj∈ LCorrupt
  Guess: After getting sufficient training,    output the guess δ′.    wins the game is δ = δ′.
  now picks randomly γ from LHs list and provides as solution to the CDH problem.
  Security of the TransformedCiphertext
  Theorem
  3. If a (t, ϵ) adversary  with an advantange ϵ breaks the IND-SE-PRE-CCAT
  security of the SE-PRE scheme, then  can be solve the Computational Diffie
  Hellman(CDH) problem with advantage ϵ′ where,
  ${ϵ}^{\prime }\ge \frac{1}{q_t}ϵ$
  Here, qtis the number of queries to H   oracle.
  Proof.: In this section we formally prove the security of the transformed ciphertext of SE-
  PRE scheme in the random oracle model. The security of the scheme is reduced to the
  CDH problem. The challenger  is giving the instance of CDH (i.e given (q, P, aP, bP)
  such that q is a large prime, P, aP, bP, ∈  find Y such that Y = abP.) Now, if there exist
  an adversary who can break the IND-SE-PRE-CCATsecurity of SE-PRE then  can
  make use of  to solve the CDH problem, which is assumed to be hard. Hence such
  an  does not exist.
  All the oracles are similar to that of IND-SE-PRE-CCAO. The challenge ciphertext issued
  will be a transformed ciphertext A has much more acces than IND-PRE-CCAO:
  is allowed to access the rekey from PKTto any PKj.
  is allowed to access Self-Decrypt for PKT
  Challenge: After getting sufficient training  provides two messages m0, m1and gives to
  .  generates the ciphertext as.
  Generate C* = Self-Encrypt(m  , tw*, PKi); PKi∈ LHonest
  Generate D* = RE-Encrypt(C*, tw*, PKi, PKT);
  Provides D* to .
  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.
  indicates data missing or illegible when filed

• 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 inFIG. 2 Table. 2. It is a known fact that pairing is very expensive than other group operations and hence we are not taking any pairing based schemes into consideration. The implementations are done on 2.4 GHz Intel Core i7 quad-core processor and the results have been reported below. The programming language used is Go language, and the programming tool is Goland 2018.2. The cryptographic protocols are implemented using the edwards25519-curve, which is the current standard deployed in cryptocurrencies for fast performances. From the performance comparison inFIG. 2 Table 1, we note that our CCA secure self-encryption SE scheme is more efficient than the existing CPA-secure El-Gamal encryption scheme. Also, fromFIG. 2 Table 2, it is evident that our self-proxy re-encryption SE-PRE scheme without bilinear pairing is more efficient than the existing pairing-free PRE scheme by others.
• 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.
• FIG. 3 is an exploded view of anintermediary system120 inFIG. 1 according to one embodiment disclosing self-encryption in proxy re-encrypt scheme. Different modules within the intermediary system that operate according to the disclosures herein are described. For example,module370 receives ciphertext from one or more clients. Module310 process the received ciphertext and extracts the sender, i.e. the first user. Module310 further extracts the second user to whom the request is supposed to be re-sent.Module320 validates that the ciphertext originated from first user. If the ciphertext is not validated, it is discarded immediately and no further action is taken on that ciphertext. If the ciphertext is not validated, error correcting mechanisms may be employed to check whether the ciphertext is corrupt because of network connection failure or an attack by an intruder.Module330 re-encrypts the ciphertext based on the re-encryption key created by first user using second user's public key.Module340, outputs the re-encrypted ciphertext only if original ciphertext was validated.Module350 provides security against chosen cipher attack and denial of service attack. Module360 as a proxy sends the reencrypted ciphertext to the second user.
• II. Secure Content Access Audit with Blockchain
• 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.
• FIG. 4 discloses adata workflow400 for an encrypted file that requires independent audit response. For example,encrypted file430 is put on the blockchain platform by an authenticatedowner410. In one embodiment, theowner410 is authenticated using proof of past public/private key transactions on the blockchain platform. In one embodiment, theowner410 is authenticated using split-keys on two or more owner devices. In one embodiment, theowner410 is authenticated using a combination of single signature on and split-key authentication techniques. Different users andclients420 can access theencrypted file430 on an ongoing basis according to security policy parameters set by owner. The security policy parameters for theencrypted file430 are enforced by an intermediary450. Another intermediary440 can provide audit services for the encrypted file.
• FIG. 5 is integration at the server level. The idea here is that the end users will not have any changes to their workflows. Everything is taken care of at the server level. Whenever a user submits data or reads data, it is automatically recorded on the blockchain by the server. This level of integration provides tamperproof auditability with accurate timestamp information. It is assumed that the server is trusted at any given moment to submit the right data to the blockchain but will not be able to alter it later on.
• FIG. 6 shows integration at the server and client level. There may be cases where even the server can't be trusted. Or the enterprise wants the audit data to be provided by the client instead of the server. In this case, it is expected that each user has credentials with the blockchain and use those credentials to submit their read/write transactions and then present that as a proof to the server to access the content. The server can continue to enforce access control and even record any access that is not permitted presenting the transaction presented by the user to read the content.
• 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.
• FIG. 7 is a schematic diagram ofcomputing device700 that can be used to implement the methods and systems disclosed herein, according to one or more embodiments.FIG. 7 is a schematic of acomputing device700 that can be used to perform and/or implement any of the embodiments disclosed herein. In one or more embodiments, client system110, anintermediary system120,service provider system130 ofFIG. 1 may be thecomputing device700.
• Thecomputing device700 may represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and/or other appropriate computers. Thecomputing device700 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.
• FIG. 7 shows an example of acomputing device700 on which techniques described here can be implemented. Thecomputing device700 can be a conventional computer system that can be used as a client computer system, such as a wireless client or a workstation, or a server computer system. Thecomputing device700 includes acomputer705, I/O devices710, and adisplay device715. Thecomputer705 includes aprocessor720, acommunications interface725,memory730,display controller735,non-volatile storage740, and I/O controller745. Thecomputer705 may be coupled to or include the I/O devices710 anddisplay device715.
• Thecomputer705 interfaces to external systems through thecommunications interface725, which may include a modem or network interface. It will be appreciated that thecommunications interface725 can be considered to be part of thecomputing device700 or a part of thecomputer705. Thecommunications interface725 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.
• Theprocessor720 may be, for example, a conventional microprocessor such as an Intel Pentium microprocessor or Motorola power PC microprocessor. Thememory730 is coupled to theprocessor720 by abus750. Thememory730 can be Dynamic Random Access Memory (DRAM) and can also include Static RAM (SRAM). Thebus750 couples theprocessor720 to thememory730, also to thenon-volatile storage740, to thedisplay controller735, and to the I/O controller745.
• The I/O devices710 can include a keyboard, disk drives, printers, a scanner, and other input and output devices, including a mouse or other pointing device. Thedisplay controller735 may control in the conventional manner a display on thedisplay device715, which can be, for example, a cathode ray tube (CRT) or liquid crystal display (LCD). Thedisplay controller735 and the I/O controller745 can be implemented with conventional well-known technology.
• Thenon-volatile storage740 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, intomemory730 during execution of software in thecomputer705. 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 theprocessor720 and also encompasses a carrier wave that encodes a data signal.
• Thecomputing device700 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 theprocessor720 and the memory730 (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 thememory730 for execution by theprocessor720. 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 inFIG. 7, such as certain input or output devices. A typical computer system will usually include at least a processor, memory, and a bus coupling the memory to the processor.
• ThoughFIG. 7 shows an example of thecomputing device700, it is noted that the term “computer system,” as used here, is intended to be construed broadly. In general, a computer system will include a processor, memory, non-volatile storage, and an interface. A typical computer system will usually include at least a processor, memory, and a device (e.g., a bus) coupling the memory to the processor. The processor can be, for example, a general-purpose central processing unit (CPU), such as a microprocessor, or a special-purpose processor, such as a microcontroller. An example of a computer system is shown inFIG. 7.
• 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.
• III. Multiple Signatures on a Smart Wallet
• 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:
• • “${FromWalletID}:${ToWalletID}:${Value}.
• 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.
• FIG. 8 shows800 multiple-signature wallet flow for messages between different entities. At810 is Administrator of the blockchain,820 is the Exchange application for transactions,830-1,2,3, . . . n are different multiple signers,840 is the smart contract,850 is modern portfolio theory wallet,860 is the depositor and870 is the withdrawer. The figure shows register, deposit and withdraw events and corresponding messages according to one embodiment.
• FIG. 9 shows900 multiple-signature wallet flow for messages between different entities in one embodiment. At910 is the Administrator,920 is the Exchange application, Signers are at930-1,2,3, . . . n,940 is the shared multiple-signature wallet associated with a smart contract,950 is the modern portfolio theory wallet,960 is the depositor, and970 is the withdrawer. The figure shows register, deposit and withdraw events and corresponding messages according to one embodiment.
• IV. Split Key Authentication and Password-Less Login
• 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 fromstep 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.
• FIG. 10 shows themessage flow1000 for split-key authentication according to one embodiment. At1010 is the user,1020 is the desktop or first device of the user,1030 is the second device or mobile of the user,1040 is the Single-sign on (“SSO”) server,1050 is the Blockchain IDP Server. The figure shows Register and Login events and corresponding message flow according to one embodiment.
• FIG. 11 is depicts aflowchart1100 illustrating an example of a method for a blockchain platform to achieve split-key authentication and passwordless login, according to one embodiment. Theflowchart1100 is discussed in conjunction with the blockchain platform environment shown in the diagram100 inFIG. 1. Atblock1105, for a given client login, create a public and private key at a client device. Atblock1110, split the private key of the client into two or more parts. Atblock1115, assign the split private key part to two or more client devices. At1120, signing to authenticate a challenge using a partial key part at one of the client devices. At1125, send the challenge to the remaining client devices who sequentially sign using short range wireless network connection, for example, Bluetooth protocol or near field communication. At1130, respond back to the challenge to login without a password. At1135, receive authentication complete based on the response to the challenge. At1140, getting access to the application or resources based on the authentication.
• 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.

Claims (20)

1. A method 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.

2. The method ofclaim 1, wherein the intermediary does not have the ability to decrypt the received ciphertext.

3. The method ofclaim 1, further comprising:

skipping outputting the re-encrypted ciphertext based on one or more condition parameters.

4. The method ofclaim 1, further comprising:

sending the re-encrypted ciphertext to a second intermediary for second hop re-encryption.

5. A 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.

6. The method ofclaim 5, wherein the owner is established using past read or write transactions performed directly on the blockchain platform.

7. The method ofclaim 5, further comprising: dividing the encrypted file into two or more parts before sending for storage on the blockchain platform.

8. A 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.

9. The method ofclaim 8, wherein:

the smart wallet with the group key supports all the functions of a single user wallet.

10. A 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.

11. A system on a blockchain platform for one or more intermediaries comprising:

a module to receive a ciphertext from a first user with condition parameters that has been encrypted with a dynamically selected encryption algorithm;

a module to receive a re-encryption key for a second user from the first user;

a module to identify whether the ciphertext is valid;

a module to re-encrypt the ciphertext;

a module to output the re-encrypted ciphertext only if the ciphertext is valid; and

a module to achieve security against chosen ciphertext attack and distributed denial-of-service attack;

a module to send the re-encrypted ciphertext to the second user for decryption.

12. The system ofclaim 11, wherein the intermediary does not have the ability to decrypt the received ciphertext.

13. The system ofclaim 11, further comprising:

a module to skip outputting the re-encrypted ciphertext based on one or more condition parameters.

14. The system ofclaim 11, further comprising:

a module to send the re-encrypted ciphertext to a second intermediary for second hop re-encryption.

15. A system of a blockchain platform for an intermediary, comprising:

a module to receive an encrypted file from a user for storage on the blockchain platform;

a module to map the user to be the owner of the encrypted file;

a module to receive one or more security policy parameters for the encrypted file from the owner;

a module to enforce the security policy parameters for all access requests to the file on the blockchain platform; and

optionally a module to provide audit report of the encrypted file storage and access.

16. The system ofclaim 15, wherein the owner is established using past read or write transactions performed directly on the blockchain platform.

17. The system ofclaim 15, further comprising: a module to divide the encrypted file into two or more parts before sending for storage on the blockchain platform.

18. A system of a blockchain platform for a smart wallet, comprising:

a module to assign a total number of two or more public-private key pairs for users associated with the smart wallet;

a module to allocate a threshold number for approval on transaction on the smart wallet wherein the threshold number is less than or equal to the total number;

a module to create a group key from the total number of public-private keys and the threshold number for approvals;

a module to use the group key to register the smart wallet on the blockchain;

a module to receive for a transaction a shared signature based on the group key from two or more users;

a module to validate and finalize the transaction when the received signatures are more than the threshold number.

19. The system ofclaim 18, wherein:

the smart wallet with the group key supports all the functions of a single user wallet.

20. A system of blockchain platform for authenticating clients, comprising of:

a module to create a public and private key at a client device;

a module to split the private key into two or more parts;

a module to assign the split private key part to two or more client devices;

a module to sign to authenticate a challenge using a partial key part at one of the client devices;

a module to send the challenge to the remaining client devices who sequentially sign using short range wireless network connection;

a module to respond back to the challenge to login without a password.

Images