11.1 Генерация пары ключей
Полная стратегия административного управления защитой при реализации должна определять жизненный цикл пары ключей, а это выходит за рамки основ аутентификации. Однако для полной защиты важно, чтобы все личные ключи оставались известны только тому пользователю, кому они принадлежат.
Данные ключа не просты для запоминания пользователю - человеку, поэтому приемлемым способом их хранения является обычный транспортабельный метод. Одним из возможных механизмов может быть использование "Smart Card". В них можно хранить секретный и (факультативно) ключи общего пользования, сертификат пользователя и копии общих ключей уполномоченных по сертификации.
Использование такой карты должно быть дополнительно защищено, например, по меньшей мере, использованием личного номера идентификации, повышающим защиту такой системы тем, что от пользователя требуется обладание такой картой и знание доступа к ней. Однако выбор точного способа хранения таких данных не входит в предмет рассмотрения настоящего стандарта.
Существует три способа, с помощью которых может быть создана пара ключей пользователя:
a) пользователь создает свою собственную пару ключей. Этот метод имеет преимущество в том, что личный ключ пользователя никогда не будет освобожден для другого логического объекта, но требует определенного уровня компетентности пользователя, как описано в приложении D;
b) пара ключей создается третьим участником. Этот третий участник должен освободить личный ключ для данного пользователя физически защищенным способом, затем уничтожить всю информацию, относящуюся к созданию пары ключей, и сами ключи. Должны быть приняты соответствующие физические меры безопасности, гарантирующие, что третий участник и операции над данными не будут подвергнуты вмешательству;
с) пара ключей создается уполномоченным по сертификации. Это особый случай способа b), и здесь применимы другие соображения.
Примечание - Уполномоченный по сертификации уже проявил доверительные функциональные возможности относительно пользователя и должен действовать в зависимости от необходимых физических мер защиты. Этот метод имеет преимущество в том, что он не требует передачи к УС защищенных данных для сертификации.
Используемая криптосистема налагает конкретные (технические) ограничения на создание ключей.
11.2 Административное управление сертификатами
Сертификат логически увязывает ключ общего пользования и уникальное различительное имя соответствующего пользователя. Таким образом:
a) уполномоченный по сертификации должен быть убежден в идентичности пользователя до создания сертификата для него;
b) уполномоченный по сертификации не должен выдавать сертификаты двум пользователям с одинаковым именем.
Создание сертификата происходит автономно, и не должно выполняться путем использования механизма автоматического запроса/ответа. Преимущество такой сертификации состоит в том, что поскольку личный ключ уполномоченного по сертификации никому неизвестен кроме изолированного и физически защищенного УС, то личный ключ такого УС может быть получен только в результате его изучения путем угрозы самому УС, что делает компромисс маловероятным.
Важно, чтобы передача информации уполномоченному по сертификации не была поставлена под угрозу и были приняты подходящие физические меры защиты. С этой точки зрения:
a) было бы серьезным нарушением безопасности, если бы УС выдавали сертификат пользователю с ключом общего пользования, который можно исказить;
b) если реализованы средства создания пары ключей 11.1с), защита передачи не требуется;
c) если реализованы средства создания пары ключей согласно 11.1a) или 11.1b), пользователь может использовать различные методы (оперативные или автономные), чтобы сообщить свой ключ общего пользования уполномоченному по сертификации защищенным способом. Оперативные методы могут предоставить некоторую дополнительную гибкость для удаленных операций, выполняемых между пользователем и УС.
Сертификат - это общедоступная часть информации, и каких-либо конкретных мер защиты для его передачи в справочник не требуется. Поскольку он создается автономным уполномоченным по сертификации по поручению пользователя, которому будут переданы копии сертификата, пользователю необходимо только занести эту информацию в свою запись справочника и получить затем доступ к справочнику. Как вариант, УС мог бы закрепить сертификат за пользователем и в этом случае этому агенту должны быть предоставлены соответствующие права доступа.
Сертификаты должны иметь свой срок службы, по истечению которого они утрачивают свою силу. Для того, чтобы продлить услуги, УС должен гарантировать своевременную готовность новых сертификатов, заменяющих сертификаты, срок действия которых истек/истекает. Здесь следует отметить два момента:
- действительность сертификатов может быть обеспечена таким образом, что каждый становится действительным по истечении срока действия своего предшественника с возможным перекрытием срока их действия. Последнее предотвращает УС от необходимости устанавливать и назначать большое число сертификатов, которые могли бы действовать, начиная с одной даты истечения срока;
- сертификаты, срок службы которых истек, обычно удаляются из справочника. Вопрос стратегии защиты и ответственности УС состоит в том, чтобы сохранять прежние сертификаты на некоторый период времени, если обеспечиваются услуги данных "безотказность отправителя".
Сертификаты могут быть отменены до истечения их срока службы, например, если предполагается, что личный ключ пользователя находится под сомнением, или если пользователь уже не имеет сертификата УС, или если предполагается, что сертификаты УС находятся под сомнением. Здесь следует отметить четыре момента:
- отмена сертификата пользователя или сертификата УС должна быть известна УС и в уместных случаях должен быть выдан новый сертификат. После этого УС может проинформировать владельца сертификата о произошедшей отмене с помощью некоторой автономной процедуры.
- УС должен поддерживать:
a) список выданных им и отмененных сертификатов с отметкой времени;
b) список аттестованных УС и отмененных сертификатов всех УС, известных данному УС, с отметкой времени.