Trusted Data Notifications from Private Blockchains^#

We make the following assumptions:

Our protocol must ensure the following:

The Bootstrap stage need only be done once for a given $\langle$recipient, LD$\rangle$ pair. In Figure 2 first, the SC-ACL contract must be installed in PrivBC through the network’s consensus process. This needs to be done just once in the lifecycle of the network. This contract supports the registration of external recipients’ public keys (or certificates) for identification and cryptographic purposes. We assume that recipient $\mathsf{R}$ can communicate its public key ($pk_{\mathsf{R}}$) separately to every member of the network as indicated in Figure 2, and that the key is committed through consensus to ledger using SC-ACL’s PermitAccess operation. Optionally, $\mathsf{R}$ may submit $pk_{\mathsf{R}}$ within a certificate signed by authorities that can be validated in this operation. As the figure also indicates, we assume the data item that $\mathsf{R}$ has been given access to (LD) is already recorded on the ledger.

$\mathsf{R}$ can confirm through a VRS (see Section II-A) that (i) $pk_{\mathsf{R}}$ has been associated with LD on PrivBC’s ledger, and (ii) that PrivBChas authorized $\mathsf{R}$to receive any future updates made to LD.

The goal of the generation step is for $\mathsf{N}$ to commit to the contents of the notification while also proving (using a zero knowledge proof) that the notification contains valid updates from the ledger. When LD is updated on PrivBC’s ledger by any $\mathsf{C}$, a call to SC-ACL is triggered using PrivBC’s transaction submission mechanism. At this point, LD already has signatures endorsing it on the chain (ledger), so this call can package LD with the signatures into ELD (or endorsed LD). The following are produced and recorded on the ledger using the RecordEncDataHashProof operation, as illustrated in Figure 3:

• •

  $\textsf{ELD}_{\mathsf{R}}$: a deterministic public-key encryption of ELD using $pk_{\mathsf{R}}$ ensuring only $\mathsf{R}$ can decrypt the notification

• •

  H${}_{\textsf{ELD}_{\mathsf{R}}}$: a hash of $\textsf{ELD}_{\mathsf{R}}$ as a commitment¹¹1a randomized commitment scheme is used, with the randomness/opening to the commitment recorded on PrivBC and later recorded on PubBC during the KeyTransfer stage.

• •

  $\pi_{\textsf{ELD}_{\mathsf{R}}}$: a zero-knowledge proof that can be used to verify, without knowing $\textsf{ELD}_{\mathsf{R}}$, that $\textsf{ELD}_{\mathsf{R}}$ was produced by encrypting some plaintext under $pk_{\mathsf{R}}$.

We will use the Encrypt-with-Hash construction in Bellare et al. [26] as our deterministic encryption scheme with the ElGamal encryption scheme [27] as the underlying randomized public-key encryption scheme. This deterministic encryption provides PRIV-CCA security [26] and it’s good enough to provide confidentiality to ELD since the underlying unforgeable signatures are ‘unpredictable’. For this encryption, the zero-knowledge proof $\pi_{\textsf{ELD}_{\mathsf{R}}}$ is generated using a pair of discrete-log exponent checks followed by a hash check.

$\mathsf{N}$ now privately generates a symmetric key $k$ (we use AES-CTR²²2IND-CPA security provided by AES-CTR is sufficient as we show in section IV) and further encrypts $\textsf{ELD}_{\mathsf{R}}$ into $\textsf{ELD}_{\mathsf{R},k}$. This second layer of encryption is to prevent $\mathsf{R}$ from learning $\textsf{ELD}_{\mathsf{R}}$ (and hence ELD) before the next step. On PubBC, $\mathsf{N}$ records the following through the RecordCipherTextHashProof operation on the SC-Reward contract:

• •

  Doubly encrypted data ($\textsf{ELD}_{\mathsf{R},k}$)

• •

  Hash H${}_{\textsf{ELD}_{\mathsf{R}}}$ of the singly encrypted $\textsf{ELD}_{\mathsf{R}}$, which is recorded on PrivBC’s ledger after consensus among its members

• •

  Zero-knowledge proof $\pi_{\textsf{ELD}_{\mathsf{R}}}$

• •

  Signatures validating PrivBC’s collective endorsement of $\mathsf{R}$’s authorization to access LD: Sigs-R-ELD; generated on the private chain upon successful conclusion of the RecordEncDataHashProof operation

The proof $\pi_{\textsf{ELD}_{\mathsf{R}}}$ is now verified using $pk_{\mathsf{R}}$, which was recorded on the ledger in the bootstrap stage, and H${}_{\textsf{ELD}_{\mathsf{R}}}$. If the verification succeeds, i.e., the proof and the hash are authentic, it implies that the hash was produced from data which itself was generated by encrypting a different data element using $pk_{\mathsf{R}}$. (We will see why this is useful when the preimage of the hash is revealed in the next stage.) If the verification fails, the protocol terminates at this stage.

The remaining steps of the protocol occur on PubBC and do not involve PrivBC.

The goal of the key transfer stage is to enable $\mathsf{N}$ to share the symmetric key $k$ with $\mathsf{R}$ in exchange for collecting a signature from $\mathsf{R}$ that allows $\mathsf{N}$ to collect its reward in later stages of the protocol. The main innovative feature of our protocol, illustrated in Figure 4, is a pair of interlocking contracts, inspired by the HTLC mechanism, that allow $\mathsf{N}$ to share its symmetric key ($k$) in exchange for $\mathsf{R}$’s signature on the resulting decrypted data. First, $\mathsf{N}$ must install contract SC-R-Sign, which obligates $\mathsf{N}$ to transfer an amount $\mathsf{A}$ to $\mathsf{R}$ if the latter submits a verifiable signature over data generated by decrypting $\textsf{ELD}_{\mathsf{R},k}$ using $k$. Once $\mathsf{R}$ can see this contract installed, it must install SC-N-Key, which promises to transfer the same amount $\mathsf{A}$ to $\mathsf{N}$ if the latter provides a valid key $k$.

Let us assume $\mathsf{N}$ supplies $k$ to SC-N-Key. Decryption of $\textsf{ELD}_{\mathsf{R},k}$ produces $\textsf{ELD}_{\mathsf{R}}^{\prime}$, which ought to be identical to $\textsf{ELD}_{\mathsf{R}}$ produced in the generation stage.Verification of this involves checking that the hash H${}_{\textsf{ELD}_{\mathsf{R}}}$ is indeed a hash of $\textsf{ELD}_{\mathsf{R}}^{\prime}$. If this check succeeds, it also proves that the preimage $\textsf{ELD}_{\mathsf{R}}^{\prime}$ is ciphertext that was generated by encrypting some plaintext using $pk_{\mathsf{R}}$; this follows from the successful verification of the zero-knowledge proof $\pi_{\textsf{ELD}_{\mathsf{R}}}$ at the end of the Generation Stage. $\mathsf{A}$ is transferred to $\mathsf{N}$ as promised if verification succeeds; otherwise, no amount is transferred and the protocol terminates.³³3Stopping the protocol if $N$ produces an $\textsf{ELD}_{\mathsf{R}}$ encrypted under a different public key is not mandatory. As an alternative, we can delay the validity check on $\textsf{ELD}_{\mathsf{R}}$ till the final verification stage. This will make $\mathsf{R}$ proceed till the final step even if $\textsf{ELD}_{\mathsf{R}}$ is invalid. But, the collision resistance property of the hash function will be enough to ensure honest behaviour of $\mathsf{R}$ and $\mathsf{N}$ without the need for zero-knowledge proofs.

Now $\mathsf{R}$ must play its part by supplying a receipt in the form of a signature over the decrypted data $\textsf{ELD}_{\mathsf{R}}^{\prime}$ to SC-R-Sign: $\sigma_{\mathsf{R},\textsf{ELD}_{\mathsf{R}}^{\prime}}$. If it provides a valid signature that can be verified using $pk_{\mathsf{R}}$, amount $\mathsf{A}$ is transferred back from $\mathsf{R}$ to $\mathsf{N}$, and the net monetary exchange is zero. If $\mathsf{R}$ does not supply a signature within a given time period or supplies an invalid signature, it ends up forfeiting $\mathsf{A}$.

Last but not least, both SC-R-Sign and SC-N-Key contain embedded timeouts (similar but not identical to time locks). SC-N-Key has a timeout $t$ just to ensure that $\mathsf{R}$ does not wait indefinitely for $\mathsf{N}$ to provide $k$. If $t$ expires, the protocol terminates without anyone losing money. But if $\mathsf{N}$ does supply a valid $k$ within $t$, $\mathsf{R}$ is obliged to provide its receipt signature within a timeout $t^{\prime}$ encoded in SC-R-Sign. $t^{\prime}$ must be chosen to be significantly greater than $t$ so that $\mathsf{R}$ gets ample opportunity to supply a signature after $\mathsf{N}$ supplies $k$.

In the final stage, our protocol verifies the validity of the notification received by $\mathsf{R}$ and rewards PrivBC members for a successful notification. To claim the reward ($\mathsf{a}$) for itself and all members of PrivBC, $\mathsf{N}$ can now submit $\mathsf{R}$’s signature $\sigma_{\mathsf{R},\textsf{ELD}_{\mathsf{R}}^{\prime}}$, obtained in the previous stage as evidence to SC-Reward (see Figure 5). A timer starts upon this submission, and $\mathsf{R}$ is given the opportunity to challenge the veracity of the received data within a given time period (call it Timeout). $\mathsf{R}$ now has $\textsf{ELD}_{\mathsf{R}}^{\prime}$, which can be decrypted using $sk_{\mathsf{R}}$, the private key corresponding to the public $pk_{\mathsf{R}}$.

The produced Dec-LD ought to be well-formed, contain LD and enough signatures from PrivBC members to prove consensus. The set of enclosed signatures should have been created by members whose public keys were recorded to PubBC in the Bootstrap Stage, and the set of signatories should match those of Sigs-$\mathsf{R}$-ELD, supplied in the Generation Stage to prove that $\mathsf{R}$ was authorized to get access to LD. Signatures in Sigs-$\mathsf{R}$-ELD should be validated as well, given that ELD (LD plus signatures) has been decrypted. The value of LD should be fresh and not an older version (a form of replay attack mounted by $\mathsf{N}$).

If any of these conditions are unsatisfied, $\mathsf{R}$ can choose to record Dec-LD on the ledger and SC-Reward can verify whether $\mathsf{R}$’s claims about receiving invalid data are correct. If that is the case, no reward is transferred to members of PrivBC, an amount is transferred from $\mathsf{N}$ to $\mathsf{R}$ as penalty for spurious information, and the protocol terminates. Otherwise, when Timeout occurs, $\mathsf{R}$’s receipt signature $\sigma_{\mathsf{R},\textsf{ELD}_{\mathsf{R}}^{\prime}}$ is verified. Upon success, reward amount $\mathsf{a}$ is transferred from $\mathsf{R}$ to PrivBC’s members, with $\mathsf{N}$ getting an extra amount to cover its transaction costs in PubBC. Upon failure, $\mathsf{R}$ pays no reward and $\mathsf{N}$ pays an amount in penalty to $\mathsf{R}$. The protocol now terminates.

ETLC ensures that the notification received by $\mathsf{R}$ accurately represents LD after it has been updated in PrivBC.

Proof sketch. The members of PrivBC obtain a reward from SC-Reward at the end of a successful run of the protocol. This happens when $\mathsf{R}$ does not submit an invalid Dec-ELD to SC-Reward. At a high level, the proof of this claim will follow the following outline: the unforgeability of signatures and the soundness of zero-knowledge proofs will ensure that a rational $\mathsf{R}$ will not submit Dec-ELD only if it corresponds to a valid LD in PrivBC.

To notify $\mathsf{R}$, $\mathsf{N}$ submits two transactions to PubBC:

• •

  $\mathsf{N}$ first submits $\textsf{ELD}_{\mathsf{R},k}$, H${}_{\textsf{ELD}_{R}}$, $\pi$, Sigs-$\mathsf{R}$-ELD to SC-Reward.

• •

  Then, $\mathsf{N}$ records a key $k$.

These actions lead to the following automatic actions by the smart contracts which cannot be altered by $\mathsf{N}$ or the members of PrivBC after they are installed:

• •

  SC-Reward verifies the zero-knowledge proof $\pi$ – ensures that $\mathsf{N}$ knows of an entry (i) which is an encryption of a message under the public key $pk_{\mathsf{R}}$ and (ii) whose hash is H${}_{\textsf{ELD}_{\mathsf{R}}}$

• •

  SC-N-Key decrypts $\textsf{ELD}_{\mathsf{R},k}$ with $k$, verifies its hash with $\textsf{ELD}_{\mathsf{R}}$ and finally transfers the amount $\mathsf{A}$ from $\mathsf{R}$ to $\mathsf{N}$ if hash is valid – given the above zk proof, collision resistance of $H$ ensures that $\textsf{ELD}_{\mathsf{R}}$ is an encryption of some message under $pk_{\mathsf{R}}$; note that the secret key encryption scheme need not be robust [28], even if $\mathsf{N}$ has the opportunity to provide a different key $k^{\prime}$ to decrypt to a different $\textsf{ELD}_{\mathsf{R}}^{\prime}$ post the submission of $\textsf{ELD}_{\mathsf{R},k}$, since the hash collision-resistance and proof’s soundness ensure that the resulting ciphertext is an encryption under $pk_{\mathsf{R}}$.

The above construct ensures that $\textsf{ELD}_{\mathsf{R}}$ encrypts a message that can be decrypted using $\mathsf{R}$’s secret key. Here, $\mathsf{R}$ can decrypt and check the validity of the message, confirming that that it is a valid LD with signatures from PrivBC. Even after $\mathsf{R}$ acknowledges receipt of $k$ from $\mathsf{N}$ by submitting its signature on $\textsf{ELD}_{\mathsf{R}}$, as a rational actor, it can subsequently submit a decrypted ELD if it turns out to be invalid. This will ensure that $\mathsf{N}$ does not get the reward, and additionally is penalized.

This property of ETLC ensures that $\mathsf{R}$ gets notified of any update to LD.

Proof sketch. This is ensured by the rationality of the members of PrivBC, who are incentivized to claim a reward from $\mathsf{R}$ through the smart contract SC-Reward upon sending an endorsed LD.

Members of PrivBC and $\mathsf{R}$ decide on a reward to be paid by $\mathsf{R}$ when $\mathsf{R}$ receives a valid notification on LD from $\mathsf{N}$. ETLC ensures that they obtain the agreed upon reward when the notification is received by $\mathsf{R}$.

Proof sketch. $\mathsf{R}$ receives the ciphertext $\textsf{ELD}_{\mathsf{R}}$ containing the notification only after $\mathsf{N}$ records the key $k$ on PubBC. Even though $\mathsf{N}$ commits $\textsf{ELD}_{\mathsf{R},k}$, H${}_{\textsf{ELD}_{\mathsf{R}}}$, $\pi$ and Sigs-$\mathsf{R}$-ELD to PubBC, $\mathsf{R}$ does not learn any information about $\textsf{ELD}_{\mathsf{R}}$, and hence about ELD, before $\mathsf{N}$ records $k$ due to the semantic security of the secret key encryption scheme, hiding of the commitment scheme and the zero-knowledge property of the proof system. After $\mathsf{N}$ records $k$, SC-N-Key transfers the amount $\mathsf{A}$ from $\mathsf{R}$ to $\mathsf{N}$. Since this amount $\mathsf{A}$ is higher than the reward that it would send to members of PrivBC, a rational $\mathsf{R}$ would send its signature on $\textsf{ELD}_{\mathsf{R}}^{\prime}$ to confirm its receipt. Unless $\mathsf{R}$ submits decryption of an invalid Dec-ELD before the pre-decided challenge timeout, the reward is automatically transferred to the PrivBC members just on $\mathsf{R}$’s confirmation of receipt of $\textsf{ELD}_{R}^{\prime}$. If the $\textsf{ELD}_{\mathsf{R}}^{\prime}$ sent by $\mathsf{N}$ is valid, to prevent the reward from being transferred, $\mathsf{R}$ should submit a Dec-ELD which upon encryption should yield $\textsf{ELD}_{\mathsf{R}}^{\prime}$, since we use a deterministic encryption scheme. But it is not possible for $\mathsf{R}$ to submit a different Dec-ELD which results in the same $\textsf{ELD}_{\mathsf{R}}^{\prime}$ due to the robustness of the public-key encryption scheme.

This property prevents a malicious $\mathsf{R}$ from denying knowledge of ELD after it has obtained ELD through ETLC.

Proof sketch. As mentioned in Claim IV.3, $\mathsf{R}$ does not learn any information about ELD, and hence about LD, before $\mathsf{N}$ records $k$ due to the semantic security of the secret key encryption scheme and the zero-knowledge property of the proof system. Hence, $\mathsf{R}$ has to wait for $\mathsf{N}$ to record $k$ on PubBC. But a rational $\mathsf{R}$ has to send a signature confirming its receipt of $\textsf{ELD}_{\mathsf{R}}$ since we set $\mathsf{A}>>\mathsf{a}$. This signature along with the hash and zero-knowledge proof (that H${}_{\textsf{ELD}_{\mathsf{R}}}$ is an encryption under $pk_{\mathsf{R}}$) serve as a proof recorded on PubBC that $\mathsf{R}$ has received a message from $\mathsf{N}$ that only it can decrypt.