[Cryptography] Data in Use

[Jan Dušátko]

Dne 5. 8. 2022 v 1:26 Jerry Leichter napsal(a):
>> So I got into a Twitter argument with Kenn White about the value of 'Data at Rest' security and I think I came up with a more general insight. In short, the traditional Data-in-Motion / Data-at-Rest diad is insufficiently descriptive. What we really have is a triad:
>>
>> Data at Rest
>> Data in Use
>> Data in Motion
>>
>> This gives us the acronym 'RUM'.
>>
>> The reason for making the distinction is that if you have a Web application or a database actively reading and modifying your data, it is really not 'at rest' in any useful sense. It is something different that is going to require us to take a very different approach.
> This third class is implicit in every system that uses encrypted data.  I don't think I've ever seen it called out in exactly this form.
>
> There are plenty of techniques that amount to "ways to keep data in use" secure.  I can think of at least two broad catagories:
>
> - Limit the data exposed to that actually needed for a particular use.  For example, there are all kinds of techniques that provide ways to give a program an encrypted database record but only allow it to decrypt parts of the record.  Of course the simplest is to have different keys for each field - but one can do better.  You could argue that mechanisms to allow access only to aggregated data while denying access to individual data fall into this category (though unfortunately they can't actually work well, as we know).  The way Google protects gMail mailboxes (or did, a decade ago) is an interesting example:  Every mailbox has its own encryption key, and when a user logs in to his email account, he's assigned a machine at random, his authentication information goes to that machine, and the machine can then use that to ask a key server for his key.  So even if you manage to take over a machine, you can only get at some random collection of mailboxes that that machine is handling right now - you can't get to a chosen mailbox.  Homomorphic encryption is, in a way, the ultimate endpoint of this approach.
>
> - Limit the scope of the environment that has access to the decrypted data.  I'm thinking of various techniques around "sealed" virtual machines, where data in memory is decrypted only when the VM is running - even the OS sees the data as encrypted when it gains control (because a hypervisor intercedes to encrypt it before letting the OS run).  In the extreme, you can look at encryption in the hardware path, where the data is decrypted only when it's inside the guts of the CPU.  Actually, I believe Apple implements this for its Secure Enclave and T2 chips.
>                                                          -- Jerry
>
>
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> https://www.metzdowd.com/mailman/listinfo/cryptography

Jerry, Phillip,
Beside RUM are amazing acronym, I not sure if reasons described are correct.
For data at the rest I prefer to use object encryption. Doesn't matter, 
if that object are on the disk or in memory. The main disadvantage of 
object encryption are problem with the protection. Because does not 
support ephemeral keys (may there could be technique which I do not 
know), can protect confidentiality of data, but cannot protect 
confidentiality of data about subject.
Opposite of that, data in motion (transport) can use ephemeral keys and 
protect not only confidentiality of data, but also confidentiality of 
data about subject. I'm a little bit sceptical about current way of use 
encryption of channel like HTTP/2 and HTTP/3, where thanks to the 
channel encryption we slowly move to the object encryption.
Idea of data in the use are quite good, but I think half of that belong 
to MCP (Multiparty Computation) and to the anonymization techniques, 
second half to symmetric, asymmetric. Not sure if I'm true, but I use 
MCP term to cover homomorphic encryption, differential privacy, private 
set intersection, zero knowledge protocols. The anonymization technique 
use part of that technologies and "classic" attitude like data 
aggregation, generalization, masking, perturbation, pseudonymization, 
randomization, redacting, suppression, synthetize, tokenization and also 
homomorphic encryption and zero knowledge protocols. Also, because 
hardware support for security enclaves, there are CPU protection and 
encryption (beside of their weakness). This mean, that data in the use 
can be hardly described and too complex. Because of that, I prefer to 
separate anonymization techniques, which seat on top of RM diade/RUM 
triade. And without anonymization, we stay on the object encryption. I 
think we need to define it better for case of use this nice acronym.

Regards

Jan

-- 
-- --- ----- -
Jan Dušátko

Tracker number:	+420 602 427 840
e-mail:		jan at dusatko.org
GPG Signature:	https://keys.dusatko.org/E535B585.asc
GPG Encrypt:	https://keys.dusatko.org/B76A1587.asc