Протокол SSL

Возможное решение - использование специального протокола для создания защищенного канала между двумя связывающимися сторонами (клиентом и сервером). К таким протоколам относятся Secure Sockets Layer protocol (SSL) и протокол TLS. Кроме создания канала, они обеспечивают шифрование и аутентификацию в течение одного сеанса, служат промежуточным слоем между протоколом сетевого уровня (TCP/IP) и протоколом уровня приложения (к примеру, HTTP). TLS/SSL обеспечивает аутентификацию сервера и необязательную аутентификацию клиента. Эти протоколы поддерживают большое число специальных алгоритмов, используемых для криптования, создания дайджестов и подписей. Они позволяют делать выбор алгоритмов с учетом требуемой надежности, соответствия принятому законодательству и иным факторам.

Наибольшее применение протокол TLS/SSL получил в обеспечении защиты HTTP-коммуникаций. Защищенный вариант использует адреса (URL), начинающиеся не с http, а с https, и использует иной порт (по умолчанию - это порт 443). Поскольку TLS/SSL работает на транспортном уровне, то он не зависит от используемого протокола на прикладном уровне. Поэтому не только HTTP, но и FTP, TELNET и другие протоколы приложений могут располагаться поверх TLS/SSL и использовать возможности защищенного соединения.

TLS/SSL, помимо создания защищенного соединения, обеспечивает шифрование передаваемой информации. В этом процессе применяется два наиболее распространенных способа шифрования - с симметричным и с открытым ключом. Для передачи ключа сеанса используется шифрование с открытым ключом, а уже ключ сеанса используется для шифрования данных, передаваемых в обе стороны. Для каждого сеанса связи используется новый ключ, поэтому расшифровка ключа одного из сеансов не позволит получить доступ к данным другого сеанса.И все было бы хорошо - поддержка TLS/SSL есть в операционных системах Windows, имеется она и у веб-сервера Apache. И функции, которые возложены на эти протоколы, встроенными средствами систем обеспечиваются. И шифрование проводится с использованием различных алгоритмов, таких как RSA, TripleDES, MD5, DSA. Защищается как работа по протоколу HTTP, так и по другим протоколам уровня приложений, включая работу с почтовыми системами. Но здесь и начинаются проблемы. Пока речь идет о защите частных электронных документов, частной переписки, особых претензий со стороны каких-либо контролирующих организаций не возникает. Но как только вопрос касается защиты финансовых, коммерческих и иных документов, мы сталкиваемся с требованиями, заложенными в Положениях и Законах РФ о цифровой подписи, электронных документах и сертификации криптографических алгоритмов.

Более чем вероятно, что распространенные за рубежом алгоритмы шифрования не будут сертифицированы в России. Следовательно, юридической силы они иметь не будут. А это в свою очередь означает, что ни один суд не примет к рассмотрению спор между организациями, оспаривающими созданный, казалось бы, по всем правилам электронный документ, даже имеющий электронно-цифровую подпись. И совсем тяжело будет тем государственным организациям, которые обязаны обеспечивать защиту своей информации и при этом должны сертифицировать все элементы системы защиты, в том числе - средства криптозащиты.

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

Если говорить об операционных системах Microsoft, то порядок взаимодействия приложений с криптографическими модулями регламентирует документ, который называется Microsoft Cryptographic Application Programming Interface. Функции, описанные в нем, поддерживаются операционными системами Windows и содержатся в определенных модулях. Но эти модули не реализуют криптографические алгоритмы, а обращаются к другим модулям, называемым Cryptographic Service Providers (CSP). Одновременно в операционной системе можно установить несколько CSP. При первом обращении к криптографическому сервису прикладная программа выбирает, с каким именно модулем CSP она будет работать (это зависит от того, какие криптографические алгоритмы ей необходимы). Но для того чтобы новый модуль CSP, реализующий сертифицированные алгоритмы, мог работать в Windows, и к нему могли обращаться прикладные программы, его необходимо заверить цифровой подписью Microsoft. А кроме того, необходимо "убедить" прикладные программы использовать этот модуль в своей работе.

Среди других, эту задачу сумела решить компания "Крипто-Про", разработавшая и внедрившая криптографические средства, реализующие в соответствии со стандартом Microsoft CSP российские криптографические алгоритмы. Их разработки (криптопровайдер "КриптоПРО CSP" и модуль поддержки сетевой аутентификации "КриптоПро TLS") полностью соответствуют требованиям Microsoft и работают под различными операционными системами Windows. К стандартным приложениям, которые теперь могут использовать российские алгоритмы электронной цифровой подписи и шифрования, относятся: