Cryptographic Use and Management

Cryptography is used to ensure the confidentiality and integrity of server data in memory and in the repository, as well as all data transmitted between the Waveset Server and Gateway.

The following sections provide more information about how cryptography is used and managed in the Waveset Server and Gateway, and addresses questions about server and gateway encryption keys.

Cryptographically Protected Data

The following table shows the types of data that are cryptographically protected in the Waveset product, including the ciphers used to protect each type of data.

Table 12–1 Cryptographically-Protected Data Types

Data Type	RSAMD5	NIST Triple DES168-Bit Key (DESede/ECB/NoPadding)	PKCS#5 Password-Based Crypto56-Bit Key (PBEwithMD5andDES)
Server encryption keys		default	configuration option
Gateway encryption keys		default	configuration option1
Policy dictionary words	yes
User passwords		yes
User password history		yes
User answers		yes
Resource passwords		yes
Resource password history	yes
All payload between server and gateways		yes

Frequently Asked Questions about Server Encryption Keys

Read the following sections for answers to frequently asked questions about server encryption key source, location, maintenance, and use.

Question:

Where do server encryption keys come from?

Answer:

Server encryption keys are symmetric, triple-DES 168-bit keys.

There are two types of keys supported by the server:

• Default key. This key is compiled into the server code.

• Randomly generated key. This key can be generated at initial server startup, or any time the security of the current key is in question.

Question:

Where are server encryption keys maintained?

Answer:

Server encryption keys are objects maintained in the repository. There can be many data encryption keys in any given repository.

Question:

How does the server know which key to use for decryption and re-encryption of encrypted data?

Answer:

Each piece of encrypted data stored in the repository is prefixed by the ID of the server encryption key that was used to encrypt it. When an object containing encrypted data is read into memory, Waveset uses the server encryption key associated with the ID prefix on the encrypted data to decrypt, and then re-encrypt with the same key if the data changed.

Question:

How do I update server encryption keys?

Answer:

Waveset provides a task called Manage Server Encryption.

This task allows an authorized security administrator to perform several key management tasks, including:

• Generating a new “current” server key

• Re-encrypting existing objects, by type, containing encrypted data with the “current” server key

See Managing Server Encryption in this chapter for more information about how to use this task.

Question:

What happens to existing encrypted data if the “current” server key is changed?

Answer:

Nothing. Existing encrypted data will still be decrypted or re-encrypted with the key referenced by the ID prefix on the encrypted data. If a new server encryption key is generated and set to be the “current” key, any new data to be encrypted will use the new server key.

To avoid multi-key issues, as well as to maintain a higher level of data integrity, use the Manage Server Encryption task to re-encrypt all existing encrypted data with the “current” server encryption key.

Question:

What happens when you import encrypted data for which an encryption key is not available?

Answer:

If you import an object that contains encrypted data, but that data was encrypted with a key that is not in the repository into which it is being imported, then the data will be imported, but not decrypted.

Question:

How are server keys protected?

Answer:

If the server is not configured to use password-based encryption (PBE) - PKCS#5 encryption (set in the System Configuration object using the pbeEncrypt attribute or the Manage Server Encryption task), then the default key is used to encrypt the server keys. The default key is the same for all Waveset installations.

If the server is configured to use PBE encryption, then a PBE key is generated each time the server is started. The PBE key is generated by providing a password, generated from a server-specific secret, to the PBEwithMD5andDES cipher. The PBE key is maintained only in memory and never persisted. In addition, the PBE key is the same for all servers sharing a common repository.

To enable PBE encryption of server keys, the cipher PBEwithMD5andDES must be available. Waveset does not package this cipher by default, but it is a PKCS#5 standard that is available in many JCE providers implementations, such as those provided by Oracle and IBM.

Question:

Can I export the server keys for safe external storage?

Answer:

Yes. If the server keys are PBE encrypted, then before they are exported, they will be decrypted and re-encrypted with the default key. This allows them to be imported to the same or another server at a later date, independent of the local server PBE key. If the server keys are encrypted with the default key, then no preprocessing is done before they are exported.

When they are imported into a server, if the server is configured for PBE keys, the keys will be decrypted and then re-encrypted with the local server’s PBE key, if that server is configured for PBE key encryption.

Question:

What data is encrypted between the server and gateway?

Answer:

All data (payload) transmitted between the server and gateway is triple-DES encrypted with a randomly generated, per server-gateway session symmetric 168 bit key.

Frequently Asked Questions about Gateway Keys

Read the following sections for answers to frequently asked questions about gateway source, storage, distribution, and protection.

Question:

Where do the gateway keys come from to encrypt or decrypt data?

Answer:

Each time an Waveset Server connects to a gateway, the initial handshake will generate a new random 168-bit, triple-DES session key. This key will be used to encrypt or decrypt all subsequent data transmitted between that server and that gateway. There is a unique session key generated for each server/gateway pair.

Question:

How are gateway keys distributed to the gateways?

Answer:

Session keys are randomly generated by the server and then securely exchanged between server and gateway by encrypting them with the shared secret master key as part of the initial server-to-gateway handshake.

At initial handshake time, the server queries the gateway to determine which mode it supports. The gateway can operate in two modes

• Default mode. Initial server-to-gateway protocol handshake is encrypted with the default 168–bit triple-DES key, which is compiled into the server code.

• Secure mode. A per shared repository, random, 168-bit key, triple-DES gateway key is generated and communicated from the server to the gateway as part of the initial handshake protocol. This gateway key is stored in the server repository like other encryption keys, and also stored by the gateway in its local registry.

  When in secure mode and a server contacts a gateway, the server encrypts test data with the gateway key and sends it to the gateway. The gateway then attempts to decrypt the test data, add some gateway unique data to the test data, re-encrypt both, and send the data back to the server. If the server can successfully decrypt the test data and the gateway unique data, the server then generates the server-gateway unique session key, encrypts it with the gateway key and sends it to the gateway. Upon receipt, the gateway decrypts the session key and retains it for use during the life of the server-to-gateway session. If the server cannot successfully decrypt the test data and gateway unique data, the server encrypts the gateway key using the default key and sends it to the gateway. The gateway decrypts the gateway key using its compiled in default key and stores the gateway key in its registry. The server then encrypts the server-gateway unique session key with the gateway key and sends it to the gateway for use during the life of the server-to-gateway session.

  From that point forward, the gateway will only accept requests from servers that have encrypted the session key with its gateway key. On startup, the gateway checks the registry for a key. If a key exists, the gateway will use that key. If there is no key, the gateway uses the default key. Once the gateway has a key set in the registry, the gateway no longer allows sessions to be established using the default key, which prevents someone from setting up a rogue server and establishing a connection to a gateway.

Question:

Can I update the gateway keys used to encrypt or decrypt the server-to-gateway payload?

Answer:

Waveset provides a task called Manage Server Encryption that allows an authorized security administrator to do several key management tasks, including generate a new “current” gateway key and update all gateways with the “current” gateway key. This is the key that is used to encrypt the per-session key used to protect all payload transmitted between server and gateway. The newly generated gateway key will be encrypted with either the default key or PBE key, depending on the value of the pbeEncrypt attribute in the System Configuration (Editing Waveset Configuration Objects).

Question:

Where are the gateway keys stored on the server, on the gateway?

Answer:

On the server, the gateway key is stored in the repository just like server keys. On the gateway, the gateway key is stored in a local registry key.

Question:

How are gateway keys protected?

Answer:

The gateway key is protected the same way server keys are. If the server is configured to use PBE encryption, the gateway key will be encrypted with a PBE generated key. If the option is false, it will be encrypted with the default key. See Frequently Asked Questions about Server Encryption Keys for more information.

Question:

Can I export the gateway key for safe external storage?

Answer:

The gateway key can be exported using the Manage Server Encryption task, just as with server keys. See Frequently Asked Questions about Server Encryption Keys for more information.

Question:

How are server and gateway keys destroyed?

Answer:

Server and gateway keys are destroyed by deleting them from the server repository. Note that a key should not be deleted as long as any server data is still encrypted with that key or any gateway is still relying on that key. Use the Manage Server Encryption task to re-encrypt all server data with the current server key and to synchronize the current gateway key to all gateways to ensure no old keys are still being used before they are deleted.