Открытые исходники и безопасность
БРЮС ШНАЙЕР
scheier@counterpane.com

Брюс Шнайер (Bruce Schneier) - основатель и главный технолог Counterpane Internet Security, Inc. (до сего года - Counterpane Systems). Разработчик симметричного шифра Twofish (одного из финалистов конкурса на американский стандарт шифрования AES), широко распространенного симметричного шифра Blowfish и ряда других криптоалгоритмов. Автор самого популярного руководства по криптографии (Bruce Schneier, Applied Cryptography - John Wiley & Sons: 1996), нескольких других книг и множества специальных и популярных статей. Как специалист в области криптографии и компьютерной безопасности, я так и не могу понять, в чем смысл тех споров, которые затевают вокруг движения за разработку программного обеспечения с открытыми исходниками.

   В мире криптографии мы рассматриваем открытый код, как необходимый для надежного обеспечения безопасности. И этого подхода мы придерживаемся десятилетиями. Публично продемонстрированная безопасность надежнее, чем обещанная разработчиком.

   Это справедливо для криптографических алгоритмов, протоколов безопасности и собственно кодов программного обеспечения безопасности. Для нас открытые исходники не просто бизнес-модель, а здоровая инженерная практика.

   Криптография с открытыми исходниками
   Как я уже заметил, криптографы придерживаются идеала открытых исходников десятилетиями, хотя называют их несколько иначе: использованием опубликованных алгоритмов и протоколов. Идея проста: криптографию реализовать трудно, и единственным способом узнать, правильно ли сделано что-то, является возможность это проверить.

   Для криптографии это жизненно важно, поскольку безопасность отличается от функциональности. Если у вас есть два алгоритма - надежный и ненадежный, оба они могут отлично "работать" - в том смысле, что шифрование и расшифровка выполняются, выполняются эффективно, с приличным пользовательским интерфейсом, и при этом алгоритмы никогда не "рушатся".

   Единственным способом отличить хорошую криптографию от плохой является ее проверка со стороны.

   И, более того, нет никакого смысла в такой проверке случайными людьми, исследующими код; единственный способ отличить хорошую криптографию от плохой - дать ее проверить экспертам. Анализ криптографии сложен, и в мире не так много людей, способных выполнить его компетентно. Прежде чем алгоритм будет признан надежным, он должен быть изучен многими экспертами в течение ряда лет.

   И это - сильный довод в пользу криптографии с открытым кодом.

   Поскольку единственный способ обрести уверенность в алгоритме - это предоставить его для изучения экспертам, а единственное условие, при котором они будут тратить время на проверку, - возможность публиковать результаты своих исследований, алгоритмы должны публиковаться.

   Использование "закрытого" алгоритма, кто бы его ни разработал и кому бы ни платили за его изучение в рамках соглашения о неразглашении, остается много более рискованным, чем использование опубликованного.

   Контраргумент, который иногда можно услышать, заключается в том, что секретная криптография надежнее, поскольку она секретна, а опубликованные алгоритмы - опаснее, поскольку всем доступны. Это звучит правдоподобно, только пока вы не задумаетесь. Публикуемые алгоритмы разрабатываются так, чтобы быть надежными с учетом того, что они публикуются. Следовательно, риска в их публикации нет.

   Если же алгоритм остается надежным, только пока остается в секрете, он и будет надежным, лишь пока кто-нибудь не проведет риверс-инжиниринг и не опубликует его.

   Целый набор секретных алгоритмов, "защищавших" цифровую сотовую телефонию, "утек" и вскоре был взломан, что иллюстрирует неадекватность этого контраргумента.

   Вместо того чтобы использовать опубликованные алгоритмы, сотовые операторы в США решили изобрести свою собственную секретную криптографию. В последние годы ряд алгоритмов был опубликован. (Нет, это не отрасль решила их опубликовать. Обычно случается так, что криптограф получает конфиденциальные спецификации в конверте без обратного адреса.) И вскоре после их публикации они были взломаны; и вот только теперь отрасль ищет изначально публичные алгоритмы на смену взломанным секретным.

   С другой стороны, популярная программа PGP всегда использовала для шифрования опубликованные алгоритмы, и ни один из них не был взломан. То же самое относится и к различным криптографическим протоколам, принятым для Internet: SSL, S/MIME, IPsec, SSH и т. п.

   Проверка, которую не купишь за деньги
   Как раз сейчас правительство США проводит конкурс, на котором будет отобран алгоритм, идущий на смену DES в качестве федерального стандарта; он будет называться AES (Advanced Encryption Standard - продвинутый стандарт шифрования).

   Осталось пять претендентов, и прежде чем будет назван победитель, лучшие криптографы мира потратят тысячи часов на их анализ и проверку. Ни одна компания, какой бы богатой она ни была, не может позволить себе купить столько экспертных усилий.

   Поскольку использование AES будет бесплатным для всех, мотивов для разработки собственных проприетарных стандартов у компаний не останется. Открытая криптография не просто лучше - она еще и дешевле!

   Те же причины, по которым разумные компании склоняются к использованию открытых криптоалгоритмов, приводят их к использованию открытых протоколов безопасности: тот, кто придумывает собственный протокол безопасности, - или гений, или глупец. Поскольку последних оказывается больше, чем первых, использовать открытые протоколы просто разумнее.

   Возьмем IPsec (IP Security protocol). Начиная с 1992 года, он находится в процессе публичной разработки комитетом, и с самого начала стал предметом серьезной оценки профессионального сообщества. Все знают, что этот протокол важен, и люди приложили немало усилий для того, чтобы добиться корректной спецификации. Предлагались различные механизмы безопасности, их ломали, затем модифицировали и совершенствовали. Первый черновой стандарт был опубликован в 1995 году, после чего обсуждение различных аспектов IPsec - безопасности, производительности, легкости внедрения и модификации - продолжалось.

   В ноябре 1998 года комитет опубликовал ключевые RFC - это стало очередным шагом к тому, чтобы сделать IPsec стандартом Internet. И протокол продолжают изучать! Криптографы из Военно-морской исследовательской лаборатории США недавно нашли мелкий огрех в спецификации реализации. То есть все еще идет публичная работа над протоколом с участием всех и каждого, кто в ней заинтересован. В результате мы получаем результат многих лет публичной экспертизы - стойкий протокол, которому доверяет большинство.

   Вот другой пример: Microsoft примерно в тех же целях разрабатывала свой собственный протокол PPTP (Point-to-Point Tunneling Protocol - протокол туннелирования от абонента к абоненту). Фирма придумала свой собственный протокол аутентификации, свою собственную хэш-функцию и свой собственный алгоритм генерации ключей. И все они были насквозь дырявыми. Microsoft взяла известный алгоритм шифрования, но использовала так, что его надежность была сведена на нет. Кроме того, ошибки реализации еще больше ослабили систему в целом. Но поскольку вся работа велась закрыто, никто не знал о слабости PPTP.

   Microsoft внедрила PPTP в Windows NT и Windows 95 и использовала его для организации виртуальных частных сетей (VPN). В конце концов протокол был открыт, и летом 1998 года компания Counterpane Systems, где я работаю, опубликовала статью, описывающую найденные упущения. Опять-таки, публичный анализ пошел на пользу.

   В Microsoft быстро разработали набор заплаток, которые мы проанализировали уже этим летом и обнаружили, что протокол стал лучше, но все еще содержит "дыры".

   Таким образом, и в случае с протоколами единственным способом отличить хорошее от плохого остается экспертная проверка. И если вам нужен протокол безопасности, гораздо разумнее использовать тот, который уже прошел такую проверку. Можно, конечно, придумать и собственный, но будет ли он лучше испытанного годами?

   Придание надежности коду
   Точно такое же рассуждение приводит разумного инженера к требованию открытого кода там, где дело касается безопасности. Еще раз: безопасность - это не функциональность. Никакой объем бета-тестирования не поможет найти дыру. Единственный способ найти дыру в безопасности, связанную с фрагментом кода - будь то криптоалгоритм или протокол, - это проанализировать сам код. Утверждение остается верным для любого кода - и открытого, и закрытого. Нужен многократный анализ с разных точек зрения в течение многих лет. Можно, конечно, нанять экспертов, но гораздо эффективнее предоставить работу профессиональному сообществу в целом. А этого легче всего достичь, опубликовав код.

   Но если вы хотите действительно быть уверенным в надежности своего кода, просто опубликовать его с лицензией на открытый код недостаточно. Нужно учесть еще две тонкости.

   Во-первых, сама по себе публикация кода вовсе не означает, что его действительно будут анализировать на предмет безопасности. Исследователи - народ занятой и к тому же капризный. Я могу назвать с дюжину криптобиблиотек с открытым кодом, о которых вряд ли кто вообще слышал, и уж точно никто на анализировал. А вот, например, код Linux, связанный с безопасностью, изучали многие очень квалифицированные специалисты.

   Во-вторых, после обнаружения дырок их нужно быстро закрыть. Дырки обязательно найдутся, и это замечательно - нет никаких оснований полагать, что на момент написания открытый код надежнее закрытого.

   Сам смысл публикации кода в том и заключается, чтобы как можно больше специалистов изучило его на предмет обнаружения дырок и чтобы последние были быстро закрыты.

   Только тогда годовалый фрагмент открытого в исходниках кода будет содержать намного меньше дырок, чем его проприетарный ровесник. Впрочем, по ходу дела дырки обнаружатся и в закрытом коде, но это будет происходить много медленнее.

   Есть ли смысл сравнивать безопасность Linux и Microsoft Windows? Это было бы не вполне честно, поскольку Microsoft тратит кучу усилий на совершенствование безопасности. Но вот сравнение Linux с Solaris более уместно: в Linux проблемы с безопасностью находят и исправляют быстрее. В результате система, приобретшая популярность лишь несколько лет тому назад, оказывается более надежной, чем Solaris была в том же возрасте.

   Безопасные PR
   Одним из величайших преимуществ движения за открытые исходники является положительная обратная связь, порожденная публичностью.

   Зайдите сегодня в любой большой компьютерный магазин, и вы увидите целую полку, заставленную продуктами под Linux. Их покупают, поскольку Linux обращена сегодня лицом не только к компьютерным профессионалам, она стала полезным инструментом и для решения прикладных задач. Та же самая цепь обратной связи работает и в вопросах безопасности: публичные алгоритмы и протоколы приобретают доверие, поскольку о них знают и ими пользуются, и они становятся текущей модой. Профессионалы маркетинга называют это mindshare. Это - не совершенная модель, но все же лучше, чем ее противоположность.

   Опубликовано в CRYPTO-GRAM (www.counterpane.com/crypto-gram.html ), September 15, 1999.
   (с) 1999 by Counterpane Internet Security, Inc.
   Пер. с англ. Максима Отставнова, публикуется с любезного разрешения автора.

Взято с www.computerra.ru