5 ms·

But it can be about you trusting your device. And the applications of trusted computing are absolutely about preventing medical records from being compromised,

But it can be about you trusting your device. And the applications of trusted computing are absolutely about preventing medical records from being compromised, but that's not a sexy headline in the same way that DRM is.

tptacek 13y ago
It is interesting to consider how content protection and platform security can be two sides of the same coin; how systems that keep code you write from snatching video frames from The Avengers can (often are) the same as the ones that keep malicious code on your device from stealing your credit card.
- Zigurd 13y ago
  Except that when you allow a third party to put code in a trusted element, it's Big Brother Inside. It's like installing someone else's security camera in your house. Odious.
  - tptacek 13y ago
    I wonder if the rootkit developers feel the same way, since the technology we're talking about (TZ) is designed to stop them as well.
    - betterunix 13y ago
      Is there some reason to think that a rootkit could not use this technology? Do you have details about this system (which, to my knowledge, are proprietary) that leads you to be believe it is something other than a way to reduce user control of their own devices (which could be a good thing for a rootkit)?
      - tptacek 13y ago
        It's a video decoding block that works with TrustZone. TZ is well-documented and conceptually very simple.
        betterunix 13y ago
        I have not been able to find anything other than marketing material; maybe I am just looking in the wrong places. Can you provide a link to some technical details?
        tptacek 13y ago
        Were you not looking on Google? http://lmgtfy.com/?q=trustzone+arm http://lmgtfy.com/?q=trustzone+arm Read the first PDF on that page.
- timthorn 13y ago
  Absolutely. And I completely get the fear of losing control of one's own device, but given the downvotes I've had today on this topic - an open question: What's the preferred approach amongst this audience to defend against malware on their platforms?
  - betterunix 13y ago
    "What's the preferred approach amongst this audience to defend against malware on their platforms?" Make hiding software hard, make reimaging the system easy.
    - tptacek 13y ago
      And you would do that exactly how? Be as specific as you can.
      - betterunix 13y ago
        They are just design principles; I did not claim to have a well-planned design ready to go to market. Some operating systems make it harder to hide software than others; GNU/Linux makes hiding software more difficult than Windows or Mac OS X. Some computers are easier to reimage than others (e.g. special key sequences during the boot process will cause a "factory reset").
    - ised 13y ago
      For the record, I've already achieved this. It is not difficult. 1. Reduce the attack surface, i.e. total LOC. My base system is super small. More complex things can be run on top of it (e.g. via chroot), but the system I boot into is only about 16MB. With some effort, it could be shrunk to about 1/4 of that size. 2. Use only open source software; and refine your methods for searching through code for suspicious things. There's no shortage of open source solutions and folks right here on HN (e.g. Russ Cox) have been kind enough to share some decent methods for efficiently searching through code. 3. Boot from read-only external media, use a memory disk for the root filesystem and use tmpfs for all writable directories/partitions. This way boot times are fast and consistent, more so than with harddisk drives. And with the rootfs in memory, you can remove the external media after booting, freeing up the USB or SD card port for other things. It's very easy to replicate (clone, image, whatever you choose to call it) this system and transfer it to more external media. It takes only a short time to compile from scratch, even on underpowered computers. There is no "software installation". You insert the media and boot. That's it. You get the same pristine system every time you boot. To anyone who injects doubt and insinuates that such an approach to evading malware as betterunix suggests is infeasible or unachievable: I'm happy to prove you wrong.
Zigurd 13y ago
Really? Are there any real-world examples?
- tptacek 13y ago
  Yes: the Intel TPM / Secure Boot system's design goal is to stop rootkits, but is also used by vendors to load secure video decoding code.
  - Zigurd 13y ago
    That's an odd meaning of "secure."
    - tptacek 13y ago
      I'm sorry that engineering terminology isn't invariably compatible with your politics.
      - Zigurd 13y ago
        The post above referred to patient control over medical records using trusted elements. Is there a real-world case where any bureaucracy has yielded control of individuals' documents to those individuals through the use of trusted computing? Anywhere? In any subject matter? Is there any case where I can submit a documents and then be assured that i can revoke access? Anyone? Bueller?
        tptacek 13y ago
        Yes, there is, since "trusted computing" mostly refers to the idea of locking your running OS down so that attackers can't persist code that alters it. Which makes your clumsy "Bueller" thing all the funnier: it's like you literally can't imagine that hardware should be any more secure than an 80386.
  - betterunix 13y ago
    "Yes: the Intel TPM / Secure Boot system's design goal is to stop rootkits" Why would you need any cryptography to do this? I have a computer that uses a much simpler, equally effective, and easier-to-use approach: the boot sector cannot be overwritten unless the system is rebooted in a special mode (and the OS cannot be booted in that mode). At least for personal computing, that is far better than a system that forces people to rely on a trusted third party to decide what software they can run.
shmerl 13y ago
You can't trust a device which has DRM.
- tptacek 13y ago
  "But you can't trust a device on which the video decoder silicon understands the TZ bits".
  - shmerl 13y ago
    In the case where you have no control over the decoder while using the system. Is it clearer now? If you have control - then it's a non issue. Same as TPM can be used for something useful, but can be used for reducing user's control.
    - tptacek 13y ago
      Yes, you have control.
      - shmerl 13y ago
        If you have control (and can disable applying this to video decoding), what is the point for the DRM lobby to push for this thing? Their usual idea is to take control away.
        tptacek 13y ago
        This is a video decoder IP block that is simply compatible with the security architecture of the rest of the system. The only reason you think "the DRM lobby" is pushing for it is because Torrentfreak wrote that. Torrentfreak is a laughable source of technical content.
        shmerl 13y ago
        So you are implying that it's not related to encryption of the video?

tptacek 13y ago

It is interesting to consider how content protection and platform security can be two sides of the same coin; how systems that keep code you write from snatching video frames from The Avengers can (often are) the same as the ones that keep malicious code on your device from stealing your credit card.

Zigurd 13y ago
Except that when you allow a third party to put code in a trusted element, it's Big Brother Inside. It's like installing someone else's security camera in your house. Odious.
- tptacek 13y ago
  I wonder if the rootkit developers feel the same way, since the technology we're talking about (TZ) is designed to stop them as well.
  - betterunix 13y ago
    Is there some reason to think that a rootkit could not use this technology? Do you have details about this system (which, to my knowledge, are proprietary) that leads you to be believe it is something other than a way to reduce user control of their own devices (which could be a good thing for a rootkit)?
    - tptacek 13y ago
      It's a video decoding block that works with TrustZone. TZ is well-documented and conceptually very simple.
      - betterunix 13y ago
        I have not been able to find anything other than marketing material; maybe I am just looking in the wrong places. Can you provide a link to some technical details?
        tptacek 13y ago
        Were you not looking on Google? http://lmgtfy.com/?q=trustzone+arm http://lmgtfy.com/?q=trustzone+arm Read the first PDF on that page.
timthorn 13y ago
Absolutely. And I completely get the fear of losing control of one's own device, but given the downvotes I've had today on this topic - an open question: What's the preferred approach amongst this audience to defend against malware on their platforms?
- betterunix 13y ago
  "What's the preferred approach amongst this audience to defend against malware on their platforms?" Make hiding software hard, make reimaging the system easy.
  - tptacek 13y ago
    And you would do that exactly how? Be as specific as you can.
    - betterunix 13y ago
      They are just design principles; I did not claim to have a well-planned design ready to go to market. Some operating systems make it harder to hide software than others; GNU/Linux makes hiding software more difficult than Windows or Mac OS X. Some computers are easier to reimage than others (e.g. special key sequences during the boot process will cause a "factory reset").
  - ised 13y ago
    For the record, I've already achieved this. It is not difficult. 1. Reduce the attack surface, i.e. total LOC. My base system is super small. More complex things can be run on top of it (e.g. via chroot), but the system I boot into is only about 16MB. With some effort, it could be shrunk to about 1/4 of that size. 2. Use only open source software; and refine your methods for searching through code for suspicious things. There's no shortage of open source solutions and folks right here on HN (e.g. Russ Cox) have been kind enough to share some decent methods for efficiently searching through code. 3. Boot from read-only external media, use a memory disk for the root filesystem and use tmpfs for all writable directories/partitions. This way boot times are fast and consistent, more so than with harddisk drives. And with the rootfs in memory, you can remove the external media after booting, freeing up the USB or SD card port for other things. It's very easy to replicate (clone, image, whatever you choose to call it) this system and transfer it to more external media. It takes only a short time to compile from scratch, even on underpowered computers. There is no "software installation". You insert the media and boot. That's it. You get the same pristine system every time you boot. To anyone who injects doubt and insinuates that such an approach to evading malware as betterunix suggests is infeasible or unachievable: I'm happy to prove you wrong.

Zigurd 13y ago

Really? Are there any real-world examples?

tptacek 13y ago
Yes: the Intel TPM / Secure Boot system's design goal is to stop rootkits, but is also used by vendors to load secure video decoding code.
- Zigurd 13y ago
  That's an odd meaning of "secure."
  - tptacek 13y ago
    I'm sorry that engineering terminology isn't invariably compatible with your politics.
    - Zigurd 13y ago
      The post above referred to patient control over medical records using trusted elements. Is there a real-world case where any bureaucracy has yielded control of individuals' documents to those individuals through the use of trusted computing? Anywhere? In any subject matter? Is there any case where I can submit a documents and then be assured that i can revoke access? Anyone? Bueller?
      - tptacek 13y ago
        Yes, there is, since "trusted computing" mostly refers to the idea of locking your running OS down so that attackers can't persist code that alters it. Which makes your clumsy "Bueller" thing all the funnier: it's like you literally can't imagine that hardware should be any more secure than an 80386.
- betterunix 13y ago
  "Yes: the Intel TPM / Secure Boot system's design goal is to stop rootkits" Why would you need any cryptography to do this? I have a computer that uses a much simpler, equally effective, and easier-to-use approach: the boot sector cannot be overwritten unless the system is rebooted in a special mode (and the OS cannot be booted in that mode). At least for personal computing, that is far better than a system that forces people to rely on a trusted third party to decide what software they can run.

shmerl 13y ago

You can't trust a device which has DRM.

tptacek 13y ago
"But you can't trust a device on which the video decoder silicon understands the TZ bits".
- shmerl 13y ago
  In the case where you have no control over the decoder while using the system. Is it clearer now? If you have control - then it's a non issue. Same as TPM can be used for something useful, but can be used for reducing user's control.
  - tptacek 13y ago
    Yes, you have control.
    - shmerl 13y ago
      If you have control (and can disable applying this to video decoding), what is the point for the DRM lobby to push for this thing? Their usual idea is to take control away.
      - tptacek 13y ago
        This is a video decoder IP block that is simply compatible with the security architecture of the rest of the system. The only reason you think "the DRM lobby" is pushing for it is because Torrentfreak wrote that. Torrentfreak is a laughable source of technical content.
        shmerl 13y ago
        So you are implying that it's not related to encryption of the video?