agievich
commented
3 months ago Онлайн-проверка статуса отзыва сертификата действительно является одним из трудных вопросов инфраструктур открытых ключей. С одной стороны, статус сертификата должен быть проверен перед его использованием. С другой стороны, проверка может быть чересчур затратной (СОС большого объема) или даже невозможной (противник блокирует обращения к OCSP-серверу). Делая проверку обязательной, мы можем затруднить штатную работу СКЗИ. Некоторые эксперты считают, что онлайн-проверка статуса попросту не работает: Revocation does not work. Проверка статуса -- это "ремень безопасности, который рвется в автокатастрофе" (А. Лэнгли).
Действительно, проверку статуса сертификата следует организовывать по-разному в зависимости от ситуации. В тех случаях, когда проверка не является обременительной, она должна быть безусловной. Другая опция --- использовать краткосрочные сертификаты и полностью или частично отказаться от проверки. Третья опция -- обязательно делать проверку, но при отказе в обслуживании разрешать ее пропускать при определенных настройках в конфигурационных файлах или при явном разрешении оператора (он должен быть предупрежден о последствиях отказа от проверки).
Вопрос актуален для онлайн проверки статуса сертификата. Например, при установке защищенного соединения (VPN, TLS).
Для установки защищенного соединения оба его участника должны аутентифицировать друг друга. Для этого зачастую используется ЭЦП. Одна сторона подписывает сообщение и отсылает его другой. Принимающая сторона проверяет ЭЦП с использованием открытого ключа отправителя, полученного из его СОК. После чего выполняет верификацию маршрута сертификации.
Однажды может наступить ситуация, когда статус сертификата противоположной стороны примет значение UNDETERMINED. Т.е. текущее время локально хранимого СОС по какой-то причине (например, забывчивость пользователя, который не обновил локальный СОС) является более поздним по отношению к значению компонента СОС nextUpdate. СКЗИ может получить адрес точки распространения СОС из сертификата противоположной стороны и попытаться запросить актуальный СОС или отправить запрос о статусе сертификата на OCSP-сервер. Однако, ни тот, ни другой сервис могут быть недоступны по независящей от пользователя СКЗИ и самого СКЗИ причине (например, халатность администратора информационной системы, атака и т.д.).
Какое решение должно принять СКЗИ в данном случае? Ведь оно не получило информацию, что сертификат противоположной стороны отозван, но и не убедилось в обратном.
Приравнивание статуса сертификата противоположной стороны со значением UNDETERMINED к статусу "отозван" фактически закладывает в СКЗИ уязвимость, которая может привести к отказу в обслуживании. Приравнивание статуса сертификата противоположной стороны со значением UNDETERMINED к статусу "действителен" может привести к ошибке в принятии решения об аутентификации. При этом надо понимать, что в данном случае необходимо знать онлайн статус сертификата, т.е. непосредственно в данный момент времени.
Видятся только две причины не доверять подписи противоположной стороны:
В первом случае, для того чтобы сертификат попал в СОС, противоположной стороне необходимо выполнить какие-то действия по уведомлению об этом УЦ. При этом, сами СКЗИ обычно имеют средства для уничтожения собственной ключевой информации. Логично, что если противоположная сторона предпринимает действия по включению сертификата в список отозванных, то и действия по уничтожению личного ключа она тоже должна предпринять. После этого вопрос о СОС становится не актуален: нет ключа – нет подписи.
Второй случай – совсем нерядовое событие. Обычно Политика УЦ в этом случае требует не просто выпустить СОС, но и сообщить всем владельцам сертификатов о компрометации личного ключа УЦ при помощи других средств оповещения.
При проектировании СКЗИ неизвестно в какой информационной системе оно будет использоваться, и к каким последствиям для этой системы может привести тот или иной выбор в этой ситуации.