Комментарии 88
Тип ПК и операционной системы, на которых они должны работать, к настоящему моменту неизвестны.
Можно было бы хоть readme глянуть:
Supported Operating Systems
Source/Destination Computer
Debian 10
PureOS 9.0
*buntu 19.10
Networked Computer
Tails 4.0
Debian 10
PureOS 9.0
*buntu 19.10
Так и про «без названия» лукавство, написано же — Tinfoil Chat.
Если есть физический доступ — то «уже поздно пить боржоми».
Если бы не было таких уязвимостей, то можно было бы правдоподобно отрицать наличие противозаконной деятельности (ввести пароль, который открыл бы например садомазо-переписку, вместо переписке о… о том, из-за чего к Вам пришли).
Но разумеется лишь в том случае, если Вы верите в исключительно законные методы дознания и в то, что Ваших гостей интересует именно содержание переписки, а не сам факт ее наличия. Если дело дойдет до терморектального криптоанализа, то и Вам уже будет без разницы (материал подвергнутый ТК не пригоден к восстановлению и должен быть утилизирован, для предотвращения токсичного воздействия на специалистов ТК), и правильный пароль с высокой вероятностью добыть удастся.
IOMMU эффективно множит DMA атаки на ноль
Толсто, публикация, как и все остальные в духе лентысру
Самое главное: где взять сплиттер аппаратный?
Еще как взлетит.
Очень много жанров с картиночками когда нужно опасаться, что прикроют прекрасное общение для тихих интеллигентных людей.
Я только одного не понял:
Интерфейс приложения предельно прост и включает окно, разбитое на три области — отправка, получение и командная строка с логом взаимодействия со шлюзом.Где запущено это приложение?
благодарю за первоисточник-там можно хотя бы понять суть сплиттера на диаграмме, а то в текстовом виде не очень понятна главная идея. тем более понятно шикарное название «диод для данных».
Если у Вас предустановленное российское ПО «для улучшения жизни пользователей», то без разницы каким сверхзащищенным мессенджером Вы пользуетесь. Предустановленное ПО само будет посылать буковки с клавиатуры куда надо.
И пруфы есть?
К слову, бывали похожие случаи и не раз. И казалось бы причем тут может быть аудиодрайвер.
Вот теперь точно, когда аналог гитхаба состряпают, оригинал анафеме предадут.
Если будет скомпроментировано то устройство которое выводит данные на экран то может использоваться социальная инженерия для того чтобы пользователь сам ввёл данные которые взломают третье.
В той статье ссылка на блог tor project в котором они предпологают что вычислили следящие узлы и пофиксили баги которые использовались для слежки.
мессенджер без названия(Он называется TFC)
Тип ПК и операционной системы, на которых они должны работать, к настоящему моменту неизвестны.(Список вам привели)
вы еще даете ссылку на tinfoil.io — портал для Nintendo Switch геймеров.
Когда-то на форуме одной защищённой ос прочитал комментарий, что пора бы уже использовать десяток raspberry pi в связке вместо ноутбука, чтобы перестать беспокоиться о дырах в системах виртуализации. Причём десяток RPi оказался дешевле, чем ноут удовлетворяющий минимальным системным требованиям той ос. В общем, пора ждать стартапа с ноутбуком из 4 малин для этого мессенджера.
10 малинок, все с разными ос и софтом от разных производителей, у которых только общий и довольно простой протокол.
Немного напоминает подход 20 летней давности "NetTop" — https://www.zdnet.com/article/nsa-attempting-to-design-crack-proof-computer-5000114035/; https://www.vmware.com/pdf/TechTrendNotes.pdf — переместить "air gap" из реального мира в разделение между несколькими виртуалками.
NetTop will run on top of a more secure distribution of Linux that the NSA has developed and an initial version of which it released in December 2000.
2008 год — https://www.nsa.gov/Portals/70/documents/resources/everyone/digital-media-center/publications/the-next-wave/TNW-17-3.pdf#page=10 (стр 10-20)
Providing multiple virtual machines for a user gave us an opportunity to create multiple single security level environments running simultaneously.… First, we treated SELinux as an embedded OS and prohibited the use of any native user applications. VMware was the only application permitted. Our next step in reducing NetTop’s attack surface, was to configure the system to make the SELinux host unreachable from any network connection.… The combination of SELinux’mandatory access controls, VMware’s isolation capabilities, and NetTop’s tightly controlled architecture have proven effective at blocking attacks.
Вопрос в физической передаче носителя, это не всегда возможно
Кроме явной проблемы с передачей шифроблокнота (какой-нибудь покупатель в даркнете придёт получить, будет весело), есть еще большая проблема Message Authentication. То есть третья сторона может неограниченно вбрасывать мусор и двигать индекс ключа. Так что без защищённой сессии не обойтись.
Можно использовать открытые данные для генерации шифроблокнота.
Не только источники но и как они обработаны. Потом задача шифроблокнота вторым слоем скрыть сигнатуры трафика. Чтоб не понятно было ключь к первому слою уже подобран или ещё перебирать надо.
Ну а если ключи скомпроментированы изначально то нужно будет ещё прогнать кучу данных через генератор шифроблокнота с правильными параметрами.
А для стеганографии уже использовать надо что-то другое.
При генерации блокнота также должен использоваться одноразовый ключь который уже легче безопасно передать.
т.е. передавать открытый индекс, сообщение, хэш индекса с солью
Была такая мысль:
Огромный файл шифроблокнота KEY
(размером KEY_SIZE
, допустим, 1 ГБ), который тем или иным способом передаётся корреспонденту, пусть даже через открытый канал связи.
В качестве ключа берутся два произвольных числа — S
и D
, оба меньше KEY_SIZE
— которые передаются принимающему любым безопасным способом. Это сделать легко: всего несколько десятков бит.
После чего каждый байт сообщения шифруется/дешифруется как MESSAGE_B[i] = MESSAGE_A[i] XOR (KEY[S + D * i])
Один и тот же файл шифроблокнота можно использовать неоднократно. Ведь каждый раз S
и D
разные — а это эквивалентно новому шифроблокноту. Значительный размер шифроблокнота исключает возможность нахождения S
и D
перебором, а использование XOR
сильно затрудняет выяснение, какой же из "дешифрованных" файлов "истинный".
Представте что известен файл шифроблокнота (он передавался открыто), дешифрованное сообщение и алгоритм шифрования. Я думаю на этой основе возможно получить S и D и расшифровать остальные сообщения.
Я предлагаю изначально зашифровать сам файл шифроблокнота на два слоя потоковым шифром (например RC4). Шифруем файл в прямом направлении и в обратном. Далее можно продолжать его шифровать в прямом и обратном направлении и просто делать XOR с сообщением. Ключ нужен будет только для запуска. В дальнейшем сохраняется состояние шифратора для того чтобы продолжать накладывать новые слои.
В этом случае для перебора ключа зная сообщение, исходный файл блокнота и алгоритм прийдётся также шифровать его в два и более слоёв пока не будет найдено совпадение.
Представте что известен файл шифроблокнота (он передавался открыто), дешифрованное сообщение и алгоритм шифрования.
Если противнику уже узвестно всё, то что ему ещё нужно-то?
Я думаю на этой основе возможно получить S и D и расшифровать остальные сообщения.
Эмм, часть про "каждый раз S
и D
разные" от Вас, как мне кажется, ускользнула.
Помните старую хохму про "мне не надо бежать быстрее медведя — мне надо бежать быстрее тебя"? Теоретически, при наличии бесконечного места и бесконечного времени, "взломать" этот "шифр" можно — полным перебором. Но практически ни того, ни другого нет. Задача безопасности в том и заключается, чтобы максимально повысить для противника цену, которую ему придётся заплатить за расшифровку, в идеале — до значения в пол-дофуа.
P.S. А для повышения стойкости имеет смысл предварительно повысить энтропию передаваемого сообщения, зашифровав его любым простейшим шифром, пусть даже с ключом из одних нулей — чтобы в нём не осталось никаких характерных последовательностей, вроде PK в заголовке ZIP-файла.
Ну, а если серьезно, то как концепт — интересно, но ИМХО совершенно не пригодно для практического применения.
В частности из-за обновлений. И все сводится к тому, что либо нужно подпихнуть зараженное обновление через аналог RFC1149, либо воспользоваться давно известной уязвимостью (они регулярно всплывают), которая не фиксится по причине полной изоляции 2-х ПК от сети.
Создан сверхзащищённый мессенджер без названия. Исходный код уже на GitHub