Ольга Полянская - Инфраструктуры открытых ключей

Другая потенциальная проблема безопасности, связанная с web-моделью, кроется в отсутствии практического механизма аннулирования любого из корневых ключей, встроенных в браузер. Если обнаруживается, что один из головных удостоверяющих центров является "плохим" или его секретный ключ скомпрометирован, то практически невозможно остановить использование открытого ключа такого УЦ в миллионах и миллионах копий браузера по всему миру. Это связано, во-первых, со сложностью уведомления всех пользователей браузеров, а во-вторых, с тем, что программное обеспечение браузера не предусматривает приема уведомлений о компрометации. Удаление скомпрометированного ключа из браузера возлагается на пользователей, причем в случае компрометации это должно быть сделано немедленно всеми пользователями браузера во всем мире. В противном случае одни пользователи будут защищены, в то время как другие останутся в рискованном положении. Так как удаление скомпрометированного ключа требует оперативности и соблюдения конфиденциальности, трудно ожидать, что такая операция выполнима в мировом масштабе.

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

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

Пример 5.3. Доверие, сконцентрированное вокруг пользователя, иллюстрирует известная система Pretty Good Privacy (PGP) [40]. В этой системе пользователь создает так называемую сеть доверия, действуя как УЦ (подписывая открытые ключи других субъектов) и обладая собственными открытыми ключами, подписанными другими. Когда пользователь А получает сертификат пользователя В , заверенный цифровой подписью пользователя C , и выясняет, что сертификат пользователя C , которого А не знает, подписан пользователем D , который хорошо знаком пользователю А , то должен решить вопрос о доверии ( см. рис. 5.4). Пользователь А может решить: доверять сертификату В (на основе доверия к цепочке сертификатов от пользователя D к пользователю C и пользователю В ) или отвергнуть сертификат В , аргументируя это тем, что к "неизвестному" пользователю В ведет слишком много связей от "знакомого" пользователя D .

Рис. 5.4. Модель доверия, сконцентрированного вокруг пользователя

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

Кросс-сертификация- это механизм связывания вместе удостоверяющих центров, ранее не имевших связей друг с другом, таким образом, что становятся возможными защищенные коммуникации между соответствующими сообществами субъектов. Фактически механизм кросс-сертификации аналогичен механизму обычной сертификации, за исключением того, что и субъект, и издатель кросс-сертификата являются удостоверяющими центрами, в то время как субъектом обычного сертификата является конечный субъект [121].

Отличия внутридоменной и междоменной сертификации зафиксированы в документе RFC 2510 [150]. Процесс называется внутридоменной кросс-сертификацией, если два удостоверяющих центра принадлежат одному и тому же домену (например, в иерархии удостоверяющих центров корпоративной PKI, где вышестоящий УЦ сертифицирует УЦ, находящийся на уровень ниже). Процесс называется междоменной кросс-сертификацией, если два удостоверяющих центра принадлежат разным доменам (например, когда УЦ одной компании сертифицирует УЦ другой компании).

Кросс-сертификация может выполняться в одном или двух направлениях. Односторонняя кросс-сертификация происходит тогда, когда УЦ 1 выпускает кросс-сертификат для УЦ 2 без одновременного выпуска УЦ 2 сертификата для УЦ 1 . Изданный кросс-сертификат является единственным. Односторонняя кросс-сертификация характерна для иерархической архитектуры. Альтернативой является двусторонняя кросс-сертификация , когда два удостоверяющих центра выпускают кросс-сертификаты друг для друга, - в результате издаются два кросс-сертификата . Этот вариант выбирают организации, желающие обеспечить защищенные коммуникации со своими партнерами.

В соответствии с терминологией рекомендаций X.509 1997 года [77], с точки зрения УЦ 1 , кросс-сертификат , изданный для него (то есть такой, в котором УЦ 1 является субъектом, а некоторый другой УЦ - издателем), получил название прямого кросс-сертификата; сертификат, изданный им самим ( УЦ 1 ), был назван обратным кросс-сертификатом. Эти термины были признаны не всеми специалистами и экспертами, поэтому в новой версии рекомендаций X.509 2000 года их назвали по-другому [78]. Термин "прямой" был изменен на "изданный для данного УЦ", а термин "обратный" - на "изданный данным УЦ".

Если в качестве хранилища сертификатов используется каталог X.500, соответствующие кросс-сертификаты ("изданный для данного УЦ" и "изданный данным УЦ") могут храниться в структуре пары сертификатов в точке входа в каталог каждого из релевантных удостоверяющих центров [44]. Эта структура может применяться при построении пути сертификации ( см. рис. 5.5).