From owner-freebsd-hackers@freebsd.org Thu May 28 12:38:15 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 5A5EB2F15D1 for ; Thu, 28 May 2020 12:38:15 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 49XnKy2YmNz4YBV for ; Thu, 28 May 2020 12:38:14 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:becd] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:becd]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 902E5C16B for ; Thu, 28 May 2020 12:38:08 +0000 (UTC) To: "freebsd-hackers@freebsd.org" From: Eric McCorkle Subject: Researching for proposals: trust and proactively-secure filesystems Autocrypt: addr=eric@metricspace.net; prefer-encrypt=mutual; keydata= mDMEXonLJBYJKwYBBAHaRw8BAQdA4oHU11A8qtqD0EtRofyORHbGX1ZIT/mnk9eceKQx56q0 JEVyaWMgTWNDb3JrbGUgPGVyaWNAbWV0cmljc3BhY2UubmV0PoiZBBMWCABBAhsDBQsJCAcC BhUKCQgLAgQWAgMBAh4BAheAAhkBFiEEPfuJobsx0Me4pIwLPOOjZtwQVqwFAl6J2DIFCQHh QI4ACgkQPOOjZtwQVqzGAAEAu2D57t8P5L7aE1zQKLrJ4B56ki67sR+N/W1mvKnw26oBANEp vVLbA7zr9q7i9wT/xrAUEnc4jylTEKM4sm60q8gBuDgEXonLJBIKKwYBBAGXVQEFAQEHQCxw rRXlvDoXgDGv2WMrLy9UaJ4fNWXIdlaiiKZIH7lBAwEIB4h+BBgWCAAmAhsMFiEEPfuJobsx 0Me4pIwLPOOjZtwQVqwFAl6J2DoFCQHhQJYACgkQPOOjZtwQVqy4UwEAruwUbIQEmOGkyGmA 8Q7A/LGqCYE7vBzF1OnpcOuV1vYBANIVrBc7ikG6UelcNkUD1o3QCsp9y5U0/KS6Uc1LQ40E Message-ID: Date: Thu, 28 May 2020 08:38:03 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0eKj0QJTHrHYawjA1YSS8ppTu5zhG3quR" X-Rspamd-Queue-Id: 49XnKy2YmNz4YBV X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of eric@metricspace.net has no SPF policy when checking 2001:470:1f11:617::107) smtp.mailfrom=eric@metricspace.net X-Spamd-Result: default: False [-1.43 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.62)[-0.615]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; HAS_ATTACHMENT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(0.16)[0.157]; DMARC_NA(0.00)[metricspace.net]; NEURAL_SPAM_SHORT(0.13)[0.130]; TO_DN_EQ_ADDR_ALL(0.00)[]; SIGNED_PGP(-2.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] 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 12:38:15 -0000 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--