kiev-security.org.ua-Криптография.Проблема компрометации секретного ключа сертификационного центра

Автор: КВИУС В.М. Сертификат открытого ключа для пользователя А содержит временную метку Т, уникальный идентификатор А и открытый ключ Ea, подписанные секретным ключом ключевого сервера (сертификационного центра) Ds: P:=Ds(Ta, А, Ea). Получатель сертификата P применяет открытый ключ сервера Es к этому сертификату, получая Т, А и Ea. Отметим, что сервер не хэширует сообщение (Т, А, Ea) перед подписанием. При работе с сертификатами существует серьгзная потенциальная угроза безопасности, связанная с компрометацией секретного ключа Ds сертификационного центра (СЦ). Злоумышленник Z в этом случае может подделать сертификаты открытых ключей. Проблема становится более серьгзной, если Z знает бывший (или текущий) секретный ключ Da какого-либо пользователя А. При этом Z сможет подделать и сертификат подписи. В частности, Z может взять некоторое сообщение, при помощи Da рассчитать подпись X, а затем использовать Ds для создания достоверного сертификата подписи, в котором будет указано время Т, когда Da имел силу. Иными словами, если Z скомпрометировал и Ds и Da, то он может создавать сообщения, законным образом увязываемые с пользователем А. Более того, Z может продолжать это делать даже после смены ключа сертификационным центром. Одним из способов защиты от подделок и компрометации всех ключей, включая ключи СЦ, является ведение контрольного журнала в СЦ (ключевом сервере) с фиксацией следующих событий: 1) регистрация открытого ключа, отмечаемая записью в журнал сертификата открытого ключа; 2) регистрация цифровой подписи, отмечаемая записью в журнал сертификата подписи (подписи не имеют законной силы до регистрации; 3) уведомление о компрометации ключа. Журнал хранится на устройстве одноразовой записи типа оптического диска, так чтобы записи нельзя было изменить, либо вставить в середину новые записи. Копии журнала можно хранить в физически разнесгнных местах для защиты от разрушения или утери. Вся информация в журнале имеет временные метки, проставленные сервером, и все записи размещаются по нарастанию времени. Только сервер может произвести запись в журнал. Этого можно достигнуть, если сервер физически изолирован, т.е. никакой процесс в сети не имеет доступа к контрольному журналу иначе, чем через сервер. Другой путь - логическая изоляция сервера и журнала на разных виртуальных машинах безопасной главной ЭВМ. Журнал не содержит секретной информации, которая доступна каждому. Журнал не шифруется. Это предотвращает утрату журнала в случае разрушения ключевого сервера, позволяет проверку сервера или разрешение спора третьей стороне и обеспечивает механизм восстановления при сбоях сервера. Запись событий в контрольный журнал. Каждое событие в журнале можно записать с подписью и без подписи сервера. Неподписанная часть используется для извлечения открытых ключей и подписей. Регистрация открытых ключей. В любое заданное время каждый пользователь имеет, по крайней мере, один действующий открытый ключ для обеспечения секретности и подписи; процедура легкол модифицируется в случае раздельных ключевых пар. Для смены ключей пользователь просто регистрирует новый открытый ключ. (Если поводом для смены ключа является компрометация предыдущего ключа, то это событие фиксируется первым.) Эта же процедура касается и ключевого - 2 - сервера. Таким образом, в журнале правильный открытый ключ пользователя отображается в виде самого последнего сертификата открытого ключа Р=Ds(Т,А,Еа) (пока за этой записью не последует сообщение о "компрометации" Ea). Журнал начинается записью, содержащей открытый ключ сервера. Когда А регистрирует Еа, то ему возвращается копия сертификата открытого ключа Р, содержащая Еа. А может проверить верность Р, используя открытый ключ сервера. Если другой пользоватиель В желает получить Еа, то он может получить Р непосредственно от А. С другой стороны, В может запросить текущий сертификат у сервера, при этом сервер посылает сертификат с текущим временем. Этот сертификат не регистрируется в журнале. Регистрация подписи. Сертификаты подписи автоматически добавляются в журнал при их запросе. В частности, когда сервер рассчитывает сертификат подписи G:=Ds(T,А,Ea,X) для подписи X пользователя А, этот сертификат добавляется сервером в журнал. Уведомление о компрометации ключа. Если секретный ключ пользователя А Da скомпрометирован, А подписывает обычным порядком (т.е. хэширование и применение Da) сообщение М="компрометация". Пусть XCOMP обозначает цифровую подпись. М и XCOMP передаются серверу, который добавляет запись Ds(Т,А,Ea,XCOMP) в журнал. Цель этой записи - ограничить ответственность А за сообщения, подписанные с помощью Da как раз перед обнаружением компрометации и вводом в действие нового открытого ключа. Если возникает спор относительно подписи X с сертификатом Ds(Т1,А,Ea,X), и журнал содержит запись о компрометации с временной меткой Т2, которая отличается от Т1 на некоторый определгнный интервал dT, то А выиграет дело. Если скомпрометирован ключ сервера, это событие также записывается в журнал. Хотя это может и не предотвратить добавление ложной информации в журнал за период между компрометацией и ег обнаружением (если злоумышленник получает доступ к журналу, что может и не быть возможным), всг же накладываются определгнные временные рамки на запись информации. В частности, становится невозможным подделывать сертификат подписи для ранее скомпрометированного ключа Da с временной меткой Т, характерной для срока действия Da. В таблице 1 показана выписка из журнала с записями, касающимися ключей S, A и B; подписей для A; компрометации ключа А. Для простоты временные метки записаны в виде год:месяц:день:час:минута:секукнда. Отметим, что компрометация ключа А зафиксирована через день после регистрации цифровой подписи X. Если dT превышает один день, то А может снять с себя ответственность за X. Таблица 1 ---------------------------------Событие Записываемый сертификат --------------------------------------------Регистрация ключа для S (82:10:20:19:37:26, S, Es) Регистрация ключа для А Ds(82:10:21:14:25:05, А, Eа) Регистрация ключа для В Ds(82:10:21:15:36:52, В, Eb) Регистрация подписи для А Ds(82:11:15:17:02:41, А, Eа, X1) Регистрация компрометации для А Ds(82:11:16:10:19:20, А, Eа, XCOMP) Регистрация ключа для А Ds(82:11:16:10:20:47, А, Eа') -----------------------------------------------Контрольный журнал не устраняет проблемы, возникающие при компрометации ключей, однако существенно их ограничивает. Важно то, что он позволяет их обнаружение. Предположим, что Z скомпрометировал секретный ключ сервера Ds, - 3 - но сервер ещг не обнаружил компрометации. Затем Z может создать фальшивые сертификаты открытых ключей. Однако пока Z не произвгл записи в контрольный журнал, открытые ключи в этих сертификатах не являются зарегистрированными соответствующим образом. Если всг же Z имеет возможность записи в журнал, сервер может обнаружить фальшивые сертификаты путгм сравнения последней записи в журнале со своей последней записью. Затем сервер может сделать запись о "компрометации", установить и распространить новый открытый ключ и уведомить пользователей, идентифицируемых в сертификатах. Если Z также скомпрометировал секретный ключ Da пользователя А, то Z сможет подделать подпись А на произвольных сообщениях, а затем подделать подпись сервера на сертификате подписи. Опять же, чтобы такой сертификат был достоверным, он должен быть записан в контрольный журнал, что делает компрометацию обнаружимой. Отметим также, что при смене пользователем А Da и Ea Z не сможет злоумышленно применить Da для сообщений, даже используя временную метку Т, характерную для срока действия Da и Ds. Это происходит по той причине, что Z должен вставить сертификат в соответствующее место в последовательности записей, что физически невозможно. Мы можем предположить и наихудший сценарий, когда злоумышленник разрушает сервер. Даже тогда возможный ущерб ограничен, так как злоумышленник не сможет создавать законного вида сертификаты, содержащие метки прошедшего времени.

2 Проблема компрометации секретного ключа сертификационного центра