Online Documentation Server
 ПОИСК
ods.com.ua Web
 КАТЕГОРИИ
Home
Programming
Net technology
Unixes
Security
RFC, HOWTO
Web technology
Data bases
Other docs

 


 ПОДПИСКА

 О КОПИРАЙТАХ
Вся предоставленная на этом сервере информация собрана нами из разных источников. Если Вам кажется, что публикация каких-то документов нарушает чьи-либо авторские права, сообщите нам об этом.




  • Проект дороги
    Карты дорог. Журналистский проект. Обзоры проектов агентства
    mydor.ru

Previous page | Next page | Contents

Cryptographic computations

The key exchange, authentication, encryption, and MAC algorithms are determined by the cipher_suite selected by the server and revealed in the server hello message.

8.1 Asymmetric cryptographic computations

The asymmetric algorithms are used in the handshake protocol to authenticate parties and to generate shared keys and secrets.

For Diffie-Hellman, RSA, and Fortezza, the same algorithm is used to convert the pre_master_secret into the master_secret. The pre_master_secret should be deleted from memory once the master_secret has been computed.

master_secret =
        MD5(pre_master_secret + SHA('A' + pre_master_secret +
            ClientHello.random + ServerHello.random)) +
        MD5(pre_master_secret + SHA('BB' + pre_master_secret +
            ClientHello.random + ServerHello.random)) +
        MD5(pre_master_secret + SHA('CCC' + pre_master_secret +
            ClientHello.random + ServerHello.random));

8.1.1 RSA

When RSA is used for server authentication and key exchange, a 48-byte pre_master_secret is generated by the client, encrypted under the server's public key, and sent to the server. The server uses its private key to decrypt the pre_master_secret. Both parties then convert the pre_master_secret into the master_secret, as specified above.

RSA digital signatures are performed using PKCS #1 [PKCS1] block type 1. RSA public key encryption is performed using PKCS #1 block type 2.

8.1.2 Diffie-Hellman

A conventional Diffie-Hellman computation is performed. The negotiated key (Z) is used as the pre_master_secret, and is converted into the master_secret, as specified above.

Note: Diffie-Hellman parameters are specified by the server, and may be either ephemeral or contained within the server's certificate.

8.1.3 Fortezza

A random 48-byte pre_master_secret is sent encrypted under the TEK and its IV. The server decrypts the pre_master_secret and converts it into a master_secret, as specified above. Bulk cipher keys and IVs for encryption are generated by the client's token and exchanged in the key exchange message; the master_secret is only used for MAC computations.

8.2 Symmetric cryptographic calculations and the CipherSpec

The technique used to encrypt and verify the integrity of SSL records is specified by the currently active CipherSpec. A typical example would be to encrypt data using DES and generate authentication codes using MD5. The encryption and MAC algorithms are set to SSL_NULL_WITH_NULL_NULL at the beginning of the SSL Handshake Protocol, indicating that no message authentication or encryption is performed. The handshake protocol is used to negotiate a more secure CipherSpec and to generate cryptographic keys.

8.2.1 The master secret

Before secure encryption or integrity verification can be performed on records, the client and server need to generate shared secret information known only to themselves. This value is a 48-byte quantity called the master secret. The master secret is used to generate keys and secrets for encryption and MAC computations. Some algorithms, such as Fortezza, may have their own procedure for generating encryption keys (the master secret is used only for MAC computations in Fortezza).

8.2.2 Converting the master secret into keys and MAC secrets

The master secret is hashed into a sequence of secure bytes, which are assigned to the MAC secrets, keys, and non-export IVs required by the current CipherSpec (see Appendix A.7).

CipherSpecs require a client write MAC secret, a server write MAC secret, a client write key, a server write key, a client write IV, and a server write IV, which are generated from the master secret in that order. Unused values, such as Fortezza keys communicated in the KeyExchange message, are empty. The following inputs are available to the key definition process:

        opaque MasterSecret[48]
        ClientHello.random
        ServerHello.random

When generating keys and MAC secrets, the master secret is used as an entropy source, and the random values provide unencrypted salt material and IVs for exportable ciphers.

To generate the key material, compute

key_block =
        MD5(master_secret + SHA('A' + master_secret + ServerHello.random +
            ClientHello.random)) +
        MD5(master_secret + SHA('BB' + master_secret + ServerHello.random +
            ClientHello.random)) +
        MD5(master_secret + SHA('CCC' + master_secret + ServerHello.random +
            ClientHello.random)) + [...];

until enough output has been generated. Then the key_block is partitioned as follows.

client_write_MAC_secret[CipherSpec.hash_size]
server_write_MAC_secret[CipherSpec.hash_size]
client_write_key[CipherSpec.key_material]
server_write_key[CipherSPec.key_material]
client_write_IV[CipherSpec.IV_size]                     /* non-export ciphers */
server_write_IV[CipherSpec.IV_size]                     /* non-export ciphers */

Any extra key_block material is discarded.

Exportable encryption algorithms (for which CipherSpec.is_exportable is true) require additional processing as follows to derive their final write keys:

final_client_write_key = MD5(client_write_key +
        ClientHello.random + ServerHello.random);
final_server_write_key = MD5(server_write_key +
        ServerHello.random + ClientHello.random);

Exportable encryption algorithms derive their IVs from the random messages:

client_write_IV = MD5(ClientHello.random + ServerHello.random);
server_write_IV = MD5(ServerHello.random + ClientHello.random);

MD5 outputs are trimmed to the appropriate size by discarding the least-significant bytes.

8.2.2.1 Export key generation example

SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for each of the two encryption keys and 16 bytes for each of the MAC keys, for a total of 42 bytes of key material. MD5 produces 16 bytes of output per call, so three calls to MD5 are required. The MD5 outputs are concatenated into a 48-byte key_block with the first MD5 call providing bytes zero through 15, the second providing bytes 16 through 31, etc. The key_block is partitioned, and the write keys are salted because this is an exportable encryption algorithm.

client_write_MAC_secret = key_block0..15
server_write_MAC_secret = key_block16..31
client_write_key        = key_block32..36
server_write_key        = key_block37..41

final_client_write_key = MD5 (client_write_key +
        ClientHello.random + ServerHello.random) 0..15;
final_server_write_key = MD5 (server_write_key +
        ServerHello.random + ClientHello.random) 0..15;

client_write_IV = MD5(ClientHello.random + ServerHello.random) 0..7;
server_write_IV = MD5(ServerHello.random + ClientHello.random) 0..7;

Previous page | Next page | Contents



With any suggestions or questions please feel free to contact us