Тема интересная, поэтому решил вынести из комментариев.
Почему в России ГОСТ, а не AES. Не совсем корректно так говорить, потому что российскими ГОСТами покрывается несколько алгоритмов шифрования, как симметричных, так и асимметричных, в то время как AES - это лишь симметричный, хоть и самый современный на текущий момент алгоритм шифрования, используемый правительством США.
Наши ГОСТы не отстают от американских, их постоянно совершенствуют и в общем, они, по крайней мере теоретически, нисколько не уступают зарубежным аналогам.
А вот причины разработки собственных алгоритмов более интересны. По крайней мере одна из них связана с параноидальностью российского общества. Русские власти боятся даже не того, что враг (то бишь американцы) знает уязвимость и молчит. Власти уверены, что в американские алгоритмы шифрования заложены закладки. Впрочем, их опасения не беспочвенны.
Одни из недостатков ГОСТов является большое неудобство их использования разработчиками по сравнению с зарубежными аналогами.
О паранойи. Лирическое отступление. Приведу один несколько отвлеченный от темы пример. Несколько лет назад в российском обществе ходила страшилка о закладке в американских процессорах, позволявшей получить контроль над компьютером по сигналу из США. Какой контроль и по какому сигналу, не уточнялось, но страшилка была достаточно популярна в СМИ. На мой взгляд, как человека, имеющего какое-то отношение к ИТ - это бред сивой кобылы.Тем не менее, как-то зашла об этом речь при общении с коллегами на бывшей уже кафедре ИТМ. Так вот один очень известный в узких кругах сотрудник согласился с этой идеей.
За давностью лет уже не помню, на каком уровне паранойи он остановился. Точно утверждал, что для перехвата управления не нужно сетевое подключение и сетевой интерфейс в компьютере. Вроде бы и компьютер может быть не включен, главное, что бы он был подключен к электричеству. Но вот точно не помню, утверждал ли этот в общем-то очень умный и уважаемый человек, что можно перехватить управление компьютером, если он вообще не подключен к источнику питания. В принципе, батарейка-то там есть! Ой, а ведь не спроста ее туда установили! 😉
А вы верите в такие страшилки?
Вторая волна. Почти насильственное внедрение ГОСТов не только в критически важные области государственной тайны, но и в гражданские приложения порождает вторичную паранойю. Теперь уже многие внутренние пользователи подозревают, что в ГОСТах есть закладки, позволяющие при необходимости ФСБ легко вскрывать шифрованные сообщения. Подогревают ее бессмысленные и беспощадные подзаконные акты к закону о персональных данных, требование хранить персональные данные россиян только на территории России и закон "Яровой".
Всё это оправдывается заботой о нашей безопасности. Ведь в импортных криптосистемах возможны утечки через закладки. А самописные приложения для шифрования без получения лицензии от регулятора так и вообще запрещены, насколько я знаю, под страхом уголовного преследования. Опять же из-за той же заботы. Ведь в самописном приложении вряд ли разработчики озаботятся доказательством его криптостойкости.
Открытый и известный алгоритм. Его преимущества очевидны. Но есть ли недостатки? Да, есть, на мой взгляд. Если уязвимость алгоритма очень трудна для обнаружения, не получится ли так, что те, кто сможет ее все-таки обнаружить, воспользуются этим? Раскрытие таких уязвимостей дело достаточно хлопотное и дорогое, позволить себе такие исследования могут гос. конторы или крупные корпорации. Естественно, вложив крупные средства в работу, они попытаются их отбить в виде финансовых или политических дивидендов.
Абсолютно неуязвимых алгоритмов, насколько я знаю, на практике сейчас нет. Популярные асимметричные алгоритмы построены на предположении об отсутствии быстрого решения некой математической задачи. Но это не говорит, что такого решения нет в принципе, и возможно, в будущем оно будет найдено.
Создание достаточно мощного квантового компьютера также скорее всего позволит очень легко и быстро вскрывать асимметричные ключи. Что приведет к краху сложившейся системы безопасности в ИТ-технологиях, так как будет потеряна возможность надежной передачи ключей симметричного шифрования.
Самая большая опасность раскрытия стандартных алгоритмов шифрования, на мой взгляд, состоит в том, что, так как алгоритм стандартный и им пользуются все, то команда криптоаналитиков после взлома больше не нужна. Достаточна техников, которые по команде, грубо говоря, нажмут кнопку и расшифруют необходимые данные. Но безнаказанность порождает вседозволенность. Не захочет ли кто из техников узнать, например, интимные пристрастия симпатичной соседки? Или сколько денег на счете у рядом живущего господина? Мотивов может быть сколько угодно. В результате под ударом может оказаться любой человек.
Получается, что можно сколько угодно пользоваться стандартными шифрованными каналами связи, полагаясь на их достаточную защищенность, а потом выяснится, что кто-то нашел (или встроил) уязвимость и уже не один год сливает молчком себе все конфиденциальные данные.
Принцип Керкгоффса. Собственно, я и не утверждал, что алгоритм шифрования должен быть секретным. Я говорил лишь о том, что для попытки вскрытия нестандартного алгоритма требуется гораздо больше усилий. Если для стандартного алгоритма уязвимость найдена, то нет потребности содержать большое количество криптоаналитиков, достаточно техников. С учетом того, что построить относительно неплохой алгоритм не очень сложно, то, при наличии большого количества разных алгоритмов, ресурсов для вскрытия их всех может просто не хватить. Собственно, в этом одна из причин запрета на использования не сертифицированных алгоритмов шифрования в России.
Сам принцип Керкгоффса не исключает использование секретных алгоритмов. В частности, военные любят использовать отличающиеся от стандартных алгоритмы, что затрудняет их вскрытие. Тем не менее, в соответствии с принципом, знание алгоритма не должно упрощать вскрытие шифра. Но его незнание делает вскрытие в принципе невозможным. В этом фишка.
Timing attack. Классная идея. Но у меня сложилось впечатление, что это очень близко к сферическому коню в вакууме. То есть это отлично работает, если удалось установить программу-агент на взламываемый комп. Правда, в этом случае возникает вопрос: не проще ли просто украсть открытый текст, или сам секретный ключ?
Вроде метод хорошо работает и из-за сетевого интерфейса, то есть в случае если наш агент сидит в локальной сети. И даже работает через несколько маршрутизаторов. Вот только авторы обычно обходят стороной вопрос загруженности этой сети и взламываемого сервера. Если сеть и/или сервер сильно загружены пакетами/запросами, то успешность такой атаки очень сильно снижается, так как полученные временные данные оказываются сильно зашумлены случайными помехами.
Но самое главное состоит в том, что эта атака хороша на алгоритмы типа RSA, где используются сложны точные операции, такие как многобитные операции возведения в степень, скорость выполнения которых зависит от сложности ключа.
В случае симметричных алгоритмов, вроде того, что я рассматривал, скорость его работы никак не зависит от сложности ключа, поэтому такой подход для взлома вообще не приемлем.
Заключение. К чему это я все писал?
- Легкость создания достаточно стойких систем шифрования делает бессмысленным запрет на не сертифицированные системы. Кому надо - тот легко сделает нестандартный алгоритм шифрации.
- Хотел показать, что отсутствие криптостойкости ЛКГ не обязательно приводит к легкости вскрытия шифра. Но об этом в следующий раз.
- Даже не скомпрометированный стандартный алгоритм шифрования практически бесполезен в случае наличия СОРМ в ЦОДе. Спецслужбы просто заберут себе уже расшифрованные данные. Именно поэтому их так бесит Телеграмм. Кстати, он до сих пор работает, несмотря на все усилия Роскомнадзора.
Согласен ГОСТ с AES не правильно сравнивать, AES - он на слуху, название же Российского алгоритма я поленился гуглить, а оказывается у него не только номер, но и имя "Кузнечик" есть :)
ОтветитьУдалитьКак Вы правильно заметили удобство использования многое значит, тот же AES есть для любого языка, бери и используй, а вот с ГОСТ алгоритмами не уверен что легко можно найти реализацию под любую платформу, самому написать конечно можно, но не хочется.
Про страшилки я вполне допускаю что при определенной последовательности команд процессор может превратиться в тыкву, но вот то что он может сам отправлять что-то куда-то минуя ОС, это выглядит из области фантастики, хотя кто его знает...
Про утечку персональных данных: по приезду в Штаты я был очень удивлен на каком уровне безопасность здесь. Вход в интернет-банк только по логину и паролю никаких дополнительных кодов по СМС, страховку можно купить по телефону продиктовав ФИО, дату рождения и номер кредитки, ну может еще адрес. Даже для взятия в кредит приличной суммы на покупку машины потребовалось только поговорить по телефону и водя мышкой!!! расписаться на присланных по электронной почте документах. Данные конечно утекают и нужно следить чтобы на твое имя не взяли кредит или еще что-нибудь, но в целом система работает. Для добропорядочных людей - очень удобно и просто.
У стандартного алгоритма, как мне кажется, есть большое приемущество: огромное число математиков пытается найти в нем дыру :) Нестандартный же никому не интересен пока не потребуется вскрыть что-то очень важное. Хотя... как показала практика с Meltdown & Spectre даже серьезную уязвимость можно хранить в тайне достаточно долго.
Я если често не особо в курсе на сколько сложно создать свой алгоритм, но как мне кажется почти любая константа в том же AES очень важна и заменив условные 15 на 42 можно легко ослабить алгоритм даже не осознав это. Военные могут позволить создать собственный алгоритм шифрования и проанализировать его надежность, их бюджет наверное позволяет это, но я бы не стал доверять алгоритму написанному на коленке.
Про Timing Attack тоже согласен, теоретически атака возможна, вот какая то статья даже есть https://cr.yp.to/antiforgery/cachetiming-20050414.pdf, но на практике мала вероятна.
Про удобство ГОСТа. Самому писать, это жесть. Там встречаются достаточно сложные алгоритмы, погрязнуть в этом деле можно надолго. Реализация, я так думаю, есть, под все основные платформы. Но сам подход к построению криптографической системы не очень удобен. У меня жена по роду службы этим занимается. Если под windows там более-менее, то под java все не очень хорошо. Во-первых, отсутствует достаточно подробная документация, во-вторых, служба тех. поддержки не очень хорошо работает. В результате реализовывать криптозащиту с использованием госта приходится зачастую методом проб и ошибок. Много времени уходит и нервов.
ОтветитьУдалитьПро страшилки. Ну ладно, последовательность команд, может быть. Но вот как процессор сигнал-то может принять без сетевого интерфейса? Не говоря про то, что бы отправить. КМК, и то, и другое технически не реализуемо.
Про персональные данные в штатх пока нормально. Все обычные гражданские системы должны быть в первую очередь удобны для людей. У нас же на людей плевать, идут по пути максимальной защиты, чуть ли не на уровне гос. тайны, не задумываясь, нужна она или не нужна. Собственно, зачем так параноидально защищать данные о том, что некий имярек купил булку хлеба? И не смотря на это, а точнее даже благодаря этому, люди в России мошенничают вовсю. У меня вон пенсию перевели из одного пенсионного фонда в другой. )
Математики, конечно, стараются. Но уж больно проблема, например, факторизации целых чисел, сложна. Если за несколько сотен лет не был найден алгоритм, способный решить проблему за полиноминальное время. Понятно, что решить проблему может и одиночка, но это крайне маловероятно. Скорее всего это будет крупный и очень дорогой проект, и найденное решение (если оно вдруг состоится) по вопросам безопасности может быть зашифровано на весьма долгий срок.
Доверять алгоритму, написанному на коленке, конечно же не стоит, без серьезного обоснования его криптостойкости. Мне просто интересно, я и придумываю всякие разные варианты из любопытства, не более того. Народ вон тоже такой ерундой активно балуется.
С другой стороны, когда особых секретов нет и при передачи по открытым каналам нет смысла особо чего-то прятать, то не важно, открытым текстом ушло сообщение, зашифрованное стандартным или каким-то любительским алгоритмом.
> Реализация, я так думаю, есть, под все основные платформы.
УдалитьЗа 5 минут гугления я не смог найти открытую реализацию Кузнечика на той же Java, может я что-то не понимаю но по моему это все еще основная платформа для enterprise приложений...
> Но вот как процессор сигнал-то может принять без сетевого интерфейса?
Кусок кремния конечно ничего никуда передать и принять не может, но вдруг он в сговоре с сетевым интерфейсом от того же Интелла? :))) Хотя такие вещи проще уже на уровне ОС делать, чем в железках.
> У нас же на людей плевать, идут по пути максимальной защиты, чуть ли не на уровне гос. тайны
Мне эта история с защитой данных чем-то напоминает 10 летнюю ситуацию с картами, когда детальные бумажные карты были секретны, а на Google Maps все было доступно :) Так и здесь запрещай не запрещай, а современный мир он такой какой и есть.
> Мне просто интересно, я и придумываю всякие разные варианты из любопытства, не более того.
:)
> За 5 минут гугления я не смог найти открытую реализацию Кузнечика на той же Java
УдалитьТут ничего сказать не могу. Но прикладники обычно так глубоко не копают. Обычно используют интерфейс более высокого уровня. Смысл в том, что, насколько я понимаю, современные системы работают примерно так:
1. Устанавливают тем или иным способом шифрованный канал с использованием асимметричного алгоритма шифрования, в котором передают сеансовый ключ симметричного шифрования. Это связано с тем, что асимметричные алгоритмы обычно очень медленные, в отличие от симметричных.
2. После обмена ключей в рамках сеанса идет симметричное шифрование, например, с использованием Кузнечика.
Прикладнику главное выполнить п. 1, выбрав правильные версии протокола и ключей. П. 2 от прикладника обычно скрыт, да и не нужен, так как если корректно выполнен п. 1, то п. 2 выполняется автоматически. Поэтому, когда я писал про сложности, я имел в виду именно такой прикладной уровень.
> но вдруг он в сговоре с сетевым интерфейсом от того же Интелла?
А вдруг сетевой интерфейс не подключен? Или стоит дискретная сетевая карта? Или набор логики не интеловский на материнке? Слишком много если, так что надо этот вариант просто отбросить, в соответствии с бритвой Оккамы.
В ОС реализовать гораздо логичнее, но тут возникает вопрос, как сигнал по сетям общего доступа доберется до пользовательского компа, закрытого многочисленными фаерволлами и зачастую не имеющего даже реального IP? Сплошная мистика, короче.
Как по мне, так весь этот бред надо оставить поклонниками теории мирового заговора. )
Да все так, как Вы описали, но вот простая прикладная задачка: нужно хранить важные данные в БД/на диске, в общем где-нибудь, так чтобы приложение могло их прочитать, а админ не мог и желательно без значительного замедления системы.
УдалитьСтандартный и универсальный подход - это шифрование на клиенте (сервере приложений). Заводим табличку: id ключа, ключ симметричного шифрования. Шифруем ее ключи ассиметричным публичным ключом, приватный ключ храним надежно, так чтобы только приложение могло его получить. Остальные данные шифруем симметричным ключом и записываем рядышком id-к ключа. Осталось приватный ключ ассиметричного шифрования не потерять и не раскрыть, но это по проще чем трястись за все гигабайты данных.
Если без паранойи, регуляций и ГОСТа, то тот же AWS позволяет все это организовать очень элементарно, он и ключи надежно хранить может и все API предоставит, буквально в 10 кликов можно все включить. Весь вопрос доверия, но если честно я ему больше доверяю чем себе :)
Если писать самому то тоже вроде не очень сложно, но нужно уметь вызывать все эти ГОСТ алгоритмы. В случае опять же Java есть стандартный API: https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html, но из коробки он ничего не знает о ГОСТе и кто-то должен по хорошему эти алгоритмы добавить и поддерживать, желательно виновник торжества :) Кстати для Java вроде есть какая-то реализация: https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/symmetric/GOST3412_2015.java, но на сколько она правильная и поддерживаемая это вопрос.
Идея понятна. Только вот такой вопрос: админ имеет доступ к приложению?
УдалитьУ жены поинтересуюсь, какими они библиотеками пользуются. Если чего интересное будет, то отпишусь.
- Админ БД - не имеет доступа к ключам.
Удалить- Админ приложения - да, но не факт что он вообще есть, вполне возможно что разные бизнес пользователи имеют админский доступ к различным подсистемам, но одного супер админа вообще нет.
Это все в теории :) на практике обычно конечно есть админ со всеми правами, потому что это проще...
Тот, кто имеет доступ к приложению, насколько я понимаю, может легко получить доступ к закрытом ключу, хотя бы через отладчик.
УдалитьЕсли же в этом случае полагаться на защищенное хранилище ключей, то не понятно, зачем использовать асимметричное шифрование? Ведь в этом случае и симметричный мастер-ключ обеспечивает тот же уровень безопасности. Разве нет?
Жена в своей работе использует сертифицированную ФСБ версию CryptoPro. Не самую последнюю, но одну из. Кузнечика там пока что нет. Видимо, ФСБ пока не понуждает использовать самые последние версии. Года через два будет очередной ахтунг, когда ФСБ начнет требовать, и все ПО на старой версии протокола перестанет работать. )
Согласен, что-то я переусложнил, симметричного шифрования вполне хватит.
Удалить