10 ms·

Breaking the Ledger Security Model

232 points by danr4 9y ago

DyslexicAtheist 9y ago
Matthew Green had a good analysis on why this is interesting also from outside a crypto currency perspective https://twitter.com/matthew_d_green/status/976066416267939840 https://twitter.com/matthew_d_green/status/97606641626793984...
- berberous 9y ago
  Interesting part: "For example, the iPhone SEP has a direct connection to the fingerprint reader, because the application processor isn’t trusted with that data. Weirdly FaceID departs from this but I digress." Anyone have any info on why FaceID works a different way? Because it needs more processing power?
  - gok 9y ago
    The application processor needs access to the camera so that you can take pictures and transmit them outside of the phone.
    - detaro 9y ago
      Which it could do through the SEP if the SEP were powerful enough, or through a secondary interface.
      - gok 9y ago
        What would that accomplish? The entire point of having the SEP wired directly to the fingerprint reader is that fingerprint images never make it to the AP because there's no reason for that. If the SEP is just going to copy every image to the AP why not just have both processors connected to the camera? (which also removes the security surface of any SEP->AP image copying code)
  - zxcvgm 9y ago
    I have not seen any sources which explicitly state that FaceID doesn't work the same way as TouchID does, but perhaps it's the lack of specific details in the iOS Security Guide [0] that might have led to this assumption? In fact, FaceID solely relies on the IR camera to do its work. You can cover the front-facing (normal) camera and your iPhone would still unlock successfully. Conversely, the newly touted Animoji feature does NOT rely on the IR camera at all, as evidenced in this iPhone X review [1] at 11:40. It may be the case that the OS don't have access to it. [0] https://images.apple.com/business/docs/iOS_Security_Guide.pdf https://images.apple.com/business/docs/iOS_Security_Guide.pd... [1] https://www.youtube.com/watch?v=9Ca8zWJOlFQ&t=700 https://www.youtube.com/watch?v=9Ca8zWJOlFQ&t=700
    - matthewdgreen 9y ago
      I based my speculation on tweets by some developers who have been able to capture raw TrueDepth data in their apps. See eg https://mobile.twitter.com/braddwyer/status/930682879977361408 https://mobile.twitter.com/braddwyer/status/9306828799773614... I can’t swear to you that this is exactly the same depth data that FaceID uses. Maybe it’s been downsampled in some way that makes it safe to give to apps, without enabling attacks on FaceID. I think I’d be a bit more willing to believe that if Apple’s Security docs actually said that. To me it seems more likely that the raw depth maps are available to the app processor (and to apps!) because the SEP isn’t powerful enough to perform the recognition task on its own.
gruez 9y ago
>Physical access before setup of the seed I can't watch the video (says unsupported mime type on my browser), but I heard the attack goes something like this: intercept the wallet, set up the wallet and copy the seed, repackage it, hope the victim uses the wallet as-is (with the seed you copied). Can't this be mitigated by resetting the device when you first get it? >2 variants of "firmware reflash" I thought firmware updates are signed? edit: disregard the second point. further down it mentions that only SE firmware is signed >Evil Maid attack Is it even possible to mitigate this? At the very least you can steal the original, replace it with a replica that looks the same, BUT all it does is send back the password to you (via bluetooth, wifi, gsm, whatever). You can even hook up the stolen wallet on the other end so it correctly respond whether the password is correct/wrong and immediately drain the wallet once the correct password is transmitted.
- StavrosK 9y ago
  > Can't this be mitigated by resetting the device when you first get it? No, he demonstrates a device going through setup and "generating" a predetermined seed. It's not the easier "your wallet has already been set up for you" attack.
  - dbrgn 9y ago
    To be precise, he overwrites the entropy source with zeroes, so that all words (except the last one) of the seed are "abandon". With a non-zero entropy source, you could generate random looking but deterministic seeds.
limpkin 9y ago
Wait... so the ledger allows any firmware to be uploaded without signature checking? damn :(
- ghthor 9y ago
  Seems insane right? Their entire userbase only exists because of the power that PKCrypto gives us to build lasting lines of trust and they don't sign firmware images....
AlexCoventry 9y ago
I picked up a Ledger in a raffle at a meetup a few months ago, and it's just been sitting around ever since because I was concerned about this kind of risk. It's a bit of a shame... Can't ethically sell it for the same reason. Fortunately, I was recently able to use it to introduce a curious friend of mine to Ethereum, using small amounts, so there's been at least some benefit.
- StavrosK 9y ago
  Keep in mind that, even with these vulnerabilities, the Ledger is still the safest you can get for cryptocurrency storage.
  - yarrel 9y ago
    Trezor is better.
    - StavrosK 9y ago
      How so? Trezor had a vulnerability where you could extract the private keys by measuring power draw.
    - charlesdm 9y ago
      Trezor seems much worse, in nearly every security write-up I have read.
  - lawn 9y ago
    Except an encrypted seed in cold storage. If you want to spend it you'll have different problems though.
    - StavrosK 9y ago
      Yeah, the problem with offline/paper seeds is that, if you want to spend them, you're going to become more vulnerable than with a hardware wallet, and they're single-use. Not to mention that they're hard to generate securely.
1upon0 9y ago
This needs much more visibility than it presently has. Device attestation is a difficult topic, and the writeup shows exactly why.
- danr4 9y ago
  Agree. What's mostly worrying me is that Ledger's high ranking officials seem to lack basic communication skills for a company selling such critical devices. You can see that in the author's section of his dealing with Ledger, and if you go to /r/ledgerwallet subrredit you'll be able to see their interaction rubs off as quite a bit condescending to downright insulting[0] considering people have lost money over some issues, shrugging it off as "it's your fault". [0] https://www.reddit.com/r/ledgerwallet/comments/7tvyar/psa_do_not_use_the_official_ledger_ethereum_app/dtfqt7j/ https://www.reddit.com/r/ledgerwallet/comments/7tvyar/psa_do...
StavrosK 9y ago
I got a Ledger wallet and was too paranoid to trust its seed generation, so I wrote some code to generate my own seed on an ESP8266 (after a failed attempt at doing the same thing with just a PDF and dice). Here's the writeup, with code you can audit/try: https://www.stavros.io/posts/perfectly-secure-bitcoin-wallet-generation/ https://www.stavros.io/posts/perfectly-secure-bitcoin-wallet...
- fokinsean 9y ago
  Shit I got mine through Amazon a few months ago and was a bit worried it could be compromised. My paranoia is kicking in a bit more now after this article. Do you have any recommendations on checking that my Ledger isn't compromised? Ledger has some suggestions on their site, but as far as I understand they only check the integrity of the wallet apps.
  - StavrosK 9y ago
    From what the article says, you basically can't be sure, unless you check the hardware. I would advise at least flashing the original firmware that you can get from Ledger themselves.
    - fokinsean 9y ago
      Ok thanks will do.
    - fokinsean 9y ago
      I just saw Ledger posted this. https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-security-fixes/ https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-secu... Sounds like it will check if it is compromised via the update.
    - gh02t 9y ago
      Am I correct in understanding that the exploit would most likely be cleared by re-flashing the firmware to a known good image before you use it? Especially if you did so using JTAG it seems like it'd be very difficult (albeit probably not impossible) for the firmware modifications described in the article to persist through a reflash as long as you're reasonably confident that the hardware itself hasn't been altered. That doesn't get rid of the evil maid scenario, but it does get rid of the supply chain attack, which is IMO the more concerning one. Evil maid attacks can be mitigated by physical security, but the supply chain attack is out of your control.
limpkin 9y ago
Disclosure: I'm the creator of Mooltipass. When creating the Mooltipass offline password keeper we actually spent a considerable amount of time thinking about solutions for the particular problem explained on this website. We therefore opted for the following techniques: - only allow signed firmware updates, signed using an encryption key unique to each device - given that firmware flashing using external programmers requires complete flash/eeprom erase, we implemented a challenge/response protocol to check for tampering during shipping. Obviously things are way easier when you don't allow custom firmwares to be flashed on a device. But as a general rule I wouldn't trust a device that would allow other programs to run on it (eg phones, computers...)
debatem1 9y ago
Cool attack, but the the proposed mitigations don't seem to solve the threat model. An attacker on the supply chain can always add a part that interposes on all i/o to the secure parts. This would have the same impact, unless I'm missing something, as compromising the insecure micro. The underlying problem is that there's no cryptographically secure path between the secure element and your eyes. Ledger's verifiable erasure scheme is pretty interesting, actually. I prototyped something similar and ultimately abandoned it due to the high complexity and bandwidth requirements. From the sounds of it the major differences were that ledger didn't attempt to wipe and then reinitialize, but instead just tried to verify know state. Might still be made to work by changing that, although good luck over a uart.
- limpkin 9y ago
  An attack on the supply chain would have to happen at the very last stages when the device is assembled, as the assembler would otherwise notice the added component. I would even dare to say that the attack on the supply chain you're describing can only be done by the device assembler itself.
  - thinkmassive 9y ago
    The NSA is laughing https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa...
  - rebuilder 9y ago
    Could the manufacturer perform this type of "attack" on their own supply chain?
nicpottier 9y ago
I have both a Ledger and Trezor and would recommend the latter even before this vulnerability. Their Ether support is meh, but for BTC it just feels more solid and well thought out. That they are open source (hardware and software) and have been very responsive to attacks found also helps on the trust front. Haven't played with the newer Model-T with a touchscreen, I'm talking about the original Trezor which I believe they have no plans to EOL.
- lawn 9y ago
  Trezor's design does have problems of its own: https://medium.com/@Zero404Cool/trezor-security-glitches-reveal-your-private-keys-761eeab03ff8 https://medium.com/@Zero404Cool/trezor-security-glitches-rev... Which to my untrained eye looks more severe.
  - nicpottier 9y ago
    That was addressed in a firmware update. All systems will have vulnerabilities, the important bit is how the companies react. Trezor has been pretty great IMO in that respect and that all their stuff is open gives me a bit more confidence that it has been well attacked and patched. https://blog.trezor.io/trezor-firmware-security-update-1-5-2-5ef1b6f13fed https://blog.trezor.io/trezor-firmware-security-update-1-5-2...
asymmetric 9y ago
Seems like Ledger finally published a security advisory[0]. It also seems like they finally accepted OP's bug report as part of their bounty program. [0]: https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-security-fixes/ https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-secu...
AlphaWeaver 9y ago
Saleem Rashid, the security researcher who discovered this vulnerability and proof of concept is 15 years old. [0] [0]: https://krebsonsecurity.com/2018/03/15-year-old-finds-flaw-in-ledger-crypto-wallet/ https://krebsonsecurity.com/2018/03/15-year-old-finds-flaw-i...
- ReverseCold 9y ago
  I met him on Telegram a while back. The joke is that he developed a wallet app in X months, but could have done it in less if he didn't have homework. He's definitely one of my motivations to pursue blockchain/cryptography. I used to be secure (in my bubble) that I was the best at what I do (for my age) until I met Saleem. Gratz Saleem :)
p0nce 9y ago
Ledger's synchronized post[0] is a nice read. [0] https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-security-fixes/ https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-secu...
Blackthorn 9y ago
> Before I get to the details of the vulnerability, I would like to make it clear that I have not been paid a bounty by Ledger because their responsible disclosure agreement would have prevented me from publishing this technical report. Ridiculous. Ledger, pay him the bounty that he quite clearly deserves.
- jv22222 9y ago
  On the ledger blog: https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-security-fixes/ https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-secu... > We would like to congratulate the three security researchers who found these bounties. > Saleem Rashid – MCU fooling > We fully appreciate their contribution, and they certainly deserve their rewards. > We have asked each security researcher to sign our Ledger Bounty Program Reward Agreement, that you can review as part of our transparency process > (this document doesn’t prevent the researcher to publish their own reports).
  - EthanHeilman 9y ago
    The "Ledger Bounty Program Reward Agreement" appears to have a clause that may allow Ledger to prevent a researcher from publish their own report. >"You have complied and will continue to comply with the responsible disclosure process described in the Ledger Bounty Program which includes your agreement (a) not to disclose the security related bug to anyone without Ledger’s prior written consent," - [0] I'm not a lawyer so I could be reading this wrong or maybe they never intended to enforce that clause. [0]: Ledger Bounty Program Reward Agreement https://www.ledger.fr/wp-content/uploads/2018/03/Ledger-Bounty-Program-Reward-Agreement.pdf https://www.ledger.fr/wp-content/uploads/2018/03/Ledger-Boun...
- invalidusernam3 9y ago
  Agreed, but if it's one or the other I would rather have "Discovered vulnerability with Ledger crypto wallet when I was 15" on my CV than a couple thousand dollar bounty
- slavik81 9y ago
  I was curious whether there was any advantage to being a 15-year-old in this case, so I did a bit of research. As a minor in the UK, he's not capable of entering into a commercial contract, so he could void the contract at any point before the age of 18. Normally when a contract is voided, the parties are returned to their prior state. But, it seems that the doctrine of restitution makes an exception for people incapable of contracting. They are not required to return benefits received under the voided contract. I am not a lawyer, but I think he could have signed the contract, published his piece, and kept his money even if it was against the terms of the contract.
abhishekjha 9y ago
I can't say I understand a lot of it. Where can I read more on hardware exploits and how people figure them out?
rdl 9y ago
I was willing to tolerate Ledger's issues here (I'm a user and I've heavily recommended their products) if they fixed them -- the problems never should have happened, but they are marginally better than Trezor in a lot of other ways. Unfortunately, the Ledger team appear to be asshats, so there's every reason to fear using them in the future, even if they've fixed this specific issue. If they're going to handle a legit issue like this (downplaying it, etc.), I'm not willing to trust them. I'd love to see three products created: 1) Split client/server wallets (so you don't need to trust the operator or your local machine alone); some work has been done on this. Also, split PC + SGX or phone + secure element wallets. This is basically software-only in cost, but at higher security, so it would be suitable for $0+ balance accounts. 2) A low end ($20?) wallet with a cheap display and button. If you retailed them at $100 but sold them to providers at $40 they could probably give them away for a lot of accounts; basically like Yubikeys but with displays. 3) Some higher-end hardware wallets; essentially HSMs plus display/input. HSM technology basically stagnated in 1995; there's a lot of need for something better today. This could be in the $10-50k per unit range for a lot of high-value keys if actually implemented well and in a way which had no "trust us" demons. There are hundreds or thousands of potential customers, and more by the day.
- jnwatson 9y ago
  At at previous job, we made an HSM. We spent a lot of time considering manufacturing and evil maid attacks. There are solutions. The biggest important leap of faith is that the manufacturer must be able to lock themselves out of the device. This involves physical tamper resistance and people processes. And lots of key management.
- Hydraulix989 9y ago
  1. Can be implemented using N-of-M signing. GreenAddress does something similar.
- 1ba9115454 9y ago
  1) There's already some work on this. Take a look at https://carbonwallet.com https://carbonwallet.com A multisignature wallet with one key encrypted browser side and another in a mobile app. https://github.com/carbonwallet/CarbonKey https://github.com/carbonwallet/CarbonKey The CarbonKey app is a simple PWA (Progressive Web App) so you can deploy it yourself and completely bypass the wallet owners supply chain.
kirankn 9y ago
Very logical explanation of the exploit. Thanks.
lisper 9y ago
I build and sell a hardware security dongle that runs 100% open-source software and generates its keys using an on-board HWRNG. https://sc4.us/hsm/ https://sc4.us/hsm/ I'm actively seeking help in porting a wallet app to the hardware. I am willing to pay to get this done.

232 points by danr4 9y ago

Matthew Green had a good analysis on why this is interesting also from outside a crypto currency perspective https://twitter.com/matthew_d_green/status/976066416267939840 https://twitter.com/matthew_d_green/status/97606641626793984...

berberous 9y ago
Interesting part: "For example, the iPhone SEP has a direct connection to the fingerprint reader, because the application processor isn’t trusted with that data. Weirdly FaceID departs from this but I digress." Anyone have any info on why FaceID works a different way? Because it needs more processing power?
- gok 9y ago
  The application processor needs access to the camera so that you can take pictures and transmit them outside of the phone.
  - detaro 9y ago
    Which it could do through the SEP if the SEP were powerful enough, or through a secondary interface.
    - gok 9y ago
      What would that accomplish? The entire point of having the SEP wired directly to the fingerprint reader is that fingerprint images never make it to the AP because there's no reason for that. If the SEP is just going to copy every image to the AP why not just have both processors connected to the camera? (which also removes the security surface of any SEP->AP image copying code)
- zxcvgm 9y ago
  I have not seen any sources which explicitly state that FaceID doesn't work the same way as TouchID does, but perhaps it's the lack of specific details in the iOS Security Guide [0] that might have led to this assumption? In fact, FaceID solely relies on the IR camera to do its work. You can cover the front-facing (normal) camera and your iPhone would still unlock successfully. Conversely, the newly touted Animoji feature does NOT rely on the IR camera at all, as evidenced in this iPhone X review [1] at 11:40. It may be the case that the OS don't have access to it. [0] https://images.apple.com/business/docs/iOS_Security_Guide.pdf https://images.apple.com/business/docs/iOS_Security_Guide.pd... [1] https://www.youtube.com/watch?v=9Ca8zWJOlFQ&t=700 https://www.youtube.com/watch?v=9Ca8zWJOlFQ&t=700
  - matthewdgreen 9y ago
    I based my speculation on tweets by some developers who have been able to capture raw TrueDepth data in their apps. See eg https://mobile.twitter.com/braddwyer/status/930682879977361408 https://mobile.twitter.com/braddwyer/status/9306828799773614... I can’t swear to you that this is exactly the same depth data that FaceID uses. Maybe it’s been downsampled in some way that makes it safe to give to apps, without enabling attacks on FaceID. I think I’d be a bit more willing to believe that if Apple’s Security docs actually said that. To me it seems more likely that the raw depth maps are available to the app processor (and to apps!) because the SEP isn’t powerful enough to perform the recognition task on its own.

gruez 9y ago

>Physical access before setup of the seed I can't watch the video (says unsupported mime type on my browser), but I heard the attack goes something like this: intercept the wallet, set up the wallet and copy the seed, repackage it, hope the victim uses the wallet as-is (with the seed you copied). Can't this be mitigated by resetting the device when you first get it? >2 variants of "firmware reflash" I thought firmware updates are signed? edit: disregard the second point. further down it mentions that only SE firmware is signed >Evil Maid attack Is it even possible to mitigate this? At the very least you can steal the original, replace it with a replica that looks the same, BUT all it does is send back the password to you (via bluetooth, wifi, gsm, whatever). You can even hook up the stolen wallet on the other end so it correctly respond whether the password is correct/wrong and immediately drain the wallet once the correct password is transmitted.

StavrosK 9y ago
> Can't this be mitigated by resetting the device when you first get it? No, he demonstrates a device going through setup and "generating" a predetermined seed. It's not the easier "your wallet has already been set up for you" attack.
- dbrgn 9y ago
  To be precise, he overwrites the entropy source with zeroes, so that all words (except the last one) of the seed are "abandon". With a non-zero entropy source, you could generate random looking but deterministic seeds.

limpkin 9y ago

Wait... so the ledger allows any firmware to be uploaded without signature checking? damn :(

ghthor 9y ago
Seems insane right? Their entire userbase only exists because of the power that PKCrypto gives us to build lasting lines of trust and they don't sign firmware images....

AlexCoventry 9y ago

I picked up a Ledger in a raffle at a meetup a few months ago, and it's just been sitting around ever since because I was concerned about this kind of risk. It's a bit of a shame... Can't ethically sell it for the same reason. Fortunately, I was recently able to use it to introduce a curious friend of mine to Ethereum, using small amounts, so there's been at least some benefit.

StavrosK 9y ago
Keep in mind that, even with these vulnerabilities, the Ledger is still the safest you can get for cryptocurrency storage.
- yarrel 9y ago
  Trezor is better.
  - StavrosK 9y ago
    How so? Trezor had a vulnerability where you could extract the private keys by measuring power draw.
  - charlesdm 9y ago
    Trezor seems much worse, in nearly every security write-up I have read.
- lawn 9y ago
  Except an encrypted seed in cold storage. If you want to spend it you'll have different problems though.
  - StavrosK 9y ago
    Yeah, the problem with offline/paper seeds is that, if you want to spend them, you're going to become more vulnerable than with a hardware wallet, and they're single-use. Not to mention that they're hard to generate securely.

1upon0 9y ago

This needs much more visibility than it presently has. Device attestation is a difficult topic, and the writeup shows exactly why.

danr4 9y ago
Agree. What's mostly worrying me is that Ledger's high ranking officials seem to lack basic communication skills for a company selling such critical devices. You can see that in the author's section of his dealing with Ledger, and if you go to /r/ledgerwallet subrredit you'll be able to see their interaction rubs off as quite a bit condescending to downright insulting[0] considering people have lost money over some issues, shrugging it off as "it's your fault". [0] https://www.reddit.com/r/ledgerwallet/comments/7tvyar/psa_do_not_use_the_official_ledger_ethereum_app/dtfqt7j/ https://www.reddit.com/r/ledgerwallet/comments/7tvyar/psa_do...

StavrosK 9y ago

I got a Ledger wallet and was too paranoid to trust its seed generation, so I wrote some code to generate my own seed on an ESP8266 (after a failed attempt at doing the same thing with just a PDF and dice). Here's the writeup, with code you can audit/try: https://www.stavros.io/posts/perfectly-secure-bitcoin-wallet-generation/ https://www.stavros.io/posts/perfectly-secure-bitcoin-wallet...

fokinsean 9y ago
Shit I got mine through Amazon a few months ago and was a bit worried it could be compromised. My paranoia is kicking in a bit more now after this article. Do you have any recommendations on checking that my Ledger isn't compromised? Ledger has some suggestions on their site, but as far as I understand they only check the integrity of the wallet apps.
- StavrosK 9y ago
  From what the article says, you basically can't be sure, unless you check the hardware. I would advise at least flashing the original firmware that you can get from Ledger themselves.
  - fokinsean 9y ago
    Ok thanks will do.
  - fokinsean 9y ago
    I just saw Ledger posted this. https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-security-fixes/ https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-secu... Sounds like it will check if it is compromised via the update.
  - gh02t 9y ago
    Am I correct in understanding that the exploit would most likely be cleared by re-flashing the firmware to a known good image before you use it? Especially if you did so using JTAG it seems like it'd be very difficult (albeit probably not impossible) for the firmware modifications described in the article to persist through a reflash as long as you're reasonably confident that the hardware itself hasn't been altered. That doesn't get rid of the evil maid scenario, but it does get rid of the supply chain attack, which is IMO the more concerning one. Evil maid attacks can be mitigated by physical security, but the supply chain attack is out of your control.

limpkin 9y ago

Disclosure: I'm the creator of Mooltipass. When creating the Mooltipass offline password keeper we actually spent a considerable amount of time thinking about solutions for the particular problem explained on this website. We therefore opted for the following techniques: - only allow signed firmware updates, signed using an encryption key unique to each device - given that firmware flashing using external programmers requires complete flash/eeprom erase, we implemented a challenge/response protocol to check for tampering during shipping. Obviously things are way easier when you don't allow custom firmwares to be flashed on a device. But as a general rule I wouldn't trust a device that would allow other programs to run on it (eg phones, computers...)

debatem1 9y ago

Cool attack, but the the proposed mitigations don't seem to solve the threat model. An attacker on the supply chain can always add a part that interposes on all i/o to the secure parts. This would have the same impact, unless I'm missing something, as compromising the insecure micro. The underlying problem is that there's no cryptographically secure path between the secure element and your eyes. Ledger's verifiable erasure scheme is pretty interesting, actually. I prototyped something similar and ultimately abandoned it due to the high complexity and bandwidth requirements. From the sounds of it the major differences were that ledger didn't attempt to wipe and then reinitialize, but instead just tried to verify know state. Might still be made to work by changing that, although good luck over a uart.

limpkin 9y ago
An attack on the supply chain would have to happen at the very last stages when the device is assembled, as the assembler would otherwise notice the added component. I would even dare to say that the attack on the supply chain you're describing can only be done by the device assembler itself.
- thinkmassive 9y ago
  The NSA is laughing https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa...
- rebuilder 9y ago
  Could the manufacturer perform this type of "attack" on their own supply chain?

nicpottier 9y ago

I have both a Ledger and Trezor and would recommend the latter even before this vulnerability. Their Ether support is meh, but for BTC it just feels more solid and well thought out. That they are open source (hardware and software) and have been very responsive to attacks found also helps on the trust front. Haven't played with the newer Model-T with a touchscreen, I'm talking about the original Trezor which I believe they have no plans to EOL.

lawn 9y ago
Trezor's design does have problems of its own: https://medium.com/@Zero404Cool/trezor-security-glitches-reveal-your-private-keys-761eeab03ff8 https://medium.com/@Zero404Cool/trezor-security-glitches-rev... Which to my untrained eye looks more severe.
- nicpottier 9y ago
  That was addressed in a firmware update. All systems will have vulnerabilities, the important bit is how the companies react. Trezor has been pretty great IMO in that respect and that all their stuff is open gives me a bit more confidence that it has been well attacked and patched. https://blog.trezor.io/trezor-firmware-security-update-1-5-2-5ef1b6f13fed https://blog.trezor.io/trezor-firmware-security-update-1-5-2...

asymmetric 9y ago

Seems like Ledger finally published a security advisory[0]. It also seems like they finally accepted OP's bug report as part of their bounty program. [0]: https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-security-fixes/ https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-secu...

AlphaWeaver 9y ago

Saleem Rashid, the security researcher who discovered this vulnerability and proof of concept is 15 years old. [0] [0]: https://krebsonsecurity.com/2018/03/15-year-old-finds-flaw-in-ledger-crypto-wallet/ https://krebsonsecurity.com/2018/03/15-year-old-finds-flaw-i...

ReverseCold 9y ago
I met him on Telegram a while back. The joke is that he developed a wallet app in X months, but could have done it in less if he didn't have homework. He's definitely one of my motivations to pursue blockchain/cryptography. I used to be secure (in my bubble) that I was the best at what I do (for my age) until I met Saleem. Gratz Saleem :)

p0nce 9y ago

Ledger's synchronized post[0] is a nice read. [0] https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-security-fixes/ https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-secu...

Blackthorn 9y ago

> Before I get to the details of the vulnerability, I would like to make it clear that I have not been paid a bounty by Ledger because their responsible disclosure agreement would have prevented me from publishing this technical report. Ridiculous. Ledger, pay him the bounty that he quite clearly deserves.

jv22222 9y ago
On the ledger blog: https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-security-fixes/ https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-secu... > We would like to congratulate the three security researchers who found these bounties. > Saleem Rashid – MCU fooling > We fully appreciate their contribution, and they certainly deserve their rewards. > We have asked each security researcher to sign our Ledger Bounty Program Reward Agreement, that you can review as part of our transparency process > (this document doesn’t prevent the researcher to publish their own reports).
- EthanHeilman 9y ago
  The "Ledger Bounty Program Reward Agreement" appears to have a clause that may allow Ledger to prevent a researcher from publish their own report. >"You have complied and will continue to comply with the responsible disclosure process described in the Ledger Bounty Program which includes your agreement (a) not to disclose the security related bug to anyone without Ledger’s prior written consent," - [0] I'm not a lawyer so I could be reading this wrong or maybe they never intended to enforce that clause. [0]: Ledger Bounty Program Reward Agreement https://www.ledger.fr/wp-content/uploads/2018/03/Ledger-Bounty-Program-Reward-Agreement.pdf https://www.ledger.fr/wp-content/uploads/2018/03/Ledger-Boun...
invalidusernam3 9y ago
Agreed, but if it's one or the other I would rather have "Discovered vulnerability with Ledger crypto wallet when I was 15" on my CV than a couple thousand dollar bounty
slavik81 9y ago
I was curious whether there was any advantage to being a 15-year-old in this case, so I did a bit of research. As a minor in the UK, he's not capable of entering into a commercial contract, so he could void the contract at any point before the age of 18. Normally when a contract is voided, the parties are returned to their prior state. But, it seems that the doctrine of restitution makes an exception for people incapable of contracting. They are not required to return benefits received under the voided contract. I am not a lawyer, but I think he could have signed the contract, published his piece, and kept his money even if it was against the terms of the contract.

abhishekjha 9y ago

I can't say I understand a lot of it. Where can I read more on hardware exploits and how people figure them out?

rdl 9y ago

I was willing to tolerate Ledger's issues here (I'm a user and I've heavily recommended their products) if they fixed them -- the problems never should have happened, but they are marginally better than Trezor in a lot of other ways. Unfortunately, the Ledger team appear to be asshats, so there's every reason to fear using them in the future, even if they've fixed this specific issue. If they're going to handle a legit issue like this (downplaying it, etc.), I'm not willing to trust them. I'd love to see three products created: 1) Split client/server wallets (so you don't need to trust the operator or your local machine alone); some work has been done on this. Also, split PC + SGX or phone + secure element wallets. This is basically software-only in cost, but at higher security, so it would be suitable for $0+ balance accounts. 2) A low end ($20?) wallet with a cheap display and button. If you retailed them at $100 but sold them to providers at $40 they could probably give them away for a lot of accounts; basically like Yubikeys but with displays. 3) Some higher-end hardware wallets; essentially HSMs plus display/input. HSM technology basically stagnated in 1995; there's a lot of need for something better today. This could be in the $10-50k per unit range for a lot of high-value keys if actually implemented well and in a way which had no "trust us" demons. There are hundreds or thousands of potential customers, and more by the day.

jnwatson 9y ago
At at previous job, we made an HSM. We spent a lot of time considering manufacturing and evil maid attacks. There are solutions. The biggest important leap of faith is that the manufacturer must be able to lock themselves out of the device. This involves physical tamper resistance and people processes. And lots of key management.
Hydraulix989 9y ago
1. Can be implemented using N-of-M signing. GreenAddress does something similar.
1ba9115454 9y ago
1) There's already some work on this. Take a look at https://carbonwallet.com https://carbonwallet.com A multisignature wallet with one key encrypted browser side and another in a mobile app. https://github.com/carbonwallet/CarbonKey https://github.com/carbonwallet/CarbonKey The CarbonKey app is a simple PWA (Progressive Web App) so you can deploy it yourself and completely bypass the wallet owners supply chain.

kirankn 9y ago

Very logical explanation of the exploit. Thanks.

lisper 9y ago

I build and sell a hardware security dongle that runs 100% open-source software and generates its keys using an on-board HWRNG. https://sc4.us/hsm/ https://sc4.us/hsm/ I'm actively seeking help in porting a wallet app to the hardware. I am willing to pay to get this done.