[Cryptography] Data in Use

[Phillip Hallam-Baker]

On Fri, Aug 5, 2022 at 2:22 PM Natanael <natanael.l at gmail.com> wrote:

>
>
> Den fre 5 aug. 2022 08:51Andrea Pasquinucci <liste at ucci.it> skrev:
>
>>
>> Sorry but to me "Data in use" is an old (but still critical) concept,
>> unless you are discussing something different.
>>
>> Please have a look for example at
>>
>> https://confidentialcomputing.io/
>>
>> whose title is
>>
>>   The Confidential Computing Consortium is a community focused on
>> projects securing data in use and accelerating the adoption of confidential
>> computing through open collaboration.
>>
>> Or are you referring to something else?
>>
>
> There's additional approaches.
>
> 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.
>
> Formal verification is another approach, and some use code synthetization
> from a spec.
>

That is exactly what I described in my thesis. But I am not seeing formal
methods as being relevant to Data in Use.

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.

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.

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.

Merely encrypting the database fields isn't sufficient if the Web Service
has access to the decryption key.


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.

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'.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20220805/caea4f93/attachment.htm>