yahoo-eng-team team mailing list archive

[Thierry Carrez <thierry.carrez+lp@xxxxxxxxx>]

** Changed in: keystone
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1214016

Title:
  CA key and signing key are not really password protected

Status in OpenStack Identity (Keystone):
  Fix Released

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/common/openssl.py is confused to
  to whether it's encrypting keys or not.

  The keystone configuration defines a ssl.ca_password and
  signing.ca_password configuration option. These are defined in
  keystone/common/config.py and etc/keystone.conf.sample.

  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
  BaseCertificateConfigure.build_ca_cert()

          if not file_exists(ca_cert):
              self.exec_command('openssl req -new -x509 -extensions v3_ca '
                                '-passin pass:%(ca_password)s '
                                '-key %(ca_private_key)s -out %(ca_cert)s '
                               ...

  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:

              self.exec_command('openssl genrsa -out %(ca_private_key)s '
                                '%(key_size)d')

  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1214016/+subscriptions