Однонаправленные хэш-функции на основе симметричных блочных алгоритмов
Однонаправленную хэш-функцию можно
построить, используя симметричный блочный алгоритм. Наиболее очевидный подход
состоит в том, чтобы шифровать сообщение М посредством блочного алгоритма в
режиме СВС или СFВ с помощью фиксированного ключа и некоторого вектора
инициализации IV.
Последний блок шифртекста можно рассматривать в качестве
хэш-значения сообщения М. При таком подходе не всегда возможно построить
безопасную однонаправленную хэш-функцию, но всегда можно получить код
аутентификации сообщения МАС (Message Authentication Code).
Более безопасный вариант хэш-функции
можно получить, используя блок сообщения в качестве ключа, предыдущее
хэш-значение – в качестве входа, а текущее хэш-значение – в качестве выхода.
Реальные хэш-функции проектируются еще более сложными. Длина блока обычно
определяется длиной ключа, а длина хэш-значения совпадает с длиной блока.
Поскольку большинство блочных алгоритмов являются 64-битовыми, некоторые
схемы хэширования проектируют так, чтобы хэш-значение имело длину, равную двойной длине блока.
Если принять, что получаемая
хэш-функция корректна, безопасность схемы хэширования базируется на безопасности
лежащего в ее основе блочного алгоритма. Схема хэширования, у которой длина
хэш-значения равна длине блока, показана на рис.3. Ее работа описывается
выражениями:
Н0 = Iн,
Нi = ЕA(В) Å С,
где
Å
– сложение по модулю 2 (исключающее ИЛИ);
Iн
– некоторое случайное начальное значение;
А, В, С
могут принимать значения
Мi,
Нi-1, (МiÅ
Нi-1)
или быть константами.
Рис.3. Обобщенная схема формирования хэш-функции
Сообщение М разбивается на блоки
Мi принятой длины, которые обрабатываются поочередно.
Три различные переменные А, В, С
могут принимать одно из четырех возможных значений, поэтому в принципе можно
получить 64 варианта общей схемы этого типа. Из них 52 варианта являются либо
тривиально слабыми, либо небезопасными. Остальные 12 схем безопасного хэширования,
у которых длина хэш-значения равна длине блока перечислены в табл.1.
Таблица 1 | ||||||||||||||||||||||||||
|
Первые четыре схемы хэширования,
являющиеся безопасными при всех атаках, приведены на рис.4.
Рис.4. Четыре схемы безопасного хэширования
Недостатком хэш-функций, спроектированных на основе блочных алгоритмов, является несколько
заниженная скорость работы. Дело в том, что ту же самую стойкость относительно двух основных
требований к хэш-функции можно обеспечить за гораздо меньшее количество операций над входными
данными.
Но для этого алгоритм необходимо изначально проектировать специально, исходя из
тандема требований (стойкость, скорость). Далее рассмотрены три самостоятельных алгоритма
криптостойкого хэширования, получивших наибольшее распространение на сегодняшний день.
Алгоритм MD5 (Message Digest №5) разработан Роналдом Риверсом.
MD5 использует 4 многократно повторяющиеся преобразования над тремя 32-битными величинами
U, V и W:
f(U,V,W)=(U AND V) OR ((NOT U) AND W) g(U,V,W)=(U AND W) OR (V AND (NOT W)) h(U,V,W)=U XOR V XOR W k(U,V,W)=V XOR (U OR (NOT W)).
В алгоритме используются следующие константы:
- начальные константы промежуточных величин –
H[0]=6745230116, H[1]=EFCDAB8916, H[2]=98BADCFE16, H[3]=1032547616;
- константы сложения в раундах –
y[j]=HIGHEST_32_BITS(ABS(SIN(j 1))) j=0...63,
где функция HIGHEST_32_BITS(X) отделяет 32 самых старших бита из двоичной записи
дробного числа X, а операнд SIN(j 1) считается взятым в радианах; - массив порядка выбора ячеек в раундах –
z[0...63] = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 1, 6, 11, 0, 5, 10, 15, 4, 9, 14, 3, 8, 13, 2, 7, 12, 5, 8, 11, 4, 1, 4, 7, 10, 13, 0, 3, 6, 9, 12, 15, 2, 0, 7, 14, 5, 12, 3, 10, 1, 8, 15, 6, 13, 4, 11, 2, 9);
- массив величины битовых циклических сдвигов влево –
s[0...63] = (7, 12, 17, 22, 7, 12, 17, 22, 7, 12, 17, 22, 7, 12, 17, 22, 5, 9, 14, 20, 5, 9, 14, 20, 5, 9, 14, 20, 5, 9, 14, 20, 4, 11, 16, 23, 4, 11, 16, 23, 4, 11, 16, 23, 4, 11, 16, 23, 6, 10, 15, 21, 6, 10, 15, 21, 6, 10, 15, 21, 6, 10, 15, 21).
На первоначальном этапе входной блок данных дополняется одним битом “1”. Затем к нему
добавляется такое количество битов “0”, чтобы остаток от деления блока на 512 составлял 448.
Наконец, к блоку добавляется 64-битная величина, хранящая первоначальную длину документа.
Получившийся входной поток имеет длину кратную 512 битам.
Каждый 512-битный блок, представленный в виде 16 32-битных значений
X[0]…X[15], проходит через сжимающую функцию, которая перемешивает его
со вспомогательным блоком (H[0],H[1],H[2],H[3]):
(A,B,C,D) = (H[0],H[1],H[2],H[3]) цикл по j от 0 до 15 T = (A f(B,C,D) x[z[j]] y[j]) ROL s[j] (A,B,C,D) = (D,B T,B,C) конец_цикла цикл по j от 16 до 31 T = (A g(B,C,D) x[z[j]] y[j]) ROL s[j] (A,B,C,D) = (D,B T,B,C) конец_цикла цикл по j от 32 до 47 T = (A h(B,C,D) x[z[j]] y[j]) ROL s[j] (A,B,C,D) = (D,B T,B,C) конец_цикла цикл по j от 48 до 63 T = (A k(B,C,D) x[z[j]] y[j]) ROL s[j] (A,B,C,D) = (D,B T,B,C) конец_цикла (H[0],H[1],H[2],H[3]) = (H[0] A,H[1] B,H[2] C,H[3] D)
После того, как все 512-битные блоки прошли через процедуру перемешивания, временные
переменные H[0],H[1],H[2],H[3], а 128-битное значение подается на выход хэш-функции.
Алгоритм MD5, основанный на предыдущей разработке Роналда Риверса MD4, был призван
дать еще больший запас прочности к криптоатакам. MD5 очень похож на MD4. Отличие состоит в
простейших изменениях в алгоритмах наложения и в том, что в MD4 48 проходов основного
преобразования, а в MD5 – 64.
Несмотря на большую популярность, MD4 “медленно, но верно” был
взломан. Сначала появились публикации об атаках на упрощенный алгоритм. Затем было заявлено о
возможности найти два входных блока сжимающей функции MD4, которые порождают одинаковый
выход.
Наконец, в 1995 году было показано, что найти коллизию, т.е. “хэш-двойник” к
произвольному документу, можно менее чем за минуту, а добиться “осмысленности” фальшивого
документа (т.е. наличия в нем только ASCII-символов с определенными “разумными” законами
расположения) – всего лишь за несколько дней.
Алгоритм безопасного хэширования SНА
(Secure Hash Algorithm) разработан НИСТ и АНБ США в рамках стандарта безопасного
хэширования SHS (Secure Hash Standard) в 1992 г. Алгоритм хэширования SНА
предназначен для использования совместно с алгоритмом цифровой подписи DSА.
При вводе сообщения М произвольной
длины менее 264 бит алгоритм SНА вырабатывает 160-битовое выходное
сообщение, называемое дайджестом сообщения МD (Message Digest). Затем этот
дайджест сообщения используется в качестве входа алгоритма DSА, который
вычисляет цифровую подпись сообщения М.
Такой же дайджест сообщения должен
вычисляться пользователем, проверяющим полученную подпись, при этом в качестве
входа в алгоритм SНА используется полученное сообщение М.
Алгоритм хэширования SНА назван
безопасным, потому что он спроектирован таким образом, чтобы было вычислительно
невозможно восстановить сообщение, соответствующее данному дайджесту, а также
найти два различных сообщения, которые дадут одинаковый дайджест.
Рассмотрим подробнее работу алгоритма
хэширования SНА. Прежде всего исходное сообщение М дополняют так, чтобы оно
стало кратным 512 битам. Дополнительная набивка сообщения выполняется следующим
образом: сначала добавляется единица, затем следуют столько нулей, сколько
необходимо для получения сообщения, которое на 64 бита короче, чем кратное 512,
и наконец добавляют 64-битовое представление длины исходного
сообщения.
Инициализируется пять 32-битовых переменных в виде:
А = 0х67452301 В = 0хЕFСDАВ89 С = 0х98ВАDСFЕ D = 0x10325476 Е = 0хС3D2Е1F0
Затем начинается главный цикл
алгоритма. В нем обрабатывается по 512 бит сообщения поочередно для всех
512-битовых блоков, имеющихся в сообщении. Первые пять переменных А, В, С, D, Е
копируются в другие переменные a, b, с, d, е:
а = А, b = В, с = С, d = D, е = Е
Главный цикл содержит четыре цикла по
20 операций каждый. Каждая операция реализует нелинейную функцию от трех из пяти
переменных а, b, с, d, е, а затем производит сдвиг и сложение.
Алгоритм SНА имеет следующий набор
нелинейных функций:
ft (Х, Y, Z) = (X Ù Y) Ú ((Ø X) Ù Z) для t = 0...19, ft (Х, Y, Z) =Х Å Y Å Z для t = 20...39, ft (Х, Y, Z) = (X Ù Y) Ú (X Ù Z) Ú (Y Ù Z) для t = 40...59, ft (Х, Y, Z) = Х Å Y Å Z для t = 60...79,
где
t
– номер операции.
В алгоритме используются также четыре константы:
Кt = 0х5А827999 для t = 0...19, Кt = 0х6ЕD9ЕВА1 для t = 20...39, Кt = 0х8F1ВВСDС для t = 40...59, Кt = 0хСА62С1D6 для t = 60...79.
Блок сообщения преобразуется из шестнадцати 32-битовых слов
(М0…М15) в восемьдесят 32-битовых слов
(W0…W79) с помощью следующего алгоритма:
Wt = Мt для t = 0...15, Wt = (Wt-3Å Wt-8Å Wt-14Å Wt-16) <<< 1 для t = 16...79,
где
t
– номер операции,
Wtt
-й субблок расширенного сообщения,
<<<
S
– циклический сдвиг влево на
S
бит.
С учетом введенных обозначений главный цикл из восьмидесяти операций можно
описать так:
цикл по t от 0 до 79 ТЕМР = (а <<< 5) ft (b, c, d) е Wt Кt е = d d = с с = (b <<< 30) b = а а = ТЕМР конец_цикла
Схема выполнения одной операции показана на рис.5.
Рис.5. Схема выполнения одной операции алгоритма SHA
После окончания главного цикла
значения а, b, с, d, е складываются с А, В, С, D, Е соответственно, и
алгоритм приступает к обработке следующего 512-битового блока данных. Окончательный выход
формируется в виде конкатенации значений А, В, С, D, Е.
Отличия SHA от MD5 состоят в следующем:
- SНА выдает 160-битовое хэш-значение, поэтому он более устойчив к атакам
полного перебора и атакам “дня рождения”, чем MD5, формирующий 128-битовые хэш-значения. - Сжимающая функция SHA состоит из 80 шагов, а не из 64 как в MD5.
- Расширение входных данных производится не простым их повторение в другом порядке, а
рекуррентной формулой. - Усложнен процесс перемешивания
Криптография, электронная подпись и pki
В данной статье мы рассмотрим, что такое Инфраструктура открытых ключей (PKI), как она устроена на логическом уровне, для чего используется, а также попытаемся выявить её плюсы и минусы. Никакой математики – только логика работы. При подготовке материала использовались лекции Антона Карпова о PKI, которые можно найти на YouTube.
ПИК Безопасности имеет богатый опыт практического внедрения, применения и сопровождения технологий, описанных в данной статье. Продукты таких вендоров, как InfoTeCS, Код безопасности, Крипто-Про представляют собой комплексные, легко масштабируемые решения, позволяющие шифровать информацию при передаче по открытым каналам связи, разворачивать инфраструктуру PKI и систему обнаружения вторжений (IDS). Полную информацию вы всегда сможете получить у наших специалистов.
Для начала разберемся для каких целей в наши дни применяется криптография:
- Конфиденциальность – невозможность прочтения информации посторонним;
- Целостность данных – невозможность незаметного изменения информации;
- Аутентификация – проверка подлинности авторства или иных свойств объекта;
- Апеллируемость – невозможность отказа от авторства.
Интересно, что конфиденциальность сообщений интересовала людей еще в Древнем мире. Наверное, образно можно говорить о том, что шифрование появилось с того момента, когда люди научились писать. Некоторые из ранних упоминаний о шифровании сообщений датируются пятым веком до н.э. Если читателя интересует история шифрования, рекомендуем к прочтению книгу Саймона Сингха “Книга шифров. Тайная история шифров и их расшифровки”. В данном труде автору удается изложить историю шифрования, начиная с древних времен и первого исторического произведения Геродота о греко-персидских войнах, до наших дней и появления квантовой криптографии – в достаточно увлекательной и захватывающей манере. В общем – категорически рекомендуем!
Ну а мы рассмотрим два принципиальных вида алгоритмов шифрования: симметричные алгоритмы шифрования и асимметричные алгоритмы шифрования.
В симметричных алгоритмах шифрования используется один и тот же ключ как для шифрования, так и для дешифрования сообщения. Таким образом, если в обмене сообщениями участвуют два субъекта, у обоих будет одинаковый ключ шифрования/дешифрования. Преимуществом данных алгоритмов шифрования является скорость работы и простота реализации. Основной же проблемой этого вида шифрования является общий ключ шифрования/дешифрования. Безопасная передача этого ключа является очень большой проблемой, ведь злоумышленник, перехватив ключ, сможет читать все сообщения. Поэтому в 70-х годах 20-го столетия появилась криптография с открытым ключом. Определяющими факторами для появления ассиметричного вида шифрования явились:
На алгоритмах RSA и Диффи-Хеллмана мы останавливаться не будем, а перейдем к сути криптографии с открытым ключом:
В ассиметричных алгоритмах шифрования для шифрования и дешифрования используются разные ключи, математически связанные между собой. Такие ключи называются ключевой парой. Один из них – закрытый (private key), другой является открытым (public key). Сообщение, которое было зашифровано на открытом ключе, может быть дешифровано только с помощью соответствующего закрытого ключа, и наоборот. Логика следующая:
- Субъект формирует ключевую пару – закрытый ключ он хранит в секрете, а копию открытого ключа он может передавать кому угодно.
- Субъект передает второй стороне свой открытый ключ.
- Вторая сторона шифрует сообщение на открытом ключе субъекта и отправляет по открытому каналу.
- Субъект расшифровывает сообщение своим закрытым ключом.
Стоит заметить, что в современных реализациях VPN (в качестве примера можно привести технологию ViPNet), используется комбинация симметричных и асимметричных алгоритмов шифрования. Например, сначала используются асимметричные алгоритмы для получения сессионного симметричного ключа шифрования (алгоритм Диффи-Хеллмана), а уже потом данные шифруются с помощью быстрого симметричного алгоритма с использованием ключа, который был выработан на первом шаге.
В нашем примере всего два субъекта и понятно, что в реальности, субъектов, обменивающихся информацией, будет гораздо больше. При этом открытый ключ не представляет из себя секрета, поэтому мы смело передаем его по открытым каналам. Таким образом, принципиальная проблема симметричных алгоритмов шифрования решена! Больше нет необходимости передавать секрет по открытым каналам связи. Но возникает другая – подтверждение подлинности открытого ключа. К примеру, субъект направляет нам свой открытый ключ и просит зашифровать на нем и отправить ему конфиденциальную информацию. При этом, мы не можем знать, действительно ли субъект является тем, за кого себя выдает, т.е. принадлежит ли открытый ключ нужному адресату. Возможно, что злоумышленник подменил открытый ключ и направил нам. Получив от нас сообщение, он сможет спокойно его расшифровать. Для решения этой проблемы и была придумана Инфраструктура открытых ключей (Public Key Infrastructure).
Перед тем, как мы перейдем к рассмотрению PKI, нужно немного сказать о технологии электронной подписи (ЭП). Существуют схемы ЭП, основанные на симметричных и асимметричных алгоритмах шифрования. Первый вариант мы рассматривать не станем ввиду малой распространенности. На асимметричных алгоритмах ЭП остановимся подробней.
В 1994 году Главным управлением безопасности связи ФАПСИ был разработан первый российский стандарт ЭЦП — ГОСТ Р 34.10-94 “Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма”.
В 2002 году для обеспечения большей криптостойкости алгоритма взамен ГОСТ Р 34.10-94 был введён одноимённый стандарт ГОСТ Р 34.10-2001, основанный на вычислениях в группе точек эллиптической кривой. В соответствии с этим стандартом, термины “электронная цифровая подпись” и “цифровая подпись” являются синонимами.
1 января 2021 года ГОСТ Р 34.10-2001 заменён на ГОСТ Р 34.10-2021 “Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи.” Применение нового ГОСТ Р 34.10-2021 обязательно с января 2021 года – об этом мы уже писали. Если вы используете электронную подпись, нужно убедиться, что ваши средства ЭП поддерживают данный стандарт.
Асимметричные технологии электронной подписи отличаются от логики работы асимметричных алгоритмов шифрования. В отличие от асимметричных алгоритмов шифрования, где сообщение шифруется на открытом ключе получателя, а дешифрование происходит с помощью закрытого ключа, в алгоритмах электронной подписи сообщение подписывается с применением закрытого ключа, а при проверке подписи используется открытая часть. Логика следующая:
- Субъект формирует ключевую пару – закрытый ключ он хранит в секрете, а копию открытого ключа он может передавать кому угодно.
- Субъект передает второй стороне свой открытый ключ.
- Субъект вычисляет контрольную сумму сообщения с помощью применения хеш-функции.
- Сообщение, вместе с контрольной суммой шифруется на закрытом ключе субъекта. Результат этого преобразования – электронная подпись, вместе с сообщением отправляется Второй стороне.
- Вторая сторона получает сообщение и электронную подпись. С помощью открытого ключа субъекта вторая сторона расшифровывает электронную подпись, а также сама вычисляет контрольную сумму сообщения.
- Вторая сторона сравнивает контрольные суммы и, если они совпадают, происходит подтверждение целостности и авторства документа, так как зашифровать контрольную сумму мог только отправитель (открытый и закрытый ключи имеют однозначное соответствие).
Парадигма PKI предполагает существование Корневого удостоверяющего центра (Certificate Authority), которому все участники взаимодействия безоговорочно доверяют. Создается иерархическая система доверия, т.е. Корневой УЦ может делегировать полномочия по подтверждению подлинности ключей пользователей другим УЦ. Система доверия выглядит как древовидная цепочка сертификатов УЦ, вплоть до конечного пользователя. Для подтверждения подлинности ключей пользователя, УЦ и выдает пользователям цифровые сертификаты.
Цифровой сертификат – это открытый ключ субъекта, подписанный закрытым ключом УЦ, содержащий в своем составе информацию о субъекте. Сертификаты создаются в соответствии со стандартом X.509, и могут использоваться для подписи, шифрования и аутентификации. Стандарт X.509 мы рассмотрим чуть дальше.
Таким образом, в состав компонентов PKI структуры входят:
- Корневой УЦ (Root CA)
- Подчиненные УЦ (Subordinate CA (IntermediateCA))
- Набор политик и регламентов
- Каталог выданных сертификатов
- Каталог отозванных сертификатов
Теперь процесс формирования ключей и обмена сообщениями, описанный ранее, в PKI выглядит следующим образом:
- Субъект формирует закрытый ключ
- Субъект формирует запрос на сертификат (CSR – Certificate Signing Request)
- Субъект отправляет запрос в УЦ
- УЦ удостоверяет личность владельца запроса и подписывает запрос своим закрытым ключом, выпуская сертификат
- Вторая сторона получает сертификат субъекта
- Вторая сторона проверяет действительность сертификата субъекта, используя цепочку вплоть до корневого сертификата УЦ, и шифрует сообщения на нем
Многие УЦ генерируют и выдают субъекту ключевую пару, т.е. открытый и закрытый ключ. Таким образом пользователь сам ничего не создает. При такой схеме возможна компрометация закрытого ключа при выдаче оператором УЦ. С другой стороны, ведь УЦ мы безоговорочно доверяем?
Еще раз остановимся на основном, фундаментальном для PKI требовании – должна быть сущность, которой все доверяют. Этой сущностью является Корневой УЦ. Если в ОС Windows открыть список доверенных корневых сертификатов (certmgr.msc -> Доверенные корневые центры сертификации), можно увидеть более 70 сертификатов УЦ, которым система доверяет по умолчанию.
Как правило, все УЦ, перечисленные в этом разделе, выдают сертификаты не пользователям, а подчиненным УЦ, которые в свою очередь работают с пользователями. Таким образом, можно приблизительно представить масштаб распространенности PKI и количество УЦ на сегодняшний день. Также нужно учитывать, что мы фактически безоговорочно доверяем создателю операционной системы, который поместил данные сертификаты в список доверенных. Конечно, для того, чтобы УЦ попал в список доверенных, он должен выполнять ряд требований, как технических, так и организационных.
Например, у Microsoft существует документ “Программа доверенных корневых сертификатов Майкрософт. Требования аудита для центров сертификации”, где описаны общие требования для УЦ.
Кроме того существует программа сертификации WebTrust – это мировой стандарт, определяющий набор правил и критериев для УЦ. Критерии стандарта WebTrust были определены The American Institute of Certified Public Accountants (AICPA) и Canadian Institute of Chartered Accountants (CICA) в 1995 году. Любой крупный УЦ регулярно должен проходить аудит WebTrust.
Сертификаты PKI, выдаваемые согласно стандарту WebTrust, имеют статус проверенных и надёжных на мировом уровне, а также попадают в список доверенных в операционных системах (Windows, MAC OS X и др.) и веб-браузерах.
В Российской Федерации, согласно Федеральному закону от 06.04.2021 N 63-ФЗ “Об электронной подписи”, аналогично с проведением международного аудита по требованиям безопасности, УЦ могут пройти процедуру аккредитации. Требования для аккредитованных УЦ устанавливает Федеральный закон и подзаконные правовые акты Минкомсвязи. Прохождение процедуры аккредитации дает право УЦ выпускать квалифицированные сертификаты электронной подписи. Такие сертификаты имеют юридическую значимость на территории РФ.
Говоря о PKI, мы по сути говорим о стандарте X.509. Стандарт X.509 предусматривает стандартную структуру сертификата (наборы полей), механизмы проверки действительности сертификата, а также стандартные механизмы получения и отзыва сертификатов:
Структура сертификата:
- Сертификат
- Версия
- Серийный номер
- Идентификатор алгоритма подписи
- Имя издателя
- Период действия:
- Имя субъекта
- Информация об открытом ключе субъекта:
- Алгоритм открытого ключа
- Открытый ключ субъекта
- Уникальный идентификатор издателя (обязательно только для v2 и v3)
- Уникальный идентификатор субъекта (обязательно только для v2 и v3)
- Дополнения (для v2 и v3)
- …возможные дополнительные детали
- Алгоритм подписи сертификата (обязательно только для v3)
- Подпись сертификата (обязательно для всех версий)
Основные форматы файла сертификата:
Согласно RFC 2459:
- .CER — сертификат, или набор сертификатов, закодированных по стандарту CER.
- .DER — сертификат, закодированный по стандарту DER.
- .PEM — PEM-сертификат, закодированный по стандарту DER и использующий Base64 и помещенный между “—– BEGIN CERTIFICATE —–” и “—– END CERTIFICATE —–“.
- .P7B, .P7C — PKCS #7 содержит несколько сертификатов или CRL.
Механизмы проверки действительности сертификата:
Любой сертификат в структуре PKI может быть скомпрометирован, поэтому стандарт X.509 предполагает механизмы их проверки. Проверка происходит с использованием “чёрных списков”. Проверка происходит по серийному номеру сертификата. Существуют два основных формата:
- CRL (Certificate Revocation List) – Список отозванных сертификатов. Публикуется УЦ на регулярной основе в публичных источниках. Имеет время жизни, которое зависит от политик и регламента УЦ. В своем составе CRL содержит серийный номер сертификата, дату и причину отзыва. CRL может содержать один из статусов: отозван (revoked) или приостановлен (hold), хотя приостановление сертификатов на практике практически не используется. Важно понимать, что CRL является оффлайн инструментом и не позволяет проверять статус сертификата в реальном времени.
- OCSP (Online Certificate Status Protocol) – сетевой протокол, который позволяет проверить статус сертификата в реальном времени. Адрес OCSP-сервера указывается в специальном поле сертификата – CDP (CRL Distribution Point). Важно обеспечить постоянную доступность OCSP-сервера.
C 31 декабря 2021 года начинает действовать редакция Федерального закона N 63-ФЗ “Об электронной подписи”, согласно которой аккредитованный УЦ будет обязан иметь в своем составе OSCP-сервер.
Проблемы стандарта X.509:
- Нет возможности ограничить подчиненные УЦ в выдаче сертификатов, т.е. если Корневой УЦ выдал сертификат подчиненному УЦ, тот может выпускать какие угодно сертификаты и у корневого УЦ нет механизмов, позволяющих это хоть как-то контролировать. Сама технология этого не предусматривает. Отсюда вытекает следующий момент: вопрос доверия огромному на сегодняшний день количеству корневых УЦ. Разве можно гарантировать, что все они прошли аудит и соблюдают правила выдачи сертификатов и аутентификации клиента перед выдачей? Если вдобавок посмотреть на политическую ситуацию в мире, то становится понятно, что использование поддельных сертификатов может быть крайне эффективным оружием в информационной войне между государствами. В этом смысле, видя решительные попытки перехода на отечественное программное обеспечение, остается только гадать, почему сертификаты для сайтов коммерческих банков, государственных органов, выданы зарубежными УЦ, ведь в процессе обеспечения информационной безопасности, одним из самых важных принципов является комплексность.
- Остается открытым вопрос: что делать, если недоступны CRL и OCSP? На текущий момент решение одно – УЦ нужно обеспечивать доступность этих компонентов.
- Что делать в случае компрометации Корневого УЦ? Ответ один: нужно отзывать корневой сертификат. При этом станут недействительны все сертификаты, выданные этим УЦ. Если взять в качестве примера Головной УЦ Минкомсвязи, который является корневым для всех сертификатов, аккредитованных УЦ в России, компрометация Головного УЦ приведет к катастрофическим последствиям в любых отношениях, использующих юридически значимую электронную подпись на территории России. На сегодняшний день насчитывается более пятидесяти сфер использования квалифицированных ЭП в нашей стране – это внешний и внутренний ЭДО, электронные торги, взаимодействие с государственными информационными системами и др.
Как видите, PKI не является идеальной инфраструктурой, и некоторые принципиальные моменты требуют решений. Тем более что сфер применения PKI становится всё больше и больше, и в глобальном значении этих областей сомневаться не приходится.
В качестве постскриптума, хочется кратко поговорить о существующих альтернативах и расширениях PKI:
Сеть доверия PGP (Pretty Good Privacy). Подробнее про PGP можно почитать в Интернете. Остановиться хочется именно на идее проверки принадлежности ключа конкретному пользователю. Как и в PKI, при использовании PGP, субъекты должны каким-нибудь способом проверить, что открытый ключ в сертификате действительно принадлежит отправителю. Если в PKI эту задачу решает существование доверенного УЦ, то в PGP используется схема проверки Web of Trust (Сеть доверия). Web of Trust основан на подписи ключей. Вы можете обозначить свое доверие ключу субъекта, которого знаете, подписав его своим ключом. Этот подписанный ключ вы можете отправить на key-server PGP (key-server выступает в роли публичного хранилища открытых ключей пользователя). Затем третье лицо, зная вас и вам доверяя, может обозначить свое доверие и тому лицу, чей ключ вы подписали. Таким образом, собирается сеть доверия. Существуют специальные мероприятия, которые называются PGP Key-signing party, где люди, показывая друг другу свои документы, удостоверяющие личность и открытый ключ (это не шутка), а затем, подписывая проверенные таким образом ключи друг друга, расширяют сеть доверия. Широкого распространения эта технология не получила и используется в довольно узких сферах (команды разработчиков, единомышленников). При этом key-server не играет ключевой роли, ключи могут быть опубликованы где угодно. Но сама идея с подписанными ключами и децентрализованной сетью доверия кажется очень интересной.
Расширение PKI – OCSP stapling. В целях снятия больших нагрузок в инфраструктуре PKI на сервер OCSP придуман механизм OCSP stapling. Он предполагает, что сайт, которому выдан сертификат, в определенные промежутки времени делает запрос в УЦ о статусе своего сертификата. УЦ отвечает метками действительности с проставлением штампа времени. При этом клиент, который заходит на сайт, видит метку УЦ на сертификате сайта, доверяет ему и не обращается к OCSP-серверу.
Расширение PKI – Certificate pinning. В общем случае клиент, который заходит на сервер, получает сертификат сервера, подписанный УЦ. Этот сертификат может быть подменен на сертификат от другого доверенного УЦ, который вдруг был взломан. Данное расширение предполагает, что на клиенте, как правило, в браузерах и мобильных приложениях, прописано соответствие серверов и сертификатов, т.е. прописан список разрешенных для домена сертификатов или УЦ, который хранится в исходных текстах браузера. Этот метод позволяет избежать подмены сертификата за счет сравнения с эталонными в защищенном хранилище браузера. Но этот метод не защищает нас от взлома УЦ, которые есть в списке соответствия данному домену.
Convergence. Так же как и в предыдущем пункте, данный метод призван защитить нас от атаки Man in the middle (MITM) или человек посередине, когда злоумышленник прослушивает канал и перенаправляет нас на свой сервер, передающий сертификат, подписанный УЦ, который находится в доверенных списках клиента. При этом мы предполагаем, что УЦ взломан. Распределенная система доверия предполагает, что в сети находятся специальные узлы, которые называются “нотариусами” (их может быть большое количество, расположены они могут быть в разных странах). Сертификаты нотариусов предварительно “зашиты” на клиенте. В момент получения сертификата с сервера, клиент, перед тем как доверять этому сертификату, обращается к “нотариусам” и просит их проверить со своей стороны, какой сертификат отдает целевой сервер при обращении к нему. Каждый нотариус идет на сервер и сравнивает сертификат сервера, который он получает с сертификатом в запросе клиента. При совпадении информации клиент доверяет сертификату сервера. Конечно, данный метод не защищает нас от взлома самого сервера.
Расширение для TLS протокола – TACK. В процессе установления соединения с сервером, клиент заявляет о поддержке расширения TACK и запрашивает TACK-ключ (эту ключевую пару генерирует администратор сервера, у данного ключа настраиваемое время жизни и порядок смены). В ответ сервер передает открытую часть TACK-ключа, сгенерированную администратором сервера. Передача происходит в рамках TLS handshake. Далее сервер передает клиенту сертификат, выданный УЦ, который подписан закрытым TACK-ключом, а клиент проверяет подпись с помощью открытой части TACK-ключа, переданной ранее. Таким образом, ответственность смещается на сторону сервера. Применение этой технологии не защищает от MITM при первоначальном подключении.
Google Key Pinning. Очень сильно похож на TACK. Отличия следующие: TACK – расширение для TLS, GKP – расширение HTTP. Ключи передаются не в рамках TLS handshake, а в заголовках сервера. У ключей GKP нет времени жизни. В целом технологии очень похожи. Стандарт предполагает генерацию резервных ключей совместно с основным ключом. В случае компрометации ключа используются резервные ключи. При этом также остается проблема MITM при первоначальном подключении.
Certificate Transparency. Технология разработана специалистами Google и призвана решить проблему поддельных сертификатов для доменов и их позднего обнаружения. Идея заключается в том, чтобы сделать невозможным создание сертификата для какого-либо домена незаметно для владельца этого домена. Технология предполагает существование трех объектов:
- Public Logs of Certificates – Постоянно расширяемый, открытый для общего доступа журнал, в который заносятся все выданные сертификаты. Предполагается, что такие журналы будут вести УЦ, записывая в них выданные сертификаты.
- Public Log Monitoring – Мониторы являются публично запускаемыми серверами, которые периодически связывают все серверы, где ведутся журналы сертификатов и следят за подозрительными сертификатами. Например, мониторы могут определить, был ли выпущен незаконный или несанкционированный сертификат для домена, а также они могут наблюдать за сертификатами, которые имеют необычные расширения, странные разрешения или, например, содержат слабые ключи. Предполагается, что Мониторы развернуты владельцами критических, с точки зрения безопасности передаваемых данных, сайтов, что позволяет отслеживать выдачу сертификатов для своих доменов или просто “неравнодушными” к проблемам безопасного интернета людей.
- Public Certificate Auditing – Аудиторы – это клиентские программные компоненты, которые выполняют две функции. Во-первых, они могут проверить, что журналы ведут себя корректно и согласовано. Во-вторых, они могут проверить, что конкретный сертификат появляется в журнале. Это особенно важная функция аудита, поскольку для платформы Transparency требуется, чтобы все сертификаты SSL регистрировались в журнале. Если сертификат не был зарегистрирован в журнале, это знак того, что сертификат является подозрительным, и клиенты TLS могут отказаться от подключения к сайтам с такими сертификатами.
На этом мы остановимся и заметим, что представленные расширения в основном направлены на решение проблемы компрометации УЦ и предлагают делегирование ответственности на других участников взаимодействия. Но, к сожалению, полностью фундаментальные проблемы это не решает и о полноценной альтернативе PKI не может идти и речи.
Также как и любое правило, которое всегда содержит исключения, любая, даже по-настоящему отличная идея, всегда будет содержать в себе недостатки. PKI решает огромную массу задач и, несмотря на имеющиеся в технологии изъяны, является одним из самых значимых применений криптографии в сфере информационных технологий на сегодняшний день. К тому же, давайте говорить прямо, это очень неплохой бизнес для сотен УЦ. Поэтому можно с уверенностью говорить, что PKI будет только расширять свое присутствие в самых различных сферах применения.
Отличия от гост р 34.10-94 (стандарт 1994—2001 гг)
Новый и старый ГОСТы цифровой подписи очень похожи друг на друга. Основное отличие — в старом стандарте часть операций проводится над полем Zp{displaystyle mathbb {Z} _{p}}, а в новом — над группой точек эллиптической кривой, поэтому требования, налагаемые на простое число p{displaystyle p} в старом стандарте (2509<p<2512{displaystyle 2^{509}<p<2^{512}} или 21020<p<21024{displaystyle 2^{1020}<p<2^{1024}}), более жёсткие, чем в новом.
Алгоритм формирования подписи отличается только в пункте 4. В старом стандарте в этом пункте вычисляются r~=akmodp{displaystyle {tilde {r}}=a^{k},{bmod {,}}p} и r=r~modq{displaystyle r={tilde {r}},{bmod {,}}q} и, если r=0{displaystyle r=0}, возвращаемся к пункту 3. Где 1<a<p−1{displaystyle 1<a<p-1} и aqmodp=1{displaystyle a^?{bmod {,}}p=1}.
Алгоритм проверки подписи отличается только в пункте 6. В старом стандарте в этом пункте вычисляется R=(az1yz2modp)modq{displaystyle R=(a^{z_{1}}y^{z_{2}},{bmod {,}}p),{bmod {,}}q}, где y{displaystyle y} — открытый ключ для проверки подписи, y=admodp{displaystyle y=a^{d},{bmod {,}}p}. Если R=r{displaystyle R=r}, подпись правильная, иначе неправильная. Здесь q{displaystyle q} — простое число, 2254<q<2256{displaystyle 2^{254}<q<2^{256}} и q{displaystyle q} является делителем p−1{displaystyle p-1}.
Использование математического аппарата группы точек эллиптической кривой позволяет существенно сократить порядок модуля p{displaystyle p} без потери криптостойкости.[2]Также старый стандарт описывает механизмы получения чисел p{displaystyle p}, q{displaystyle q} и a{displaystyle a}.
Параметры схемы цифровой подписи
- J(E)=17284a34a3 27b2(modp){displaystyle J(E)=1728{frac {4a^{3}}{4a^{3} 27b^{2}}}{pmod {p}}}, причём 4a3 27b2≢0(modp){displaystyle 4a^{3} 27b^{2}not equiv 0{pmod {p}}}.
- целое числоm{displaystyle m} — порядокгруппы точек эллиптической кривой, m{displaystyle m} должно быть отлично от p{displaystyle p}
- простое числоq{displaystyle q}, порядок некоторой циклическойподгруппы группы точек эллиптической кривой, то есть выполняется m=nq{displaystyle m=nq}, для некоторого n∈N{displaystyle nin mathbb {N} }. Также q{displaystyle q} лежит в пределах 2254<q<2256{displaystyle 2^{254}<q<2^{256}}.
- точка P=(xP,yP){displaystyle P=(x_{P},;y_{P})} эллиптической кривой E{displaystyle E}, являющаяся генератором подгруппы порядка q{displaystyle q}, то есть q⋅P=0{displaystyle qcdot P=mathbf {0} } и k⋅P≠0{displaystyle kcdot Pneq mathbf {0} } для всех k = 1, 2, …, q-1, где 0{displaystyle mathbf {0} } — нейтральный элемент группы точек эллиптической кривой E.
- h(M){displaystyle h(M)} — хеш-функция (ГОСТ Р 34.11-2021), которая отображает сообщения M в двоичные векторы длины 256 бит.
Каждый пользователь цифровой подписи имеет личные ключи:
Дополнительные требования:
Проверка цифровой подписи
- Вычисление по цифровой подписи ξ{displaystyle xi } чисел r{displaystyle r} и s{displaystyle s}, учитывая, что ξ=(r¯|s¯){displaystyle xi =({bar {r}}|{bar {s}})}, где r{displaystyle r} и s{displaystyle s} — числа, соответствующие векторам r¯{displaystyle {bar {r}}} и s¯{displaystyle {bar {s}}}. Если хотя бы одно из неравенств r<q{displaystyle r<q} и s<q{displaystyle s<q} неверно, то подпись неправильная.
- Вычисление хеш-функции от сообщения М: h¯=h(M).{displaystyle {bar {h}}=h(M).}
- Вычисление e=zmodq{displaystyle e=z,{bmod {,}}q}, и если e=0{displaystyle e=0}, положить e=1{displaystyle e=1}. Где z{displaystyle z} — целое число соответствующее h¯.{displaystyle {bar {h}}.}
- Вычисление ν=e−1modq.{displaystyle nu =e^{-1},{bmod {,}}q.}
- Вычисление z1=sνmodq{displaystyle z_{1}=snu ,{bmod {,}}q} и z2=−rνmodq.{displaystyle z_{2}=-rnu ,{bmod {,}}q.}
- Вычисление точки эллиптической кривой C=z1P z2Q{displaystyle C=z_{1}P z_{2}Q}. И определение R=xcmodq{displaystyle R=x_{c},{bmod {,}}q}, где xc{displaystyle x_{c}} — координата x{displaystyle x} точки C.{displaystyle C.}
- В случае равенства R=r{displaystyle R=r} подпись правильная, иначе — неправильная.
Формирование цифровой подписи
Блок-схемы:
- Вычисление хеш-функции от сообщения М: h¯=h(M){displaystyle {bar {h}}=h(M)}
- Вычисление e=zmodq{displaystyle e=z,{bmod {,}}q}, и если e=0{displaystyle e=0}, положить e=1{displaystyle e=1}. Где z{displaystyle z} — целое число, соответствующее h¯.{displaystyle {bar {h}}.}
- Генерация случайного числа k{displaystyle k} такого, что 0<k<q.{displaystyle 0<k<q.}
- Вычисление точки эллиптической кривой C=kP{displaystyle C=kP}, и по ней нахождение r=xcmodq,{displaystyle r=x_{c},{bmod {,}}q,} где xc{displaystyle x_{c}} — это координата x{displaystyle x} точки C.{displaystyle C.} Если r=0{displaystyle r=0}, возвращаемся к предыдущему шагу.
- Нахождение s=(rd ke)modq{displaystyle s=(rd ke),{bmod {,}}q}. Если s=0{displaystyle s=0}, возвращаемся к шагу 3.
- Формирование цифровой подписи ξ=(r¯|s¯){displaystyle xi =({bar {r}}|{bar {s}})}, где r¯{displaystyle {bar {r}}} и s¯{displaystyle {bar {s}}} — векторы, соответствующие r{displaystyle r} и s{displaystyle s}.