Securing your Notes ID vault server
Abstract
Notes/Domino 8.5 introduces a new security feature, the Notes ID vault. The vault provides a great deal of convenience for administrators and end users -- password resets, ID file provisioning, ID file synchronization, centralized ID file backups, and more. This paper will discuss some techniques that administrators can use to securely configure their Notes ID vault servers. Not all of these techniques will be applicable to every environment; administrators should determine which recommendations make sense to implement in their environments.
Defense in depth
The first step to protecting the Notes ID vault is to protect the Domino server hosting the ID vault. Don't just configure the Notes ID vault feature securely; configure the entire Domino server securely. Limit the number of users who can open databases on that Domino server, and if feasible, dedicate a secure machine to the ID vault. Configure the computer's operating system securely, and don't allow network traffic from outside of your organization to route to any of your Notes ID vault replicas. Limit the number of administrators with remote access to the operating system, and block all of the network ports that aren't explicitly needed in order to cut down on the odds of an exploit in the OS or another application. Limit physical access to the computer itself, and don't forget to look up -- does your office building have a drop ceiling?
Securing the server ID file
To guard against an attacker who does manage to steal a copy of the vault.nsf database and the server's ID file, secure the ID file for the Domino server on which your Notes ID vault resides. We understand that most Domino servers are not password-protected to make unattended reboots simpler, but the vault server's ID file is a key element in the security of your ID vault. There are no APIs that can be used to attack a vault.nsf using a server ID file, but a sophisticated attacker with a vault database and one of the corresponding server IDs and passwords would have all of the cryptographic information needed to masquerade as the vault server and decrypt all of the ID files stored in the vault.
First, make it harder for an attacker to guess the password of your vault server in the case that the attacker does manage to steal a copy of the ID file by changing the ID file encryption strength from the default setting to one of the relatively new settings introduced in 8.0.1 -- AES-256. This setting will encrypt the ID file with a 256 bit AES key derived from the password using PKCS#5 v2.1's PBES2. That algorithm uses salt and an iteration count to frustrate an attacker; crude non-scientific tests showed that the default setting of 5,000 iterations resulted in each password guess taking about 7,000 times longer than with the RC2-64 technique introduced in Notes V1. You've upgraded your hardware a few times since then, it's time to upgrade your security settings as well.
What about environments that just can't password protect a server ID file due to a hard requirement for unattended reboots? Another option is to secure that server ID file with a smartcard instead of a password, and use the EM_GETPASSWORD extension manager hook to supply the smartcard PIN to the server on reboot. The server can reboot without administrative intervention, and an attacker would need to sneak into your server lab and walk off with the physical token in order to use a stolen copy of the server ID file. Anybody who takes this approach should store a password-protected backup of that server ID file in a secure location, in the same way that they already securely back up their certifier ID files and passwords. Protecting the vault server ID file with a smartcard instead of a password does not negate the recommendation to upgrade the ID file encryption strength to AES-256 before protecting the ID file with the smartcard. Sample C API pseudo-code is shown below to lock an ID file with a key on a smartcard.
Another ID file that should be stored securely is the vault ID file which is created when the initial vault server is configured. This ID file will be stored on the admin client's workstation by default (in a directory along the lines of c:\Lotus\Notes\Data\ids\vault), and will be needed again to add new vault replicas. This ID file should not be left on the admin's workstation; it should be securely backed up and protected in the same manner as a certifier ID file.
Auditor: Extract ID from vault
One of the powerful capabilities provided by the Notes ID vault is the ability for an auditor to extract an ID file from the vault without knowledge of the corresponding password. However, most organizations will not need to utilize this functionality on a regular basis, and should disable it by setting SECURE_DISABLE_AUDITOR=1 in the notes.ini files on all of their vault servers. When the auditor functionality is required, shut down the Domino server hosting one of the vault replicas, remove that notes.ini variable, and restart the server. Remember to reverse the process after extracting the desired ID file or ID files from the vault, and keep in mind that this variable can only be set and un-set in the notes.ini file; it cannot be changed through the server console.
Server Key Rollover
Notes/Domino 8.0 added support for 2048 bit user and server ID files. Administrators should either deploy all of their Notes ID vault replicas on servers that already have 2048 bit RSA keys, or use the server key rollover feature to upgrade those future vault replicas to 2048 bit RSA keys before deploying those vault replicas. A 640 bit RSA key was successfully publically factored in November of 2005 in about 4.5 months on a gigabit cluster of 80 2.2GHz CPUs, so we recommend against using 512 or 630 bit RSA keys to protect your organization's ID files. A team of researchers has successfully factorized 768 bit RSA on December 12, 2009 and published a paper about their work titled
Factorization of a 768-bit RSA modulus
. No 1024 bit RSA keys have been publically factored (at least as of January 2009), but the slight performance hit to upgrade directly to 2048 bit keys should be worth the improved security and peace of mind.
Notes/Domino 8.5: If all of the vault server replicas for a given vault have at least 1024 bit RSA keys, the Vault Operations key will be encrypted using a 128 bit RC2 key. Just how strong is this? In 1998, the Electronic Frontier Foundation (EFF) built a dedicated hardware DES cracker for less than $250,000, including design costs, and in 1999 that machine managed to crack a 56 bit DES key in less than a day, with the help of 100,000 PCs on the Internet. A machine that could crack that 56 bit key in one second would take approximately 149 thousand billion years to crack a 128 bit symmetric key. However, if you're worried about quantum computing, or your security department doesn't like RC2, you can change that 128 bit RC2 key into a 256 bit AES key by setting the DEBUG_SEAL2_AES=256 notes.ini variable on the primary vault server when initially creating the Notes ID vault vault and when adding new vault replicas. This will ensure that the Vault Operations key is encrypted with a 256 bit AES key.
Notes/Domino 8.5 FP1 and 8.5.1: Starting in Domino 8.5 FP1 and 8.5.1, the Notes ID vault will always encrypt the Vault Operations key with a 256 bit AES key. For this reason, I would recommend that you upgrade your Notes ID vault servers to 8.5 FP1 or better.
C API pseudo-code to lock an ID file with a key on a smartcard. Don't attempt to run this pseudo-code directly -- real code should validate inputs and check for and handle error conditions.
error = SECManipulateSC (SC_manip_GetVersion,
NULLSCMCTX,
NULL,
&Version,
NULL);
/* Initialize the PKCS#11 context.
*/
SCMCTX Context = NULLSCMCTX;
error = SECManipulateSC (SC_manip_InitializeContext,
&Context,
NULL, NULL, NULL);
/* Set up the server's ID file
*/
error = SECManipulateSC (SC_manip_EnterIDFile,
&Context,
NULL,
&dwIDLen,
ServerIDPath);
/* Unlock the smartcard
*/
error = SECManipulateSC (SC_manip_EnterPIN,
&Context,
NULL,
&dwPINLen,
PIN);
/* Note -- SC_manip_EnterPIN will use an external authentication path if it exists. If the token doesn't support a protected authentication path, SC_manip_EnterPIN will use the supplied PIN if one exists or generate a prompt if a NULL or zero-length PIN was used. */
DWORD i = 0;
DWORD numKeys = 0;
/* Find all matching certs
*/
error = SECManipulateSC (SC_manip_FindAllKeys,
&Context,
NULL,
&numKeys,
NULL);
/* Optionally, loop over all keys and display info about them
*/
for (i = 0; i < numKeys; i++)
{
DWORD retLen = i;
BYTE *pBuf = NULL;
SC_MANIP_IMPORTABLE_CERT *pStruct = NULL;
/* How big is this cert?
*/
error = SECManipulateSC (SC_manip_GetMatchedCert,
&Context,
NULL,
&retLen,
NULL);
/* Allocate a buffer pBuf of size at least retLen + 1
*/
...
pStruct = (SC_MANIP_IMPORTABLE_CERT *) pBuf;
pStruct->dwSize = (size of buffer pointed to by pBuf)
/* Fetch the i'th cert, along with some other identifying info
*/
retLen = i;
error = SECManipulateSC (SC_manip_GetMatchedCert,
&Context,
NULL,
&retLen,
pBuf);
/* Display info from pStruct
*/
...
/* Free pBuf
*/
...
}
/* Lock the ID file with one of the keys on the smartcard
*/
DWORD key = 0;
...
if (key > numKeys)
xprintf ("Invalid choice... aborting\n");
error = SECManipulateSC (SC_manip_LockIDWithKeyRO,
&Context,
NULL,
&key,
NULL);
/* Clean up
*/
SECManipulateSC (SC_manip_TerminateContext,
&Context,
NULL, NULL, NULL);