5 ms·

DRM can be used for good as well as bad; it is about control. Most DRM is used for corporations to control you. But you can use things like this readout protect

DRM can be used for good as well as bad; it is about control. Most DRM is used for corporations to control you. But you can use things like this readout protection and Restricted ("Secure") Boot to get control over your own devices. If the BIOS lets you use your own keys (many do), Restricted Boot prevents attackers from booting unauthorized software on your computer. Similarly readout protection just hides the code on the device; this is useful for anyone who wants added security (security through obscurity is not perfect but it is always helpful). In that regard this news is bad since it means a security tool has been broken. But it is good in that the security tool was very often used by evildoers. Of course both of these examples rely on you trusting the bios & rdp implementation - ideally they would be open source.

saagarjha 7y ago
> Similarly readout protection just hides the code on the device; this is useful for anyone who wants added security (security through obscurity is not perfect but it is always helpful). Trying to hide your code is a stupid thing to do. Trying to hide cryptographic keys is more useful (though still often only used for DRM applications) but preventing people from dumping your firmware is misguided.
- bfrog 7y ago
  Where do you think keys are stored on occasion?
  - saagarjha 7y ago
    :(
- zimmerfrei 7y ago
  > Trying to hide your code is a stupid thing to do That's not what I hear from reputable reverse engineers, at least for IoT devices. Even though security by obscurity should be frowned upon, and being understood that hiding code might give a false sense of security, most RE workflows assume availability of firmware, and it is a giant pain to start breaking platforms where the unknown firmware must be manually extracted first, especially the boot loader.
  - maxbond 7y ago
    I agree. I've said before on this site, obscurity is a totally valid tactic to impose additional costs on attackers. It's best to think of it more as a preemptive strike than a defensive layer. Thinking of it as a defensive layer can lead to complacency, but thinking of it as an opening gambit is totally fine. One shouldn't be obsequious to heuristics like "never use security through obscurity," one should understand the systems they're building and make considered choices. Additionally, preventing people from dumping your firmware is usually not about security as much as it is preventing some fly-by-night company from reversing your product & selling it as their own. Why engineer a product when you can steal someone else's IP?
    - saagarjha 7y ago
      It also gives security engineers who are looking for bugs in your code more reason to hate you, and heaven forbid that they have less perseverance than a determined attacker. Also, what’s so special about your slow and buggy libc and statically linked in crypto?
      - maxbond 7y ago
        The salary of the engineer who built it. If you hire those security engineers, you can give them access to the source code. If you didn't hire them, there is no way to tell benign attackers from other attackers, and they can deal. It probably won't give them much trouble anyway. :)
        saagarjha 7y ago
        > If you didn't hire them, there is no way to tell benign attackers from other attackers, and they can deal. The better way to deal with this is to make your firmware secure regardless of whether someone can pull it off your device. Making security engineers’ lives difficult just means that you’ll find out about bugs from the news when they’re being sold to authoritarian countries to suppress dissents rather than the paper on firmware security that a graduate student was going to write before they decided to move to a much nicer platform.

saagarjha 7y ago

> Similarly readout protection just hides the code on the device; this is useful for anyone who wants added security (security through obscurity is not perfect but it is always helpful). Trying to hide your code is a stupid thing to do. Trying to hide cryptographic keys is more useful (though still often only used for DRM applications) but preventing people from dumping your firmware is misguided.

bfrog 7y ago
Where do you think keys are stored on occasion?
- saagarjha 7y ago
  :(
zimmerfrei 7y ago
> Trying to hide your code is a stupid thing to do That's not what I hear from reputable reverse engineers, at least for IoT devices. Even though security by obscurity should be frowned upon, and being understood that hiding code might give a false sense of security, most RE workflows assume availability of firmware, and it is a giant pain to start breaking platforms where the unknown firmware must be manually extracted first, especially the boot loader.
- maxbond 7y ago
  I agree. I've said before on this site, obscurity is a totally valid tactic to impose additional costs on attackers. It's best to think of it more as a preemptive strike than a defensive layer. Thinking of it as a defensive layer can lead to complacency, but thinking of it as an opening gambit is totally fine. One shouldn't be obsequious to heuristics like "never use security through obscurity," one should understand the systems they're building and make considered choices. Additionally, preventing people from dumping your firmware is usually not about security as much as it is preventing some fly-by-night company from reversing your product & selling it as their own. Why engineer a product when you can steal someone else's IP?
  - saagarjha 7y ago
    It also gives security engineers who are looking for bugs in your code more reason to hate you, and heaven forbid that they have less perseverance than a determined attacker. Also, what’s so special about your slow and buggy libc and statically linked in crypto?
    - maxbond 7y ago
      The salary of the engineer who built it. If you hire those security engineers, you can give them access to the source code. If you didn't hire them, there is no way to tell benign attackers from other attackers, and they can deal. It probably won't give them much trouble anyway. :)
      - saagarjha 7y ago
        > If you didn't hire them, there is no way to tell benign attackers from other attackers, and they can deal. The better way to deal with this is to make your firmware secure regardless of whether someone can pull it off your device. Making security engineers’ lives difficult just means that you’ll find out about bugs from the news when they’re being sold to authoritarian countries to suppress dissents rather than the paper on firmware security that a graduate student was going to write before they decided to move to a much nicer platform.