demos FAQ PKI (1027778), страница 2

21. Надо ли менять ключи из-за обновления аппаратных средств ?
Тот факт, что аппаратные средства улучшаются, указывает на необходимость замены ключей на более длинные каждые несколько лет или даже меньше. Замена ключей позволяет воспользоваться всеми преимуществами новых аппаратных средств и повысить защищенность криптосистемы. Обратите внимание, что рост вычислительной мощности и улучшение аппаратных средств повышает защищенность криптосистемы только при регулярном увеличении длины ключа.

22. Что происходит при потере частного ключа ?
Если ваш частный ключ потерян или разрушен, но не раскрыт, Вы впредь не должны подписывать или шифровать сообщения этим ключом, однако, сообщения подписанные им ранее все еще имеют силу. Немедленно сообщите о случившемся Центру Сертификации, чтобы ключ был отменен и помещен в список CLR - это предотвратит его незаконное использование, если ключ будет найден или восстановлен злоумышленником. Потеря частного ключа может произойти, например, при потере смарт-карты или повреждении диска, где хранился ключ. Вы должны сразу же получить новую пару ключей, чтобы минимизировать количество приходящих Вам сообщений, зашифрованных прежним ключом, так как они больше не читаются.

23. Что происходит при раскрытии частного ключа ?
Если ваш частный ключ раскрыт или Вы подозреваете, что кто-то перехватил его, то Вы обязаны предположить, что нападающий может читать любые сообщения, зашифрованные соответствующим открытым ключом, и подделывать Вашу подпись на документах, пока другие продолжают считать этот открытый ключ Вашим. Серьезность этих последствий подчеркивает важность защиты частного ключа.

Вы должны немедленно уведомить все Центры Сертификации, чтобы Ваш открытый ключ был помещен в Список CRL; таким образом Вы широко сообщите о раскрытии Вашего частного ключа и об отмене соответствующего открытого ключа. Затем создайте новую пару ключей и получите новый сертификат для открытого ключа. С помощью нового частного ключа можно заново подписать документы, подписанные скомпрометированным частным ключом, хотя некоторые документы, имеющие кроме подписи цифровую дату все ещё могут иметь силу. Также необходимо проанализировать причины инцидента и принять меры против его повторения.

24. Как надо хранить частный ключ?
Секретные ключи надо хранить надежно, так как их раскрытие приводит к нежелательным последствиям. Меры для защиты частного ключа должны по крайней мере соответствовать защите сообщений, шифруемых этим ключом. Вообще, частный ключ ни в коем случае не должен храниться в открытом виде и даже самый простой механизм хранения должен шифровать частный ключ паролем. Однако, пароли иногда очень легко угадать и потому их необходимо выбирать очень тщательно, так как защита непосредственно зависит от пароля.
Кроме этого рекомендуется хранить зашифрованный ключ на диске, который не доступен по сети - это затруднит большинство нападений. В некоторых случаях удобно хранить ключ на компьютере, который не доступен для других пользователей или на съемных носителях. Секретные ключи также можно хранить на переносных носителях типа смарт-карт. Пользователи с чрезвычайно высокими требованиями защиты, типа Центров Сертификации, должны использовать для защиты частных ключей взломо-защищеные устройства.

25. Как получить чей-либо открытый ключ ?
Есть несколько путей получить чей-либо открытый ключ. Владелец ключа может переслать его Вам по электронной почте или передать иным путем. Так как открытый ключ является общедоступным, то нет необходимости шифровать его при передаче, хотя нужно проверять подлинность открытого ключа.
Уже появляются достаточно обширные каталоги, работающие как справочники с централизованным управлением. Наряду со стандартами ITU-T X.509 большинство каталогов содержит не только открытые ключи но и сертификаты; наличие сертификата понижает потребности защиты каталогов.

26. Что такое сертификаты?
Сертификаты - цифровые документы, подтверждающие связь открытого ключа с его владельцем. Сертификаты позволяют удостовериться в принадлежности открытого ключа определенному субъекту, а с другой стороны предотвращает использование фальшивого ключа для имперсонации. В некоторых случаях необходимо создать цепочку, в которой каждый следующий сертификат будет удостоверять предыдущий, пока проверяющая сторона не удостоверится в заявленном соответствии.
В простой форме сертификаты всегда содержат открытый ключ и имя его владельца. Кроме этого сертификат может содержать срок годности, название Центра Сертификации, выпустившего сертификат, порядковый номер, и, возможно, другую информацию. Но самое важное, что в сертификате присутствует цифровая подпись стороны запросившей этот сертификат. Наиболее широко принятый формат сертификатов определен в спецификации ITU-T X.509, что обеспечивает доступность всех сертификатов для приложений поддерживающих X.509.

27. Как используются сертификаты?
Обычно сертификаты используются для того чтобы обеспечить доверие открытому ключу. Сертификаты - по существу цифровые подписи, которые защищены открытыми ключами от подделки, ложного предъявления или дублирования. Поэтому проверка подписи может включать проверку законности сертификата соответствующего открытого ключа.

28. Что такое иерархия сертификатов и как она используется?
Наиболее надежное применение аутентификации подразумевает присоединение одного или нескольких сертификатов к каждому подписанному сообщению. Получатель сообщения проверяет сертификат, используя открытый ключ Центра Сертификации и, будучи уверен в открытом ключе отправителя, проверяет подпись сообщения. К сообщению могут быть присоединены два или несколько сертификатов, сформированные в иерархическую цепочку, где один сертификат удостоверяет подлинность предыдущего сертификата. В конце цепочки находится Центр Сертификации высшего уровня, которому доверяют без сертификата все прочие Центры Сертификации. Общий ключ Центра Сертификации высшего уровня должен быть известен из независимых источников, например, из открытых публикаций.
Если Отправитель и Получатель знакомы, то есть между ними существует определенная степень доверия к открытым ключам друг друга, требуется меньшее количество удостоверяющих сертификатов. Например, если Анна посылает сообщения Борису каждый день, то она может приложить цепочку сертификатов только к первому сообщению. Борис проверяет цепочку и затем сохраняет открытый ключ Анны, уверенный в том, что ключ действительно принадлежит ей, и не требует сертификатов со следующими сообщениями. Отправитель, чья компания Получателю известна, может приложить только один сертификат (выпущенный Организацией), в то время как Отправитель, чья организация Получателю неизвестна, должен приложить два или несколько сертификатов. Есть хорошее практическое правило, что к сообщениям прилагаются такие цепочки, чтобы Центр Сертификации выпустивший самый высший в этой цепочке сертификат был известен Получателю. Если сообщение рассылается нескольким адресатам, то возможно для каждого из них надо создавать различные цепочки или же одна цепочка должна содержать набор сертификатов достаточный для каждого из адресатов.

29. Что такое Списки Аннулированных Сертификатов (CRL)?
Список Аннулированных Сертификатов (CRL) - список сертификатов, отмененных до истечения срока их службы. Существует несколько причин отмены сертификата и помещения его в CRL:
· Раскрытие ключа, указанного в сертификате.
· Прекращение прав владельца на использование этого ключа.
Например, если владелец ключа уволен, и Компания не хочет оставлять ему право использовать этот ключ в дальнейшем, то сертификат ключа помещается в CRL.

30. Кто поддерживает, рассылает и использует Списки Аннулированных Сертификатов (CRL)?
Списки CRL поддерживаются Центром Сертификации; в Списке CLR приводится информация об аннулированных сертификатах, выпущенных этим Центром Сертификации. В списке CRL приводятся только те сертификаты, которые были отозваны раньше истечения их срока службы, а по истечению этого срока этот сертификат удаляется из Списка CRL. При проверке подписи необходимо проверить по соответствующему Списку CRL, что сертификат автора этой подписи не отменен.
Обычно Списки CRL распределяются одним из двух способов. В pull-модели Проверяющие запрашивают Списки CRL у Центра Сертификации по мере необходимости. В push-модели Центр Сертификации рассылает Списки CRL Проверяющим регулярно. Некоторые системы используют комбинированный подход, когда CRL регулярно рассылается нескольким промежуточным архивам, откуда Проверяющие загружают их себе самостоятельно.
Списки CRL поддерживаются распределенным образом, но иногда организуются централизованные архивы, хранящие списки CRLS различных Центров Сертификации. Например, банк может организовать собственный внутренний архив Списков CRL для проверки всех выполняемых транзакций. Ранние методы предлагают пользователю список всех аннулированных сертификатов; новые методы аннулирования сертификата (например, в X.509 версии 3) более гибки.

PKI FAQ 1-10 вопросы

PKI FAQ 11-20 вопросы

PKI FAQ 21-30 вопросы

PKI FAQ 31-40 вопросы

PKI FAQ 41-46 вопросы

32. Как RSA Keon Advanced PKI повышает защищенность PKI?
В сегодняшней среде PKI, проблема защиты частного ключа оставлена конечному пользователю, что означает наихудший тип защиты - иллюзию защиты.
Главная особенность RSA Keon Advanced PKI - повышенная защита. Во-первых, единое хранилище, в котором хранятся полные наборы цифровых удостоверений пользователей, защищается в соответствии с политикой безопасности, определяемой системным администратором. Это означает, что системный администратор определяет минимальный допустимый уровень аутентификации пользователей, зависящий от важности информации, к которой они получают доступ. Для некоторых пользователей может быть достаточно обычного пароля, для других, возможно, придется использовать более строгие методы установления подлинности.

Это приводит к необходимости такого элемента расширенной защиты как аутентификация пользователей на основе RSA SecurID. Вместе с RSA Keon Advanced PKI можно использовать любое устройство RSA SecurID; весь ряд этих устройств обеспечивает надежную аутентификацию для доступа к защищенным ресурсам. В дополнение к тому, что аутентифицированный доступ контролируется системной политикой, RSA Keon выполняет проверку по главному списку CRL и потому эта проверка является единой и непротиворечивой для всех приложений.
Наконец, RSA Keon Advanced PKI позволяет Компаниям легко интегрировать в информационные структуры доверительное управление различными центрами сертификации: разумно предположить, что Компании потребуется несколько собственных Центров Сертификации. Возможно, для работы некоторых Центров Сертификации потребуется человеческое участие, например, для создания сертификатов новым служащим Компании. Компания, занимающаяся сервисными услугами, должна создавать сертификаты для поддержки своих клиентов; финансовая организация должна создавать сертификаты для пользователей, которым нужен доступ к SAP и так далее. RSA Keon Advanced PKI позволяет создавать базовую политику доверия, охватывающую все указанные источники сертификатов, которые можно использовать в системе RSA Keon Advanced PKI.

33. Взаимодействие с RSA Keon Advanced PKI
Ещё одним свойством RSA Keon Advanced PKI является его способность к взаимодействию с продуктами сторонних разработчиков. RSA Keon Advanced PKI - первая система PKI, позволяющая взаимодействовать с сертификатами, выпущенными различными Центрами Сертификации (локальными или сторонними). На сегодняшний день гарантируется совместимость с Verisign, Netscape и собственным RSA Keon Certificate Server. В будущем предполагается возможность работы с сертификатами и других источников.
Во-вторых, использование стандарта LDAP для публикации как сертификатов так и публикации CRL, позволяет интегрировать RSA Keon Advanced PKI с разнообразными стандартными каталогами LDAP.
И наконец, RSA Keon Advanced PKI поддерживает приложения PKI-ready (типа Outlook, Explorer, Messenger, Communicator, Apache и другие) и содержит набор инструментов, которые позволяют подстраивать прочие приложения для работы с PKI. Дополнительные наборы инструментов позволяют встроить в систему единую регистрацию при которой введенная пользователем информация надежно сохраняется в системном хранилище. Также возможно шифрование данных передаваемых между клиентами и серверами.
Все эти возможности увеличивают преимущества централизованного управления политикой безопасности. Кроме этого для работы с системой SAP R/3 Enterprise Resource Management System предлагается RSA Keon Agent, созданный по той же технологии.