Handling of Private Keys
This topic discusses the proper handling of private keys, in particular the IdP's signing key. The public keys bound to X.509 certificates in metadata are discussed in the Key Usage topic.
It is easy to generate a long-lived, self-signed certificate with OpenSSL:
$ openssl req -new -x509 -keyout key.pem -out cert.pem \
-days 3650 -newkey rsa:2048 -subj "/CN=hostname.example.org"
The above command will store the private key in file key.pem and the corresponding public key certificate in file cert.pem. The latter is eventually added to InCommon metadata.
Protect your private key!
Positive control of the private key must be maintained at all times.
The security of your deployment depends on the security of the private key used to sign and/or decrypt messages. Develop a strategy for securing your private key before you generate it.
The IdP Signing Key
In the case of the IdP, the private key is used to sign SAML assertions transmitted to the SP. (The corresponding certificate in metadata contains the public key that is used by the SP to verify the signature on the assertion.) If the private key is lost or stolen, the holder has the power to issue arbitrary assertions to any SP. This is the absolute worst thing that can happen in a federated context.
The IdP's private signing key is necessarily an online key, that is, it must be available to the IdP software at runtime. An online key may be encrypted, but the password or passphrase used to decrypt the key generally has to be available in an unencrypted file so that the IdP service can be restarted in unattended fashion. Therefore an online key is considerably more vulnerable than an offline key, and must be protected accordingly.
If the signing key is stored in the file system as an ordinary file, it should have strict permissions to prevent unauthorized copying of the private key. For stronger protection, the signing key may be stored in a hardware security module (HSM) that prevents export of the private key.
Key Audit
You need to go back to day one of the total lifetime of each of your private keys and ask the following question: Has this key been under my positive control at all times? If the answer to that question is anything other than yes, the key should be considered compromised. This of course requires that the corresponding public key certificate be systematically migrated out of metadata. See the Certificate Migration topic for instructions how to do this.
If there is reason to believe that the IdP's signing key has fallen into the wrong hands, it should be replaced immediately. In this case, there can be no orderly migration of the corresponding public key certificate in metadata, which should be replaced immediately as well. This will break interoperability with SPs until such time as they have refreshed metadata (which is why regular, automated metadata refresh is important), so replace the IdP's signing key only under the most serious circumstances.