Принципы безопасности: общее описание

Ранее мы уже познакомились с одним из основных принципов безопасности: принципом изоляции и разделения. Далее я опишу ещё несколько принципов. Названия я выдумал сам. Главное - не название, а содержание.

Принцип дублирования В каждом методе защиты могут быть неучтённые уязвимости. Поэтому, в идеале, мы должны строить систему так, чтобы один метод защиты дублировал второй. Например, при шифровании можно воспользоваться двумя шифрами вместо одного. Если один из них будет взломан, то другой прикроет первого. Аналогично, если подписать файл двумя цифровыми подписями вместо одной, то взломать их будет тяжелее. Например. Представим себе, что мы - разработчики криптографического программного обеспечения. Когда-то ещё был вполне жив 128-битный хеш md5. Следующий после него по стойкости был sha-1 160 битов. Допустим мы подписали некоторый документ двумя цифровыми подписями: один с хешем md5, а другой с хешем sha-1. Теперь хеш md5 взломали. sha-1 всё ещё доказывает правоту цифровой подписи. Прошло какое-то вермя - взломали и sha-1 (в 2017-ом году Google провёл успешную экспериментальную подделку хеша sha-1). Плюс данной системы в том, что даже тогда, взломать одновременно два хеша было бы всё ещё затруднительно. То есть мы получили защиту даже больше, чем самый сильный хеш. Вообще говоря, принцип дублирования не означает, что один из методов может быть нестойким. Оба метода должны быть стойкими. Такой двойной алгоритм должен был быть выведен из строя не позднее 2005-ого года, так как в 2005-ом году на md5 уже была проведена успешная практическая атака, а в 2004-ом сообщалось о серьёзных уязвимостях. Ещё в 1993 году md5 получил первые теоретические наработки по взлому. Таким образом, мы должны были бы готовится к отказу от этого хеша заранее. Поэтому, не позднее 2005-ого года мы должны были бы заменить md5 на более стойкий дублирующий алгоритм. Например, RIPEMD-160. Таким образом, в 2005-ом году мы заменили md5 на, допустим, RIPEMD-160. Теперь в паре стоят RIPEMD-160 и sha-1. В 2017-ом году такие мы должны были бы отказаться от sha-1 в пользу более стойкого алгоритма.

Принцип недоверия Мы недоверяем методам защиты, считая, что они недостаточно хороши. Даже тогда, когда мы думаем, что они хороши. Из предыдущего примера. Наши мы, как воображаемые разработчики, отказались от md5 только в 2005-ом году, когда была произведена практическая атака на md5. Учитывая принцип недоверия, мы должны были бы выбирать как можно более стойкие алгоритмы хеширования. В 95-ом году была опубликована версия стандарта SHA-1. Будем считать, что именно в этом году мы начали программировать свою криптографическую систему. И мы выбрали SHA-1 как основной метод, а md5 - как дополнительный, дублирующий. В 96-ом году на md5 была произведена теоретическая атака, а в 93-ем более простая теоретическая атака. Так как к нам поступает информация о том, что md5 недостаточно хорош, мы, как разработчики, должны взволноваться :) . В 96-ом году был опубликован стандарт RIPEMD-160. Так что нам уже было бы на что переходить. Как видим, используя принцип недоверия, мы переходим с хеша md5 на RIPEMD-160 на 9 лет раньше. То есть обеспечиваем больший запас по прочности алгоритму в 9-ть лет. Однако, мы не спокойны. Хотя бы потому, что оба алгоритма у нас на 160-бит, а более слабый алгоритм взломан. Поэтому, мы хотим заменить их на что-то более интересное. В 2000-ом году выходит 512-битный Whirlpool и мы можем сменить один из алгоритмов на другой. Но как определить, в какой из алгоритмов заменить на Whirlpool? SHA-1 имеет размер 160 битов и опубликован в 95-ом. RIPEMD-160 опубликован в 96-ом и также имеет размер 160 битов. Подбрасывать монетку? Не обязательно. Здесь можно подумать над тем, что sha-1 - это правительственный стандарт США, разработанный в недрах NSA. А RIPEMD-160 и Whirlpool - академические стандарты. Далее можем вспомнить про то, что NSA регулярно ранее не заботилось о стойкости алгоритмов шифрования. Поэтому мы можем заменить sha-1 на Whirlpool. То есть здесь мы используем основания недоверять NSA. Может быть и другая логика. Давайте оставим один стандарт правительственный, а один - академический. Логика тоже хороша. Я выберу вторую. Мы заменили RIPEMD-160 на Whirlpool. Пока разбирались и программировали наступил уже 2001-ый. Теперь у нас Whirlpool и sha-1. Если вам стало лень читать, пролистайте часть текста ниже. В 2002-ом году выходит sha-2. Как разработчики, пользующиеся принципом недоверия, мы стараемся недоверять всему. Однако, этот алгоритм предусматривал существенно большие длины хешей. Значит, обещает большую защищённость. Так как у нас есть правительственный стандарт, разработанный той же организацией, то мы просто заменим sha-1 на sha-2. Так как мы ничему не доверяем, мы будем использовать самую стойкую версию sha-2 - 512 битов. Тем более, что Whirlpool тоже 512-ти битный. Далее. В 2005-ом году была опубликована серьёзная атака на sha-1. Но мы уже отказались от него. Заметьте, на 12 лет ранее, чем в случае простого дублирования. То есть мы выиграли для наших пользователей лишние 12-ть лет повышенной стойкости. Теперь у нас Whirlpool + sha2 512 битов, который не взломан до сих пор (на момент 2020 года). Однако, в 2008-ом году индийские исследователи опубликовали довольно достойную атаку на sha-2. Мы могли бы взволноваться снова. Но чем заменить sha-2? В 2009-ом на Whirlpool также была опубликована серьёзная атака. Но заменить ни тот хеш, ни другой нечем. Ну если только ещё какой-то третий брать. Так как эти уже под подозрением. В этот момент времени NIST проводит конкурс на новый алгоритм. Наверное, стоит подождать его. В 2011 году 5 штук функций прошли в финал конкурса. Возможно, мы выбрали одну из них. Например, BLAKE. Но, возможно, решили подождать. И вот, тёплой осенью 2012-ого года NIST разрождается стандартом. Функция keccak объявлена победителем. Теперь мы берём и заменяем наши алгоритмы уже на keccak и BLAKE. И хотя доступны алгоритмы 256 битов, мы берём максимум - 512-ть битов. Мало того, мы задумываемся, что будет, когда оживут квантовые компьютеры??? Может стоит сделать хеш большей длинны? Но ничего интересного на виду нет.

Такой вот логикой мы пытаемся не просто дублировать алгоритмы, но ещё и недоверять им, выявляя и используя самые стойкие из них. Таким образом мы выигрываем приблизительно по 10 лет криптостойкости на каждый алгоритм. Как мы видим, тут даже постоянно напрашивается использование третьего алгоритма с повышенной стойкостью. Недоверием к алгоритмам мы постоянно пытаемся также использовать и самые стойкие их версии. Несмотря на то, что они требуют более мощных машин для вычислений (или дольше ждать придётся).

Метод стопорных якорей. Мне неизвестно названия этому методу. Мне вообще неизвестно, чтобы кто-то прямо упоминал этот метод. Но он существует. Метод заключается в следующем. Когда вы принимаете решение, вы должны постараться остановится и подумать, что вы делаете. Задаться какими-либо вопросами, подходящими под ситуацию. Например: Где вы находитесь? Безопасно ли это? Можно ли отказаться прямо сейчас? На каких фактах основано моё решение? Как эти факты подтверждаются? Не могут ли меня сейчас обмануть? Манипулировать мною? ---------------------------------------------------------------- Пример 1. Вы хотите потратить деньги. Но ещё 5-ть минут назад вы не собирались их тратить и даже не думали об этом. Даже не так. "Потратить деньги" - неверная формулировка. Вы должны представить себе следующие ситуации: "Я тянусь туда, где лежат деньги или указываю туда" "Я достаю деньги или открываю карман с ними" "Я хочу отдать деньги любым способом". Не заплатить, а именно отдать. Вы должны представить себе ситуации такого типа. Представьте себе, что вы останавливаетесь в такие моменты и задумываетесь, то ли вы делаете, что необходимо сделать? Не важно, что происходит. Остановись. Что я сейчас делаю? Какие эмоции заставляют меня хотеть тратить деньги? Я хочу их потратить или я стесняюсь отказать? Точно ли я получу то, что хочу? Если вы чувствуете, что сейчас будет стандартная ситуация, вы можете задаться этими вопросами заранее и, например, на кассе магазина отдавать деньги зная, что вы сейчас их хотите отдать. В остальных случаях надо выработать реакцию: если вы хотите отдать деньги или даже просто думаете потянуться к ним (купюрам, банковским картам) - остановись! ---------------------------------------------------------------- Пример 2. Я ввожу пароль или пин-код. Остановись! Туда ли я ввожу пароль? Тот ли пароль я хочу ввести? Кто на меня сейчас может смотреть? А через окно или видео? Я должен проверить, что сайт в строке - верный. Я долежн проверить, что я намереваюсь взять из менеджера паролей верный пароль Если я ввожу пароль с клавиатуры, я должен проверить, не смотрит ли кто на меня и, в идеале, накрыть клавиатуру чем-либо. ---------------------------------------------------------------- Как этому научится? Конечно же, всегда могут быть проблемы. Однако общий смысл обучения таков. Если хотите сами выявить новый стопорный якорь, то. Вы внимательно читаете обучающие материалы, обращаете внимание на рассказы о том, как кого-то пытались обмануть или обманули. Вы оцениваете, какие именно ситуации для вас являются опасными. Что в них общего? Какое действие или сигнал может послужить вам стопорным якорем? Например, желание достать деньги или ввести пароль. Якорь должен быть где-то близко к опасным действиям, но не всегда. Далее вам нужно научиться стопорному якорю. Вы представляете себе обычные ситуации, в которых нужно будет остановится. Представляете себе нежелательные ситуации, в которых нужно будет остановится. Убеждаетесь, что выбрали правильный способ останова (правильный стопорный якорь). Что он предотвратит нежелательную ситуацию, но не помешает в обычной. Затем, представляете себе несколько раз такие ситуации, или даже, если это что-то простое, типа ввода пароля, проигрываете их вживую в безопасной обстановке. Везде вы акцентируете своё внимание на стопорном якоре: на действии, которое вы только ещё собираетесь сделать. Но останавливаетесь. Не делаете его. А делаете то, что заучили до этого: задаёте себе вопросы. Поднимаете руки с клавиатуры. Или ещё что-то. Каждый раз, выполняя такие действия, вы акцентированно останавливаетесь на стопорном якоре. Вы обращаете внимание на то, что вы остановили все совершаемые вами действия и оцениваете обстановку. Далее мы остановимся подробнее на некоторых стопорных якорях. Их не так много и надо.

Принцип необходимости проверки (Проверяй!) Когда ты принимаешь решение, постарайся проверить факты, на основе которых ты принимаешь это решение. Мы уже обсуждали в главе про доверие о том, что мы иногда вынуждены доверять. Однако, если мы можем не доверять - мы должны не доверять. Например, если мы можем проверить надёжность метода защиты, мы должны его проверить. Конечно, если это не опасно и не слишком затруднительно. Когда-то я настраивал свой фаервол (он же межсетевой экран - МСЭ) на личном компьютере. В этой копии ОС я настраивал его очень жёстко: даже браузер мог выходить только по определённым IP-адресам. При этом, чтобы не долбаться указанием IP-адресов, я просто указал в МСЭ доменные имена. Грубо говоря, написал "yandex.ru". Что я сделал дальше? Дальше я воспользовался принципом "Проверяй". Я запустил браузер и ввёл туда несколько доменных имён: как тех, что должны были открываться, так и тех, которые не должен был открываться. Каково же было моё удивление, когда часть из адресов открылась. Я смог попасть, скажем, на mail.ru, хотя данный адрес не был разрешён. Часть адресов была заблокирована, а часть - открывалась. Оказалось, что это дефект работы выбранного МСЭ (COMODO Internet Security), причём в фирме о ней знают, но не исправляют уже, наверное, более 10-ти лет. Бывают ситуации, когда проверка показывает недостатки в настройках. То есть ошибку сделал тот, кто настраивал. Поэтому всегда нужно проверять, что всё работает так, как должно работать: блокирует там, где нужно блокировать, не блокирует там, где не нужно блокировать.

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

Принцип простоты. Представим себе, что у нас есть сложное программное обеспечение, допустим, Microsoft Word или Libre Office (Open Office), которые способны открывать *.doc-файлы или, скажем, pdf или любые другие сложные форматы. И также есть любой текстовый редактор формата *.txt. Все они написаны на одних и тех же технологиях и всё у них примерно похоже. Какой из них будет безопаснее? Конечно же редактор файлов *.txt. Почему? Давайте посмотрим, что нужно, чтобы редактировать txt-файл. Нам нужно вывести на экран текст каким-либо шрифтом, не обязательно всеми подряд причём. Например, можно использовать только моноширинные шрифты, что упрощает расчёт места, занимаемого символами. Текст очень прост по форматированию, так что его будет довольно просто выводить на экран. Редактирование текста тоже довольно просто: нужны операции вставки, удаления, добавления в файл текста. Чтобы редактировать, или хотя бы открыть, doc или pdf документы нужно: Уметь выводить на экран все шрифты, которые есть. В том числе, не моноширинные. Шрифты в таких документах часто могут встраиваться В сложных форматах файлов часто используется сжатие. Так что нужна библиотека для сжатия (архиватор). В сложных форматах файлов можно отображать картинки. Причём разных форматов. Так что требуется библиотеки для отображения картинок. Потребуется сохранять кучу служебных полей внутри файла, так как они в этих файлах есть (кто написал, когда и т.п.) Сам формат файла более сложный: чтобы его открыть и просто получить доступ к тексту, нужно уже постараться. В таких документах часто ещё и макросы бывают или, по крайней мере, возможность подгрузки внешних объектов. Сами поля файла могут быть незаметны для непрофессионала и открыть реальное авторство файла, который должен был быть анонимным (забытые поля "Автор" или, скажем, GPS-позиционирование картинок). Таким образом, раз можно встроить шрифт в документ, то можно встроить и вредоносный шрифт. Такие бывают. В архиваторах тоже бывают ошибки, и могут быть и критические. В библиотеках для отображения картинок также неоднократно находились критические уязвимости типа RCE - remote code execution - удалённое исполнение кода. При обработке сложного формата как такового пишется значительно больше кода, а значит, в этом коде можно сделать больше ошибок. Про макросы я уже вообще молчу: они могут сделать много чего вредоносного. Подгрузка внешних сущностей также может позволить, например, узнать IP-адрес человека, открывшего документ. В некоторых ситуациях это может позволить в дальнейшем отследить человека, узнать его личность. Или вообще, подгрузить туда что-то заражённое прямо из интернета. Практически всего этого нет в текстовых редакторах документов в формате txt. Конечно, в txt не положишь картинку, не сделаешь таблицу и т.п. За счёт своей простоты txt-редакторы настолько более безопасны, что я никогда не слышал о том, чтобы в них нашли критические уязвимости (исключая DLL HiJacking: но это проблема скорее ОС, чем программ). В то же время, иногда кажется, что сложные редакторы являются просто бесконечным источником уязвимостей и ошибок. Таким образом, то, что просто, обычно содержит меньше ошибок. Это касается и конспиративных мер. Если вы делаете сложные меры, то вероятность в них ошибиться обычно выше, чем в простых мерах. Конечно же, это означает, что от чего-то придётся отказаться: txt-файлы гораздо менее красочны и не могут отображать картинок, таблиц и т.п. Но безопасность может того стоить. Для важных сообщений никогда не используйте никаких форматов, кроме простого txt. Вообще, если у вас есть отдельный компьютер для криптографии, никогда не открывайте на нём и не посылайте другим людям какие-либо файлы, кроме txt. А если очень нужно, посылайте картинки отдельно. В крайнем случае - пошлите HTML. Вы можете даже договориться о том, что отсылка сообщения в doc или pdf-файле сама по себе будет знаком того, что вы под контролем (только пусть это будет не единственный ваш знак). Принцип простоты очень важен. Мы уже касались простоты кода и ранее - когда сравнивали асимметричную и симметричную криптографию. Симметричная криптография более проста - и более надёжна. Конечно, простота не всегда хороша. Например, шифр цезаря очень прост, но абсолютно ненадёжен. Простота в данном случае заключается в уменьшении объёма исходных кодов программы. Таким образом, раз объём уменьшен, значит ошибок будет меньше. Аналогично, чем меньше людей знает информацию, тем меньше вероятность того, что её кто-то продаст насторону.

Методика одной способности При проектировании средств защиты мы предполагаем, что наш злоумышленник обладает какой-то одной, но сверхестественной способностью. Например, он умеет проходить сквозь двери. Но не сквозь решётки. Или наоборот: сквозь решётки и двери с окошками - умеет, а сквозь сплошные двери - нет. Или наш злоумышленник способен гипнотизировать людей. Заставить их всех что-либо сделать или, например, просто усыпить. И так далее.

Принципы безопасности: общее описание 2.