Lnd: [Feature Request] Support HW sign on LND

[htczion]

Background

Currently, LND is only support SW wallet. In order to improve this problem in the future, we can discuss it in this FR.

Environment:

• version of lnd
  LTND: Version: 0.7.1-beta commit=v0.7.1-beta-236-g2cf10ada0f83f1b41376f693f689ee88ca0965c5-dirty, build=development
• which operating system
  Android Linux localhost 4.9.65-perf-g36d6d98 #1 SMP PREEMPT Mon Sep 16 13:27:08 CST 2019 aarch64
• version of btcd, bitcoind, or other backend
  HtcCore: bitcoind Bitcoin Core version v0.18.0.0-2472733a2-dirty (release build)
• any other relevant environment details
  make Android for lndmobile.aar on Testnet

Discussion:

Below is the minimum change range for enabling outsourced signing in lnd,
Basically, HW wallet should create 3 new classes to inherit ‘signer’, ‘btcwallet’, and ‘producer’ respectively, and redirect ‘sign key’, ‘get public key’, and ‘get Commitment Secret / CommitmentPoint’ related operations to TrustZone.

1. Modify this function to request ‘sign’ from TZ

2. lndwallet/btcwallet/signer::SignOutputRaw(tx, signDesc)

3. Query (family) public keys from TZ in BIP44 format, eg, m/1017'/coinType'/keyFamily'/0/index, and all lnd private keys will never leave trust zone

4. keychain/btcwallet::DeriveKey
5. keychain/btcwallet::DeriveNextKey

6. keychain/btcwallet::DerivePrivKey(keyDesc)

7. Create new producer class and update related utilities to generate the correspond "commitment" point through TZ.

8. lnd/shachain/producer
9. input/script_util::ComputeCommitmentPoint

if there is any suggestion, please advise.

[Roasbeef]

Is your end goal to be able to _fund_ channels from a hardware wallet, or use lnd as a generic interface to interact with a hardware wallet (do regular on-chain sends, watch only support, etc)?

[htczion]

Is your end goal to be able to _fund_ channels from a hardware wallet, or use lnd as a generic interface to interact with a hardware wallet (do regular on-chain sends, watch only support, etc)?

For short term, the target is unlock/fund protected by HW.
For long term, the target is all lnd behaviors related privkey are all protected by HW.
A generic interface like HWI in Bitcoin is a reference.

Is there any idea or suggestion? Is it possible in this stage?

[htczion]

In order to fund channels from a hardware wallet, the idea is to move all the family private
keys from lnd's btc wallet to TrustZone HW. In current lnd commitment flow, for every new lnd commitment, it will need to send an old CommitSecret to the other side. Our thought is TrustZone will either provide an interface for lnd to query CommitSecrets or just send out the RevocationRoot private key to lnd (SW side) to generate CommitSecret. However, our concern is either way it looks like we lose the benefit of all the private keys / CommitSecret to be in HW? Is there any suggestion on this path?

[devrandom]

@ksedgwic and I are looking at a similar use case. @htczion's last comment brings up the important topic of policy controls.

There are several attack vectors that can drain the funds from a lightning wallet even if the keys are adequately protected. One vector is, as you mentioned above, disclosing a commit secret before a new commitment has been made. Another vector is mistakenly publishing an out of date commitment transaction.

In general, it is not possible to protect a Lightning wallet with a stateless secure enclave. @ksedgwic and I are working to define the policy controls that a secure enclave must implement in order to provide meaningful security.

[devrandom]

As to the code changes, I think you you are on the right track. I was thinking of the following strategy:

• Expand the existing Signer interface operations with a method to get the xpub of each key family (account xpub). This is necessary because the account xpub computation requires hardened derivation from the seed. Lower key derivation can be done in btcwallet.
• modify the existing btcwallet component to work in two modes: full and watch-only. "full" is the existing implementation, where both private keys and public keys are available within btcwallet. In the "watch-only" mode btcwallet would only perform actions that do not require private keys - including blockchain watching, non-hardened derivations and public key tweaks. In this mode, the account xpubs would be populated from the Signer that is configured.
• Secure enclave implementations would extend the Signer, Producer and NodeSigner interfaces
• As a future effort, add any metadata to the signing methods so that the secure enclave can make policy decisions (e.g. channel peer basepoints?)

[devrandom]

It doesn't look like the btcsuite/btcwallet module supports starting a wallet in watch-only mode or importing account pubkeys.

@Roasbeef what would you recommend for managing the public keys in a hardware wallet situation? Enhance btcsuite/btcwallet? or create a completely new module to replace lnd/lnwallet/btcwallet? The latter approach would seem to create a lot of code duplication.

[Roasbeef]

I brain dumped a path to supporting the above, and much more in this post: https://groups.google.com/a/lightning.engineering/forum/#!topic/lnd/3rF65UxvDtM

[htczion]

I brain dumped a path to supporting the above, and much more in this post: https://groups.google.com/a/lightning.engineering/forum/#!topic/lnd/3rF65UxvDtM

@Roasbeef
Will this new btcsuite/btcwallet protect the keys(funding key...) during every commitment transaction, or just funding and settlement transaction?

Refer to https://github.com/lightningnetwork/lnd/issues/3085

[Naylor95023]

Hi, Roasbeef

As you say, after this saga is complete,
hardware wallet is able to be a external signer, if it provide the gRPC services properly, right?

But lnd do signing autolly after wallet unlocked.
It's not adapt to the mechnism of hardware wallet,
let user have to confirm sign request by entering password everytime.

It seems not be metioned in chapters.
How dose external signer handle the frequent signReq when sendPayment or negotiation of closeChannel?