Re: [bitcoin-dev] Nonce blinding protocol for hardware wallets and airgapped signers

[Marko via bitcoin-dev]

Thanks for starting this initiative; it has been a long standing goal of
mine to implement and release this protocol. Your blog post on the topic
actually inspired me to pick up this work again a few months ago.

Jonas Nick has implemented the protocol in the secp256k1 library for
Schnorr sigs here: https://github.com/bitcoin-core/secp256k1/pull/590

I have backported the same scheme to ECDSA in the secp256k1 library
here, so it can be used also for current transactions:

https://github.com/bitcoin-core/secp256k1/pull/669

I also made proof of concepts for the BitBox02 hw wallet firmware and
BitBoxApp wallet to verify that the protocol also works well in practice.

The actual scheme used in those implementations is a generalized
sign-to-contract scheme, where the final nonce is computed as `k' = k +
H(k*G, n)` instead of `k'=k+n`, but otherwise it works mostly the same
for the anti nonce covert channel protocol. I suggest to use this scheme
in PSBT as well.

> We can either use proprietary fields [4] or define key-value pairs and add
> them to the BIP-174. Depends if anyone else is interested in using this
> protocol or not.

I'd definitely be interested in seeing widespread support for this, and
standardizing it would help with that.

With PSBT used with an air-gapped signer, there is increased danger in
implementing the protocol wrongly by relying on the contents of the PSBT
alone in the final verification step of a signature. The PSBT must be
verified carefully against state stored by the host for the PSBT.
Otherwise the signer can for example change or pre-fill the relevant
NONCE fields and leak the private keys anyway. Is there a current best
practice for how a PSBT can be identified by the host to store/retrieve
the state?

Are there other examples in PSBT where the host can't trust the contents
of the PSBT the signer returns (except of course for the parts the user
can verify themselves, like recipients, amounts, etc.)? In any case,
guidelines or conventions on how to avoid the pitfalls would be good.

Best, Marko



0x67A2B160F74DB275.asc
Description: application/pgp-keys
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Nonce blinding protocol for hardware wallets and airgapped signers

[Stepan Snigirev via bitcoin-dev]

Dear ZmnSCPxj,

> I think it would be unsafe to use a deterministic scheme, that takes as
input the message m and the privkey only.

Yes, using only the message and the private key is unsafe. Signer should
use all the data coming from the host, so f(sha256(n), m, privkey) is a
good candidate. If more than one blinding factor is sent - all of them
should be used as well.

> Otherwise a completely-random `k` would be much better, but the signer
might not have enough resources to gather sufficient entropy.

I am not a big fan of pure RNG-generated nonces, so I would suggest to use
this entropy only as additional data for a deterministic scheme.
For example, Yubikey had a problem with RNG initialization that caused
leakage of the private key [1].
If the signer has any source of entropy, even if it is not a very good one,
the entropy from this source can be mixed into the nonce generation
function:
f(sha256(n),m,privkey,entropy).

Another issue is that deterministic nonce generation is vulnerable to
glitch attacks - if I ask the wallet to sign the same message twice but
after nonce generation I glitch and flip a bit in the message, I will get
two signatures with the same nonce but with different messages - from these
signatures I can calculate the private key.
So I would recommend to include a monotonic counter into the nonce
generation function as well: f(sha256(n), m, privkey, entropy, counter)
As usual, counter should be increased _before_ signing.

Ref: [1]
https://www.yubico.com/support/security-advisories/ysa-2019-02/#technical-details

Best,
Stepan
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] [bitcin-dev] BIP157 Filter Type Extensibility Proposal for Combinations

[nopara73 via bitcoin-dev]

BIP157 defines a section called "Filter Types" (
https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki#filter-types
 )

>  For the sake of future extensibility and reducing filter sizes, there
are multiple *filter types* that determine which data is included in a
block filter as well as the method of filter construction/querying. In this
model, full nodes generate one filter per block per filter type supported.

>  Each type is identified by a one byte code, and specifies the contents
and serialization format of the filter. A full node MAY signal support for
particular filter types using service bits. The initial filter types are
defined separately in BIP 158
, and one
service bit is allocated to signal support for them.

While it provides a way to extend to multiple filter types, it does not
provide a way to extend to filter type combinations. Such combinations are
possible if the filter types would have to be defined with the power of
two: 1, 2, 4, 8, 16..., so every octet of a byte array could denote a
specific filter type, this way we could be able to signal for any number of
combinations of those filter types.

Originally this idea is described in more details and with code here:
https://github.com/bitcoin/bitcoin/issues/18221

MarcoFalke suggested for me to submit it to the mailing list instead of a
GitHub issue then propose an update to the BIP if consensus is reached.

-- 
Best,
Ádám
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Nonce blinding protocol for hardware wallets and airgapped signers

[ZmnSCPxj via bitcoin-dev]

Good morning Stepan,

> This topic appeared in the list a few times so I would like to discuss it in 
> more detail and maybe push forward to standardization.
>
> We have to accept that any hardware wallet or an air-gapped computer we use 
> to sign transactions can be compromised. It may happen via a supply chain 
> attack or malicious firmware update.
>
> If the signer is isolated (faraday cage, airgap and so on), it still can leak 
> private keys to the outside world by choosing nonces for signatures in a 
> funny way such that the attacker can calculate our private keys. Back in the 
> days, I wrote a small post [1] and a proof-of-concept demo [2] of this attack.
>
> Deterministic nonce generation can be verified only if we have private keys 
> somewhere else. It doubles the attack surface - now we need to maintain two 
> independent signers from different vendors that use the same private key and 
> the same deterministic algorithm for a nonce generation. In addition to that, 
> as Pieter mentioned in the Schnorr-BIP, deterministic nonces are vulnerable 
> to glitch attacks [3].
>
> A simple way to fix it is by forcing the signer to use additional entropy 
> from the host. This protocol takes away the privilege of picking nonce from 
> the signer and doesn't require any secret material outside the signer.
>
> I suggest the following implementation of the protocol for signing a message 
> `m`:
>
> 1. Host picks a random number `n` and sends its hash together with the 
> message `m` to the signer.
> 2. Signer computes a nonce `k` it wants to use for signing. It can be either 
> a deterministic scheme or using RNG. Signer commits to the chosen nonce by 
> sending the corresponding point `R=kG` to the host.

I think it would be unsafe to use a deterministic scheme, that takes as input 
the message m and the privkey only.

Let us consider the case where the hardware signer has its power supply coming 
from USB and the communication channel is over USB as well.
Thus, the host can selectively turn on/off the hardware signer (e.g. a hacker 
with physical access can just unplug it).

With R determined from m and the privkey, then the host knows the R that the 
signer will use, and can arrange an n that cancels that R and adds a specific R 
it wants to target.
It could, for example, arrange to have two different `m` signed with the same 
`R'`.

What would have to be done would be derive `k` from the message `m` plus the 
`sha256(n)` and the privkey.
Perhaps you considered this already, but it may be useful to have it explicitly 
stated that this has to be mixed as well, i.e. if `k` is generated 
deterministically it has to be `k = f(sha256(n), m, privkey)` where `f()` is 
some suitable hashing function.

Otherwise a completely-random `k` would be much better, but the signer might 
not have enough resources to gather sufficient entropy.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Removing Single Point of Failure with Seed Phrase Storage

[ZmnSCPxj via bitcoin-dev]

Good morning Christopher,

>
> > As a replacement for paper, something like this makes sense v.s. what you 
> > do with a ledger presently.
> >
> > However, shamir's shares notoriously have the issue that the key does exist 
> > plaintext on a device at some point.
> >
> > Non-interactive multisig has the benefit of being able to sign transactions 
> > without having keys in the same room/place/device ever.
>
> I agree that that interactive multisig is best for transactional recovery, 
> but there is still a place in our tool chest for Shamir split backups 
> especially in operational security scenarios, but as you state, you must be 
> aware of the limitations of Shamir, not only from the fact that there is 
> vulnerability in that you must restore keys in one place, but also there are 
> denial edge cases where when you only have k-1 of n, someone can deny you 
> knowledge of who gave you the corrupted share. 
>
> Right now the best C-library for Shamir sharding of recovery seeds is at the 
> Blockchain Commons Github 
> https://github.com/BlockchainCommons/sss/blob/master/README_slip39.md 
> however, this code base needs refactoring to be a good standalone library. 
> This requires us separating out the Shamir portions from the SLIP-39 mnemonic 
> elements and command-line elements. We also want to separate out the 
> randomness portions of the code so you can test different implementations 
> against deterministic randomness to ensure they give the same value (but 
> don't use this for production!) Once this is complete, we will be submitting 
> this library for formal review.
>
> We are also working on air-gapped open-source open hardware for seed 
> creations and Shamir restoration. For instance, this device has no wifi, 
> Bluetooth, or persistent memory, and the serial port is disabled. It is sized 
> to fit in a bank safe deposit box. See 
> https://twitter.com/ChristopherA/status/1175465994644574208?s=20
>
> Longer-term for seed sharding, we want to leverage the VSS (Verifiable Secret 
> Sharing) that future Bitcoin musig uses, which we believe has advantages over 
> Shamir Secret Sharing. It can be used for both traditional sharding, but also 
> for musig transactional recovery without restoring of master seeds on a 
> single device, and it is easier to prove that shares are live and avoid 
> denial use cases.
>
> All this being said, we recommend Bitcoin multisig transactions as the best 
> solution for self-sovereign recovery of funds vs using Shamir (or SLIP39). 
> Lately, we've been working on PSBT and bitcoind descriptor support in our 
> alpha bitcoin wallet for iOS, FullyNoded 2 
> https://github.com/BlockchainCommons/FullyNoded-2 — in theory, this iOS 
> wallet can facilitate any scenario that bitcoind supports as a descriptor as 
> it communicates with your own private full-node over Tor v3.
>
> P.S. If you've not seen it yet, our free #SmartCustody book 
> http://bit.ly/SmartCustodyBookV101 offers what we think are current best 
> practices for single seed recovery. We did not include multisig scenarios in 
> v1 of this book as at the time they were too difficult and error-prone for 
> most people. We are now working on v2 of the book which will cover multisign 
> and fiduciary scenarios now that PSBT is maturing and more wallets are 
> improving multisig support.

I believe you missed a point that Jeremy was making:

* In a Shamir Secret Sharing Scheme, at some point in the past, some device had 
to contain the actual original pre-shared secret, and that device might have 
had backdoors you were unaware of at the time that you were doing the secret 
sharing.
  * Thus the entire secret might already be compromised long before you recover 
the secret again.

Verifiable Secret Sharing seems to be better in this regard, as each signer 
device can generate its own share independently of every other and effectively 
do an interactive setup to determine their public key (as I understand it --- I 
am not a mathist, and while I do have some notes regarding this from gmax, I 
confess I still have only a vague grasp of this math).
It may be better to outright forget Shamir Secret Sharing even exists, and 
prefer to use Verifiable Secret Sharing instead.


Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev