В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 18. Серверы ключей ключей может быть распределено между несколькими компьютерами. Вда- ваться в подробности этих методов мы не будем, так как не собираемся созда- вать сервер ключей для десятков тысяч участников: это слишком рискованно. Опасность больших серверов ключей состоит в том, что все ключи находятся в одном и том же месте. Это делает сервер ключей весьма привлекательной мишенью для нападения. Кроме того, сервер ключей должен все время нахо- диться в рабочем состоянии, а значит, злоумышленник может связаться с ним в любой удобный момент. Текущие средства безопасности не очень хорошо защищают компьютеры от сетевых атак, а размещение всех ключей в одном и том же месте равносильно подготовке к убийству. В системах меньшего размера общая “сумма” ключей, которые хранятся на сервере, относительно невелика, поэтому вероятность угрозы снижается 2 . В следующих нескольких главах мы рассмотрим инфраструктуру управления ключами, которая хо- рошо подходит для крупных систем. В свою очередь, для описания сервера ключей ограничимся сравнительно небольшими системами — до нескольких тысяч участников. 18.3.1 Безопасное соединение Попробуем кратко описать наше простое решение. Прежде всего предпо- ложим, что пользователь А и сервер ключей совместно применяют общий ключ K A . Вместо того чтобы использовать этот ключ непосредственно для обмена данными, они запускают с его помощью протокол согласования клю- чей наподобие описанного в главе 15, “Протокол согласования ключей”. (Если K A — это пароль, вам следовало бы использовать один из протоколов, пред- назначенных для обработки паролей с низкой степенью энтропии (см. раз- дел 15.12). К сожалению, это влечет за собой все проблемы, связанные с их лицензированием.) Протокол согласования ключей генерирует для сервера ключей и пользователя А новый ключ K 0 A . Все другие участники общения запускают этот же протокол между собой и сервером ключей, в результате чего каждый из них получает по новому ключу для обмена данными с сер- вером ключей. Пользователь А и сервер ключей применяют ключ K 0 A для создания без- опасного канала общения (см. главу 8, “Безопасный канал общения”). Исполь- зуя последний, пользователь А и сервер ключей могут безопасно взаимодей- ствовать друг с другом. Безопасный канал общения обеспечивает и конфи- денциальность, и аутентификацию, и даже защиту от атак воспроизведения. Весь последующий обмен данными между пользователем А и сервером клю- чей происходит по безопасному каналу общения. Аналогичные каналы для взаимодействия с сервером создают и другие участники. 2 Вообще-то нам не нравится оставлять в системе хоть какую-нибудь вероятность угрозы, но в управлении ключами всегда приходится выбирать компромиссное решение. 18.3. Решения попроще 335 18.3.2 Создание ключа Теперь нам намного легче разработать протокол, который будет генери- ровать ключ для взаимодействия между пользователями А и Б. Требуется рассмотреть только те случаи, когда сообщения будут утеряны или удале- ны злоумышленником; от остальных манипуляций последнего нас защитит безопасный канал общения. Таким образом, наш протокол будет иметь до- вольно простую структуру. Пользователь А обращается к серверу ключей с просьбой сгенерировать ключ для обмена данными между ним и пользова- телем Б. Сервер ключей отвечает на запрос, посылая новый ключ K AB обоим пользователям. Более того, сервер ключей может послать сообщение пользо- вателю Б через пользователя А, поэтому ему нет необходимости связываться с пользователем Б напрямую. Этот протокол накладывает на систему одно ограничение: пользователь Б должен выполнить протокол согласования ключей с сервером ключей преж- де, чем пользователь А обратится к последнему с просьбой сгенерировать общий ключ для него и пользователя Б. Степень серьезности данной пробле- мы, а также ее возможные решения зависят от конкретных обстоятельств. 18.3.3 Обновление ключа Как и все ключи, ключ K 0 A должен иметь ограниченное время жизни. Реализовать данное свойство несложно, потому что пользователь А может в любой момент перезапустить протокол согласования ключей (используя для аутентификации исходный ключ K A ) , чтобы сгенерировать новый ключ K 0 A . Как правило, время жизни ключа рекомендуется ограничивать несколькими часами. Поскольку обновление ключа может быть выполнено в любой момент, серверу ключей не обязательно сохранять состояние безопасного канала об- щения очень надежным способом. Предположим, что в результате сбоя сер- вер ключей потерял все сведения о состоянии. Если сервер ключей сохранил ключ K A (и соответствующие ключи для взаимодействия с другими участни- ками), восстановить состояние безопасного канала общения будет несложно. Все, что для этого требуется, — еще раз запустить протокол согласования ключей между сервером и каждым участником общения. Таким образом, хо- тя в нашем случае сервер ключей и не лишен состояния, ему не обязательно изменять свое долговременное состояние (ту часть данных, которая хранится на энергонезависимых носителях) при выполнении криптографических про- токолов. |