mTLS passphrase use.

[lukehinds]

We currently use a passphrase for the client side encrypted private key for mTLS and the phrase is gathered by the tenant code using ConfigParser.

I question what extra security this really brings. If someone with ill intention gains access to the system sufficient to steal the client certs, its trivial for them to open keylime.conf and grab the passphrase which is stored as plain text.

This is not to say its less secure than no passphrase, but its akin to buying a very expensive tungsten lock and leaving the key under the door mat.

Client side security will be bolstered once JWT is implemented and we will then be 'belt and braces' with both mTLS and tokens combined. With that in mind I wonder if we should drop support for the passphrase as it adds little value in it's current implementation and will only lead to a factor that will be reported on as insecure in any threat analysis / pen tests that occur.

[lukehinds]

@jetwhiz / @nabilschear any thoughts?

[jetwhiz]

@lukehinds I agree that a more mature access management (done correctly) can be a much better way to handle this than hard-coding a password in the configuration file. I'm inclined to leave this in until we have that set up, though, since full compromise of the verifier or tenant is outside the threat model of Keylime. There would likely be much more severe and profound consequences to a full verifier compromise, for instance, than someone just getting access to these keys, though I defer to @nabilschear to see his take.

[lukehinds]

hey @jetwhiz

I am having some trouble trying to create a client-private.pem with no passphrase. From what I can see the pw is set here globalcb

keylime/keylime/ca_util.py

Lines 118 to 122 in 610565d

	# write out the private key with password
	with os.fdopen(os.open("%s-private.pem"%name,os.O_WRONLY | os.O_CREAT,0o600), 'wb') as f:
	biofile = BIO.File(f)
	pk.save_key_bio(biofile, 'aes_256_cbc', globalcb)
	biofile.close()

Looking at save_bio_key in M2Cyrpto it requires the passphrase as a callback (you cannot pass over '' or None etc).

https://fossies.org/dox/m2crypto-0.30.1/classM2Crypto_1_1EC_1_1EC.html#a09e1f2f3dc4966624b7a27d684f3874e

The only way I can see of doing this is removing it afterwards (which is a less than ideal solution).

Any ideas, is this perhaps set earlier somewhere in the verifiers private key?

Reason for doing this is we need to move to using python requests as it handles sessions better (for auth / jwt), but requests won't work with a passphrase. psf/requests#1573

[lukehinds]

update:

    # write out the private key with password
    with os.fdopen(os.open("%s-private.pem"%name,os.O_WRONLY | os.O_CREAT,0o600), 'wb') as f:
        biofile = BIO.File(f)
        pk.save_key_bio(biofile, None)
        biofile.close()

See any complications with that @jetwhiz @nabilschear , it works fine (I no longer need a passphrase in the tenant)?

[jetwhiz]

I think that should do what you're looking for, but we should be careful about where we store those unprotected private keys (granted the password was stored in /etc/ before anyways, as you point out).
Is there any way psf can take the raw private key via a variable instead of from a file, so we never need to write keys out in the first place (though this would require more changes to keylime to accommodate)?

[lukehinds]

I think that should do what you're looking for, but we should be careful about where we store those unprotected private keys (granted the password was stored in /etc/ before anyways, as you point out).

So I think we can iron this out in documentation and guidance. We would remind users they should be mindful of protecting these assets, so for example 'tls_dir' be on a HSM or the like.

Is there any way psf can take the raw private key via a variable instead of from a file, so we never need to write keys out in the first place (though this would require more changes to keylime to accommodate)?

I don't know of anyway, but open to considering options.

As it stands now we will have this as our posture.

1. We no longer have a passphrase to protect the keys.
2. We now however require all sessions be authenticated.

I think this should equate when factored together as being slightly more secure than before.

[nabilschear]

hi, all those stupid passwords are my fault =) the problem is bootstrapping. At the end of the day, the keys have to live unprotected somewhere (either encrypted with the password stored elsewhere on the disk (protected with fs permissions), or just stored unprotected with FS protections. By using the password, we make the private keys a little more portable, but i agree the benefit is incremental at best. Note that ca_util does have the --insecure option which will generate unprotected private keys for cert packages.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 7 days if no further activity occurs. Thank you for your contributions.