Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains

[Ethan Kosakovsky <ethankosakovsky@protonmail.com>]

Chris,

Thank you for taking the time to share your thoughts. I agree there are wide considerations surrounding key handling and storage. I dont think my proposal interferes with that perspective any more than BIP32 itself would. How keys are handled is a separate matter than the cryptography of key derivation and trying to get back to the one single backup that is future proof.

My proposal is not concerned with how the initial master key/seed is generated, just that we have one. My proposal is concerned with how to avoid having to generate more master keys because of the wide adoption of standards that impose restrictions (like BIP39); or the fragmented methods of initialization various wallets; as well as the instances where sharing the BIP39 seed with multiple wallets is undesirable due to security concerns (for example hot and offline wallet); or just plain incompatible standards.

If we were to start everything from scratch, we would obviously do things differently. However, there are already millions of wallets created using existing standards. It's just not possible to reset sadly.

> What I think Ethan is proposing is the ability to turn any child derived
> xprv key into a new set valid seed words that could be used by a wallet or
> other devices that don't understand xprv and will only allow import of new
> seeds words. This gets even more complicated if the seed words are not the
> standard BIP-39 set (which BTW, are not an ideal set of words, the
> selection of the SLIP-39 words is much better).

I am proposing two separate things.

  - that we use fully hardened paths to derive keys in order to derive entropy.
  - that a BIP44 like derivation path can be used to describe what the entropy is intended for

    For example we use the prefix 83696968 (ASCII seed in decimal) `m/83696968'/type'/index'`
      - `type` defines how the entropy will be used
        `0` means use 128 bits of the entropy as input to BIP39, producing a 12 word BIP39 mnemonic
        `4` means use 256 bits of the entropy as the secret exponent to create a compressed WIF (for use as hdseed in Bitcoin Core)

    In this way, we can neatly define the specific use-cases of the entropy maintaining some order.

      - `index` is the key index so we can generate multiple instances of this type of entropy

To answer your question about whether to one-way-transform the resulting k. In practice, k is already safe because it was derived from a fully hardened path which protects the parent tree. However, the purpose here semantically is to be entropy. But k is not entropy, it's a private key on that derivation path. Neither are we exporting and xprv. We want entropy to seed the derivation of something else specified by the `type`. For that reason I consider it important to transform k by way of a hash or hmac. Using HMAC over hash is a decision based on an abundance of caution to ensure ward off unwanted side effects should k be used for a dual purpose, including as a nonce hash(k), where undesirable and unforeseen interactions could occur.

> Though possibly pragmatic, this approach would be a hack – starting with some raw entropy, convert this to an entropy seed, then to words, then hmac to xprv, then derive child keys, then convert that child key to a new entropy seed, then hmac to xprv, and then derive child keys again, etc.

I am not proposing the nesting, although nothing would prohibit it, I'm just proposing one master root key from which all child keychains can be derived and overcome the incompatibilities and impracticalities detailed.

> Let me know if you'd like to participate in the discussions (currently either Github issues or a Signal group for the group)

Sure! What's the URL of the Github?

Ethan


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, March 21, 2020 2:46 AM, Christopher Allen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> I agree with the problem statement in this proposal, but not the proposed solution.
>
> The challenge of safely securing a seed for a single signature is not insignificant. Blockchain Commons has published procedures that we consider the current best practices for cold storage in a free book at http://bit.ly/SmartCustodyBookV101 and in github at https://github.com/BlockchainCommons/smartcustodybook. It currently requires a couple of hours and $200 or more of materials (home safe, 2 ledgers, titanium blanks, etc.) to safely product (significantly less time and money than Glacier Protocol). 
>
> Presumably, people are not going to go to this level of protection for too many keys, thus there needs to be methods to leverage the root seeds that are properly protected.
>
> Currently Blockchain Commons is working on standards for airgap solutions for storing and signing from offline keys. Scenarios include using Shamir and SLIP-39  on an offline device with no-WiFi or Bluetooth, an air-gapped mobile phone in airplane mode, or another dedicated device (for instance the SafeKey device if open source was an option). You would use this device to create and restore seeds, convert seeds from BIP-39 to SLIP-39, derive HD keys, and then use QR code from the device to transfer the generated child keys for use by different apps. In some cases, this offline device could also read QR transactions and sign them. We have working prototypes of this today.
>
> This technique works fine for online Bitcoin apps that accept child keys in the form of xprv (or equivalents) such as those our FullyNoded2 iOS wallet supports, but the problem for other wallets is that you can't go from an xprv back to a seed — the xprv creation is a one-way hmac-sha512 operation (still not convinced this was a good decision). 
>
> What I think Ethan is proposing is the ability to turn any child derived xprv key into a new set valid seed words that could be used by a wallet or other devices that don't understand xprv and will only allow import of new seeds words. This gets even more complicated if the seed words are not the standard BIP-39 set (which BTW, are not an ideal set of words, the selection of the SLIP-39 words is much better). 
>
> Though possibly pragmatic, this approach would be a hack – starting with some raw entropy, convert this to an entropy seed, then to words, then hmac to xprv, then derive child keys, then convert that child key to a new entropy seed, then hmac to xprv, and then derive child keys again, etc.
>
> I'd really prefer to start with finding standards ways to protect the entropy seed (not specifically the bip39 words derived from that but also as derived roots for WebAuthN/FIDO, GPG, Signal/Session, etc.) that can be then be used to create other hierarchies of keys using airgap solutions.
>
> For instance, here is what FullyNoded 2 currently uses to restore a Bitcoin wallet including root seed:
>
> {
>   "birthdate": 1584725088,
>   "label": "Testnet Single Signature",
>   "entropy": "b3b17e8f425bf7b96d68b67867cdc816",
>   "walletName": "DEFAULT_EBaiuGgZQS_StandUp",
>   "descriptor": "wpkh([6955c2cb/84'/1'/0']tprv8giCxdrRRrKfQkXTJ4q2PNZBsPL7HiTXXteajiG8wqAGpLVsHJfN1EwwKM8F8x1Cuk8p6vh1KrKBCuZtZdDtL6Sc2CB1ou8sYiGSf6hcujv/0/*)",
>   "blockheight": 1
> }
>
> Alternatively, FullyNoded 2 can also restore a wallets without the full seed, so for instance, if this QR restore was missing the entropy field, only derived child xprv from the descriptor could be used, so no other accounts could be created but new addresses as children of the xprv could be created.
>
> The advantage of of an entropy seed storage centered technique is that I can convert that entropy seed into either BIP39 words, or any number of SLIP-39 shards, or Lightning words, and back. We are also looking at using this with the VSS that underlies Schnorr Musig. We can talk other secure tool makers on how to use this raw entropy for other purposes to create chains or hierarchies of keys for their unique needs.
>
> Blockchain Common's doesn't have a full architecture for this yet as we are working on our POC and are seeking suggestions from other wallet vendors (in particular lightning and non-bitcoin secure services) on requirements. Let me know if you'd like to participate in the discussions (currently either Github issues or a Signal group for the group)
>
> — Christopher Allen