<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 5, 2022 at 2:22 PM Natanael <<a href="mailto:natanael.l@gmail.com">natanael.l@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den fre 5 aug. 2022 08:51Andrea Pasquinucci <<a href="mailto:liste@ucci.it" target="_blank">liste@ucci.it</a>> skrev:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Sorry but to me "Data in use" is an old (but still critical) concept, unless you are discussing something different.<br>
<br>
Please have a look for example at<br>
<br>
<a href="https://confidentialcomputing.io/" rel="noreferrer noreferrer" target="_blank">https://confidentialcomputing.io/</a><br>
<br>
whose title is <br>
<br>
  The Confidential Computing Consortium is a community focused on projects securing data in use and accelerating the adoption of confidential computing through open collaboration.<br>
<br>
Or are you referring to something else?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">There's additional approaches. </div><div dir="auto"><br></div><div dir="auto">The first that comes to mind is capability based systems, wherein the default level is system access for any piece of code is nothing at all. Access isn't even inherented from a parent process, it has to be explicitly delegated. I believe some schemes go so far as to encrypt the memory and link the encryption key access to capability tokens. </div><div dir="auto"><br></div><div dir="auto">Formal verification is another approach, and some use code synthetization from a spec. </div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">That is exactly what I described in my thesis. But I am not seeing formal methods as being relevant to Data in Use.</div><br></div><div><div class="gmail_default" style="font-size:small">Data in Use is really about privilege escalation in a situation where there is at least one active party that has access to the plaintext. Such as a database connected to the Internet via a Web Service.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The reason it is useful to distinguish in use from at rest is that our cryptographic toolkit only really works for data at rest or data in motion. So one way to provide security for the Web Service scenario is to minimize the 'in-use' data surface by converting as much as possible to data at rest.</div><br></div><div><div class="gmail_default" style="font-size:small">For example, a merchant payment system does not need to keep the credit card number in the online system. It can encrypt the card number under a public key provided by the payment gateway.</div><br></div><div><div class="gmail_default" style="font-size:small">Merely encrypting the database fields isn't sufficient if the Web Service has access to the decryption key.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">To fully engage a cryptographic control like the Mesh, we need to get to the situation where the client making the enquiry has an authenticated encryption key and a trusted path to ensure that only an authorized party gets the data. We could imagine making use of a trusted module to enforce this requirement as a single point of control.</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Again, these are not new ideas in themselves. But we are in a new situation. Until recently, we did not have a practical solution for either Data at Rest or Data in Use. Whether or not people decide to use the Mesh, it is at the very least a proof of existence for a practical solution to the document level data at rest case. So distinguishing these cases is useful now because we are distinguishing the part of the problem we can solve from the part where large parts of the map are still marked 'here be dragons'.</div></div></div>