The Inner Circle

 View Only
  • 1.  Confidential Computing

    Posted Apr 23, 2020 12:38:00 PM
    I was interviewed for an article about Confidential Computing at Dark Reading.  If you are not familiar with the topic, it is about using the Trusted Execution Environment in the computer hardware to protect very sensitive data and compute so that even the CSP cannot see what the tenant is doing.  The context was IBM's announcement.  Right now this is fairly nascent in cloud, it will be interesting to see how it develops.

    https://www.darkreading.com/cloud/ibm-cloud-data-shield-brings-confidential-computing-to-public-cloud/d/d-id/1337626

    ------------------------------
    Jim Reavis CCSK
    Cloud Security Alliance
    Bellingham WA
    ------------------------------


  • 2.  RE: Confidential Computing

    Posted Apr 24, 2020 02:06:00 PM
    Hi Jim. Always interesting to see reporting on topics that have any mention of encryption...such an easily misunderstood area of technology. Reporters misunderstand Confidential Computing all the time, and this one made the same mistake I've seen made nearly universally: stating that the data is being operated on in memory while encrypted. This is not how the Intel SGX model works, though it is understandable that journalists get this wrong. The author of the article states that the following: "In-memory encryption, another term for confidential computing, encrypts data in use to eliminate the possibility of exposure." This is incorrect. Data is not encrypted in use. The Intel SGX hardware leverages cryptography in the overall solution, but once data is brought into the enclave it must be decrypted in order to operate on the data. What the author should have included in the article was a statement that in the case of application code that was developed as a "shim" for your application - or, in the case of Fortanix, a 3rd party application - you must trust the application code instead of the cloud provider. In other words, either you must write (or re-write) all of your own application code to natively leverage SGX, or you must trust the code of the vendor that writes it. Of course in the case of code that is written by the CSP that is hosting the "Confidential Computing" environment you are still placing trust in the cloud provider that there is no "back door" in their code. There are schemes that will attempt to provide attestation for that 3rd party code (again, using cryptographic methods) but ultimately unless the customer owns all the code that is allowed to run (and handle data) in the enclave there will be a non-zero risk of data compromise.

    Years back I was interviewed for an article in CIO Magazine. It had to do with cloud providers' access to customer data. They got encryption details wrong, too. Nearly all reporting on this topic includes some kind of technical error, and obviously in this case you weren't asked about these dynamics and I agree with everything you were quoted as saying. I'm currently addressing this topic from one angle in the Cloud Key Management Working Group, but am thinking that the document doesn't cover anything on Intel SGX and key management challenges in that particular case...maybe we should. Your thoughts on this would be appreciated.

    ------------------------------
    Paul Rich
    ------------------------------



  • 3.  RE: Confidential Computing

    Posted Apr 26, 2020 12:45:00 PM
    Hi Paul,

    You are of course correct in that the enclave or Trusted Execution Environment within the hardware is operating on decrypted data.  I think it is a very difficult topic for a reporter to tackle without already being very knowledgeable about cryptography.  I have to admit that I struggle when I have a 15 minute interview about an arcane security topic and probably am sometimes guilty of oversimplifying a concept to get a larger message out there.  I think the Confidential Computing initiative is really interesting in shrinking the space where information is not encrypted and provides some fairly manageable threat vectors.  We shall see if has good cost of ownership, developer support, application agility, usability, standards, etc.

    ------------------------------
    Jim Reavis CCSK
    Cloud Security Alliance
    Bellingham WA
    ------------------------------



  • 4.  RE: Confidential Computing

    Posted Apr 25, 2020 11:48:00 PM
    Edited by Olivier Caleff Apr 25, 2020 11:49:13 PM

    Unfortunately The "Confidential Computing Consortium" portal (announced last August) didn't provide much details up to now apart from a FAQ and a list of projects.



    ------------------------------
    Olivier Caleff - CSA French Chapter - Chapter Leader - [email protected] - https://CloudSecurityAlliance.fr
    ------------------------------



  • 5.  RE: Confidential Computing

    Posted Apr 26, 2020 11:49:00 AM

    Bonjour Olivier!

    Thanks for the link, I wasn't aware of the Consortium. I am very pleased with the FAQ entry "What is Confidential Computing?": "Confidential Computing is the protection of data in use by performing computation in a hardware-based Trusted Execution Environment." Nothing about encryption there, and more notably nothing about performing computation on encrypted data.

    When I was still at Microsoft I did many public talks on encryption in cloud services (one was done via BrightTalks, the series hosted by CSA) and included some coverage of Microsoft efforts and messaging regarding Confidential Computing, and you can still find one or two of those talks online. At the time, I was working with the Confidential Computing team to determine the feasibility of adapting the model for use with Office 365 services. This quickly revealed the impossibility of making the model work for SaaS in any way that would accomplish the fundamental privacy goals of customers interested in the "promise" of SGX and Confidential Computing. Again, this does not mean that SGX/CoCo have no value. On the contrary, I believe there to be enormous potential, but to achieve the promise/goals for which CoCo was invented, one cannot allow an "intermediate" software vendor that writes the code that runs within the TEE or does I/O with the TEE without accepting some risk that the code does things that violate the privacy promise of CoCo. That removes SaaS from consideration. Even PaaS may prove impossible to fully "privatize", as I've tried to illustrate above with the Fortanix/IBM services. It seems reasonable that IaaS will deliver on the goals of CoCo, but do keep in mind that achieving the goal will also be dependent upon avoiding relevant software bugs in any application leveraging CoCo. My main point is this: do your scientific analysis on any claims made regarding "Confidential Computing" and SGX-based services and features. Don't accept any other "truth" - marketing claims will always outpace the scientific truth when computer/data security and privacy are concerned.



    ------------------------------
    Paul Rich
    Executive Director
    JPMorgan Chase & Co.
    ------------------------------