CA key and signing key are not really password protected
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
High
|
John Dennis |
Bug Description
OpenSSL offers two methods to protect sensitive cryptographic keys.
1) standard file system permissions on key file
2) encrypting the key file with a password, i.e. PBE (Password Passed Encryption)
The key management code in keystone/
The keystone configuration defines a ssl.ca_password and signing.ca_password configuration option. These are defined in keystone/
However these passwords are never actually used to password protect any of the keys.
The only use of either of the ca_password variables is a no-op when the CA self-signed cert is created in BaseCertificate
if not file_exists(
In this instance there is no point in passing in a password to decrypt the ca_private_key file because the ca_private_key file was never encrypted to begin with.
The ca_private_key file is created a few lines above with this code:
To have applied PBE (Password Based Encryption) to the ca_private_key the openssl genrsa command would need to have included the -passout arg (i.e. the password to encrypt the output file with, the output file is the key) and the encryption method which is either DES, triple-DES, or IDEA (-des, -des3, or -idea respectively).
The same problems exist with respect to the signing key.
Issue:
The point of protecting a key with a password is to further protect the key (keys are the most security sensitive components, especially both the CA and signing key). But using PBE on the keys currently requires storing the password in a configuration file which can only be protected by file system permissions. Thus using PBE on keys may not offer much additional security if the configuration file containing the key password can be read by an unauthorized user. If an attacker can read the file containing the password they probably also can read the key file or visa-versa. On the other hand one more layer of security doesn't hurt (perhaps the attacker only stole the key file because it's an obvious target but failed to find or obtain the config file with the password needed to extract the key from the key file.
As to which PBE scheme to use? DES is too weak. It's too bad AES is not an option. IDEA is faster and probably stronger than triple-DES (the patent protection on IDEA just recently expired so there shouldn't be any licensing issues)
Summary:
The the presence of key passwords in the configuration options gives the false illusion keys are password protected when in fact they aren't The only use of the password option in the current code is meaningless because it's being used to unlock a key file that was never locked in the first place.
Either the key passwords should be removed (because they aren't actually used) or they should be used consistently to lock and unlock the keys.
The security vulnerability is probably just "do we want to alert folks that the key passwords are not actually used?" and by extension grabbing the key file is sufficient to initiate an attack because you'll have immediate access to the key.
summary: |
- CA key and signing key are not password protected + CA key and signing key are not really password protected |
information type: | Private Security → Public |
no longer affects: | ossa |
Changed in keystone: | |
importance: | Undecided → High |
milestone: | none → havana-3 |
status: | New → Confirmed |
Changed in keystone: | |
milestone: | havana-3 → havana-rc1 |
Changed in keystone: | |
status: | Fix Committed → Fix Released |
Changed in keystone: | |
milestone: | havana-rc1 → 2013.2 |
Nice find!
This is definitely a bug that should be fixed ASAP, but it's a bit in the grey area on the vulnerability side. Yes, people may think their key is more protected than it actually is, but then we are not relying on that "feature" to actually protect the key, and the fix does not provide extra security beyond the obscurity of needing to steal two files (protected with the same rights) instead of one. The ca_password option sounds pretty useless to begin with, so we could probably get rid of it.
I'm wandering on the "no" side, but could easily be convinced otherwise.