Pull to refresh

Comments 71

«Сверхзащищенный мессенджер Signal тайно сохраняет историю и ключи шифрования открытым текстом»

Прочитав заголовок статьи подумал о том, что сигнал тайно сохраняет сообщения и ключи открытым текстом на удаленных серверах, но похоже здесь речь о другом. Получив локальный доступ к устройству можно много чего сделать
Ох уж это мастерство загаловка. ладно хоть обошлось без «ШОК! Signal тайно стал делать это...»
А что не так с заголовком? Сигнал никак не предупреждает о расшифровке. Для пользователей не прочитавших эту статью, это будет очень «приятным» сюрпризом. Особенно если учесть, что не каждый станет пользоваться Signal просто потому, что захотелось. Наверняка были веские причины.
Во-первых, заголовок кликбейтный, ну ладно, щас без этого никто не живет. Во-вторых, signal выбирают из-за его проверенной надежности в плане шифрования данных при передаче и не складировании где-то посередине. В-третьих, signal не для рядовых пользователей, а те, кто в теме всегда оценивют модель угроз при использовании средств общения (ставки высокие). В-четвертых, не видел, чтобы signal утверждал, что он обеспечивает локальное шифрование и надежное хранение (да, есть вещи, о которых нужно думать самому). То, что кто-то себе напридумывал с оверсекурностью сигнала, его личные проблемы. Вот поэтому заголовок со словом «тайно» ничего, кроме кликбейтности не имеет.
Да как угодно, это ничего не меняет, кроме желания хайпа:)
В заголовке написано:
мессенджер Signal тайно сохраняет историю и ключи шифрования
Как есть на самом деле:
Человек, создавший баг в багтрекере, сделал экспорт для обновления с (вероятно, очень старой, с несовместимой базой) версии программы на версию новее, 3 дня назад. Авторы пока не ответили на этот баг. Кроме того, пишут:
Messages and attachments are not meaningfully encrypted on-disk in the latest Signal Desktop even without exporting/upgrading
Последняя фраза дополняется другой фразой того же человека:
i'm not a signal dev and do not intend to support or refute their choices, just noting an observation.


Что значит, я тут мимокрокодил и заметил, что оно не шифруется, но я не разработчик и не знаю зрада это чи перемога.

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

Сохраняет ли Signal историю и ключи шифрования тайно? Вероятно, нет. Заголовок не соответствует действительности.
способы локального хранения не играют значительной роли, и типичные реализации шифрования с использованием пароля на запуск программы могут только замедлить расшифровку данных, но не предотвратить её.
Почему, если пароль использовался бы для шифрования файлов? Или речь о том, что и пароль можно подобрать за конечное время?

Можно считать что Дуров был прав, или это не тот случай?


Ну я бы сказал, что это предсказание из разряда «или халиф, или ишак, или я». Всё-таки сейчас пять лет — это очень много. =)
Тем более что отличить хороший бэкдор от обычной ошибки/непроработанности непросто.
У них там бекдор.

— создатель централизованного мессенджера с проприетарным шифрованием, про децентрализованный опенсорсный мессенджер
Сигнал централизованный, как я понимаю. Плюс, привязан к номерам телефонов (читай: к личности и местоположению).
Точно, извиняюсь, перепутал с Matrix.
Это только на 1/3 уменьшает иронию ситуации — вопросы к открытости кода (https://github.com/signalapp/Signal-Server vs код серверов тг закрыт) и проверенности криптографии остаются.
И Телеграм также без подтверждения номера не работает.
проприетарным шифрованием
При том, точно так же опенсорсным.
Давно математики доказали, что общедоступные алгоритмы шифрования надежнее, чем самописные. Еще вопрос, кто первым профейлится, AES с бэкдором или Дуров со своей самопиской
Если бэкдор есть, то значит его уже используют.
Если бэкдор есть в алгоритме, используемом правительством США, то потенциальные противники могут его также эксплуатировать. Не слишком умно как-то.
А вы не думаете, что у них для особо важных дел есть своя версия алгоритма или рекомендации как избежать действия бэкдора? Это ж банально горшок с медом. Примерно как у нас есть ГОСТ 28147-89, у которого есть гражданский вариант, и был секретный военный вариант, немного модернизированный.
Наличие сноуденов всяких показывает, что не бывает ничего уж слишком секретного. Кроме того, дырявость систем в США показывает, что это далеко не главная угроза. А последствия от раскрытия подобного бэкдора были бы катастрофическими. Мало того, что куча правительственных систем остались бы без защиты, так и еще и подорвано доверие к системе международной стандартизации алгоритмов шифрования.
Ваша гипотеза мою гипотезу опровергнуть не может. Вероятность остается.
Весь смысл «безопасных мессенджеров» строго в невозможности доступа третих лиц к переписке с использованием незащищенных каналов связи.

Если у вас есть есть доступ к железу на котором крутится что-то «безопасное», то оно в любом случае не может считаться «безопасным». Как бы не новость.

p.s. Но, конечно, косяк :)
Уязвимость, но при наличии доступа на локальное устройство.

Занятно, что именно сегодня пакет Signal потребовал обновиться.
У моего знакомого пропали скромные сбережения в крипте, из-за того, что было слабое обратимое шифрование файла данных локального кошелька. Кроме него к компу доступа никто не имел. Всего-лишь нужно человеку интересующему забросить на комп пейлоад вредоносный каким-то способом.
Сбережения пропали из-за знакомого, а не из-за слабого шифрования — с тем же успехом троян мог перехватить пароль при вводе. Полумеры в безопасности недопустимы и если пользователь не предусматривает все векторы атак, то виноват в этом только он сам.
Кошелек лежал не тронутым несколько месяцев, никакие пароли он не вводил, перехватить было нельзя. Пользователь не может знать всего. А в кошельке была уязвимость, которую разработчики игнорировали полгода.

Я это сказал к тому, что оправдание «при наличии доступа на локальное устройство» в реальности очень слабая отговорка.
Вы перекладываете ответственность пользователя на софт в то время, когда софт отлично выполняет свою задачу. А если разработчик сделает сильное шифрование, но не будет требовать минимум 14-значный пароль в разном регистре с цифрами и спецсимволами, и пользователь введёт «12345», то виноват снова разработчик?

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

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

По криптокошельку вот ссылка на историю vxlabs.com/2017/06/10/extracting-the-jaxx-12-word-wallet-backup-phrase Там ровно такая же история, там создатели начали оправдываться и говорить, что «наш кошелек вовсе не то, что вы могли подумать», но только после того, как куча людей уже попали на бабки. А нужно было предупреждать всех при первом запуске программы.
Полагаю, выносить суждение можно, только когда все данные перед глазами.

В любом случае, если на систему занесли вредонос, боржом пить поздно. В такой ситуации нужен уже следующий пункт инструкции: как минимизировать ущерб, если вас всё-таки pwn'ули.
Не хватает пункта опроса «Ничего не поменялось. Использую как компромиссное временное решение»
Где вариант «Не пользуюсь» (Давно про него знаю и не пользуюсь)?
Ждём новость «шок — системы по умолчанию не шифруют данные, наглые производители бездействуют».
UFO just landed and posted this here
Приложение могло бы хранить ключи в TPM или его аналогах (secure enclave).

Или на токенах/смарткартах PKCS#11!

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


Вообще, защита локальных данных — это довольно скользкая тема. От мессенджера я лично ожидаю исключительно защиты данных при передаче по сети (в т.ч. от разработчиков мессенджера, чтобы исключить хранение моей переписки у них на серверах). От менеджера паролей, gnupg, ssh, криптокошелька — надёжной защиты данных хранящихся у меня на винте и хотя бы формальных попыток защитить пароли/ключи находящиеся в памяти этих приложений. Шифрование логов мессенджера у меня на винте для меня задача не очевидная — вопрос от каких именно рисков это шифрование должно помогать? При ответе на этот вопрос нередко выясняется, что основной риск — это физический доступ к компу посторонних, но для защиты от этого самое адекватное решение это шифрование диска целиком.


Единственное, с чем я согласен в статье — то, что вложения в самоуничтожающиеся сообщения не удалялись — это фейл.

А если tpm нет? К тому же это все равно security through obscurity — если ключ в какой-то момент находится в памяти его можно достать точно так же как например кейлоггер может записать мастер пароль. Единственное для чего делают локальное шифрование — это защита от белок-паникеров "Аааа!!! Не зашифровано!!! Опасность! Бэкдор! Ужас!"

UFO just landed and posted this here
А каким пользоваться тогда? Такое впечатление создается, что несмотря на некоторое «изобилие» придется писать свой, ага, 15-ый как на карикатуре xkcd. Большинство имеющихся, увы, либо смотрит на безопасность сквозь пальцы, либо допускает сомнительные решения, которые тут же становятся векторами атаки.
Да можно и Сигналом наверное пользоваться, просто теперь нужны дополнительные меры безопасности.
Карандаш и бумага. После прочтения сжечь.
«Перед прочтением сжечь!» Классика же =)

OMEMO если используется Jabber. OTR для остальных протоколов. Вероятно, Matrix тоже подходит. Для совсем гиков можно ещё Keybase. Шифрование в популярных мессенджерах вроде вотсапа или телеграм у меня лично вызывает большие сомнения, из таких разве что Signal выглядит приемлемым на крайний случай, но лучше не рисковать и ограничиться OMEMO и OTR.

Не забываем, что OMEMO сделан на базе протокола Signal

Ничего не имею против протокола Signal, но привязка самого клиента к номеру телефона, самому телефону, контактам — это на любителя. Я предпочитаю мессенджеры, которым не нужно сообщать номер телефона.

Вы имеете в виду Double Ratchet Algorithm, а не протокол Signal (который описывает сетевое взаимодействие).
Хе-хе. Вы не представляете сколько ПРОМЫШЛЕННО эксплуатируемых систем хранит ключи в открытом виде. Обычная реакция техподдержки вендора на обращение с вопросом «как зашифровать» отвечает «что предполагается что доступ к серверу есть только у администратора».
Ну всегда будет проблема хранения ключа где то. И доступу к этому носителю.
на обращение с вопросом «как зашифровать»
Проблема же не в том, как зашифровать. Проблема в том, как расшифровать так, чтобы больше никто не мог расшифровать.
Ну и в общем-то правильно. Если по вашим серверам с ПРОМЫШЛЕННО эксплуатируемыми системами шляется кто угодно с правами админа, то это не проблема разработчиков приклада. С такими правами можно и отладчик запустить, и память сдампить, и диск целиком скопировать через драйвер. Шифрование добавит много геморроя и примерно 0 защиты.
Вот точка зрения обычной ТП (техподдержки). У кого как минимум есть доступ: администратор непосредственно той ИС, которая установлена на сервере, железячники, бэкап… в общем много людей у которых доступ к диску вроде как должен быть, но видеть что на нем — не должен
От железячников придумано шифрование диска целиком силами ОС. Бэкапы ну не ручками же делаются, а один раз настроенным софтом из-под учётной записи ОС, при этом к самим бэкапам имеют доступ полтора админа под присмотром офицера СБ. Админ локалхоста после установки ОСи запрещается, всё управление-обновление производится силами тех же полутора доверенных админов.
PS. Я действительно не понимаю, как может помочь шифрование внутри прикладного софта. Вариант а) пароль записан тут же рядом на диске, или на флешке, или в usb-ключе, т.е. человек с физическим доступом к железу — расшифрует. Вариант б) пароль записан на бумажке. Тогда при каждой перезагрузке сервера, например, из-за пропадавшего питания завести систему может только специально обученный офицер с бумажкой. И пока он по всем серверам не пробежится — система так и будет лежать. Ну ок. Ещё варианты?
А существует ли вообще способ шифровать, но не хранить ключи где-либо? Вариант с постоянным вводом пароля не сильно поможет. Разве что на отдельном защищённом устройстве шифровать, но такое вряд ли будет популярно.
А не удалять временные файлы это конечно фейл. Но где их не бывает?
Я к тому, что это не компрометирует сигнал. Просто его, «оказывается», нужно использовать только на доверенной машине. А как ещё?
UFO just landed and posted this here
Ключ на usb брелке с закрытым для чтения ключом и шифрованием на стороне девайса. Но не отнимает шанса на кражу брелка.
В некоторых аппаратных криптокошельков в расширенном режиме интересная и надежная схема реализована:
1. Основная часть ключа хранится (и происходит шифрование, точнее в случае кошелька формирование цифровых подписей) — на отдельном аппаратном девайсе. И генерируется и хранится она на этом устройстве в неизвлекаемом виде
2. Дополнительная часть ключа («соль») выводится из пароля вводимого пользователем для доступа к кошельку. Эта часть нигде не хранится кроме памяти пользователя. Вводится перед каждым использованием и пересылается на устройство.

В результате взлом компьютера и хищение/перехват вводимого пароля ничего не дают, т.к. основной ключ в отдельном устройстве и на компьютер вообще никогда не передается.
Физическая утеря/кража устройства доступа к защищаемым данным злоумышленникам тоже не даст, т.к. у них не будет доступа ко 2й части ключа хранимой в памяти владельца.

Единственный более-менее реальный вектор атаки — это похищение устройства одновременно вместе с его владельцем и применением к последнему условного терморектального криптоанализа.
В современных компьютерах есть крипточип Trusted Platform Module (TPM), либо выделенным чипом, либо эмулируемый средствами современных процессоров (Intel PTT). Он позволяет выполнять некоторые криптографические операции непосредственно на чипе, не копируя ключ в ОС/RAM.
UFO just landed and posted this here
А ведь это затрагивает куда более глубокую проблему: продукт с открытым исходным кодом и тысячами активных пользователей, существующий более 4 лет, при этом сфокусированный на анонимности и безопасности, и никто так и не удосужился провести аудит кода? Все пользовались, считая что кто-то уж точно все независимо проверил. А ведь со множеством opensource продуктов и модулей может быть аналогичная ситуация.
А проблема ли это вообще? Переписку можно прочитать лишь получив физический или удаленный доступ к ПК. Если нужна защита и на таком уровне — надёжный вариант — TrueCrypt диск с виртуальной машиной. А полагаться на то, что мессенджер будет шифровать или удалять без возможности восстановления локальные данные, — в любом случае не стоило.
Heartbleed уже давно продемонстрировал, что так и есть
Протокол и его реализация проходили аудит кода.

Аааааа! Паника!!! Ssh тайно хранит приватный ключ прямо на диске в незашифрованном виде!

Ещё и при первом коннекте не проверяет подлинность сервера
UFO just landed and posted this here
Ну в случае с ssh хотя бы есть выбор, шифровать ключ пассфразой или нет.
Коллеги, я не пользуюсь десктопными WhatsApp/Signal, но не является ли причиной изложенного в статье поведения то, что они используют end-to-end шифрование, в котором «центром мира» является телефон (который всё время должен быть онлайн)?

А точнее не из-за того ли, что их десктопные «клиенты» — это электрон, который упакован в браузер, который работает в докер-контейнере, который крутится в виртуальной машине?

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

Вот я понимаю люди извращаются как могут
Используйте PGP ключи и хоть mail.ru, хоть бумажной почтой информацию можно отправлять. Ради действительно секурного общения, для шифрования и дешифрования можно использовать отдельный компьютер (неважно с какой ОС), который не нужно подключать к интернету. А все эти криптомессенджеры, торификация трафика и прочее баловство одно.
Sign up to leave a comment.

Articles