Difference between revisions of "Projects/Crypto modularity"

Revision as of 08:34, 19 June 2009

Desired Changes

The objective of this project is to clear the way for the cryptographic implementations from various providers to be used in lieu of MIT Kerberos custom cryptography. The existing crypto directory should be divided into two subdirectories krb and builtin. The first of these folders will be designated for the Kerberos specific functionality, while the second directory will be a place-holder for the generic lower level cryptographic primitives. Additional directories will be added as part of the adaptation of vendor's crypto-systems ( such as NSS, OpenSSL, BSAFE etc)

Functional Requirements

The existing crypto and hash providers will serve as a cryptographic front-end, while the back-end will provide the implementation dependent cryptographic primitives. The crypto provider should be chosen with a designated flag during configure process.

Design

• Divide crypto directory into two subdirectories:

krb - Kerberos specific functionality. Provides front-end into crypto routines. Files: checksum, dk, aead, enc_provider, hash_provider, keyhash_provider, nfold, key ops, etype ops, prf, raw, crc32, old [, prng, yarrow] builtin - MIT implementations. Provides back-end of the crypto routines. Files: md*, des*, aes, hmac, sha1, pbkdf2 [, prng, yarrow]

• Add a new directory to provide a crypto implementation based on OpenSSL or NSS crypto-system. The directory will have the structure similar to builtin.

For example, the modifications in md5 subdirectory may look like the following if OpenSSL implementation is used:

 rsa-md5.h:
 #include <openssl/evp.h>
 #include <openssl/md5.h>
 ...
 /* Data structure for MD5 (Message-Digest) computation */
 typedef struct {
    EVP_MD_CTX ossl_md5_ctx;     /* OPEN_SSL */
    krb5_ui_4 i[2];                       /* number of _bits_ handled mod 2^64 */
    krb5_ui_4 buf[4];                     /* scratch buffer */
    unsigned char in[64];                 /* input buffer */
    unsigned char digest[16];             /* actual digest after MD5Final call */
 } krb5_MD5_CTX;
 ...
 md5.c:
 void krb5_MD5Init (krb5_MD5_CTX *mdContext)
 {
    EVP_MD_CTX_init(&mdContext->ossl_md5_ctx );
    EVP_DigestInit_ex(&mdContext->ossl_md5_ctx , EVP_md5(), NULL);
 }
 void krb5_MD5Update (krb5_MD5_CTX *mdContext, const unsigned char *inBuf, unsigned int inLen)
 {
    EVP_DigestUpdate(&mdContext->ossl_md5_ctx , inBuf, inLen);
 }
 void krb5_MD5Final (krb5_MD5_CTX *mdContext)
 {
   EVP_DigestFinal_ex(&mdContext->ossl_md5_ctx , mdContext->digest , NULL);
 }

In addition, if back-end refers to keys using opaque handles, as might be needed on a PKCS#11 device, “overload” krb5_keyblock structure by using its member “krb5_octet *contents” as a void ptr to the opaque key handle/structure. To ensure that the existing applications would still work one of the options is to assign a special value to magic that would control how krb5_keyblock->contents is used.

• Add new flags to configure to control the use of the desired cryptographic implementation. The lib/crypto make system will be modified to build lib/crypto/krb and lib/crypto/builtin files to construct libk5crypto library in case when builtin cryptography is desired. However, in the cases when the different crypto implementation was chosen, builtin makesystem will direct the build process into the implementation specific directory.

Tasks/ Milestones

1. Split crypto directory into two directories krb and builtin;
2. Makefile changes to handle the new structure of lib/crypto directory;
3. Implement back-end crypto based on OpenSSL or NSS;
4. Develop test cases;

Testing Plan

1. Use "make check" to ensure krb5 integrity;
2. Use existing and new client/server test tools built with mixed crypto implementations.