Researching for proposals: trust and proactively-secure filesystems

[Chris]

On Thu, 28 May 2020 08:38:03 -0400 Eric McCorkle eric at metricspace.net said

> Hello,
> 
> I'm gathering information for some proposals I'm working on that build
> on the public-key trust system idea I proposed back in 2018 (which I
> haven't been able to work on since, unfortunately).  I'm interested in
> any feedback about feasibility.
> 
> (Assume there are sponsors and users interested in any features or
> applications I describe, because there are.)
> 
> A bit of recap, the public-key trust system would provide a kernel-level
> trust store which could serve as a system-wide root of trust, and would
> be designed such that you could configure applications to use a kernel
> device file as their CA certificate.  The kernel would maintain a set of
> trusted certificates, which could be established and revoked through
> another device file interface.
> 
> In the original work, I just had the trust store maintain a list of
> certificates with no private keys.  This could be added, though.  I
> suggested this as future work, and pointed out that you could do some
> interesting things like remote capability delegations.
> 
> 
> The first concept is fairly straightforward: tie the public-key trust
> system together with a hardware TPM.  This would limit the cipher
> selection to what TPMs support (no curve 25519), but seems otherwise
> feasible to me.  The "trust" device interface I described in my initial
> work was essentially a software-emulated TPM in the kernel anyway.
> 
> How would this differ from a plain TPM device?  Not terribly.  The real
> point of the trust system is to be an abstraction for what the system
> does and does not trust.  So the command interface would look more like
> "create an attestation at this trust level", versus "sign with this
> particular key".  In keeping with my original work, the goal is that the
> kernel could issue non-forgeable authorization materials that could be
> exported from the system and checked for validity later.
> 
> 
> The second concept deals with filesystems, and particular ZFS (yes, I am
> aware of existing ZFS encryption work).  ZFS is particularly interesting
> because of its write-once structure.  This potentially lets you use
> ciphers/MACs with "one-shot" keys, such as chacha20/poly1305.  It *also*
> potentially lets you use distinct keys for each individual file.
> 
> That capability could allow you to grant fine-grained access to sets of
> files.  The use case here is that you can have different "access levels"
> within an individual filesystem that can be turned on and off.  (You can
> accomplish this with FDE, but it's fairly awkward.)
> 
> If you tweak the virtual memory/filesystem interface a bit to load data
> from the filesystem while still encrypted and decrypt it only on demand,
> you can do away with the notion of turning access levels on at the
> system-wide level.  Here, each individual user either does or does not
> have the right keys to access the data.  (There's some interesting
> possibilities here with secret-sharing: you could, for example, have
> data that requires a specific *set* of authorizations to decrypt)
> 
> There is, of course, a possibility that an adversary could take
> advantage of a kernel data leak in all these mechanisms.  However, there
> is a smaller window in which that is possible.
> 
> The theme in all of this is that you're essentially mediating access
> through possession of keys as opposed to kernel access control (hence
> the term "proactively secure")
> 
> 
> Additionally, there's a possible scheme where you essentially view a
> file as a one-way encrypted channel.  You could generate two key-pairs,
> create the session key, then destroy one side's public key and the other
> side's private key.  The material that gets saved to disk is the public
> key and data encrypted with the session key.  The other private key
> serves as an access token.  I personally can't think of an advantage of
> this scheme over just saving a portion of a secret-shared symmetric key
> to the disk, but that doesn't mean there isn't one.
I think it's a wonderful concept. +1 on that.
How much overhead do you suppose this might impose?
Would your concept permit the ability to simply insert say a USB device
(stick) with the required material, and be done with it? IOW require no
additional effort/action(s) on the administrators part?

Thanks for taking something like this on! I think it's a great idea.

--Chris