Как можно создать безопасную и «самоуничтожающуюся» электронную почту?

Question

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

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

Решение (я полагаю, наиболее распространенное) состоит в том, чтобы отправить сообщение доверенной третьей стороне и ссылку наэто сообщение получателю, который затем читает это сообщение от третьего лица.Или отправитель может отправить зашифрованное сообщение (используя симметричное шифрование) получателю и отправить ключ третьей стороне.

В любом случае, есть фундаментальная проблема с этим подходом: если эта третья сторона скомпрометирована, все ваши усилия будут бесполезными.Для реального примера подобного инцидента, обратитесь к разгромам, связанным с Crypto AG сговором с АНБ

Другим решением, которое я видел, было Vanish , которое шифруетсообщение, разбивает ключ на части и «сохраняет» части в DHT (а именно в Vuze DHT).К этим значениям можно легко и несколько надежно получить доступ, просто просматривая хеш-коды (хеш-коды отправляются вместе с сообщением).Через 8 часов эти значения будут потеряны, и даже предполагаемый получатель не сможет прочитать сообщение.С миллионами узлов нет единой точки отказа.Но это также было сломано путем организации атаки Сибилла на DHT (см. Дополнительную информацию на веб-странице Vanish).

Так есть ли у кого-нибудь идеи о том, как этого добиться?

РЕДАКТИРОВАТЬ: Я думаю, я не прояснил себя.Основная проблема не в том, что получатель намеренно хранит сообщение (я знаю, что это невозможно контролировать), а в том, что сообщение где-то доступно.

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

Answer 1

Существует так много разных способов решения этой проблемы, у каждого из которых есть свои плюсы и минусы, и вам просто нужно выбрать правильный для вашего сценария. Я думаю, что лучший способ добиться этого - это то же самое, что и ваше «самое распространенное» решение. Надежной третьей стороной действительно должны быть вы - вы создаете собственный веб-сайт с использованием своей собственной аутентификации. Тогда вам не нужно никому давать свои гипотетические ключи.

Вы можете использовать двусторонний метод сертификации, создав собственное клиентское программное обеспечение, которое может читать электронные письма, при этом у пользователя есть собственный сертификат. Лучше быть в безопасности, чем потом сожалеть!

Answer 2

Самоуничтожение очень сложно, потому что пользователь может сделать снимок экрана и сохранить скриншот незашифрованным на своем диске и т. Д. Поэтому я думаю, что у вас нет шансов применить это (всегда найдется способ, даже если Вы ссылаетесь на внешнюю страницу). Но вы можете просто попросить получателя удалить его позже.

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

Например, я использую GnuPG для (почти) всех писем, которые я пишу, что основано на асимметричных методах шифрования. Здесь я знаю, что только те, кому я дал явное разрешение, могут читать почту, и, поскольку есть плагины, доступные почти для всех популярных MUA, получателю также будет довольно легко читать почту. (Таким образом, никто не должен шифровать почту вручную и может забыть удалить незашифрованное сообщение с диска ...). И также возможно отозвать ключи, если кто-то украл ваш личный ключ, например (который обычно шифруется в любом случае).

По моему мнению, GnuPG (или, альтернативно, S / MIME) следует использовать постоянно, потому что это также поможет сделать спам более трудным. Но это, наверное, один из моих глупых снов;)

Answer 3

(Отказ от ответственности: я не читал подробности об атаке Ваниша или Сибил, что может быть похоже на то, что происходит ниже)

Прежде всего: сообщения электронной почты, как правило, довольно малы, особеннопо сравнению с 50-мегабайтным видео YouTube вы можете скачать 10 раз в день или больше.На этом я основываю предположение о том, что хранение и пропускная способность здесь не являются реальной проблемой.

Шифрование, в общем смысле этого слова, вводит в вашу систему части, которые трудно понять и, следовательно, трудно проверить.(подумайте о типичной магии openssl, которую все просто выполняют, но 99% людей действительно понимают; если какой-то шаг X в HOWTO скажет: «Теперь перейдите на сайт X и загрузите * .cer * .pem и * .csr» для проверки шагов.1 к X-1, я думаю, что 1 из 10 человек просто сделает это)

Объединив два наблюдения, я предлагаю безопасную (*) и понятную систему:

Скажем, у вас естьсообщение М 10 кб.Возьмите N раз 10 кб от /dev/(u)random, возможно, от аппаратных случайных источников, назовите его K (0) - K (N-1).Используйте простую операцию xor для вычисления

K(N) = M^K(0)^K(1)^...^K(N-1)

сейчас, по определению

M = K(0)^K(1)^...^K(N)

, т. Е. Чтобы понять сообщение, вам нужны все K.Храните K с N различными (более или менее доверенными) сторонами, используя любой протокол, который вам нравится, под случайными 256-битными именами.

Чтобы отправить сообщение, отправьте N ссылок на K.

Чтобы уничтожить сообщение, убедитесь, что по крайней мере один К. удален.
(*) Что касается безопасности, система будет столь же безопасной, как и самая безопасная сторона, принимающая К.

Не принимайтефиксированное N, не имейте фиксированного количества K на одном узле на сообщение (т. е. помещайте 0-10 K одного сообщения на одном узле), чтобы сделать грубую атаку тяжелой, даже для тех, кто имеет доступ ко всемузлы, хранящие ключи.

Примечание: это, конечно, потребует некоторого дополнительного программного обеспечения, как и любое решение, но сложность необходимых плагинов / инструментов минимальна.

Answer 4

IMO, наиболее практичным решением для ситуации является использование IM-клиента Pidgin с Off-the-Record (без регистрации) и pidgin-encrypt (сквозное ассиметричное шифрование) вместе.Сообщение будет уничтожено, как только окно чата будет закрыто, и в экстренном случае вы можете просто отключить компьютер, чтобы закрыть окно чата.

Answer 5

Проблема, как вы ее описали, звучит очень близко к проблеме, рассматриваемой Ванишем и подробно обсуждаемой в их статье. Как вы заметили, у их первой реализации была обнаружена слабость, но она скорее слабая, чем фундаментальная, и поэтому, вероятно, исправима.

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

Следовательно, ваш лучший вариант - это подождать Vanish версии 2. С программным обеспечением безопасности сворачивание собственного почти никогда не является хорошей идеей, а получение чего-либо от устоявшейся академической группы безопасности намного безопаснее.

Answer 6

Если ваша среда это позволяет, вы можете использовать доверенную загрузочную среду , чтобы убедиться, что доверенный загрузчик использовался для загрузки доверенного ядра, что может проверить, используется ли доверенный почтовый клиентполучить письмо перед отправкой.См. Удаленная аттестация .

. Почтовый клиент будет обязан ответственно удалять сообщения своевременно - возможно, полагаясь только на хранилище в памяти и запрашивая память, которая не может бытьподкачка на диск.

Конечно, в программах могут возникать ошибки, но этот механизм может гарантировать, что нет преднамеренного пути к хранению электронной почты.

Answer 7

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

Answer 8

Если получатель знает, что сообщение может стать нечитаемым позже, и он считает сообщение ценным, он намерен сохранить его, поэтому он попытается ослабить защиту.

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

Одним из способов может быть использование саморазрушающегося оборудования, как в «Миссии невыполнима» - аппаратногобудет отображать сообщение, а затем уничтожать его, но, как вы можете видеть, это также неудобно - получатель должен понимать сообщение, просматривая его только один раз, что не всегда возможно.

Так, учитывая тот факт, чтополучатель может быть заинтересован в подрыве защиты, а защита может быть подорвана, и вся идея, скорее всего, будет работать не так, как задумано, но, несомненно, сделает работу с сообщениями менее удобной.