The server storage key is a computer-specific key. Each server creates a server storage key which is unique to that server and which can be used to securely wrap other keys for either local or remote storage. After a key is wrapped with a server storage key, only code on that server can unwrap the key, this allows the wrapped key to be remain secure even when stored remotely.
Prior to NICI 3.0, the storage keys were Triple Data Encryption algorithm (3DES) keys. NICI 3.0 creates AES 256-bit storage keys. Any application that uses the storage keys to securely wrap other keys should be able to handle the new algorithm to encrypt new data. However, any data which is currently wrapped with the older 3DES keys will still be assessable without any changes.
To securely send data from a client to a server or server to server or vice versa, NICI provides the SASDFM keys which serve as a session key. Prior to NICI 3.0, the session keys were 3DES keys. NICI 3.0 supports AES 256-bit session keys, as well as 3DES keys, depending on the capabilities of the applications.
The client application and the eDirectory server will use the AES 256-bit session key only if both of them use NICI 3.0.
If either of them uses a lower version of NICI, they will use a 3DES session key.
NICI SDI (Security Domain Infrastructure) is an eDirectory service which provides and manages shared keys for all servers within a security domain. Access to SDI keys is governed by eDirectory rights and attributes. There is a specific set of rights and attributes that allow a server to create and distribute an SDI key. A server with this set of rights and attributes is known as a Key server. There is a different set of rights and attributes that allows a server to acquire keys from a Key server.
NICI SDI can manage multiple keys of varying strengths and algorithms. Each SDI key can have a different security domain and is controlled by the eDirectory rights and attributes of the eDirectory object representing the SDI key known as the SDI key object:
Linux: libniciext.so
Windows: niciext64.dlm
The security domain keys are not intended for clients.
Tree keys are a special kind of NICI SDI key. The security domain for tree keys consists of the whole eDirectory tree, and they are automatically managed by eDirectory and NICI SDI.
In all prior versions of eDirectory a single security domain consisting of the whole tree has been established and the associated key is often referred to as the Tree key or sometimes the W0 key (as the SDI key object used to manage this key is CN=W0.CN=KAP.CN=Security). This key is a 3DES key, and all the servers in an eDirectory tree have the rights to acquire this key. This key will continue to be available.
Beginning in eDirectory 9.0 with NICI 3.0, eDirectory will support the creation of a new AES 256-bit Tree key. The SDI key object used to manage this new Tree key is CN=W1.CN=KAP.CN=Security. It is required that all servers in the tree be upgraded to eDirectory 9.0 before enabling this key. Although eDirectory 9.0 will automatically create this SDI key object, it will not assign a Key server and the key will not get created by default. An administrator will need to assign a Key server to the SDI key object, after confirming that all servers in the tree have been upgraded to eDirectory 9.0, in order to enable the new AES 256-bit Tree key. For more information, see Creating an AES 256-Bit Tree Key.
Although any server can be configured as a Key server for the tree keys, it is recommended that only servers holding a writeable replica of the SDI key object be assigned. It is recommended that the first Key server assigned be the Master replica (for example, the server holding the Master replica of the object CN=W1.CN=KAP.CN=Security).
NICI SDI supports having multiple Key servers for any SDI key and it is recommended that multiple Key servers be assigned. In NICI 3.0, once a Key server has been assigned to the Tree key objects, the new Heath-Check feature will automatically add servers holding a writeable replica of the SDI key object). The idea here is that NICI SDI will automatically mirror the Key servers to your eDirectory replicas.
Various services rely on the availability of Tree keys, including but not limited to SecretStore/Single-Sign-On, PKI (Certificate Server), and NMAS.
NOTE:The NICISDI module is different from the SASDFM module. SASDFM manages session keys between two physical boxes, typically between a client and a server.