Модели и механизмы доверия

Четырехсторонняя модель доверия

Обоснованность четырехсторонней модели доверия была протестирована в пилотном проекте обеспечения функциональной совместимости удостоверяющих центров Национальной Ассоциации клиринговых палат (США) [90]. Четырехсторонняя модель доверия представлена на рис. 5.3. В качестве четырех сторон в модели выступают подписчик, доверяющая сторона и удостоверяющие центры подписчика и доверяющей стороны.

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

увеличить изображение
Рис. 5.3. Четырехсторонняя модель доверия

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

Web-модель

Web-модель получила свое название, поскольку базируется на популярных браузерах Netscape Navigator и Microsoft Internet Explorer, используемых как средства навигации во Всемирной Паутине - World Wide Web. Эта модель предусматривает встраивание в готовый браузер набора открытых ключей головных удостоверяющих центров, которым пользователь браузера может изначально "доверять" при проверке сертификатов. Хотя браузер позволяет корректировать набор корневых ключей (удалять одни ключи и добавлять другие), очевидно, что лишь немногие пользователи имеют достаточное представление о PKI и проблемах безопасности, чтобы управлять этим режимом работы браузера.

На первый взгляд эта модель аналогична модели распределенного доверия, но по существу более похожа на модель строгой иерархии. Web-модель немедленно делает пользователя браузера доверяющей стороной всех PKI-доменов, представленных в браузере. Для всех практических нужд каждый производитель браузера имеет свой собственный головной УЦ, сертифицирующий "головные" удостоверяющие центры, открытые ключи которых физически встроены в программное обеспечение браузера. По существу это строгая иерархия с подразумеваемым корнем, то есть производитель браузера является виртуальным головным УЦ, а уровень, находящийся ниже, образуют встроенные в браузер открытые ключи удостоверяющих центров [44].

Web-модель обладает явными преимуществами: удобством использования и простотой обеспечения функциональной совместимости. Однако при принятии решения о развертывании PKI в каждом конкретном случае следует учитывать проблемы безопасности. Пользователи браузера автоматически доверяют всем удостоверяющим центрам, открытые ключи которых были заранее встроены в браузер, поэтому безопасность может быть полностью скомпрометирована, если хотя бы один из этих центров окажется "плохим". Например, пользователь А будет доверять сертификату пользователя В, даже если он содержит имя пользователя В, но открытый ключ пользователя C, и подписан "плохим" УЦ, открытый ключ которого был встроен в браузер. В этом случае пользователь А может непреднамеренно разгласить конфиденциальную информацию пользователю C или принять документ с его фальшивой подписью. Причина нарушения безопасности заключается в том, что у пользователя обычно нет уверенности, какой именно корневой ключ из большого числа ключей, встроенных в браузер, участвует в проверке сертификата. Некоторые версии наиболее популярных браузеров поддерживают порядка 100 корневых сертификатов, поэтому пользователю может быть известна лишь небольшая группа из представленных удостоверяющих центров. Кроме того, в этой модели клиентское программное обеспечение доверяет всем удостоверяющим центрам, открытые ключи которых встроены в браузер, в равной степени; таким образом, сертификат, заверенный одним из них, будет, безусловно, принят.

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

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

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

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