Модификация процедуры проверки электронной подписи

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

проверки. Проверка статуса сертификата требует получения данных о сертификате от УЦ который его выпустил, эти данные предоставляются одним из методов, которые описаны далее. Использование CRL - наиболее распространенный метод информирования пользователей о том, что сертификат их контрагента был отозван. Недостаток метода состоит в том, что существует «окно опасности», разница во времени между временем отзыва сертификата пользователя и временем, когда публикуется новый CRL. Использование протокола OCSP - это наиболее точный способ информирования пользователей о том, что сертификат их контрагента был отозван. Недостатком данного протокола является то, что он требует сетевой доступности УЦ, выпустившего сертификат подписанта на момент проверки его подписи, кроме того, не все реализации УЦ поддерживают данный протокол. Для данного метода «окно опасности» также существует, но оно меньше чем для CRL.

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

1.1.    Сценарии успешной проверки скомпрометированных ЭП

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

Сценарий №1

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

Сценарий №2

Отличается от первого сценария только тем, что пользователь успевает сообщить в УЦ информацию о компрометации ключей в течение суток, но время проверки ЭП оказывается меньше времени информирования о компрометации t_ch_eck < tinform и скомпрометированная подпись принимается.

Сценарий №3

Пользователь своевременно сообщает в УЦ информацию о компрометации ключей, но УЦ пренебрегает своими обязанностями и эту информацию не добавляет в CRL тут же, а делает это спустя некоторое время, в итоге растет вероятность принятия скомпрометированной ПОДПИСИ, так как растет временной диапазон tcheck < tinform = tcompromise + tdelay

Сценарий №4

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

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

Математически эти процессы можно описать следующим образом. В диапазоне срока действия ключей ЭП от tstart До tfinish в момент времени tcompromise случается компрометация ключей. Информацию об этом в указанный момент может знать только атакующий и атакуемый пользователь (если процесс атаки был наглядным). Информация о компро- метации ключей достигает проверяющих за время tinform = tcompromise + tdelay, время tdelay требуется для публикации данных о компрометации в CRL или OCSP.

Исправить данную ситуацию возможно путем повторной проверки ЭИ спустя некоторое время, которе будет больше, чем ti_nf _orm = t_compromi_se + td_ei_ay- Фактически, только повторно проверенную подпись стоит считать абсолютно действительной, если она верна. Для ЭИ, которые проверяются однократно, стоит ввести некую меру достоверности, измеряя которую можно сказать, с какой вероятностью проверяемая подпись является действительной.

Мера доверенности может быть определена вероятностью признания подписью недействительной.

1.2.    Детерминированная проверка ЭП

Исходя из ранее описанных ситуаций детерминированной проверкой ЭП, следует считать двойную проверку ЭП:

• •    после первой проверки ЭП подписанного сообщения и спустя некоторое время в случае использования OCSP.

• •    после первой проверки ЭП подписанного сообщения и спустя срок действия CRL, который использовался для этой проверки.

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

Учитывая ранее описанные проблемы и риски, предлагается модифицировать процедуру проверки электронной подписи следующим образом. Необходимо выполнять процедуру проверки действительности сертификата дважды, так чтобы tcheck2 - tchecfei > tcompromise + tdelay- В натуральных величинах эти значения определяются удостоверяющим центром следующим образом: t_compromi_se - указывается в нормативных документах, отвественность за информирование удостоверяющего центра о компрометации за этот промежуток времени возлагается на собственника ключей и сертификата. Если данное требование не выполняется, то все финансовые и юридические риски несет собственник сертификата проверки ЭП. Как правило, параметр определен в 24 часа. Параметр td_ei_ay - состоит из времени, которое тратит УЦ на публикацию информации о компрометации сертификата и времени доставки этой информации пользователю. В случае с протоколом OCSP данное время занимает несколько минут, но не более часа, аналогично УЦ должен поступать и в случае с CRL, то есть оперативно его обновлять. Гарантированным сценарием проверки для OCSP следует считать сценарий, когда пользователь проверят ЭП в момент ее приема, после чего проверяет ее повторно спустя t_compromi_se + td_ei_ay, то есть 24,5 часа, если результаты проверки оба положительны, подпись признается действительной. Такой подход гарантирует исключение ответственности проверяющего за некорректную процедуру проверки ЭП. Но в случае использования CRL в качестве средства информирования о статусе сертификатов проверки ЭП возможны несколько сценариев с различными итогами. Корректный сценарий проверки - пользователь проверяет подпись, после чего, выжидает время t_compromi_se + td_ei_ay, получает новый CRL файл от УЦ и проверяет повторно, если результаты проверки оба положительны, подпись признается действительной. Но есть ряд случаев когда CRL спустя сутки после первой проверки недоступен, его мог не выпустить УЦ, пользователь утратил возможность получить его по сети, пользователь не счел нужным его получать, так как ранее полученный CRL еще действует и так далее. В этом случае стоит оценивать степень риска, который принимает на себя проверяющий.

1.3.    Оценка вероятности компрометации ЭП

Сертификат открытого ключа имеет свой срок жизни, он определяется в зависимости от технических средств, которые используются в роли носителя контейнера секретного ключа. Как правило, для самых, часто употребимых сертификатов, данный срок составляет 3 года, при том, что срок действия секретного ключа ограничивается 1-1,25 года. На протяжении всего срока действия сертификата вероятность его компрометации меняется в зависимости от условий использования, хранения, возможностей средств взлома секретного ключа. Можно обозначить срок действия открытого ключа, так как именно от него зависит корректность проверки электронной подписи как некий диапазон времени между величинами (а, 3)- Именно в нем стоит принимать решение о истинности результатов проверки ключа на действительность. Действительным стоит считать ключ, который не был скомпрометирован и отозван до момента успешного выполнения процедуры проверки электронной подписи. В заданном диапазоне вероятность компрометации величина непрерывная, поскольку существует в каждый момент времени. Пусть компрометация будет обозначена - X. Её возникновение возможно в ранее заданном диапазоне, что можно выразить в трех событиях:

• • событие А состоит в том, что компрометация происходит когда X < 3,

• • событие В состоит в том, что компрометация происходит когда X < а,

• • событие С состоит в том, что компрометация происходит когда а <  X < 3

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

Неограниченно уменьшая участок (а,3 ) полагая что 3 —^ а в пределе вместо вероятности попадания на участок, получим вероятность того, что величина примет отдельно взятое значение а:

p(X = а) = lim (а < X < 3) = lim [F(3 ) — F (а)]. /3— >а               3—>а

Поскольку функция F(X) в точке а непрерьшна, то lim^ >а(а < X < 3) = 0. Следовательно, вероятность любого отдельного значения непрерывной случайной вероятности компрометации ЭП равна нулю. В нашем случае, это объясняется тем, что за точку отсчета а выбирается момент гарантированной действительности сертификата ЭП. То есть когда проведена гарантированная проверка действительности ЭП или был выпущен сертификат ЭП. Но из того, что событие X = а имеет вероятность, равную 0, не следует, что частота события равна 0. Так как при большом числе проверок ЭП вероятность только приближается к частоте, следовательно, X = а будет проявляться сколь угодно редко. Отсюда же следует, что противоположное ему событие X имеет вероятность 1, но не достоверно. Функция распределения вероятности на больших временных отрезках может иметь разрывы, вызванные возникновением новых факторов окружающей среды, например, носитель ключа взяли из офиса домой или в командировку. В этом случае вероятность компрометации путем кражи или потери увеличилась. Но подобные факторы не дискретны и также действуют на протяжении некоторого периода времени (а, 3) Е [0, t) и на нем функцию можно считать непрерывной и дифференцируемой. Функцию F(X) следует считать неубывающей функцией ввиду того, что вероятность компрометации ключа ЭП растет с частотой его эксплуатации. Так как закон распределения данной вероятности может быть определен только эмпирически, из статистики, которая отсуствует в открытом виде, допустим, что функция распределения величины компрометации на отрезке времени в одни сутки (а,/3) = (0,1/365) задается выражением

Ғ(х) = < х2

при х < 0, при 0 < х < 1, при х > 1.

В этом случае плотность распределения величины X выражается

/ (х) =  2х

при х < 0, при 0 < х < 1, при х > 1.

Откуда можно определить вероятность компрометации ЭП без повторной проверки в случае, если сутки назад данная проверка была успешно проведена как Р (0 < X < 1/365) = Ғ (1/365) — Ғ (0) = 0, 00272 — 0 = 0, 000007506. Что можно признать адекватным значением вероятности компрометации ключей для российского единого пространства доверия исходя из данных удостоверяющих центров, входящих в него.

2.    Заключение

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