Revocable and traceable blockchain rewrites using attribute-based cryptosystems

Abstract

Method and apparatus for efficient and authorized rewriting of records already written to a blockchain. Mutable transactions will make a fraction of all blockchain transactions, but will be a necessity to meet the needs of privacy regulations, for example the General Data Protection Regulation. Embodiments of the present invention provide an efficient framework for transaction-level blockchain rewrites that is fine-grained and supports revocation. Embodiments of the present invention provide a novel revocable chameleon hash with ephemeral trapdoor method and/or system, a novel revocable fast attribute-based encryption method and/or system, and a dynamic group signature method and/or system.

Description

BACKGROUND OF THE INVENTION

Embodiments of the present invention relate to a system for performing access control including revocation for transaction rewrites in blockchains.

In access control techniques, revocation is a problem that is easily motivated from a practical standpoint. A blockchain is an append-only ledger to which entities can post messages in a decentralized manner. A message can be a financial transaction, a smart contract, or any data that needs to be shared among several users, but whose provenance needs to be verified. At a high level, a block is a collection of multiple messages (also called transactions), and their hash digests. Usually, once a message has been written to the blockchain, the message is considered immutable and cannot be edited.

While blockchain edits or rewrites are not required in all applications, there is an important class of applications where editing messages written onto a blockchain is important. For instance, in the European Union (“EU”), the general data protection regulation (“GDPR”), Chapter 2, Article 17: “Right to erasure” and Article 19: “Notification obligation regarding rectification or erasure of personal data or restriction of processing”, gives users or data subjects the right to request that their personal data be erased/edited by the person or entity collecting or publishing their data, per their request. The U.S. state of California passed the California Privacy Rights Act (“CPRA”), whose origins were laid out in the California Consumer Privacy Act (CCPA) in 2018.

Blockchain technology has widespread applications in healthcare, regulatory compliance and audit, record management, Internet of Things, and more. It is easy to envisage examples where a user's sensitive data is part of the committed blockchain transactions, and at a later point needs to be erased. For example, a global consortium of banks is currently using a blockchain platform to manage financial agreements, securities trading, etc. These transaction records will include clients' information and could potentially contain personally identifiable information.

As per the individual's “right to forget” (e.g., in GDPR), a user can request a purge of their identification data from the blockchain, (true even with encrypted data), and should be able to independently verify that the data has been purged. Also, when a blockchain is used for record keeping and auditing the actions of a set of mutually untrusting parties, there may be situations where a non-monetary record needs to be expunged from the blockchain, e.g., offensive content, leaked personal information/encryption keys, etc., and companies have prototyped editable blockchains for addressing this. The U.S. Department of Homeland Security in a recent report on the use of blockchains in government has judged permissioned blockchains to be useful for maintaining government records, supply chain monitoring, and government approval chain processes, which will encourage blockchain adoption. In all such applications, there may occasionally arise a need for correcting/updating transactions. There is thus a present need for a method and apparatus for providing revocable and traceable blockchain rewrites.

Recently, some solutions have been proposed to enable modifications of data posted to a blockchain. One method is a hard fork, which involves diverging the blockchain at the point where a message needs to be changed, creating a new forked blockchain, and invalidating all subsequent blocks in the old blockchain. Another technique is to modify a message m to m′, post m′ pointing to m on the blockchain. In addition to being inefficient, these techniques do not expunge the old message from the chain, and do not enable fine-grained control over who can modify messages.

A couple of editable options have been proposed, for example, one solution for blockchain edits is by rewriting entire blocks using chameleon hash functions. Another solution is a system for block-level rewrites where any user can propose a redaction or an edit of a block, which is then voted upon by other users, and the edit is accepted if it wins a majority vote. Coarse block-level solutions result in needlessly rewriting an entire block, when only a single transaction in a block needs to be expunged. In addition, coarse block-level solutions do not provide fine-grained transaction level control by helping set permissions about who can rewrite individual transactions. There is thus a present need for system which provides transaction-level rewriting, particularly a system wherein a transaction can be updated, if needed, at which point only the updated transaction is visible on the blockchain.

Recently, chameleon hash functions have been proposed to enable blockchain rewrites. Chameleon hash functions enable a user to find collisions in the domain of a hash function, such that several pre-images can be created that map to the same hash digest. The process of finding a collision on a given message, termed adapting the message, is done using a trapdoor associated with the digest. For increased security and flexibility, the idea of two trapdoors being associated with a digest, a permanent long-term trapdoor and an ephemeral trapdoor, which is chosen per message, has been proposed. However, a message cannot be adapted without knowing both trapdoors. Another known system proposed the use of an ephemeral trapdoor associated with a digest of a message posted on the blockchain that is encrypted using ciphertext-policy attribute-based encryption (“CPABE”), and only users possessing enough attributes that satisfy the policy can decrypt the ephemeral trapdoor and adapt a message. The problem with these methods and/or systems is that access to the ephemeral trapdoor, once issued, cannot be revoked, i.e., once given out, the ephemeral trapdoor is accessible to users in perpetuity. A perpetual trapdoor is of course not desirable as we would like to revoke such trapdoors once the edit has been made. For this reason, embodiments of the present invention preferably use chameleon hashes, attribute-based encryption (“ABE”) and a dynamic group signature method and/or system to provide non-perpetual editing capabilities.

Motivated by the problem of performing transaction rewrites on a blockchain, the following questions should be asked:

• • 1) Who gets to erase or overwrite transactions/messages?
  • 2) What if a user is allowed to update a given message only for a short period of time?
  • 3) Once a message has been modified, should the identity of the modifier be revealed?
  • 4) If yes, to whom should the identity be revealed?These questions need to be addressed to make editable transactions usable. Embodiments of the present invention preferably address three important challenges:
  • 1) Revoking access to ephemeral trapdoors: a revoked user cannot update a message even if he/she has a local copy of the long-term and ephemeral trapdoors;
  • 2) Revoking attributes from users: a user who no longer has access to an attribute secret key cannot update a message and/or trapdoor; and
  • 3) Traceability: a user who anonymously rewrites a particular message, but violates the rewriting policy, can be identified.

For addressing the first two challenges, new cryptographic primitives are needed because existing ones do not provide the properties that are needed.

Note that the following discussion refers to a number of publications by author(s) and year of publication, and that due to recent publication dates certain publications are not to be considered as prior art vis-a-vis the present invention. Discussion of such publications herein is given for more complete background and is not to be construed as an admission that such publications are prior art for patentability determination purposes.

BRIEF SUMMARY OF EMBODIMENTS OF THE PRESENT INVENTION

Embodiments of the present invention relate to a method and computer software for improving the functionality of a computer operating on blockchain by enabling blocks containing editable records to be added to the blockchain, the method including creating a mutable record, a digest of the mutable record, along with a long-term trapdoor, an ephemeral trapdoor, and a plurality of tuples that regulate record edits, the mutable record having an immutable portion and an editable portion, modifying a hash verification function of the blockchain to perform verification of the mutable record, and modifying the blockchain such that when a block containing the mutable record is added to the blockchain, only the immutable portion of the mutable record is used in a block hash calculation. The method can also include onboarding an originator of the mutable record with attribute-issuing authority and signature-key issuing authority before creating the mutable record, the digest of the mutable record, the long-term trapdoor, the ephemeral trapdoor, and the plurality of tuples that regulate the record edits and/or prior to modifying the blockchain, establishing a set of authorized users, who can edit the mutable record by creating a record collision on the digest of the mutable record after the block containing the mutable record has been posted on the blockchain. In the method, creating the digest of the mutable record and the ephemeral trapdoor contained in the mutable record can include using a revocable chameleon hash algorithm to allow authorized users to edit the editable portion of the mutable record while keeping the immutable portion unchanged. The editable portion of the mutable record need not be selected from a predetermined list.

The method can further include providing access control of the ephemeral trapdoor and the long-term trapdoor—and providing access control can include using a revocable attribute-based encryption algorithm wherein a set of authorized administrators decides, grants and revokes record editing privileges. The method can also include updating the ephemeral trapdoor using a revocable chameleon hash algorithm.

In one embodiment, the immutable portion of the mutable record can include the long-term trapdoor and the digest of the mutable record. Preferably, the editable portion of the mutable record is not used in the block hash calculation. The method can also include providing a policy which spells out dynamic group signature system groups from which one or more users can anonymously sign a record edit and post it on the blockchain.

Embodiments of the present invention also relate to a computer readable medium having computer software stored thereon providing editing of records on a blockchain, including code allowing the creation of mutable record, a digest of the mutable record, a long-term trapdoor, an ephemeral trapdoor, and a plurality of tuples that regulate record edits wherein the mutable record comprises an immutable portion and an editable portion, code modifying a hash verification function of the blockchain to perform verification of the mutable record; and code modifying the blockchain, such that when a block containing the mutable record is added to the blockchain, for each mutable record in the block, only the immutable portion of the mutable record is used in a block hash calculation. The computer readable medium can also include code onboarding an originator of the mutable record with attribute-issuing authority and signature-key issuing authority before creating the mutable record, the digest of the mutable record, the long-term trapdoor, the ephemeral trapdoor, and the plurality of tuples that regulate the record edits. The computer readable medium can also include code which, prior to modifying the blockchain, establishes a set of authorized users, who can edit the mutable record by creating a collision on the digest of the mutable record after the block containing the mutable record has been posted on the blockchain. The code creating the digest of the mutable record and the ephemeral trapdoor contained in the mutable record can include code applying a revocable chameleon hash algorithm to allow authorized users to edit the editable portion of the mutable record while keeping the immutable portion unchanged. The code preferably does not require the editable portion of the mutable record to be selected from a predetermined list. The computer readable medium can also include code providing access control of the ephemeral trapdoor, and the code providing access control can include code using a revocable attribute-based encryption algorithm wherein a set of authorized administrators decides, grants and revokes record editing privileges. The computer readable medium can also include code updating the ephemeral trapdoor using a revocable chameleon hash algorithm. Preferably, the immutable portion can include the long-term trapdoor and the digest of the mutable record. The computer readable medium can also include code providing a policy which spells out dynamic group signature system groups from which one or more users can anonymously sign a record edit and post it on the blockchain. Preferably, the editable portion of the mutable record is not used in the block hash calculation.

Embodiments of the present invention provide:

• • 1) a new revocable chameleon hash with ephemeral trapdoor method, hereinafter occasionally referred to as “RCHET”, which guarantees that a revoked user cannot adapt a blockchain message or a trapdoor;
  • 2) a new, efficient revocable ABE, occasionally referred to as “RFAME”, to control access to the ephemeral trapdoor; and
  • 3) a revocable and traceable blockchain rewriting framework, occasionally referred to as “ReTRACe”, using the novel RCHET and RFAME method and/or systems, and a dynamic group signature method as building primitives. In ReTRACe, authorized users can adapt messages using the ephemeral trapdoor of a message's chameleon hash digest. Access to the ephemeral trapdoor can be revoked instantly as needed. Authorized users can anonymously post to and adapt messages on a blockchain, but their identities can be unmasked by legitimate oversight authorities if needed.

In one embodiment, ReTRACe does not modify the way miners communicate with one another and how the blocks are mined in a permissioned blockchain adapted with ReTRACe's functionality (except transaction verification). Both the ReTRACe messages and non-ReTRACe messages can co-exist in the underlying permissioned blockchain, i.e., after integrating ReTRACe into a permissioned blockchain, the resultant chain can accept mutable (messages with trapdoors controlled with ABE policies) as well as regular immutable messages such as financial transactions and records of payments between different entities.

Objects, advantages and novel features, and further scope of applicability of the present invention will be set forth in part in the detailed description to follow, taken in conjunction with the accompanying drawings, and in part will become apparent to those skilled in the art upon examination of the following, or may be learned by practice of the invention. The objects and advantages of the invention may be realized and attained by means of the instrumentalities and combinations particularly pointed out in the appended claims.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The accompanying drawings, which are incorporated into and form a part of the specification, illustrate one or more embodiments of the present invention and, together with the description, serve to explain the principles of the invention. The drawings are only for the purpose of illustrating one or more embodiments of the invention and are not to be construed as limiting the invention. In the drawings:

FIG. 1 is a drawing which illustrates the structure of a RCHET message tuple according to an embodiment of the present invention;

FIG. 2 is a drawing which illustrates the structure of a ReTRACe message according to an embodiment of the present invention;

FIG. 3 is a drawing which graphically depicts group authorizations for a message and revocation of access to a trapdoor according to an embodiment of the present invention;

FIGS. 4A and 4B are drawings which respectively illustrate verification of a message update and verification of a trapdoor update according to an embodiment of the present invention;

FIG. 5 is a drawing which graphically illustrates groups of users who do and do not need rekeying when a member of a group has his or her authorization revoked;

FIGS. 6A and B are graphs with respectively illustrate times for: key generation and setup (6A), and encryption and decryption (6B) as a function of the number of attributes for 80 users.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the present invention, occasionally referred to herein as “ReTRACe” relate to a blockchain transaction rewriting framework that builds on a novel revocable chameleon hash with ephemeral trapdoor and a novel revocable CP-ABE method/system. ReTRACe provides efficient and authorized transaction rewrites in blockchains, in addition to revocability and traceability of the users updating the transactions(s).

ReTRACe is preferably constructed using three primitives: 1) a revocable chameleon hash method and/or system, RCHET, which provides a dynamic and mutable ephemeral trapdoor required for updating a message posted on the blockchain (“BC”); 2) a revocable attribute-based encryption method and/or system, RFAME used to control access to the ephemeral trapdoor; and 3) a dynamic group signature method and/or system (“DGSS”), which helps legitimate users knowing the current ephemeral trapdoorto sign message updates anonymously before posting them to the blockchain. Both, RFAME and DGSS are preferably associated with policies.

As used throughout this application, the term “BC” is occasionally used to refer to a blockchain, the term “message” is used to mean a pre-image of the chameleon hash function, which is posted on the BC as a transaction, and the term “trapdoor”, is used to mean the ephemeral trapdoor of the chameleon hash, unless otherwise specified. A chameleon hash function's output has mutable and immutable parts. The immutable part contains the digest of the hash function. The mutable part includes the trapdoor needed for creating a message collision, among other things.

In one embodiment, ReTRACe preferably includes four kinds of policies, all represented as Boolean predicates: 1) A trapdoor associated with the digest of a given message is encrypted under an ABE policy, γ_ABE; 2) The policy γ_GS spells out certain DGSS groups from which users can anonymously sign a message update and post it on the BC; 3) For revoking access to the trapdoor, a policy, γ_ABEadmin, is provided which sets forth who can create an updated ephemeral trapdoor and encrypt it under a new policy, γ_ABE′; 4) Finally, γ_GSadmin governs who can change γ_GS, and thus exclude users of certain DGSS groups from producing valid signatures.

For simplicity of exposition, the γ_ABEadmin and γ_GSadmin policies, once set, are preferably not changed (this preference can be relaxed on an as-needed basis by setting up a higher level of control). It is the γ_ABEadmin and γ_GSadmin policy clauses that are preferably immutable, i.e. the system preferably allows for the set of people satisfying them to be dynamic and ever-changing.

Unlike ABE methods, DGSS do not have the concept of policies built into them; this is preferably also the case for ReTRACe. A DGSS policy is preferably a publicly-known Boolean predicate linked to a message that specifies which groups can produce valid signatures on m, for example (Y_GS=“Admin” AND “Payroll”) indicates that users belonging to groups “Admin” and “Payroll” can produce valid signatures on m. In case of Boolean predicates with conjunctive clauses, the signatures (σ) and corresponding group public keys (gpk) are preferably collected into a set, ξ_m where ξ_m=(=σ_admin gpk_admin),(σ_payroll, gpk_payroll). Any public verifier can preferably check the validity of a set of signatures for a message with respect to a given policy.

The parties involved in ReTRACe can optionally be categorized into:

• • 1) originator, which preferably creates a message, its digest and trapdoor, and sets four tuples γ_ABE, γ_GS, γ_ABEadmin, γ_GSadmin that regulate further message updates;
  • 2) a set of Authorized users (“AuthU”), which is a set of users who can create a collision on a message posted on the BC by the originator (AuthU can also optionally include the originator) as long as they possess enough attributes that satisfy Y_ABE, and are a member of DGSS group satisfying γ_GS; and
  • 3) a set of Authorized user Administrators (“AuthUAdmins”), which is preferably a set of users who can modify the trapdoor, as well as create a collision on the message (AuthUAdmins can also include the originator), as long as they possess enough attributes to satisfy γ_ABEadmin and are member of the DGSS group satisfying γ_GSadmin.
  • 4) attribute-issuing authority and Group Manager: The attribute-issuing authority (“AIA”) for the ABE system and/or method and the Group Manager (“GM”) for the DGSS issue keys to their respective users. For presentation clarity, a single AIA and GM are described. However, in practice more can be used easily in ReTrace if desired.

A ReTRACe transaction preferably includes a mutable part (plaintext message, policies, trapdoor, ciphertexts, signatures, etc.) and an immutable part (digest). When a ReTRACe transaction is included in a block by the miners, only the immutable part of the ReTRACe transaction is preferably used in the Merkle tree of the given block instead of the hash of the whole transaction. This makes it possible to update a ReTRACe transaction in the future as long as the mutable part of the updated transaction verifies with the immutable digest on the BC. ReTRACe is preferably independent of the kind of underlying BC system, including the consensus mechanism, e.g., Proof of Work/Stake, as long as the security requirements for ReTRACe, as described further in this application, are preferably met. For a user to be able to post any ReTRACe messages in the BC, the user needs to be previously onboarded with an AIA and GM in the given ReTRACe system.

To use ReTRACe with a given BC system, the hash verification function of the BC is preferably modified to perform the ReTRACe messages' verification (miner verification and public verification of the ReTRACe messages). But ReTRACe preferably does not leak sensitive information to the miners, hence the miners are not onboarded by the AIA and GM. Adding or removing miners in the system using ReTRACe works preferably the same as any other BC system; the miners have a few extra steps when verifying updates to ReTRACe transactions, but none of those steps involve the miners learning privileged information about the messages posted on the BC.

Each block on a ReTRACe-modified BC could have mutable as well as immutable transactions and the resultant hash of the block is preferably always immutable as per the rules of traditional BCs. The verification algorithm can verify mutable as well as immutable transactions, thus ReTRACe can be implemented on a blockchain which supports both mutable and immutable transactions. Note that in one embodiment, once a transaction is written to the BC as immutable, it cannot be modified. In this embodiment, only transactions which were originally posted as ReTRACe transactions with a trapdoor and access policy are updatable. The AIA and GM are preferably publicly available to all users to sign up with if any user needs to post mutable transactions on the BC. The user preferably does not need to sign up with the AIA/GM if they do not want to post immutable transactions.

As in most BC-enabled systems, it is assumed that the consensus protocol being used ensures honest operation by miners. AIA is preferably assumed to honestly generate attributes and secret keys; this assumption can be relaxed by using multi-AIA techniques, where components of users' secret keys are generated by multiple AIAs. Similarly, for the DGSS, it can be assumed that the GM for a group will issue signing keys properly and trace users honestly. This assumption can be diluted by introducing a tracing manager and separating the roles of group and tracing managers. These relaxations can be applied on as as-needed basis.

In one embodiment, a primary goal of the treat model and security is to protect against adversaries that have no access to the long-term trapdoor and/or current version of the ephemeral trapdoor for a given message, m, posted on the BC, that do not satisfy the policies associated with m, yet who try to update m or its trapdoors. A second goal is to protect the privacy of, and provide anonymity to, the individuals who post a message or update a message and/or its trapdoor on the BC.

The security of ReTRACe is derived from time-tested, well-regarded assumptions based on the Discrete Log problem, the Decision Linear problem (“DLIN”), and the Decisional Diffie-Hellman (“DDH”) problem. ABE access control policies can be modeled as Boolean formulas with AND and OR gates, where each input is associated with an attribute, and the Boolean formulas are represented as monotone span programs.

Consider a single AIA and GM in a system. Let [1 . . . n] represent a set of users, the AIA issues sets of secret keys S₁, . . . , SK_n, and the GM issues sets of signing keys, sk₁, . . . , sk_n to the users. Let mpk_ABE and gpk denote the public keys of the ABE and DGSS respectively.

Consider a user, u, who creates a message, m, to be posted on the BC. User u creates an adaptable (i.e., updatable) trapdoor T, that enables future modifications of m (using the RCHET method and/or system of the present invention), creates a policy, γ_ABE, which defines a set of authorized users, AuthU, that are allowed to modify m. User u encrypts with mpk_ABE (using revocable ABE, RFAME of the present invention), E_mpkABE (τ, γ_ABE)→Y. For controlling who can update in the future, u picks an r←$ Z_G (where G and GS=|G| are part of the public parameters and will be used in the cryptographic operations of ReTRACe). User u then creates the γ_admin policy that defines the set of authorized user administrator(s), AuthUAdmins who are allowed to update τ and computes E_mpkABE (r, γ_ABEadmin)→X_r. A user in AuthU updates m during a message adaptation, a user in AuthUAdmins updates m, X and X_r during a trapdoor update.

User u also sets the DGSS policies, γ_GS and γ_GSadmin, that stipulate only members of AuthU and AuthUAdmins are authorized to produce valid anonymous signatures on an updated message and updated trapdoor, respectively, before posting to the BC. Finally u posts tuple t=(m, X, X_r γ_info=(γ_ABE,γ_GS), γ_admin=(γ_ABEadmin,γ_GSadmin)) along with a signature on t to the BC. Optionally, standard techniques, which can include for example nonces/timestamps, can be used to prevent replay attacks.

In one embodiment, any user i∈[1 . . . n], s.t. i∈AuthU whose secret key set∈SK {SK₁, . . . , SK_n} satisfies γ_ABE, can optionally decrypt X, obtain τ, and update m to m′ (using RCHET). Note that being able to satisfy γ_ABE only allows i to decrypt the trapdoor τ and update m, but not update τ. User i preferably produces signature on m′ using sk_i that satisfies γ_GS, and post m′ and the signature on the BC.

The digest of a given transaction preferably only corresponds to the m contained in it. The miner's verification function in ReTRACe ensures that only members of AuthU can update m and X, and only members of AuthUAdmins have permission to update m, X and X_r. The miners in ReTRACe do not need any extra or privileged information other than what is already available as part of the public parameters of ReTRACe, hence they do not need to sign up with the AIA or GM in the system.

Revocation of users from AuthU is preferably handled by either a member of AuthUAdmins updating γ_ABE to γ_ABE′ (RFAME), or by the AIA/GM revoking individual users, in which case γ_ABE is unchanged. Any user j∈[1 . . . n], s.t. j∈AuthUAdmins whose secret key set SK_i∈{SK_i, . . . , SK_n} satisfies γ_ABEadmin, can decrypt Xr, obtain r, update τ to τ′ (using RCHET), such that τ′ will only be decryptable by non-revoked users (using RFAME for access control). User j will preferably compute E_mpkABE(τ′,.)→X′, will prove knowledge of r to the miner thus proving it can satisfy γ_ABEadmin, and is a member of AuthUAdmins. User then preferably picks r′←$ Z_q, computes E_mpkABE(τ′,.)→X_r′, to replace r. Then j will sign and post m′, X′, X_r′ on the BC. The DGSS signature will preferably be produced using j's signing keys, sk_i that satisfy γ_GSadmin.

A revocable CHET “RCHET” method and/or system can be provided where the long-term trapdoor remains permanent, but access to the ephemeral trapdoor can be revoked at will. Intuitively, for performing revocation, the ephemeral trapdoor is preferably updated, and the revoked user is prevented from accessing the updated trapdoor.

Algorithms 1 depicts an algorithm for construction of an RCHET system and/or method that provides the construction of revocable chameleon hash with ephemeral trapdoors. The security of RCHET construction is based on the discrete log and DDH assumptions. At a high level, the idea is to hide the long-term and ephemeral trapdoors in the exponent of public parameters and use non-interactive zero knowledge proofs of knowledge (“NIZKPoKs”) to prove knowledge of them. In the construction, Π is an IND-CCA2 public key encryption method, which is used to encrypt randomness associated with the trapdoors.

Algorithms 1:

RCHET Algorithms

• • a) RCHET.systemSetup(1^λ)→(pubpar): This algorithm generates the public parameters of the system:
    • 1. (,g,g)←GGen(1^λ). GGen generates prime-order cyclic group , g∈, q=||.
    • 2. Pick H's key, k∈, and crs→Gen(1^λ), where is the key-space of H. Set and return pubpar=(k,,g,q,crs). We assume pubpar is implicitly passed as input to all other algorithms.
  • b) RCHET.userKeySetup(1^λ)→(sk_ch,pk_ch): This algorithm generates the long-term trapdoor and a public key:
    • 1. Pick x←*q, h←g^x, π_pk←NIZKPoK{x:h=g^x}, generate keys (SK,PK)←Π.KeyGen(1^λ).
    • 2. Set pk_ch=(PK,h,π_pk) and sk_ch=(SK,x). Return (sk_ch,pk_ch).
  • c) RCHET.cHash(sk_ch,pk_ch,m)→{(digest,rand,Γ_pubinfo,Γ_privinfo), ⊥}: Creates a chameleon hash for a message m:
    • 1. Check verify(π_pk,h)₌?1, if not, return ⊥. Pick r, etd, d, δ←q.
    • 2. Compute h′←g^etd, D←g^d, and Δ←g^δ. Do π_t←NIZKPoK{etd: h′=g^etd}, π_D←NIZKPoK{d: D=g^d}, πΔ←NIZKPoK{δ:Δ=^δ}.
    • 3. Generate hash of message to be posted, a←H_k(m) and create chameleon hash parameters:

$\beta \leftarrow \left(r+\frac{\delta }{x}+\frac{d}{x}\right),p\leftarrow h^{\prime },b\leftarrow p·h^{\prime a}.$

• • •  Do π_p←NIZKPoK{r:p=h^r}. Do C←Π.Encrypt(PK,r), C′←Π.Encrypt(PK,a).
    • 4. Return digest=(b,h′,π_t,C,C′), rand=(β,p,π_p), Γ_pubinfo=(Δ,π_Δ,D,π_D), Γ_privinfo=(δ,d,etd).
  • d) RCHET.verify Transaction(pk_ch,m,digest,rand,Γ_pubinfo)→{0, 1}: This algorithm verifies the digest for a message m.
    • 1. Check verify(π_pk,h)1, verify(π_p,p)1, verify(π_t,h′)1, verify(π_D,D)1, and verify(π_Δ,Δ)1.
    • 2. Check

$b\stackrel{?}{=}\frac{h^{\beta }·h^{\prime a}}{D·\Delta },$

• • •  where a←H_k(m). If check passes, return 1, else return 0.
  • e) RCHET.adaptMessage(sk_ch,m,m′,digest,rand,Γ_pubinfo,Γ_privinfo)→{rand′, ⊥}: This algorithm updates a message m:
    • 1. Decrypt a←Π.Decrypt(SK,C′), check aH_k(m). Check

$b\stackrel{?}{=}\frac{h^b·h^{a\prime }}{D·\Delta }.$

• • •  If checks fail, return ⊥.
    • 2. Check hg^x, pg^xr, h′g^etd, Dg^d, and Δg^δ. If checks fail, return ⊥.
    • 3. Decrypt r←Π.Decrypt(SK,C), if r=⊥, return ⊥.
    • 4. Compute a′←H_k(m′).

$r^{\prime }\leftarrow \left(\frac{\mathrm{rx}+a·\mathrm{eid}-a^{\prime }·\mathrm{etd}+\delta }{x}\right).$

• • • 5. Set p′=h^r′ and do π_p′←NIZKPoK{r′:p′=h^r′}. Compute

${\beta }^{\prime }\leftarrow \left(r^{\prime }+\frac{d}{x}\right).$

• • • Set and output rand′=(β′,p′,π_p′).
  • f) RCHET.adaptTrapdoor(sk_ch,m,m′,digest,rand,Γ_pubinfo,Γ_privinfo)→{(rand′,Γ′_pubinfo,Γ′_privinfo), ⊥}: This algorithm modifies the trapdoor to an existing chameleon hash for a message m as follows:
    • 1. Decrypt a←ΠDecrypt(SK,C′), check aH_k(m). Check

$b\stackrel{?}{=}\frac{h^b·h^{a\prime }}{D·\Delta }.$

• • •  If checks fail, return ⊥.
    • 2. Check hg^x, pg^xr, h′g^etd, Dg^d, and Δg^δ. If checks fail, return ⊥.
    • 3. Decrypt r→Π.Decrypt(SK,C), if r=⊥, return ⊥. Compute a′←H_k(m′).
    • 4. Pick d′, δ′←*q. Compute D′←g^d′, Δ′←g^δ′, do π_D′←NIZKPoK{d′:D′=g^d′}, π_Δ′←NIZKPoK{δ′:Δ′=g^δ′}.
    • 5. Set

$r^{\prime }\leftarrow \left(\frac{\mathrm{rx}+a·\mathrm{eid}-a^{\prime }·\mathrm{etd}+\delta }{x}\right),p^{\prime }\leftarrow h^{r\prime }$

• • • Compute

${\beta }^{\prime }\leftarrow \left(r^{\prime }+\frac{d^{\prime }}{x}\right),{\pi }_{p^{\prime }}\leftarrow \mathrm{NIZKPoK}\left\{r^{\prime }:p^{\prime }=h^{r\prime }\right\}.$

• • • 6. Prove knowledge of DDH tuple (g,g^δ,g^d,g^δd). Set and output rand′=(β′,p′,π_p′), Γ′_pubinfo=(Δ′,π_Δ′,_D′,π_D′), and Γ′_privinfo=(δ′,d′,etd).

The properties of indistinguishability public and private collision resistance were introduced some time ago and retained in the industry. However, they have been strengthened in their security definition by giving the adversary access to an oracle for adapting messages in the private collision resistance game, while others only gave the adversary access to a hash oracle. Embodiments of the present invention provide further strengthened security properties by:

• • 1) introducing the notion of revocation collision resistance, which any RCHET method and/or system should provide, and
  • 2) giving the adversary access to oracles for both adapting messages and adapting trapdoors.

Informally, indistinguishability requires that an outsider, given a random string, rand, cannot tell if rand was obtained by hashing the original message, a message update or a trapdoor update. Public collision resistance requires that a user who possesses neither the long-term nor ephemeral trapdoor cannot find collisions by himself. Private collision resistance requires that even the holder of the long-term trapdoor cannot find collisions, as long as the ephemeral trapdoor is unknown to them. Revocation collision resistance requires that a user that knows both the long-term trapdoor and ephemeral trapdoor cannot find collisions after the ephemeral trapdoor has been updated, as long as the new ephemeral trapdoor is unknown to them. These security properties are formalized and give the proof of the following theorem.

Theorem: If the discrete log assumption and DDH assumption hold in G, is collision resistant, Π is IND-CCA2 secure, and the NIZKPoKs satisfy completeness, simulation soundness, extractability and zero knowledge, then our revocable chameleon hash with ephemeral trapdoors method and/or system, RCHET shown in Algorithm 1, is secure

Most of the known benchmark methods and/or systems in ABE do not consider attribute revocation. Revocation model: In ABE there are, broadly speaking, two possible kinds of revocation. One is policy-level revocation, where revocation entails deleting a clause from an ABE policy, e.g., γ=“CS students” and “EE staff” can be updated to a more restrictive policy, γ′=“CS students”. The other is the more fine-grained user-level revocation which calls for revoking decryption rights of individual users, e.g., if we do not wish to update γ, but revoke access of a member of staff from EE. Embodiments of the present invention allow for consideration of user-level revocation, but also support modifiable policies, if needed or desired.

Most of the known benchmark ABE methods do not support revocation. The ones that do are either based on non-standard assumptions, offer only selective security, are application-specific, do only policy-level revocation, do not support Type III pairings, need revocation lists which do not scale well, or perform inefficient revocation. Embodiments of the present invention provide an efficient revocable ABE method and/or system, RFAME, to revoke access to ephemeral trapdoors that provide desired properties.

Algorithms 2 illustrates construction of an embodiment of RFAME, which has security that is based on the DLIN assumption. Efficient Rekeying in RFAME: consider an AIA of an organization that issues four kinds of attributes, “Admin”, “Payroll”, “Benefits”, and “Accounts”. Assume there are unique users possessing each attribute, a total of 4 users in the system, and that there are three messages in the system encrypted under different policies: i) Msg₁ is encrypted under γ_Msg1 (“Admin” OR “Payroll”); ii) Msg₂ is encrypted under β_Msg2=(“Payroll” OR “Benefits”); iii)Msg₃ is encrypted under γ_Msg2=(“Benefits” OR “Accounts”).

Algorithms 2:

RFAME Algorithms

• • a) RFAME.SetupABE(1^λ,U)→(mpk_ABE,msk_ABE): The algorithm first generates the group parameters (q, , , , e, g, h), picks a₁,a₂,b₁,b₂,p₁,p₂←_$q^‡,d₁,d₂,d₃←_$q. It picks α_y←_$q^‡, and computes h^αγ for each γ∈U. It sets mpk_ABE=(h,H₁=h^a1,H₂=h²²,T₁=e(g,h)^p1d1a1+d3, T₂=e(g,h)^p2d2a2+d3, h^αγ1, . . . , h^αγ|U|), and sets msk_ABE=(g,h,a₁,a₂,b₁,b₂,p₁,p₂,d^d1,g^d2,g^d3,α_γ1 . . . α_γ|U|).
  • b) RFAME.KeyGenABE(mpk_ABE,msk_ABE,γ₁, . . . , γ_|U|)→SK: The algorithm generates the secret keys for all attributes γ∈U. Pick r₁, r₂←_$q. Compute sk₀=(h^b1r1,h^b2r2,h^r1+r2)
  • For all γ∈U and t∈{1, 2}, pick σ_γ, σ′←_$q, and compute:

${\mathrm{sk}}_{y,t}={\mathscr{H}\left(y1t\right)}^{\frac{b_1{r}_1}{a_t+{\alpha }_y}}·{\mathscr{H}\left(y2t\right)}^{\frac{b_2{r}_2}{a_t+{\alpha }_y}}·{\mathscr{H}\left(y3t\right)}^{\frac{r_1+r_2}{a_t+{\alpha }_y}}·g^{\frac{{\sigma }_y}{a_t+{\alpha }_y}}·g^{\frac{{\alpha }_y}{a_t+{\alpha }_y}};{\mathrm{sk}}_{y,3}=\left(g^{-{\alpha }_y}·g^{-{\sigma }_y}\right)$ ${\mathrm{sk}}_t^{\prime }={\mathscr{H}\left(011t\right)}^{\frac{b_1{r}_1}{a_t}}·{\mathscr{H}\left(012t\right)}^{\frac{b_2{r}_2}{a_t}}·{\mathscr{H}\left(013t\right)}^{\frac{r_1+r_2}{a_t}}·g^{\frac{{\sigma }^{\prime }}{a_t}};{\mathrm{sk}}_3^{\prime }=\left(g^{d_3}·g^{-{\sigma }^{\prime }}\right),{\mathrm{sk}}^{\mathrm{\prime \prime }}=g^{d_t{p}_t}$ $\mathrm{Set}\mathrm{and}\mathrm{return}\mathrm{SK}=\left({\mathrm{sk}}_0,{\mathrm{sk}}_{y,1},{\mathrm{sk}}_{y,2},{\mathrm{sk}}_{y,3},{\mathrm{sk}}_1^{\prime },{\mathrm{sk}}_2^{\prime },{\mathrm{sk}}_3^{\prime },{\mathrm{sk}}^{″}\right)$

• • c) RFAME.Encrypt(mpk_ABE,msg,(M,ρ))→C. Pick s₁, s₂←_$q. Let ρ(i) denote a mapping to the attributes i∈I that satisfy a given policy Compute:

${\mathrm{ct}}_{\rho \left(i\right),1}=H_1^{s_1}·{\left(h^{{\alpha }_{\rho \left(i\right)}}\right)}^{s_1}=h^{s_1\left(a_1+{\alpha }_{p\left(i\right)}\right)}\mathrm{and}\mathrm{similarly}{\mathrm{ct}}_{\rho \left(i\right),2}=h^{s_2\left(a_2+{\alpha }_{\rho \left(i\right)}\right)},\mathrm{and}\mathrm{set}$ ${\mathrm{ct}}_0=\left({\mathrm{ct}}_{0,1}=H_1^{s_1},{\mathrm{ct}}_{0,2}=H_2^{s_2},{\mathrm{ct}}_{\rho \left(i\right),1},{\mathrm{ct}}_{\rho \left(i\right),2},{\mathrm{ct}}_{0,3}=h^{s_1+s_2}\right)$

• • Assume M has n₁ rows and n₂ columns. Then, for each row, i∈[1 . . . n₁] and l=1, 2, 3, compute:

${\mathrm{ct}}_{i,1}={\mathscr{H}\left(\rho \left(i\right)l1\right)}^{s_1}·{\mathscr{H}\left(\rho \left(i\right)l2\right)}^{s2}·\prod _{j=1}^{n_2}{\left[{\mathscr{H}\left(0jl1\right)}^{s_1}·{\mathscr{H}\left(0jl2\right)}^{s_2}\right]}^{{\left(M\right)}_{i,j}};\mathrm{Set}❘{\mathrm{ct}}^{\prime }=\left(T_1^{s_1}·T_2^{s_2}·\mathrm{msg}\right)$ $\mathrm{Set}\mathrm{and}\mathrm{output}C=\left({\mathrm{ct}}_0,{\mathrm{ct}}_{i,l}\forall i\in \left[1\dots n_1\right],l\in \left\{1,2,3\right\},{\mathrm{ct}}^{\prime }\right)$

• • d) RFAME. Decrypt(SK,Cz,(M,φ)→{msg, ⊥}: Parse C as (ct₀,ct_i,l∀i∈[1 . . . n₁], l∈{1, 2, 3}, ct′). For each row ct_i,l∈M, pick coefficients γ_i∈{0, 1} such that

$\mathrm{num}={\mathrm{ct}}^{\prime }·e\left(\prod _{i\in I}{\mathrm{ct}}_{i,1}^{y_i},{\mathrm{sk}}_{0,1}\right)·e\left(\prod _{i\in I}{\mathrm{ct}}_{i,2}^{y_i},{\mathrm{sk}}_{0,2}\right)·e\left(\prod _{i\in I}{\mathrm{ct}}_{i,3}^{y_i},{\mathrm{sk}}_{0,3}\right)$ $\mathrm{den}=\prod _{i\in I}e\left({\mathrm{sk}}_{\rho \left(t\right),1}^{y_i}·{\mathrm{ct}}_{\rho \left(i\right),1}\right)·\prod _{i\in I}e\left({\mathrm{sk}}_{\rho \left(t\right)2}^{y_i}·{\mathrm{ct}}_{\rho \left(i\right),2}\right)·e\left({\mathrm{sk}}_3^{\prime }·\prod _{i\in I}{\mathrm{sk}}_{\rho \left(i\right),3}^{y_i}·{\mathrm{ct}}_{0,3}\right)·\prod _{t\in \left\{1,2\right\}}e\left({\mathrm{sk}}_t^{\prime }·{\mathrm{sk}}_t^{″},{\mathrm{ct}}_{0,t}\right)$

• • e) RFAME.Revoke(mpk_ABE,msk_ABE,ν)→(mpk_ABE′,msk_ABE′,SK′): Let a user holding attribute ν∈U be revoked by the AIA. This algorithm is run by the AIA which generates new parameters for the non-revoked users of attribute group ν, and updates its mpk_ABE and msk_ABE. It picks β_ν←_q^‡, and computes h^βν. It updates

${\mathrm{mpk}}_{\mathrm{ABE}}^{\prime }=\left(h,H_1,H_2,T_1,T_2,h^{{\alpha }_{y_1}},\dots ,h^{{\alpha }_{y❘U❘-1}},h^{{\beta }_v}\right).$ The msk_ABE remains the same except the α_ν gets replaced with β_ν. It then generates (a component of) the secret key for all non-revoked users possessing attribute ν as follows:

${\mathrm{sk}}_{v,t}={\mathscr{H}\left(v1t\right)}^{\frac{b_1{r}_1}{a_t+{\beta }_v}}·{\mathscr{H}\left(v2t\right)}^{\frac{b_2{r}_2}{a_t+{\beta }_v}}·{\mathscr{H}\left(v3t\right)}^{\frac{r_1+r_1}{a_t+{\beta }_v}}·g^{\frac{{\sigma }_v}{a_t+{\beta }_v}}·g^{\frac{{\beta }_v}{a_t+{\beta }_v}};{\mathrm{sk}}_{v,3}=\left(g^{-{\beta }_v}·g^{-{\sigma }_v}\right)$ where t∈{1, 2}, and all other variables are as defined in the setupABE and KeyCenABE algorithms. Set SK′=(sk₀,sk_ν,t,sk_ν,3,sk₁′,sk₂′,sk₃′,sk″). SK′ is distributed only to the non-revoked users who possess attribute ν.

Using current revocable CPABE methods and/or systems, if one user possessing the Admin attribute terminates employment, their secret key is preferably revoked by the AIA and the other γ−1 Admin users get rekeyed. Msg¹ needs to be re-encrypted to prevent the revoked user from decrypting it. Since Payroll is part of the γ_Msg1 policy, all y users holding Payroll get rekeyed, as Msg₁ got re-encrypted. Payroll users getting rekeyed results in Msg₂ needing to be re-encrypted. Consequently, users holding Benefits and Accounts attributes need to be rekeyed, and Msg₃ needs to get re-encrypted. In total, three re-encryptions and rekey 4γ−1 users are preferably performed for a single user revocation. In one embodiment, the present invention avoids such a domino effect.

At a high level, each attribute, attr is preferably associated with some unique randomness, r and r is imbedded into the secret keys of all users who possess attr. When a user possessing attr needs to be revoked, the randomness is preferably updated to r′ and new secret keys are reissued with r′ embedded in them only to the non-revoked users holding attr, and all ciphertexts whose policies involve attr are preferably re-encrypted. For facilitating this, the AIA can maintain a compact local table identifying which users possess a given attribute, a small storage cost in exchange for avoiding system-wide rekeying of users.

Furthermore, non-revoked users possessing attributes other than attr can still use their current keys to decrypt re-encrypted ciphertexts, which significantly reduces the number of users that need to be rekeyed and the ciphertexts that need to be re-encrypted. Embodiments of the present invention are flexible, in that they allow user-level revocation and do not impose any restrictions on policies.

Thus, RFAME handles revocation more efficiently. When a user possessing Admin gets revoked, only the other γ−1 users in Admin are rekeyed, and only Msg₁ needs to be re-encrypted to prevent the revoked user from decrypting it. In one embodiment, RFAME is a revocable CPABE method and/or system.

In summary, in the worst case, if x is the number of unique attributes in a system, y the number of users per attribute, then the overhead, using state-of-the-art revocation methods, is o(x) re-encryptions and o(xy)rekeyings. In RFAME, the overhead is Θ(1) re-encryptions and Θ(y) rekeyings. RFAME is CPA-secure, and is later turned into a CCA-secure method and/or system for ReTRACe. The IND-CPA is given game for RFAME and the proof of the following theorem: RFAME is fully IND-CPA secure under the DLIN assumption on Type III pairings in the random oracle model.

In one embodiment, a group signature method and/or system is preferably used for providing privacy and anonymity to users posting messages on the BC, yet retaining the ability to trace them if necessary. The group signature method and/or system can be easily replaced with a regular signature method and/or system in ReTRACe if anonymity is not required in the system. Group signature method and/or systems are based on three kinds of groups: static, semi-dynamic, and dynamic groups. Static groups do not support user addition or revocation, semi-dynamic groups support addition but not revocation, and dynamic groups allow addition and revocation. A dynamic group signature method and/or system (DGSS) is preferably used in ReTRACe. In one embodiment, DGSS is not constructed because existing constructions provide the properties that are needed. Thus, in one embodiment, ReTRACe is independent of any specific construction.

An embodiment of a detailed construction of the ReTRACe framework, having its various algorithms, is described in Algorithms 3A-D, 4A-B, 5, and 6. In the algorithms, M denotes the monotone span program representing an ABE policy, and ρ represents a mapping function that maps rows of M onto attributes. BC.write is used to denote a blockchain write operation. The Keygen, UserSetup, Sign, Verify, AdaptMessage algorithms are fairly self-explanatory. The salient features of the CreateMessage, VerifyMiner and Revoke User algorithms, which are more involved, are described in more detail below. A given implementation can optionally use standard techniques, for example, nonces and timestamps, to prevent against replay attacks.

Algorithm 3A:
ReTRACe.Keygen(lλ)
1: GSetup(lλ) → pubpar
2: GKGen(pubpar) → (outGM, stGM),
   where outGM= (mpk, info0)
3: Set gpk = (pubpar, mpk), stGM is GM's state
4: RFAME.SetupABE(lλ, U ) → (mpkABE, mskABE)
5: RCHET.cSetup(lλ) → param
6: RCHET.userKeySetup(param) → (skch, pkch)
7: PubPar = (  , g, q, pkch, mpkABE, gpk)
8: SecPar = (mskABE, stGM)
9: return (SecPar, PubPar, skch)
(a) ReTRACe: AIA/GM Setup

Algorithm 3B:
ReTRACe.UserSetup(SecPar, PubPar)
1: Get   , the list of all groups in DGSS
   that current user needs to join, set    = Ø
2: For each group in   , Run DGSS.Join get
   gsk,    =    ∪ gsk
3: RFAME.KeyGenABE(mpkABE, mskABE, y1, . . . ,
   y|U|) → SK
4: Retrieve skch
5: return key = (  , SK, skch)
(b) ReTRACe: System Setup for User

Algorithm 3C:
ReTRACe.Sign(  , m, ΥGS)
1: Pick   , s.t .,    ⊆   , ΥGS(  ) = 1
2: for gski ∈   , where i ∈ 1 . . . |   | do
3: DGSS.Sign(gski, i. info, m) → {σi, ⊥}
4: ξ = (σi, i.gpk) ∪ ξ
5: return ξ
(c) ReTRACe: Signing a Message

Algorithm 3D:
ReTRACe.Verify(PubPar, msg, ξmsg)
1: for (σ1, 1 gpk) ∈ ξmsg do
2: if DGSS.VerifySignature(l .gpk, l .info, msg,
   σ1 )   0, return 0
3: for (σ1, l .gpk) ∈ ξΥinfo do
4: if DGSS.VerifySignature(l .gpk, l .info, Υinfo,
   σ1 )   0, return 0
5: if RCHET.verifyTransaction(pkch, m, digest,
   rand, Γpubinfo)   1
6: return 1.
(d) ReTRACe: Verifying a Message

ReTRACe.CreateMessage: This algorithm (Algorithm 4A), is preferably run by the originator who first runs RCHET to create a digest and trapdoors for a message m. The originator sets γ_ABE, γ_GS (for members of AuthU), and γ_ABEadmin and γ_GSadmin (for members of AuthUAdmins). The ephemeral trapdoor is encrypted under γ_ABE to obtain X. The originator then picks an r←$ Z_q and encrypts it under γ_ABEadmin to obtain X_r. This ensures that only members of AuthUAdmins can decrypt r, and modify γ_ABE and γ_GS. The originator creates a tuple, msg, with X and policy information, signs using his/her signing key(s) that satisfy γ_GS, and creates a set of signatures γ_info with each signature bundled with its corresponding verification key. Finally, the originator signs γ_info and sends the signature along with msg·ξ_msg·ξ_γinfo to the miner.

ALGORITHM 4A
ReTRACe.CreateMessage(key, PubPar, m)
1:  RCHET.cHash(skch, pkch, m) →
    (digest, rand, Γpubinfo, Γprivinfo)
2:  RFAME.Encrypt(mpkABE, Γprivinfo, (MΥABE,
    ρΥABE)) → X
3:  Create GS . Set Υinfo = (ΥABE, ΥGS)
4:  r ←S   *q, ω = gr, πω ← NIZKPoK{r : ω = gr}
5:  R.FAME.Encrypt(mpkABE, r, (MΥABEadmin,
    ρΥABEadmin )) → Xr
6:  Create ΥGSadmin
7:  SetΥadmin = (ΥABEadmin, ΥGSadmin, Xr, ω, πω )
8:  ReTRACe.Sign( , Υinfo, ΥGSadmin) → ξΥinfo
9:  msg = (m, digest, rand, Γpubinfo, X, Υinfo,
    Υadmin, ξΥinfo)
10: ReTRACe.Sign( , msg, ΥGS) → ξmsg
11: Call ReTRACe.VerifyMiner(PubPar, msg, ξmsg, πω )
12: return (msg, ξmsg)
    (a) RETRACe: Creating a Message

ALGORITHM 4B
ReTRACe.AdaptMessage(key, PubPar, m′, msg, ξmsg)
1: if ReTRACE.Verify(PubPar, msg, ξmsg)   0
   return ⊥
2: RFAME.Decrypt(SK, X, (MΥABE, ρΥABE )) → Γprivinfo
3: RCHET.adaptMessage(skch, m, m′, digest, rand
   Γpubinfo, Γprivateinfo) → rand′
4: msg′ = (m′, digest, rand′, Γpubinfo, X, Υinfo,
   Υadmin, ξΥinfo)
5: ReTRACe.Sign( , msg′, YGS) → ξmsg′
6: if ReTRACe.VerifyMiner(PubPar, msg′,
   ξmsg, ⊥)   0
   return ⊥
7: return (msg′, ξmsg′ )
(b) ReTRACe: Updating a Message

ALGORITHM 5A
ReTRACe.RevokeUser(key, PubPar, m′, msg, ξmsg)
1:  if ReTRACe.Verify(PubPar, msg, ξmsg)   0
    return ⊥
2:  RFAME.Decrypt(SK, Xr, (MΥABEadmin,
    ρΥABEadmin )) → r
3:  r′ ←$  *q, ω′ = gr′. Set πω′ ← NIZKPoK{r′: ω′ = gr′}
4:  RFAME.Encrypt(mpkABE, r′, (MΥABEadmin,
    ρΥABEadmin)) → Xr′
5:  Υ′admin = (ΥABEadmin, ΥGSadmin, Xr′, ω′, πω′)
6:  RFAME.Decrypt(SK, X, (MΥABE, ρΥABE )) → Γprivinfo
7:  RCHET.adaptTrapdoor(skch, m, m′, digest, rand,
    Γpubinfo, Γprivinfo) → (rand′, Γ′pubinfo, Γ′pubinfo)
8:  RFAME.Encrypt(mpkABE, Γ′privinfo, (MΥ′ABE
    ρΥ′ABE)) → X′
9:  Υ′info = (Υ′ABE, ΥGS)
10: ReTRACe.Sign( , Υ′info, Υ′GSadmin) → ξΥ′info
11: msg′ = (m′, digest, rand′, Γ′pubinfo, X′,
    Υ′info = (Υ′admin, ξΥ′info)
12: ReTRACe.Sign( , msg′, ΥGS) → ξmsg′
13: Call VerifyMiner(PubPar, msg′, ξmsg′, πω′ )
14: return (msg′, ξmsg′)
(a) ReTRACe: Revoke Case 1: Revoke Users by Updating Polices

ALGORITHM 5B
ReTRACe.RevokeUser(key, PubPar, m′, msg, ξmsg)
1:  if ReTRACe.Verify(PubPar, msg, ξmsg)   0
    return ⊥
2:  RFAME.Decrypt(, Xr, ( MΥABEadmin,
    ρΥABEadmin)) → r
3:  r′ ← $ *q, ω′ = gr′. Set πω′ ← NIZKPoK{r′: ω′ = gr′}
4:  RFAME.Encrypt(mpkABE′, r′, (MΥABEadmin,
    ρΥABEadmin )) → Xr′
5:  Υ′admin = (ΥABEadmin, ΥGSadmin, Xr′, ω′, πω′)
6:  RFAME.Decrypt(SK, X, (MΥABE, ρΥABE )) → Γprivinfo
7:  RCHET.adaptTrapdoor(skch, m, m′, digest,
    rand, Γpubinfo, Γprivinfo) → (rand′, Γ′pubinfo, Γ′pubinfo)
8:  RFAME.Encrypt(mpkABE, Γ′privinfo, (MΥ′ABE
    ρΥ′ABE)) → X′
9:  msg′ = (m′, digest, rand′, Γ′pubinfo, X′, Υinfo,
    Υ′admin, ξΥ′info
10: ReTRACe.Sign( , msg′, ΥGS) → ξmsg′
11: Call VerifyMiner(PubPar′, msg′, ξmsg′, πω′ )
    return (msg′, ξmsg′)
(b) ReTRACe: Revoke Case 2: AIA Revoking a Single User

ReTRACe.VerifyMiner: This algorithm (Algorithm 6) is preferably run only by miners to verify a message before posting it on the BC. If a message is being adapted (=⊥), the miner does not do NIZK verifications. If a trapdoor is being adapted (=T), the tuple submitted to the miner is an update to a pre-existing msg on the BC, and the ω used to verify the NIZK π_ω is obtained from the current msg on the BC. If a new message is being created (=π_ω), then the ω used to verify the NIZK π_ω is obtained from the msg tuple itself. In all cases, the miner checks if all signatures in ξ_msg pass verification with respect to γ_GS contained in the tuple msg, checks if all verifications in ξ_γinfo pass verification with respect to γ_GSadmin and the digest of msg is checked. If all checks pass, the tuple msg, along with the list of signatures on it, is written to the BC. Note that if ReTRACe is deployed in a BC that hosts both mutable and immutable transactions, then for immutable transactions the miner verification process is the same as in current BC systems.

Algorithm 6:
ReTRACe.VerifyMiner(PubPar,ms  , ξms  , ζ)
1:  for (σl, l. gpk) ∈ ξmsg do
2:  if DGSS.VerifySignature(l. gpk, l. info, msg, σ1 )   0
3:  return 0
4:  for (σl, l. gpk) ∈ ξΥinfo do
5:  if DGSS.VerifySignature(l. gpk, l. info, Υinfo, σ1 )   0
    return 0
6:  if ζ = πω
7:  if verify(ω, πω ) ≠ 1, return 0
8:  if RCHET.verifyTransaction(pkch, m, digest, rand,
    Γpubinfo)   1
9:  BC.write(msg, ξmsg, ) return 1
10: return 0
RETRACe: Miner Verifying a Message

ReTRACe.RevokeUser: This algorithm (Algorithms 5A and 5B) is preferably called by a member of AuthUAdmins either when they want to revoke clauses from the ABE policy, γ_ABE, or when the ephemeral trapdoor, or Γ_privinfo, needs to be re-encrypted in response to the AIA revoking a user. Both cases are preferably handled differently:

Case 1: Revoking a clause from γ_ABE: This algorithm (Algorithm 5B) is preferably run by a user ν E AuthUAdmins who wants to modify a γ_ABE associated with msg. The AIA/GM are not involved, and no algorithm from RFAME is called. User ν first decrypts the trapdoor, Γ_privinfo, using his/her RFAME secret keys, ν picks an r, and encrypts r′ under γ_admin. This is to ensure that only non-revoked members of AuthUAdmins can decrypt r′ and adapt the ephemeral trapdoor in the future. Next ν adapts the ephemeral trapdoor. The new message and trapdoor are encrypted under a new policy, γ_ABE′, which is a low-cost operation and involves no re-keying operations. We have not depicted the γ_GS getting updated, for clarity of presentation. There are four exemplary cases:

• • 1) If γ_ABE changes to a more inclusive γ_ABE′, the new user groups need to be present in γ_GS as well;
  • 2) If γ_ABE changes to a more restrictive γ_ABE′, the revoked users cannot decrypt the trapdoor and successfully adapt the message, so γ_GS does not need to change;
  • 3) If γ_GS changes to a more restrictive γ_GS′, such that the users satisfying γ_GS were also a part of γ_ABE, γ_ABE needs to change too, revoking the users from the ABE method and/or system; and
  • 4) If γ_GS changes to a more restrictive γ_GS′, such that the users satisfying γ_GS′ are not a part of γ_ABE, the new users cannot decrypt the trapdoor and successfully adapt the message, so γ_ABE does not need to change. User ν then signs the new γ_info′ using their signing keys that satisfy Y_GSadmin; the signature set denoted as zi prime info. A new msg′ is created and signed using a set of keys that satisfy γ_GS, and the resulting signature set is denoted by ξ_msg′. Finally, msg′ and ξ_msg′ are given to the verifiers and who post them.

Case2: AIA revoking a user: This third algorithm (Algorithm 5A) is preferably run by a user ν∈AuthUAdmins as soon as the AIA revokes user holding attribute γ (which appears either γ_ABE or γ_ABEadmin). First, the AIA updates its own public key from mpk_ABE and mpk_ABE′ (which results in PubPar getting updated to PubPar′), and then issues SK only to the non-revoked users holding the attribute γ. User ν then proceeds to adapt the ephemeral trapdoor Γ_privinfo, to prevent the revoked user from being able to perform any future message adaptations. User ν then generates a new r′, encrypts, etc. The rest of the steps are similar to Case 1.

Regarding the security properties of ReTRACe, indistinguishability, public, private, and revocation collision resistance are preferably provided. The first three properties were first introduced for any policy-based chameleon hash method and/or system. By giving the adversary the ability to adapt messages and revoke messages, the revocation collision resistance is defined and the first three security properties of ReTRACe are strengthened. Indistinguishability requires that it should be computationally infeasible for an adversary to distinguish whether the randomness associated with a given message was generated as a result of a CreateMessage, AdaptMessage or RevokeUser. Public collision resistance requires that an adversary who knows neither the long-term nor the ephemeral trapdoor cannot produce valid collisions even after seeing past adaptations of messages and trapdoors, even with access to some attributes, but not the complete attribute set that can decrypt the ephemeral trapdoor.

Private collision resistance requires that an adversary that knows the long-term trapdoor, but not ephemeral trapdoor of the RCHET method and/or system, cannot produce valid collisions, even with knowledge of past message and trapdoor adaptations. This property should hold even if he/she has access to a subset of attributes, but not the complete set of attributes needed to decrypt the current trapdoor. Revocation collision resistance requires that an adversary, who knows the long-term and ephemeral trapdoors and has valid attributes to decrypt the ephemeral trapdoor, cannot produce valid collisions if either the RFAME policy changed to exclude him/her, or the AIA revoked a subset of his/her attributes necessary to decrypt the trapdoor. The IND-CPA security of RFAME is proven. For example, the Fujisaki-Okamoto transform can be applied to convert RFAME to an IND-CCA2 secure method and/or system to accomplish the proof. Theorem: if RCHET is secure, RFAME is fully IND-CCA2 secure, and DGSS is a secure dynamic group signature method and/or system then ReTRACe is secure.

Implementation in Ethereum: ReTRACe can be plugged into existing blockchains (including but not limited to Ethereum) by updating cryptographic operations with equivalent ones in ReTRACe. For instance, in Ethereum the signature algorithm in the module “crypto/crypto.go” is preferably modified to use ReTRACe.Sign; “trie/trie.go” to use the digest of rewritable transactions at the leaves of the blocks' Merkle trees; ReTRACe.AdaptMessage and ReTRACe.RevokeUser is preferably added to the “ethclient” module and ReTRACe.VerifyMiner to the “miner/miner.go” module. Such modifications can be ported to Ethereum.

With ReTRACe-adapted Ethereum, an authorized user preferably updates a transaction using the chameleon hash and then submits it to the transaction pool. Using an embodiment of the present invention, the transactions are preferably updated with a binary flag (‘0’←new; ‘1’←updated). A miner that picks up an updated transaction verifies the transaction using ReTRACe, verifies and updates the transaction in the block (the remaining transactions are preferably untouched), and propagates the block for consensus. At each node storing the BC, the block with the updated transaction replaces the old block post transaction-verification.

The cost of ReTRACe operations in Ethereum (in gas) are proportional to their computational cost. The exact cost of operations is dynamic, varying based on many factors (number of pending transactions, minimum cost, etc.). At the base computation level, ReTRACe scales linearly with an increasing number of attributes and users, which is highly desirable.

Referring now to FIG. 1, a message in RCHET preferably contains several components. The plain text message is represented in FIG. 1 as m. The digest, rand, pub, and priv components constitute the chameleon hash part of the message with the digest being the only permanent component of the message. The verification function in RCHET takes as input the public part of the rchet message namely, m, digest, rand, and pub and outputs a message confirming or rejecting the verification. The priv component of the message needs to be protected and should not be available to the public as it acts as the trapdoor for adapting the message and the trapdoor itself. By design, anyone with knowledge of priv can adapt the message and update m and rand to some m′ and rand′, such that the verification for the message would pass, or even adapt the trapdoor by changing pub and priv to some pub′ and priv′. This allows authorized entities (with access to priv) to make changes to the message already in a block in the blockchain.

As best illustrated in FIG. 2, ReTRACe preferably includes three major building blocks RCHET (Revocable Chameleon Hash), RFAME (Revocable CP-ABE), and the GSS for group signature. RCHET helps the transaction to be adaptable. RFAME helps control access to the revocable chameleon hash trapdoor associated with a given transaction. The GSS scheme is used to sign all ReTRACe transactions and updates to the transactions thus providing for privacy of the signer in the system but also allowing for traceability by an authority in case of malicious activity on part of the signer.

In conventional blockchains, hashes of entire transactions are used to build the Merkle root for a given block. But in the case of a Retrace adapted BC, only the hash component of a given ReTRACe transaction is used in the Merkle tree. The Priv component from RCHET message is preferably broken into γ_info and γ_admin.

γ_info contains information along with the ABE encrypted trapdoor giving access to authorized users (“AU”) to carry out message adaptation. Similar to γ_info, γ_admin contains ABE encrypted information giving access to AuthUadmins (“AUA”), authorized administrators to be able to adapt the trapdoor of a retrace transaction. A given ReTRACe system will preferably have three authorities, an Attribute issuing authority, AIA, associated with the RFAME process, a Group Manager (“GM”), and a Tracing Manager (“TM”) associated with the GSS process. The GSS process provides anonymity for users while ensuring traceability of bad actors as a TM can be used to trace which member from a given GSS group produced a given set of signatures.

INDUSTRIAL APPLICABILITY

The invention is further illustrated by the following non-limiting examples.

Example 1

As a hypothetical use-case example, while referring to FIGS. 3-5, assume an organization that uses ReTRACe enabled BC to store records and update communication shared among multiple groups within the organization. Such an organization could be a County Assessor's Office recording land transactions; a judicial system storing records of court cases and their followups; a consortium of banks (e.g., R3 consortium) storing interbank transaction records. In each such case, there is an AIA, GM, and TM setup in the organization as part of the ReTRACe system. Each employee who interacts with the system is preferably given GSS keys as part of the GSS setup and might possess one or multiple attribute keys from the AIA according to their role(s) in the organization and the groups within.

Let us take a user, Alice, who operates within the Finance (“Fin”) group as well as Human Resources (“HR”), hence possesses attribute keys for Fin and HR and signing keys under the BIZ_Ops group in the GSS system. She creates a message ‘m’containing some information that needs to be posted in the BC. She creates her ReTRACe transaction containing message m. She sets the γ_ABE in γ_info to (Fin∧ HR) and γ_GS to BIZ_Ops so that she and other users in her role (members of AU for a given message), i.e., possessing both HR and Fin attributes can decrypt the trapdoor and update the message. She also sets the γ_ABEadmin to (VP_Fin∧ VP_HR) and γ_GSadmin to (VP) defining requirements for AUA group, so that only the user(s) in the organization serving as VPs of Finance and the HR group can decrypt the trapdoor and update the γ_info policy.

In this example, assume that Bob belongs to the group of VPs in the organization and possesses both VP_Fin as well as VP_HR attributes and signing keys under the VP group, hence Bob can update γ_info. However, a user, Charlie, in the organization who does possess signing keys under the BIZ_Ops group, will not be able to update the message because he does not possess the attribute keys Fin and HR under the AIA. Once Alice has created the message, she sends it to the BC system and the miner verifies the message and it is posted.

Whenever the message needs to be updated, members of AU, like Alice, can decrypt the trapdoor, update the message to some m′ and the transaction is sent to the miners for verification. The transaction is verified by the miners by checking the Chameleon hash and the group signature according to the γ_GS defined in the message. If all verifications pass, then the message is updated in the BC.

If a user in AU, for example Alice, leaves her position in the finance group and hence loses her Fin attribute keys from the AIA, the AIA would revoke her key and update all other users' keys in the Finance group. At this point, the message will need to be update by another user in AU or AUA to update the trapdoor. This ensures that Alice cannot create any valid message adaptations since she will not have access to the newly updated trapdoor due to her revoked keys.

On the other hand, if there is a scenario where there is a restructure in the organization and the responsibility of maintaining the message gets shifted entirely to the HR group, members of AUA can update the γ_ABE in the γ_info accordingly and once again update the message trapdoor so that only the current members as defined in the γ_ABE can access the trapdoor and adapt the message.

In both cases of trapdoor updates, the miners verify the signatures according to γ_GSadmin to verify that the trapdoor adaptation was carried out by an authorized user.

The encrypted information contained within γ_info along with the ABE policy enables users in AU, to update the message. Similar to γ_info, information in γ_admin is preferably only available to users in AUA and enables them to update the trapdoor. For a user to produce a valid retrace transaction update, they need to have keys to the attribute groups defined in upsilon ABE, as well as the signing keys defined in the group signature policy (upsilon GS).

The small Venn diagrams in the call-out boxes for γ_info, and γ_admin in FIG. 3 are used to illustrate group memberships, in this case, user Alice who has GSS keys for Biz_Ops can create valid signatures and has access to trapdoor info to adapt message from having the Fin and HR attributes from AIA. However, another user, Charlie, who is also part of the Biz_Ops group, cannot adapt the message even though he can produce valid signatures from the GSS membership since he does not have access to the trapdoor info (the extra key that Alice possesses).

Both message and trapdoor adaptations require verification on the miner's part before updating the given transaction on a block. The first check is a simple RCHET verification of the message hash and rand. The second step is to check that the group signatures, which are provided with the message update, satisfy the respective group signature policies defined in γ_info and γ_ABEAdmin. A message adaptation in retrace results in m and rand components getting updated to m′ and rand′ while a trapdoor adaptation results in γ_info also getting updated because it contains the trapdoor info. Just as a note, there are two kinds of trapdoor adapts in Retrace. Case 1 is when a policy on a retrace message is updated to eliminate trapdoor access for an entire attribute group. And Case 2 is when the trapdoor policy remains the same but a user in one of the attribute groups had their keys revoked and hence the trapdoor needs to be updated and re-encrypted with the new keys for the ABE process—this is discussed in more detail in the foregoing text of this application.

In RFAME, when a user is revoked from an attribute group and the message is re-encrypted with the new public key of the AIA, the attribute groups in the policy who were not revoked will still be able to decrypt the data with their original keys. This avoids the need to re-encrypt messages having policies with the revoked attribute group, here M2 and M3. But the re-encrypted data M1′ cannot be decrypted with the old keys of the revoked attribute A. This is a high-level overview of the specific efficiency achieved by RFAME in the revoke operation when compared to the related work. We refer you to the paper for the detailed algorithms and the math supporting the scheme.

Example 2

RFAME, RCHET, and ReTRACe was implemented in Python 3, and Charm was used for cryptographic modules. All the experiments were carried out on a machine with 64 GB RAM and an Intel® Core™ i7-6700K CPU clocked at 4.00 GHz. RCHET and RFAME were implemented to compare their performance against CHET and FAME, respectively, to quantify the price of adding revocation. RFAME was not compared quantitatively with other revocable ABE methods and/or systems, since they do not provide the properties that RFAME provides. Using RCHET and RFAME, ReTRACe was implemented. Note that ReTRACe is the first system that provides transaction-level revocable blockchain rewrites, there is no equivalent state-of-the-art method and/or system to compare it with.

RFAME Results: We set our ABE policies to contain a total of 8, 16, 32 and 64 attributes, and all our policies have two equisized conjunctive clauses separated by a single disjunction. In each run, 10, 20, 40, or 80 users signed up with the AIA for each attribute. The computation time increased linearly with the number of users. So, for brevity, FIGS. 6A and 6B illustrate results for RFAME and FAME for 80 users per attribute only, with 6A illustrating key generation and setup times and with 6B illustrating encryption and decryption times. The setup times for RFAME w higher than for FAME because of the extra operations involved in computing the master public key (mpk_ABE) and master secret key (msk_ABE) during setup; and the growth of the public key size in RFAME was linear in the number of attributes (small-universe property).

In FAME, the size of one of the components of the ciphertext increased linearly in the number of attributes satisfying the given policy, whereas for RFAME there were two components whose size increased linearly, accounting for the difference in their encryption and decryption timings. For decryption, the number of pairing operations in RFAME was 6+2×(number of attributes satisfying a given policy), as compared to 6 pairing operations for FAME.

Table 1 shows the time taken when revoking one user from each attribute group with 10, 20, 40, and 80 users each, which resulted in the rekeying of the remaining users. The results were linear as expected because in each case 9, 19, 39, and 79 users got new keys, respectively. This trend is expected to continue as the number of users per attribute increases.

TABLE 1
Timing for the RFAME.Revoke (time in secs)
10 Users per attribute 0.115
20 Users per attribute 0.2
40 Users per attribute 0.364
80 Users per attribute 0.714

As mentioned previously in the application, previously known methods do not provide efficient revocation. To carry out a user revocation under previously known methods, the entire system would have to be rekeyed using the Setup and Keygen functions, and all ciphertext re-encrypted regardless of whether the revoked user had access to the message or not. Thus, the cost in rekeying the users is significantly lower in RFAME, especially when the revoked user is in a single attribute group.

RCHET Results: Table 2 compares the running times for CHET and RCHET. In RCHET, when compared to CHET, one extra encryption and decryption, two NIZKPoK generation and verifications, and three modular exponentiations were added to all functions, except systemSetup and userKeySetup. Despite this, RCHET did not display a significant increase in latency, at the same time providing the ability to adapt the trapdoor of a message digest. The time difference between RCHET and CHET algorithms was in the order of milliseconds and this was a minimal trade-off for the added functionality that RCHET provided.

TABLE 2
Comparison of RCHET vs. CHET [10] (time in secs)
	Algorithm	CHET	RCHET
	Setup	0.537	0.5369
	Chash	0.0216	0.0234
	Verify	0.000697	0.000967
	Adapt Message	0.0414	0.0415
	Adapt Trapdoor	—	0.04305

ReTRACe Results: ReTRACe was implemented with the DGSS policies being the same as the ABE policies and containing 20 users per attribute for 8 and 16 attributes. Except for the RFAME revocation component, whose running time is proportional to the number of users, the rest of the cryptographic primitives, i.e., DGSS, RCHET, and other RFAME algorithms, are independent of the number of users in the system. The running time for operations in ReTRACe were found to increase linearly with the number of users per attribute, as illustrated in the RFAME results.

Table 3 shows the timings of ReTRACe, with 20 users/attribute and messages with policies containing 8 and 16 attributes respectively. UserSetup and Keygen take significantly more time than the other functions as expected; both these functions involve all users in the system and are run only once at the beginning during system and users' setup. CreateMessage, Sign, Verify, and VerifyMiner were run more frequently, and all had sub-second timings. For testing Case 1 of ReTRACe.RevokeUser, we eliminated one attribute from γ_ABE, and in Case 2 we revoked one user from the AIA that held an attribute in γ_ABE. Case 2 took longer because it included the AIA's operations for revoking a user from one attribute group and rekeying of the rest of the users in the same group, whereas Case 1 just changed the message policy and updated the message trapdoor.

TABLE 3
ReTRACe running time, 20 users/attribute (secs)
ReTRACe Algorithms	8 Attr	26 Attr
UserSetup and Keygen (for 20 users)	2.997	4.694
CreateMessage	0.473	0.963
Sign	0.0904	0.180
Verify	0.114	0.232
Verify Miner	0.225	0.460
AdaptMessage	0.0928	0.152
RevokeUser (Case1)	0.545	1.015
RevokeUser (Case 2) (for 19 users)	0.676	1.049

The preceding examples can be repeated with similar success by substituting the generically or specifically described components and/or operating conditions of embodiments of the present invention for those used in the preceding examples.

Optionally, embodiments of the present invention can include a general or specific purpose computer or distributed system programmed with computer software implementing steps described above, which computer software may be in any appropriate computer language, including but not limited to C, C++, FORTRAN, BASIC, Java, Python, Linux, assembly language, microcode, distributed programming languages, etc. The apparatus may also include a plurality of such computers/distributed systems (e.g., connected over the Internet and/or one or more intranets) in a variety of hardware implementations. For example, data processing can be performed by an appropriately programmed microprocessor, computing cloud, Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), or the like, in conjunction with appropriate memory, network, and bus elements. One or more processors and/or microcontrollers can operate via instructions of the computer code and the software is preferably stored on one or more tangible non-transitive memory-storage devices.

Note that in the specification and claims, “about”, “approximately”, and/or “substantially” means within twenty percent (20%) of the amount, value, or condition given. All computer software disclosed herein may be embodied on any non-transitory computer-readable medium (including combinations of mediums), including without limitation CD-ROMs, DVD-ROMs, hard drives (local or network storage device), USB keys, other removable drives, ROM, and firmware.

Embodiments of the present invention can include every combination of features that are disclosed herein independently from each other. Although the invention has been described in detail with particular reference to the disclosed embodiments, other embodiments can achieve the same results. Variations and modifications of the present invention will be obvious to those skilled in the art and it is intended to cover in the appended claims all such modifications and equivalents. The entire disclosures of all references, applications, patents, and publications cited above are hereby incorporated by reference. Unless specifically stated as being “essential” above, none of the various components or the interrelationship thereof are essential to the operation of the invention. Rather, desirable results can be achieved by substituting various components and/or reconfiguring their relationships with one another.

Claims

1. A method for editing records on a blockchain comprising: creating a mutable record, a digest of the mutable record, along with a long-term trapdoor, an ephemeral trapdoor, and a plurality of tuples that regulate record edits;the mutable record comprising an immutable portion and an editable portion, the immutable portion comprising the long-term trapdoor and the digest of the mutable record;modifying a hash verification function of the blockchain to perform verification of the mutable record; andmodifying the blockchain such that when a block containing the mutable record is added to the blockchain, only the immutable portion of the mutable record is used in a block hash calculation.

2. The method of claim 1 further comprising onboarding an originator of the mutable record with attribute-issuing authority and signature-key issuing authority before creating the mutable record, the digest of the mutable record, the long-term trapdoor, the ephemeral trapdoor, and the plurality of tuples that regulate the record edits.

3. The method of claim 1 further comprising, prior to modifying the blockchain, establishing a set of authorized users who can edit the mutable record by creating a record collision on the digest of the mutable record after the block containing the mutable record has been posted on the blockchain.

4. The method of claim 1 wherein creating the digest of the mutable record and the ephemeral trapdoor contained in the mutable record comprises using a revocable chameleon hash algorithm to allow authorized users to edit the editable portion of the mutable record while keeping the immutable portion unchanged.

5. The method of claim 1 wherein the editable portion of the mutable record need not be selected from a predetermined list.

6. The method of claim 1 further comprising providing access control of the ephemeral trapdoor and the long-term trapdoor and wherein providing access control comprises using a revocable attribute-based encryption algorithm wherein a set of authorized administrators decides, grants and revokes record editing privileges.

7. The method of claim 1 further comprising updating the ephemeral trapdoor using a revocable chameleon hash algorithm.

8. The method of claim 1 further comprising providing a policy which spells out dynamic group signature system groups from which one or more users can anonymously sign a record edit and post it on the blockchain.

9. A non-transitory computer readable medium comprising computer software stored thereon providing editing of records on a blockchain comprising: code allowing the creation of mutable record, a digest of the mutable record, a long-term trapdoor, an ephemeral trapdoor, and a plurality of tuples that regulate record edits wherein the mutable record comprises an immutable portion and an editable portion, the immutable portion comprising the long-term trapdoor and the digest of the mutable record;code modifying a hash verification function of the blockchain to perform verification of the mutable record; andcode modifying the blockchain, such that when a block containing the mutable record is added to the blockchain, for each mutable record in the block, only the immutable portion of the mutable record is used in a block hash calculation.

10. The computer readable medium of claim 9 further comprising code onboarding an originator of the mutable record with attribute-issuing authority and signature-key issuing authority before creating the mutable record, the digest of the mutable record, the long-term trapdoor, the ephemeral trapdoor, and the plurality of tuples that regulate the record edits.

11. The computer readable medium of claim 9 further comprising code which, prior to modifying the blockchain, establishes a set of authorized users who can edit the mutable record by creating a collision on the digest of the mutable record after the block containing the mutable record has been posted on the blockchain.

12. The computer readable medium of claim 9 wherein code creating the digest of the mutable record and the ephemeral trapdoor contained in the mutable record comprises code applying a revocable chameleon hash algorithm to allow authorized users to edit the editable portion of the mutable record while keeping the immutable portion unchanged.

13. The computer readable medium of claim 9 wherein the code does not require the editable portion of the mutable record to be selected from a predetermined list.

14. The computer readable medium of claim 9 wherein said computer readable medium further comprises code providing access control of the ephemeral trapdoor and wherein the code providing access control comprises code using a revocable attribute-based encryption algorithm wherein a set of authorized administrators decides, grants and revokes record editing privileges.

15. The computer readable medium of claim 9 further comprising code updating the ephemeral trapdoor using a revocable chameleon hash algorithm.

16. The computer readable medium of claim 9 further comprising code providing a policy which spells out dynamic group signature system groups from which one or more users can anonymously sign a record edit and post it on the blockchain.