Skip site navigation (1)Skip section navigation (2)
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>