Вообще когда смотришь на взрослых людей играющих в игры какое-то странное чувство возникает. Но с другой стороны умение играть это как раз то что и отличает нас от животных.
На момент написания статьи аккаунт… был доступен в Linkedin.
Сеть Linkedin заблокирована Роскомнадзором на территории РФ. В тоже время одна из ведущих компаний, которая выпускает и продает железки как раз для выполнения гос. требований требований с этой сетью активно работает… интересно получается :)
Статья в целом неплохая но не хватает конкретики, что делать Банка или Российским сервисным бюро в свете этой утечки.
Лично мне хватило бы абстрактного описания протокола. Реализацию тестить наlj все равно не на исходниках а снифать пакеты по факту.
Чистые симметричные крипто схемы очень неудобны в эксплуатации. Поэтому, судя по вашим ответам я предполагаю, что в ваша система сделана следующим образом.
На узлах сети, есть встроенные «магические» ключи. При начале обмена вы рандомом генерируете случайный сессионный ключ, шифрутете его магическим ключом и транслируете в сеть. Другие узлы видят пакет, расшифровывают его своим магическим ключом и извлекают от туда сеансовый ключ, так начинается сеанс обмена. Во время сеанса пакеты вы шифруте и считаете HMAC. Для защиты от повторов используется нумерование пакетов. Такой своеобразный протокол TCP.
Подобная схема как раз соответствует указанной выше модели угроз.
Это, конечно, всё хорошо. Только 1 человек — не годится. ФЗ №152 даёт исключения относительно физ. лиц. Это первое.
Второе...
Не понял о чем речь. Ну да ладно.
Если вернуться к Golos, то как вы на практике докажите, что их ключи есть ПД?
Считаю что Golos вообще зря заморочился на тему ПД и опубликовал эти слова в политике конфиденциальности.
Строить защиту по 152-ФЗ лучше с точки зрения анализа риска утечки. Если утечет база с предполагаемыми данными будут ли проблемы со стороны физ. лиц или нет. Если не будет, то можно забить, чтобы у вас там не лежало.
Всем кто считает меня параноиком, рекомендую посмотреть презентации с Positive Hack Days, где ребята ломали промышленную автоматизацию. Начало у пром. автоматики было такое же — «за цените как круто и удобно».
P.S. Мне просто интересно, как коллеги реализовали шифрование :)
При оценке безопасности вы, на мой взгляд, неправильно оцениваете риски.
Вы можете включать или выключать 220V. Если человек будет работать с электрической сетью и на нее будет несанкционированно подано напряжение это может привести к смерти.
Системы безопасности лучше внедрять и совершенствовать в начале продукта, а не когда он разошелся миллионным тиражом.
Про формально-юридический метод очень интересно!..
Вы утверждаете что «идентификация» и «информация которая определят прямо или косвенно» одно и тоже. Но в законе сказано не определяет, а информация, которая относится, а не определяет.
Используя указанный вами метод и смысловой анализ проведу разбор всего определения.
«ПДн — любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных);»
(0)
Определение задает отличительные признаки факта, позволяющие выбрать его из всего множества доступных фактов.
(1)
Рассмотрим влияние слов «прямо или косвено» на определение ПДн.
Отношение, как связь чего-то с чем-то, а в данном случае информации и физ. лица может быть прямое или косвенное, других типов отношений быть не может,
Поэтому упоминание типа связи — прямое или косвенное можно вообще опустить, поскольку они описывают все возможные варианты, соответственно получаем сокращенное определение
«ПДн — любая информация, относящаяся к определенному или определяемому физическому лицу».
(2)
Слова «определенному» или «определяемому» подразумевают что КТО-ТО определил или определяет физ. лицо,.на основании «любой информации».
Подчеркну, что в определении не указано КТО выполняет эти действия. Соответственно, если не заданы отличительные признаки, то лицом, которое «определяет» или для которого физ. лицо может быть «определено» может быть абсолютно любым лицом на земном шаре,
С учетом (0) и данного факта можно Сделать
Вывод 1 — если хоть один человек в мире может на основании рассматриваемой информации определить физ. лицо, то указанная информация является ПДн.
Пример, если хоть один человек знает что почта a@b.c принадлежит мне, то a@b.c — ПДн
С учетом приведенных фактов и выводов можно сделать
Если не можете привести схему, то продемонстрируйте хотя бы модель угроз по которой вы строили систему защиты.
И еще вы упомянули, что генерируете ключи случайным образом, опишите пожалуйста откуда вы берете энтропию и какой алгоритм генерации используете. Сноуден очень интересно рассказывал про «случайные» ключи шифрования.
Я максимально усложнил работу взломщикам, введя дополнительную защиту от брутфорса. Это всё, что я пока могу сказать.
НО применяя один и тот же ключ более чем к одному открытому тексту, злоумышленник перехватив зашифрованные данные способен к безключевому чтению. Вот такая вот защита от брут-форса…
Говоря о ПДн, все всегда начинаю вспоминать про идентификацию. Ради интереса открыл сейчас актуальную редакцию 152-ФЗ и поискал там слово идент* его нет…
Поэтому не стоит говорить о том, чего нет в законе. Есть только про установление личности в части биометрических ПДн но это не то.
К слову говоря идентификация была в первых редакциях 152-ФЗ, но еще раз подчеркну, сейчас ее нет.
Определение ПДн в законе МЕГА КРИВОЕ и под него можно подвести что угодно. Я не хочу его защищать, но оперировать можно только тем, что написано в законе ну или найти разъяснения высших судов.
Никто другой, кроме судов, включая Роскомнадзор толковать законодательство не имеет право…
А про суды общей юрисдикции можно сказать, что в России не прецедентное право, и по одинаковым ситуациям могут быть вынесены диаметрально противоположные решения. Выигрывает тот, чей адвокат / прокурор лучше умеют говорить.
Из политики конфиденциальности по ссылке
1.1. Сервис собирает, получает доступ и использует в определенных Политикой целях техническую и иную информацию, связанную с Пользователем.
ст. 3 152-ФЗ «О перс. данных»
1) персональные данные — любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных);
Вывод, если пользователь физ. лицо, сервис обрабатывает перс. данные.
Коллеги, прошу не понять меня неправильно. Я интересуюсь безопасностью IoT с профессиональной точки зрения и не в коем случае не хочу критиковать вашу разработку. Но…
ECB+CBC+собственные алгоритмические решения. В итоге я остался доволен,
Пугают собственные алгоритмические решения. В подавляющем большинстве случаев подобные решения гораздо хуже стандартных с точки зрения безопасности. Это общеизвестное мнение доказанное практикой и неоднократно озвученное и доказанное метрами в криптографии, такими как Б. Шнаеер, да и отчетами pentest-ров. Надеюсь что у вам не так. Можно узнать чем конкретно вы оказались довольны?
ECB/CBC/CTR в чистом классическом виде нормально при постоянной передаче данных не защищают.
ECB — алгоритм использования блочного шифра, допускающий применение при передаче данных размером не больше размера блока шифра. На практике применяется довольно редко и указан в запросе для того чтобы было понятно о чем спрашиваю.
CBC — применяется довольно широко, в том числе браузерами для TLS соединения. Американская налоговая FATCA принимает отчеты зашифрованные с использование данного режима шифрования
CTR — тоже широко используемый режим, позволяющий использовать блочный шифр как потоковый
Указанные режимы использования блочных шифров приведены в самом последнем госте по криптографии — ГОСТ 34.13-2015. Поэтому утверждать про отсутствие нормальной защиты… ну вы поняли :)
Ключи создаются случайным образом.
А как они тогда распространяются / согласовываются?
Поясню на примере. Указанная вами схема криптографической защиты с применением блочных симметричного шифра будет похожа на передачу файла зашифрованного с помощью архиватора, так называемый архив на пароле.
Например, я хочу послать файл вам, придумал случайный ключ (пароль), зашифровал файл и отправил его вам по эл. почте. Но как вы его расшифруете? Вам каким-то образом нужно будет узнать ключ (пароль)
Это и есть то о чем я спрашиваю.
Режимы использования блочных шифров, механизмы согласования ключей обычно являются частями комплексных протоколов прикладного уровня, таких как например IPSec, OpenVPN, TLS и др. Данные протоколы проанализированы вдоль и поперек, что позволяет сделать суждение об их безопасности.
В тоже время закрытые разработки подобной уверенности не дают.
Можете ли вы опубликовать полную схему использования криптографической защиты?
P.S. Одно из древнейших правил криптографии гласит, что безопасность криптосистемы должна базироваться на конфиденциальности ключей нежели применяемых алгоритмов.
Здраствуйте. Подскажите, может я просмотрел, а как по факту работает шифрование?
Если мы говорим про AES, то это симметричный криптоалгоритм, значит закрытый ключ должен быть распространен по всем узлам участвующим в обмене.
Соответственно вопросы:
1. Как устанавливаются/меняются ключи шифрования на узлах?
2. Какой алгоритм использования блочного шифра применяется ECB/CBC/CTR ...?
3. Какая длина ключа 128/192/256?
Ремарка, по поводу атак повторного использования на CRL.
УЦ выпускает CRL с периодичностью указанной у него в Регламенте, например раз в день.
Клиентский софт, должен загружать к себе CRL тоже с такой же периодичностью.
УЦ может выпустить CRL раньше срока например в середине дня, но клиентский софт его забирать в середине дня не будет, если явно не пнуть.
Когда подойдет время следующего обновления CRL, клиентский софт сам полезет на УЦ за новым CRL.
MITM подсунуть старый CRL (повторное использование) не сможет, поскольку у старого CRL протухнет дата (Next update), а подделать CRL нельзя так как он подписан УЦ.
Таким образом единственным случаем когда возможна атака повторного использования, это когда клиентский софт внепланово лезет за CRL, например проверяет его при каждом запросе, но проверка сертификатов по CRL не предназначена для online режима, как вы это обозначили раньше.
И еще. Проблема всей технологии PKI в том, что каждый интерпретирует/реализовывает ее по разному, а в некоторых случаях некоторые механизмы не реализовываются (не настраиваются админами) вовсе.
При внедрении SDL компания, сформирует что-то типа политики написания программного кода / разработки ПО.
Но для того, чтобы какие-либо требования работали, в том числе данная политика, нужен контроль их выполнения.
Как вы видите лучшую практику организации подобного контроля для небольших компаний, где есть 1-2 разработчика ПО и например 1 ИБист?
В свое время на уроке физики нам как-то рассказывали, что однажды спросили у ученых —
«Если будет потерянны все знания из физики, но будет возможность сохранить только одну теорию. что бы вы сохранили?» Ответ был — «Молекулярно-кинетическую теорию газов».
Интересно, какая информация считается важной в данном случае?
Смогут ли люди, например четвертое или пятое поколение выживших после апокалипсиса воспользоваться этой информацией? Если вспомнить историю, то например аборигены (или другие дикари) не умели смотреть фотографии.
И еще, послание инопланетянам на Вояджере было на золотой пластине, может от пленок лучше уйти к золоту?
Если только некий id, тогда непонятно причем тут ограничения на 4кб в куку, если же в сессии присутствует состояние полное состояние клиента, то для того чтобы его нехранить на сервере его надо шифровать и оно должно шифроваться на клиенте.
Спасибо за статью идея интересная но есть пару проблемных моментов.
1. HMAC — это не электронная подпись. Поскольку строится на базе симметричного ключа и соответственно может быть подделана одной стороной без возможности это опровергнуть другой стороной. Классическая ЭП на ассиметричной криптографии этого не допускает, поскольку ЭП строится с помощью закрытого ключа который есть только у подписывающей стороны.
2. В приведенных вами исходниках ключ шифрования вшит в код, а с учетом того, то шифрование должно осуществляться на стороне клиента этот ключ может быть перехвачен третьей стороной и после чего данные будут подделаны.
Пример. Вася подключается в Web-клиенту Банка. К нему грузятся скрипты, содержащие ключ шифрования.
Вася отключается, но ключ у него есть. Вася знает что у Зины на счету много денег. Он от имени Зины строит сессию (ему даже авторизовываться не надо) и совершает перевод.
3. Вы скорее всего скажите, что сессия будет защищена TLS. Но раз так, тогда смысла в доп. шифровании нет.
Для исправления ситуации необходимо как минимум для каждой сессии получать рандомный ключ шифрования. Но даже это не защитит от атак повтором. Поэтому нужно капать в сторону использования ассиметричной крипты.
Но на мой взгляд нужно делать продукт, который будет реализовывать «облачный токен» внутри компании.
Держать приватные ключи «где-то у кого-то» в Интернете можно только в исключительных случаях, когда ключи не представляют большой ценности.
Вообще когда смотришь на взрослых людей играющих в игры какое-то странное чувство возникает. Но с другой стороны умение играть это как раз то что и отличает нас от животных.
Сеть Linkedin заблокирована Роскомнадзором на территории РФ. В тоже время одна из ведущих компаний, которая выпускает и продает железки как раз для выполнения гос. требований требований с этой сетью активно работает… интересно получается :)
Статья в целом неплохая но не хватает конкретики, что делать Банка или Российским сервисным бюро в свете этой утечки.
Чистые симметричные крипто схемы очень неудобны в эксплуатации. Поэтому, судя по вашим ответам я предполагаю, что в ваша система сделана следующим образом.
На узлах сети, есть встроенные «магические» ключи. При начале обмена вы рандомом генерируете случайный сессионный ключ, шифрутете его магическим ключом и транслируете в сеть. Другие узлы видят пакет, расшифровывают его своим магическим ключом и извлекают от туда сеансовый ключ, так начинается сеанс обмена. Во время сеанса пакеты вы шифруте и считаете HMAC. Для защиты от повторов используется нумерование пакетов. Такой своеобразный протокол TCP.
Подобная схема как раз соответствует указанной выше модели угроз.
Не понял о чем речь. Ну да ладно.
Считаю что Golos вообще зря заморочился на тему ПД и опубликовал эти слова в политике конфиденциальности.
Строить защиту по 152-ФЗ лучше с точки зрения анализа риска утечки. Если утечет база с предполагаемыми данными будут ли проблемы со стороны физ. лиц или нет. Если не будет, то можно забить, чтобы у вас там не лежало.
P.S. Мне просто интересно, как коллеги реализовали шифрование :)
Вы можете включать или выключать 220V. Если человек будет работать с электрической сетью и на нее будет несанкционированно подано напряжение это может привести к смерти.
Системы безопасности лучше внедрять и совершенствовать в начале продукта, а не когда он разошелся миллионным тиражом.
Вы утверждаете что «идентификация» и «информация которая определят прямо или косвенно» одно и тоже. Но в законе сказано не определяет, а информация, которая относится, а не определяет.
Используя указанный вами метод и смысловой анализ проведу разбор всего определения.
«ПДн — любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных);»
(0)
Определение задает отличительные признаки факта, позволяющие выбрать его из всего множества доступных фактов.
(1)
Рассмотрим влияние слов «прямо или косвено» на определение ПДн.
Отношение, как связь чего-то с чем-то, а в данном случае информации и физ. лица может быть прямое или косвенное, других типов отношений быть не может,
Поэтому упоминание типа связи — прямое или косвенное можно вообще опустить, поскольку они описывают все возможные варианты, соответственно получаем сокращенное определение
«ПДн — любая информация, относящаяся к определенному или определяемому физическому лицу».
(2)
Слова «определенному» или «определяемому» подразумевают что КТО-ТО определил или определяет физ. лицо,.на основании «любой информации».
Подчеркну, что в определении не указано КТО выполняет эти действия. Соответственно, если не заданы отличительные признаки, то лицом, которое «определяет» или для которого физ. лицо может быть «определено» может быть абсолютно любым лицом на земном шаре,
С учетом (0) и данного факта можно Сделать
Вывод 1 — если хоть один человек в мире может на основании рассматриваемой информации определить физ. лицо, то указанная информация является ПДн.
Пример, если хоть один человек знает что почта a@b.c принадлежит мне, то a@b.c — ПДн
С учетом приведенных фактов и выводов можно сделать
Вывод 2
ПДн — любая информация относящаяся к физ. лицу.
Поэтому желание узнать обеспечивает ли шифрование безопасность вполне справедливое желание узнать потребительские качества решения.
И еще вы упомянули, что генерируете ключи случайным образом, опишите пожалуйста откуда вы берете энтропию и какой алгоритм генерации используете. Сноуден очень интересно рассказывал про «случайные» ключи шифрования.
В природе существует абсолютно стойкий шифр — шифр Вернама (однаразовый блокнот) брут-форс по нему невозможен и это научно доказано.
НО применяя один и тот же ключ более чем к одному открытому тексту, злоумышленник перехватив зашифрованные данные способен к безключевому чтению. Вот такая вот защита от брут-форса…
Поэтому не стоит говорить о том, чего нет в законе. Есть только про установление личности в части биометрических ПДн но это не то.
К слову говоря идентификация была в первых редакциях 152-ФЗ, но еще раз подчеркну, сейчас ее нет.
Определение ПДн в законе МЕГА КРИВОЕ и под него можно подвести что угодно. Я не хочу его защищать, но оперировать можно только тем, что написано в законе ну или найти разъяснения высших судов.
Никто другой, кроме судов, включая Роскомнадзор толковать законодательство не имеет право…
А про суды общей юрисдикции можно сказать, что в России не прецедентное право, и по одинаковым ситуациям могут быть вынесены диаметрально противоположные решения. Выигрывает тот, чей адвокат / прокурор лучше умеют говорить.
Из политики конфиденциальности по ссылке
1.1. Сервис собирает, получает доступ и использует в определенных Политикой целях техническую и иную информацию, связанную с Пользователем.
ст. 3 152-ФЗ «О перс. данных»
1) персональные данные — любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных);
Вывод, если пользователь физ. лицо, сервис обрабатывает перс. данные.
Пугают собственные алгоритмические решения. В подавляющем большинстве случаев подобные решения гораздо хуже стандартных с точки зрения безопасности. Это общеизвестное мнение доказанное практикой и неоднократно озвученное и доказанное метрами в криптографии, такими как Б. Шнаеер, да и отчетами pentest-ров. Надеюсь что у вам не так. Можно узнать чем конкретно вы оказались довольны?
ECB — алгоритм использования блочного шифра, допускающий применение при передаче данных размером не больше размера блока шифра. На практике применяется довольно редко и указан в запросе для того чтобы было понятно о чем спрашиваю.
CBC — применяется довольно широко, в том числе браузерами для TLS соединения. Американская налоговая FATCA принимает отчеты зашифрованные с использование данного режима шифрования
CTR — тоже широко используемый режим, позволяющий использовать блочный шифр как потоковый
Указанные режимы использования блочных шифров приведены в самом последнем госте по криптографии — ГОСТ 34.13-2015. Поэтому утверждать про отсутствие нормальной защиты… ну вы поняли :)
А как они тогда распространяются / согласовываются?
Поясню на примере. Указанная вами схема криптографической защиты с применением блочных симметричного шифра будет похожа на передачу файла зашифрованного с помощью архиватора, так называемый архив на пароле.
Например, я хочу послать файл вам, придумал случайный ключ (пароль), зашифровал файл и отправил его вам по эл. почте. Но как вы его расшифруете? Вам каким-то образом нужно будет узнать ключ (пароль)
Это и есть то о чем я спрашиваю.
Режимы использования блочных шифров, механизмы согласования ключей обычно являются частями комплексных протоколов прикладного уровня, таких как например IPSec, OpenVPN, TLS и др. Данные протоколы проанализированы вдоль и поперек, что позволяет сделать суждение об их безопасности.
В тоже время закрытые разработки подобной уверенности не дают.
Можете ли вы опубликовать полную схему использования криптографической защиты?
P.S. Одно из древнейших правил криптографии гласит, что безопасность криптосистемы должна базироваться на конфиденциальности ключей нежели применяемых алгоритмов.
Если мы говорим про AES, то это симметричный криптоалгоритм, значит закрытый ключ должен быть распространен по всем узлам участвующим в обмене.
Соответственно вопросы:
1. Как устанавливаются/меняются ключи шифрования на узлах?
2. Какой алгоритм использования блочного шифра применяется ECB/CBC/CTR ...?
3. Какая длина ключа 128/192/256?
Ремарка, по поводу атак повторного использования на CRL.
УЦ выпускает CRL с периодичностью указанной у него в Регламенте, например раз в день.
Клиентский софт, должен загружать к себе CRL тоже с такой же периодичностью.
УЦ может выпустить CRL раньше срока например в середине дня, но клиентский софт его забирать в середине дня не будет, если явно не пнуть.
Когда подойдет время следующего обновления CRL, клиентский софт сам полезет на УЦ за новым CRL.
MITM подсунуть старый CRL (повторное использование) не сможет, поскольку у старого CRL протухнет дата (Next update), а подделать CRL нельзя так как он подписан УЦ.
Таким образом единственным случаем когда возможна атака повторного использования, это когда клиентский софт внепланово лезет за CRL, например проверяет его при каждом запросе, но проверка сертификатов по CRL не предназначена для online режима, как вы это обозначили раньше.
И еще. Проблема всей технологии PKI в том, что каждый интерпретирует/реализовывает ее по разному, а в некоторых случаях некоторые механизмы не реализовываются (не настраиваются админами) вовсе.
Но для того, чтобы какие-либо требования работали, в том числе данная политика, нужен контроль их выполнения.
Как вы видите лучшую практику организации подобного контроля для небольших компаний, где есть 1-2 разработчика ПО и например 1 ИБист?
«Если будет потерянны все знания из физики, но будет возможность сохранить только одну теорию. что бы вы сохранили?» Ответ был — «Молекулярно-кинетическую теорию газов».
Интересно, какая информация считается важной в данном случае?
Смогут ли люди, например четвертое или пятое поколение выживших после апокалипсиса воспользоваться этой информацией? Если вспомнить историю, то например аборигены (или другие дикари) не умели смотреть фотографии.
И еще, послание инопланетянам на Вояджере было на золотой пластине, может от пленок лучше уйти к золоту?
Если только некий id, тогда непонятно причем тут ограничения на 4кб в куку, если же в сессии присутствует состояние полное состояние клиента, то для того чтобы его нехранить на сервере его надо шифровать и оно должно шифроваться на клиенте.
В статье схемы взаимодействия не хватает.
1. HMAC — это не электронная подпись. Поскольку строится на базе симметричного ключа и соответственно может быть подделана одной стороной без возможности это опровергнуть другой стороной. Классическая ЭП на ассиметричной криптографии этого не допускает, поскольку ЭП строится с помощью закрытого ключа который есть только у подписывающей стороны.
2. В приведенных вами исходниках ключ шифрования вшит в код, а с учетом того, то шифрование должно осуществляться на стороне клиента этот ключ может быть перехвачен третьей стороной и после чего данные будут подделаны.
Пример. Вася подключается в Web-клиенту Банка. К нему грузятся скрипты, содержащие ключ шифрования.
Вася отключается, но ключ у него есть. Вася знает что у Зины на счету много денег. Он от имени Зины строит сессию (ему даже авторизовываться не надо) и совершает перевод.
3. Вы скорее всего скажите, что сессия будет защищена TLS. Но раз так, тогда смысла в доп. шифровании нет.
Для исправления ситуации необходимо как минимум для каждой сессии получать рандомный ключ шифрования. Но даже это не защитит от атак повтором. Поэтому нужно капать в сторону использования ассиметричной крипты.