id: Гость   вход   регистрация
текущее время 03:05 08/12/2022
создать
просмотр
редакции
ссылки

Как сохранить безопасность против слежки АНБ


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


Последние две недели я вместе с Guardian работал над историей вокруг АНБ и прочитал сотни сверхсекретных документов АНБ, предоставленных информатором Эдвардом Сноуденом. Я не принимал участие в сегодняшней публикации — она готовилась задолго до моего появления, — но всё прочитанное мной подтверждает сообщения Guardian.


Теперь же, как мне кажется, я готов дать ряд советов, как оградить себя от подобного противника.


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


АНБ имеет доступ к магистральным каналам интернета за счёт своих тайных соглашений с телекоммуникационными компаниями — всеми компаниями из США и Великобритании, а также ряда прочих своих «партнёров» по всему миру. В случаях, когда оно не может положиться на такой «дружественный» доступ, оно идёт на всё, чтобы обеспечить скрытое прослушивание коммуникаций: подключается к подводным кабелям, перехватывает спутниковую связь и т.д.


Объёмы получаемых данных огромны, но АНБ располагает в равной мере огромными возможностями, чтобы быстро просеивать их в поисках интересующего трафика. «Интересующими» могут быть множество характеристик: источник, адресат, содержание, участники коммуникации и прочее. Все эти сведения направляются в гигантскую систему АНБ для последующего анализа.


В ещё больших объёмах АНБ собирает метаданные трафика: кто и с кем связывается, когда, как долго, каким способом. Метаданные, по сравнению с содержанием, гораздо проще хранить и анализировать, они могут иметь чрезвычайно личный характер для человека и они невероятно ценны для разведки.


Возглавляет направление по сбору данных Управление системной разведки, и объёмы ресурсов, которые оно выделяет на эти цели, просто поражает. Я читаю отчёт за отчётом, рассматривающие возможности этих программ, их функциональные детали, планы модернизации и т.д. На каждую конкретную проблему — извлечение электронных сигналов из оптических кабелей, поддержание скорости перехвата терабайтных потоков данных, отфильтровывание интересующих вещей — есть своя отдельная группа, занятая поисками решений. Охват тем глобален.


АНБ также атакует и сами сетевые устройства: маршрутизаторы, свитчи, брандмауэры. Большинство этих устройств имеют встроенные функции для прослушки; хитрость заключается в том, чтобы незаметно активировать их. Это крайне плодотворное направление взлома: маршрутизаторы реже обновляют, на них реже установлены программные средства безопасности и они, как правило, не рассматриваются в качестве уязвимого компонента.


Кроме того, АНБ направляет значительные ресурсы на взлом оконечных компьютеров. Этим делом у них занимается группа TAO — Отделение адаптированного доступа. У TAO есть меню эксплоитов, которыми оно может «обслужить» ваш компьютер (будь он под управлением Windows, Mac OS, Linux, iOS или чего-то ещё), и ряд приёмов, чтобы доставить их на ваш компьютер. Их не обнаружит ни ваш антивирус, ни, скорее всего, вы сами, даже если будете знать, что искать. По сути, это хакерские инструменты, разработанные хакерами с практически безграничным бюджетом. Что я вынес из документов Сноудена — это тот факт, что если АНБ захочет влезть в ваш компьютер, оно влезет. Точка.


АНБ решает проблему зашифрованных данных, с которыми ему приходится сталкиваться, в основном обходя криптографию, нежели используя какие-то секретные математические открытия. Во-первых, в мире полно бестолковой криптографии. К примеру, если оно обнаруживает сетевое соединение, защищённое с помощью MS-CHAP, его легко взломать и восстановить ключ. Оно взламывает слабые пользовательские пароли, используя такие же словарные атаки, которыми пользуются гражданские хакеры.


Как мы сегодня узнали, АНБ также «взаимодействует» с разработчиками средств безопасности, чтобы их коммерческие средства шифрования были уязвимы в таких местах, о которых известно только Агентству. Мы помним, что такое уже было в истории: CryptoAG и Lotus Notes — два самых ярких примера, и есть свидетельства в пользу бэкдора в Windows. Несколько человек сообщили мне ряд более свежих историй из своего недавнего опыта, и вскоре я собираюсь об этом написать. В сущности, АНБ предлагает компаниям вносить небольшие незаметные изменения в их продукты: сделать генератор случайных чисел менее случайным, каким-либо образом производить утечку ключа, добавить общую экспоненту в протокол согласования ключей и т.п. Если кто-либо обнаруживает бэкдор, он объясняется как обычная программная ошибка. И, как нам теперь известно, АНБ добилось невероятных успехов с этой инициативой.


TAO также взламывает компьютеры для извлечения долгосрочных ключей. Таким образом, если вы поддерживаете VPN со сложным общим секретом для защиты данных, и АНБ посчитает их заслуживающими внимания, оно может попытаться выкрасть этот секрет. Такие операции предпринимаются только в отношении особо важных целей.


Итак, как же вам организовать безопасную связь при наличии такого противника? Сноуден дал ответ в своём интервью вскоре после обнародования своих первых документов: «Шифрование работает. Должным образом реализованные стойкие криптосистемы — одна из немногих вещей, на которую вы можете положиться».


Думаю, это правда, даже несмотря на сегодняшние откровения и провокационные намёки Джеймса Клэппера, директора национальной разведки, на «прорывные возможности криптоанализа», сделанные им в другом сверхсекретном документе. Все эти возможности заключаются в намеренном ослаблении криптографии.


Но последующая фраза Сноудена имеет не меньшую значимость: «К несчастью, оконечная безопасность столь ужасающе низка, что АНБ зачастую способно её обойти».


«Оконечная» — это программы, которые вы используете, компьютер, на котором вы их используете, и локальная сеть, в которой вы их используете. Если АНБ удастся модифицировать алгоритм шифрования или закинуть на ваш компьютер троян, никакая криптография на свете вам уже не поможет. Если вы хотите сохранить безопасность против АНБ, вам придётся пойти на всё, чтобы работе шифрования ничто не могло помешать.


Исходя из всего сказанного, у меня есть пять советов:


  1. Спрячьтесь в сети. Используйте скрытые сервисы. Используйте Tor, чтобы самому оставаться анонимным. Да, АНБ интересуют пользователи Tor, но это всё равно препятствие для его работы. Чем менее вы заметны, в тем большей вы безопасности.
  2. Шифруйте связь. Используйте TLS, используйте IPSec. Опять же, хотя АНБ целенаправленно перехватывает зашифрованные коммуникации (и, возможно, располагает специальными эксплойтами против названных протоколов), вы будете гораздо лучше защищены, чем при передаче данных открытым текстом.
  3. Исходите из того, что хотя ваш компьютер могут взломать, для АНБ это будет дополнительной работой и риском, так что, вероятно, он не взломан. Если имеете дело с чем-то действительно важным, используйте автономные не подключенные к сети системы. С тех пор, как я начал работать с документами Сноудена, я купил новый компьютер, который никогда не подключал к интернету. Когда мне нужно передать файл, я зашифровываю его на безопасном компьютере и отношу к своему сетевому компьютеру на флэшке. Чтобы расшифровать что-то, я действую в обратном порядке. Этот метод не безупречен, но достаточно хорош.
  4. Относитесь с подозрением к шифровальному ПО, особенно от крупных разработчиков. Полагаю, что большинство криптографических продуктов от больших американских компаний имеют бэкдоры для АНБ и, скорее всего, множество зарубежных тоже. Будет разумным допустить, что иностранные продукты идут в комплекте с собственными иностранными бэкдорами. АНБ проще встроить закладки в закрытое ПО, нежели в ПО с открытым исходным кодом. Системы с общими секретами более уязвимы для АНБ, за счёт как законных, так и нелегальных методов.
  5. Старайтесь использовать стандартные методы шифрования, которые должны быть совместимы с другими реализациями. Например, АНБ труднее встроить бэкдор в TLS, нежели в BitLocker, поскольку реализация TLS у одного разработчика должна быть совместимой со всеми прочими реализациями TLS, тогда как BitLocker должен быть совместим лишь самим собой, что развязывает АНБ руки при внесении изменений. И поскольку BitLocker проприетарен, вероятность обнаружения в нём этих модификаций значительно ниже. Отдавайте предпочтение симметричному шифрованию над шифрованием с открытым ключом. Предпочитайте общепринятые системы на дискретных логарифмах перед системами на эллиптических кривых; последние содержат константы, проталкиваемые АНБ при малейшей возможности.

То время, что я работаю над документами Сноудена, я использую GPG, Silent Circle, Tails, OTR, TrueCrypt, BleachBit и ещё несколько вещей, о которых мне бы не хотелось распространяться. В моей программе Password Safe есть недокументированная шифровальная функция, доступная из командной строки; её я тоже использую.


Я сознаю, что большинство перечисленного невозможно для простого интернет-пользователя. Даже я сам не использую все эти инструменты для всего, над чем я работаю. И я по-прежнему, к сожалению, использую в основном Windows. С Linux было бы безопасней.


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


Доверяйте математике. Шифрование — ваш друг. Хорошо обращайтесь с ними и сделайте всё от вас зависящее, чтобы они не были скомпрометированы. Это поможет вам оставаться в безопасности даже перед лицом АНБ.


© 2013 Брюс Шнайер
Перевод © 2013 SATtva

 
На страницу: 1, ... , 3, 4, 5, 6, 7, ... , 18 След.
Комментарии [скрыть комментарии/форму]
— Гость (11/09/2013 08:02)   <#>
Все вышесказанное теоретически правильно, но слабо относится к реальной жизни. Никогда нельзя быть в чем-то на 100% уверенным, поэтому в ход идут разные компромиссы и перестраховки. Вы же советуете либо класть все яйца в одну корзину, либо вообще не класть, жить без яиц.
— Гость (11/09/2013 08:20)   <#>
На входную дверь в квартире ставят минимум два замка с разным принципом действия. А данные почему-то шифруют одним шифром, хотя использование каскада дешевле чем второй дверной замок, а ущерб от взлома шифра будет намного больше чем от квартирной кражи.
— Гость (11/09/2013 08:42)   <#>

Чувство ложной защищённости — широко известный эффект. Вот обратный эффект* куда тоньше тоньше.


Уже.


Как правило — да, но, как я понял, не всегда, поэтому надо смотреть внимательно на каждый случай.


Конечно, нет.


Академики — это единственное, что имеет под собой хоть какую-то (пусть и неидеальную) основу, всё остальное — это суеверия и народные поверья уровня «с какой ноги встать». В акадмической литературе рассмотрено много всего того, что пока никак не реализовано на практике. Даже если придерживаться вашей логики, то для начала стоит впитать и понять хотя бы академические разработки (а их немало, в том числе, и по каскадам), прежде чем пускаться во все тяжкие.


Да, но перестраховки не должны сводиться к суеверям, дающим ложное ощущение дополнительной защиты.


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


Каскад имеет смысл только при независимых ключах. 256-битный пароль выглядит вот так:
Z"`Hgt8H:?)2g!zqmNCdEv_n#Zb>6u^bwCA23mP
Если у вас каскад из двух 256-битных шифров, то вам надо запомнить минимум что-то такое:
k+a1,%|R$]Fr!yb5yr1rFpsbwB|UKIQn*X/9XHv"ZFvJZ|RyymM}#uE6qJ;<&8xVBW]K<]oJaf_7,s
Если запоминание таких паролей для кого-то составляет проблему, то каскады ничем не помогут. Предполагаю, что это одна из причин их непопулярности (усилить блочный шифр, используя одинаковые ключи, не получится).

*Заставить противника обшибочно считать, что самый лучший инструмент — уязвимый, вынудив его перейти на менее безопасные и более уязвимые альтернативы.
— Гость (11/09/2013 09:14)   <#>
Почему же тогда общепризнанные, в том числе и здесь, TrueCrypt и DiskCryptor имеют поддержку каскадов? Их создатели небось не дураки, делали для себя и все шифруют тройным каскадом, а попсовые https и pptp делали для бизнеса, не избежав влияния АНБ.
— sentaus (11/09/2013 10:08)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Их создатели небось не дураки, делали для себя и все шифруют тройным каскадом, а попсовые https и pptp делали для бизнеса,


Производительность тоже учитывают. Более того, если посмотреть на финал AES, то явно выбирали самый быстрый из достаточно стойких, а вовсе не самый стойкий шифр.
— unknown (11/09/2013 12:04)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Truecrypt общепризнан не всеми, не везде, в т.ч. и здесь. Они нахимичили с лицензией, что странно для открытого проекта, в итоге они сами себя сделали лицензионно грязными и во избежание претензий их не стали включать в серьёзные Linux-дистрибутивы.

Во-вторых, Truecrypt — проект с открытым исходным кодом, не разрабатываемый открыто. Непонятная команда разработчиков договаривается между собой в узком кругу и релизит исходники текущих версий, но не ведёт всей разработки в режиме реального времени через публично доступный для просмотра Git или другую систему контроля версий. Так в серьёзных открытых проектах уже не делают, так делают или мелкие незначительные проекты, или только коммерческие компании, которые вынуждены релизить код по принципу "нате, держите и отвяжитесь со своими требованиями исходников по вашим лицензиям" (всякие проекты с открытыми исходниками от Google, Oracle и пр.).

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

*Т.е. максимально дружественного не только к свободам использования, но и по отношению к процессу разработки и обмена кодом.
— Гость (11/09/2013 12:46)   <#>
Ну раз уж коснулись Truecrypt, подскажите какой по надежности алгоритм лучше выставить в настройках шифрования: AES-Twofish-Serpent или Serpent-Twofish-AES?
И алгоритм хеширования: SHA-512 или Whirpool?
— unknown (11/09/2013 14:10)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Полагаю, что честно будет ответить "не знаю" на оба вопроса. Возьму смелость даже утверждать, что на данный момент это был бы честный ответ даже для ведущих специалистов-теоретиков, поскольку ответов на такого рода вопросы не знает никто.

В случае хэш-функций, если они применяются там только в режиме PBKDF2, то при правильной реализации, даже некоторые реальные уязвимости хэш-функций не дали бы никаких преимуществ противнику, даже теоретических: одно дело использовать коллизии для получения подставных подписей, другое дело пытаться подобрать пароль или ключ, где важнее псевдослучайность, необратимость, отсутствие возможностей сокращённых вариантов перебора.
— SATtva (11/09/2013 15:18)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4116
Ещё пара наблюдений от Фелтена — относительно стандартов, к которым АНБ приложило руку. Что толку использовать каскад, если ключи к нему могут быть сгенерированы затрояненным ГСЧ?
— Гость (11/09/2013 22:49)   <#>
Странное это противление каскадам. Странное...
— Гость (11/09/2013 23:20)   <#>

Ага. Вероятность встретить динозавра – 1/2. Либо встретишь, либо нет :)

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

Поэтому, если хотите спать спокойнее (не абсолютно спокойно, но гораздо спокойнее), используйте каскады.

А упорное отговаривание от этого вызвано, скорее всего, подсознательным зомбирующим влиянием чего-то типа Большого Брата. об этом есть в книгах Алексея Меняйлова
— Гость (11/09/2013 23:42)   <#>

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


Не знаю, почему LUKS не поддерживает каскады. Могу предположить, что дело в следующем:
  1. У систем повышенной безопасности низкая востребованность. Это мало кому нужно.1 Можете считать, что разработчикам и исследователям «нечего скрывать», а тем, кому есть что скрывать, не могут потянуть амбициозный проект. Если посмотреть на историю, многие проекты были изначально написаны не потому, что «а давайте напишем, почему бы и нет», а потому, что автору это было нужно для себя и своих целей. Если такой автор и его проект потом достигают некоторого уровня зрелости, наличие инструмента обществом начинает восприниматься обыденностью.2
  2. Системы повышенной безопасности опираются на плохо проработанные академические идеи, поэтому мейнстримные проекты относятся к ним скептически.3


Выше приведена ссылка на обсуждение улучшения криптопримитивов (тема про KeccaK). Почитайте её. В обсуждении участвовали все топовые действующие лица.


Это типично и для академических разработок. Посмотрите, как разрабатывается, например, Ocaml. Наука тоже так же делается по принципу «дуракам половину работы не показывают». Когда всё готово — статью/код/ещё что-нибудь релизят, пока не готово — сидят молчат.


Раз речь пошла об усилении шифрования, можно вспомнить о бессигнатурном шифровании и отрицаемости. Последние могут несколько затруднить взлом, т.к. противнику не будет известен ни заголовок, ни начало, ни конец криптотома (и, тем более, используемый алгоритм).


Каскад, при котором ключи на оба шифра одинаковые, сводится к попытке улучшения одного единственного шифра (что эффективно эквивалентно отсутствию каскада), а про такие наивные попытки улучшения всё уже было сказано в теме про KeccaK. Ссылки выше были приведены.


1StegFS была в Linux, это был вроде даже один из проектов Ассанджа, но её забросили.
2Трудно представить, что такого проекта могло бы в мире вообще не быть несмотря на то, что масса прекрасных интересных проектов загнулись, так и не вышедши на поддерживаемый уровень — та же StegFS, к примеру.
3Это же касается и отрицаемого шифрования и стеганографии, а не только каскадов.
— Гость (12/09/2013 00:10)   <#>

John says that NSA people and their allies worked consistently to make the standard less secure, more complicated, less efficient, and harder to implement securely. He didn’t see a smoking-gun attempt to introduce a backdoor, but what he describes is a consistent effort to undermine the effectiveness of the standard. And indeed, IPSEC has not had anything like the impact one might have expected.

Вспоминается история с IPSec в OpenBSD... Вполне возможно, это чёрный PR на 100%, но лишняя связь между IPSec и АНБ — это не к добру. А про ECC уже недавно вспоминали:

> Вы и Шнайер что-то такое знаете, но деталями не делитесь.
Делимся, но вы ж не читаете... Краткая история вопроса: здесь и здесь.

Извиняюсь за глупый вопрос, но что из конвенционального софта поддерживает каскады? PGP? GnuPG? OpenSSL? OpenSSH? Никто из перечисленных?
— Гость (12/09/2013 00:35)   <#>
Имеющиеся инструменты вроде бы позволяют делать каскады для основных задач – шифрования файловых систем и сетевых соединений. Двукратное бессигнатурное шифрование dmcrypt разными алгоритмами и ключами почти не усложняет жизнь. Для luks это тоже возможно, хотя и сложнее – для создания второго шифрованного виртуального устройства нужно сделать смещение с помощью dmsetup. Создание двухкаскадной vpn, например через ssh + через ssl тоже не вызывает особых проблем. Причём создаётся запас прочности не только по шифрованию, но и по сетевым протоколам – для взлома нужны уязвимости одновременно как в ssh, так и в ssl.
— Гость (12/09/2013 01:31)   <#>

И вот вопрос: почему повышенная безопасность не вызывает повышенного интереса в академическом сообществе? Поддчёркиваю, не в прикладном, а в академическом!
На страницу: 1, ... , 3, 4, 5, 6, 7, ... , 18 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3