Technical Deep Dive with David Braden
This is part one of a two-part series focusing on Holochain, Holo Accounts, and Cryptographic Key Management.
Highlights
- Holochain/Holo Accounts and Keys
1.1 What Are We Talking About? - “Account” Keys and Libsodium
2.1 Holochain Key Derivation
2.2 Holo Browser “Account” Keys
2.3 Hardware Wallets and Holochain
Details
Holochain/Holo Accounts and Keys
In our Leadership & Org post last week, we talked about Holo Accounts. We thought it would be a good idea to go into more depth on the specific technologies and strategies underlying Holochain, Holo Accounts, and cryptographic key management from a developer’s perspective.
The security models for Holochain and Holo have been designed (we hope!) to limit the barriers and complexities of entry as much as possible, without closing the doors to really solid, even paranoid, security models should a user elect them.
This means that, you should get solid security on par with, or better than, the industry standards of the classic, centralized web when running a Holochain application, setting up a HoloPort to host for others, or logging onto a Holo-enabled app from a browser. If you want to take things further and generate your keys on an air-gapped device in a Faraday cage two miles underground and then print them with a dot-matrix printer — go for it!
1.1 — What Are We Talking About?
It’s difficult to even know what we are talking about when we say our “Account.” You’ve got Holochain, Holo hosting, core apps like DeepKey (our key management app), and apps built on top of Holochain, such as our HoloFuel currency app. So to be clear, we think of an account in terms of an individual DeepKey keyset.
Before diving into DeepKey, let’s talk a little bit about seed derivation — the part before you get your hands on the keys.
2 — “Account” Keys and LibSodium
Holochain (and Holo) care about two main cryptographic operations — signatures and encryption. Signatures are used for chain validity; in other words “did person X really create this entry?” Encryption is used both at rest, to secure persisted information on the disk, and in transit, to secure communications between parties.
We have chosen libsodium as the basis of our cryptography, not only to satisfy these operations, but also for the derivation functions it provides.
A user will be able to backup a single seed value and reproduce all the keys generated from it, as well as make use of passwords and passphrases in a manner that is resistant to brute-force attacks.
2.1 — Holochain Key Derivation
You want to run a full Holochain node for yourself, as hosting for others, or both? Great! How do you get set up?
The Holochain Admin UI will ask you a series of questions, the first time you run it. Have you already created a DeepKey account? Would you like to create a new one? Would you like to create a new one with keys generated elsewhere, or generate keys now?
If you want to visit that cage in your bunker to generate your own keys — now is the time! You’ll do all the same stuff Holochain will do, but on a separate device, and bring the resulting encrypted application keys back here.
“Wait? If I’m bringing the private keys back, what’s the point of the air-gap?”
The root seed and the revocation key pairs do not come back. These stay in your bunker.
Each device you want to hook together under your keyset gets a different subset of keys that can be individually revoked, giving security isolation.
If a device is destroyed, and you are fairly certain the keys on it are not compromised, you could use your root seed and a backup of your private chain to rebuild your account on a new device — though you may want to go ahead and revoke the keys to be thorough.
So, what is the derivation process?
First off, we need a passphrase from you. This passphrase isn’t used to generate keys. Anything persisted to disk, presented on the screen, or sent to a printer will be encrypted with this passphrase (see appendix for algorithms). The only exception is if you choose to backup your root seed or revocation seed with a set of mnemonic words (like with a classic cryptocurrency), they will be displayed unencrypted.
Next, we generate some secure randomness then bam! You have a root seed! Libsodium provides a deterministic, index-based derivation function that you can apply multiple times to achieve a hierarchy of seeds. One path from the root leads down a tree that gives revocation keys. One path leads to a set of device seeds. Those device seeds lead to application seeds, which can finally be turned into application key pairs.
Holochain will present you with encrypted backup blobs of the root seed, revocation seed, and bundles for additional devices. You can print these or save them to disk. Afterward, Holochain will shred all this info in memory and forget about it.
Now we need to create a DeepKey entry — but we’ll talk about that next time. First, let’s see how this key generation is different for a Holo end-user working from a browser.
2.2 — Holo Browser “Account” Keys
Password derivation that is resistant to brute-force attacks (i.e. throwing a dictionary at it to see what works) depends upon two things. Firstly, that the hashing or derivation algorithm uses a high amount of memory and CPU, making it slow to try a bunch of different options. Secondly, on what is called salt, which is random, non-secret entropy mixed in with the password so we cannot easily make a reverse lookup table of hashes to passwords.
We want Holo end-users to be able to log into an application from any computer, without having to memorize 24 mnemonic words, or give up control of their private keys to anyone, including the Holo organization or the HoloPort hosts who run their app.
We need a tiny bit of centralization to make this happen. An end-user needs a password and a salt. So if they move to another computer/browser, they would still know their password, but how do they know their salt? The Holo organization is going to host a salt registration service, associating an email address with this salt. We’re looking into using Cloudflare Workers, so even though one company is hosting the service, there will be ~over 160 decentralized points of presence from which to obtain your salt. : )
As a Holo end-user, you will log in with your email and password. The email will be used to look up your salt. The password will not be sent over the Internet in any way; it will remain entirely client-side. The salt and password will be hashed to produce a pre-seed, which will be hashed with the DNA hash of the application with which you are trying to interact to produce a seed that can be used to generate application key pairs.
Now that you have application key pairs, you need to interact with DeepKey in the same manner as a full Holochain node. But first, classic crypto hardware wallets use a very similar hierarchical derivation scheme; can we use them for Holochain too?
2.3 — Hardware Wallets and Holochain
At first glance, there is a lot of similarity between what we’ve been talking about and how hardware wallets work for cryptocurrencies like Bitcoin and Ethereum. Can we use them? For now, we’re saying, “maybe someday.”
First off, Holochain uses cryptography for both signing and encryption. Bitcoin, as an example, uses it exclusively for signatures. It may be possible to write a hardware wallet app to do encryption as well (hardware RSA keys can), or we could keep doing the encryption in software and only move signing to the device.
Secondly, Holochain does a lot of signing — constantly. Every time a node interacts with another node, every time a bit of DHT info is gossiped, every time a query is made, Holochain signs the communication. Can you imagine sitting there with your hardware key, clicking approve each time someone else in the network published a social media post?
No — we’d need to implement some auxiliary signature scheme for specific apps, and logic within the app, to validate this additional layer of signature for certain publish types. But maybe someday.
We’ll talk about DeepKey Key Management, next week.
