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
apply hotfix TBD.
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);