11 ms·

Bypassing ESP32 Encrypted Secure Boot

165 points by mleonhard 6y ago

megous 6y ago
And this is why I don't understand people who think that without secure boot devices like Pinephone are insecure. Secure boot is nice optional protection, but real security comes from ability of the platform to reliably boot from known good media without any ability of the software outside that media to intervene. That is the only way you can know what you're booting/running. Relying on some crypto implementation and allowing other people to try to attempt to break it is a nice defense in depth, but not the ultimate protection, and may even induce false sense of security.
- lifty 6y ago
  A good secure boot implementation is nice, as long as you can add your own verification keys.
  - tatersolid 6y ago
    But that defeats the point of tamper-proof hardware: it should not be modifiable via software. Unless you make adding your own keys a one-time event and then blow fuses, I’m not sure you can have a secure boot chain slung with control over the hardware keys.
    - TeMPOraL 6y ago
      It's about ownership. I want to own my phone. That means whatever I do with it is by definition not tampering. The procedure should involve repeated ability to add and remove keys, but require direct physical access to the chip, perhaps by means of a separate device that's coded to only work with your phone, and that you would never carry together with your phone. Lacking that, I guess "one-time event and then blow fuses" is fine too, though end-users need to be warned up front they're doing something irreversible and must be absolutely sure to protect their key.
      - inetknght 6y ago
        One time events is not an okay tradeoff: the ability to revoke the key is important too. Keys aren't meant to last forever.
        tatersolid 6y ago
        Aren’t the trusted boot signing keys from MSFT burned in and therefore not revocable? Maybe they have multiple keys with some offline backup keys or something.
    - lifty 6y ago
      Or, if you need more flexibility, some kind of out-of bound mechanism that doesn't rely on the OS that is booting and you are trying to verify. This could be loaded via some kind of internal memory card or via an interface that requires access to the board. This opens you up to physical attacks but you get a bit of a middle ground between security and flexibility.
    - jojobas 6y ago
      You buy a blank chip and burn in a key. That's a reasonable model, unlike asking the chip vendor to sign your key.
    - a1369209993 6y ago
      Actually the solution is to store the secure-boot key and the full-disk-encryption key in the same place, and design the hardware so that erasing the former also erases the latter. You don't need any one-time anything.
- josteink 6y ago
  > Secure boot is nice optional protection, but real security comes from ability of the platform to reliably boot from known good media Which is exactly what (UEFI) Secure Boot usually aims to assist. I mean... One can complain how it tries to achieve that, but either you realize it or not, you are seemingly in full agreement with the overall design-goal of Secure Boot.
  - megous 6y ago
    As long as in-device firmware is modifiable and the protection relies on lack of bugs in its implementation, then I'm not in agreement. What I have in mind is just a fixed boot order enforced by firmware stored in ROM, where external storage takes priority, and where you can easily control external storage. (as easy as inserting a uSD card) All the TF-A, bootloader, kernel is loaded from the external storage, so no software at all is loaded from any modifiable storage that's part of the device itself, if you don't want to. Any attacker made changes to the software on the storage inside the device would be irrelevant. Such setup seems much better than having to assume no bugs in existing firmware or HW related to secure boot, etc.
phh 6y ago
That's a pretty nice write-up, and continues to show why hardened hardware is needed, not just software, if you actually have secrets to protect. One thing that struck me is "After running these experiments for more than a day, resulting in more than 1 million experiments, we did not observe any successful glitch…" That's like 100ms per test. Are those devices that fast to put into uart mode and reset and wait for the result? Were they running this with multiple devices in parallel?
- MayeulC 6y ago
  > continues to show why hardened hardware is needed, not just software, if you actually have secrets to protect Right. But I tend to disagree against the premise, though: I generally tend to think that an attacker with hardware access will compromise that hardware sooner or later, and you should design your security measures around that assumption. The only useful uses I see for this are: * Giving your HW for somebody else to operate, while hoping that this person won't recover secrets from the inside. * As a variant, locking customers out from using the HW with software it was not designed for, or extract the SW it came with. I am most often on the receiving end of the second option, and do not have any sympathy for it. The first issue is a trust issue, and I would avoid those situations anyway. Another option is: * Protect an unattended device against tampering Which is a bit saner, but you probably shouldn't leave a sensitive device unattended anyway, as it can always bite you back. What is desperately needed is the hardware equivalent of a software checksum, to verify that the device conforms to specs.
  - deleted 6y ago
    [deleted]
  - jon-wood 6y ago
    > You probably shouldn't leave a sensitive device unattended anyway I find this area fascinating in terms of how you protect devices that are both sensitive, and need to be left unattended in someone else's possession. One of the best explorations I've seen of this is Big Clive's tear down of a smart meter. The thing is absolutely full of anti-tampering measures, including several switches that will cut off the power supply if the casing is removed, but most interestingly to me the cellular modem being connected to a big capacitor designed to give it just enough power to send out a last cry for help even if the entire radio module is pulled off the meter. https://www.youtube.com/watch?v=G32NYQpvy8Q https://www.youtube.com/watch?v=G32NYQpvy8Q
userbinator 6y ago
This is a good thing --- it lets you actually own the hardware you purchased! I wonder what it is about the security industry that seems to make it full of corporate bootlickers who are all too proud to find and "fix" these "vulnerabilities" and continue the trend of locking users out.
- jakear 6y ago
  Secure boot is an option provided to users, not a manufacturer-instituted requirement.
  - londons_explore 6y ago
    An option provided to device manufacturers. When the user buys their smart IOT cheesegrater on Amazon, they get no option...
- Rebelgecko 6y ago
  In the security industry, getting owned is usually considered a bad thing
platz 6y ago
Are Bus Pirates still being produced? If not, what fills the same role in the toolbox (device multi-tool and rapid protocol testing without code)
- octorian 6y ago
  I've wasted enough time getting a Bus Pirate to try and behave when I wanted to test something that I pretty much gave up. Now I just keep a random Arduino board around and push snippets of scratch code to it for the same purpose. (And I say that as someone who doesn't really use Arduino boards for the final project.)
  - platz 6y ago
    fair enough - i guess the idea of the bus pirate was that it's flow was supposed to be faster than writing code, i.e. you want to peek & poke a target more interactively or exploratory just to see how the it behaves. but Yeah if you know exactly what you want to do why not just skip right to writing code for it with the arduino.
antoniuschan99 6y ago
Hrmm, this vulnerability seems to only affect the previous versions of the esp’s? There was a revision made after that glitching attach at the same time last year. ESP32-D0WDQ6 is the newest revision. It even says in the Security Advisory: The ESP32-D0WD-V3 and related products support a new RSA-based Secure Boot implementation (ESP32 Secure Boot V2) and have a feature to permanently disable the UART Download Mode via eFuse. Because of these modifications, these attacks can be prevented on ESP32 V3 SoCs and modules.

165 points by mleonhard 6y ago

And this is why I don't understand people who think that without secure boot devices like Pinephone are insecure. Secure boot is nice optional protection, but real security comes from ability of the platform to reliably boot from known good media without any ability of the software outside that media to intervene. That is the only way you can know what you're booting/running. Relying on some crypto implementation and allowing other people to try to attempt to break it is a nice defense in depth, but not the ultimate protection, and may even induce false sense of security.

lifty 6y ago
A good secure boot implementation is nice, as long as you can add your own verification keys.
- tatersolid 6y ago
  But that defeats the point of tamper-proof hardware: it should not be modifiable via software. Unless you make adding your own keys a one-time event and then blow fuses, I’m not sure you can have a secure boot chain slung with control over the hardware keys.
  - TeMPOraL 6y ago
    It's about ownership. I want to own my phone. That means whatever I do with it is by definition not tampering. The procedure should involve repeated ability to add and remove keys, but require direct physical access to the chip, perhaps by means of a separate device that's coded to only work with your phone, and that you would never carry together with your phone. Lacking that, I guess "one-time event and then blow fuses" is fine too, though end-users need to be warned up front they're doing something irreversible and must be absolutely sure to protect their key.
    - inetknght 6y ago
      One time events is not an okay tradeoff: the ability to revoke the key is important too. Keys aren't meant to last forever.
      - tatersolid 6y ago
        Aren’t the trusted boot signing keys from MSFT burned in and therefore not revocable? Maybe they have multiple keys with some offline backup keys or something.
  - lifty 6y ago
    Or, if you need more flexibility, some kind of out-of bound mechanism that doesn't rely on the OS that is booting and you are trying to verify. This could be loaded via some kind of internal memory card or via an interface that requires access to the board. This opens you up to physical attacks but you get a bit of a middle ground between security and flexibility.
  - jojobas 6y ago
    You buy a blank chip and burn in a key. That's a reasonable model, unlike asking the chip vendor to sign your key.
  - a1369209993 6y ago
    Actually the solution is to store the secure-boot key and the full-disk-encryption key in the same place, and design the hardware so that erasing the former also erases the latter. You don't need any one-time anything.
josteink 6y ago
> Secure boot is nice optional protection, but real security comes from ability of the platform to reliably boot from known good media Which is exactly what (UEFI) Secure Boot usually aims to assist. I mean... One can complain how it tries to achieve that, but either you realize it or not, you are seemingly in full agreement with the overall design-goal of Secure Boot.
- megous 6y ago
  As long as in-device firmware is modifiable and the protection relies on lack of bugs in its implementation, then I'm not in agreement. What I have in mind is just a fixed boot order enforced by firmware stored in ROM, where external storage takes priority, and where you can easily control external storage. (as easy as inserting a uSD card) All the TF-A, bootloader, kernel is loaded from the external storage, so no software at all is loaded from any modifiable storage that's part of the device itself, if you don't want to. Any attacker made changes to the software on the storage inside the device would be irrelevant. Such setup seems much better than having to assume no bugs in existing firmware or HW related to secure boot, etc.

phh 6y ago

That's a pretty nice write-up, and continues to show why hardened hardware is needed, not just software, if you actually have secrets to protect. One thing that struck me is "After running these experiments for more than a day, resulting in more than 1 million experiments, we did not observe any successful glitch…" That's like 100ms per test. Are those devices that fast to put into uart mode and reset and wait for the result? Were they running this with multiple devices in parallel?

MayeulC 6y ago
> continues to show why hardened hardware is needed, not just software, if you actually have secrets to protect Right. But I tend to disagree against the premise, though: I generally tend to think that an attacker with hardware access will compromise that hardware sooner or later, and you should design your security measures around that assumption. The only useful uses I see for this are: * Giving your HW for somebody else to operate, while hoping that this person won't recover secrets from the inside. * As a variant, locking customers out from using the HW with software it was not designed for, or extract the SW it came with. I am most often on the receiving end of the second option, and do not have any sympathy for it. The first issue is a trust issue, and I would avoid those situations anyway. Another option is: * Protect an unattended device against tampering Which is a bit saner, but you probably shouldn't leave a sensitive device unattended anyway, as it can always bite you back. What is desperately needed is the hardware equivalent of a software checksum, to verify that the device conforms to specs.
- deleted 6y ago
  [deleted]
- jon-wood 6y ago
  > You probably shouldn't leave a sensitive device unattended anyway I find this area fascinating in terms of how you protect devices that are both sensitive, and need to be left unattended in someone else's possession. One of the best explorations I've seen of this is Big Clive's tear down of a smart meter. The thing is absolutely full of anti-tampering measures, including several switches that will cut off the power supply if the casing is removed, but most interestingly to me the cellular modem being connected to a big capacitor designed to give it just enough power to send out a last cry for help even if the entire radio module is pulled off the meter. https://www.youtube.com/watch?v=G32NYQpvy8Q https://www.youtube.com/watch?v=G32NYQpvy8Q

userbinator 6y ago

This is a good thing --- it lets you actually own the hardware you purchased! I wonder what it is about the security industry that seems to make it full of corporate bootlickers who are all too proud to find and "fix" these "vulnerabilities" and continue the trend of locking users out.

jakear 6y ago
Secure boot is an option provided to users, not a manufacturer-instituted requirement.
- londons_explore 6y ago
  An option provided to device manufacturers. When the user buys their smart IOT cheesegrater on Amazon, they get no option...
Rebelgecko 6y ago
In the security industry, getting owned is usually considered a bad thing

platz 6y ago

Are Bus Pirates still being produced? If not, what fills the same role in the toolbox (device multi-tool and rapid protocol testing without code)

octorian 6y ago
I've wasted enough time getting a Bus Pirate to try and behave when I wanted to test something that I pretty much gave up. Now I just keep a random Arduino board around and push snippets of scratch code to it for the same purpose. (And I say that as someone who doesn't really use Arduino boards for the final project.)
- platz 6y ago
  fair enough - i guess the idea of the bus pirate was that it's flow was supposed to be faster than writing code, i.e. you want to peek & poke a target more interactively or exploratory just to see how the it behaves. but Yeah if you know exactly what you want to do why not just skip right to writing code for it with the arduino.

antoniuschan99 6y ago

Hrmm, this vulnerability seems to only affect the previous versions of the esp’s? There was a revision made after that glitching attach at the same time last year. ESP32-D0WDQ6 is the newest revision. It even says in the Security Advisory: The ESP32-D0WD-V3 and related products support a new RSA-based Secure Boot implementation (ESP32 Secure Boot V2) and have a feature to permanently disable the UART Download Mode via eFuse. Because of these modifications, these attacks can be prevented on ESP32 V3 SoCs and modules.