4 ms·

This discussion is not very interesting from a security perspective. I tuned out at “cloud”. If it’s not in your physical possession, it’s not your computer.

by efitz 5y ago

This discussion is not very interesting from a security perspective. I tuned out at “cloud”. If it’s not in your physical possession, it’s not your computer. If it’s not your computer, then whoever administers the computer, or whoever [points a gun at/gives enough money to] the administrator of that system can access whatever you put on that system. If a “cloud” or “service” is involved, then you can trivially use them to move or store data that you encrypted locally on your computer with your key that was generated and stored locally and never left your system. But subject to the limits above, the administrators of the other computers will still be able to see metadata like where the data came from and is going to. And they might be able to see your data too if you ever (even once, ask Ross Ulbrecht) failed to follow the basic encryption guidelines above. You can make metadata access harder via VPNs and Tor, but you CANNOT make it impossible- in the worst case, maybe your adversary is controlling all the Tor nodes and has compromised the software. Which leads me to my last point, if you did not write (or at least read) the code that you’re using to do all of the above, then you’re at the mercy of whoever wrote it. And, if you try to follow perfect operational security, you will have a stressful and unpleasant life, as it’s really really hard.

judge2020 5y ago
If i'm reading this page correctly, AMD is working on something that would allow you to run trusted code that not even someone with physical access to the hardware could read (without breaking this system). https://www.amd.com/en/processors/epyc-confidential-computing-cloud https://www.amd.com/en/processors/epyc-confidential-computin... And this tech is already implemented by GCP: https://cloud.google.com/confidential-computing https://cloud.google.com/confidential-computing > With the confidential execution environments provided by Confidential VM and AMD SEV, Google Cloud keeps customers' sensitive code and other data encrypted in memory during processing. Google does not have access to the encryption keys. In addition, Confidential VM can help alleviate concerns about risk related to either dependency on Google infrastructure or Google insiders' access to customer data in the clear.
- efitz 5y ago
  Then you only have to trust that AMD did not accidentally or intentionally introduce a bug in the system. Remember Spectre? Remember all the security bugs in the Intel management code? You also have to trust that AMD generated and have always managed the encryption keys for that system properly and in accordance with their documentation. And are you even sure that you’re actually running on an AMD system? If the system is in the cloud, then it’s hard to be sure what is executing your code. And are you sure that your code didn’t accidentally break the security guarantees of the underlying system? I have worked on all these problems in my day job, working on HSMs. At the end of the day there are still some leaps of faith.
  - smoldesu 5y ago
    puts on tinfoil hat You'd also need to consider AMD's management engine, the Platform Security Processor. If we're really slinging conspiracy theories, AMD processors are likely just as backdoored as Intel one. I don't mean to be grim, but I think it's safe to assume that the US government has direct memory access to the vast majority of computer processors you can buy these days. [/conspiracy]
    - 123pie123 5y ago
      if you're going to that level, then have a look at five-eyes (and it's derivatives) https://en.wikipedia.org/wiki/Five_Eyes https://en.wikipedia.org/wiki/Five_Eyes / Echelon
      - smoldesu 5y ago
        I probably shouldn't have removed my tinfoil lining yet but yes, you're correct. Any information the US government has access to through these channels is also probably accessible by our surveillance/intelligence allies. It raises a lot of questions about how deep the rabbit hole goes, but I won't elucidate them here since I've been threatened with bans for doing so. I guess it's a do-your-own research situation, but always carry a healthy degree of skepticism when you read about anything government-adjacent.
michaelmior 5y ago
> if you did not write (or at least read) the code that you’re using to do all of the above, then you’re at the mercy of whoever wrote it. It's worse than that. Even if you read the code, you have to trust that the code you read is the code a service is actually using. Even if you deploy the code yourself, you have to trust that the infrastructure you're running on does not have some type of backdoor. Even if you run your own infrastructure, hardware can still have backdoors. Of course, the likelihood of any of these things actually becoming a problem decreases significantly as you read through the paragraph.
- inetknght 5y ago
  > the likelihood of any of these things actually becoming a problem decreases significantly as you read through the paragraph. And yet, "likelihood" doesn't necessarily mean "hasn't been done". Just look at: * [0]: Intel ME * [1]: Solarwinds attack and CI systems * [2]: Ubiquiti attack and complete infrastructure compromise * [3]: And the famous Ken Thompson statement [0a]: https://news.ycombinator.com/item?id=15298833 https://news.ycombinator.com/item?id=15298833 [0b]: https://www.blackhat.com/eu-17/briefings/schedule/#how-to-hack-a-turned-off-computer-or-running-unsigned-code-in-intel-management-engine-8668 https://www.blackhat.com/eu-17/briefings/schedule/#how-to-ha... [1]: https://www.cisecurity.org/solarwinds/ https://www.cisecurity.org/solarwinds/ [2]: https://krebsonsecurity.com/2021/04/ubiquiti-all-but-confirms-breach-response-iniquity/ https://krebsonsecurity.com/2021/04/ubiquiti-all-but-confirm... [3]: https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-tho...
  - michaelmior 5y ago
    Indeed. I mentioned those specific things because it has been done. However, I think the likelihood of the average user being affected by things near the end of the list is generally quite small. If we aren't willing to accept this, at some point, we can't use technology for anything important.
- dointheatl 5y ago
  > Even if you read the code, you have to trust that the code you read is the code a service is actually using. Don't forget to verify the code for the compiler to ensure that hasn't been compromised in order to inject an exploit into the binary at compile time.

by efitz 5y ago

judge2020 5y ago

If i'm reading this page correctly, AMD is working on something that would allow you to run trusted code that not even someone with physical access to the hardware could read (without breaking this system). https://www.amd.com/en/processors/epyc-confidential-computing-cloud https://www.amd.com/en/processors/epyc-confidential-computin... And this tech is already implemented by GCP: https://cloud.google.com/confidential-computing https://cloud.google.com/confidential-computing > With the confidential execution environments provided by Confidential VM and AMD SEV, Google Cloud keeps customers' sensitive code and other data encrypted in memory during processing. Google does not have access to the encryption keys. In addition, Confidential VM can help alleviate concerns about risk related to either dependency on Google infrastructure or Google insiders' access to customer data in the clear.

efitz 5y ago
Then you only have to trust that AMD did not accidentally or intentionally introduce a bug in the system. Remember Spectre? Remember all the security bugs in the Intel management code? You also have to trust that AMD generated and have always managed the encryption keys for that system properly and in accordance with their documentation. And are you even sure that you’re actually running on an AMD system? If the system is in the cloud, then it’s hard to be sure what is executing your code. And are you sure that your code didn’t accidentally break the security guarantees of the underlying system? I have worked on all these problems in my day job, working on HSMs. At the end of the day there are still some leaps of faith.
- smoldesu 5y ago
  puts on tinfoil hat You'd also need to consider AMD's management engine, the Platform Security Processor. If we're really slinging conspiracy theories, AMD processors are likely just as backdoored as Intel one. I don't mean to be grim, but I think it's safe to assume that the US government has direct memory access to the vast majority of computer processors you can buy these days. [/conspiracy]
  - 123pie123 5y ago
    if you're going to that level, then have a look at five-eyes (and it's derivatives) https://en.wikipedia.org/wiki/Five_Eyes https://en.wikipedia.org/wiki/Five_Eyes / Echelon
    - smoldesu 5y ago
      I probably shouldn't have removed my tinfoil lining yet but yes, you're correct. Any information the US government has access to through these channels is also probably accessible by our surveillance/intelligence allies. It raises a lot of questions about how deep the rabbit hole goes, but I won't elucidate them here since I've been threatened with bans for doing so. I guess it's a do-your-own research situation, but always carry a healthy degree of skepticism when you read about anything government-adjacent.

michaelmior 5y ago

> if you did not write (or at least read) the code that you’re using to do all of the above, then you’re at the mercy of whoever wrote it. It's worse than that. Even if you read the code, you have to trust that the code you read is the code a service is actually using. Even if you deploy the code yourself, you have to trust that the infrastructure you're running on does not have some type of backdoor. Even if you run your own infrastructure, hardware can still have backdoors. Of course, the likelihood of any of these things actually becoming a problem decreases significantly as you read through the paragraph.

inetknght 5y ago
> the likelihood of any of these things actually becoming a problem decreases significantly as you read through the paragraph. And yet, "likelihood" doesn't necessarily mean "hasn't been done". Just look at: * [0]: Intel ME * [1]: Solarwinds attack and CI systems * [2]: Ubiquiti attack and complete infrastructure compromise * [3]: And the famous Ken Thompson statement [0a]: https://news.ycombinator.com/item?id=15298833 https://news.ycombinator.com/item?id=15298833 [0b]: https://www.blackhat.com/eu-17/briefings/schedule/#how-to-hack-a-turned-off-computer-or-running-unsigned-code-in-intel-management-engine-8668 https://www.blackhat.com/eu-17/briefings/schedule/#how-to-ha... [1]: https://www.cisecurity.org/solarwinds/ https://www.cisecurity.org/solarwinds/ [2]: https://krebsonsecurity.com/2021/04/ubiquiti-all-but-confirms-breach-response-iniquity/ https://krebsonsecurity.com/2021/04/ubiquiti-all-but-confirm... [3]: https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-tho...
- michaelmior 5y ago
  Indeed. I mentioned those specific things because it has been done. However, I think the likelihood of the average user being affected by things near the end of the list is generally quite small. If we aren't willing to accept this, at some point, we can't use technology for anything important.
dointheatl 5y ago
> Even if you read the code, you have to trust that the code you read is the code a service is actually using. Don't forget to verify the code for the compiler to ensure that hasn't been compromised in order to inject an exploit into the binary at compile time.