2. Лекция: "Общие критерии", часть Основные идеи 8

Скачать 3.7 Mb.

Название	2. Лекция: "Общие критерии", часть Основные идеи 8
страница	14/22
Тип	Лекция

filling-form.ru > бланк строгой отчетности > Лекция

1 ... 10 11 12 13 14 15 16 17 ... 22

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

Основные идеи и понятия протокола TLS

Мы приступаем к рассмотрению протокола безопасности транспортного уровня (Transport Layer Security, TLS) (см. [42]), в котором получили дальнейшее развитие понятия, изложенные в версии 3.0 популярного протокола Secure Socket Layer (SSL) корпорации Netscape.

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

TLS имеет двухуровневую организацию. На первом (нижнем) уровне, опирающемся на надежный транспортный сервис, каковой предоставляет, например, TCP, располагается протокол передачи записей (TLS Record Protocol), на втором (верхнем) - протокол установления соединений (TLS Handshake Protocol). Строго говоря, протокол безопасности транспортного уровня располагается между транспортным и прикладным уровнями. Его можно отнести к сеансовому уровню эталонной модели ISO/OSI.

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

Протокол установления соединений позволяет серверу и клиенту провести взаимную аутентификацию, согласованно выбрать алгоритм шифрования и криптографические ключи перед тем, как прикладной протокол начнет передачу данных. Для аутентификации сторон применяются методы криптографии с открытым ключом(см. [91]), при выработке совместных секретов обеспечивается конфиденциальность и целостность, в том числе защита от нелегального посредника.

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

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

В спецификациях TLS фигурируют четыре криптографические операции: цифровая подпись, потоковое шифрование, блочное шифрование и шифрование открытым ключом. Все они, особенно асимметричное шифрование, способны поглотить много процессорного времени. Для решения этой проблемы определенное внимание уделено вопросам эффективности, минимизации нагрузки на процессор и сеть: предлагаемая схема кэширования в рамках сеанса уменьшает число соединений, устанавливаемых "с нуля".

В последующих разделах подробно рассматриваются составляющие протокола 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.1. Начальная структура блока протокола передачи записей. (html, txt)

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

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

struct {

ContentType type;

/* Тот же, что и TLSPlaintext.type */

ProtocolVersion version;

/* Та же, что и TLSPlaintext.version */

uint16 length;

opaque fragment [TLSCompressed.length];

} TLSCompressed;

Листинг 10.2. Структура блока протокола передачи записей после сжатия. (html, txt)

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

key_block = PRF

(SecurityParameters.master_secret,

"key expansion",

SecurityParameters.server_random +

SecurityParameters.client_random);

/* PRF - псевдослучайная функция */

/* "+" обозначает операцию конкатенации */

Листинг 10.3. Вычисление ключевого блока в протоколе передачи записей. (html, txt)

Затем ключевой блок делится на порции, служащие клиенту и серверу ключами хэш-функций и шифрования, а также начальным вектором (см. листинг 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.4. Параметры криптографических операций протокола передачи записей. (html, txt)

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

HMAC_hash (MAC_write_secret, seq_num +

TLSCompressed.type +

TLSCompressed.version +

TLSCompressed.length +

TLSCompressed.fragment));

Листинг 10.5. Вычисление имитовставки в протоколе передачи записей. (html, txt)

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

На четвертом шаге выполняется шифрование блока вместе с имитовставкой (см. листинг 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;

Листинг 10.6. Шифрование блока вместе с имитовставкой в протоколе передачи записей. (html, txt)

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

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

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

Протокол установления соединений и ассоциированные протоколы

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

На рис. 10.1 показан процесс формирования сеанса. Звездочками помечены необязательные сообщения, в квадратные скобки заключено сообщение протокола смены параметров шифрования.

Рис. 10.1. Процесс формирования сеанса

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

Новое соединение на основе существующего сеанса формируется более экономным образом (см. рис. 10.2).

Рис. 10.2. Формирование нового соединения на основе существующего сеанса

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

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

Приветственное сообщение клиента, открывающее процесс формирования сеанса или соединения, выглядит следующим образом (см. листинг 10.7).

struct {

uint32 gmt_unix_time;

opaque random_bytes [28];

} Random;
struct {

ProtocolVersion client_version;

Random random;

SessionID session_id;

CipherSuite cipher_suites<2..2^16-1>;

CompressionMethod

compression_methods<1..2^8-1>;

} ClientHello;

Листинг 10.7. Структура приветственного сообщения клиента в протоколе установления соединений. (html, txt)

Если идентификатор сеанса (session_id) пуст, имеется в виду формирование нового сеанса; в противном случае устанавливается новое соединение в рамках существующего сеанса. Поля compression_methods и cipher_suites содержат списки предлагаемых клиентом алгоритмов сжатия и криптографии (в порядке убывания приоритетов). Они должны быть построены так, чтобы согласие между клиентом и сервером было заведомо возможным. В частности, в списке алгоритмов сжатия должен фигурировать пустой метод.

Сервер отвечает клиенту собственным приветствием, главное в котором - выбранные алгоритмы сжатия и криптографии (см. листинг 10.8).

struct {

ProtocolVersion server_version;

Random random;

SessionID session_id;

CipherSuite cipher_suite;

CompressionMethod compression_method;

} ServerHello;

Листинг 10.8. Структура приветственного сообщения сервера в протоколе установления соединений. (html, txt)

Если клиент представил непустой идентификатор сеанса, сервер ищет его в своем кэше и при возможности и желании возобновляет сеанс, формируя на его основе (по сокращенному варианту, показанному на рис. 10.2) новое соединение. В противном случае организуется еще один сеанс, быть может, анонимный (с пустым идентификатором) и, следовательно, невозобновляемый.

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

Если сертификат сервера не посылался или содержащихся в нем данных недостаточно, сервер должен отправить свой ключевой материал в отдельном сообщении. При желании сервер может запросить сертификат клиента.

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

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

Структура сообщения о завершении формирования сеанса (соединения) показана на листинге 10.9.

struct {

opaque verify_data[12];

} Finished;
Finished.verify_data = PRF (master_secret,

finished_label, MD5(handshake_messages) +

SHA-1(handshake_messages)) [0..11];
/* Хэшируются все сообщения, участвовавшие в */

/* установлении соединения */

/* Значениями параметра "finished_label"

/* служат, соответственно, цепочка символов */

/*"client finished" на стороне клиента */

/* и "server finished" на стороне сервера. */

Листинг 10.9. Структура сообщения о завершении формирования сеанса в протоколе установления соединений. (html, txt)

Мастер-секрет вычисляется единообразно для всех методов выработки ключей ( см. листинг 10.10).

master_secret = PRF

(pre_master_secret,

"master secret",

ClientHello.random + ServerHello.random)

[0..47];

Листинг 10.10. Вычисление мастер-секрета. (html, txt)

Участвующий в процессе формирования сеанса протокол смены параметров шифрования устроен предельно просто и заключает в себе один тип однобайтных сообщений.

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

Применение протокола HTTP над TLS

Применение протокола HTTP над TLS описано в спецификациях [76]. С концептуальной точки зрения, оно организовано весьма просто. HTTP/TLS-сервер слушает порт 443. HTTP/TLS-клиент, являясь, в частности, TLS-клиентом, начинает процесс установления соединения с посылки приветственного сообщения. По сформированному TLS-соединению направляются обычные HTTP-запросы и ответы на них, которые трактуются протоколом TLS как прикладные данные.

В уникальном идентификаторе ресурсов (URI) сочетание HTTP/TLS обозначается как "https":

https://www.example.com/home.html

Обычно после анализа URI клиент узнает имя хоста, на котором функционирует сервер. Это имя должно быть сопоставлено с тем, которое фигурирует в сертификате сервера. Если сервер задан IP-адресом, тот же адрес должен присутствовать в сертификате и подвергаться проверке.

В качестве сигнала окончания взаимодействия используется уведомление о завершении сеанса.