[TASK] Ledger Interfacing, Possible Solutions

[ghost]

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

• Implementation can be initially limited to chrome
• Security is not weakened

Solution Paths

[jamespic]

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:

• Chromium devs make the chrome.hid API available to extensions, or make an API available which allows extensions to use U2F or WebUSB with an arbitrary origin (roughly along the lines of how they expose the fetch API to extensions). Obviously this depends on the Chromium team, at the bare minimum, accepting a patch to enable this.
• MetaMask roundtrips Ledger requests via a HTTPS origin (maybe via an IFRAME or a Service worker), where U2F is allowed.
• MetaMask puts Ledger support purely in the in-page script.
• MetaMask adds a native component, that can talk directly to USB.
• MetaMask becomes an Electron app, so can use @ledgerhq/hw-transport-node-hid.
• MetaMask only adds Ledger support to Mascara, which is purely HTTPS.

[ghost]

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]

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]

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]

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

[jamespic]

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]

@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]

@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]

@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]

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:

• It would add complexity and cut against abstractions in MetaMask,
• It would mean the Ledger signing code were running in "enemy territory", so pages could potentially intercept signing requests from MetaMask (that the user has seen and approved in the MetaMask UI), and send a different transaction to the Ledger.
• It would only work on HTTPS sites (a terrifying number of dapps are still HTTP only).

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:

• This also adds incidental complexity.
• It means that MetaMask's signing capabilities depend on the network (since the IFRAME would have to point to a HTTPS site, albeit one we control). This might be sidestepped with judicious use of service workers, but it's a kludge.

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:

• Any native components have to be installed, updated, and uninstalled separately from the Chrome extension.
• The code has to be built for every architecture you support.

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]

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]

@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]

@lazaridiscom yes

[ghost]

@gre, just to be sure:

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

• https://github.com/LedgerHQ/ledger-wallet-ethereum-chrome

What is this here about?

• https://github.com/LedgerHQ/blue-app-eth

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

[gre]

@lazaridiscom

• https://github.com/LedgerHQ/ledger-wallet-ethereum-chrome is the (soon legacy) chrome frontend app for Ethereum.
• https://github.com/LedgerHQ/blue-app-eth is the sourcecode of the ethereum app that runs on the hardware device

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

• https://github.com/LedgerHQ/ledger-live-desktop/blob/master/src/helpers/getAddressForCurrency/ethereum.js
• https://github.com/LedgerHQ/ledger-live-desktop/blob/master/src/helpers/signTransactionForCurrency/ethereum.js

[ghost]

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]

@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]

@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]

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]

@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]

Closing, all relevant info moved over to #4060.

[ghost]

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

[jamespic]

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]

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).