Безопасность через неясность () — принцип, используемый для обеспечения безопасности в различных сферах деятельности человека. Основная идея заключается в том, чтобы скрыть внутреннее устройство системы или реализацию для обеспечения безопасности.
Система, полагающаяся на «безопасность через неясность», может иметь существующие или предполагаемые уязвимости, но её владельцы или разработчики считают, что если недостатки неизвестны, то злоумышленники не смогут их обнаружить. Система может также использовать безопасность через неясность в качестве одного из уровней защиты системы, поскольку даёт время разработчикам системы устранить найденную уязвимость, тогда как публичное раскрытие продуктов и версий делает их основной целью для использования обнаруженных уязвимостей в этих продуктах и версиях. Первым шагом злоумышленника обычно является сбор информации: эта задача усложняется при использовании безопасности через неясность.
История вопроса
Существующая официальная литература по вопросу о безопасности через неясность довольно скудна. Книги по инженерии безопасности ссылаются на Принцип Керкгоффса от 1883 года, если вообще на что-то ссылаются.
В области права Питер Свайр написал о компромиссе между тем, что «безопасность через неясность — это иллюзия», и по мнению военных, что «слухи топят корабли», а также о том, как конкуренция влияет на стимулы к раскрытию информации.
Принцип безопасности через неясность был общепринятым в криптографических работах в дни, когда, по существу, все хорошо информированные криптографы работали на национальные спецслужбы, такие как Агентство национальной безопасности. Теперь криптографы часто работают в университетах, где исследователи публикуют многие или даже все их результаты, и публично тестируют чужие разработки, или в частном секторе, где результаты чаще контролируются патентами и авторскими правами, нежели секретностью, поэтому принцип потерял часть его былой популярности. Например, PGP выпущен в виде исходного кода и обычно считается (при правильном использовании) криптосистемой военного уровня.
Преимущества и недостатки использования принципа
Приведём аргументы в пользу использования принципа. Несмотря на то, что создание защиты системы, которая опирается исключительно на принцип безопасность через неясность, является плохим решением, использование данного принципа с целью сохранения в тайне некоторых деталей системы может являться разумной тактикой в рамках системы многоуровневой защиты. Например, при обнаружении уязвимости системы её создателями безопасность через неясность может являться временным барьером для злоумышленников, пока не будет устранена данная уязвимость. В этом случае целью использования принципа является снижение в краткосрочной перспективе риска эксплуатации уязвимости в основных компонентах системы.
Рассмотрим компьютерную сеть, которая содержит известную уязвимость. Не имея информации о конкретном устройстве системы, злоумышленник должен решить вопрос, использовать данную уязвимость или нет. Если система настроена на обнаружение этой уязвимости, она обнаружит, что находится под атакой и может ответить, либо путём блокировки системы, пока администраторы не получат возможность отреагировать, либо путём мониторинга и отслеживания атаки нападающего, либо путём отсоединения злоумышленника. Суть использования принципа в данной ситуации заключается в том, что злоумышленник не может быстро получить необходимую информацию о системе, чтобы принять твёрдое решение о соотношении риска быть заблокированным при попытке использования уязвимости и возможного вознаграждения в случае удачной атаки. Также, как следствие отсутствия необходимой информации об устройстве системы, он не может однозначно выбрать ту часть системы, которую надо атаковать в первую очередь.
Ещё одна стратегия использования принципа предусматривает существование двойного слоя уязвимостей, оба из которых держатся в секрете. При этом создатели системы позволяют одной из уязвимостей «утечь». Идея состоит в том, чтобы дать злоумышленнику ложное чувство уверенности, что защита была преодолена и он победил. Например, это может использоваться как часть приманки (рус. аналог термина — «ловля на живца»).
Аргументы против принципа безопасность через неясность восходят к принципу Керкгоффса, выдвинутому в 1883 году Огюстом Керкгоффсом. Этот принцип утверждает, что дизайн криптографической системы не должен требовать секретности и не должен причинять неудобств, если он попадёт в руки врага. Разработчики должны считать, что весь дизайн системы безопасности известен нападавшим, за исключением криптографических ключей (безопасность криптографической системы находится полностью в криптографическом ключе). В 1940 году Клод Шеннон сформулировал этот принцип как «враг знает систему».
Чем больше число точек возможной компрометации содержится в системе, тем больше вероятность того, что стратегия нападения на одну из этих точек существует или будет разработана. Системы, которые содержат секретность структуры или операций, которые также являются точками возможной компрометации, являются менее безопасными, чем аналогичные системы без этих точек, если усилие, необходимое для получения уязвимости в результате раскрытия структуры проекта или метода работы, а также усилие, чтобы использовать эту уязвимость, меньше усилий, необходимых для получения секретного ключа. Уровень безопасности системы сводится при этом к усилиям, необходимым для использования этой уязвимости.
Например, если кто-то хранит запасной ключ под ковриком, в случае, если двери заперты снаружи, то он полагается на безопасность через неясность. Теоретическая уязвимость в системе безопасности в том, что кто-то может ворваться в дом, открыв дверь с помощью этого запасного ключа. Кроме того, поскольку грабители часто знают предполагаемые места тайников, владелец дома будет подвергаться большому риску кражи со взломом, скрывая ключ, так как усилие, требуемое для того, чтобы найти ключ, вероятно, будет меньше усилий, необходимых для проникновения (например путём взлома) другим способом, например, через стекло. Хозяин добавил уязвимость — тот факт, что входной ключ хранится под ковриком — в систему, и такую, которую очень легко угадать и эксплуатировать.
В прошлом несколько алгоритмов программного обеспечения или систем со скрытием внутренних деталей видели, как эти внутренние детали становятся достоянием общественности. Случайное раскрытие произошло несколько раз, например, в известном случае GSM конфиденциальная документация касательно шифра была передана в Университет Брэдфорда без наложения обычных требований конфиденциальности. Кроме того, уязвимости были обнаружены и использованы в программном обеспечении даже тогда, когда внутренние детали оставались секретными. Взятые вместе, эти и другие примеры показывают, что сложно или неэффективно держать детали систем и алгоритмов в секрете.
Безопасность через неясность не признаётся подходящим инженерным подходом к обеспечению безопасности системы, так как она противоречит принципу «KISS». Национальный институт стандартов и технологий специально рекомендует использовать безопасность через неясность не более чем в одном документе. Согласно NIST, «система безопасности не должна зависеть от секретности реализации или её компонентов».
Существует общий консенсус, даже среди тех, кто выступает в пользу безопасности через неясность, что принцип «безопасность через неясность» никогда не должен использоваться в качестве основной меры безопасности. Это, в лучшем случае, вторичная мера, и раскрытие информации о неясности не должно приводить к компрометации.
Примеры использования
Различие значения использования принципа в открытом и закрытом программном обеспечении
Ценность использования принципа при создании открытого или закрытого ПО весьма различна и неоднозначна. Рассмотрим процесс создания открытого ПО. Наиболее часто разработчики более заинтересованы в создании нового кода, чем в анализе уже существующего на наличие уязвимостей. Так как создание открытого ПО является делом добровольцев, в общем случае безопасности уделяется меньше внимания, чем если бы одной из обязанностей автора был бы анализ безопасности программы. С другой стороны, существует закон Линуса, гласящий, что «при достаточном количестве глаз баги выплывают на поверхность», предполагает повышенную безопасность алгоритмов и протоколов, описание которых опубликовано. Больше людей может просмотреть детали таких алгоритмов, выявить недостатки и раньше их исправить. Сторонники этой точки зрения считают, что частота и тяжесть последствий компрометации будет меньше, чем для закрытого или секретного программного обеспечения. Из всего этого можно заключить, что в случае создания открытого ПО, безопасность напрямую зависит от популярности программы, то есть чем выше популярность, тем больше добровольцев анализируют код программы и тем выше вероятность нахождения уязвимостей в нём. В подтверждение этого приведём пример, что исходный код Linux имеет 0,17 ошибки на тысячу строк исходного кода, в то время как закрытое коммерческое ПО в среднем насчитывает 20—30 ошибок на 1000 строк исходного кода.
Что касается закрытого ПО, то при его создании анализу безопасности кода уделяется большое внимание, что повышает надёжность системы. С другой стороны, так как количество разработчиков зачастую меньше, чем в случае открытого ПО, уменьшается вероятность обнаружения существующих уязвимостей в программе. К тому же, операторы и разработчики/производители систем, которые полагаются на безопасность через неясность, могут сохранить в тайне тот факт, что в их системе найдена уязвимость, чтобы избежать снижения уверенности в своих услугах или продуктах и, следовательно, избежать снижения его конкурентоспособности, внушив, таким образом, ложную уверенность в безопасности своих продуктов. Были известны случаи, по меньшей мере, 1960-х годов, когда компания задерживала выпуск исправлений и патчей, отдавая приоритет своим корпоративным правилам, а не проблемам или рискам клиентов.
История использования принципа в сервисе Skype
В июле 2010 года в Интернете появилась новость, что Шон О’Нил с группой коллег смог раскрыть исходные коды программ, которые защищают известный сервис IP-телефонии Skype. А точнее, им удалось получить исходные коды проприетарных протоколов шифрования сервиса Skype. В своём блоге Шон О’Нил даёт ссылку на сайт cryptolib.com, где, по его словам, находятся полученные коды.
По их собственному свидетельству, Шон О’Нил и его коллеги по реверс-инжинирингу в действительности занимались проблемами безопасности сервиса Skype на протяжении долгого периода времени. Так как они были специалистами в анализе двоичных кодов, им удалось довольно быстро восстановить программу по двоичным кодам, несмотря на то, что программисты Skype очень интенсивно применяли обфускацию. Именно по причине того, что разработчики Skype интенсивно применяли обфускацию, немногим до этого удавалось восстановить программу по двоичным кодам, а те, кто это смог сделать, не публиковали исходные коды, так как они выглядели устрашающе.