gnome-keyring utilizing a tpm?

[Peter Moody-3]

Hey Kees,

In a conversation with a co-worker the other day, the idea came up of having gnome-keyring utilize the tpm on the increasing number of platforms which support them.  Is this a ridiculous idea? ie, is there some long-ago made design decision that keyrings MUST BE (rfc caps) exportable? IIRC, don't kwallet and gnome-keyring use the same crypto libraries (and thus, wouldn't kwallet benefit from something like this as well?)

Cheers,

peter

--
ubuntu-hardened mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-hardened

[Kees Cook-5]

Hi Peter,

On Tue, Apr 12, 2011 at 07:14:17PM -0700, Peter Moody wrote:
> In a conversation with a co-worker the other day, the idea came up of having
> gnome-keyring utilize the tpm on the increasing number of platforms which
> support them.  Is this a ridiculous idea? ie, is there some long-ago made
> design decision that keyrings MUST BE (rfc caps) exportable? IIRC, don't
> kwallet and gnome-keyring use the same crypto libraries (and thus, wouldn't
> kwallet benefit from something like this as well?)

I'm less familiar with kwallet, but speaking just to the gnome-keyring
idea, there is a desirable reason (for some people) to the exportability
of the keyring: sharing it between systems via UbuntuOne or a similar
cloud-storage system.

Ignoring that use-case for a moment, TPM would really only add some
additional level of protection to the gnome-keyring from offline
inspection. But since the keyring is already encrypted with the user's
login passphrase, it already has a certain level of offline inspection
protection. TPM would just add a "harder" passphrase.

(Additionally, to make the TPM secrets useful, you'd need end-to-end TPM
from the BIOS, bootloader, kernel, and package manager before it would be
particularly useful for providing secrets to decrypt the gnome keyring.)

Or perhaps I'm misunderstanding some feature of TPM. :)

-Kees

--
Kees Cook
Ubuntu Security Team

--
ubuntu-hardened mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-hardened

[Peter Moody-3]

On Wed, Apr 13, 2011 at 10:29 AM, Kees Cook <[hidden email]> wrote:

Hi Peter,

On Tue, Apr 12, 2011 at 07:14:17PM -0700, Peter Moody wrote:
> In a conversation with a co-worker the other day, the idea came up of having
> gnome-keyring utilize the tpm on the increasing number of platforms which
> support them.  Is this a ridiculous idea? ie, is there some long-ago made
> design decision that keyrings MUST BE (rfc caps) exportable? IIRC, don't
> kwallet and gnome-keyring use the same crypto libraries (and thus, wouldn't
> kwallet benefit from something like this as well?)

I'm less familiar with kwallet, but speaking just to the gnome-keyring
idea, there is a desirable reason (for some people) to the exportability
of the keyring: sharing it between systems via UbuntuOne or a similar
cloud-storage system.

Ignoring that use-case for a moment, TPM would really only add some
additional level of protection to the gnome-keyring from offline
inspection. But since the keyring is already encrypted with the user's
login passphrase, it already has a certain level of offline inspection
protection. TPM would just add a "harder" passphrase.

(Additionally, to make the TPM secrets useful, you'd need end-to-end TPM
from the BIOS, bootloader, kernel, and package manager before it would be
particularly useful for providing secrets to decrypt the gnome keyring.)

I'm no tcg expert, but think you're thinking of sealing secrets on the tpm and I'm just looking to be able to bind data. I think the former would require the full trusted boot while the latter does not.

Or perhaps I'm misunderstanding some feature of TPM. :)

-Kees

--
Kees Cook
Ubuntu Security Team

--
ubuntu-hardened mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-hardened

[Kees Cook-5]

On Wed, Apr 13, 2011 at 11:23:51AM -0700, Peter Moody wrote:
> I'm no tcg expert, but think you're thinking of sealing secrets on the tpm
> and I'm just looking to be able to bind data. I think the former would
> require the full trusted boot while the latter does not.

In this case, does it really have a benefit? Currently anything on the
D-Bus session bus can ask for a given clear-text password from the keyring.
Storing them in the TPM doesn't really make a difference in this case --
anything can still read the contents by just asking gnome-keyring for it.

-Kees

--
Kees Cook
Ubuntu Security Team

--
ubuntu-hardened mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-hardened

[Peter Moody-3]

On Wed, Apr 13, 2011 at 11:53 AM, Kees Cook <[hidden email]> wrote:

On Wed, Apr 13, 2011 at 11:23:51AM -0700, Peter Moody wrote:
> I'm no tcg expert, but think you're thinking of sealing secrets on the tpm
> and I'm just looking to be able to bind data. I think the former would
> require the full trusted boot while the latter does not.

In this case, does it really have a benefit? Currently anything on the
D-Bus session bus can ask for a given clear-text password from the keyring.
Storing them in the TPM doesn't really make a difference in this case --
anything can still read the contents by just asking gnome-keyring for it.

 

I think I got the binding/sealing backwards, but the point is that the tpm never actually releases the private key material (so it doesn't actually make sense for storing things like passwords).  

My somewhat fuzzy understanding of the operation of a tpm is that when you seal private keys or certificates "in" the tpm, they're stored on disk (location depends on the pkcs11 library used, I think. on my system data is stored in /var/lib/opencryptoki/tpm/${USER}/) encrypted with the the tpm endorsement key. when you later want to use one of the keys for authentication (eg in a challenge-response auth scheme), you load the encrypted key into the tpm along with the challenge provided by the server, the tpm then decrypts the key, generates the response and hands that back to you. The private key material is never in system ram and can never actually be retrieved, but it can be used to authenticate a user.

Anyway, this seemed like it could be beneficial security-wise for ssh keys or 802.1x certificates (I know network manager supports accessing keys stored in a tpm).  Those are definitely enterprise wins, though I admit that they're of dubious personal use.

Cheers,

peter

-Kees

--
Kees Cook
Ubuntu Security Team

--
ubuntu-hardened mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-hardened