dxdt.ru: занимательный интернет-журнал

Про перехват TLS я уже писал, например, применительно к HTTPS, а также касательно некоторых технических особенностей, обеспечивающих прозрачность перехвата TLS. Продолжим тему технических деталей. Пусть требуется пассивно читать трафик TLS, сервис-провайдер готов участвовать, но не имеет возможности предоставить внешний API для доступа к ключам, как быть? Есть известное решение, но оно требует некоторого бэкдора.

Идея состоит в том, чтобы значение ключа можно было восстановить из самого защищённого трафика. Напомню, что трафик TLS защищается при помощи симметричного шифра и сеансового ключа. В современных реализациях сеансовый ключ генерируется сторонами по протоколу Диффи-Хеллмана (классического или на эллиптических кривых), который и обеспечивает защиту сессии. Какие секретные параметры нужно знать, чтобы вычислить сеансовый ключ? Такой параметр лишь один – это экспонента Диффи-Хеллмана (DH), используемая сервером (или экспонента клиента). Действительно, если прослушивающая канал сторона знает экспоненту (являющуюся в протоколе Диффи-Хеллмана секретным ключом сервера), то она может вычислить общий сеансовый ключ так же, как это делает сервер или клиент. Осталось понять, как можно передать значение экспоненты, например, с сервера “в эфир”, чтобы не догадались те, кто канал не должен прослушивать. Для этого в TLS есть целый ряд способов. Самый простой – это поле ServerRandom, которое содержит случайное значение длиной в 32 байта (256 бит) и передаётся в открытом виде. В этом поле может быть передано состояние генератора псевдослучайных чисел, который используется для выбора значения секретного значения протокола Диффи-Хеллмана. Зная состояние генератора – третья сторона сможет определить это секретное значение.

Осталось придумать, как сохранить в секрете возможность прослушивания – чтобы расшифровать данные мог только тот, “кому следует”. Для этого оператору сервера передаётся открытый ключ (например, в качестве типового параметра настроек), который он использует для зашифрования состояния генератора, перед тем, как передать его в поле ServerRandom на всеобщее обозрение. Кстати, 256 бит – это слишком мало для RSA, но вполне достаточно для эллиптических кривых, поэтому в качестве механизма защиты может использоваться какая-нибудь разновидность криптосистемы Эль-Гамаля на эллиптических кривых. Считается, что именно этот способ предполагался на роль бэкдора в нашумевшем случае DUAL_EC_DRBG. Естественно, зашифрованный параметр в ServerRandom практически неотличим от случайного числа – чтобы что-то понять, нужно знать секретный ключ, который неизвестен даже серверу-источнику перехватываемого трафика. (Передача ключей в ServerRandom – не единственный способ.)

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

Адрес записки: https://dxdt.ru/2016/04/04/7893/