Public key infrastructure

Вступление

В настоящее время интеллектуальные транспортные системы (англ.: Intelligent Transport Systems, ITS) активно развиваются. Их функционирование невозможно без создания телекоммуникационных систем, позволяющих транспортным средствам обмениваться информацией со внешними устройствами (англ. Vehicle-to-Everything, V2X). Транспортные средства накапливают информацию посредством различных сенсоров, радаров, лидаров и камер. Для обеспечения автономного вождения и передвижения машин в плотном строю (так называемый platooning) необходимо обеспечивать обмен этой информацией между различными транспортными средствами. Обмен информацией может также осуществляться с элементами дорожной инфраструктуры, что позволяет обеспечивать большую безопасность движения посредством передачи объектами инфраструктуры предупреждающих сообщений. Кроме того, существует большое число других приложений, которые обеспечивают удобство вождения и безопасность, а также уменьшают число пробок и предоставляют различные развлекательные сервисы. Разнообразные приложения порождают различные требования на задержки, надёжность и скорость беспроводной передачи данных. Однако кроме требований на производительность сети во многих случаях важно, чтобы передаваемые данные были защищены. В этой статье я хотел бы дать краткий обзор основных механизмов стандарта IEEE 1609.2, который описывает методы защиты информации в транспортных сетях, построенных по технологии Wi-Fi.

DSRC телекоммуникации

На данный момент одним из самых распространённых способов коммуникации в V2X является выделенная связь на короткие расстояния (англ.: Dedicated Short Range Communications, DSRC), для обеспечения которой используется набор стандартов беспроводной связи в транспортной среде: стандарты IEEE 1609 и IEEE 802.11p. Комитетом IEEE был выпущен специальный гайд, в котором они детально описаны. Заинтересовавшиеся могут найти его по ссылке.

Набор стандартов для DSRC

Стандарт IEEE 802.11p описывает работу физического и основной части MAC уровня модели OSI в диапазоне частот 5,9 ГГц (и 60 ГГц опционально). Как видно, этот диапазон частот отличается от частот, на которых работает "классический Wi-Fi": 2,4 ГГц и 5 ГГц. "Классические" частоты являются нелицензируемыми, и это приводит к их зашумлённости передачами устройств, работающих по другим стандартам, что крайне нежелательно для транспортных сетей, которые сделаны в частности для поддержки приложений, обеспечивающих безопасность дорожного движения. В свою очередь, диапазон частот в 5,9 ГГц является бесплатным и лицензированным в том плане, что в этом диапазоне могут работать только устройства, использующие определённый набор стандартов. Стандарт IEEE 1609.4 описывает многоканальные методы доступа к среде, которые позволяют поочерёдно передавать сразу в двух каналах, например, канале для передачи данных и канале для контрольных сообщений. IEEE 1609.3 описывает WSMP (Wave Short Message Protocol), который является альтернативой протоколам TCP/UDP и IP на транспортном и сетевом уровне соответственно. Также стандарт IEEE 1609.3 выполняет некоторые другие функции, например, выбор канала для передачи данных. Стандарт IEEE 1609.2 описывает методы обеспечения безопасной передачи данных и именно ему я хотел бы уделить внимание в данной статье.

Основные положения IEEE 1609.2

Стандарт IEEE 1609.2 основывается на асимметричной криптографии и в частности описывает методы шифрования сообщений и методы создания цифровой подписи. Единицей данных для этого стандарта является так называемый SPDU (Secured Protocol Data Unit), который состоит из защищаемых данных и специальных полей для обеспечения защиты информации. IEEE 1609.2 защищает только данные, являющиеся полезной нагрузкой для протокола транспортного уровня. То есть заголовки транспортного, сетевого, LLC, MAC, а тем более физического уровней стандарт IEEE 1609.2 не защищает. Пример пакета, который иллюстрирует местоположение защищаемых данных, представлен на рисунке ниже. Базовая структура SPDU стандарта IEEE 1609.2 представлена здесь под буквой D:

Местоположение данных, защищаемых стандартом IEEE 1609.2

Так как трафик в транспортных сетях по большей части является широковещательным, описывать методы шифрования я не буду, так как при шифровании у принимающего устройства есть секретный ключ, известный только ему, а у передающих открытый - расшифровать сообщений может только принимающее устройство, то есть передача должна быть не широковещательной, а по конкретному адресу. Поэтому я сосредоточусь на описании инфраструктуры для криптографии с открытым ключом (англ.: PKI, Public Key Infrastructure) применительно к транспортным сетям и на алгоритме создания и проверки цифровой подписи. Цифровая подпись используется для проверки того, что отправитель сообщения действительно является тем устройством, за которое себя выдаёт, и для проверки того, что данные не были изменены сторонним устройством. Для создания цифровой подписи устройство использует свой секретный ключ и добавляет значение цифровой подписи в специальные поля SPDU. Проверить сообщение на подлинность может любое устройство, которое знает открытый ключ, соответствующий секретному ключу передающего устройства. Так как для проверки цифровой подписи необходимо знать только открытый ключ, то добавлять цифровую подпись можно даже к широковещательным сообщениям, например, к базовым сообщениям приложений безопасности (англ.: Basic Safety Messages, BSM) и к beacon-ам (специальные кадры технологии Wi-Fi, применяемые для обмена служебной информацией). О том как устройства узнают открытый ключ, соответствующий секретному ключу, я расскажу в следующей главе.

Инфраструктура открытых ключей в сетях V2X

Сразу оговорюсь, что далее я буду говорить только о транспортных средствах, поддерживающих процедуру создания и проверки электронной подписи по стандарту IEEE 1609.2, так как на данный момент этот стандарт поддерживают не все транспортные средства. Сперва я хотел бы отметить, что у каждого транспортного средства имеется 2 типа секретных ключей: долгосрочный и краткосрочный. При этом краткосрочных ключей может быть несколько. Долгосрочный секретный ключ выдаётся при производстве транспортного средства по договорённости производителя и властей того региона, где ключ выдавался. Выдаётся он вместе с соответствующим открытым ключом, некоторой технической и идентификационной информацией о транспортном средстве и сертификатом открытого ключа (сертификат содержит открытый ключ и некоторую информацию о владельце соответствующего секретного ключа). Долгосрочный секретный ключ известен только устройству, которому он выдан, и хранится в так называемом аппаратном защитном модуле транспортного средства, из которого секретный ключ не так-то просто достать. Открытый ключ, его сертификат и некоторая идентификационная информация устройства хранятся в сертификационном центре (англ.: Certification Authority, CA), из которого другие устройства могут получить информацию о сертификате и открытом ключе зарегистрированного устройства. Стоит отметить, что во время производства нового транспортного средства оно получает также 2 открытых ключа сертификационного центра: один для проверки электронной подписи сообщений, переданных от CA, а второй на случай, если злоумышленнику удастся узнать первый секретный ключ CA. Если злоумышленнику удастся узнать этот ключ, то CA сможет сменить секретный и открытый ключ, разослав новый открытый ключ всем устройствам и подписав сообщение вторым секретным ключом. Стоит отметить, что время жизни долгосрочного секретного ключа должно быть равно времени жизни транспортного средства или по крайней мере составлять большую часть его жизни.

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

Я довольно много говорил об обмене информацией между CA и нашим устройством, но не сказал, как он осуществляется. Для пояснения я приведу следующую картинку:

Обмен информацией между сертификационным центром и транспортным средством

Транспортные средства обмениваются информацией с CA посредством придорожной инфраструктуры (англ.: Road-Side Unit, RSU). Ранее я писал, что стандарт IEEE 1609.2 защищает только полезную нагрузку транспортного уровня, но не заголовки транспортного уровня и нижележащих уровней модели OSI, что позволяет RSU и другим устройствам, выполняющим роль маршрутизатора, передавать сообщения от транспортного средства к CA и обратно, даже не имея возможности узнать содержимое сообщения (если оно зашифровано, например). То есть обмен информацией между автомобилями и CA осуществляется через RSU.

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

Стоит отдельно отметить, что CA может не только регистрировать сертификаты, но и отзывать их по истечении срока жизни или по каким-то иным причинам. Так что если злоумышленник захочет сбить систему дорожной безопасности транспортного средства с толку, но сертификат открытого ключа злоумышленника не будет зарегистрирован в CA, то у него ничего не выйдет. Больше информации об инфраструктуре открытых ключей в транспортных сетях можно узнать, например, из статьи 1 или статьи 2, на которых основывается мой рассказ про инфрастурктуру открытых ключей в V2X.

Параметры алгоритма создания электронной подписи и операции на эллиптических кривых

Для создания и проверки электронной подписи в стандарте IEEE 1609.2 используется алгоритм цифровой подписи на основе эллиптических кривых (англ.: Elliptic Curve Digital Signature Algorithm, ECDSA). Здесь я дам его краткое описание. Больше информации об этом алгоритме и криптографии на эллиптических кривых можно найти, например, в этой статье на хабре или в этой научной статье. Алгоритм ECDSA позволяет создать электронную подпись сообщения с помощью закрытого ключа, а затем проверить её с помощью открытого. То есть отправитель должен знать секретный ключ, а все принимающие устройства должны знать открытый ключ. Однако кроме знания одного из двух ключей устройства также должны знать параметры алгоритма. Первыми двумя параметрами алгоритма являются коэффициенты используемой эллиптической кривой. В алгоритме ECDSA используются эллиптические кривые форме Вейерштрасса, под которыми в криптографии подразумевается множество точек (x, y) следующего вида (далее под эллиптической кривой буду подразумевать именно это множество точек):

Здесь - это поле Галуа, состоящее из целых чисел от 0 до p - 1, где p - простое число, либо степень простого числа. В криптографии p выбирают либо простым числом, либо степенью двойки. Числа a и b, являющиеся параметрами эллиптической кривой, также принадлежат . Дополнительное условие на эти коэффициенты делает эллиптическую кривую применимой в криптографии. Под "0" подразумевается нулевой элемент эллиптической кривой, при прибавлении которого к любому элементу получится тот же самый элемент. Геометрически нулевой элемент - это бесконечно удалённая точка расширенной действительной плоскости. Стоит отметить, что эллиптическая кривая имеет конечное число элементов и при правильном введении операции сложения и взятия обратного элемента становится абелевой группой относительно этой операции сложения. Чтобы геометрически пояснить операцию сложения и взятия обратного элемента, я вставлю сюда картинку, которая иллюстрирует вид эллиптической кривой в , то есть кривой вида:

Операция сложения на эллиптической кривой в форме Вейерштрасса

Красная кривая - это качественный вид эллиптической кривой, задаваемой уравнением выше. У такой кривой есть ось симметрии, которая в данном случае проходит через ось абсцисс. Ось симметрии позволяет ввести понятие обратного элемента: точка P эллиптической кривой называется обратной к точке M эллиптической кривой, если точка M симметрична точке P относительно оси симметрии нашей эллиптической кривой. Результат сложения симметричных точек M и P определяется следующим образом:

Стоит отметить, что на представленном выше рисунке изображена не только сама эллиптическая кривая, но и геометрический смысл операции сложения. Чтобы найти сумму двух разных точек эллиптической кривой, не симметричных относительно оси симметрии этой кривой (на рисунке точки P и Q), необходимо провести через них прямую и найти её точку пересечения с кривой (точка пересечения существует в силу условий на параметры a и b). Тогда суммой точек эллиптической кривой называется точка, обратная к указанной выше точке пересечения. Для нахождения результата сложения некоторой точки эллиптической кривой с самой собой (на рисунке P + P) необходимо провести касательную к этой точке, найти пересечение касательной с эллиптической кривой (пересечения опять-таки существует в силу условий на a и b) и взять точку, обратную к пересечению. Для реализации алгоритма ECDSA на компьютере указанные выше операции сложения необходимо записать в аналитическом виде. Это можно сделать, используя методы аналитической геометрии. Здесь я напишу лишь конечные формулы для сложения точек в полях Галуа. Будьте внимательны! Я не зря выделил последнюю фразу жирным шрифтом. Под делением в полях Галуа я подразумеваю взятие обратного элемента: элемент x поля Галуа называется обратным к элементу y поля Галуа если:

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

В свою очередь, формула для сложения точки с самой собой имеет вид:

Однако a, b и p - это не единственные параметры алгоритма ECDSA. Дело в том, что алгоритм ECDSA работает не на всей эллиптической кривой, а на её циклической подгруппе, образуемой некоторой генерирующей точкой G эллиптической кривой. Все элементы этой подгруппы получаются путём сложения точки G с самой собой некоторое число раз. Порядок этой подгруппы (то есть число элементов в ней) является пятым параметром алгоритма ECDSA. По-другому порядок подгруппы можно определить как наименьшее положительное целое число n такое, что: nG = "0". Последним параметром является так называемый кофактор подгруппы. Он определяется следующим образом:

Здесь под N подразумевается порядок всей эллиптической кривой, то есть число элементов в ней. В силу так называемой теоремы Лагранжа, n всегда является делителем числа N, так что кофактор определён корректно.

В стандарте IEEE 1609.2 возможно использование лишь определённого набора параметров, для которых нет общеизвестных методов быстрого взлома алгоритма ECDSA (о том, как его можно взломать я расскажу чуть позже). Используемый набор параметров для передающего устройства можно получить вместе с его открытым ключом от CA. Примеры этих наборов можно найти, например, в этой статье в разделе ECDSA.

Алгоритм ECDSA

Теперь перейду к описанию самого алгоритма ECDSA. Этот алгоритм работает не с самим передаваемым сообщением, а с его хэшем. Хэш-функция позволяет преобразовать сообщение произвольной длины в последовательность бит фиксированной длины. При этом данное преобразование выполняется таким образом, что восстановление всех возможных исходных значений сообщения по заданному значению хэша является вычислительно сложной задачей, тогда как вычисление самой хэш-функции можно произвести быстро. Полученную после действия хэш-функции последовательность бит можно интерпретировать как десятичное число в двоичной форме записи. Именно это число используется алгоритмом ECDSA. Если это число получается большим, чем n, то хэш сообщения необходимо урезать. Стандарт IEEE 1609.2 определяет всего 2 допустимые хэш-функции: SHA-256 и SHA-384.

Теперь перейду к описанию процедуры генерации открытого и закрытого ключей. Закрытый ключ d является случайно выбранным элементом поля Галуа, лежащим в интервале [1, n - 1]. Открытый ключ вычисляется из закрытого по следующей формуле (здесь и далее набор параметров алгоритма (p, a, b, G, n, h)):

Для вычисления значения открытого ключа по закрытому ключу и генерирующей точке существуют эффективные алгоритмы, позволяющие вычислить открытый ключ быстро. А вот обратная задача, то есть вычисление закрытого ключа по известной генерирующей точке и открытому ключу, считается сложной. Эта задача называется задачей дискретного логарифмирования, и именно на сложности её решения базируется криптографическая стойкость алгоритма ECDSA. Для того чтобы эта задача была по-настоящему сложной и не решалась за приемлемое время на обычных компьютерах, необходимо выбирать большие значения p и n. Например, для одного из специфицируемых стандартом IEEE 1609.2 набора параметров алгоритма ECDSA под названием NIST P-224 параметры p и n имеют следующие значения:

Теперь перейду к процедуре генерации электронной подписи алгоритмом ECDSA. Выпишу её в виде алгоритма (m - это исходное сообщение):

1) - Сперва необходимо выбрать случайное число:

2) - Далее вычисляем точку и число:

3) - Если r = 0, то возвращаемся к шагу 1

4) - Затем необходимо вычислить значение:

5) - Если s = 0, то возвращаемся к шагу 1

6) - Возвращаем сообщение m и пару чисел (r, s)

Процедура проверки электронной подписи выглядит следующим образом:

1) - Проверяем, что:

2) - Вычисляем значения:

3) - Вычисляем точку:

4) - Подпись действительна тогда и только тогда когда:

Проверка корректности алгоритма

Теперь проверим корректность этого алгоритма (нестрого). Сперва перепишем P в несколько другом виде, учитывая что :

Учитывая определение и , получим:

Ранее было дано следующее определение:

Умножив обе части уравнения на k и поделив на s, мы получим, что:

А это значит, что:

Из написанной выше проверки корректности следует, что посредством этого алгоритма значение r было вычислено двумя способами: на передающем устройстве с помощью закрытого ключа и на принимающем с помощью открытого. Затем 2 значения r были сопоставлены друг с другом.

Заключение

В данной статье были рассмотрены базовые принципы функционирования стандарта IEEE 1609.2, описывающего защиту информации в транспортных сетях, работающих по технологии Wi-Fi. Сперва был рассмотрен набор стандартов для беспроводной связи в транспортных сетях. Затем был сделан обзор методов распределения открытых и генерации секретных ключей в сетях V2X. Далее была описана арифметика криптографии на эллиптических кривых и алгоритм ECDSA, используемый для создания электронной подписи в стандарте IEEE 1609.2. В конце была проверена корректность алгоритма ECDSA.

Памятка для удостоверяющих центров и других участников PKI

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

УЦ должен работать, как часы. От его правильного функционирования зависит электронный документооборот множества клиентов и систем.

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

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

В этом посте я хочу рассказать, с какими критическими проблемами и нарушениями в работе УЦ часто приходится сталкиваться, а также о том, как их избежать.

У полноправного участника Public Key Infrastructure, должна быть информационная система со встроенными СКЗИ, которая позволяет вести электронный документооборот с клиентами и партнерами, обмениваясь с ними документами с электронной подписью (ЭП) или зашифрованными данными.

Когда партнер присылает документы с ЭП, система выполняет ряд действий. Она проверяет электронную подпись на документе и партнерский сертификат открытого ключа проверки этой подписи.

В частности, для сертификата партнера строится путь сертификации - цепочка сертификатов, от его конечного пользовательского, на котором проверилась ЭП, до корневого центра сертификации.

В случае с квалифицированными сертификатами корневым будет сертификат Министерства цифрового развития, связи и массовых коммуникаций, а промежуточным между корневым и конечным пользовательским сертификат аккредитованного УЦ, выданный головным УЦ Министерства цифрового развития.

Для квалифицированных сертификатов также выполняются проверки согласно 63-ФЗ Об электронной подписи и Приказа ФСБ РФ 795. Контролируется наличие и правильность заполнения всех необходимых атрибутов в сертификате пользователя.

Одна из главных задач контроля и ключевых фишек PKI в автоматическом электронном обмене документами это необходимость и возможность убедиться, что сертификат не был отозван партнером и УЦ подтверждает, что сертификат действующий.

Сбои и некорректная работа УЦ в части публикации CRL

В сертификатах есть атрибут CDP - CRL Distribution Points, в нем УЦ публикует ссылки на свой список отозванных сертификатов - Certificate Revocation List

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

CRL тоже подписан ЭП удостоверяющего центра, что дает дополнительную защиту от подмены и атак посредника Man in the middle при его загрузке по открытому каналу. Он содержит атрибуты с периодом своего действия и серийные номера отозванных сертификатов.

Процедура полной проверки сертификата на отзыв сводится к необходимости загрузить список с указанного URL, проверить срок его действия, проверить ЭП, убедиться, что серийного номера данного сертификата в нем нет.

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

Такие документы будут отвергнуты до восстановления возможности проверить сертификат на отзыв.

То же самое касается контроля клиентских и серверных сертификатов, которые используются для построения защищенного канала связи TLS ГОСТ или TLS RSA по протоколу HTTPS. Если системам партнеров не удается проверить их на отзыв, то защищенное и 100% доверенное соединение партнеры установить между собой не смогут.

Какие сбои и нарушения здесь может допустить УЦ?

1. Перенаправление ссылок (Redirect)

УЦ опубликовал в сертификате конкретный URL, но на сервере, где этот ресурс опубликован, происходит перенаправление клиента на другой URL.

Вызывающая система на Java может легко определить, что включено перенаправление следующим образом:

private static final String ATTENTION_CRL_REDIRECT_DETECTED = "Attention CRL redirect detected: ";    private static final String LOCATION = "Location";   URL url = new URL(crlURL);        InputStream crlStream = null;        URLConnection connection = url.openConnection();        String redirect = connection.getHeaderField(LOCATION);        if (redirect != null) {            throw new DownloadCRLException(                    ATTENTION_CRL_REDIRECT_DETECTED + crlURL + STRING_DIRECTION + redirect);        }

2. HTTPS в CDP атрибуте сертификата и ни одной общедоступной ссылки

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

Попадались сертификаты с https://, ldap:// или защищенный SFTP, также были просто URL с IP адресами из внутренней подсети. Все эти ссылки допустимы при наличии хотя бы одной ссылки HTTP или FTP (без логина и пароля) доступной из сети Internet всем.

Почему HTTPS к свободным не относится?

За списками отзыва могут обращаться далеко не только интернет-браузеры, имеющие обширное хранилище корневых доверенных сертификатов международных УЦ, которое позволяет им поднимать защищенное соединение по HTTPS-ссылке и принимать ресурс как доверенный.

Другие информационные системы могут не иметь такого хранилища с предустановленными корневыми сертификатами и не обязаны поднимать контекст защищенного соединения к HTTPS-ссылкам.

Просто невозможно во все системы установить все корни для всего многообразия УЦ, выпускающих SSL/TLS-сертификаты.

По понятным причинам информационные системы также не могут знать логин и пароль от FTP и не будут иметь доступ к внутренней службе Active Directory по LDAP-протоколу.

Поэтому принято, что CRL публикуется в свободном доступе.

3. HTTP перенаправление (redirect) на HTTPS

Это гибридная ситуация, с которой приходилось сталкиваться, состоящая из приведенных выше пунктов 1 и 2.

Как такое возможно?

Сайт компании, где УЦ публикует свои списки отзыва, или просто веб-сервер, который используется удостоверяющим центром для этих целей, запущен, например, на Nginx.

Администратор сайта, желающий исключительно добра и защитить сайт и пользователей, совершенно забыв, а может, и не зная про публикацию CRL, включает безусловный redirect всего сайта на HTTPS.

server {    listen 80 default_server;    listen [::]:80 default_server;    server_name _;    return 301 https://$host$request_uri;}

Получается, что в сертификате приведен URL с http://, а системы, которые чувствительны к такому факту подмены подписанной информации из сертификата и справедливо защищаются от атак посредников, перестают загружать списки отзыва данного УЦ, пока администратор не настроит на сайте исключения для CRL.

4. Фильтрация по User Agent

Данная проблема и нарушение доступа к спискам отзыва сильно перекликается с приведенной в пункте 3.

Тот же администратор сайта, на том же Nginx включает фильтрацию по User Agent. Например, все системы на Java будут получать ошибку HTTP 403 при обращении к ресурсу.

Администратор забывает про то, что совершенно любая система должна иметь доступ к спискам отзыва в соответствии со стандартами группы PKIX.

if ($http_user_agent = "Mozilla/5.0 (Linux; Android 4.2.2; SGH-M919 Build/JDQ39) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.169 Mobile Safari/537.22"){    return 403;}if  ($http_user_agent ~* "^Java"){ return 403; }

Еще администратор сайта, где публикуются списки отзыва, может включить redirect на основе User Agent.

5. Просроченный CRL

Сертификат может содержать несколько ссылок на списки отзыва. Внутри каждого CRL могут быть вложены ссылки на его дельты с иными, более короткими сроками жизни, а следовательно, обновляемые чаще.

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

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

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

Были случаи, когда по каким-то причинам УЦ своевременно не обновлял CRL.

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

6. Сбои на сетевом и транспортном уровне

В качестве примера можно привести ситуацию со сбоем или некорректными настройками и состоянием на оборудовании удостоверяющего центра или сайта организации.

В сертификате, выпущенном УЦ, может быть прописано два URL с http:// и разными host именами. Такой подход правильный, он позволяет иметь резерв и всегда держать одну ссылку в доступе, если требуется провести какие-то работы на другом сервере.

Но вот незадача. Вызывающая система вдруг начинает получать IOException: ConnectionTimeOut при попытке подключения к одной из ссылок. Вторая ссылка при этом работает и отдает CRL. А вызывающая система все равно начинает замедляться на настроенное в ней время, например, ConnectionTimeOut=15000 mSec, потому что проверяет обе ссылки, и ей приходится ждать ответа от недоступной в настоящий момент.

А если в CDP сертификата четыре, пять разных ссылок на CRL и при этом две или три из них оказываются недоступны с ConnectionTimeOut?

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

А что, если обмен нашей информационной системы идет с этим УЦ или партнером, организацией, аффилированной с данным УЦ? И система партнера имеет свой таймаут на вызов нашей информационной системы, который заведомо меньше того времени, которое наша система тратит на проверку их сертификата?

Получается коллизия.

Партнеры говорят нам, что не получают ответ от нашей системы и отключаются по таймауту, а происходит это на самом деле из-за регламентных работ на их УЦ.

Почему может происходить ConnectionTimeOut?

Как вариант, это регламентные работы, сетевая атака или повышенная нагрузка на сайт УЦ, что привело к неконсистентному состоянию:

• какой-то брандмауэр, файрвол на пути, который просто начал съедать сетевые пакеты, не сообщая отправителю такие вещи, как "No Route to host"

• началась потеря пакетов из-за неправильной конфигурации сети или перегрузки линии

• слишком много запросов, перегружающих сервер

• небольшое количество одновременно доступных потоков / процессов на сервере, что приводит к их блокировке. Это происходит особенно с запросами, выполнение которых занимает много времени и может сочетаться с предыдущим пунктом

Как с этим справляться?

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

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

Если точка публикации будет корректно отключена, то вызывающая система, мгновенно получив от этой ссылки, например, IOException Connection Refused: connect, сразу перейдет к загрузке по следующему URL.

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

Чем должны руководствоваться УЦ при публикации CRL

RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

Спецификацией RFC 5280 IETF и стандартом X.509 ITU-T, разработанными Инженерным советом Интернета и Международным консультационным комитетом по телефонии и телеграфии.

В частности, пунктом 8. Security Considerations из RFC 5280

When certificates include a cRLDistributionPoints extension with an https URI or similar scheme, circular dependencies can be introduced. The relying party is forced to perform an additional path validation in order to obtain the CRL required to complete the initial path validation! Circular conditions can also be created with an https URI (or similar scheme) in the authorityInfoAccess or subjectInfoAccess extensions. At worst, this situation can create unresolvable dependencies.

CAs SHOULD NOT include URIs that specify https, ldaps, or similar schemes in extensions. CAs that include an https URI in one of these extensions MUST ensure that the server's certificate can be validated without using the information that is pointed to by the URI. Relying parties that choose to validate the server's certificate when obtaining information pointed to by an https URI in the cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess extensions MUST be prepared for the possibility that this will result in unbounded recursion.

УЦ не должны включать HTTPS или LDAP-ссылки для публикации своих списков отзыва.

Если УЦ все же включают такие ссылки, то они должны убедиться, что серверные сертификаты могут быть проверены без использования этих ссылок.

Также удостоверяющим центрам следует знать и помнить, что включение HTTPS-ссылок на свои списки отзыва, в том числе в серверные сертификаты для того же HTTPS-канала, может создавать циклические неразрешимые зависимости и привести к неограниченной рекурсии в попытках проверить сертификат на отзыв и установить защищенное соединение с применением этого же сертификата.

Другими словами, клиент и сервер будут пытаться поднять защищенное HTTPS-соединение друг с другом. Для этого им потребуется проверить сертификаты на отзыв. А чтобы это сделать, тоже нужно поднять защищенное соединение по HTTPS-ссылке к CRL, которую УЦ неосмотрительно опубликовал в атрибуте сертификата.

Следует упомянуть, что существует иной способ проверки сертификата на отзыв.

Протокол онлайн-проверки статуса сертификата OCSP - Online Certificate Status Protocol.

Такие сертификаты также включают в себя стандартный атрибут CDP и могут проверяться обычным способом.

А для работы с сервером OCSP они должны включать еще и расширение OCSP Server Client.

Но это материал для отдельнойстатьи.

Обязательные атрибуты квалифицированных сертификатов

Состав квалифицированного сертификата регулируется Федеральным законом "Об электронной подписи" от 06.04.2011 N 63-ФЗ и Приказом ФСБ РФ от 27 декабря 2011 г. N 795 "Об утверждении Требований к форме квалифицированного сертификата ключа проверки электронной подписи".

Несколько раз встречались квалифицированные сертификаты проверки подписи юридических лиц, выпущенные аккредитованным УЦ, в которых в поле Subject - субъект сертификации отсутствовал атрибут L Местоположение.

Контроль квалифицированных сертификатов нашей системы отвергал данный сертификат и документы с ЭП партнера.

Удостоверяющий центр данную ситуацию комментировал так:

атрибут L для юридических лиц, зарегистрированных в г. Москве, не проставляется согласно 63-ФЗ и Приказа 795

На конкретный пункты Закона и Приказа в УЦ не ссылались.

Собственный повторный анализ юридических аспектов показал:

63-ФЗ от 06.04.2011 "Об электронной подписи"

Статья 14. Сертификат ключа проверки электронной подписи

2. Сертификат ключа проверки электронной подписи должен содержать следующую информацию:

2) фамилия, имя и отчество (если имеется) - для физических лиц, наименование и место нахождения - для юридических лиц или иная информация, позволяющая идентифицировать владельца сертификата ключа проверки электронной подписи;

Статья 17. Квалифицированный сертификат

2. Квалифицированный сертификат должен содержать следующую информацию:

2) фамилия, имя, отчество (если имеется) владельца квалифицированного сертификата - для физического лица, не являющегося индивидуальным предпринимателем, либо фамилия, имя, отчество (если имеется) и основной государственный регистрационный номер индивидуального предпринимателя - владельца квалифицированного сертификата - для физического лица, являющегося индивидуальным предпринимателем, либо наименование, место нахождения и основной государственный регистрационный номер владельца квалифицированного сертификата - для российского юридического лица, либо наименование, место нахождения владельца квалифицированного сертификата, а также идентификационный номер налогоплательщика (при наличии) - для иностранной организации (в том числе филиалов, представительств и иных обособленных подразделений иностранной организации);

Приказ ФСБ РФ от 27 декабря 2011 г. 795

III. Требования к порядку расположения полей квалифицированного сертификата

5) stateOrProvinceName (наименование штата или области).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование соответствующего субъекта Российской Федерации. Объектный идентификатор типа атрибута stateOrProvinceName имеет вид 2.5.4.8;

6) localityName (наименование населенного пункта).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование соответствующего населенного пункта. Объектный идентификатор типа атрибута localityName имеет вид 2.5.4.7;

7) streetAddress (название улицы, номер дома).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую часть адреса места нахождения соответствующего лица, включающую наименование улицы, номер дома, а также корпуса, строения, квартиры, помещения (если имеется). Объектный идентификатор типа атрибута streetAddress имеет вид 2.5.4.9;

В сертификате партнера в имени субъекта сертификации были указаны: stateOrProvinceName (наименование штата или области), streetAddress (название улицы, номер дома).

И не указано localityName (наименование населенного пункта).

locality - Местонахождение

В Законе 63-ФЗ и Приказе 795 нет информации, что для города Москва не нужно заполнять атрибут locality - Местонахождение.

Наоборот в обоих документах на русском языке применяется термин место нахождения, чему соответствует атрибут localityName ( 2.5.4.7)

После данного разбора удалось найти документ ФСБ РФ ИЗВЕЩЕНИЕ ОБ ИСПОЛЬЗОВАНИИ АТРИБУТА ИМЕНИ LOCALITYNAME ПОЛЯ SUBJECT В СТРУКТУРЕ КВАЛИФИЦИРОВАННОГО СЕРТИФИКАТА КЛЮЧА ПРОВЕРКИ ЭЛЕКТРОННОЙ ПОДПИСИ

Согласно части 2.2 статьи 18 Закона об ЭП для заполнения квалифицированного сертификата в соответствии с частью 2 статьи 17 Закона об ЭП аккредитованный удостоверяющий центр запрашивает и получает из государственных информационных ресурсов, в том числе, выписку из единого государственного реестра юридических лиц в отношении заявителя юридического лица.

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

На основании изложенного в качестве значения атрибута имени localityName поля subject в структуре квалифицированного сертификата следует указывать текстовую строку, содержащую наименование соответствующего населенного пункта или соответствующего муниципального образования.

Данное извещение с разъяснениями регулятора, как правильно заполнять атрибут L в квалифицированном сертификате юридического лица, также было направлено в аккредитованный УЦ.

Прошу использовать данную информацию в работе.

Желаю всем участникам PKI удачи и успехов!