Hello everyone on such a fine day :-)

I've started working on integration with the very popular ledger nano s hardware wallet [1]. The project consists of a dedicated app for stellar [2] that will run on the device and a javascript library [3] for communicating with it -to be used by desktop wallet applications. This way I can focus purely on the device integration part and allow new and existing wallet applications to add support for the Ledger Nano S device.

The project is still in the early stages, but the proof of concept is working: I've already activated my Ledger-based Stellar account with Lumens and successfully signed and approved a transaction by running a test script. The next step that will fulfil the minimal requirements for a usability is to show the transaction details on the device so that the user knows what she is signing. I'm hopeful that I can have that running in the next two weeks.

A Stellar transaction can contain a lot of (different) operations and supports a rich set of information. My first focus will be on payments. Users will be able to send lumens and other stellar-based assets using their device. Support for other operations, multiple operations in a single transaction, hashed memo's, timebounds, etc. is more of a long term goal.

I've been in contact with the Ledger team about donating the code to them. In order to load the app onto the device they use a device manager application. They have confirmed that they accept code donations and that after review and approval will be able to add the app to their manager.

  1. https://www.ledgerwallet.com/products/ledger-nano-s
  2. https://github.com/lenondupe/ledger-app-stellar
  3. https://github.com/lenondupe/stellar-ledger-api

Let me know what you think and have a nice day!

@dupe This is great.

As the primary developer behind lupoex.com, I would say that we would love to integrate ledger Nano S. The only thing we really need is the ability to sign a transaction similar to this:

https://www.stellar.org/developers/js-stellar-base/reference/building-transactions.html

As part of your javascript library, I would suggest implementing a function sign(transaction) that takes a transaction of type https://stellar.github.io/js-stellar-sdk/Transaction.html and returns the signed transaction.

Hi! What you are describing is exactly my intention. I am basing the library on Ledger's node js api [1]. The name is a little bit misleading because the library can also be used in supported browsers.

The calls will be asynchronous calls that you can pass a callback function. Leaving out some details it basically comes down to:

var stlr = ledger.stlr();
var transaction = buildTransaction();
stlr.signTransaction(transaction, function(signedTransaction) {
sendTransaction(signedTransaction);
});

  1. https://github.com/LedgerHQ/ledger-node-js-api/

Please take the transaction hash as a parameter instead of the transaction, so you can support networks without using the global Network object-hack.

And please return the signature, so it works with multi-sig transactions.

  • dupe replied to this.

    Signing arbitrary messages would also be nice, not sure if Ledger supports that.

    (I'm hashing the messages twice so you can't phish people into signing TXs)

    • dupe replied to this.

      dzham For security reasons I'm afraid it is not possible to take the hash as input for signing a transaction. Remember the purpose of these devices is to be 100% tamperproof. That means the user must be certain of what it is they are signing. So the device needs the actual signature base of the transaction that contains all the transaction details. This way it can show the details on the device for approval. The signature base is also the thing that is then hashed and signed resulting in the signature. If you could just send a hash and receive back the signature it would be easy for malicious code on the client to send a hash that corresponds to a different transaction than the on presented to the user on the client.

        This is great, let me know if you need a tester!

        • dupe replied to this.

          dupe

          I know how signing works, I'm just telling you what I would need in terms of API, to easily integrate with what I have already. I display the tx for all transactions the user ever does, in the wallet (Stargazer)

          • dupe replied to this.

            dzham And I'm not suggesting you will write malicious code, but a computer can get infected or other wallet applications might ship with malicious code. For a hardware wallet, displaying the transaction on the client (stargazer in this case) is not enough, because a completely different transaction hash can easily be sent to the device for confirmation.This is why devices like this have a display. You can verify that what you are actually signing is what you intended when you entered the details on you computer (and it's really important that you do!).

            But I'm interested in the problem you see with sending the transaction and why you want to send the hash instead. You mentioned something about "networks without using the global Network object-hack". I'm not familiar with this problem. Can you expand on that?

              zcc Thanks a lot! I will post a link with instructions once the code is far enough along. Are you a developer? It will be necessary to set up a development environment to compile and load the app onto the device and then to build the javascript library. My plan is also to ship a small browser-based demo with the javascript library so you don't have to edit and run scripts to test the app.

              • zcc replied to this.

                dupe transaction + network hash would work

                The problem is that the StellarSDK signing code (The tx-hash calculation) isn't reentrant. Not sure if that ever is an issue is js/node though, but having to specify the network globally is certainly a code-smell IMHO, especially if you support multiple networks.

                The problem with transactions, that you might not have thought about, is that a transaction can contain up to 100 operations. Operations might have different source accounts. How are you going to display that on the tiny display of a Ledger Nano in a meaningful way? I'm having enough issues with this myself, and I'm a lot less constrained. (https://github.com/johansten/stargazer/blob/master/app/core/services/humanizer.js)

                ?

                • dupe replied to this.

                  dzham The problem with transactions, that you might not have thought about, is that a transaction can contain up to 100 operations.

                  You may want to read my initial post again.

                  @dupe oh, you will only be supporting payment operations in a transaction? If so, I don't think we will be able to make use of it at lupoex.

                  • dupe replied to this.

                    istrau2 Was my post really that unclear? If I read it back it clearly states that I want to support all the advanced use cases in the long term.

                    The initial goal is to support a single payment, in any asset. I think that is the most important use case for a hardware wallet and the one that the large majority of people are most interested in. After the initial release I want to add functionality incrementally. Eventually I would like to support the whole set of possible transactions if that proves viable. Perhaps it will be very easy to support all these things and they can implemented quite soon but I think it's a good process to release in stages and try to support the most important features first. Hope this clears things up.

                      dupe Yes, I am a developer and was planning on adding Stellar support to the Nano, but you beat me to it ?

                        I like what your doing. Keep up the good work! Hopefully i will be using it one day soon

                        dupe

                        I'll follow your progress, and when it works for arbitrary tx's I will integrate.

                        dupe, Just thought of something..

                        You could filter away all ops that have a source account that isn't signed for by the on-device key. That would make it work for a lot more scenarios than just a regular payment, while still keeping it simple in the UI.