Date: Thu, 28 May 2020 10:07:46 -0700 From: Chris <bsd-lists@BSDforge.com> To: Eric McCorkle <eric@metricspace.net> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Researching for proposals: trust and proactively-secure filesystems Message-ID: <c3ace90a4c79b9f3f76709114deced87@udns.ultimatedns.net> In-Reply-To: <daf1df33-6a39-2987-27f8-1d120d82547d@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 28 May 2020 08:38:03 -0400 Eric McCorkle eric@metricspace=2Enet said > Hello, >=20 > 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)=2E I'm interested in > any feedback about feasibility=2E >=20 > (Assume there are sponsors and users interested in any features or > applications I describe, because there are=2E) >=20 > 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=2E The kernel would maintain a set of > trusted certificates, which could be established and revoked through > another device file interface=2E >=20 > In the original work, I just had the trust store maintain a list of > certificates with no private keys=2E This could be added, though=2E I > suggested this as future work, and pointed out that you could do some > interesting things like remote capability delegations=2E >=20 >=20 > The first concept is fairly straightforward: tie the public-key trust > system together with a hardware TPM=2E This would limit the cipher > selection to what TPMs support (no curve 25519), but seems otherwise > feasible to me=2E The "trust" device interface I described in my initial > work was essentially a software-emulated TPM in the kernel anyway=2E >=20 > How would this differ from a plain TPM device? Not terribly=2E The real > point of the trust system is to be an abstraction for what the system > does and does not trust=2E So the command interface would look more like > "create an attestation at this trust level", versus "sign with this > particular key"=2E 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=2E >=20 >=20 > The second concept deals with filesystems, and particular ZFS (yes, I am > aware of existing ZFS encryption work)=2E ZFS is particularly interesting > because of its write-once structure=2E This potentially lets you use > ciphers/MACs with "one-shot" keys, such as chacha20/poly1305=2E It *also* > potentially lets you use distinct keys for each individual file=2E >=20 > That capability could allow you to grant fine-grained access to sets of > files=2E The use case here is that you can have different "access levels" > within an individual filesystem that can be turned on and off=2E (You can > accomplish this with FDE, but it's fairly awkward=2E) >=20 > 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=2E Here, each individual user either does or does not > have the right keys to access the data=2E (There's some interesting > possibilities here with secret-sharing: you could, for example, have > data that requires a specific *set* of authorizations to decrypt) >=20 > There is, of course, a possibility that an adversary could take > advantage of a kernel data leak in all these mechanisms=2E However, there > is a smaller window in which that is possible=2E >=20 > 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") >=20 >=20 > Additionally, there's a possible scheme where you essentially view a > file as a one-way encrypted channel=2E You could generate two key-pairs, > create the session key, then destroy one side's public key and the other > side's private key=2E The material that gets saved to disk is the public > key and data encrypted with the session key=2E The other private key > serves as an access token=2E 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=2E I think it's a wonderful concept=2E +1 on that=2E 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=2E --Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c3ace90a4c79b9f3f76709114deced87>