Tutorial: Windows Cryptographic API and Session Key

Management

Dr. Edwin Hernandez

IEEE SOUTHEAST CONFERENCE 2005

Outline

• Problem: Key management and Storage• Microsoft’s Crypto API and Important

Concepts• Session Keys in Crypto API• Sample code• Exchanging session keys• Exponent-of-one transformation• Conclusions

Problem: Key Management and Storage in Applications

• Hardcoded: – BYTE mysecretkey[]= {"\x01\x02\x03\x04\x05\

x06\x07\x08\x09\x0A\x0B\x0C\x0D\x0E"};

• Obfuscated in the code

• Special tools that create secret compartments in your memory space

• Smartcards and key containers

Microsoft’s Crypto API (MS CAPI)

The Cryptography API contains functions that allow applications to encrypt or digitally sign data in a flexible manner, while providing protection for the user's sensitive private key data. All cryptographic operations are performed by independent modules known as cryptographic service providers (CSPs). One CSP, the Microsoft RSA Base Provider, is included with the operating system.

CSPs in MSDN (Not all are supported in all platforms)

Cryptographic Service Providers

Windows CE CSPs

Cryptographic Service Providers

• Available in:– Windows (Desktop): Platform SDK– Windows CE (Window Mobile, Smartphones,

Pocket PC). Platform Builder

Important concept: Key Containers

• Each container has a Key Database

• Each Key Database has Keys

• A key container work as a smart card, however containers are designed to protect keys.

Important Concepts

• Session Keys– Session keys are used when encrypting and decrypting data..

These keys are kept inside the CSP for safekeeping. Unlike the key pairs, session keys are volatile. Applications can save these keys for later use or transmission to other users by exporting them from the CSP into application space in the form of an encrypted key binary large object or key blob using the CryptExportKey function. Public or Private Key Pairs

• Each user generally has two public or private key pairs. – One key pair is used to encrypt session keys and the other to

create digital signatures. These are known as the key AT_EXCHANGE, and AT_SIGNATURE keys.

Important Concepts: Containers and Key Storage

• CSPs keep the keys and all the containers for those keys isolated from the application layer. By opening a container, application are then able to sign, encrypt, and decrypt data with a key. The container could be password protected, stored in a smartcard, or a secure media.

• Two methods can be used to set keys in a CSP.– CSP Generated key (e.g. via CryptGenKey or

CryptDeriveKey)– Force a session and application keys be the same

(Exponent-of-One Transformation)

Digital Signature Wizard (Platform SDK or Windows Mobile SDK)

Methods of generating keys into a container

The CryptGenKey calls are used to create a new key values. The key value could be DES, 3DES, etc.

You can derive a key from a hash or a password using CryptDeriveKey also.

Sample code with Key Containers

• We will see how to initialize and use a Key container

• How to use a key from the container

• Finally, how to exchange session keys

Acquire Valid Key Container// HPROV hProv, provider’s handle context3

If (CryptAcquireContext(&hProv,

L"KeyContainerTest1",

NULL,

PROV_RSA_FULL, 0))

printf("CryptAcquireContext ok\n");

else

printf("Error %x CryptAcquireContext!\n", GetLastError());

Application

CSP(Cryptograhpic Service

Provider)

Windows CE

KeyDtabase

Key Container #1

Signature Key PairExchange Key Pair

Key Container #2

Signature Key PairExchange Key Pair

The concept

Retrieving Container Keys (Signature)

//------------------------------------------// Public and Private Keys for the Container//------------------------------------------if (CryptGetUserKey(hProv,

AT_SIGNATURE,&hKeySignature))printf("CryptGetUserKey AT_SIGNATURE ok \n");

else printf("Error %x AT_SIGNATURE \n", GetLastError());

Retrieving Container Keys (Exchange)

//------------------------------------------// Public and Private Keys for the Container//------------------------------------------if (CryptGetUserKey(hProv,

AT_KEYEXCHANGE,&hKeySignature))printf("CryptGetUserKey AT_SIGNATURE ok \n");

else printf("Error %x AT_SIGNATURE \n", GetLastError());

Retrieve Key Public KeypbPublicKeyBlob = (LPBYTE) malloc (cbPublicKeyBlob);if (CryptExportKey(hKeySignature,

0, PUBLICKEYBLOB, 0, pbPublicKeyBlob, &cbPublicKeyBlob))

{ printf("CryptExportKey is ok \n ");

printf("The Public Key Length is : %d. \n", cbPublicKeyBlob); for (i=0; i<cbPublicKeyBlob; i++) {

printf("%2.2x ", *(pbPublicKeyBlob +i));if ((i+1) % 16 == 0) printf("\n");

}printf("\n");

}

Retrieving Key Container (Private Key Blob)

pbPrivateKeyBlob = (LPBYTE) malloc (cbPrivateKeyBlob);

if (CryptExportKey(hKeySignature,

0,

PRIVATEKEYBLOB,

0,

pbPrivateKeyBlob,

&cbPrivateKeyBlob))

{

\\ Obviously this must fail, however certain keys can

\\ be stored as CRYPT_EXPORTABLE otherwise the private key cannot

\\ be exported

}

Exchanging a Session KeyTo send an encrypted session key • Create a random session key, using the CryptGenKey function. • Encode the message, using the session key. • Export the session key into a key BLOB with the CryptExportKey

function. Specify that the key be encoded with the destination user's key exchange public key, which is the receiver's public key.

• Send the encoded message and the encoded key BLOB to the destination user.

• The receiver then imports the key BLOB into the CSP, using the CryptImportKey function. This automatically decodes the session key, provided that the destination user's key exchange private key was specified in step three.

• The receiver can then decode the message, using the session k ey

Exchanging Encrypted Data with Session Key

Sender Receiver

hKey = CryptGenKey(CALG_3DES)CryptImport(hKeyExchange, &ReceiversPublicKey);CryptExport(hKey, &SessionKey)CryptEncrypt(hKeyExchange, ..&SessionKey,)CryptEncrypt(hKey, &Message);Send(Message, SessionKey)

Receive(Message, eSessionKey)CryptImport(hMyOwnPublicKey, &dSessionKey);CryptDecrypt(hKey, &Message);

Session key exchange

Symmetricencryption algorithm

Public Keyencryption algorithm

Receiver PublicKey

Message(plaintext)

Session Key

xxxxxxxxxxxxxxxxxxxxx

Encryptedmessage(cipher)

Symmetricdecryption algorithm

Public Keydecryption algorithm

Session Key

Encryptedsession

key(KeyBlob)

Message(plaintext)

Receiver PrivateKey

Backward CompatibilityMatching Session Keys with Container Key

• What if we want to Import a key and not use CryptGenKata

• I encoded using “MySecretKey”? Can we match session key with container’s key?

• Answer: Exponent-of-One Transformation

Exponent-of-One

• As we’ve seen in the past slides, AT_SIGNATURE and AT_EXCHANGE are used to import a public key and encode/decode session keys for other users.

• However, RSA encryption takes place by using:– If the message representative m is not between 0 and

n – 1, output “message representative out of range” and stop.

– Let c = me mod n.– Output c.

• It can be shown that e =1 will not generate any transformation.

Hardcoded session key = Key container key

1) Generate a Key pair (CryptGenKey)2) Export the session key from the key pair created (CryptExportKey).3) Since, this is a Private Key Blob, the key should be modified by applying an

exponent of one. A private key blob is represented by: PUBLICKEYSTRUC publickeystruc ;

RSAPUBKEY rsapubkey; BYTE modulus[rsapubkey.bitlen/8]; BYTE prime1[rsapubkey.bitlen/16]; BYTE prime2[rsapubkey.bitlen/16]; BYTE exponent1[rsapubkey.bitlen/16]; BYTE exponent2[rsapubkey.bitlen/16]; BYTE coefficient[rsapubkey.bitlen/16]; BYTE privateExponent[rsapubkey.bitlen/8]; This representation of a private key is the Chinese remainder theorem and

could be referenced in

4) Change exponent2, exponent 1 to 0x01 no transformation will occur when importing the key into the CSP.

5) Once the new key is set, the key is imported into the CSP by CryptImportKey(…) The CryptImportKey API allows the use of two HKEY values, the key itself

being imported, and a key used to make certain transformation (hPubKey, in Crypto API reference).

6) Any subsequent CryptImportKey calls can then use the key that does nothing to the key that’s being imported and both session and CSP keys match.

Conclusions

• Crypto API provides a mechanism to manage and storage keys, structured and isolated from users

• You can let the CSP maintain session keys and manage your key containers

• Public keys can be imported and session keys send to receivers

• Sessions and application keys can be match using the exponent-of-one transforamition. For obvious reasons this practice is NOT RECOMMENDED

• Additionally Certificates management can be incorporated to key containers, as well as retrieval of data from Smartcards becomes trivial.

Questions

• Thanks.