search

MetaMask / metamask-extension

:globe_with_meridians: :electric_plug: The MetaMask browser extension enables browsing Ethereum blockchain enabled websites
https://metamask.io
Other
12k stars 4.91k forks source link

[TASK] Ledger Interfacing, Possible Solutions #4204

Closed ghost closed 6 years ago

ghost commented 6 years ago

re #4060 (was #717)

Background

In order to provide support for hw-wallets (currently Ledger, as a reference-implementation), a communication or transport-layer must be provided.

The MetaMask Extension and the (or a newly implemented) Ledger Extension must be able to communicate securely.

Requirements

Solution Paths

jamespic commented 6 years ago

The U2F and WebUSB options require cooperation from the Chromium team, as they both require capabilities that Chrome doesn't currently have. I'm not sure how extension messaging would help here.

If it helps, I had an email from a developer looking to work on this, and in my reply i outlined the ways forward I can see, which I've included below:

ghost commented 6 years ago

The U2F would be a candidate for a high-profile bounty, and would be an independent path.

re extension-messaging, I've some fuzzy thoughts, not yet clear.

Can you please take a look at the "Extension-to-extension communication", to see if this could be a valid path to go? (@danfinlay, @kumavis - me currently off-code, possibly you can try to assess this, too).

jamespic commented 6 years ago

It might help if you clarify your thoughts on extension messaging. I can't see a way it could help us, but that might just be lack of imagination on my part.

An issue you're likely to face with anything based on extension messaging is that the built-in Chrome U2F extension will only accept messages from a very short whitelist of other extensions (IIRC, the only extension it'll talk to is another Chrome built-in one, although it's very permissive about talking to web pages). All the obvious solutions I can see fail to clear this hurdle.

ghost commented 6 years ago

It might help if you clarify your thoughts on extension messaging

I've no control over this, i'ts a matter of hours, max. days. Will file an elaborating issue (which can be closed, if its found non-implementable).

ghost commented 6 years ago

see #4383 - Provide Cross-Extension-Messaging based Com-Layer

jamespic commented 6 years ago

Another possibility that just occurred to me: The Ledger team are working on a new native wallet. If they exposed a native messaging endpoint, then MetaMask could hook into that. This saves MetaMask having to incorporate a native component, since most Ledger owners will likely already install this wallet. @gre does this sound like something the Ledger team would consider looking at?

gre commented 6 years ago

@jamespic interesting! It's one possible path but i'm not sure if it will be the best one (the fact user need to have both MetaMask & Ledger app installed. also i have not studied the implication of this in term of security and all things that this will require on our side). Sorry to have been silent the past weeks but we're pretty busy right now & focused on our MVP, we'll add this in our list of things to check & come back to you later. in the meantime if you find a simpler way, it could be great. technically the device works in U2F but i understand the struggle, in a soon future we should have support for WebUSB as well, but yeah I guess as you said, today, it does not work neither from an extension...

hope you the best

ghost commented 6 years ago

@jamespic - #4383 Path-A suggests that Ledger adds a "Messaging Endpoint" (to use your terminology). They would add this to the existent Ledger Eth Chrome App. There would be no need for "MetaMask having to incorporate a native component".

Instead of talking to Ledger via U2F, it would talk via the Cross-Extension-Messaging ("Messaging Endpoint").

ghost commented 6 years ago

@jamespic , I've updated #4060 with the more concrete stuff, and changed this issue here to "Ledger Interfacing, Possible Solutions". To your suggestions:

MetaMask puts Ledger support purely in the in-page script.

Can you elaborate on this? Would this mean that devs would have to add the script to their apps? So it would not work out-of-the-box?

MetaMask roundtrips Ledger requests via a HTTPS origin (maybe via an IFRAME or a Service worker), where U2F is allowed.

Launching an IFRAME from within an extension, wouldn't this still keep the "chrome:extension" origin?

A service-worker as an U2F-relay... this could work I guess.

MetaMask adds a native component, that can talk directly to USB.

Extensions can add "native" stuff? Any idea about the effort for this?

The Ledger team are working on a new native wallet. If they exposed a native messaging endpoint,

This should be fine, too.

(In the end, its all about "weighting the effort & chances of success" for the different solution paths)

jamespic commented 6 years ago

I'll try and elaborate on these options.

The inpage script wouldn't need any changes for dapp developers. MetaMask injects a small amount of code into all web pages (pretty much just Web3, and a simple provider that forwards most requests to the background script). We could add Ledger support code to this, since it runs in the context of the page. This can definitely work - it's the approach I took in SpaceSuit. However:

An IFRAME launched from an extension should have the origin of the page that it points to, so it should avoid the origin issues if it's pointing to a HTTPS origin (and MetaMask can talk to it with postMessage). However:

The service worker is a variant on this, but I'm less sure than I was that it's possible to send messages to a site's service worker from a page in a different origin.

Chrome does support communicating with native components (a project I work on in my day job relies on this). However:

Bundling it into the Ledger native app offloads the build and deploy issues onto the Ledger team (who will presumably have to solve these issues anyway), but it sounds like they're very busy.

ghost commented 6 years ago

Very nice elaborations. I need a day or two to digest/verify.

but it sounds like they're very busy.

It looks like most (if not all) of the relevant Ledger Code is in the open, so there's no dependency to the Ledger Teams availability (could be done in the usual OSS contribution way).

For now, my favorite path is the combination of #4469 and #4383.

ghost commented 6 years ago

@gre, is this here https://github.com/LedgerHQ/ledger-live-desktop the mentioned new native wallet?

@jamespic , after some thought, my favorite path is still #4469 + #4383. Leaving this issue open, for the case someone finally wants to try one of the described paths here, or wants to add something.

gre commented 6 years ago

@lazaridiscom yes

ghost commented 6 years ago

@gre, just to be sure:

I've identified this here as the relevant ledger software which has to be extended, is this correct?

What is this here about?

And a final question: are you aware of any examples which interface to the LedgerEthApp, ideally in JS?

gre commented 6 years ago

@lazaridiscom

Not exactly sure about the LedgerEthApp question, you mean usages of @ledgerhq/hw-app-eth lib ? maybe these can help:

ghost commented 6 years ago

is the (soon legacy) chrome frontend app for Ethereum.

This will be replace by https://github.com/LedgerHQ/ledger-live-desktop ?

you mean usages of lib ?

Yes, the links are fine.

ghost commented 6 years ago

@gre , the development branch of "leger-wallet-api" contains an ETH api, how stable is this and is it expected to be finalized (or will this become legacy, too) ?

https://github.com/LedgerHQ/ledger-wallet-api/tree/develop

gre commented 6 years ago

@lazaridiscom probably legacy (2 years old). yes, Ledger Wallet Ethereum Chrome will be replaced by https://github.com/LedgerHQ/ledger-live-desktop . I'm not yet sure what's our plan regarding opening or not our API to public usage, also we are likely to improve a lot our current api that have some issues with ethereum, so it's probably recommended to look at solution like Infura for now if you're looking for such an api.

ghost commented 6 years ago

I'm just looking to find the easiest path to access Ledger(Eth) from MetaMask, and want to ensure that I don't overlook something. What I'm missing most in the Ledger repos is a overview document, which lists all available software, clarifying their status.

I'm not yet sure what's our plan regarding opening or not our API to public usage

You should provide at least the same api-functionality that the legacy apps provided. I mean, Ledger is an open system (I saw even the board-schematics in the open), so an API is a must.

ghost commented 6 years ago

@jamespic wrote:

Another possibility that just occurred to me: The Ledger team are working on a new native wallet. If they exposed a native messaging endpoint,

This suggestion gains validity, simply because the rest of the Ledger software (chrome apps and js-interfacing code) become/are legacy/unmaintained.

@gre, I understand that this is additional effort for you, but just in case, you need to allow extensions explicitly by name, which seems secure enough:

allowed_origins List of extensions that should have access to the native messaging host. Wildcards such as chrome-extension:/// are not allowed.

https://developer.chrome.com/extensions/nativeMessaging#native-messaging-host

ghost commented 6 years ago

Closing, all relevant info moved over to #4060.

ghost commented 6 years ago

@jamespic, @gre, please ensure that you have a look at this (Trezor) solution: #4625

jamespic commented 6 years ago

Looks like they got around it by roundtripping requests through a HTTPS origin (https://connect.trezor.io). I hadn't given this much attention for Ledger, as it would mean someone would need to host and run that HTTPS site, and I wasn't in a position for it to be me.

It's also got the downside that it won't work offline (so airgapped or other paranoid use cases won't work), but if someone is in a position to host something comparable for Ledger, it could be viable.

ghost commented 6 years ago

as it would mean someone would need to host and run that HTTPS site It's also got the downside that it won't work offline

Agreeing here. I don't like the dependency to hosted code at all, so I still prefer the chrome-app-gateway or iframe-gateway as a 1st solution-path (chrome-apps will be disconued at some point).

In any case, I added the trezor-connect solution-path as an 2nd alternative (see #4060), as it seems to be valid.

but if someone is in a position to host something comparable for Ledger, it could be viable.

This should be something for the Ledger makers, e.g. to adopt the Trezor-Solution (possibly even talk with trezor to standardize this concept).