Rambler's Top100
 
 
  04 июля 2009 года Я здесь впервые! Компьюлента
CIO
Терралаб
Бизнес-журнал
iBusiness
в поле зрения | terralab | своя игра | интерактив | блоги | readitorial | голубятня | наука и жизнь
Открытые исходники и безопасность
Автор: Брюс Шнайер
Опубликовано в журнале "Компьютерра" №40 от 05 октября 1999 года

Брюс Шнайер (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.
   Пер. с англ. Максима Отставнова, публикуется с любезного разрешения автора.

ТАКЖЕ В РАЗДЕЛЕ
24 февраля 2009 года
Не отрываясь 
24 февраля 2009 года
Жилец вершин 
10 февраля 2009 года
Гаджеты, которых нет 
10 февраля 2009 года
Схватка 
10 февраля 2009 года
Список задач 
 
Новости партнеров
Загружается, подождите...
Ну и как вам Firefox 3.5?






  
Результаты опросов

19:00 / Внедрение свободного ПО на предприятиях
Oleg Bancekin:
Феерическое обсуждение!Aceler, я был не прав - надо такие вещи писать!

/  свежий номер

Обложка журнала
Редакционный блог журнала "Компьютерра".
Анонс свежего номера.


Архив номеров журнала

О проекте | Распространение | Подписка | Реклама на сайте | Рассылки сайта | КПК–версия | RSS-трансляция | Компьютерра на Twitter

© ООО «Компьютерра–Онлайн», 1997 — 2009.
При цитировании и использовании любых материалов ссылка на портал «Компьютерра–Онлайн» обязательна (для Интернет–изданий — www.computerra.ru)
Редакция сайта: site@computerra.ru
Техподдержка сайта: websupport@computerra.ru
Редакция журнала: inform@computerra.ru
Отдел рекламы: reklama@computerra.ru
Телефон: (495) 232–22–61, (495) 232–22–63
Работает на «Битрикс: Управление сайтом»
Почта защищена сервером «СПАМОРЕЗ»

Сайт работает на сервере DEPO Computers
Rambler's Top100