4 ms·

For what values of "full knowledge" - you bootstrapped your compiler and verify every line of source code you've downloaded. But then if you're up against natio

by cmdkeen 11y ago

For what values of "full knowledge" - you bootstrapped your compiler and verify every line of source code you've downloaded. But then if you're up against nation state actors they can probably force your source code source to be compromised for you and only you - so those "many eyes" are seeing different code. You are after all checking that other people have the same hashes for the download that you use... Then we're getting into compromised hardware, you verified that the chips actually are the same as the circuit diagrams after all. There is only so much tinfoil you can deploy. If an advanced nation state truly has you in its sights there isn't much you can do about it, and to be honest that's the way it should be. We sacrifice individual liberties for the advantages of being part of an organised society, and the limitation of coercive power to the state is a key part of that. A well regulated state in which the right people get targeted, with an acceptably low false positive rate that scales based on the degree of privacy violation of the targeting seems to be a perfectly sensible state of affairs. Apple's argument that they are being asked to do something that isn't justified fits just fine into that.

CaptSpify 11y ago
tl;dr: "it's hard to verify code. therefore, we shouldn't even try!"
- freehunter 11y ago
  Not hard. Impossible. Have you seen obfuscated C? Is it possible for enough people to read it and understand it that it would make a difference? What about if you can read it but I can't? Do I trust you? How many people have to verify it before a non-expert can trust it? Theoretically, none. Everyone could be in on the conspiracy except me. And how do I verify that the code I've just read is what shipped on my computer? If I install it myself, how do I verify the CD or ISO I have is what I read? If I compiled it myself, how do I verify the compiler didn't change anything? What about the system that compiled the code, do I trust that? How far back do I have to go before I have trusted everything? And then what about hardware? Is there a chip that changes some of the code that's running? Can I verify every piece of hardware in my system, a 16-core CPU with 64GB of RAM and a high-end video card? How do I even do that? And what are the odds I am a world class C coder and a world-class hardware expert? And then what about client code? Am I a world-class Javascript expert too, with full source access to the Django backend? And the system that is running that server code, do I have access to that hardware to make sure it's not going to compromise my security? No. Fully trusting a computer is impossible. It doesn't mean we shouldn't try, we should at least make it as hard as possible for the bad guys to trick us. But what's better, IMO, is to create an environment where it's detrimental to companies to trick their users like that. Apple seems to have gotten a lot of great press for standing up in this situation. There's a market for it. Can you trust Apple tech? Maybe not. But can you trust it more than Google or Microsoft or Samsung or Facebook or Amazon etc etc? It does seem that way. Without being a world-class expert in everything, eventually you have to trust someone.
  - CaptSpify 11y ago
    > No. Fully trusting a computer is impossible. It doesn't mean we shouldn't try, we should at least make it as hard as possible for the bad guys to trick us. I completely agree. I liken it to something like world-peace: It's an ideal, and we'll probably never get there. Doesn't mean we shouldn't try to get there though.
    - mentat 11y ago
      We still need to have a realistic idea of what's possible though and not make claims that are stronger than what's likely.
  - cyphar 11y ago
    Sure, you can't be 100% sure of anything. In the same vein, you can't even be sure that the world is real. The fact you can't have 100% assurances doesn't mean anything. What matters is how strong you make your assurances. A company having an existing system allowing for the installation of backdoored firmware is an example of something that shouldn't be possible. It should be possible to reasonably assure that someone cannot flash something onto a person's phone without either wiping the data or having the update signed by the user.
- Joeri 11y ago
  A modern software stack involves in excess of 500 million lines of code. One can properly audit no more than 5000 lines of code per day. The math dictates that trust will be a given.
  - CaptSpify 11y ago
    I agree. It's an unfortunate inevitability. Doesn't mean we shouldn't try. We shoud be able to verify any subsection of it as well, whenever we need to.
delroth 11y ago
Just because you can never get full coverage doesn't mean it has to be easy. For example, here are some things that could be imlpemented to make firmware backdooring harder: * Certificate Transparency-style public ledger for all firmwares that Apple has signed. Refuse an update if the firmware version has not been published to the ledger. This would make these backdooring attempts public, since we can assume people would watch the ledger and ask questions in case of an unknown version being published. * For open source firmwares, reproducible builds are a great tool to make sure the distributed binaries actually match the publicly reviewable source code. Third parties could recompile the firmware and attest (through signing) that they get the same result. I don't know any implementation of either of these two systems, at least publicly available (hint: Bazel does reproducible builds, and you can guess what is driving this requierment). Debian and Mozilla are experimenting with reproducible builds but I don't know that it ever reached any useful conclusion.
- koolba 11y ago
  > Certificate Transparency-style public ledger for all firmwares that Apple has signed. Refuse an update if the firmware version has not been published to the ledger. This would make these backdooring attempts public, since we can assume people would watch the ledger and ask questions in case of an unknown version being published. That's seems like a fantastic idea but without open source firmware I don't see how it could be enforced.
- pdpi 11y ago
  E.g. Bitcoin has reproducible builds in the wild. https://github.com/bitcoin/gitian.sigs https://github.com/bitcoin/gitian.sigs
  - nadaviv 11y ago
    Reproducible builds, and a release process that incorporates digital signatures from multiple members of the Bitcoin development community.
EdHominem 11y ago
That stuff (checking hashes, etc) is currently mostly theatre because, as you say, a nation-state can easily serve you different hashes to check. But it's pretty easy to imagine a feature where, similar to cert-pinning, many clients report the hashes that they see on the website and if you see something different from what everyone else does, you know something is wrong. It wouldn't need to be a "techie" feature - it would simply show a package as broken and refuse to install if it wasn't verifying, etc. And the goal isn't some impossible 100% security, the goal is enough security to end mass interception and make the government rely on warrants and targeted tactics again.
- darkr 11y ago
  > That stuff (checking hashes, etc) is currently mostly theatre because, as you say, a nation-state can easily serve you different hashes to check. This is why as well as serving those hashes over HTTPS, you sign the hashes with a key, the public part of which is distributed/retrievable/verifiable via some other means.
  - EdHominem 11y ago
    Right. But if I were attacking you and was in your site and knew that you signed your hashes I'd be targeting your build script to save your key and passphrase, or build a backdoored version at the same time. Something like Certificate Transparency for code-signing would be really solid though; tampering would stand out. https://www.certificate-transparency.org/log-proofs-work https://www.certificate-transparency.org/log-proofs-work I think there's value in the purely user-based solution though. If two people go to a site at the same time and aren't served the same binary they should be curious why, even if the company securely and auditably signed both images. And, it helps in all the cases when companies don't implement great release-security.

by cmdkeen 11y ago

CaptSpify 11y ago

tl;dr: "it's hard to verify code. therefore, we shouldn't even try!"

freehunter 11y ago
Not hard. Impossible. Have you seen obfuscated C? Is it possible for enough people to read it and understand it that it would make a difference? What about if you can read it but I can't? Do I trust you? How many people have to verify it before a non-expert can trust it? Theoretically, none. Everyone could be in on the conspiracy except me. And how do I verify that the code I've just read is what shipped on my computer? If I install it myself, how do I verify the CD or ISO I have is what I read? If I compiled it myself, how do I verify the compiler didn't change anything? What about the system that compiled the code, do I trust that? How far back do I have to go before I have trusted everything? And then what about hardware? Is there a chip that changes some of the code that's running? Can I verify every piece of hardware in my system, a 16-core CPU with 64GB of RAM and a high-end video card? How do I even do that? And what are the odds I am a world class C coder and a world-class hardware expert? And then what about client code? Am I a world-class Javascript expert too, with full source access to the Django backend? And the system that is running that server code, do I have access to that hardware to make sure it's not going to compromise my security? No. Fully trusting a computer is impossible. It doesn't mean we shouldn't try, we should at least make it as hard as possible for the bad guys to trick us. But what's better, IMO, is to create an environment where it's detrimental to companies to trick their users like that. Apple seems to have gotten a lot of great press for standing up in this situation. There's a market for it. Can you trust Apple tech? Maybe not. But can you trust it more than Google or Microsoft or Samsung or Facebook or Amazon etc etc? It does seem that way. Without being a world-class expert in everything, eventually you have to trust someone.
- CaptSpify 11y ago
  > No. Fully trusting a computer is impossible. It doesn't mean we shouldn't try, we should at least make it as hard as possible for the bad guys to trick us. I completely agree. I liken it to something like world-peace: It's an ideal, and we'll probably never get there. Doesn't mean we shouldn't try to get there though.
  - mentat 11y ago
    We still need to have a realistic idea of what's possible though and not make claims that are stronger than what's likely.
- cyphar 11y ago
  Sure, you can't be 100% sure of anything. In the same vein, you can't even be sure that the world is real. The fact you can't have 100% assurances doesn't mean anything. What matters is how strong you make your assurances. A company having an existing system allowing for the installation of backdoored firmware is an example of something that shouldn't be possible. It should be possible to reasonably assure that someone cannot flash something onto a person's phone without either wiping the data or having the update signed by the user.
Joeri 11y ago
A modern software stack involves in excess of 500 million lines of code. One can properly audit no more than 5000 lines of code per day. The math dictates that trust will be a given.
- CaptSpify 11y ago
  I agree. It's an unfortunate inevitability. Doesn't mean we shouldn't try. We shoud be able to verify any subsection of it as well, whenever we need to.

delroth 11y ago

Just because you can never get full coverage doesn't mean it has to be easy. For example, here are some things that could be imlpemented to make firmware backdooring harder: * Certificate Transparency-style public ledger for all firmwares that Apple has signed. Refuse an update if the firmware version has not been published to the ledger. This would make these backdooring attempts public, since we can assume people would watch the ledger and ask questions in case of an unknown version being published. * For open source firmwares, reproducible builds are a great tool to make sure the distributed binaries actually match the publicly reviewable source code. Third parties could recompile the firmware and attest (through signing) that they get the same result. I don't know any implementation of either of these two systems, at least publicly available (hint: Bazel does reproducible builds, and you can guess what is driving this requierment). Debian and Mozilla are experimenting with reproducible builds but I don't know that it ever reached any useful conclusion.

koolba 11y ago
> Certificate Transparency-style public ledger for all firmwares that Apple has signed. Refuse an update if the firmware version has not been published to the ledger. This would make these backdooring attempts public, since we can assume people would watch the ledger and ask questions in case of an unknown version being published. That's seems like a fantastic idea but without open source firmware I don't see how it could be enforced.
pdpi 11y ago
E.g. Bitcoin has reproducible builds in the wild. https://github.com/bitcoin/gitian.sigs https://github.com/bitcoin/gitian.sigs
- nadaviv 11y ago
  Reproducible builds, and a release process that incorporates digital signatures from multiple members of the Bitcoin development community.

EdHominem 11y ago

That stuff (checking hashes, etc) is currently mostly theatre because, as you say, a nation-state can easily serve you different hashes to check. But it's pretty easy to imagine a feature where, similar to cert-pinning, many clients report the hashes that they see on the website and if you see something different from what everyone else does, you know something is wrong. It wouldn't need to be a "techie" feature - it would simply show a package as broken and refuse to install if it wasn't verifying, etc. And the goal isn't some impossible 100% security, the goal is enough security to end mass interception and make the government rely on warrants and targeted tactics again.

darkr 11y ago
> That stuff (checking hashes, etc) is currently mostly theatre because, as you say, a nation-state can easily serve you different hashes to check. This is why as well as serving those hashes over HTTPS, you sign the hashes with a key, the public part of which is distributed/retrievable/verifiable via some other means.
- EdHominem 11y ago
  Right. But if I were attacking you and was in your site and knew that you signed your hashes I'd be targeting your build script to save your key and passphrase, or build a backdoored version at the same time. Something like Certificate Transparency for code-signing would be really solid though; tampering would stand out. https://www.certificate-transparency.org/log-proofs-work https://www.certificate-transparency.org/log-proofs-work I think there's value in the purely user-based solution though. If two people go to a site at the same time and aren't served the same binary they should be curious why, even if the company securely and auditably signed both images. And, it helps in all the cases when companies don't implement great release-security.