В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 23. Стандарты Когда мы пытались донести эту проблему до тех, кто занимается стан- дартизацией, то часто получали в ответ высказывания примерно такого рода: “Этим технарям всегда подавай идеальный стандарт. . . ”, “Политические реа- лии таковы, что мы вынуждены идти на компромисс. . . ”, “Именно так и ра- ботает система. . . ”, “Да посмотрите же, чего мы достигли. . . ”, “Все и так хо- рошо. . . ” и т.п. Простите за резкость, но в сфере безопасности это не пройдет. Даже того, что после принятия стандарта необходимо проводить тестирова- ние на совместимость, вполне достаточно, чтобы четко уяснить: стандарты, разработанные комитетом, не подходят для обеспечения безопасности. Если функциональная часть стандарта (т.е. самая легкая его часть) недостаточно хороша, чтобы гарантировать совместимость систем различных разработчи- ков без предварительного тестирования, тогда часть стандарта, отвечающая за безопасность, скорее всего, тоже не сможет обеспечить безопасность си- стем без тестирования. В свою очередь, мы знаем, что протестировать си- стему на безопасность невозможно. Вероятно, мы могли бы создать реали- зацию, использующую подмножество функциональности стандарта, которое также будет безопасным, но для стандарта безопасности этого явно недоста- точно. Стандарт безопасности провозглашает, что, придерживаясь его, мы непременно достигнем определенного уровня безопасности. Нет, безопасность слишком сложна, чтобы отдавать ее в руки комитета. Мы не знаем ни одного стандарта, разработанного комитетом, который бы стоил внимания. Поэтому, когда кто-нибудь предлагает использовать крипто- графический стандарт, мы относимся к этому крайне неприязненно, а порой и враждебно. Существует лишь несколько действительно стоящих криптографических стандартов, ни один из которых не был разработан комитетом. Иногда стан- дарт разрабатывается небольшой группой единомышленников, которые вме- сте создают один последовательный стандарт. А иногда проект принимают в качестве стандарта без каких-либо политических компромиссов. Такие стан- дарты могут оказаться довольно неплохими. Рассмотрим два наиболее важ- ных из них. 23.2 SSL Это протокол безопасности, используемый Web-обозревателями для без- опасного подключения к Web-серверам. Первой версией данного протокола, вошедшей в широкое применение, была SSL 2, которая содержала несколько недочетов в системе безопасности. Улучшенная версия SSL получила назва- ние SSL 3 [36]. Она была разработана группой из трех человек без организа- 23.3. AES: стандартизация на конкурсной основе 393 ции каких-либо комитетов. Протокол SSL 3 получил широкое распростране- ние и в целом был признан хорошим. Небольшое предупреждение: SSL — хороший протокол, но это еще не озна- чает, что любая система, использующая его, будет безопасной. Для аутенти- фикации Web-сервера SSL использует функциональность инфраструктуры открытого ключа (PKI), а клиент PKI, встроенный в большинство обозре- вателей, обладает такой толерантностью к чужим сертификатам, что общий уровень безопасности оказывается довольно низким. У одного из наших обо- зревателей имеется 108 различных корневых сертификатов от 35 центров сертификации. Таким образом, даже не начав рассмотрение активных атак, мы уже сталкиваемся с фактом существования 35 различных организаций, разбросанных по всему миру, которым мы должны доверять всю нашу Web- информацию. Протокол SSL никогда не был стандартизирован по-настоящему. Он был просто разработан компанией Netscape и стал стандартом де-факто. Стан- дартизацией и дальнейшей разработкой протокола SSL (под именем TLS) занимается IETF. Мы не занимались подробным изучением TLS. Пока что отличия TLS от SSL выглядят довольно незначительными, поэтому у нас нет оснований думать, что TLS в чем-то уступает SSL 3. Тем не менее, учитывая последние “достижения” IETF в области разработки протоколов безопасно- сти, таких, как IPSec [32], мы опасаемся, что эффект комитета опять проявит себя и испортит хороший стандарт. 23.3 AES: стандартизация на конкурсной основе Для нас AES является ярким примером того, как следует стандартизиро- вать системы безопасности. Стандарт AES не был разработан на собраниях комитета — его отобрали на конкурсной основе. Схема проведения подобного конкурса довольно проста. Вначале вы задаете, каким требованиям должна соответствовать система и какова ее цель. Разработка спецификаций системы может выполняться сравнительно небольшим коллективом людей с исполь- зованием многих внешних источников. Следующий шаг — объявить конкурс. Вы обращаетесь к экспертам с просьбой разработать законченное решение, которое будет соответствовать заданным требованиям. Как только эксперты представят свои предложения, вам останется лишь выбрать одно из них. Это прямое соревнование, в ко- тором проекты-конкурсанты оцениваются по ряду критериев. Если главным критерием отбора выступает безопасность, участники будут крайне заинте- ресованы в том, чтобы найти как можно больше слабых мест в безопасности систем своих конкурентов. В случае удачи это обеспечит неоценимую обрат- |