From owner-freebsd-hackers@freebsd.org Thu May 28 17:07:31 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2DEDA2F777C for ; Thu, 28 May 2020 17:07:31 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49XvJg09f8z3TqV for ; Thu, 28 May 2020 17:07:30 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 04SH7e9X077689 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 28 May 2020 10:07:46 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: "freebsd-hackers@freebsd.org" In-Reply-To: From: Chris Reply-To: bsd-lists@BSDforge.com To: Eric McCorkle Subject: Re: Researching for proposals: trust and proactively-secure filesystems Date: Thu, 28 May 2020 10:07:46 -0700 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 49XvJg09f8z3TqV X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 17:07:31 -0000 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