В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 19 PKI: красивая мечта В этой главе рассматривается стандартная концепция инфраструктуры открытого ключа (PKI) и то, как она позволяет решить проблему управле- ния ключами. Очень важно, чтобы вы хорошо поняли этот материал, прежде чем продолжать чтение книги. В следующей главе мы объясним, почему на практике инфраструктура открытого ключа работает совсем не так хорошо, как ожидалось. Но это все будет потом, а пока совершим экскурсию в иде- альный мир, где инфраструктура открытого ключа одним махом решает все наши проблемы. 19.1 Краткий обзор инфраструктуры открытого ключа Инфраструктура открытого ключа (Public-Key Infrastructure — PKI) представляет собой систему, с помощью которой можно определять, кому принадлежит тот или иной открытый ключ. Рассмотрим ее классическое опи- сание. Существует некий центральный орган, который называется центром сер- тификации или ЦС (Certificate Authority — CA) . Центр сертификации обла- дает парой “открытый ключ-закрытый ключ” (например, парой ключей RSA) и публикует свой открытый ключ. Будем исходить из предположения, что от- крытый ключ центра сертификации известен всем. Поскольку данный ключ остается неизменным на протяжении длительных периодов времени, достичь этого будет несложно. Чтобы присоединиться к инфраструктуре открытого ключа, пользова- тель А генерирует собственную пару “открытый ключ-закрытый ключ”. За- крытый ключ он сохраняет в секрете, а открытый ключ PK A передает центру сертификации со следующим пояснением: “Привет, я пользователь А, и у ме- 337 338 Глава 19. PKI: красивая мечта ня есть открытый ключ PK A ”. Центр сертификации проверяет, действительно ли пользователь А является тем, за кого себя выдает, а затем подписывает цифровое утверждение примерно следующего содержания: “Ключ PK A при- надлежит пользователю А”. Это подписанное утверждение называется сер- тификатом (certificate) . Оно удостоверяет, что данный ключ принадлежит пользователю А. Теперь, если пользователь А захочет пообщаться с пользователем Б, он может отослать ему свой открытый ключ и сертификат. У пользователя Б есть открытый ключ центра сертификации, с помощью которого он может проверить цифровую подпись последнего. Если пользователь Б доверяет цен- тру сертификации, он может довериться и тому, что ключ PK A действительно принадлежит пользователю А. Выполнив описанные действия, пользователь Б может заверить в центре сертификации свой открытый ключ, после чего отослать открытый ключ и сертификат пользователю А. Теперь пользователи А и Б знают открытые ключи друг друга. Последние, в свою очередь, могут быть использованы для запуска протокола согласования ключей, который сгенерирует ключ сеанса для последующего безопасного общения. Для реализации описанной схемы нужен главный центр сертификации, которому все будут доверять. Каждый участник общения должен заверить свой открытый ключ в центре сертификации, и каждый участник должен знать открытый ключ самого центра сертификации. После этого все участ- ники смогут безопасно общаться друг с другом. На первый взгляд звучит довольно просто. 19.2 Примеры инфраструктуры открытого ключа Чтобы облегчить понимание материала оставшейся части главы, рассмот- рим несколько примеров реализации и использования инфраструктуры от- крытого ключа. 19.2.1 Всеобщая инфраструктура открытого ключа Самой заветной мечтой разработчиков является всеобщая инфраструкту- ра открытого ключа, т.е. большая организация (наподобие почты), которая сертифицирует открытый ключ каждого человека. Прелесть данной идеи со- стоит в том, что каждому человеку понадобится сертифицировать лишь один ключ, который он мог бы использовать где угодно. Поскольку все жители Земли доверяют почте (или любой другой организации, которая будет выпол- нять роль всеобщей инфрастуктуры открытого ключа), они смогут безопасно общаться друг с другом и жить в мире и согласии до конца дней своих. 19.2. Примеры инфраструктуры открытого ключа 339 Неудивительно, если все это напоминает вам сказку, — так оно и есть. Всеобщей инфраструктуры открытого ключа нет и быть не может. 19.2.2 Доступ к виртуальным частным сетям В качестве более реального примера можно привести компанию, у которой есть виртуальная частная сеть (virtual private network — VPN). С ее помо- щью сотрудники компании могут осуществлять доступ к корпоративной сети прямо из дома или, скажем, из гостиничного номера во время путешествия. Точки доступа VPN должны уметь распознавать людей, которым разрешено получать доступ к сети, и предоставлять им соответствующий уровень до- ступа. В этом случае IT-департамент компании выступает в качестве центра сертификации. Он предоставляет каждому сотруднику сертификат, благода- ря которому точка доступа VPN сможет распознать этого сотрудника. 19.2.3 Электронные платежи Пусть некоторый банк хочет предоставить своим клиентам возможность осуществлять финансовые транзакции на Web-узле банка. Данному прило- жению критически важна правильная идентификация клиентов, а также воз- можность генерировать доказательства, которые будут приниматься в суде. Такой банк может сам выполнять роль центра сертификации и заверять от- крытые ключи своих клиентов. 19.2.4 Нефтеперегонный завод Структура нефтеперегонного комплекса очень сложна. По километрам труб и подъездных дорог разбросаны сотни датчиков, которые измеряют та- кие показатели, как температура, дебит и давление. Умному злоумышлен- нику не составит большого труда подделать показания датчиков, отправля- емые в диспетчерскую, чтобы действия, ошибочно предпринятые оператора- ми, привели к колоссальному взрыву. Таким образом, диспетчеры должны быть уверены в том, что они действительно получают корректные показания датчиков. Мы можем использовать стандартные механизмы аутентификации, чтобы предотвратить подделку данных датчиков, но для обеспечения иден- тификации этих датчиков потребуется некоторая инфраструктура ключей. В этом случае компания может выступить в качестве центра сертификации и развернуть инфраструктуру открытого ключа для всех датчиков, чтобы в диспетчерской могли распознать каждый датчик, установленный на пред- приятии. |