Официальный сайт НИИ прикладных проблем математики и информатики

skzi

Модернизация СТБ 34.101.27

05.05.2017 Администратор

Действующий стандарт СТБ 34.101.27 определяет требования к программным СКЗИ (средствам криптографической защиты информации). Проект Skzi, открытый нами на площадке Github, сопровождает разработку новой редакции СТБ 34.101.27.

В новой редакции мы хотим:

1. Ввести требования безопасности не только к программным, но и к аппаратным СКЗИ. 
2. Уточнить классификацию СКЗИ, ввести новые классы (по сути, уровни безопасности).
3. Ввести пакеты – опциональные группы консолидированных тематических требований.
4. Уточнить действующие требования, учитывая практику применения СТБ 34.101.27.

Мы считаем, что требование безопасности должно быть компромиссом между заказчиком, разработчиком и экспертом.

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

Разработчику СКЗИ важно, чтобы требования были понятны и технологически реализуемы. Разработчик не принимает декларации типа "генератор случайных чисел, который используется для построения ключей, должен выдавать реализации независимых случайных величин с равномерным распределением на {0,1}".

esign3.0

ЭЦП 3.0

20.04.2017 Администратор

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

1. ГосСУОК.
2. Граф доверия.
3. Динамика доверия.
4. Аттестаты.
5. Расширенная ЭЦП.
6. Процессы выработки и проверки РЭЦП.

Закон об ЭЦП был принят в нашей стране в 1999 году. Раньше чем в США, РФ и странах Западной Европы. Закон решил главную задачу – он объявил электронные документы, т.е. документы с ЭЦП, юридическими значимыми. Для этого было достаточно, чтобы генерация личного ключа и выработка подписи выполнялись с помощью сертифицированного средства ЭЦП.

sig_vfy

Процессы выработки и проверки РЭЦП

20.04.2017 Администратор

[продолжение, предыдущая часть]

Процессы управления расширенной подписью намного сложнее процессов управления обычной.

Во-первых, к процессам выработки и проверки добавляется процесс дополнения подписи новыми неподписанными атрибутами. Дополнение, как мы уже говорили, может выполнять не только подписант, но и верификатор. Дополняемые атрибуты – это в основном аттестаты, которые облегчают проверку подписи или других аттестатов. 

Во-вторых, усложняется и детализируется процесс выработки подписи (см. рисунок). Вырабатывать подпись средству ЭЦП помогает специальная программа. Она передает средству документ, который требуется подписать, организует взаимодействие между средством и подписантом. В совокупности средство ЭЦП и программа составляют систему выработки подписи. С этой системой, в свою очередь, взаимодействует прикладная программа. Именно здесь готовится подписываемый документ, формируются атрибуты, аттестаты и прочие данные, необходимые для выработки РЭЦП. Подготовленные данные передаются системе. Перечень передаваемых данных определяется политикой выработки подписи. Политика описывается специальным документом, задается конфигурационными файлами прикладной программы или жестко фиксируется в ее коде. Политика определяет формат подписи (CAdES, XAdES или PAdES), задает профиль, определяет размещение подписи (вложенная, обертывающая или отделенная).

В-третьих, усложняется процесс проверки подписи.

ades

Расширенная ЭЦП

19.04.2017 Администратор

[продолжение, предыдущая часть]

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

Мы привели цитату из СТБ 34.101.45 (Bign). Кратко сказанное означает, что ЭЦП – это доказательство целостности и подлинности сообщения (документа). Доказательство, от которого нельзя отказаться.

В современной криптографии имеется разветвленная система доказательств различных фактов и свойств. От доказательства хранения файла на облачном сервере до доказательства вычислительной работы (proof-of-work) в Bitcoin. ЭЦП строится как доказательство владения личным ключом применительно к подписываемому документу. Во многих случаях, одним из которых является Bign, ЭЦП – это доказательство с нулевым разглашением: подпись не содержит информации о личном ключе.

Личный ключ – это уникальный идентификатор подписанта в цифровом мире, открытый ключ – это ссылка на личный. Фраза "при правильном управлении ключами" из приведенной цитаты очень важна.

val_data

Аттестаты

18.04.2017 Администратор

[продолжение, предыдущая часть]

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

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

На рисунке приводится классификация аттестатов, рассмотренных выше и определяемых далее.

Сертификат открытого ключа (СОК) связывает имя Алисы с ее личным ключом. Как мы уже говорили, личный ключ уникально идентифицирует Алису в цифровом мире. Поэтому, продолжая аналогию со справками, СОК – это цифровой паспорт Алисы. Или даже ее пропуск в цифровой мир. Кстати, перед выпуском пропуска Регистрационный центр (еще одна служба ИОК) обычно проверяет паспортные данные Алисы, и речь при этом идет не о цифровом, а об обычном бумажном паспорте.

Бумажный паспорт является серьезным долговременным аттестатом. В период его действия Алиса может получать временные полномочия, и эти полномочия будут отражаться в ее краткосрочных аттестатах.

dyn_trust

Динамика доверия

18.04.2017 Администратор

[продолжение, предыдущая часть]

Доверие не статично. Рут доверяет Алисе ограниченно долго, с момента t₁ до момента t₂. Например, с момента приема на работу и до окончанияконтракта. Отрезок [t₁,t₂] указывается в сертификате A(R) и называется сроком действия. Интересно, что сертификат X.509 спроектирован так, что момент выпуска в нем не фиксируется. Обычно предполагается, что сертификат выпущен в момент t₁.

Отрезок доверия [t₁,t₂] также не статичен. Алиса может уволиться в момент t₃ > t₂ или потерять в этот момент свой личный ключ. В таких ситуациях отрезок доверия должен быть сокращен до [t₁,t₃]. Как это сделать? Ведь сертификат A(R) уже выпущен, забрать его нельзя. Мы сталкиваемся с общей особенностью цифрового мира – опубликованные данные бессрочны, "рукописи не горят".

Если нельзя отменить публикацию, то давайте опубликуем опровержение. Так и поступает Рут. Рут регулярно (например, ежедневно) публикует объявление об отзыве. В нем Рут перечисляет номера отозванных сертификатов, ранее им выпущенных, указывает время отзыва. Рут фиксирует время публикации текущего и следующего объявлений, подписывает объявление.  Объявление называется списком отозванных сертификатов (СОС). По последнему СОС Боб определяет текущий отрезок доверия сертификата Алисы.

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

graph_of_trust

Граф доверия

14.04.2017 Администратор

[продолжение, предыдущая часть]

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

По личному ключу Алиса строит открытый ключ. Открытый ключ вместе с именем Алисы и другими реквизитами подписывается Рутом, и в результате получается сертификат. Алису (A) называют субъектом сертификата, Рута (R) – эмитентом. Выпуск сертификата обозначим как R → A. Боб (B) также получает сертификат у Рута, сертификат Руту выдает Зед (Z), предварительно Зед выпускает сертификат самому себе:

R → B, Z → R, Z → Z.

Сертификат является видом электронного документа, т. е. документа с подписью. Доверие к стороне переносится на документы, подписанные этой стороной, и, наоборот, доверие к стороне возникает из доверия к ее сертификату. Доверяя Зеду, мы доверяем выпущенному Зедом сертификату Рута и, как следствие Руту. Доверяя Руту, мы доверяем Алисе и Бобу. Доверяя Алисе и Бобу, мы доверяем подписанным Алисой и Бобом документам. Как видим, доверие транзитивно.

Построим граф доверия, в котором вершины – это стороны ИОК, а дуги связывают эмитентов с субъектами.

bpki

ГосСУОК

07.04.2017 Администратор

Ахиллесовой пятой криптографии с открытыми ключами является, по выражению В. Столлингса, управление этими самыми ключами. Ключи должны распространяться по так называемым аутентифицированным каналам связи (АКС): получатель Боб должен иметь возможность проверить, что ключ отправлен Алисой (подлинность) и что ключ не был изменен во время передачи (целостность). Важно, что Алисе и Бобу не нужен дорогостоящий секретный канал связи (СКС), который дополнительно обеспечивает конфиденциальность ключей. Отказ от СКС в пользу АКС и есть суть революции, состоявшейся в криптографии в 1970-х годах. Революцию начали У. Диффи и М. Хеллман, продолжили разработчики RSA. И протокол Диффи – Хеллмана, и криптосистема RSA фактически являются инструментами поднятия АКС до СКС. 

Не следует понимать АКС буквально. Это не физический канал связи, а скорее интерфейс, концепция. Для организации АКС Алиса и Боб прибегают к сервисам, которые принято называть услугами доверия. Сервисы предоставляют специальные службы (центры, серверы)  – поставщики услуг доверия.

Последний термин является калькой с английского Trust Service Provider. Интересно, что англоязычный термин претерпел несколько транформаций. Прежде было принято говорить Trusted Service Provider (доверенный поставщик  услуг), а еще раньше – Trusted Third Party (третья доверенная сторона). Термин Trust Service Provider кажется наиболее удачным.

bee2evp

Bee2evp: плагин для OpenSSL

21.12.2016 Администратор

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

Но криптографическая инфраструктура нашей страны не исчерпывается алгоритмами и протоколами. Имеется довольно большой массив, так называемых, форматных стандартов: СТБ 34.101.17 (запросы на выпуск сертификата), СТБ 34.101.19 (сертификаты открытого ключа, списки отозванных сертификатов), СТБ 34.101.23 (CMS), СТБ 34.101.26 (OCSP), СТБ 34.101.67 (атрибутные сертификаты).

Управление форматами – это довольно трудная задача. Трудная из-за многообразия форматов и их внутренней сложности. Сложность определяется как большим количеством форматных полей, так и большим числом вариантов их комбинирования. Целевые форматы описываются на языке АСН.1. Этот язык позволяет задать структуру полей, типы полей, атрибуты полей. Варианты комбинирования появляются из-за того, что поля могут описываться различными способами (идет речь о конструкции CHOICE) и что поля могут опускаться (конструкция OPTIONAL).

Известный криптографический тезис гласит: "сложность – главный враг безопасности". Из-за сложности форматов постоянно возникают уязвимости в различных криптографических продуктах.

safe(bee2)

Регуляризация Bee2

21.12.2016 Администратор

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

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