В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 8 Безопасный канал общения Пришло время заняться решением первой настоящей проблемы, прису- щей реальным системам. Пожалуй, наиболее распространенной практической проблемой является создание безопасного канала общения. 8.1 Формулировка проблемы Неформально нашу проблему можно определить следующим образом: со- здание безопасного соединения между пользователями А и Б. Чтобы четко сформулировать, о чем пойдет речь в этой главе, описание проблемы придет- ся немного формализовать. 8.1.1 Роли Большинство соединений являются двунаправленными. Пользователь А отсылает сообщения пользователю Б, а пользователь Б отсылает сообщения пользователю А. Чтобы не перепутать эти потоки данных, протокол обмена данными должен обладать некоторой “асимметричностью”. В реальных систе- мах одним из участников общения может быть клиент, а другим — сервер. Иногда для удобства говорят об инициаторе (участнике общения, иниции- ровавшем безопасное соединение) и ответчике. В любом случае участникам общения нужно назначить роли пользователя А и пользователя Б, чтобы каждый четко знал, в какой роли он выступает. Разумеется, у нас всегда есть злоумышленник Е, который пытается ата- ковать безопасный канал общения всеми возможными способами. Злоумыш- ленник Е может читать все сообщения, которыми обмениваются пользовате- ли А и Б, и как угодно манипулировать этими сообщениями. В частности, злоумышленник Е может удалять, вставлять или изменять данные, переда- ваемые по каналу общения. 132 8.1. Формулировка проблемы 133 Когда мы говорим о передаче сообщений от пользователя А к пользовате- лю Б, то в большинстве случаев имеем в виду два физических компьютера, отсылающих друг другу сообщения по некоторой сети. Еще одной интересной областью применения этой модели является безопасное хранение данных. Ес- ли представить процесс хранения данных как передачу данных из настояще- го времени в будущее, все приведенные ниже сообщения будут справедливы и для хранения данных. В этом случае пользователем А и пользователем Б может быть одно и то же лицо, а носителем, применяемым для передачи дан- ных, — магнитная лента. Как и обычный канал общения, магнитную ленту нужно защищать от внешних вторжений и манипуляций ее содержимым. Ра- зумеется, отсылая данные в будущее, мы не можем применять двусторонний протокол, потому что из будущего невозможно отправить сообщение в про- шлое. 8.1.2 Ключ Чтобы реализовать безопасный канал общения, нам нужен какой-нибудь общий секрет. В данном случае предположим, что пользователи А и Б приме- няют общий секретный ключ K , не известный никому, кроме них самих. Это очень важное свойство. Криптографические функции никогда не могут иден- тифицировать пользователя А как физическое лицо. В большинстве случаев они идентифицируют ключ. Алгоритм верификации, применяемый пользо- вателем Б, сообщает ему примерно следующее: “Это сообщение было посла- но кем-то, кто знает ключ K и выступает в роли пользователя А”. Данное утверждение может пригодиться пользователю Б только в том случае, если он знает, что ключ K известен ограниченному числу лиц, например только ему самому и пользователю А. На данном этапе нас не волнует конкретный способ выбора и распростра- нения ключа. Мы просто предполагаем, что ключ уже есть. Об управлении ключами речь идет в главе 15, “Протокол согласования ключей”. К ключу K предъявляются следующие требования: • он должен быть известен только пользователям А и Б; • каждый раз при инициализации безопасного канала общения следует генерировать новое значение ключа K . Второе требование не менее важно, чем первое. Если один и тот же ключ будет использоваться на протяжении долгого времени, злоумышленник Е сможет воспроизвести старые сообщения и отправить их пользователю А или Б, внеся полную неразбериху в поток сообщений. Таким образом, да- же если в качестве основного ключа используется фиксированный пароль, пользователи А и Б должны применять протокол согласования ключей для |