Протокол TLS и&nb p; российские алгоритмы

Протоколы обеспечения аутентичности и конфиденциальности могут использоваться в двух режимах: транспортном и туннельном. В первом случае защищается только содержимое пакетов и, быть может, некоторые поля заголовков. Как правило, транспортный режим используется хостами. В туннельном режиме защищается весь пакет — он инкапсулируется в другой IP-пакет. На транспортном уровне аутентичность, конфиденциальность и целостность потоков данных обеспечивается протоколом TLS (Transport Layer Security, RFC 2246).

 

 

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

TLS — дальнейшее развитие протокола SSLTLS — это протокол, который был введен в действие на основе протокола SSL организацией IETT, подготовившей соответствующий стандарт. Он обеспечивает возможность повторного подключения без повторной аутентификации и согласования ключей сеанса. Обеспечивается согласование допустимых алгоритмов генерирования ключей (DH), шифрования (3DES-CBC, RC2, RC4, IDEA, DES, Triple-DES, AES, Blowfish), цифровой подписи и аутентификации (DSS, RSA, анонимный доступ с последующей дополнительной аутентификацией), хеширования (SHA-1, MD5).

Протокол имеет два уровня: протокол записей TLS и протокол диалога TLS. На нижнем уровне, работающем поверх надежного транспортного протокола (например, TCP [TCP]), размещается протокол записей TLS. Этот протокол обеспечивает безопасность соединений, которые имеют два основных свойства:

• Соединение является конфиденциальным. Для шифрования данных используется симметричная криптография (например, DES [DES], RC4 [RC4] и так далее). Ключи для шифрования генерируются независимо для каждого соединения и базируются на секретном коде, получаемом с помощью другого протокола (такого, как протокол диалога TLS). Протокол записей может использоваться и без шифрования.
• Соединение является надежным. Процедура передачи сообщения включает в себя проверку целостности с помощью вычисления MAC. Для расчета >MAC используются хеш-функции (например, SHA, MD5 и так далее). Протокол записей может работать и без MAC, но в этом режиме он применяется только в случае, когда другой протокол использует протокол записей в качестве транспортного при выяснении параметров безопасности.

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

Стандартный TLS не предусматривает поддержки российских алгоритмовВ соответствии со стандартом RFC 2246, протокол TLS поддерживает различные алгоритмы шифрования, широко распространенные в мире. Но не поддерживает российские алгоритмы. В связи с этим возникают проблемы использования этого протокола в ситуациях, когда требуется выполнение регламентирующих документов ФАПСИ по использованию сертифицированных алгоритмов. В числе таких документов следующие:

• ГОСТ 28147-89 — "Системы обработки информации. Защита криптографическая".
• ГОСТ Р 34.11 — "Информационная технология. Криптографическая защита информации. Функция хеширования".
• ГОСТ Р 34.10-94 — "Информационная технология. Криптографическая защита информации. Система электронной цифровой подписи на базе асимметричного криптографического алгоритма".
• ГОСТ Р34.10-2001 — "Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи".

Для решения вопросов поддержки протоколом TLS российских алгоритмов в 2002-м году ряд компаний, занимающихся разработкой систем защиты информации, электронной цифровой подписи, объединили свои усилия и подписали соглашение о сотрудничестве. В числе этих компаний были ФГУП НТЦ «Атлас», ООО "Крипто-Про", ООО "Фактор-ТС", ЗАО «МО ПНИЭИ» и ОАО «Инфотекс», ЗАО "Санкт-Петербургский региональный центр защиты информации", ООО «Криптоком», ООО "Р-Альфа", «КриптоПРО». Компании договорились об объединении усилий в целях достижения совместимости криптографических продуктов, разработки рекомендаций по стандартизации форматов сертификатов открытых ключей, списков отозванных сертификатов, криптографических сообщений с учетом использования российских алгоритмов.

В рамках «Соглашения о совместимости СКЗИ» были разработаны пять проектов информационных документов. Первые версии трех из них были представлены сотрудником компании "Крипто-Про" в июле 2003 года на 57-ой конференции IETF в Вене и с интересом встречены интернет-сообществом. Два документа уже получили статус документов рабочих групп IETF.

Решение по поддержке российских криптоалгоритмов стало дополнением к RFC 2246Один из них представляет интерес в рамках рассматриваемого вопроса. Это — проект "Addition of GOST Ciphersuites to Transport Layer Security (TLS)", который является дополнением к спецификации RFC 2246 в части описания применения российских алгоритмов. Документ описывает четыре механизма, реализующих ключевые протоколы при использовании открытых ключей ГОСТ Р 34.10-94 и ГОСТ Р 34.10-2001. Первая пара использует шифрование ГОСТ 28147-89 и контроль целостности с помощью имитовставки, вторая пара не использует шифрования и контролирует целостность с помощью ключевого хеша (MAC) на основе алгоритма ГОСТ Р 34.11-94.

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

Одно из решений предложено компанией «Новый Адам», выпустившей «Удостоверяющий центр сертификатов цифровой подписи Инега УЦ». Создаваемые в нем сертификаты могут участвовать в организации защищенного соединения по протоколу Transport Layer Security (TLS) (RFC 2246 The TLS Protocol Version 1.0.) с российскими криптографическими алгоритмами (хеш-функция — ГОСТ Р34.11-94, подпись — ГОСТ Р34.10-94, шифрование и выработка имитовставки — ГОСТ 28147-89).

Свое решение предлагает и компания «КриптоПРО». Модуль поддержки сетевой аутентификации «КриптоПро TLS», входящий в состав СКЗИ «КриптоПро CSP», реализует протокол Transport Layer Security (TLS v. 1.0, RFC 2246) с использованием российских криптографических стандартов. Протокол TLS предназначен для обеспечения криптографическими средствами аутентификации отправителя (клиента) — адресата (сервера), контроля целостности и шифрования данных информационного обмена. В механизме защиты реализации протокола TLS (аутентификация клиента и сервера, шифрование информации, контроль целостности информации) применяются криптографические алгоритмы шифрования в соответствии с ГОСТ 28147-89, обмена ключей по алгоритму Диффи-Хеллмана, хеширования в соответствии с ГОСТ Р 34.11-94.

Модуль поддержки сетевой аутентификации "Крипто-Про TLS" функционирует совместно со средством криптографической защиты информации (СКЗИ) «КриптоПро CSP» в операционных средах Windows 95, Windows 95 OSR2, Windows 98. Windows 98 SE, Windows ME, Windows NT 4.0, Windows 2000/ XP. А для операционных систем Linux, FreeBSD, а также Windows аналогичный продукт, полностью совместимый с "Крипто-Про TLS", разработала компания «Цифровые технологии». Он называется Trusted TLS и представляет собой доработанное программное решение ModSSL, позволяющее использовать российские стандарты криптографической защиты информации в веб-сервере Apache. В качестве сертифицированных ГОСТ алгоритмов используются российские стандарты шифрования.

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

И хотелось бы затронуть еще один момент, связанный с использованием защищенных протоколов. Всегда ли можно доверять сервисам, которые их применяют? Компания Microsoft предупреждает, что верить можно далеко не в каждом случае. По этому поводу ею был выпущен специальный документ — «Как обнаруживать опасные веб-узлы и гиперссылки и защищаться от них». В нем, в частности, говорится следующее.

"Чтобы защититься от подложных веб-узлов, необходимо выполнять следующие инструкции:

• перед отправкой важной информации убедитесь, что веб-узел использует протокол SSL/TLS (Secure Sockets Layer/Transport Layer Security), и проверьте имя сервера. Как правило, протокол SSL/TLS применяется для шифрования данных при пересылке через Интернет. Кроме того, с его помощью можно проверить, что данные передаются на нужный сервер. Имя сервера, на котором размещается текущая веб-страница, можно проверить по соответствующему имени пользователя цифрового сертификата SSL/TLS. Для этого необходимо, чтобы в правом нижнем углу окна обозревателя Internet Explorer появился значок в виде замка.
• чтобы проверить имя сервера на цифровом сертификате, дважды щелкните значок замка и запомните имя рядом с надписью «Кому выдан». Не отправляйте важные данные или данные, содержащие личные сведения, на веб-узлы, которые не используют протокол SSL/TLS. Если имя в поле «Кому выдан» отличается от имени веб-узла, на котором предположительно должна размещаться просматриваемая веб-страница, закройте окно обозревателя и покиньте данный узел".

Какой из этого можно сделать вывод? Доверяйте тем веб-узлам, использующим доступ по протоколу TLS, которые вы знаете. Не передавайте конфиденциальную информацию на те узлы, в которых вы сомневаетесь. И, конечно, проверяйте подпись на сертификате узла, чтобы удостовериться в его подлинности.

Ссылки по теме

• Совместимость средств криптографической защиты информации различных производителей
• TLS протокол

Статья получена: hostinfo.ru

загрузка...