Topics

Misc thoughts on end user computing

Mike Hearn
 

The talk I gave at the end of DevDay is now online:

 

https://www.youtube.com/watch?v=BDQGq14irbM

 

Unfortunately the slides are an 800 megabyte Keynote file, so they aren’t uploaded anywhere.

 

The CordaChat app I wrote for the talk is available here: https://github.com/mikehearn/cordachat  -  Rich G, you asked for it, here it is. We are coming for you Slack 😊

 

The mysterious announcement I refer to in the section on artificial intelligence was our partnership with Her Majesty’s Land Registry. If you can buy and sell land using Corda then we’re one step closer to the AI-run economy I was talking about.

 

The Graviton app browser I demoed is an open source project that I’m working on occasionally in my evenings and weekends (this is a simple way to avoid arguments about whether it’s worth doing or not 😃). There will probably be a first release within a month or two, depending on the weather / what’s on TV etc.

 

I am looking for volunteers! If you’re interested let me know and I’ll send you a link to the GitHub repo and chatroom. I could use someone good at web design to help make a nice website for it, and people who enjoy GUI programming.

 

As it develops further I’ll start making announcements here and in other forums. Although I feel client-side UIs for Corda/business apps are important for the reasons outlined in my talk, Graviton is not really Corda specific. I plan to abuse my admin privileges by sometimes emailing news here anyway.

 

Scaling down. In the talk I ponder what it’d take to reach millions of apps, and what such apps might look like. Scaling is also about how many firms use Corda. We just posted about MAXIMUS, the project to let the node scale up to hosting lots of third party identities. We’re also thinking about how to scale Corda down such that small firms can take part directly, with their own node and private key kept on site.

 

There are several problems we need to solve to empower small firms to sign their own transactions and manage their own data on Corda. “Small firm” here is defined as any firm that does not have an IT department, or which outsources whatever minimal IT they do have.

 

Why might a small firm want to in-source the node? Because:

 

  1. They wish to take part in multiple potentially competing business networks at once, and thus the BNOs are not natural homes for their node.
  2. They want or need to keep data local to their territory.
  3. Cost savings.
  4. They are afraid of data being stolen from, or abused by, the service provider.
  5. Their node host doesn’t provide enough access e.g. no direct API calls, no ability to reconfigure, limited selection of apps.
  6. Digital signatures might stop being legal signatures if the key was given to another party, in their territory.
  7. The business they’re doing on Corda is their core competency.

 

Based on the experience of making consumer Bitcoin wallets I argue the following problems are prime:

 

  • Backup
  • Private key recovery
  • Installation and upgrade

 

If we can solve those three the other problems are easy.

 

Backup and private key recovery are not the same, because if you encrypt your backups under your private key you can suddenly outsource the disk storage to third parties without risk – storing bytes is a commodity business without any lockin potential, and you normally want backups to be offsite anyway. Even something free like Google Drive or OneDrive will work.

 

If you do use this backup strategy you at least need to keep your private key safe. There’s no good way to back that up without granting the backup site the same powers you have.

 

Encoding private keys as words. Private keys are unique for another reason – they are valuable but small enough to be written down using ordinary pen and paper. Even a printer is not required. This makes them easy to back up in an intuitive way. All businesses should have at least enough competence to keep some bits of paper safe.

 

Here's what this looks like:

 

 

These “seed words” are selected from a predefined dictionary. 12 words are sufficient to encode 128 bits of entropy. Add more words to incorporate some metadata. This is effectively a randomly generated password but with cryptographic strength.

 

Using an approach like BIP-32 these 12 words can be iterated into all the keys needed. You never require more than one root key, even when using lots of randomized keys as part of confidential identities.

 

Social private key recovery. But let’s imagine that they lose the words. Perhaps the node is set up by someone who doesn’t understand the private key is important. Perhaps they have terrible handwriting and whoever tries to recover the key can’t read the piece of paper. Perhaps the key was itself encrypted under a passphrase and the passphrase is forgotten.

 

Blockchain systems implicitly assume that loss of a private key = loss of everything. This is harsh. There are very few IT mistakes a business can make that will completely destroy them overnight. Automated trading is one case (Knight Capital), getting ransomware in your network is another (NotPetya attack). We probably shouldn’t add a third.

 

In particular it’s hard to lose access to your bank account. Even if a hurricane sweeps away your entire office, strips you naked and destroys all your ID documents, you can probably turn up at your bank and get your account access back. They have your photo and details on file after all and maybe know you personally. It’s a form of social recovery – you know me, so give me back my stuff. That’s pretty good. Unfortunately it also makes your bank a super-admin of your business and we’re trying to avoid creating more of those.

 

We can implement social recovery in a decentralized way using Shamir’s secret sharing. Shamir’s scheme is quite straightforward. Using it like this was discussed years ago. I’ll briefly describe it here.

 

In SSS a secret number can be split into n “shares”, of which a subset k of them can be recombined to recover the original secret. The shares by themselves are useless to the holders and just look like random numbers.

 

For example, you might take your private key, split it into 5 shares, and require 3 of them to be recombined to recover the key. Now distribute those 5 shares to 5 different companies who you trust to not collaborate against you. Perhaps it could be a service provided by notary operators, given we already make a threshold-anti-collaboration security assumption about them. When you prove your identity to any of them (maybe they charge a fee for this), they agree to give you back the share they possess. After you recover enough shares you can recover your private key, and from that your vault backups, even in the case where your entire IT infrastructure and all paper key backups have been destroyed.

 

SSS is based on the observation that you can encode a secret as the first coefficient of a randomized polynomial and recover it by using Lagrange interpolation. It is quite straightforward to implement.

 

Installation and upgrade.  With solutions in hand for backup and key recovery, we move on to local installation and maintenance.

 

Making P2P apps that work well in a  consumer context is a well-studied problem. IPv6 helps a lot, STUN and UPnP can negotiate crossings of consumer firewalls. When all these techniques fail, you fall back to routing traffic via remote servers. If we added end-to-end encryption to the Corda protocol, we could produce “buffer nodes” that have no intelligence themselves. They simply proxy message traffic for the real nodes, sitting behind firewalls. If the node goes offline the buffer node will spool messages to disk until the node comes back (i.e. they are just MQ brokers). There is no obligation for the node to be always online. It would be fine for it to run only during office hours.

 

Graviton is a JVM and application update engine. It’s triggered by a scheduled task, knows how to update apps whilst they are running, or whilst they aren’t. It resolves software from Maven repositories. It has first class support for command line apps, not just GUI apps. With a few more features it could easily handle installation and upgrade of Windows services.

 

Intel SGX allows for the generation of private keys in malware resistant ways if the PC is recent enough and Intel PVP is sufficient to show the resulting words to the user for backup. Chips with the needed features have been on sale for years so by this time this scheme was implemented, many businesses would have at least a few machines that could do it.

 

Thus we can see a path forward here. A new user verifies their identity with some identity broker, like a bank. As part of the workflow they “Sign in with Google” or Microsoft or DropBox or whoever. At the end of the ID verification user experience, a personalized EXE file is made available for download. The EXE contains a one-time-use token representing the verified identity, and an auth token for access to their cloud drive. Double clicking it immediately and without further interaction installs the application, which generates a private key (hopefully inside an enclave), gets the user to write down the words on a piece of paper, then swaps the one-time-use token baked into the installer for a signed certificate containing the public key and a buffer node endpoint. It registers that endpoint with the network map, opens up an app marketplace of some sort for the user to pick what they want, and off you go.

 

This user experience is no harder than installing Microsoft Office, and we know even very small businesses run by IT unsavvy people can handle that.

 

I don’t think R3 will work on any of the pieces needed for it this year. It can go faster if you volunteer to help. Most of the pieces are small and easy to do:

 

  • Add support for uploading encrypted vault backups to consumer drives.
  • Add support for running Windows services to Graviton, and pre-binding specific apps to the Graviton Windows installer.
  • Add support for binding the running node to a pre-verified identity. This would integrate nicely with the Corda Testnet which does something similar already, but for Linux only.
  • Small other misc bits and pieces, like automatically restarting when the node has been upgraded.
  • For adventurous programmers only, end to end encryption of the protocol.

 

If anyone is interested, let me know.

 

 

Konstantinos (Kostas) Chalkias
 

First comment: I love this post.

Second comment: SSS is great, Visual Cryptography is cool, Kurihara XOR-only secret protocol is also a very interesting alternative (even faster than naive SSS implementations).

Third comment: Consider me as a volunteer especially for cryptography related tasks.

Mike Hearn
 

Great!

 

I hadn’t heard of Kurihara et al’s technique before, is there an open access PDF anywhere describing it?

 

Probably the first step is to finish off the HSM work because as part of that, the key store is being upgraded. Then we can implement a software key store that uses BIP-32 style (or simpler) deterministic key derivation, and which can output the private root key as 12 words. There’s code in bitcoinj that implements the algorithm - it’s not entirely trivial so would make sense to reuse it.

 

 

Mike Hearn
 

Oh never mind, I wasn't searching for the right terms. The Kurihara technique is described in this paper:

https://eprint.iacr.org/2008/409.pdf

This paper describes the concept of ramp secret sharing, which is also new to me. I'm not sure it's useful in our context though.

Konstantinos (Kostas) Chalkias
 

Correct. Kurihara et al. state they are faster than naive implementation of SSS, but in practice they are probably very similar. Also, we might not care about efficiency of reconstructing a key anyway, as this will be a rare incident. Btw, I recently came across an SSS implementation over GF(2^8) https://github.com/codahale/shamir which also allows for tiered sharing: e.g. recovering a secret requires two admin shares and three user shares.