2020-10-09
800Лекция 2. Особенности применения шифрования электронной и цифровой подписи ipsec и ssl
Особенности использования вычислительной техники в криптографии.
Практическая криптография распространяется все шире вслед за развитием электронного документооборота, широкодоступных сетевых служб, обмена информацией через сети общего пользования. Средствами криптографической защиты информации (СКЗИ) решается множество задач, непосредственно связанных с обеспечением информационной безопасности любой системы, базы данных или сети передачи информации. Кроме того, существует ряд направлений, в которых применение СКЗИ практически не имеет альтернативы:
• защищенная электронная почта (электронный документооборот);
• обеспечение безопасности электронных транзакций (электронные платежи);
• виртуальные частные сети.
Со временем значение криптографии, по всей вероятности, возрастет. Однако приходится признать, что многие криптографические системы не обеспечивает того высокого уровня защищенности, о котором обычно говорится в рекламе. При этом криптографические системы редко взламываются чисто математическими методами, причиной проблем обычно становится не слабость структуры криптографического алгоритма или протокола, а недостатки его практической реализации.
Немало проблем, связанных с использованием криптографических средств, создают и пользователи, игнорирующие требования принятой политики безопасности.
Причины ненадежности практических реализаций криптосистем приведены на рис. 3.23.
Основные ошибки, допускаемые при практическом использовании криптоалгоритмов: недостаточная длина ключа, некачественная процедура управления ключами, некачественный генератор псевдослучайных чисел или неправильная его инициализация и, наконец, использование криптоалгоритмов не по назначению, а также использование на практике модели доверительных отношений, отличной от той, в расчете на которую проектировалась система.
Надежная система защиты должна уметь оперативно обнаруживать несанкционированные действия для минимизации возможного ущерба. В случае обнаружения повреждений в системе должны включаться эффективные процедуры восстановления разрушенных элементов. Система не должна потерять живучесть даже в случае проведения успешной атаки на нее.
Наиболее важным компонентом реализации любой криптографической системы является криптографический ключ. При использовании криптографических ключей необходимо соблюдать ряд принципов:
• недопущение компрометации (разглашения или возможности разглашения) секретных частей криптографической системы;
• комплексность (иерархии ключей, использование различных криптосистем для повышения надежности шифрования и процедуры распределения ключей);
• прозрачность (непричастность пользователей к формированию ключей и управлению ими).
Рис. 3.23. Причины ненадежности криптосистем
Несмотря на успехи современной криптографии, задача построения надежной системы криптографической защиты комплексная, она значительно сложнее, чем кажется на первый взгляд.
В качестве устройств шифрования наиболее широко используют три вида шифраторов:
1) программные;
2) аппаратные;
3) программно-аппаратные.
Их основное различие заключается не только в способе реализации шифрования и степени надежности защиты данных, но и в цене, что часто становится для пользователей определяющим фактором. Как правило, наиболее дешевое решение — программное, далее идут программно-аппаратные средства и, наконец, наиболее дорогостоящие — аппаратные. Однако хотя стоимость аппаратных шифраторов обычно существенно выше программных, она практически всегда окупается за счет более высокого качества защиты информации, несравнимого с разницей в цене.
Программные средства криптографической защиты. Программные СКЗИ представляют собой реализацию криптографического алгоритма на высоко- или низкоуровневом языке программирования. Обычно функционирование таких средств требует выполнения ряда вычислительных операций стандартными аппаратными средствами компьютерной системы.
Технология реализации криптоалгоритмов программными средствами имеет ряд особенностей:
• необходимость дополнительного контроля качества функционирования, поскольку в общем случае работу программного средства нарушить легче, чем его аппаратного аналога;
• возможность контроля ошибок в закрытом тексте при шифровании путем внедрения избыточности;
• необходимость обеспечения надежного хранения ключей, что достигается за счет использования иерархии ключей (использование мастер-ключа для шифрования ключей пользователей);
• возможность масштабирования и дополнения СКЗИ новыми программными блоками и модификациями существующих блоков;
• принципиальная возможность использования программного СКЗИ с открытым кодом, что допускается при шифровании информации в частных целях и облегчает построение общей схемы защиты информации.
Таким образом, программное СКЗИ отличает способность использования в открытых системах, более гибкая реализация, способность масштабирования и высокая мобильность.
Можно выделить следующие функции программных СКЗИ:
• идентификация и аутентификация пользователей;
• обеспечение криптографической защиты операционных систем и приложений, встроенной производителем;
• генерация псевдослучайных последовательностей;
• шифрование данных на диске, в том числе «прозрачное» шифрование;
• формирование и проверка ключей, электронных подписей, защита от копирования программного кода;
• обеспечение безопасной передачи секретного ключа при инициализации СКЗИ, в том числе и аппаратных.
Схема типового программного СКЗИ приведена на рис. 3.24.
Блок управления выполняет координацию функций различных компонентов СКЗИ, коммутацию модулей и внешних потоков информации, а также внешних команд. Компонентом взаимодействия с пользователем является интерфейс, который предоставляет возможности управления программной реализацией алгоритма, контроля функционирования. Модуль управления ключами выполняет задачи обработ
 |
ки ключевой информации, идентификации и аутентификации пользователей. Дополнительно используется идентификация устройств, которая может использоваться как элемент защитной подсистемы.
Генераторы случайных чисел, используемые в программных СКЗИ, также реализуются программно. Для этих целей применяются различные алгоритмы генерации псевдослучайных битовых последовательностей. Библиотеки программных средств криптографической защиты применяются при решении прикладных задач и настройке СКЗИ в зависимости от условий эксплуатации. Качество готовых библиотек криптографических функций подтверждается опытом применения в различных проектах и сертификатами соответствия. Использование подобных библиотек снижает риски внесения ошибок в программные реализации стойких алгоритмов шифрования, вызванные недостаточной квалификацией разработчиков.
Построение защищенных Windows-приложений. Доминирующее положение операционной системы Windows на рынке обусловливает внимание к программным интерфейсам библиотек криптографических функций (криптографическим интерфейсам) этой операционной системы — Crypto API, CNG API.
Application Programming Interfaces (API) — интерфейс программирования приложений, определяет функциональность, которую предоставляет программа (модуль, библиотека), при этом API позволяет абстрагироваться от того, как именно эта функциональность реализована.
Crypto API — это интерфейс программирования приложений, который предоставляет разработчикам Windows-приложений средства вызова криптографических функций. В основе шифрования Windows Vista, Windows Server 2008 и более поздних версий операционной системы лежит новый криптографический интерфейс, называемый CNG API (Cryptography Next Generation). Основными отличиями CNG API являются: отделение хранилищ ключей от операций алгоритма, изоляция процессов для операций с долговременными ключами, подключаемые генераторы случайных чисел, криптографический API режима ядра и отсутствие ограничений на экспорт.
Криптографические интерфейсы Windows, с одной стороны, позволяют включать но мере разработки новые функции, а с другой, не требуют после этого изменения и обновления всех ранее созданных приложений. Для реализации такого интерфейса выбрана структура пакета, в которой обращение к функциям API представляет собой уровень связи с приложениями, а за ним располагается другой уровень, открытый для обновления и включения новых функций в виде встраиваемых компонентов, в том числе и от независимых разработчиков. Эта структура иллюстрируется рис. 3.25.
Встраиваемый компонент, позволяющий осуществлять отдельные криптографические операции (шифрование, электронная подпись и т.д.) в операционной системе и реализующий криптографические алгоритмы, в терминологии Microsoft называется провайдером службы шифрования — CSP (Cryptographic Service Provider).
По своей сути криптопровайдеры CSP являются независимыми модулями (независимыми динамическими библиотеками DLL или вообще отдельными сервисами), предоставляющими криптографические функции пользовательским приложениям. Они подписаны цифровой подписью, так что система может проверять их подлинность. В составе операционной систе 
Рис. 3.25. Взаимодействие между приложением и провайдерами службы шифрования посредством Crypto API
мы Windows пользователь получает несколько таких CSP, которые реализуют наиболее часто используемые методы шифрования. Если разрабатываемое приложение нуждается в стороннем компоненте CSP, это никак не отражается на программировании самого приложения. Оно строится точно так же, как если бы в нем использовался один из «родных» компонентов Windows.
В такой структуре на криптографический интерфейс практически не возлагаются иные функции, кроме передачи сообщений между приложением и выбранными для приложения CSP. Поэтому при необходимости можно достаточно быстро настроить приложение на другой алгоритм шифрования, указав при вызове функций Crypto API новый компонент CSP.
Таким образом, еще одним достоинством криптографических интерфейсов Windows является возможность замены в уже разработанном приложении одной библиотеки криптографических функций на другую, более современную, созданную заслуживающей большего доверия организацией или реализующую более стойкие криптографические алгоритмы и протоколы. Причем эта замена может быть произведена без какой-либо переделки самой прикладной программы.
Криптопровайдеры CSP отличаются друг от друга своими типами, которые определяются набором параметров, включающим:
• алгоритм обмена сессионным (симметричным) ключом;
• алгоритм вычисления цифровой подписи;
• формат цифровой подписи;
• схему генерирования сессионного ключа по хэшу;
• длину ключа.
Разработан ряд криптопровайдеров, поддерживающих отечественные стандарты криптографических алгоритмов ГОСТ Р 34.10—2012, ГОСТ Р
34.11-2012, ГОСТ 28147-89 (КриптоПро CSP, ViPNet CSP, Shipka Base Cryptographic Provider GOST, Валидата CSP и др.) и имеющих сертификат ФСВ России. Использование этих криптопровайдеров позволяет соблюсти, если это необходимо, требование об обязательном использовании сертифицированных СКЗИ.
Архитектура Crypto API может быть разделена на три основные части:
1) базовые функции;
2) функции для работы с сертификатами;
3) функции для работы с сообщениями.
В первую группу входят функции для выбора и подключения к кринго- провайдеру, генерации и хранения ключей, обмена ключами, выбора режима алгоритмов блочного шифрования (СВС или ЕСВ), а также криптографическая функция генерации случайных данных. К базовым относятся также функции для хэширования и получения цифровой подписи данных, шифрования и расшифрования.
Во вторую группу входят функции для использования сертификатов, основной задачей которых является предоставление доступа к открытому ключу. Crypto API поддерживает сертификаты спецификации Х.509, в которые входит информация о версии сертификата, его серийном номере, периоде действия, алгоритмах шифрования публичного ключа.
Под сообщениями в Crypto API понимаются данные в стандартизованном формате PKCS #7, разработанном RSA Laboratories. Функции для работы с ними делятся на две части: высокоуровневые функции (упрощенные) и низкоуровневые.
Зачастую применение непосредственно функций Crypto API достаточно проблематично, например в web-клиентах, где вызовы процедур напрямую невозможны. Для подобных целей, а также для упрощения работы с Crypto API был создан тип объектов CAPICOM (Crypto API COM-object). В своей реализации данный объект почти полностью охватывает все — от шифрования до работы с сертификатами.
Платформа.NET Framework позволяет работать с функциями Crypto API (CNG API) в объектно-ориентированной среде посредством набора классов в пространстве имен System.Security.Cryptography. Пространство System.Security.Cryptography содержит основные симметричные шифры (DES, 3DES, AES, Rijndael, RC2) и асимметричные криптосистемы (RSA DSA ECDSA система Диффи — Хеллмана на эллиптических кривых), несколько хэш-функций (MD5, SHA-l, SHA-2, RIPEMD160), кодов аутентификации (HMAC-SHA-1, HMAC-SHA-2, HMAC-RIPEMD, MAC-3DES) п криптографически сильный генератор псевдослучайных чисел. Эта криптографическая основа может быть расширена за счет подключения CSP сторонних производителей. Расширения криптографической объектной модели.NET Framework могут быть двух типов: добавление новой реализации криптоалгоритма, уже определенного в.NET Framework, или добавление нового криптоалгоритма.
Пространство имен System.Security.Cryptography содержит следующие основные классы:
• SymmetricAlgorithm — симметричные шифры;
• AsymmetricAlgorithm — криптосистемы с открытым ключом;
• CryptoStream — поддерживает модель программирования на основе потоков (streams), представляющих данные из разных хранилищ (текстовых файлов, XML-документов, памяти, сети), при криптографических преобразованиях;
• CspParameters — передает параметры криптопровайдеру CSP, который выполняет криптографические преобразования;
• Hash Algorithm — функции хэширования и коды аутентификации;
• RandomNumberGenerator — генератор псевдослучайных последовательностей;
• классы Cryptography Next Generation (CNG) — для прямого вызова криптографических API-функций. Центральным является класс CngKey — хранение и использование CNG-ключей, также реализованы поддерживающие CNG-классы (CngProvider — провайдер хранилища ключей, CngAlgorithm и CngAlgorithmGroup — реализованные средствами CNG алгоритмы шифрования или группы алгоритмов (CngKey получает объекты CngAlgorithm через параметр Algorithm и возвращает объекты CngAlgorithmGroup), CngUlPolicy — политика пользовательского интерфейса, относящегося к операциям с ключами).
Перечисленные классы являются абстрактными базовыми классами, которые инкапсулируют другие классы, специфичные для конкретных криптоалгоритмов. Производные классы реализуют конкретные публичные свойства и виртуальные методы абстрактного базового класса в зависимости от используемого криптоалгоритма.
Пространство имен System.Security.Cryptography.XML реализует цифровую подпись XML-объектов, a System.Security.Gryptography.X509Certificaties обеспечивает поддержку операций с цифровыми сертификатами.
Аппаратные средства криптографической защиты.
Аппаратное СКЗИ — специализированный блок, компонент средства вычислительной техники или отдельное устройство, выполняющее криптографическое преобразование информации.
Кроме собственно шифрования аппаратное СКЗИ обычно выполняет функции управления ключами (генерация, хранение), также аппаратно могут быть реализованы контроль доступа и проверка целостности данных (на основе вычисления криптографических контрольных сумм и хзш- функций).
Использование аппаратных СКЗИ позволяет перенести все криптографические операции для всех приложений информационной системы из внешней недоверенной среды (например, незащищенной памяти) в защищенное окружение.
Аппаратная реализация алгоритма шифрования:
• гарантирует неизменность самого алгоритма, тогда как в программной алгоритм может быть намеренно модифицирован;
• исключает какое-либо вмешательство в процесс шифрования;
• позволяет использовать аппаратные датчики истинно случайных чисел, что повышает качество реализации различных криптографических алгоритмов;
• позволяет напрямую загружать ключи шифрования в шифропроцес- сор, минуя оперативную память компьютера, тогда как в программном шифраторе ключи находятся в памяти даже во время работы шифратора;
• разгружает центральный процессор компьютера за счет выполнения всех криптографических операций собственным шифропроцессором.
Не менее важен и тот факт, что па базе аппаратного шифратора можно создавать различные системы разграничения и ограничения доступа к компьютеру. Кроме того, можно отметить ряд других достоинств аппаратной реализации:
• надежность, позволяющая использовать средство криптографической защиты в критичных по надежности узлах автоматизированных систем;
• возможность реализации отдельным блоком, что зачастую позволяет более гибко строить топологию защищенной автоматизированной системы;
• исключение возможности программного повреждения ключей шифрования, что дает гарантию стабильности системы в целом.
Аппаратное средство криптографической защиты содержит ряд дополнительных блоков, которые не требуются в программной реализации (рис. 3.26):
• блок управления криптографическими ключами;
• генератор случайных чисел;
• память — постоянная и оперативная;
• блок синхронизации времени;
• устройство хранения и проверки контрольных сумм и хэш-значений;
• шифронроцессор.
Рис. 3.26. Базовая схема аппаратного С КЗ И
Шифропроцессор представляет собой специализированную микросхему с фиксированным набором команд или микросхему программируемой логики (PLD — Programmable Logic Device), которая выполняет шифрование данных. Также возможно использование отдельных специализированных блоков идентификации, аутентификации и авторизации (проверки и генерации электронной подписи).
Блок управления выполняет координацию функций различных компонентов СКЗИ, коммутацию устройств и внешних потоков, управление данными, передаваемыми по системной шине.
Память аппаратного средства подразделяется на два блока:
1) оперативная, хранящая программное обеспечение СКЗИ, а также все программируемые компоненты, изменяемые значения и пр.;
2) постоянная, содержащая набор команд, реализующих защитные функции и загрузку программного обеспечения СКЗИ.
Кроме того, могут выделяться два дополнительных блока памяти — память журнала регистрации событий и память храпения ключей.
Используемые в аппаратной реализации криптографической защиты генераторы случайных чисел основаны на различных физических процессах. Блок управления ключами выполняет прием, обработку и выдачу ключевой информации, а также, если это необходимо, функции идентификации и аутентификации. Блок синхронизации времени требуется в операциях контроля функционирования самого СКЗИ, при синхронизации потока данных, для расчета и согласования операций. Устройство ввода-вывода обеспечивает обработку сигналов, поступающих от внешних устройств (системной шины компьютерной системы либо приемно-передающего устройства линии передачи информации; устройств хранения ключевой информации, применяемых в задачах идентификации и аутентификации; контроллеров жестких дисков и устройств резервного копирования информации).
Таким образом, полнофункциональное аппаратное СКЗИ может являться даже специализированным компьютером, реализованным в виде аппаратного блока, внешнего или внутреннего, связанного с центральным процессором собственными каналами передачи данных (системной шиной).
Программно-аппаратное СКЗИ — специальным образом организованные комплексы, содержащие взаимосвязанные программные и аппаратные блоки и реализующие следующий набор функций:
• идентификацию и аутентификацию пользователей;
• криптографическое преобразование данных;
• обеспечение целостности информации.
Основной целью применения программно-аппаратных средств обеспечения информационной безопасности является усиление или замещение существующих функций защиты компьютерных систем для обеспечения требуемого уровня защищенности. Программно-аппаратные комплексы являются наиболее сложной и эффективной разновидностью СКЗИ.
Криптографическая защита в компьютерных сетях.
Шифрование является основным средством обеспечения конфиденциальности передаваемых по каналам связи данных. Криптографическая защита каналов передачи данных может быть реализована на следующих уровнях, для каждого из которых характерно использование определенных средств защиты и протоколов:
• физический уровень — специфической формой шифрования, реализуемой аппаратно и применимой только на физическом уровне, является защита передачи (защита по ширине частотного спектра);
• сетевой уровень — шифрование передаваемого между узлами трафика (например, протокол IPSec);
• уровень представления — шифрование данных, передаваемых между удаленными приложениями (например, протоколы SSL и TLS);
• прикладной уровень — самостоятельное шифрование данных приложениями.
Кроме того, криптографические методы и средства могут использоваться для решения задач аутентификации сторон информационного обмена, обеспечения аутентичности и неотрекаемости источника данных и целостности передаваемых данных.
Вопросы информационной безопасности распределенных систем (сетей) достаточно полно и глубоко трактуются в технической спецификации Х.800 Международного союза электросвязи, при этом шифрование и цифровая подпись рассматриваются в качестве ключевых механизмов безопасности. Данный документ лег в основу стандарта ISO 7498-2:1989 и отечественного гармонизированного стандарта ГОСТ Р ИСО 7498-2—1999 «Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 2. Архитектура защиты информации». Криптографические механизмы могут быть реализованы на разных уровнях эталонной модели взаимодействия сетей OSI, рекомендуемые Х.800 уровни реализации приведены в табл. 3.6. На прикладном уровне могут быть обеспечены все услуги безопасности.
Таблица 3.6
Связь между сервисами безопасности и уровнем шифрования (Х.800)
| Требование | Сервис безопасности | Уровень шифрования |
| Полная конфиденциальность потока трафика | Полная конфиденциальность | 1-й (физический уровень) |
| Высокая градация защиты (наличие потенциально отдельного ключа для каждой ассоциации приложений) | Целостность без восстановления, предотвращение отказа от авторства, селективная защита полей, полная конфиденциальность | 6-й (уровень представления) |
| Массовая защита всей связи между оконечными системами и (или) внешними устройствами шифрования | Конфиденциальность и целостность без восстановления | 3-й (сетевой уровень) |
| Целостность с восстановлением вместе с высокой градацией защиты | Конфиденциальность и целостность с восстановлением и без восстановления | 4-й (транспортный уровень) |
На самых нижних уровнях сетевой архитектуры (физическом и канальном) шифруются абсолютно все данные, проходящие по каналу связи, включая открытый текст сообщения и служебную информацию (заголовки, маршрут сообщения, информация об используемом коммуникационном протоколе). Такой вид шифрования обычно называется канальным {link encryption). Не шифруется только трафик управляющих сообщений канального уровня, который включает в себя команды и параметры, используемые различными канальными устройствами для синхронизации процесса коммуникаций. Канальное шифрование весьма эффективно, однако требует раскрытия данных (расшифровывания заголовков для получения служебной информации и повторного шифрования для дальнейшей передачи) в каждом промежуточном узле сети (например, на маршрутизаторе). Эта особенность требует дополнительной защиты всех коммуникационных узлов сети, что может существенно повысить стоимость реализации. Шифрование служебной информации, имеющей типовую структуру, может привести к появлению статистических закономерностей в шифро- текстах, облегчить криптоаналитику задачу определения используемых криптографических ключей. Примером защищенного протокола канального уровня является РРТР, использующийся в технологии VPN-туннелирования компании Microsoft.
Шифрование на верхнем уровне сетевой архитектуры (прикладном, уровне представления) обычно называется сквозным {end-to-end encryption). При сквозном шифровании данные остаются зашифрованными, пока не будут доставлены к месту назначения. Шифрование на прикладном уровне более гибко, так как оставляет пользователям (пользовательским приложениям) решение вопроса о необходимости шифрования тех или иных сообщений. В то же время криптоаналитик получает возможность анализа трафика, так как дополнительная информация (о маршрутизации, размере передаваемых сообщений, частоте обмена данными между конкретными абонентами, связи этого обмена с различными внешними событиями) остается открытой. Примером прикладного защищенного протокола является S/MIME, позволяющий пользователям шифровать и подписывать сообщения электронной почты.
Сетевые механизмы безопасности используют как симметричные, так и асимметричные криптосистемы. Обычно асимметричная схема служит для обеспечения аутентификации сторон и распределения сеансовых ключей, симметричные шифры — для непосредственного шифрования передаваемых данных. Использование асимметричных криптосистем требует сертификации открытых ключей и функционирования PKI-инфраструктуры (см. параграф 3.9). Далее рассмотрены наиболее известные сетевые протоколы защищенного обмена данными и аутентификации.
Протокол IPSec
Протокол IPSec (IP Security) — набор криптографических протоколов для обеспечения защиты передаваемых данных в IP-сетях. Протокол может функционировать на сетевом или транспортном уровне модели OSI. Использование протокола IPSec является преобладающим в реализациях виртуальных частных сетей (VPN-туннелей), на рынке представлены как программные, так и программно-аппаратные реализации этого протокола.
Протокол IPSec определяет:
• протоколы защиты передаваемого потока АН (Authentication Header) и ESP (Encapsulating Security Payload);
• параметры защищенного канала передачи данных SA (Security Associations), характеризующие соединение (например, используемые алгоритм шифрования, хэш-функция, секретные ключи, номер пакета и др.);
• протокол обмена криптографическими ключами IKE (Internet Key Exchange)]
• алгоритмы шифрования данных и аутентификации.
Протокол IPSec обеспечивает:
• аутентификацию сторон при создании защищенного канала;
• обеспечение конфиденциальности (шифрование) и целостности передаваемых данных;
• распределение ключей между сторонами.
Протокол IPSec не устанавливает обязательной поддержки каких-то определенных алгоритмов шифрования и обеспечения целостности данных, однако спецификация IPSec содержит рекомендованные алгоритмы, использование которых призвано обеспечить совместимость между различными реализациями протокола. Существуют реализации протокола, поддерживающие отечественные стандарты криптографической защиты информации (например, КриптоПро IPSec).
Для шифрования данных используется симметричное шифрование, реализуемое протоколом ESP. Рекомендуемым алгоритмом шифрования является DES в режиме сцепления блоков шифротекста СВС (DES-CBC). Более современные рекомендации IPSec позволяют использовать и другие алгоритмы блочного шифрования (AES, Triple DES, Blowfish, IDEA 3IDEA CAST, RC5), если они поддерживаются обеими сторонами взаимодействия. Конкретные криптоалгоритмы могут добавляться производителями, однако практически все современные реализации протокола поддерживают AES-шифрование (AES-СВС и AES-CTR). Кроме шифрования, ESP обеспечивает целостность пакетов, а также защиту от их повторной передачи (рекомендуемые криптографические алгоритмы для вычисления контрольной суммы — НМАС с функцией хэширования SHA-1 или MD5, в настоящее время может использоваться AES-XCBC-MAC). Сервисы аутентификации предоставляются опционально. Для аутентификации пакетов используются хэш-значения (I1MAC), а не цифровые подписи. Возможно отключение шифрования или аутентификации (но не обоих одновременно), в этом случае используется соответствующий пустой алгоритм (NULL algorithm).
Протокол АН обеспечивает целостность передаваемых данных и аутентификацию их источника и опционально — защиту от повторной передачи данных. Для вычисления контрольных сумм протокол АН использует те же алгоритмы, что и ESP (обычно НМАС- SHA1 или AES-XCBC-MAC).
Протоколы ESP и АН могут использоваться по отдельности или совместно, определены два режима их работы — туннельный и транспортный. Туннельный режим функционирует на сетевом уровне, подходит для построения виртуальных частных сетей (VPN) и предполагает шифрования всего исходного IP-пакета совместно с его последующей инкапсуляцией. Поскольку IPSec работает на уровне IP-протокола, созданный защищенный канал может использоваться протоколами более высоких уровней, например TCP/UDP или прикладные протоколы. Транспортный режим функционирует на более высоком уровне сетевой архитектуры, производится шифрование только данных 1 P-пакета, исходный заголовок не изменяется. Этот режим подходит для защиты туннелей, организованных другими средствами (например, L2TP).
Протокол IKE обеспечивает начальную аутентификацию сторон, а также распределение ключей. Формирование общего секретного ключа для сессии производится с использованием алгоритма Диффи — Хеллмана, аутентификация — с помощью цифровых сертификатов сторон (Х.509, обычно используются цифровые подписи RSA или ECDSA). Сначала производится согласование параметров SA (защищенного канала), затем формируется общий ключ с помощью системы Диффи — Хеллмана и лишь затем проводится аутентификация сторон взаимодействия. IPSec допускает возможность установки ключа сессии вручную без использования IKE, однако этот метод не рекомендуется и используется крайне редко.
Протоколы SSL/TLS — протоколы создания защищенного канала связи в клиент-серверных системах (между двумя приложениями, как правило, между клиентом и сервером в сети Интернет). Протоколы SSL/TLS работают поверх протоколов транспортного уровня, например TCP. В то же время они располагаются ниже прикладного уровня и не зависят от используемого прикладного протокола стека TCP/IP, поэтому могут использоваться совместно с любым из них (например, частое использование совместно с протоколом HTTP привело к появлению защищенного прикладного протокола HTTPS). Разные источники относят протоколы SSL/TLS либо к транспортному уровню, либо к уровню представления.
Протокол SSL
Протокол SSL (Secure Sockets Layer) разработай специально для обеспечения безопасной передачи данных по протоколу HTTP между узлами сети Интернет. Протокол обеспечивает конфиденциальность (за счет симметричного шифрования) и целостность (за счет использования кодов аутентификации) сообщений, а также аутентификацию сервера и необязательную аутентификацию клиента (за счет использования цифровых сертификатов). Протокол SSL поддерживается большинством интернет-браузеров, доминирующей является версия SSL 3.0. В настоящее время протокол SSL признан небезопасным, на его основе разработан более современный протокол TLS (Transport Layer Security), первая версия которого вышла в 1999 г. TLS не обеспечивает совместимости с SSL.
Протокол TLS состоит из двух протоколов, имеющих различное назначение:
1) TLS Handshake Protocol — установление защищенного сеанса связи, взаимная аутентификация приложений и безопасный обмен криптографическими ключами;
2) TLS Record Protocol — обеспечение конфиденциальности и целостности передаваемых данных.
Первый из них предусматривает согласование используемых криптографических алгоритмов (шифрования и хэширования), обмен сеансовыми случайными величинами и криптографическими параметрами для дальнейшего формирования ключей, обмен и проверку сертификатов (Х.509) для аутентификации сторон (или только сервера), формирование общего сеансового ключа, проверку предыдущих этапов подтверждения связи (с помощью НМАС с MD5, SHA-1 или SHA-2). Сеансовый ключ передается в зашифрованном виде (с помощью асимметричной криптосистемы RSA) либо формируется по алгоритму Диффи — Хеллмана. Поддерживаются цифровые подписи RSA DSA ECDSA и хэш-функции MD5, SHA-1, SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512).
Протокол TLS Record Protocol использует параметры, полученные во время работы TLS Handshake Protocol. Он реализует симметричное шифрование, сжатие и проверку целостности передаваемых данных. Доступные для использования алгоритмы определяются версией протокола TLS. Симметричные блочные шифры используются в режиме сцепления блоков шиф- ротекста СВС. В текущей версии TLS 1.2 доступны: AES (128, 256), Triple DES и потоковый шифр RC4. Каждое сообщение снабжается кодом аутентификации НМАС (с MD5, SHA-1 или SHA-2). Использование шифрования и (или) кодов аутентификации может быть отключено.
Протоколы SSL/TLS позволяют создать VPN-туннель в интернет-соединениях и приложениях электронной коммерции, обеспечивая безопасность не только HTTP, но и других прикладных протоколов, таких как SMTP, FTP. Протоколы поддерживаются большинством современных браузеров и операционных систем на разных платформах, имеют программные и аппаратные реализации. Существуют реализации протокола TLS с поддержкой российских криптографических стандартов (например, КриптоПро TLS, входящий в состав КриптоПро CSP, реализация TLS в составе Вали- дата CSP, ViPNet CSP, Континент TLS VPN и др.).
Другие протоколы
Протокол Kerberos — протокол взаимной аутентификации и распределения сеансовых ключей в клиент-серверных системах с участием третьей (доверенной) стороны. Kerberos является одной из модификаций протокола взаимной аутентификации Нидхема — Шрёдера с применением симметричных криптосистем.
В качестве симметричных шифров могут быть использованы DES, 3DES и AES в режиме СВС. К передаваемым данным перед шифрованием добавляется контрольная сумма, в роли которой могут выступать коды аутентификации НМ АС (с хэш-функциями MD4, MD5, SHA-1), хэш-значения или контрольная сумма CRC-32. Доверенной стороной выбираются наиболее стойкие криптографические алгоритмы из списка тех, которые поддерживаются сторонами.
При непосредственной аутентификации на сервере пользователь вынужден проходить процедуру для каждой службы сети, а каждый сервер — хранить ключи и регистрационную информацию всех клиентов. Такая система не слишком удобна для пользователей и создает дополнительные риски безопасности. Протокол Kerberos предполагает централизованное хранение аутентификационной информации клиентов и позволяет реализовать принцип единого входа (Single Sign-On) — возможность использования единой учетной записи пользователя для доступа к любым службам и ресурсам сети без повторной аутентификации. Протокол Kerberos и его расширение, позволяющее проводить аутентификацию с помощью цифровых сертификатов, реализован в операционных системах Windows Server.
Kerberos обеспечивает аутентификацию в недоверенной среде, подразумевающей наличие у противника следующих возможностей:
• способность выдать себя за одну из сторон сетевого взаимодействия;
• физический доступ к одному из участвующих в соединении компьютеров;
• перехват, модификация и повторная передача пакетов.
Безопасность протокола Kerberos требует обязательной синхронизации
системных часов всех участвующих во взаимодействии узлов.
В роли доверенной стороны (арбитра) выступает служба KDC (центр распределения ключей, Kerberos Key Distribution Center), работающая на физически защищенном сервере. В сетях иод управлением операционной системы Windows Server КОС располагается на контроллере домена. КОС хранит базу регистрационных данных всех клиентов сети, а также секретные ключи клиентов, используемые для шифрования служебной информации, передаваемой в процессе аутентификации. Эти ключи, называемые долговременными, применяются пользователями только для связи с KDC. Предполагается, что секретный ключ известен обеим сторонам (и клиенту, п КОС) и был передан надежным способом до начала взаимодействия.
В состав службы КОС входят сервер аутентификации AS (Authentication Server) и служба выдачи разрешений TGS (Ticket Granting Service, Ticket Granting Server).
' Шнайер Б. Прикладная криптография: протоколы, алгоритмы, исходные тексты на языке Си; Мамаев М. Технологии защиты информации в Интернете.
Основными элементами безопасности Kerberos являются билеты (мандаты, ticket) и аутентификаторы {authenticator). Билеты предназначены для безопасной передачи серверу личности клиента и имеют определенный политикой безопасности срок действия (обычно не более 8 ч). Аутентификатор — это дополнительный одноразовый атрибут, предъявляемый вместе с билетом. Особенностью протокола Kerberos является использование концепции ТОТ {ticket granting ticket, билет для получения билета), позволяющей клиентам однократно пройти аутентификацию для доступа к нескольким сервисам в течение определенного времени.
Пусть клиент А хочет получить доступ к сетевому сервису на сервере SS {Service Serveг). Тогда, в несколько упрощенном виде, участники протокола Kerberos должны будут выполнить следующие шаги (рис. 3.27):
1) клиент А отсылает серверу аутентификации AS запрос, содержащий идентификатор клиента (А), идентификатор сервиса (SS) и метку времени клиента ТА, зашифрованную долговременным ключом клиента:
где Еа — симметричный шифр на долговременном ключе клиента А
2) сервер аутентификации AS проверяет наличие регистрационных данных клиента А в базе данных учетных записей и проводит первоначальную аутентификацию клиента по знанию секретного ключа. Если клиент зарегистрирован и при расшифровании сервером AS получена правильная метка времени, AS предоставляет клиенту информацию для доступа к серверу выдачи разрешений. Клиенту А направляются:
• идентификатор сервера TGS (обозначим его ITGS) и случайный сеансовый ключ К, для связи А с TGS, зашифрованные секретным ключом клиента А,
• билет TGT, зашифрованный ключом сервера TGS,
• срок действия L билета TGT (время начала и окончания действия) и сгенерированная сервером аутентификации метка времени TAS.
TGT содержит копию сеансового ключа для связи с А срок действия билета, метку времени и идентификатор клиента:
где TGT =?tgs(A L, Kv TAS); ETCS — симметричный шифр на секретном ключе сервера TGS;
3) получив сообщение, клиент расшифровывает свою часть с целью получения сеансового ключа А, для связи с сервером TGS. Клиент пересыла-
Рис. 327. Аутентификация Kerberos
ет TGT службе TGS. Кроме того, он отсылает свой аутентификатор, зашифрованный сеансовым ключом Kv и идентификатор сервиса SS. Аутентификатор содержит идентификатор клиента и новую метку времени ТА
4) служба TGS расшифровывает полученный от клиента TGT, теперь она имеет в своем распоряжении ключ Кх и может расшифровать остальные присланные клиентом данные. В ответ служба TGS генерирует билет сервиса (,service ticket) и шифрует его секретным ключом сервера SS. Билет сервиса включает: идентификатор клиента, случайный сеансовый ключ К2 для связи клиента А с сервисом SS, время жизни билета и метку времени. Кроме того, служба TGS, направляет пользователю копию сеансового ключа, идентификатор сервиса и время жизни билета L, зашифрованные ключом К{:
где TGS = Ess(A L, К2, ГТС8); Ess — симметричный шифр на секретном ключе сервера SS. Служба TGS является таким же сетевым сервисом, как и остальные, поэтому билеты TGT и TGS обладают одинаковой структурой;
5) клиент А расшифровывает свою часть сообщения и получает сеансовый ключ для связи с сервером SS. Теперь А может пройти авторизацию на сервисе. Л посылает серверу SS полученный билет сервиса и новый аутентификатор (идентификатор клиента и его метку времени), зашифрованный на сеансовом ключе К2, предназначенном для связи клиента А с сервером SS:
6) сервер SS расшифровывает билет сервиса своим секретным ключом и извлекает сеансовый ключ К2 для связи с клиентом А Теперь он может расшифровать присланный клиентом аутентификатор. Сервер SS подтверждает свою подлинность клиенту, посылая ему значение ТА + 1, зашифрованное общим ключом К2:
7) клиент расшифровывает сообщение и проверяет корректность обновления своей метки времени. Если время обновлено корректно, пользователь может доверять серверу.
При необходимости общий сеансовый ключ К., может использоваться для дальнейшего шифрования сообщений между клиентом Л и сервером SS. Если требуется односторонняя аутентификация только клиента серверу, шаги 6 и 7 опускаются.
Kerberos может использоваться и для междоменной аутентификации. В случае обращения клиента к серверу из другого домена КОС выдает билет переадресации для обращения к КОС другого домена. Это предполагает наличие ключей для взаимной связи КОС разных доменов.
Использование в зашифрованных сообщениях меток времени позволяет обеспечить защиту от повторного использования удостоверений. Противник, перехвативший и сохранивший аутентификатор клиента, не сможет использовать его позже при условии корректной синхронизации времени.
Следует, однако, иметь в виду, что большинство сетевых протоколов синхронизации времени небезопасно. Протокол Kerberos не может защитить от атак «отказ в обслуживании» п кражи секретных ключей на стороне клиента. Полученные клиентом билеты, а также секретные ключи должны защищаться от несанкционированного доступа.
Поскольку в большинстве реализаций долговременные ключи пользователей генерируются на основании их паролей (обычно используется хэш- значение пароля), слабые пользовательские пароли позволяют реализовать атаку на основе подбора пароля. Windows Server 2012 предусматривает защиту от автономных атак подбора паролей за счет использования безопасного туннелирования между клиентом Kerberos и КОС.
Другим подходом является усиление Kerberos за счет использования цифровых сертификатов (Х.509) для первоначальной аутентификации клиента на ранних этапах протокола (шаги 1—3). Такая возможность реализуется в операционных системах Windows Server в виде расширения PKINIT (Public Key Initialization). Расширение PKINIT позволяет проводить аутентификацию с помощью смарт-карт, в памяти которых хранится пара ключей (открытый и личный) клиента. Расширение PKINIT определяет следующий порядок применения цифровых сертификатов при обмене по подпротоколу AS Exchange:
• открытый ключ ОК(А) служит для шифрования сеансового ключа клиента А службой KDC;
• личный ключ ЛК(Л) — для расшифрования сеансового ключа клиентом.
Тогда этап предварительной (первоначальной аутентификации) клиента в протоколе Kerberos включает следующие шаги:
1) клиент Л отсылает серверу аутентификации AS запрос, содержащий, дополнительно к стандартному, цифровой сертификат CERT клиента (с его открытым ключом ОК(А)). Метка времени в запросе подписана личным ключом клиента ЛК(А):
где Р.|К(А) — цифровая подпись клиента А с использованием асимметричной криптосистемы;
2) сервер аутентификации AS проверяет действительность присланного сертификата, затем расшифровывает метку времени полученным открытым ключом клиента и проверяет ее корректность. Если проверка пройдена, клиенту направляется TGT, формируемый точно таким же образом, как при стандартном режиме аутентификации Kerberos, и клиентская информация, зашифрованная открытым ключом клиента:
где РОК(А) — асимметричное шифрование на открытом ключе клиента А
3) получив сообщение, клиент расшифровывает свою часть для получения сеансового ключа К, имеющимся в его распоряжении личным ключом ЛК(А).
Последующие действия сторон полностью совпадают с выполняемыми в рамках стандартного протокола Kerberos. Смарт-карта, закрытый ключ и сертификат открытого ключа не используются до следующей регистрации пользователя в системе.
Методика PKINIT позволяет реализовать двухфакторную аутентификацию пользователя на этапе предварительной аутентификации протокола Kerberos: пользователь должен иметь смарт-карту (с хранящимися в ее памяти ключами) и знать PIN-код смарт-карты (чтобы иметь возможность использовать закрытый ключ для формирования цифровой подписи). Закрытый ключ и сертификат обычно хранятся в разных областях памяти смарт-карты.
Существуют отечественные разработки, позволяющие использовать на этапе предварительной аутентификации протокола Kerberos с PKINIT российские криптоалгоритмы (например, КриптоПро Winlogon, входящий в состав КриптоПро CSP).
Протокол SET(Secure Electronic Transaction) — протокол, специально разработанный для проведения защищенных электронных транзакций по платежным картам в недоверенной среде (например, в сети Интернет). SET защищает от подделки платежных карт, используемых для онлайн-платежей. Протокол обеспечивает конфиденциальность и целостность данных владельца карты, одновременно предоставляя средства для аутентификации карты. SET является протоколом прикладного уровня и не зависит от используемых транспортных протоколов.
Протокол SET является альтернативой использования протокола SSL/TLS при выполнении электронных платежей и рекомендован международными платежными системами Visa International и MasterCard в качестве стандарта в области электронной коммерции. По сравнению с протоколом SSL/TLS, SET имеет более узкую специализацию н не является универсальным. Функционирование протокола SET требует наличия специального программного обеспечения как на стороне сервера, так и на стороне клиента, что приводит к дополнительным издержкам. Кроме того, транзакции SET требуют больше ресурсов и работают медленнее транзакций с использованием SSL/TLS. Данные недостатки могут оказаться критичными для продавца, обрабатывающего большое число транзакций. Однако, по мнению представителей платежных систем, это компенсируется более высоким уровнем безопасности электронных транзакций SET.
Спецификация SET поддерживает все возможности, предоставляемые современными платежными (кредитными) картами: регистрацию держателя карты, регистрацию продавца, запрос покупки, авторизацию платежа, перевод денежных средств, кредитные операции, возврат денежных средств, отмену кредита, дебитные операции.
SET позволяет потребителям и продавцам подтвердить подлинность всех участников сделки (рис. 3.28), происходящей в Интернете, средствами асимметричной и симметричной криптографии, применяя, в том числе, цифровые сертификаты. Номера на рис. 3.28 обозначают следующие операции: 1 — распределение сертификатов; 2 — формирование заказов; 3 — взаимная аутентификация; 4 — проверка счета клиента; 5 — оплата.
Протокол SET предоставляет сервис аутентификации для участников посредством использования сертификатов Х.509. Сертификаты должны
Рис. 3.28. Упрощенная схема транзакции SET
обслуживаться через определенную иерархию удостоверяющих центров. Во главе иерархической структуры находится корневой удостоверяющий центр SET (Secure Electronic Transaction) (LLC или SETCo).
Протокол SET защищает только финансовую информацию, непосредственно сопряженную с платежной транзакцией. Защита информации, содержащейся в заказе, SET не регламентирует.
Интересной особенностью протокола SET является использование концепции двойных подписей, дающей возможность связывать два фрагмента данных и посылать их двум сущностям.
Двойная подпись формируется следующим образом:
1) для каждого из двух подписываемых фрагментов данных формируется хэш-значение;
2) полученные хэш-значения сцепляются и снова обрабатываются хэш- функцией;
3) окончательное хэш-значение шифруется личным ключом подписывающего, формируя цифровую подпись.
Для шифрования SET использует как симметричные, так и асимметричные криптографические алгоритмы: сообщения шифруются на случайных ключах симметричными алгоритмами, после чего дополняются симметричными ключами и зашифровываются с помощью асимметричной схемы. Для обеспечения целостности по умолчанию используется HMAC-SHA-1, для цифровой подписи — RSA-SHA-1, симметричное шифрование по умолчанию осуществляется DES-CBC. Существенным достоинством SET является отсутствие ограничений на используемые криптоалгоритмы, что позволяет реализовать национальные стандарты шифрования.
Система SET не получила широкой популярности, и в настоящее время в качестве ее замены Visa International и MasterCard предлагают XML-npo- токол с поддержкой двухфакторной аутентификации пользователей. Этот протокол носит название 3-D Secure в системах Visa International и MasterCard SecureCode (МСС) в системах MasterCard.
Протокол SSH (Secure Shell, защищенная оболочка) — протокол прикладного уровня, обеспечивающий защищенную аутентификацию, соединение и безопасную передачу данных между узлами сети. Протокол реализует VPN-туннелирование для передачи данных в недоверенпой среде (например, в сети Интернет), а также предоставляет возможность сжатия передаваемых данных.
Протокол широко используется для удаленного администрирования операционных систем и защищенной передачи файлов. Бесплатная версия протокола с открытым исходным кодом OpenSSH поддерживается большинством unix-платформ, предоставляя SSH-клиент и SSII-сервср в качестве стандартных утилит. В 2006 г. SIILI принят в качестве интернет-стандарта.
Протокол предполагает сквозное шифрование всего трафика, обязательную аутентификацию сервера, возможность аутентификации клиента различными способами (включая использование цифровых сертификатов, аутентификацию по паролю и методы аутентификации, поддерживаемые конкретной операционной системой), обеспечение целостности и возможность сжатия передаваемых данных методом Лемпеля — Зива. Аутентификация с использованием открытых ключей является предпочтительной.
Для шифрования используется симметричный алгоритм, выбираемый в процессе переговоров сторон сеанса связи (3DES — обязательный для реализации, AES — рекомендованный, Blowfish, Twofish, CAST, Serpent в режиме СВС или потоковый шифр ARCFOUR — RC4 с 128-битным ключом). Для создания общего секретного (сеансового) ключа используется алгоритм Диффи — Хеллмаиа или передача в зашифрованном виде (RSA с SHA1 или SHA-256). Целостность передаваемой информации обеспечивается HMAC-SHA1 (обязательный) или HMAC-MD5. Цифровые подписи используют алгоритмы RSA (рекомендованный) или DSA (обязательный) с SHA-1.
Протокол S/MIME {Secure/Multipurpose Internet Mail Extensions) — стандарт обеспечения конфиденциальности и целостности почтовых сообщений. S/MIME является протоколом прикладного уровня и предназначен для использования совместно с системами электронной почты e-mail (но не web-mail). Протокол S/MIME поддерживается, в частности, почтовыми программами М icrosoft.
Хотя S/MIME наиболее известен как протокол защиты электронной почты, он может использоваться с любым транспортным механизмом, осуществляющим поддержку S/MIME, например с HTTP S/MIME может применяться в автоматических агентах передачи сообщений, использующих криптографические сервисы. В спецификации S/MIME указывается, как использовать сервисы для шифрования факсимильных сообщений.
Конфиденциальность обеспечивается за счет симметричного шифрования 3DES (обязательный), распределение ключей производится по протоколу Диффи — Хеллмаиа или с использованием RSA-шифрования на открытом ключе получателя, целостность сообщений и аутентификация их источника обеспечиваются с помощью технологии ЭЦП. S/MIME поддерживает цифровые сертификаты Х.509 на основе RSA и алгоритмов хэширования SHA-1 (обязательный) и MD5. Должны распознаваться и цифровые подписи DSA с SНА-1. Допускается только подписание или только шифрование сообщений, а также совместное использование цифровых подписей и шифрования.
При совместном использовании шифрования и ЭЦП порядок операций определяется реализацией протокола и (или) выбором пользователя. Если первым выполняется шифрование, цифровая подпись может быть проверена без вскрытия защищенной оболочки («конверта») сообщения. Такой порядок предпочтителен в системах, использующих автоматическую проверку цифровых подписей. В этом случае получатель сможет удостовериться в том, что блоки шифротекста ие были изменены при передаче, однако он не может установить явную связь между открытым текстом присланного сообщения и отправителем. В случае использования обратного порядка операций (сначала подписание, потом шифрование) получатель сможет удостовериться в подлинности открытого текста сообщения, но не получит гарантий целостности неподписанных частей шифротекста.
Возможно совместное использование с S/MTME российских криптоалгоритмов.
Криптографическая защита электронного документооборота и финансовых систем. Работа современных предприятий немыслима без создания эффективной системы электронного документооборота (СЭД), позволяющей оптимизировать формирование, обработку, передачу и хранение корпоративных документов. Перед СЭД может также ставиться задача обеспечения юридической значимости электронных документов. Правовую основу электронного документооборота составляют нормы Гражданского кодекса РФ (часть 4), Федерального закона от 27 июля 2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации» и Федерального закона от 6 апреля 2011 г. № 63-ФЗ «Об электронной подписи». Согласно последнему юридическая значимость электронного документа обеспечивается с помощью электронной подписи. Порядок использования ЭЦП в корпоративных информационных системах может устанавливаться предприятием или соглашением между участниками электронного взаимодействия.
Федеральный закон «Об электронной подписи» вводит понятия простой и усиленной электронной подписи, последняя может быть усиленной неквалифицированной и усиленной квалифицированной электронной подписью.
Усиленная ЭЦП должна быть получена в результате криптографического преобразования информации с использованием ключа электронной подписи, обеспечивает целостность электронного документа п позволяет определить лицо, его подписавшее. Усиленная квалифицированная электронная подпись (квалифицированная подпись) дополнительно предполагает использование квалифицированных сертификатов, а также средств генерации и проверки подписи, отвечающих специальным требованиям. На практике это означает необходимость поддержки отечественных криптоалгоритмов, сертификацию ФСБ России используемого программного обеспечения с криптографическими функциями и выдачу сертификата удостоверяющим центром, использующим сертифицированные ФСБ России СКЗИ. С криптографической точки зрения предполагается использование асимметричных криптосистем, базирующееся на инфраструктуре открытых ключей РКТ.
Использование усиленной квалифицированной подписи приравнивает подписанный электронный документ к документу на бумажном носителе, заверенному собственноручно. Электронные документы, заверенные другими типами подписей, могут иметь юридическую силу по соглашению сторон (участниками электронного взаимодействия должны быть предварительно приняты соответствующие нормативные правовые акты и (или) соглашения). В государственных информационных системах используется только усиленная квалифицированная ЭЦП.
Другой задачей СЭД может быть обеспечение конфиденциального документооборота, что предусматривает, в том числе, шифрование электронных документов при их хранении и передаче. Шифрование документов, как правило, обеспечивается симметричными криптосистемами.
Таким образом, под системой защищенного документооборота (защищенной СЭД) обычно понимается система обеспечения юридически значимого электронного документооборота, обеспечивающего конфиденциальность, целостность и имитозащиту обрабатываемых электронных документов. Под имитозащитой в этом случае понимается невозможность отправки ложного электронного документа от имени легального пользователя системы.
Защищенный юридически значимый электронный документооборот используется для:
• организации коллективной работы с документами в территориально- распределенных корпоративных информационных системах;
• обеспечения конфиденциальности и целостности документов;
• подтверждения авторства (аутентичности) документов и невозможности отказа от авторства;
• обеспечения доверия пользователей к содержанию электронных документов;
• регламентации доступа пользователей к документам.
Методические рекомендации по обеспечению с помощью криптосредств безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств автоматизации, утвержденные руководством 8 Центра ФСБ России 21.02.2008 № 149/54-144, требуют использования сертифицированных ФСБ России СКЗИ для защиты персональных данных. Использование сертифицированных СКЗИ потребуется и для защиты государственных информационных систем, в том числе для построения защищенных СЭД. Согласно приказу ФСБ России от 27 декабря 2011 г. № 796, содержащему «Требования к средствам электронной подписи» и «Требования к средствам удостоверяющего центра», СКЗИ, имеющие в своем составе функции по созданию и проверке электронных подписей, должны:
1) при создании электронной подписи-.
• показывать лицу, подписывающему электронный документ, содержание информации, которую он подписывает,
• создавать ЭЦП только после подтверждения операции по созданию подписи лицом, подписывающим электронный документ,
• однозначно показывать, что ЭЦП создана;
2) при проверке.электронной подписи:
• показывать содержание подписанного электронного документа,
• показывать информацию о внесении изменений в подписанный электронный документ,
• указывать на лицо, с использованием ключа которого подписаны электронные документы.
В современных условиях электронный документооборот, как правило, выходит за внутрикорпоративные рамки (например, предприятия сдают электронную бухгалтерскую отчетность в налоговые органы), поэтому предпочтительным является использование квалифицированной электронной подписи. Удостоверяющий центр, выдающий квалифицированные сертификаты, должен иметь лицензии ФСБ России на осуществление деятельности, связанной с криптографическими средствами, пройти аккредитацию в Министерстве связи и массовых коммуникаций и подключиться к сети доверенных удостоверяющих центров (ФНС России и, при необходимости, других государственных служб). Удостоверяющий центр часто также имеет лицензию ФСТЭК России на деятельность но технической защите конфиденциальной информации. Возможно создание удостоверяющего центра собственными силами крупной компании, однако, как правило, прибегают к услугам стороннего доверенного центра сертификации.
Таким образом, невозможно избежать необходимости передачи электронных документов но открытым сетям (через Интернет), что может также обусловливаться территориальной распределенной структурой самой компании и (или) необходимостью организации работы мобильных пользователей. Все это требует организации защищенных VPN-подключений, которые могут быть реализованы средствами стандартных защищенных сетевых протоколов (SSL и TLS для передачи в Интернете и IPSec — в рамках локальной сети), в том числе, при необходимости, на базе сертифицированных криптопровайдеров (CSP), поддерживающих российские криптографические стандарты.
Возможная структура защищенной СЭД представлена на рис. 3.29. Работа во внутренней сети организована но принципу «тонкого клиента», т.е. большая часть операций СЭД выполняется непосредственно на сервере.
Система защиты информации включает подсистемы:
• аутентификации пользователей;
• управления доступом;
• регистрации и учета событий;
• контроля целостности;
• управления пользователями;
• криптографической защиты.
Рис. 3.29. Пример защищенной СЭД
Криптографический модуль системы защиты СЭД обеспечивает работу с электронной подписью и обращение к доверенному центру сертификации, а также прозрачное шифрование информации с целью ее безопасного хранения и передачи. Он также может являться частью подсистемы аутентификации пользователей, поддерживая использование отчуждаемых ключевых носителей (смарт-карт, USB-токенов). Этот вариант предпочтительнее, так как позволяет хранить секретные ключи, используемые как для аутентификации, так и для подписывания документов, на внешних носителях.
Информационные системы, используемые в банковском и кредитно-финансовом секторе, по сути, представляют собой защищенные СЭД и отличаются, как правило, большой степенью модульности и сложной, территориально-распределенной структурой. Согласно стандарту Банка России СТО БР ИББС-1.0-2014 «Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Общие положения» в банковских информационных системах необходимо использовать СКЗИ, которые сертифицированы уполномоченным государственным органом либо имеют разрешение ФСБ России; СКЗИ, применяемые для защиты персональных данных, должны иметь класс не ниже КС2. Необходимость использования СКЗИ определяется организацией БС РФ самостоятельно, если иное не предусмотрено законодательством РФ.
В системах электронных платежей с использованием платежных карт необходимо использовать средства защиты, соответствующие требованиям стандарта безопасности данных индустрии платежных карт (PCI DSS v.3.0, Payment Card Industry Data Security Standard). PCI DSS предусматривает использование стойких криптографических алгоритмов для защиты данных держателей карт при их хранении и передаче, а также внедрение процедур управления ключами.
Запрещается хранение после авторизации: критических аутентификационных данных (кроме эмитентов карт), полного содержимого магнитной полосы карты, CVC- и PIN-кодов, даже в зашифрованном виде. Для хранения номеров платежных карт PAN используются однонаправленные хэш- функции или стойкое шифрование. При передаче данных через общедоступные сети применяются надежные криптографические алгоритмы и протоколы защиты (например, SSL/TLS, IP
