1

Regarding the Ledger Nano S hardware wallet for cryptocurrencies, I've heard it claimed that the private keys for the wallet are securely stored on the physical device and protected even if the PC is infected with malware.

However, isn't it necessary for the private keys to be passed through USB into the client application's memory at some point in order to send money from the wallet onto the Bitcoin/Ethereum blockchain? Is that a possible attack vector?

Or is it possible for the client application to initiate a transaction without the private key, using some kind of derivative instead. If so, what if the malware was able to intercept this derivative?

Does someone with more technical knowledge of this understand how the security is maintained?

Simon East
  • 440
  • 5
  • 10

1 Answers1

1

Properly implemented hardware wallets perform all operations with the private key on the wallet itself, and not in the PC connected to the wallet. Only the inputs and outputs to the signing operations are sent over the USB connection, never the private key itself.

  1. The user uses their application to specify that they want to make a transaction.
  2. The (hardware-aware) application generates a transaction that is not yet signed with the private key, then sends it to the hardware wallet to be signed over USB.
  3. The hardware wallet signs the transaction, using the private key kept in a secure element, and returns the signature over USB.
  4. The application uploads the signed transaction to the pool to be included in the blockchain, finalizing the transaction.

In most hardware wallets (e.g., TREZOR and Ledger), there is a step between 2 and 3. These wallets require the user to confirm the transaction using an interface on the wallet itself. This is to protect against malware forging requests to the wallet to spend money (which could occur without the user noticing).

These concepts are not new to hardware wallets for cryptocurrency: many smartcard based systems have used these for years, such as the OpenPGP card for performing GnuPG-based operations.

David
  • 15,814
  • 3
  • 48
  • 73
  • Excellent explanation, thanks. That explains the step I was missing: that broadcasting a transaction does not actually include the private key, but rather a signature derived from the private key that the network is able to verify. I would assume that someone eavesdropping on this signed transaction cannot manipulate it for their own purposes. – Simon East Jan 11 '18 at 02:10