Комментарии 49
Если с ПК более-менее понятно: LInux + LUKS разделы, то со смартфонами и мессенджерами, сливающими данные в гуглдрайв не очень. Если чистый андроид уязвим к взлому, то получается, что телефон — очень слабое звено?
На телефоне всё тоже самое в принципе что и с ноутом. Если у тебя хороший пароль (не пин код или ключ) и полное шифрование диска. И ты успел выключить устройство, то взломать это — брутфорс пароля. А если устройство не выключено, то с ноутом тоже начинаются сложности в духе подключиться к pci или вообще сделать колдбут и вытащить ключ шифрования из оперативной памяти.
Ну и облачные решения тоже мало отличаются от десктопа. На телефоне тоже можно не пользоваться облаками и не хранить данные неизвестно где.
Ну и облачные решения тоже мало отличаются от десктопа. На телефоне тоже можно не пользоваться облаками и не хранить данные неизвестно где.
*лозунг* Сиди в мессенджерах только с ПК, терпи до дома!
А причина подобного банальна: пользователям просто неудобно вводить кучу паролей и заморачиваться с безопасностью. Пользователю удобно, когда при смене телефона он один раз вводит данные от аккаунта, после чего все данные подгружаются автоматически. Значит, все данные будут храниться не локально, а в облаке. Ну а ключи шифрования данных тоже не будут ему подвластны.
Интересно, каким образом эти комплексы ломают смартфоны, имеющие сейчас полное шифрование памяти по-умолчанию? Насколько я помню — основа взлома этими ящиками есть банальный брут ключа, который сработает только на примитивные цифровые пин-коды. Сделайте себе сложный мультисимвольный не словарный пароль хотя бы на 10 знаков и спите спокойно.
VeraCrypt контейнеры с надежными паролями. Можно создавать как файл-контейнер (его можно потом хоть по е-мейлу отправить), так и целый раздел жесткого диска использовать. После подключение контейнера через VeraCrypt с ним любой софт работает как с обычным логическим диском, можно с него портабельный софт запускать.
Но это решение для компа (кроссплатформенное), под мобильные его нет.
Но это решение для компа (кроссплатформенное), под мобильные его нет.
Спасибо за информацию, Александр, будем иметь в виду.
;) xD
;) xD
Пользователям поставил VeraCrypt. Хранили там файлы Word и Excel. Все было хорошо, внезапно разрушилась файловая структура виртуального логического диска (если я правильно употребил термин). Вместо файлов — куча папок с мусорными нечитаемыми названиями, внутри какая-то невнятица. Это не работа вируса, это именно сбой файловой системы. Восстановить ничего не удалось. Данные восстановили 2-х месячной давности со старой флешки с помощью R-Studio (они уже были удалены оттуда).
Видел подобный глюк лет 20 назад у популярного тогда BestCrypt.
Так что то… такое.
Видел подобный глюк лет 20 назад у популярного тогда BestCrypt.
Так что то… такое.
Сисадмины делятся на 2 группы: те, кто ещё не делает бэкапы, и те, кто уже делает.
надо делать резервную копию Заголовка тома, на всякий случай.
случайно при переустановке винды форматнул диск зашифрованный truecrypt
наковырял тут на храбре статью о выколупывании заголовка тома, нашел, восстановил. бледный пол дня ходил, теперь копию заголовка делаю сразу.
других сбоев за десять лет работы не припомню, даже с нештатными перезагрузками все данные на месте.
случайно при переустановке винды форматнул диск зашифрованный truecrypt
наковырял тут на храбре статью о выколупывании заголовка тома, нашел, восстановил. бледный пол дня ходил, теперь копию заголовка делаю сразу.
других сбоев за десять лет работы не припомню, даже с нештатными перезагрузками все данные на месте.
А можете подробнее рассказать: как ее сделать, и как ей пользоваться при сбое?
Создать в меню «Сервис» есть пункт «Создать резервную копию заголовка тома».
Я восстанавливал после удаления разделов(форматирования) вот по этой статье
Вот еще какие-то эксперименты с восстановлением зашифрованного системного диска.
Я восстанавливал после удаления разделов(форматирования) вот по этой статье
Вот еще какие-то эксперименты с восстановлением зашифрованного системного диска.
а если SSD?
На ПК работаю с VeraCrypt. Надеюсь защищен.
Ссылка ведет на «Подарок от Мегафона или как на наших сайтах крутится чужая реклама — форум об интернет-маркетинге».
Прошу прощения, видимо, неправильно вставил ссылку.
Продублирую текстом:
Пользователям поставил VeraCrypt. Хранили там файлы Word и Excel.
Все было хорошо, внезапно разрушилась файловая структура виртуального логического диска (если я правильно употребил термин).
Вместо файлов — куча папок с мусорными нечитаемыми названиями, внутри какая-то невнятица. Это не работа вируса, это именно сбой файловой системы.
Восстановить ничего не удалось. Данные восстановили 2-х месячной давности со старой флешки с помощью R-Studio (они уже были удалены оттуда).
Собственно, вот об этом и хотел предупредить.
encfs есть реализация для macos, Linux и Android. Возможно есть и для win. Так же создаём раздел на любом облачном диске, после чего подключаем на всех своих устройствах.
Хорошие статьи про возможности взлома iPhone и Android были в «Хакере» за сентябрь 2018 и за февраль 2019. Насчёт того, что «программно-аппаратный комплекс от Cellebrite позволяет взломать все модели iPhone и Android» – не совсем правда. Зависит от того, насколько старый телефон и насколько сам владелец позаботился о защите.
На любое шифрование найдется терморектальный криптоанализ. Так что в особых случаях только физическое же и уничтожение.
На эту тему мы как раз готовим новую статью.
Есть информация А зашифрованная ключом В. Результатом является С.
Вопрос: можно ли (разумными методами в разумные сроки) сформировать такой ключ В2, который, будучи применён для расшифровки С, позволит получить некоторую осмысленную информацию А2 — имеющую при этом мало общего с А?
То есть, у Вас ДВА ключа: один настоящий, другой фальшивый. Фальшивый, тем не менее, срабатывает вполне корректно — только вот с совершенно иным результатом.
Насколько я понимаю, если не накладывать ограничений на длину ключей, задача вполне решаема. Можно сколько угодно «вариантов расшифровки» сделать — только вот практический смысл при таком подходе теряется. А если таки наложить, удерживая длину в разумных пределах?
Вопрос: можно ли (разумными методами в разумные сроки) сформировать такой ключ В2, который, будучи применён для расшифровки С, позволит получить некоторую осмысленную информацию А2 — имеющую при этом мало общего с А?
То есть, у Вас ДВА ключа: один настоящий, другой фальшивый. Фальшивый, тем не менее, срабатывает вполне корректно — только вот с совершенно иным результатом.
Насколько я понимаю, если не накладывать ограничений на длину ключей, задача вполне решаема. Можно сколько угодно «вариантов расшифровки» сделать — только вот практический смысл при таком подходе теряется. А если таки наложить, удерживая длину в разумных пределах?
Гаммирование (xor) с очень длинным ключом.
Тогда A XOR B = C, а C XOR A2 = B2.
Тогда A XOR B = C, а C XOR A2 = B2.
Ну да, это банальное решение, «в лоб». Но тогда А и В должны быть, как минимум, сравнимой длины. То есть, большой файл придётся шифровать большим файлом, как-то так. Вопрос в том, насколько можно снизить длину ключа при решении таковой задачи (и как это сделать).
Например, в качестве большого файла берется один и тот же фильм. Скачанный обоими участниками переписки с одного и того же рутрекера...)
Каждое последующее сообщение копируется последовательно или по какому-то алгоритму выбираемым блоком байт из него. Энтропия у видеофайлов максимальна, размер большой…
Каждое последующее сообщение копируется последовательно или по какому-то алгоритму выбираемым блоком байт из него. Энтропия у видеофайлов максимальна, размер большой…
Это хороший способ, близкий к «бесконечному шифроблокноту». Но, всё же, проблему «равноправных ключей» он не решает (или я чего-то не понял).
Попробую сформулировать иначе. Итак, имеем следующее:
1) Сообщение А1 в зашифрованном виде даёт С.
2) Сообщение А2 — существенно отличное от А1, но имеющее такую же или сравнимую длину — тоже в зашифрованном виде даёт С.
Задача: создать алгоритм, способный генерировать ключи В1 и В2 соответственно для первого и второго случая — причём, одинаковой и минимальной при этом длины. Требований к С при этом никаких особых (пока, в первом приближении) не накладывается — с небольшими оговорками, см. ниже.
То есть, когда от Вас требуют расшифровать С — Вы предъявляете ключ В2, воспользовавшись которым можно получить А2. И никто никогда не сможет доказать, что существует В1, применение которого к С даст А1. Зашифрованная информация С не даёт никаких оснований так полагать.
Как я уже упоминал, если ограничений на длину ключей нет, это нет проблема. Грубо говоря, из первого файла всегда можно сделать второй или третий на выбор, оперируя в качестве ключа четвёртым или пятым. Вопрос в том, каков теоретический (ну и практический тоже) предел уменьшения длины ключей в такой задаче.
Попробую сформулировать иначе. Итак, имеем следующее:
1) Сообщение А1 в зашифрованном виде даёт С.
2) Сообщение А2 — существенно отличное от А1, но имеющее такую же или сравнимую длину — тоже в зашифрованном виде даёт С.
Задача: создать алгоритм, способный генерировать ключи В1 и В2 соответственно для первого и второго случая — причём, одинаковой и минимальной при этом длины. Требований к С при этом никаких особых (пока, в первом приближении) не накладывается — с небольшими оговорками, см. ниже.
То есть, когда от Вас требуют расшифровать С — Вы предъявляете ключ В2, воспользовавшись которым можно получить А2. И никто никогда не сможет доказать, что существует В1, применение которого к С даст А1. Зашифрованная информация С не даёт никаких оснований так полагать.
Как я уже упоминал, если ограничений на длину ключей нет, это нет проблема. Грубо говоря, из первого файла всегда можно сделать второй или третий на выбор, оперируя в качестве ключа четвёртым или пятым. Вопрос в том, каков теоретический (ну и практический тоже) предел уменьшения длины ключей в такой задаче.
всё уже давно придумано:
1) по основному ключу монтируется диск с вашими данными
2) если у вас терморектально достали второй ключ — монтируется безобидный раздел с котиками.
по размерам монтируемого диска и размерам криптоконтейнера подделку не обнаружить.
ответ submagic ниже:
надо ссылки не на абстракции в вики постить, а ссыку на доку:
www.veracrypt.fr/en/Hidden%20Volume.html
1) по основному ключу монтируется диск с вашими данными
2) если у вас терморектально достали второй ключ — монтируется безобидный раздел с котиками.
по размерам монтируемого диска и размерам криптоконтейнера подделку не обнаружить.
ответ submagic ниже:
надо ссылки не на абстракции в вики постить, а ссыку на доку:
www.veracrypt.fr/en/Hidden%20Volume.html
Это известная технология. Только вот:
по размерам монтируемого диска и размерам криптоконтейнера подделку не обнаружить.спорное утверждение, увы.
Что-то подобное я когда-то слышал. В одном контейнере хранились и нормальные данные и фейковые. Один пароль подключал нормальный диск, а второй — фейковый и при этом тёр (вроде как) нормальный.
Не так давно эту задачу решили, пока правда только «академики».
НЛО прилетело и опубликовало эту надпись здесь
Переписка в Whаtsарр и Vibеr уже давно читается её умеют читать без физического доступа. На счёт Tеlеgrаm не спрашивал…
Разве нас это ещё удивляет?
Разве нас это ещё удивляет?
Локальное хранилище сообщений в Telegram Desktop всегда было зашифрованным, и там не «база данных» это раз, два, что «исследование» того студента фундаментально bullshit.
Повесить плакат «Не болтай!», раз. И не стоит мышам ходить туда, где по словам кота лежит сыр.
Ну, а допустим, такой способ. Немного радикальный, но все же. Скажем, имеем Android-устройство. Не пользуемся проприетарными сервисами, только FOSS (Free and Open Source Software). Это лишь для удаленной защиты. Для защиты физической придется жертвовать больше. Скажем, подпортить Recovery-раздел, чтобы его невозможно было запустить, получить на устройстве Root-права, и установить путем Xposed ADB-паранойю. Далее, выпаять (каким-нибудь чудным образом) USB-разъем с платы. Вернее, оставить в нем лишь возможность зарядки, но не передачи данных. Включить встроенное шифрование.
Критикуйте. Интересно.
Критикуйте. Интересно.
В порядке бреда: можно также купить на E-Bay старенький Blackberry. Говорят, лучшая платформа была в плане защиты данных. Правда или нет, не знаю.
У них там даже весьма особенная ОС стояла. Вообще, лично мне платформа казалось удачной и перспективной. Очень жалею, что это всё не получило развития.
Если рекавери запорото, но есть возможность запустить fastboot, то не проблема подгрузить рабочее рекавери, так что смысла портить рекавери нет, себе же неудобнее будет (обновления ОС планируете ставить ведь?)
+ система самоуничтожения всего и вся при некоторых предсказуемых и характерных попытках получить доступ. Лучше две независимые системы (и неочевидные притом).
Вопрос защиты своих данных очень прост и сложен одновременно.
Проблема заключается в том, что людям, которым это шифрования действительно нужно, НИ ХРЕНА В ЭТОМ НЕ ПОМНИАЮТ!!!
А люди, которые реально в шифровании понимают, ИМ ЭТО НА ХРЕН НЕ НУЖНО!!!
В итоге у тех, кто этим вопросом озабочен ходит куча легенд и мифов типа «взламывается всё» и «я купил какой-то смартфон с выпеленным микрофоном».
На само деле всё просто. Данные могут быть спецслужбами двумя способами:
1. Из различных публичных сервисов (мессенджеры, файлохранилища, почтовые сервисы, т.д.).
2. При физическом доступе к устройству.
С 1-м пунктом всё просто. Если хочешь быть уверен — заводи свою инфраструктуру. Мессенджеры и файлообменники на своих серверах. В первую очередь конечно это актуально для корпоративных пользователей. Мало кто это готов делать, так как это хлопотно и опять же сложно в силу того, что потребитель в этом ничего не понимает, а реально понимающих в этом людей надо ещё уметь найти.
С 2-м пунктом тоже не так сложно. Только опен сорс только открытый код. Линукс имеет всё, что нужно. Андроид = линукс. Но там не так просто. Раньше было просто. Если у тебя был рут, то ты мог в терминале ввести нужные команды и поставить на шифрование файловой системы надёжный пароль, оставив пин из 5-ти цифр.
С 6-ого андроида, если не путаю, всё стало сложно. Этот фокус не работает. Если есть квалификация, то ты можешь найти в крифтфс тех же самсунгов тупо ошибки. И тупо параметр «чейнджпассворд» выдаёт ошибку. «Чекпассворд» работает, а ченддж нет… Прикольно. При этом как бы в АОСП всё как и было раньше. Но в реальных телефонах АОСП не стоит… То есть как бы всё вроде бы открыто и прозрачно, а по факту если хочешь себе «честное» шифрование в Андроид — программируй сам. Прикльно.
В общем не всё так сложно, но и не всё так просто.
Ещё раз повторюсь. Проблема не в том, что зашифровать свои данные не возможно. Проблема в том, что все решения имеющие статус хорошего годного популярного «ПРОДУКТА» как-то так получается, что зашифрованы ровно на столько, чтобы гопники не могли, а ФСБ (ФБР, МИ6… т.д. и т.п.) могли… Хочешь красиво и удобно — мирись с тем, что не ты один читаешь свои сообщения. Хочешь надёжно — заморачивайся.
Проблема заключается в том, что людям, которым это шифрования действительно нужно, НИ ХРЕНА В ЭТОМ НЕ ПОМНИАЮТ!!!
А люди, которые реально в шифровании понимают, ИМ ЭТО НА ХРЕН НЕ НУЖНО!!!
В итоге у тех, кто этим вопросом озабочен ходит куча легенд и мифов типа «взламывается всё» и «я купил какой-то смартфон с выпеленным микрофоном».
На само деле всё просто. Данные могут быть спецслужбами двумя способами:
1. Из различных публичных сервисов (мессенджеры, файлохранилища, почтовые сервисы, т.д.).
2. При физическом доступе к устройству.
С 1-м пунктом всё просто. Если хочешь быть уверен — заводи свою инфраструктуру. Мессенджеры и файлообменники на своих серверах. В первую очередь конечно это актуально для корпоративных пользователей. Мало кто это готов делать, так как это хлопотно и опять же сложно в силу того, что потребитель в этом ничего не понимает, а реально понимающих в этом людей надо ещё уметь найти.
С 2-м пунктом тоже не так сложно. Только опен сорс только открытый код. Линукс имеет всё, что нужно. Андроид = линукс. Но там не так просто. Раньше было просто. Если у тебя был рут, то ты мог в терминале ввести нужные команды и поставить на шифрование файловой системы надёжный пароль, оставив пин из 5-ти цифр.
С 6-ого андроида, если не путаю, всё стало сложно. Этот фокус не работает. Если есть квалификация, то ты можешь найти в крифтфс тех же самсунгов тупо ошибки. И тупо параметр «чейнджпассворд» выдаёт ошибку. «Чекпассворд» работает, а ченддж нет… Прикольно. При этом как бы в АОСП всё как и было раньше. Но в реальных телефонах АОСП не стоит… То есть как бы всё вроде бы открыто и прозрачно, а по факту если хочешь себе «честное» шифрование в Андроид — программируй сам. Прикльно.
В общем не всё так сложно, но и не всё так просто.
Ещё раз повторюсь. Проблема не в том, что зашифровать свои данные не возможно. Проблема в том, что все решения имеющие статус хорошего годного популярного «ПРОДУКТА» как-то так получается, что зашифрованы ровно на столько, чтобы гопники не могли, а ФСБ (ФБР, МИ6… т.д. и т.п.) могли… Хочешь красиво и удобно — мирись с тем, что не ты один читаешь свои сообщения. Хочешь надёжно — заморачивайся.
Есть и третий пункт. Самое крутое и правильно шифрование теряет смысл, если всё грамотно сделано только на одной стороне. Если вторая сторона косячит или хотя бы может накосячить с высокой вероятностью, тады ой :-(
Есть и такой пункт. Но тут надо понимать, что «безопасность» должна быть сбалансирована с удобством. Нельзя доходить до маразма. Уровень безопасности надо сопоставлять с уровнем угроз.
Вообще конечно в идеале все конфиденциальные данные должны быть «заперты» внутри некой контролируемой тобой (собственником данных) инфораструктуры, включающей как серверную часть, так и клиентскую.
Есть ещё и 4-й пункт, который самый сложный и по сути не решен в принципе нигде и никем полностью. Это вопрос связанный с контролем привилегированного доступа. Более того, на этот пункт как правило все кладут с прибором. Можно тысячу раз зашифровать все свои сервера и обложиться впнами, но если ключи от всех твоих данных знает твой айтишник, которому ты платшь 80 тысяч рублей, то всё это идёт лесом. Айтишник не имеет достаточной заинтересованности в хранении данных и в определённых случаях «отдаст» тебя кому надо с потрохами. Этот пункт на самом деле самый сложный.
Технически он решений не имеет, а «городить» организационные мероприятия, позволяющие тебе контролировать свои данные самому, а айтишнику администрировать инфраструктуру, никто не умеет, не может, да и не хочет часто.
Вообще конечно в идеале все конфиденциальные данные должны быть «заперты» внутри некой контролируемой тобой (собственником данных) инфораструктуры, включающей как серверную часть, так и клиентскую.
Есть ещё и 4-й пункт, который самый сложный и по сути не решен в принципе нигде и никем полностью. Это вопрос связанный с контролем привилегированного доступа. Более того, на этот пункт как правило все кладут с прибором. Можно тысячу раз зашифровать все свои сервера и обложиться впнами, но если ключи от всех твоих данных знает твой айтишник, которому ты платшь 80 тысяч рублей, то всё это идёт лесом. Айтишник не имеет достаточной заинтересованности в хранении данных и в определённых случаях «отдаст» тебя кому надо с потрохами. Этот пункт на самом деле самый сложный.
Технически он решений не имеет, а «городить» организационные мероприятия, позволяющие тебе контролировать свои данные самому, а айтишнику администрировать инфраструктуру, никто не умеет, не может, да и не хочет часто.
Хотел плюсануть сообщение, но по правилам мне еще рановато поэтому напишу здесь — Самый лучший комент! В первом же абзаце раскрыта вся суть этой болталогии: «Проблема заключается в том, что людям, которым это шифрования действительно нужно, НИ ХРЕНА В ЭТОМ НЕ ПОМНИАЮТ!!! А люди, которые реально в шифровании понимают, ИМ ЭТО НА ХРЕН НЕ НУЖНО!!! Читаю и думаю про себя я на Хабре или на собрании игиловцев? Мой скромный совет всем параноикам — не лезьте в политику и будет вам шастье!
Еще хотел бы написать непосредственно автору статьи. По поводу этой части я уже выше написал и добавить мне вобщем нечего. Но вот по поводу первой части очень хотелось бы задать автору пару вопросов. К сожалению комментировать ту часть мне еще нельзя по статусу, так что спрошу здесь. Во-первых через всю статью «красной чертой» проходит мысль автора об ужасных, коррумпированных, жестких российских спецслужбах, которые спят и видят как бы арестовать очередного пользователя «телеграм». А поэтому мой первый вопрос — сколько хакеров (т.е. в общем компьютерных спецов) арестовали российские спецслужбы за последние пару лет? И сразу в догоночку второй вопрос — сколько тех же персонажей за эту же пару лет арестовали американские спецслужбы??? А после непродолжительного анализа, давайте подумаем — так чьих спецслужб надо бояться больше? Я уже не говорю про длительность сроков заключения, которые получают хакеры судимые американскими судами в сравнении с российскими. Так что ИМХО — статья получилась слишком предвзятой и однобокой.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Когда шифрование не поможет: рассказываем про физический доступ к устройству