4 ms·

I've seen that article and it's a heap of crap. There's no reason they couldn't make the firmware read-only so you could verify it, then publish the source to a

I've seen that article and it's a heap of crap. There's no reason they couldn't make the firmware read-only so you could verify it, then publish the source to audit and verify against. >Reminder that open source projects are not provably more secure, nor is it easy (or even possible in many cases) to assert the source you see made the binary in question. I can (and do) read the code for security-related software, and I can at least check for obvious backdoors and flaws myself. With reproducable builds it is possible to assert the source you see made the binary in question (and security related software must support reproducable builds for this reason). If you want to convince yourself the product is secure, that's up to you, but it's not.

KirinDave 10y ago
You obviously didn't read the article. There is no way for you to actually do that. And the secure platforms themselves have NDAs around their specs and software tooling. So yeah, there is a reason they didn't do that. The hardware they're using specifically makes it difficult to do the verification you want to do. Which is directly related to foiling the kind of attacks they want to foil. > If you want to convince yourself the product is secure, that's up to you, but it's not I think we have the same goal, but you have a conviction that open source stops "obvious back doors." It in no way would help that at all in this case. The hardware is configured before it is shipped, then locked in a way designed to prevent rewriting or inspection. You have no rational basis for the belief that the source code on a website and the binary a malicious and deceptive actor would deploy to the hardware are the same thing. Being open source only affects the way security auditing can be done. It doesn't guarantee better quality.
- Sir_Cmpwn 10y ago
  I have read the article, several times, thank you very much. Don't take the easy way out by dismissing the opposition as ignorant. >So yeah, there is a reason they didn't do that. The hardware they're using specifically makes it difficult to do the verification you want to do. Which is directly related to foiling the kind of attacks they want to foil. Then they've chosen the wrong hardware. This doesn't make it more secure, it just explains why their product is insecure. >I think we have the same goal, but you have a conviction that open source stops "obvious back doors." It in no way would help that at all in this case. The hardware is configured before it is shipped, then locked in a way designed to prevent rewriting or inspection. You have no rational basis for the belief that the source code on a website and the binary a malicious and deceptive actor would deploy to the hardware are the same thing. I already addressed this - reproducable builds. I don't have to take anyone's word for it.
  - KirinDave 10y ago
    > Then they've chosen the wrong hardware. This doesn't make it more secure, it just explains why their product is insecure. If the hardware is more resistant to hardware and software attacks, it seems odd to then deem it less secure just because you don't get source code that isn't guaranteed to correspond to a given binary. > reproducable builds There's so much literature on how this methodology fails, some of it quite famous. There is no assurance that your device conforms to the build you can reproduce, unless you can arbitrarily inspect the state of the entire device at each step. Being able to do that would defeat the purpose of these devices.
    - Sir_Cmpwn 10y ago
      >If the hardware is more resistant to hardware and software attacks, it seems odd to then deem it less secure just because you don't get source code that isn't guaranteed to correspond to a given binary. It may be, but there's no guarantee it behaves the way it claims to. There's no guarantee it's not backdoored. There are powerful actors involved in these areas. >There's so much literature on how this methodology fails, some of it quite famous. There is no assurance that your device conforms to the build you can reproduce, unless you can arbitrarily inspect the state of the entire device at each step. Being able to do that would defeat the purpose of these devices. Care to cite some of this literature?
      - KirinDave 10y ago
        > It may be, but there's no guarantee it behaves the way it claims to. There's no guarantee it's not backdoored. There are powerful actors involved in these areas. It renders your point about source code moot though, doesn't it. Security is ultimately the art of trust propagation. > Care to cite some of this literature? The most famous discourse here is the "untrustworthy compiler problem." Most famous citation is by none other than Thompson: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp... Trust chains are their weakest link, and people often put a lot of trust in compilers without really asking what it is doing. Not unlike crypto, we're told not to roll our own. People have proposed ways around this, but they're not very good (http://imgur.com/a/BWbnU#0 http://imgur.com/a/BWbnU#0). The moral of the story is that at some point, you extend trust to someone. Security is never absolute.

KirinDave 10y ago

You obviously didn't read the article. There is no way for you to actually do that. And the secure platforms themselves have NDAs around their specs and software tooling. So yeah, there is a reason they didn't do that. The hardware they're using specifically makes it difficult to do the verification you want to do. Which is directly related to foiling the kind of attacks they want to foil. > If you want to convince yourself the product is secure, that's up to you, but it's not I think we have the same goal, but you have a conviction that open source stops "obvious back doors." It in no way would help that at all in this case. The hardware is configured before it is shipped, then locked in a way designed to prevent rewriting or inspection. You have no rational basis for the belief that the source code on a website and the binary a malicious and deceptive actor would deploy to the hardware are the same thing. Being open source only affects the way security auditing can be done. It doesn't guarantee better quality.

Sir_Cmpwn 10y ago
I have read the article, several times, thank you very much. Don't take the easy way out by dismissing the opposition as ignorant. >So yeah, there is a reason they didn't do that. The hardware they're using specifically makes it difficult to do the verification you want to do. Which is directly related to foiling the kind of attacks they want to foil. Then they've chosen the wrong hardware. This doesn't make it more secure, it just explains why their product is insecure. >I think we have the same goal, but you have a conviction that open source stops "obvious back doors." It in no way would help that at all in this case. The hardware is configured before it is shipped, then locked in a way designed to prevent rewriting or inspection. You have no rational basis for the belief that the source code on a website and the binary a malicious and deceptive actor would deploy to the hardware are the same thing. I already addressed this - reproducable builds. I don't have to take anyone's word for it.
- KirinDave 10y ago
  > Then they've chosen the wrong hardware. This doesn't make it more secure, it just explains why their product is insecure. If the hardware is more resistant to hardware and software attacks, it seems odd to then deem it less secure just because you don't get source code that isn't guaranteed to correspond to a given binary. > reproducable builds There's so much literature on how this methodology fails, some of it quite famous. There is no assurance that your device conforms to the build you can reproduce, unless you can arbitrarily inspect the state of the entire device at each step. Being able to do that would defeat the purpose of these devices.
  - Sir_Cmpwn 10y ago
    >If the hardware is more resistant to hardware and software attacks, it seems odd to then deem it less secure just because you don't get source code that isn't guaranteed to correspond to a given binary. It may be, but there's no guarantee it behaves the way it claims to. There's no guarantee it's not backdoored. There are powerful actors involved in these areas. >There's so much literature on how this methodology fails, some of it quite famous. There is no assurance that your device conforms to the build you can reproduce, unless you can arbitrarily inspect the state of the entire device at each step. Being able to do that would defeat the purpose of these devices. Care to cite some of this literature?
    - KirinDave 10y ago
      > It may be, but there's no guarantee it behaves the way it claims to. There's no guarantee it's not backdoored. There are powerful actors involved in these areas. It renders your point about source code moot though, doesn't it. Security is ultimately the art of trust propagation. > Care to cite some of this literature? The most famous discourse here is the "untrustworthy compiler problem." Most famous citation is by none other than Thompson: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp... Trust chains are their weakest link, and people often put a lot of trust in compilers without really asking what it is doing. Not unlike crypto, we're told not to roll our own. People have proposed ways around this, but they're not very good (http://imgur.com/a/BWbnU#0 http://imgur.com/a/BWbnU#0). The moral of the story is that at some point, you extend trust to someone. Security is never absolute.