[Cryptography] Data in Use

[Jerry Leichter]

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20220804/598a0545/attachment.htm>