Cryptographic Operations

Author

Torben Pedersen, CRM

The crypto manager offers cryptographic operations through a cryptographic module. These operations are called by using the static methods of the CryptoManager. The following operations are available

Key generation (public/private key pairs and conventional keys)
Random bit generator (which is also used indirectly for key generation)
Making and verifying signatures
Making and verifying MAC values
Public key encryption/decryption
Conventional encryption/decryption
Computation of message digests using a hash function
Operations with a master key (this is a conventional key encryption key)

When using the cryptographic operations the algorithm to be used must be specified. This is currently done using integer codes defined in CryptoConstants, but this may be changed in coming versions to allow verification at compilation time whether the right type of algorithm is specified.

Initialisation of the crypto manager

The initialisation does three main things:

Loads the correct module (for the moment this is a default module, CRMModule ).
Initialises the pseudo random generator (PRG) of the module (the first time this is based on a user supplied seed - entered through TINGUIN - later initialisations use a seed stored in the archive). The class CryptoSeed contains this seed.
Loads the master key from archive (the very first time a master key is generated, and the user is asked to provide a password by entering it twice; in all subsequent initialisations the user must provide this password).

In principle the following cryptographic operations can all be used prior to initialisation:

Making and verifying signatures
Making and verifying MAC values
Public key encryption/decryption
Conventional encryption/decryption
Computation of message digests using a hash function

In addition it is possible to generate keys provided the caller provides a random seed (normally this is not needed as the manager uses the pseudo random generator).

However, in practice all secret keys will be protected under the master key (see below), and this key cannot be used until the manger has been properly initialised.

Intialisation of the Crypto Manager requires that a userId can be read from the configuration ("semper.configuration.username"). If no user name is supplied here the manager will simply read the id from the system. The manager uses this name when storing and retrieveing user specific iinformation such as the master key and the seed used by the pseudo random generator. In addition the user name is used when defining the standard key identifier when generating keys.

Key protection

The crypto manager protects all keys by encrypting them under a master key handled by the crypto manager. The master key is generated initially and recovered by services in CryptoMasterKey. As mentioned above the master key is protected under a password defined by the user. There is no control that the use selects a "good password". The advantage of this approach compared to just protecting the keys directly under the password is that changing a password (which is anticipated to take place relatively often) just requires the encryption of the master key to be changed.

Cryptographic keys are handled by CryptoKeyInfo objects. Such an object can either contain a handle to the key or the actual key value. These objects are designed to contain information needed to control use of the keys. However, this is not fully implemented yet.

Keys can be stored using storeKeyVal. In this operation the user can ask that the key be encrypted under the masterKey (default) or some other key before storage. Keys can be retrieved using getKeyVal. Here the user can either ask for the encrypted key or the decrypted key value. Again the masterKey of CryptoMan is the default key.

Unless another key identifier is explicitly assigned, the key is stored under the key identifier (AccessName) defined by the manager when generating the key. This standard key name is made unique by containing among other parts the user name and a user specific serial number, which is assigned to the key during key generation. which is u

Testing

The present version has been tested on WIN95, Linux, Soloaris and AIX with RSA and DES as cryptographic algorithms. The program "semper/src/semper/crypto/Test/TCrypto" tests storing keys in and retrieving keys from archive. The test programs in "semper/src/semper/statement/Test" can be used to illustrate the use of the CryptoManager in the Statement services . Libraries for WIN95, SOLARIS, LINUX and AIX are on the server. See the file "readme.txt" in the crypto directory for more information.

To be done

Provide methods for changing password and master key
Use preferences for specifying security level (e.g., key lengths)
Suppport more than one module by the manager (this includes defining an interface that such modules must implement).
Test more cryptographic algorithms
Add methods for using the cryptographic operations of files (the module is prepared for this, but the manager is not).
Support access control to the services of the crypto manager
Provide a utility for picking up randomness (e.g., by timing key strokes).
Support the functionality for files.

Date: January 27, 1997 .