Протокол TLS

Нуль или стандартный поточный шифр

Поточные шифры (включая BulkCipherAlgorithm.null) преобразуют структуры TLSCompressed.fragment в (или из) структуры TLSCiphertext. fragment.

stream-ciphered struct { opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];} GenericStreamCipher;

MAC генерируется как:

HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment));

где "+" означает объединение (слияние).

Заметим, что MAC вычисляется до шифрования. Поточный шифр преобразует весь блок, включая MAC. Для поточных шифров, которые не используют вектор синхронизации (такой, как RC4), состояние шифра записи используется в последующих пакетах. Если CipherSuite равен TLS_NULL_WITH_NULL_NULL, шифрование представляет собой операцию идентичного преобразования (т.e., данные не шифруются, а размер MAC равен нулю, что говорит о том, что MAC не применяется). TLSCiphertext.length равна TLSCompressed.length плюс CipherSpec.hash_size.

Блочный шифр CBC

Для блочных шифров (таких, как RC2 или DES), функции шифрования и MAC преобразуют структуры TLSCompressed.fragment в блоки структур TLSCiphertext.fragment или обратно.

block-ciphered struct {
                       opaque content[TLSCompressed.length];
                       opaque MAC[CipherSpec.hash_size];
                       uint8 padding[GenericBlockCipher.padding_length];
                       uint8 padding_length;
                       } GenericBlockCipher;

Длина шифрованных данных ( TLSCiphertext.length ) на единицу больше, чем сумма TLSCompressed.length, CipherSpec.hash_size и padding_length.

Если длина блока равна 8 байт, длина содержимого ( TLSCompressed.length ) равна 61 байту, а длина MAC равна 20 байтам, длина до заполнения составляет 82 байта. Таким образом, длина заполнения по модулю 8 должна быть равна 6, для того чтобы сделать полную длину четной, кратной 8 байтам (длина блока). Длина заполнения может быть 6, 14, 22 и т.д. до 254. Если бы длина заполнения была минимально необходимой (6), заполнитель имел бы 6 байтов, каждый из которых содержал число 6. Таким образом, последние 8 октетов GenericBlockCipher до блочного шифрования были бы xx 06 06 06 06 06 06 06, где xx последний октет MAC.

Для блочного шифра в режиме CBC (Cipher Block Chaining) вектор инициализации (IV) для первой записи генерируется с другими ключами и секретными кодами, когда параметры безопасности заданы. IV для последующих записей равен последнему блоку шифрованного текста предыдущей записи.

Протокол записей требует алгоритма для генерации ключей, IV и секретных кодов MAC из параметров безопасности, поставляемых протоколом диалога.

Мастерный секретный код (master secret) хэшируется в последовательность байтов, которая присваивается секретным кодам MAC, ключам и IV, требуемых текущим состоянием соединения. CipherSpecs требует чтобы клиент и сервер записали секретный код MAC, ключ и IV, которые сформированы из мастерного секретного кода в указанном порядке. Неиспользованные значения остаются пустыми.

Для генерации ключей вычисляется:

key_block = PRF(SecurityParameters.master_secret, "key expansion",
SecurityParameters.server_random + SecurityParameters.client_random);

до тех пор, пока не будет сформирован выходной код. Затем key_block позиционируется следующим образом:

client_write_MAC_secret[SecurityParameters.hash_size]
server_write_MAC_secret[SecurityParameters.hash_size]
client_write_key[SecurityParameters.key_material_length]
>server_write_key[SecurityParameters.key_material_length]
client_write_IV[SecurityParameters.IV_size]
server_write_IV[SecurityParameters.IV_size]

Значения client_write_IV и server_write_IV генерируются только для не экспортных блочных шифров. Для экспортируемых блочных шифров векторы инициализации генерируются позже, как это описано ниже. Любой лишний материал key_block отбрасывается.

Спецификация шифра требует 2 x 24 байтовых ключей, 2 x 20 байтовых секретных кодов MAC, и 2 x 8 байтов IV, для 104 байтов материала ключей.

Алгоритмы экспортируемого шифрования (для которого CipherSpec.is_exportable равно 'истинно') требуют дополнительной обработки для получения ключей записи, как это показано ниже:

final_client_write_key =
PRF(SecurityParameters.client_write_key,
             "client write key",
             SecurityParameters.client_random +
             SecurityParameters.server_random);
    final_server_write_key =
PRF(SecurityParameters.server_write_key,
             "server write key",
             SecurityParameters.client_random +
             SecurityParameters.server_random);

Алгоритмы экспортируемого шифрования получают свои IV исключительно из случайных кодов сообщений hello:

iv_block = PRF("", "IV block", 
   SecurityParameters.client_random + SecurityParameters.server_random);

Блок iv_block делится на два инициализационных вектора, как это делалось выше для key_block:

client_write_IV[SecurityParameters.IV_size]
server_write_IV[SecurityParameters.IV_size]

Заметим, что PRF используется в этом случае без секретного кода: это означает, что секретный код имеет длину нуль байт и не вносит ничего в хэширование PRF.

TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 требует пяти случайных байт для каждого из двух ключей шифрования и 16 байт для каждого ключа MAC, что составляет 42 байта ключевого материала. Выход PRF запоминается в key_block. Блок key_block делится, а ключи записи запоминаются, так как это алгоритм экспортного шифрования.

key_block                = PRF(master_secret,
                         "key expansion",
                         server_random +
                         client_random)[0..41]
client_write_MAC_secret  = key_block[0..15]
server_write_MAC_secret  = key_block[16..31]
client_write_key         = key_block[32..36]
server_write_key         = key_block[37..41]
final_client_write_key   = PRF(client_write_key,
                         "client write key",
                         client_random +
                         server_random)[0..15]
final_server_write_key   = PRF(server_write_key,
                         "server write key",
                         client_random +
                         server_random)[0..15]
iv_block                 = PRF("", "IV block", client_random +
                         server_random)[0..15]
client_write_IV          = iv_block[0..7]
server_write_IV          = iv_block[8..15]

Протокол диалога TLS

Протокол диалога TLS содержит набор из трех субпротоколов, которые применяются, чтобы партнеры могли согласовать используемые параметры безопасности для уровня записи, аутентифицировать себя, и уведомлять друг друга об ошибках.

Протокол диалога ответственен за согласования характеристик сессии, куда входят следующие объекты:

Эти объекты применяются затем для определения параметров безопасности уровня записей при защите прикладных данных. Многие соединения могут реализоваться в рамках той же сессии с помощью процедуры возобновления протокола диалога.