Date: Thu, 28 May 2020 08:38:03 -0400 From: Eric McCorkle <eric@metricspace.net> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Researching for proposals: trust and proactively-secure filesystems Message-ID: <daf1df33-6a39-2987-27f8-1d120d82547d@metricspace.net>
next in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0eKj0QJTHrHYawjA1YSS8ppTu5zhG3quR Content-Type: multipart/mixed; boundary="umDHIpLs1NT2RileS7urBip0D8H0RZ012" --umDHIpLs1NT2RileS7urBip0D8H0RZ012 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 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. --umDHIpLs1NT2RileS7urBip0D8H0RZ012-- --0eKj0QJTHrHYawjA1YSS8ppTu5zhG3quR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQ9+4mhuzHQx7ikjAs846Nm3BBWrAUCXs+wrwAKCRA846Nm3BBW rLMmAQC3cXoGk5MyF9ErYlIHThQeQ6VMheTMNo5U920y+umT2AEAlaDGbuMToCW5 ivylj5gkJGlONMqnJ76KnGUfi0UKXAU= =Tyhc -----END PGP SIGNATURE----- --0eKj0QJTHrHYawjA1YSS8ppTu5zhG3quR--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?daf1df33-6a39-2987-27f8-1d120d82547d>