2 ms·

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

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.
    - Sir_Cmpwn 10y ago
      >It renders your point about source code moot though, doesn't it. Security is ultimately the art of trust propagation. I don't see how that follows. If I can audit the source code and confirm that the same code is running on the device, the weak link is reduced to my ability to aduit it (combined with everyone else who's auditing it as well and might publish their findings). >The most famous discourse here is the "untrustworthy compiler problem." I thought this might be what you're talking about, but this is ridiculous. Do you really think that the Yubikey folks have backdoored my copy of gcc? Dude.
      - KirinDave 10y ago
        > the weak link is reduced to my ability to aduit it (combined with everyone else who's auditing it as well and might publish their findings). And if the hardware itself has microcode that overrides your code? > but this is ridiculous. Do you really think that the Yubikey folks have backdoored my copy of gcc? Actually, I think the first and foremest threat would be, "Could someone insert a yubikey into a malicious device that changed its behavior such that it now leaks information and does not provide actual security." Because those kinds of attacks actually exist. Ultimately, what you're arguing for is the pleasure and moral superiority of being able to do that audit. Not only does that audit not give you many guarantees, but giving you the ability to do that audit opens you up to much more sinister attacks.

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.
  - Sir_Cmpwn 10y ago
    >It renders your point about source code moot though, doesn't it. Security is ultimately the art of trust propagation. I don't see how that follows. If I can audit the source code and confirm that the same code is running on the device, the weak link is reduced to my ability to aduit it (combined with everyone else who's auditing it as well and might publish their findings). >The most famous discourse here is the "untrustworthy compiler problem." I thought this might be what you're talking about, but this is ridiculous. Do you really think that the Yubikey folks have backdoored my copy of gcc? Dude.
    - KirinDave 10y ago
      > the weak link is reduced to my ability to aduit it (combined with everyone else who's auditing it as well and might publish their findings). And if the hardware itself has microcode that overrides your code? > but this is ridiculous. Do you really think that the Yubikey folks have backdoored my copy of gcc? Actually, I think the first and foremest threat would be, "Could someone insert a yubikey into a malicious device that changed its behavior such that it now leaks information and does not provide actual security." Because those kinds of attacks actually exist. Ultimately, what you're arguing for is the pleasure and moral superiority of being able to do that audit. Not only does that audit not give you many guarantees, but giving you the ability to do that audit opens you up to much more sinister attacks.