В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 15. Протокол согласования ключей 15.4 Соглашение об аутентификации Прежде чем продолжать рассмотрение протокола согласования ключей, мы познакомим вас с соглашением об аутентификации. Протоколы часто обладают множеством элементов данных, поэтому иногда бывает сложно определить, какие элементы данных должны подвергнуться аутентифика- ции. Некоторые протоколы оказываются взломанными, поскольку не прово- дят проверку определенных полей данных. Во избежание этих проблем мы используем простое соглашение об аутентификации. В наших протоколах каждый раз, когда участник посылает сообщение об аутентификации, он применяет функцию аутентификации ко всем данным, которыми до этого момента обменялся с другим участником, т.е. ко всем предыдущим сообщениям и всем полям данных, предшествующим значению функции аутентификации в самом сообщении об аутентификации. В протоко- ле, представленном на рис. 15.1, пользователь А должен был бы подсчитать аутентификатор не для k , а для X и Y . В свою очередь, аутентификатор пользователя Б охватывал бы X , Y и AUTH A . Это соглашение позволяет устранить несколько потенциальных путей атак, а его реализация обходится совсем недорого. Участники криптографи- ческих протоколов не обмениваются слишком большим количеством данных, а вычисления аутентификаторов практически всегда начинаются с хэширо- вания входной строки. Функции хэширования работают настолько быстро, что дополнительные расходы в терминах производительности оказываются незначительными. Помимо всего прочего, данное соглашение позволяет сократить запись функций. Вместо того чтобы писать нечто наподобие AUTH A ( X, Y ) , мы бу- дем записывать просто AUTH A . Поскольку данные, подлежащие аутенти- фикации, задаются соглашением, больше не нужно указывать их явно. Все последующие протоколы, представленные в книге, соответствуют этому со- глашению. Еще раз напомним: функция аутентификации удостоверяет подлинность только строки байтов. Каждая строка байтов, подвергающаяся аутентифи- кации, должна начинаться с уникального идентификатора, определяющего точное место протокола, в котором применяется соответствующий аутенти- фикатор. Кроме того, преобразование предыдущих сообщений и полей дан- ных в строку байтов должно выполняться таким образом, чтобы эти сообще- ния и поля могли быть восстановлены без какой-либо дальнейшей контекст- ной информации. Мы уже обсуждали это более подробно, однако данный момент, несмотря на всю его важность, весьма легко упустить. 15.5. Вторая попытка 287 15.5 Вторая попытка Как же исправить недостатки предыдущего протокола? Мы не хотим ис- пользовать фиксированный набор параметров алгоритма DH. Пусть эти па- раметры выберет пользователь А и отошлет их пользователю Б. Мы также сократим количество сообщений, которыми обмениваются поль- зователи А и Б, с четырех до двух (рис. 15.2). Пользователь А выбирает па- раметры алгоритма DH и случайное число x , вычисляет X и отсылает все это пользователю Б вместе со значением функции аутентификации. Пользо- ватель Б должен проверить, что полученные им параметры алгоритма DH выбраны правильно и что значение X корректно. (Более подробно реализа- ция этих проверок описана в главе 12, “Алгоритм Диффи–Хеллмана”.) Остав- шаяся часть протокола полностью аналогична предыдущей версии. Пользо- ватель А получает значение Y и AUTH B , проверяет их и вычисляет значение ключа DH. У нас больше нет фиксированных параметров алгоритма DH. Мы исполь- зуем только два сообщения вместо четырех, нигде не применяем ключ сеан- са, помимо его основного назначения, а наше соглашение об аутентификации гарантирует, что строки, подвергающиеся аутентификации, не будут одина- ковыми. Несмотря на все это, у нас появилось несколько новых проблем. • Что делать, если пользователь Б захочет использовать простое число большего размера, чем было предложено пользователем А? Возможно, пользователь Б применяет более строгие политики безопасности, и чис- ло, выбранное пользователем А, кажется ему недостаточно безопасным. В этом случае пользователю Б придется прервать выполнение протоко- Пользователь А Выбрать подходящие (p, q, g) Пользователь Б x R {1, ..., q- 1} (p, q, g), X: = g x , AUTH A Y := g y , AUTH B y R {1, ..., q- 1} k Y x k X y Проверить (p, q, g), X, AUTH A Проверить Y, AUTH B Рис. 15.2. Вторая попытка согласования ключа |