Спецификация Internet-сообщества TLS

Протокол передачи записей

В общем виде функционирование протокола передачи записей можно представлять себе следующим образом. Сообщение, поступившее для передачи с более высокого протокольного уровня, включает длину, тип и содержимое. Оно разбивается на блоки (записи), допускающие эффективную обработку (или, наоборот, в один блок объединяется несколько небольших однотипных сообщений), сжимается, снабжается имитовставкой, шифруется, затем результат передается. На стороне получателя принятые данные расшифровываются, верифицируются, подвергаются декомпрессии и сборке, и затем сообщение доставляется клиенту на вышележащем протокольном уровне.

Спецификациями TLS предусмотрено четыре вышележащих клиента протокола передачи записей:

• протокол установления соединений;
• протокол оповещения (alert protocol);
• протокол смены параметров шифрования (change cipher spec protocol);
• протокол передачи прикладных данных (application data protocol).

Функции этих протоколов будут рассмотрены в следующем разделе.

С точки зрения протокола передачи записей, каждое соединение является двунаправленным и может находиться в одном из двух состояний: обработки (т. е. быть текущим) и ожидания (быть отложенным). Кроме того, состояние соединения характеризуется применяемыми алгоритмами (сжатия, шифрования, вычисления имитовставки) и их параметрами (секретными ключами и начальными векторами. Наконец, каждому соединению соответствуют четыре экземпляра состояния: по два на клиентской и серверной сторонах (любая из них может передавать и принимать данные).

Перечислим и другие элементы состояния соединения:

• мастер-секрет - 48-байтное значение, разделяемое партнерами по общению и служащее для выработки других общих секретов (ключей шифрования и т.п.);
• два 32-байтных случайных значения, одно из которых предоставляется сервером, а другое - клиентом, но оба участвуют в выработке ключей и начальных векторов;
• два 64-битных порядковых номера передаваемой записи (по одному на сторонах отправителя и получателя) с нулевым начальным значением.

Первоначальное состояние - ожидания - создает протокол установления соединений ; он же ведает переводом отложенных соединений в текущие и наоборот.

Формально процесс обработки данных протоколом передачи записей можно описать как последовательность преобразований структур (в спецификациях [ 42 ] для этой цели используется интуитивно понятный C-подобный язык).

На первом шаге выполняется фрагментация (или объединение однотипных) сообщений, предназначенных для передачи, в структуры TLSPlaintext размером не более 16384 байт (см. листинг 10.1).

enum {
  change_cipher_spec(20), alert(21), 
  handshake(22), application_data(23), (255)
} ContentType;

struct {
  ContentType type;
  ProtocolVersion version;
  uint16 length;
  opaque fragment [TLSPlaintext.length];
} TLSPlaintext;

Типы сообщений, поступающих с вышележащих уровней протоколу передачи записей, могут чередоваться, а сами сообщения - создавать очереди. В таком случае прикладные данные имеют наименьший приоритет.

На втором шаге выполняется сжатие данных (естественно, без потери информации). Оно приводит к появлению следующей структуры (см. листинг 10.2).

struct {
  ContentType type;		
  /* Тот же, что и TLSPlaintext.type */
  
  ProtocolVersion version;	
  /* Та же, что и TLSPlaintext.version */
  
  uint16 length;
  opaque fragment [TLSCompressed.length];
} TLSCompressed;

Далее следуют криптографические операции. К этому моменту на основе мастер-секрета и случайных значений, предоставленных сервером и клиентом, должен быть сгенерирован ключевой блок достаточной длины (см. листинг 10.3).

key_block = PRF 
    (SecurityParameters.master_secret,
     "key expansion", 
     SecurityParameters.server_random +
     SecurityParameters.client_random);
	
/* PRF - псевдослучайная функция */
/* "+" обозначает операцию конкатенации */

Затем ключевой блок делится на порции, служащие клиенту и серверу ключами хэш-функций и шифрования, а также начальным вектором (см. листинг 10.4).

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]

/* MAC - Message Authentication Code, */
/* аутентификационный код сообщения */
/* IV - Initialization Vector, */
/* начальный вектор */

С помощью сформированных параметров криптографических операций выполняется третий шаг протокола передачи записи, состоящий в вычислении имитовставки (см. листинг 10.5).

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

Обратим внимание, что в состав аргумента хэш-функции входит порядковый номер записи для защиты от кражи, дублирования и переупорядочения сообщений.

На четвертом шаге выполняется шифрование блока вместе с имитовставкой (см. листинг 10.6).

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

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

struct {
  ContentType type;
  ProtocolVersion version;
  uint16 length;
  select (CipherSpec.cipher_type) {
    case stream: GenericStreamCipher;
    case block: GenericBlockCipher;
  } fragment;
} TLSCiphertext;

На стороне получателя действия выполняются в обратном порядке:

• расшифрование;
• контроль целостности;
• декомпрессия;
• сборка сообщений.

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