Re: [bitcoin-dev] Hardware Wallet Standard

[Thomas Kerin via bitcoin-dev]

I want to pitch a use-case that might have been ignored in this discussion:

I don't think this protocol is only useful for hardware wallets.
Technically any website that wants to request public keys/signatures and
offload the responsibility for managing keys and signing to the user
would also find this valuable.

I hope we can move forward with a protocol that suits both the hardware
people, and the people who find signing transactions in browsers
unsettling.

Maybe we the focus should move away from only servicing hardware, and
asking if the motivation is better captured by "allow users pick their
own ECDSA implementation, hardware or software", then working out what
we need to get us there.


On 08/18/2016 12:23 PM, Nicolas Bacca via bitcoin-dev wrote:
> On Thu, Aug 18, 2016 at 11:49 AM, Jonas Schnelli via bitcoin-dev
>  > wrote:
>
> Hi
>
> > I have some experience with hardware wallet development and its
> > integration and I know it's a mess. But it is too early to
> define such
> > rigid standards yet. Also, TREZOR concept (device as a server
> and the
> > primary source of workflow management) goes directly against your
> > proposal of wallet software as an workflow manager. So it is
> clear NACK
> > for me.
>
> The current question – as already mentioned – is we ACK to work
> together
> on a signing protocol or if we NACK this before we even have started.
>
>
> ACK for Ledger. What's necessary to sign a transaction is well known,
> I don't see how driving any hardware wallet from the wallet itself or
> from a third party daemon implementing that URL scheme would make any
> difference, other than providing better devices interoperability, as
> well as easier maintenance and update paths for the wallets.
>
> -- 
> Nicolas Bacca | CTO, Ledger
>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Moral Agent via bitcoin-dev]

It would be nice if the detached signer and the normal wallet could both
verify the correctness of generated addresses before you cause coins to be
sent there.

e.g. the hardware wallet could give its master public key to Bitcoin Core
and you can thereafter generate your receiving addresses on Core, with the
option to have the HW wallet validate them.

One of my biggest fears about using any wallet is the "whoops, cosmic ray
flipped a bit while producing receiving address; SFYL!" possibility. For
high value cold storage, I always generate my addresses on two independent
machines using two different pieces of software. Am I nuts for doing that?

With the above scheme, you are pretty well protected from losing money if
your HW wallet is defective. You could still lose it if the HW wallet was
evil of course, but that strikes me as much more likely to be discovered
quickly.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Nicolas Bacca via bitcoin-dev]

On Thu, Aug 18, 2016 at 11:49 AM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi
>
> > I have some experience with hardware wallet development and its
> > integration and I know it's a mess. But it is too early to define such
> > rigid standards yet. Also, TREZOR concept (device as a server and the
> > primary source of workflow management) goes directly against your
> > proposal of wallet software as an workflow manager. So it is clear NACK
> > for me.
>
> The current question – as already mentioned – is we ACK to work together
> on a signing protocol or if we NACK this before we even have started.
>

ACK for Ledger. What's necessary to sign a transaction is well known, I
don't see how driving any hardware wallet from the wallet itself or from a
third party daemon implementing that URL scheme would make any difference,
other than providing better devices interoperability, as well as easier
maintenance and update paths for the wallets.

-- 
Nicolas Bacca | CTO, Ledger
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Jonas Schnelli via bitcoin-dev]

Hi

> I have some experience with hardware wallet development and its
> integration and I know it's a mess. But it is too early to define such
> rigid standards yet. Also, TREZOR concept (device as a server and the
> primary source of workflow management) goes directly against your
> proposal of wallet software as an workflow manager. So it is clear NACK
> for me.

The current question – as already mentioned – is we ACK to work together
on a signing protocol or if we NACK this before we even have started.

I'm not saying that the draft proposal I made is the way to go, I'm
happy to NACK it myself in favor of a better proposal.

I strongly recommend to work together on a standard that will have one
central winner: the end user.





signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Marek Palatinus via bitcoin-dev]

On Thu, Aug 18, 2016 at 11:35 AM, Jonas Schnelli 
wrote:

> I agree that BIP70 is a mess (including the bitcoin:// additions). The
> proposed URI scheme would be completely different.


This reminds me https://xkcd.com/927/

I have some experience with hardware wallet development and its integration
and I know it's a mess. But it is too early to define such rigid standards
yet. Also, TREZOR concept (device as a server and the primary source of
workflow management) goes directly against your proposal of wallet software
as an workflow manager. So it is clear NACK for me.

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

Re: [bitcoin-dev] Hardware Wallet Standard

[Jonas Schnelli via bitcoin-dev]

Hi

> The main benefit is that you don't need "standard" to solve problem, but
> use natural tools in given environment and programming stack. Build a
> "standard" on top of URI protocol is a huge limitation, which does not
> give any advantage.

Standards can help an ecosystem to grow, can help to sustain a good user
experience.

The hardware wallet vendors have used "natural tools" and look where we
are. We have *native* plugins in Electrum, Copay, etc. for different
hardware wallets. Mostly the plugins are in the code base of the wallet,
which makes it – in theory – impossible to change from the perspective
of the hardware wallet vendor (there is no control of the deployment if
there are bugs in the plugins code).
The plugins functions overlap significant.

I think this is a bad design for security critical applications.

What I want as hardware wallet user:
* I'd like to have a trusted application (layer) where I'm sure I'm
using software provided through my hardware wallet vendor.

What I want as hardware wallet vendor:
* I'd like to be able to provide and update a software layer (app) to my
customer with the ability to provide code signatures and security
updates anytime. I do want to control the user experience.


> We already see issues with dead simple "bitcoin uri" standard, it barely
> works in most of bitcoin apps. Think of vague definitions of parameters
> or ability to send payment requests over it. HW API would be complicated
> by an order of magnitude and I have serious concerns that it will be
> helpful for anything. So why complicate things.

As far as I know most bitcoin wallets do support the bitcoin:// URI
scheme quite well.
I agree that BIP70 is a mess (including the bitcoin:// additions).

The proposed URI scheme would be completely different. The only
similarity is using the URI scheme as transport layer (which is the
proposed long term inter-app communication layer by Apple and Google).

>> How would the library approach work on mobile platforms? Would USB be
> the only supported hardware communication layer?
> 
> Interprocess communication/libraries/dependencies on Android are not
> bound to specific transport anyhow. Such library could be used by any
> android app, and the library would implement proper transports for
> various supported vendors. USB for Trezor, NFC for something different
> etc. If the point is "make life of app developers easier", let's do this
> and do not define artifical "standards".

So you propose having one library that would support multiple vendors?
What if new vendors add a new transport layer (lets assume NFC or
Bluetooth), wouldn't that result in every possible consumer of that
library (all wallets) need to update before the new vendors transport
layer could be used, resulting in a huge deployment process probably
require many month until it can be used?

What if there is a critical security issue in the library? How would the
deployment plan looks like?

I really think we should remove the "hardware communication layer" from
wallets and move it towards the hardware vendor app.

What about iOS? Should we just leave that platform unsupported with
hardware wallets?





signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Marek Palatinus via bitcoin-dev]

> Can you elaborate what benefits you would get from the library approach
and how the library API would be different form the proposed URI-scheme?

The main benefit is that you don't need "standard" to solve problem, but
use natural tools in given environment and programming stack. Build a
"standard" on top of URI protocol is a huge limitation, which does not give
any advantage.

We already see issues with dead simple "bitcoin uri" standard, it barely
works in most of bitcoin apps. Think of vague definitions of parameters or
ability to send payment requests over it. HW API would be complicated by an
order of magnitude and I have serious concerns that it will be helpful for
anything. So why complicate things.

> How would the library approach work on mobile platforms? Would USB be
the only supported hardware communication layer?

Interprocess communication/libraries/dependencies on Android are not bound
to specific transport anyhow. Such library could be used by any android
app, and the library would implement proper transports for various
supported vendors. USB for Trezor, NFC for something different etc. If the
point is "make life of app developers easier", let's do this and do not
define artifical "standards".

slush


On Thu, Aug 18, 2016 at 8:54 AM, Jonas Schnelli 
wrote:

> Hi
>
> > I fundamentally disagree with the concept of driving signing workflow by
> > the wallet software. Wallet software does not know in advance all data
> > necessary for the signer to do the job. As Jochen mentioned above,
> > Segwit vs Non-segwit use cases are a good example, but there may be many.
>
> I think this is easily solvable. The required data to verify and sign a
> (standard) bitcoin transaction (including P2WSH multi-sig) is manageable.
>
> IMO what a signing devices requires in order to sign a (standard)
> transaction:
> -> serialized tx
> -> serialized tx of the inputs
> -> scriptPubKey of the inputs
> -> inputs redeem-Scripts
> -> input amounts
> -> position of the change output any maybe its keypath
> -> cosigners pubkeys for inputs and changeaddress
>
> This seems to be manageable for a 1 round communication?
> Or do I miss something?
>
>
> > Currently the TREZOR protocol works like device is a server and wallet
> > is a client calling methods on it. It's like: "Sign this for me,
> > please", "Ok, give me this information", "Here it is", "Now I need this
> > another piece" "There is the signature". Wallet does not know in
> > advance what will go next, and it is for sake of simplicity. I'm quite
> > happy with the protocol so far.
>
> I think multiple rounds would still be possible with a clever design.
> Although I could imaging that >95% of the users transaction would
> require only a single "shot".
>
> Whats the benefits of the multiple rounds communication? Would a single
> round result in to many data transported?
>
> Passing a 300kb chunk (assuming a large transaction) over a URI scheme
> requires a couple of milliseconds on standard Smartphones or PCs.
>
> > Considering the difference in between current hardware, I really don't
> > think it is possible to find any minimal URI-based API good enough for
> > communicating with all vendors. What I see more likely is some 3rd party
> > libraries (JS, C++, Python, ...) defining high-level API and
> > implementing hardware-specific protocols and transports as plugins. That
> > way vendors are not limited by strict standard and application
> > developers and services can integrate wide range of hardware wallets
> > easily. However, this can be done already and we do not need any
> > standardization process (yet).
>
> The URI-based API allows transmitting data of multiple megabytes while
> there is no need for...
> * dependencies of any form (library, etc.)
> * library support for a particular language
> * platform that supports the dependencies of the library (like USBHID,
> not supported by iOS)
>
> Can you elaborate what benefits you would get from the library approach
> and how the library API would be different form the proposed URI-scheme?
>
> How would the library approach work on mobile platforms? Would USB be
> the only supported hardware communication layer?
>
> Thanks
> --
> 
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Jonas Schnelli via bitcoin-dev]

Hi

> I fundamentally disagree with the concept of driving signing workflow by
> the wallet software. Wallet software does not know in advance all data
> necessary for the signer to do the job. As Jochen mentioned above,
> Segwit vs Non-segwit use cases are a good example, but there may be many.

I think this is easily solvable. The required data to verify and sign a
(standard) bitcoin transaction (including P2WSH multi-sig) is manageable.

IMO what a signing devices requires in order to sign a (standard)
transaction:
-> serialized tx
-> serialized tx of the inputs
-> scriptPubKey of the inputs
-> inputs redeem-Scripts
-> input amounts
-> position of the change output any maybe its keypath
-> cosigners pubkeys for inputs and changeaddress

This seems to be manageable for a 1 round communication?
Or do I miss something?


> Currently the TREZOR protocol works like device is a server and wallet
> is a client calling methods on it. It's like: "Sign this for me,
> please", "Ok, give me this information", "Here it is", "Now I need this
> another piece" "There is the signature". Wallet does not know in
> advance what will go next, and it is for sake of simplicity. I'm quite
> happy with the protocol so far.

I think multiple rounds would still be possible with a clever design.
Although I could imaging that >95% of the users transaction would
require only a single "shot".

Whats the benefits of the multiple rounds communication? Would a single
round result in to many data transported?

Passing a 300kb chunk (assuming a large transaction) over a URI scheme
requires a couple of milliseconds on standard Smartphones or PCs.

> Considering the difference in between current hardware, I really don't
> think it is possible to find any minimal URI-based API good enough for
> communicating with all vendors. What I see more likely is some 3rd party
> libraries (JS, C++, Python, ...) defining high-level API and
> implementing hardware-specific protocols and transports as plugins. That
> way vendors are not limited by strict standard and application
> developers and services can integrate wide range of hardware wallets
> easily. However, this can be done already and we do not need any
> standardization process (yet).

The URI-based API allows transmitting data of multiple megabytes while
there is no need for...
* dependencies of any form (library, etc.)
* library support for a particular language
* platform that supports the dependencies of the library (like USBHID,
not supported by iOS)

Can you elaborate what benefits you would get from the library approach
and how the library API would be different form the proposed URI-scheme?

How would the library approach work on mobile platforms? Would USB be
the only supported hardware communication layer?

Thanks
--




signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Bryan Bishop via bitcoin-dev]

On Tue, Aug 16, 2016 at 7:14 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The other serious problem - and this is a problem with smartcards in
> general
> anyway - is that without Bitcoin-specific logic you're just signing
> blindly; we
> recently saw the problems with that with the Bitfinex/BitGo hack. And even
> then, without a screen most of the hardware wallets in are still just
> signing
> blindly, with at best hard-to-use limits on maximum funds moved
> per-transaction. Also note how even hardware wallets with a screen, like
> Trezor, aren't yet able to authenticate who you are paying.
>

"Welcome to my threat model."

In multisig scenarios, there must be a different "trust root" for each key.
For example, storing two private keys next to each other on the same web
server is broken because if one key is compromised it is infinitely trivial
to compromise the second key. Using multiple web servers is also broken if
the two servers are controlled by the same AWS keys or same "help me get my
servers back" support email request to whatever single sign-on service is
used. In some cases, it can be better to write software such that
transaction data is served at a particular location, and another
security-critical step is responsible for downloading that data from the
first machine, rather than the first computer directly pushing (with
authentication credentials in place for the attacker to compromise) the
data to the second computer.

I recommend using hardware security modules (HSMs). It's important to have
a public, reviewed bitcoin standard for hardware wallets, especially HSMs.
I expect this is something that the entire industry has a tremendous
interest in following and contributing to, which could even lead to
additional resources contributed (or at the very least, more detailed
requirements) towards libconsensus work.

Instead of signing any bitcoin transaction that the hardware wallet is
given, the hardware should be responsible for running bitcoin validation
rules and business logic, which I recommend for everyone, not only
businesses. Without running business logic and bitcoin validation rules,
the actual bitcoin history on the blockchain could be a very different
reality from what the hardware thinks is happening. Using a different
out-of-band communication channel, the hardware could query for information
from another database in another trust root, which would be useful for
business logic to validate against.

As for a screen, I consider that somewhat limited because you only get text
output (and I don't know if I can reasonably suggest QR codes here). With a
screen, you are limited to text output, which can compromise privacy of the
device's operations and info about the wallet owner. An alternative would
be to have a dedicated port that is responsibly only for sending out data
encrypted to the key of the wallet owner, to report information such as
whatever the hardware's transaction planner has decided, or to report about
the state of the device, state of the bitcoin validation rules, or any
accounting details, etc. Additionally, even a signed transaction should be
encrypted to the key of the device owner because a signed transaction can
be harmless as long as the owner still has the ability to control whether
the signed transaction is broadcasted to the network. It's "separation of
concerns" for transaction signing and decrypting a signed transaction
should be unrelated and uncoupled.

Also I am eager to see what the community proposes regarding signed and
authenticated payment requests.

((insert here general promotional statement regarding the value of reusable
checklists used during every signing ritual ceremony))

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Marek Palatinus via bitcoin-dev]

Hi,

I fundamentally disagree with the concept of driving signing workflow by
the wallet software. Wallet software does not know in advance all data
necessary for the signer to do the job. As Jochen mentioned above, Segwit
vs Non-segwit use cases are a good example, but there may be many.

Currently the TREZOR protocol works like device is a server and wallet is a
client calling methods on it. It's like: "Sign this for me, please", "Ok,
give me this information", "Here it is", "Now I need this another
piece" "There is the signature". Wallet does not know in advance what
will go next, and it is for sake of simplicity. I'm quite happy with the
protocol so far.

Considering the difference in between current hardware, I really don't
think it is possible to find any minimal URI-based API good enough for
communicating with all vendors. What I see more likely is some 3rd party
libraries (JS, C++, Python, ...) defining high-level API and implementing
hardware-specific protocols and transports as plugins. That way vendors are
not limited by strict standard and application developers and services can
integrate wide range of hardware wallets easily. However, this can be done
already and we do not need any standardization process (yet).

slush

On Wed, Aug 17, 2016 at 1:34 PM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Dana
>
> >> The URI scheme does not require any sorts of wallet app level
> >> configuration (where the stdio/pipe approach would require to configure
> >> some details about the used hardware wallet).
> >
> > Hi everybody, just thought I’d throw my opinion in here.
> >
> > The URI scheme is a nice idea, but this ignores the fact that hardware
> wallet vendors do most of the work on talking between the computer/mobile
> and the wallet on a lower level of communication. In the case of BitLox,
> the base protocol is Google’s ProtoBuf. The commands and transaction data
> is in a “schema” which is then encoded in different methods accessible via
> ProtoBuf (depending on the data being sent). The advantages of this
> protocol is that it can be implemented on a wide variety of platforms. (but
> that’s a whole 'nother discussion)
> >
> > The URI would be handled way up in the specific application (such as
> the mytrezor wallet software or the various standalone wallets) - nowhere
> near the actual hardware communications layer.
>
> This is maybe a question of the scope.
> The BIP I'm proposing would make a clear interface cut between
> wallet-with-unsigned-transaction and a signing-device (and maybe between
> wallet-requires-pubkey, signing-device generate some pubkeys [or
> non-hardened xpub]).
>
> The detached-signing proposal does not duplicate work. It just moves the
> current plugin design into a separate application. Plugins in security
> and privacy critical wallet software is something that should probably
> be avoided.
>
> It's intentional at a high level to allow maximum flexibility at the
> hardware interaction layer.
>
> Your protobuf example is a good use-case. You could implement your
> custom processes behind the URI scheme (which is probably way more
> efficient then writing a couple of wallet plugins where you – at the end
> – mostly don't control the deployment and the source-code).
>
> Defining a standard on the hardware interaction layer is possible, but a
> fairly different approach.
>
> 
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Jonas Schnelli via bitcoin-dev]

Hi Dana

>> The URI scheme does not require any sorts of wallet app level
>> configuration (where the stdio/pipe approach would require to configure
>> some details about the used hardware wallet).
> 
> Hi everybody, just thought I’d throw my opinion in here.
> 
> The URI scheme is a nice idea, but this ignores the fact that hardware wallet 
> vendors do most of the work on talking between the computer/mobile and the 
> wallet on a lower level of communication. In the case of BitLox, the base 
> protocol is Google’s ProtoBuf. The commands and transaction data is in a 
> “schema” which is then encoded in different methods accessible via ProtoBuf 
> (depending on the data being sent). The advantages of this protocol is that 
> it can be implemented on a wide variety of platforms. (but that’s a whole 
> 'nother discussion)
> 
> The URI would be handled way up in the specific application (such as the 
> mytrezor wallet software or the various standalone wallets) - nowhere near 
> the actual hardware communications layer.

This is maybe a question of the scope.
The BIP I'm proposing would make a clear interface cut between
wallet-with-unsigned-transaction and a signing-device (and maybe between
wallet-requires-pubkey, signing-device generate some pubkeys [or
non-hardened xpub]).

The detached-signing proposal does not duplicate work. It just moves the
current plugin design into a separate application. Plugins in security
and privacy critical wallet software is something that should probably
be avoided.

It's intentional at a high level to allow maximum flexibility at the
hardware interaction layer.

Your protobuf example is a good use-case. You could implement your
custom processes behind the URI scheme (which is probably way more
efficient then writing a couple of wallet plugins where you – at the end
– mostly don't control the deployment and the source-code).

Defining a standard on the hardware interaction layer is possible, but a
fairly different approach.





signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Dana L. Coe via bitcoin-dev]

> On Aug 17, 2016, at 15:24, Jonas Schnelli via bitcoin-dev 
>  wrote:
> 
> URI scheme instead of stdio/pipe
> 
> The URI scheme is not ugly. Its a modern way – implemented in almost all
> platforms – how applications can interact with each other while not
> directly knowing each other. Registering a URI scheme like "bitcoin://"
> has some concrete advantages over just piping through stdio.
> 
> Also, the stdio/piping approach does not work for mobile platforms
> (where the URI scheme works).
> 
> The URI scheme does not require any sorts of wallet app level
> configuration (where the stdio/pipe approach would require to configure
> some details about the used hardware wallet).

Hi everybody, just thought I’d throw my opinion in here.

The URI scheme is a nice idea, but this ignores the fact that hardware wallet 
vendors do most of the work on talking between the computer/mobile and the 
wallet on a lower level of communication. In the case of BitLox, the base 
protocol is Google’s ProtoBuf. The commands and transaction data is in a 
“schema” which is then encoded in different methods accessible via ProtoBuf 
(depending on the data being sent). The advantages of this protocol is that it 
can be implemented on a wide variety of platforms. (but that’s a whole 'nother 
discussion)

The URI would be handled way up in the specific application (such as the 
mytrezor wallet software or the various standalone wallets) - nowhere near the 
actual hardware communications layer.

Best regards,
Dana
BitLox


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Nicolas Bacca via bitcoin-dev]

On Wed, Aug 17, 2016 at 9:24 AM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Conclusion:
> ===
> * Non of the points convinced me that there is a better alternative to
> the proposed URI scheme interaction (please tell me if I'm stubborn).
>

I'd also agree with this - and it's convenient to test against simulators /
mocks.

-- 
Nicolas Bacca | CTO, Ledger
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Nicolas Bacca via bitcoin-dev]

On Wed, Aug 17, 2016 at 2:14 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> I'm not aware of any ECC-enabled smart-cards that can sign the specific
> curve
> that Bitcoin uses, not to mention the fact that those smartcards generally
> only
> speak higher level protocols than raw signature generation, precluding the
> signing of bitcoin transactions.
>

any Java Card supporting ECC can sign on user supplied Weierstrass curve
parameters - you can find a good shopping list at
http://www.fi.muni.cz/~xsvenda/jcsupport.html (look for ALG_ECDSA_SHA256 on
javacard.crypto.signature). The NXP JCOP platform (found in Yubico Neo) is
a popular choice, and then you can add your own custom logic for validation.

-- 
Nicolas Bacca | CTO, Ledger
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Jonas Schnelli via bitcoin-dev]

Hi all

Thanks for the response.


Jochen's points:
===
Indeed. There are some missing points and I'd like to work this into the
BIP. Thanks for bringing this up.

Along with a support for wallet-creation with a xpub from the signing
device, we might also want to support loading multiple pubkeys into a
keypool from the device (in case someone likes to use hardened
derivation at all levels). I guess this would not be over-complex to
achieve.

Luke's points:
=

USB / Plugin/Driver problematic
---
I don't think it would be wise to set Trezors USB communication
(hardware interface) as "the standard". A) A USB stack/interaction in
wallets should be avoided IMO. B) This approach won't work for some
platforms (like iOS) due to technical and legal restrictions.

In my opinion, each hardware wallet has to provide custom software in
any case. We don't want to standardize how a hardware wallet has to do
backups, recovers, firmware upgrade, etc. and if we agree on that, then
hardware wallets must provide an application (mostly Chrome extensions
today) to implement theses processes.

Also diversity at the hardware interface will reduce centralized risks
for weak security/vulnerabilities.

The proposed URI scheme approach does not require any sorts of
libraries/dependencies. USB HID can be a problem for cross platform
desktop wallets as well as it won't work of one of the major mobile
platform (iOS). USB HID interaction can be restricted or disabled in non
superuser setups where I'm not aware of any restriction on URI-Scheme level.

URI scheme instead of stdio/pipe

The URI scheme is not ugly. Its a modern way – implemented in almost all
platforms – how applications can interact with each other while not
directly knowing each other. Registering a URI scheme like "bitcoin://"
has some concrete advantages over just piping through stdio.

Also, the stdio/piping approach does not work for mobile platforms
(where the URI scheme works).

The URI scheme does not require any sorts of wallet app level
configuration (where the stdio/pipe approach would require to configure
some details about the used hardware wallet).


Thomase D.'s points:
===
Standardizing to many layers of the interaction stack (including the
hardware interaction) will very likely result in vendors not sticking to
the standard.

I agree, the URI scheme has some fragility, but at a level where we can
handle it and with the advantage of abstracting the used brand/device
for privacy and security reasons.

> The existing URI scheme, while allowing disambiguate by manufacturer,
provides no way to to enumerate available manufacturers or enabled
wallets.

Most operating systems allow to check if a certain URL-Scheme is
supported (registered), this would allow at least to check for known
major vendors (like trezor, etc.) which should solve most
multi-hardware-wallet use-cases.

The URI return scheme does work fine and with the correct set timeouts
it should result in a neat user experience.
It's the proposed way of application intercommunication in Apple iOS [1]
and Google Android [2].

Conclusion:
===
* Non of the points convinced me that there is a better alternative to
the proposed URI scheme interaction (please tell me if I'm stubborn).
* Also, we should move the end users UX in the center of the
problems-to-solve (and not overweight the ideal
code-/API-/hardware-interaction-design while ignoring the end user
experience).
* We should try to not over-standardize the interaction with the device
itself to allow flexibility on the hardware wallet vendor side.

[1]
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html
[2] https://developer.android.com/training/basics/intents/sending.html





signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Thomas Kerin via bitcoin-dev]

Hi all,

Thanks again Jonas for starting this!

I worked on a similar proposal a while back (never posted), approaching
the same problem as if a merchant's website accepted xpubs/public keys,
created multi-signature addresses, and wanted the user to easily sign
offline instead of using some javascript code / using Core's debug
console / coinb.in

Happily the procedure is largely the same, though I would echo Jochen's
point that there needs to be a way to request an xpub/public key.

The redeemScript and witnessScript are also required fields for full
validation & signing a transaction input if it's P2SH, or just the
witnessScript if it's bare V0_P2WSH

Since the output amounts are required, so maybe instead provide
serialized TxOut's? or Utxo's i.e: [txid, vout, amount, scriptPubKey].

The protocol ought to be as stateless as possible - it can't be assumed
whether the redeemScript and other details will ever be saved on the
device - so perhaps provide the redeemScript + witnessScript as the
final fields on the Utxo structure above.

I do think it enables two important choices for bitcoin users:

* it might be preferable to provide your own xpub vs generating a brand
new HD key to potentially lose.

* you could leverage the services provided by [random example]
GreenAddress without necessarily having to rely on signing code provided
by them, and so end up only having to trust only one ECDSA
implementation when interacting with a wide number of services

All the best

Thomas

On 08/16/2016 06:48 PM, Jochen Hoenicke via bitcoin-dev wrote:
> Hello Jonas,
>
> thanks for your efforts of writing the draft for the standard.
>
> First, this only describes detached signing.  A wallet also needs to
> connect with a hardware wallet at some time to learn the xpubs
> controlled by the hardware.  Do you plan to have this in a separate
> standard or should this also be included here?  Basically one needs one
> operation: get xpub for an HD path.
>
> From a first read over the specification I found the following points
> missing, that a fully checking hardware wallet needs to know:
>
> - the amount spent by each input (necessary for segwit).
> - the full serialized input transactions (without witness informations)
> to prove that the amount really matches (this is not necessary for segwit)
> - the position of the change output and its HD Path (to verify that it
> really is a change output).
> - For multisig change addresses, there are more extensive checks
> necessary:  All inputs must be multisig addresses signed with public
> keys derived from the same set of xpubs as the change address and use
> the same "m of n" scheme.  So for multisig inputs and multisig change
> address the standard should allow to give the parent xpubs of the other
> public keys and their derivation paths.
>
> It is also a bit ambiguous what the "inputscript" is especially for p2sh
> transactions.  Is this always the scriptPubKey of the transaction output
> that is spent by this input? For p2wsh nested in BIP16 p2sh transactions
> there are three scripts
>
> witness:  0  <1   2 CHECKMULTISIG>
> scriptSig:<0 <32-byte-hash>>
>   (0x220020{32-byte-hash})
> scriptPubKey: HASH160 <20-byte-hash> EQUAL
>   (0xA914{20-byte-hash}87)
>  (quoted from BIP-141).
>
> In principle one could put witness and scriptSig (with "OP_FALSE" in
> places of the signatures) in the raw transaction and make inputscript
> always the scriptPubKey of the corresponding output.  Then one also
> doesn't need to distinguish between p2pkh or p2sh or p2wpkh or "p2wpkh
> nested in bip16 p2sh" transactions.
>
> Regards,
>   Jochen
>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


On 08/16/2016 06:48 PM, Jochen Hoenicke via bitcoin-dev wrote:
> Hello Jonas,
>
> thanks for your efforts of writing the draft for the standard.
>
> First, this only describes detached signing.  A wallet also needs to
> connect with a hardware wallet at some time to learn the xpubs
> controlled by the hardware.  Do you plan to have this in a separate
> standard or should this also be included here?  Basically one needs one
> operation: get xpub for an HD path.
>
> From a first read over the specification I found the following points
> missing, that a fully checking hardware wallet needs to know:
>
> - the amount spent by each input (necessary for segwit).
> - the full serialized input transactions (without witness informations)
> to prove that the amount really matches (this is not necessary for segwit)
> - the position of the change output and its HD Path (to verify that it
> really is a change output).
> - For multisig change addresses, there are more extensive checks
> necessary:  All inputs must be multisig addresses signed with public
> keys derived from the same set of xpubs as the change address and use
> the 

Re: [bitcoin-dev] Hardware Wallet Standard

[Thomas Daede via bitcoin-dev]

On 08/16/2016 12:22 PM, Luke Dashjr via bitcoin-dev wrote:
> It would be best if the hardware protocol were standardised, so the user 
> doesn't need a plugin of *any* sort... I notice some hardware wallets have 
> begun to implement (or reuse) Trezor's interface, so that would seem a good 
> place to start?

I also agree with this - the user experience would be a lot better
without the need to install custom adapter software, especially for the
desktop case.

There could be two layers to the specification - the raw messages that
need to be passed, and the transport mechanism to pass them (USB HID, QR
code, audio...). For the most common case (USB), both layers could be
defined, and other transports could be added later. This split already
exists in the draft specification, though it's not very clear (URIs
include return URIs that don't make sense for a pipe, for example).

The existing URI scheme, while allowing disambiguate by manufacturer,
provides no way to to enumerate available manufacturers or enabled
wallets. This means that the "driver" would have to include a GUI to
select this. Also, passing return URIs seems rather fragile - are there
any other examples of protocols that use URIs for bidirectional IPC?

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

Re: [bitcoin-dev] Hardware Wallet Standard

[Peter Todd via bitcoin-dev]

On Wed, Aug 17, 2016 at 09:36:02AM +1000, Aiqin Li via bitcoin-dev wrote:
> Out of curiosity, what is the technical reason a normal ECC-enabled
> smart-card cannot be used for the hardware signing component of a wallet
> app? (Since if it can, its standardization must have been discussed.)
> 
> Debian wiki gives a list of such cards with related opensource software to
> access them.

I'm not aware of any ECC-enabled smart-cards that can sign the specific curve
that Bitcoin uses, not to mention the fact that those smartcards generally only
speak higher level protocols than raw signature generation, precluding the
signing of bitcoin transactions.

The other serious problem - and this is a problem with smartcards in general
anyway - is that without Bitcoin-specific logic you're just signing blindly; we
recently saw the problems with that with the Bitfinex/BitGo hack. And even
then, without a screen most of the hardware wallets in are still just signing
blindly, with at best hard-to-use limits on maximum funds moved
per-transaction. Also note how even hardware wallets with a screen, like
Trezor, aren't yet able to authenticate who you are paying.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Aiqin Li via bitcoin-dev]

Out of curiosity, what is the technical reason a normal ECC-enabled 
smart-card cannot be used for the hardware signing component of a wallet 
app? (Since if it can, its standardization must have been discussed.)


Debian wiki gives a list of such cards with related opensource software 
to access them.


Regards

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

Re: [bitcoin-dev] Hardware Wallet Standard

[Luke Dashjr via bitcoin-dev]

On Tuesday, August 16, 2016 2:10:04 PM Jonas Schnelli via bitcoin-dev wrote:
> The BIP describes two approaches how to communicate (pipe and
> URI-scheme) with the signing-devices app, although, in my opinion, all
> major platform do support the URI approach (maybe we could drop the pipe
> approach then).

IMO it's kindof ugly to abuse URIs for communication. Stdio pipes are pretty 
universally supported, why not just use those?

On the other hand, no matter how the plugin is implemented, it's still a 
security risk, and requires installation (which the user might not have access 
for). It would be best if the hardware protocol were standardised, so the user 
doesn't need a plugin of *any* sort... I notice some hardware wallets have 
begun to implement (or reuse) Trezor's interface, so that would seem a good 
place to start?

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

Re: [bitcoin-dev] Hardware Wallet Standard

[Jochen Hoenicke via bitcoin-dev]

Hello Jonas,

thanks for your efforts of writing the draft for the standard.

First, this only describes detached signing.  A wallet also needs to
connect with a hardware wallet at some time to learn the xpubs
controlled by the hardware.  Do you plan to have this in a separate
standard or should this also be included here?  Basically one needs one
operation: get xpub for an HD path.

From a first read over the specification I found the following points
missing, that a fully checking hardware wallet needs to know:

- the amount spent by each input (necessary for segwit).
- the full serialized input transactions (without witness informations)
to prove that the amount really matches (this is not necessary for segwit)
- the position of the change output and its HD Path (to verify that it
really is a change output).
- For multisig change addresses, there are more extensive checks
necessary:  All inputs must be multisig addresses signed with public
keys derived from the same set of xpubs as the change address and use
the same "m of n" scheme.  So for multisig inputs and multisig change
address the standard should allow to give the parent xpubs of the other
public keys and their derivation paths.

It is also a bit ambiguous what the "inputscript" is especially for p2sh
transactions.  Is this always the scriptPubKey of the transaction output
that is spent by this input? For p2wsh nested in BIP16 p2sh transactions
there are three scripts

witness:  0  <1   2 CHECKMULTISIG>
scriptSig:<0 <32-byte-hash>>
  (0x220020{32-byte-hash})
scriptPubKey: HASH160 <20-byte-hash> EQUAL
  (0xA914{20-byte-hash}87)
 (quoted from BIP-141).

In principle one could put witness and scriptSig (with "OP_FALSE" in
places of the signatures) in the raw transaction and make inputscript
always the scriptPubKey of the corresponding output.  Then one also
doesn't need to distinguish between p2pkh or p2sh or p2wpkh or "p2wpkh
nested in bip16 p2sh" transactions.

Regards,
  Jochen




signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev