Encrypting DAML data

Questions
,
1

Has anyone used any node or react crypto libraries for storing DAML data in an encrypted way?

Any best practices related to this topic ?

2 Likes
2

This is a great question!

You should use signatory/observers to restrict access to the data. The underlying ledger (ok - maybe not the sandbox, but a production ledger) will take care of encryption for you, or it might even restrict access physically by keeping the data on your local node, where other parties are unable to access it altogether! edit: See ledger topologies for an overview of the different approaches that may be used to guarantee privacy. It all depends on the implementation and it’s affinity to our abstract ledger model.

That’s one of the main advantages of DAML - it abstracts all this stuff away for you, and ensures portability across ledgers.

It also means that you don’t have to be a cryptographer and have knowledge of the underlying algorithms; this in turn reduces security risk, leaving the implementation to (hopefully!) a subject-matter expert. By this I don’t mean the cipher, but rather the implementation of the crypto-system as a whole, including details like key management, initialization, operation modes etc.

I’d be interested to hear if this answer doesn’t satisfy you. Is there a particular reason that you want to explicitly have control over privacy in the ledger?

3 Likes
3

Can’t say there are any best practices. The main challenge is that most encryption algorithms act on binary data and DAML doesn’t have a binary type. So you are going to have to encode it into a Text field. Base64 encoding is not a bad choice for that.
As noted in my post on attachments, I would not recommend doing this for large blobs of data, though.

3 Likes
4

Thanks for the insights. It is indeed a great feature from DAML that data is encrypted and is only available for signatory and observers.

My question was prompted by 2 insights:

  1. an operator of the network may not need the necessary access to some critical identification data ( aka triple blinded transactions as per securekey’s implementation - https://www.hyperledger.org/blog/2017/08/15/blockchain-based-digital-identity-how-hyperledger-is-helping-to-turn-hype-into-reality)
  2. Also, given the recent guidelines from “Blinding Identity Taxanomy” (https://docs.kantarainitiative.org/Blinding-Identity-Taxonomy-Report-Version-1.0.pdf) there is a best practice to blind transactions if you have a dataset that contains sensitive identity data fields, by being encrypting them or excluding them from the ‘blinded’ dataset in such a way that the resulting dataset no longer contains readable data in any of the defined fields
1 Like
5

So if I understand correctly, the real concern is that you have some data you don’t want the operator to see - it should be private to the individual parties?

I think again this comes down to the ledger topology you’re using (refer to link from OP), which will determine the visibility the operator has. Sadly, this is nearing the limit of my knowledge on this topic.

Your first link mentions Hyperledger Fabric - we do support it, but someone more familiar with the implementation would need to comment.

Considering the other topologies, and looking specifically at the whitepaper linked on the canton website, page 8 “sample message flow”, it says

First,the submitter (Bob in the example) splits the transaction up according to theDAML privacy model. Next, Bob sends the chopped-up transaction as a batch of messages to the domain’s sequencer. This batch is the confirmation request.Crucially, the messages are encrypted with the recipients’ keys, so the sequencer does not learn the message content.

This implies to me that even the operator of the global sequencer has no visibility under this model - however, I think that the local node operators do still see everything of their local parties. Perhaps somebody else can confirm my understanding?

So, on to the real question: Is it possible to make data party-private (rather than node-private) on the ledger without resorting to explicit encryption? I don’t know - it’s an interesting question, and I hope someone more knowledgeable can chime in.

3 Likes
6

You’re correct, Luciano. In the global-state topologies, whichever node has the global state (e.g., Sandbox, or the current Fabric integration) sees all contract data. There’s no confidentiality protection beyond what the user manually implements (e.g., encrypting the individual fields of the contract before creating the contract over the Ledger API).

In partitioned topologies, such as the ones you get running Canton over either Postgres or Fabric (the latter integration is a prototype), there’s no such central operator, and only the participant nodes that a party is hosted on see the party’s contract data. If you operate your own participant node, then I don’t see why you’d want to bother encrypting data manually.

Now, since DAML is about synchronizing data between multiple parties, you have to trust your counterparties (i.e., other contract stakeholders) to not be careless about the data. This is true regardless of how you protect it, using something like Canton or manually (even if you encrypt it manually, your counterparties can just go and make the encryption keys public if they wish to do so).

3 Likes