Иерархические PKI способны быстро реагировать на компрометацию отдельного УЦ внутри инфраструктуры. Если УЦ скомпрометирован, вышестоящий УЦ просто аннулирует его сертификат. Как только работа УЦ восстанавливается, он выпускает новые сертификаты для всех своих пользователей. Вышестоящий УЦ выпускает для скомпрометированного УЦ новый сертификат с новым открытым ключом, что позволяет вернуть этот центр обратно в иерархию. Во время восстановления работы скомпрометированного УЦ продолжает поддерживаться защищенная связь между двумя пользователями, находящимися вне скомпрометированного сегмента PKI. Безусловно, пользователи, находящиеся в скомпрометированном сегменте иерархии, теряют возможность пользоваться сервисами PKI.
Что касается компрометации головного УЦ, то она имеет те же последствия, что и компрометация одиночного УЦ. Критически важным является своевременное информирование всех пользователей иерархической PKI о компрометации головного УЦ. Пользователи не могут полагаться на PKI для установления защищенных коммуникаций, пока не восстановлена работа головного УЦ, не выпущены новые сертификаты для подчиненных удостоверяющих центров и не распространена информация о новом пункте доверия. Преимущество иерархической архитектуры по сравнению с одиночным УЦ заключается в том, что в случае компрометации головного центра требуется выпустить существенно меньшее количество новых сертификатов. Кроме того головной УЦ может оперировать автономно, значительно сокращая вероятность компрометации своего ключа.
Построение пути в иерархической PKI
В иерархиях пути сертификации начинаются в корне (с головного УЦ) и заканчиваются конечными субъектами, однако строятся они в обратном направлении [60]. Построение начинается с сертификата конечного субъекта. В сертификате указаны его издатель (УЦ) и дополнение Authority Key Identifier (идентификатор ключа УЦ). Эти атрибуты позволяют найти сертификат УЦ. Имя издателя используется для определения местонахождения сертификатов УЦ в репозитории. Репозиторий может содержать несколько сертификатов, выпущенных для УЦ. Идентификатор ключа УЦ в сертификате конечного субъекта сравнивается с идентификатором ключа субъекта только в одном сертификате - искомом сертификате УЦ. Этот процесс повторяется до тех пор, пока не будет найден сертификат, изданный головным УЦ, пунктом доверия иерархии.
На рис. 10.5 показаны пути сертификации для пользователей А, В, С и D в иерархической PKI. Каждый конечный субъект имеет единственный путь сертификации. Некоторые пути сертификации длиннее прочих, но все пути начинаются в корне иерархии. Запись [(ГУЦ -> УЦ3); (УЦ3 -> D)] означает, что путь от головного УЦ (ГУЦ) до пользователя D состоит из двух сертификатов.
Рис. 10.5. Пути сертификации в иерархической PKI
В иерархиях совершенно предсказуемы те пути, которые можно построить. Поэтому конечным субъектам следовало бы защищать пути сертификации протоколом безопасности, чтобы пути нельзя было реконструировать. В архитектурах, отличных от иерархий, PKI-субъекты имеют разные пункты доверия, поэтому построение каждого пути неоднозначно.
Сетевая PKI
Сетевая архитектура PKI является альтернативой иерархической архитектуры [10]. Сетевая PKI строится как сеть доверия, многочисленные удостоверяющие центры которой предоставляют PKI-сервисы и связаны одноранговыми, то есть равноправными, отношениями. Каждый пользователь доверяет одному УЦ, причем только тому, который издал его сертификаты. Удостоверяющие центры выпускают сертификаты друг для друга; пара сертификатов описывает двусторонние отношения доверия. В сетевую PKI легко добавляется новый УЦ, для этого ему нужно обменяться сертификатами, по крайней мере, с одним УЦ, который уже входит в сеть. Однако строить путь сертификации в сетевой PKI намного труднее, чем в иерархической инфраструктуре, где построение пути от сертификата пользователя до пункта доверия строго определено. Построить путь сертификации в сети достаточно сложно, поскольку этот процесс не детерминирован и имеются многочисленные варианты формирования цепи сертификатов. Одни из них приводят к построению правильного пути, другие - заводят в тупик. Длина пути может быть больше, чем в иерархической PKI, и даже может достигать общего числа удостоверяющих центров инфраструктуры. Более того, в сети можно построить бесконечную цепь сертификатов.
Рис. 10.6. Пример сетевой PKI и построенных путей сертификации
Сертификаты, выпускаемые в сетевой PKI, содержат больше дополнительной информации. В силу того, что между удостоверяющими центрами устанавливаются равноправные отношения, одни центры не могут влиять на типы сертификатов, которые выпускают другие центры. Если УЦ желает ограничить доверие, то должен задать эти ограничения в дополнениях сертификатов, изданных для всех других удостоверяющих центров, с которыми он связан.
Сетевые PKI обладают большой гибкостью, так как имеют многочисленные пункты доверия. Компрометация одного УЦ не отражается на сетевой PKI в целом: удостоверяющие центры, которые выпустили сертификаты для скомпрометированного УЦ, просто аннулируют их, тем самым удаляя из инфраструктуры ненадежный УЦ. В результате не нарушается работа пользователей, связанных с другими удостоверяющими центрами, - они по-прежнему могут полагаться на надежные пункты доверия и защищенно связываться с остальными пользователями своей PKI. Компрометация сетевой PKI приводит либо к тому, что сворачивается работа одного УЦ вместе с его сообществом пользователей, либо, если стали ненадежными несколько удостоверяющих центров, к тому, что PKI распадается на несколько меньших инфраструктур. Восстановление после компрометации сетевой PKI происходит проще, чем иерархической, прежде всего, потому что компрометация затрагивает меньше пользователей.
Пример 10.3. На рис. 10.6 удостоверяющие центры объединены в сетевую PKI. Пользователи А и В доверяют УЦ1. Пользователь С доверяет УЦ2, а пользователь D - УЦ3. Пользователю А гораздо труднее найти и проанализировать путь сертификации до пользователя С, чем в иерархической PKI. В том случае, если путь строится от УЦ1 к УЦ2, то он содержит два сертификата, а если путь к УЦ2 проходит через УЦ3, то - три сертификата. Пытаясь обнаружить один из нескольких правильных путей, пользователь может построить пути, которые ведут в тупик (например, путь через УЦ4 ). Обработка большего количества сертификатов более сложна, поскольку сопровождается анализом ограничений, включаемых в дополнения сертификатов.