Контроль за безопасностью e-mail информации
Как известно, информация, пересылаемая через email может быть перехвачена злоумышленниками в трех основных местах: на ПК отправителя, в процессе передачи данных (в пути) и на ПК получателя. Как обезопасить информацию когда она попала на ПК получателя и находится под его контролем?
Один метод, который я прочитал недавно: загружать всю важную информацию на аналог dropbox (в зашифр. виде) и пересылать ссылку, а не сам файл. Таким образом у отправителя все еще остается какой-то контроль над информацией и ее можно в крайнем случае удалить с сервера.
Некоторые предлагают использовать самоуничтожающие email, что мне как-то не очень нравится.
Какие есть другие способы?
комментариев: 9796 документов: 488 редакций: 5664
медицинаинформационная безопасность здесь бессильна.комментариев: 1060 документов: 16 редакций: 32
Это всё скорее для удобства передачи больших объёмов, чем для безопасности.
комментариев: 393 документов: 4 редакций: 0
Посмотрите проект SMS-шифровальщика и протокол Axolotl
Это доработанный OTR для оффлайна. Я еще зимой сделал свой шифровальщик почты по прототипу, но уперся в одну проблему, пока не готов его представить.
Общий концепт таков: в каждое письмо вкладывается DH-ключ, используемый для обновления мастер-ключей переписки. После отправки письма мастер-ключ, с которого был выведен ключ шифрования, тот час заменяется своим хешем (идея от Циммермановского SilentCircle), так что при доступе к машине отправителя ничего из уже отправленного не получится расшифровать. При получении – то же, т.е. при захвате машины отправителя получится расшифровать только вновь приходящие письма, но не уже прочитанные. После получения каждого нового письма обновляется все по полученному в письме очередному DH-ключу (как в OTR).
Плюс автоматические отработки таймаутов: стирание старых ключей для задержавшихся писем. Плюс ручное стирание в эктстренных ситуациях.
Плюс еще отрицаемость (хотя, на мой взгляд, как раз под вопросом) в отношении долговременных ключей, удостоверяющих личности. Т.е. при захвате одной из машин невозможно доказать, что переписка велась с другим абонентом.
У меня есть мысль сделать сервера-пересыльщики (онлайн) на скрытых сервисах (недоверяемых) и организовать почту с адресами вида: онион_получателя@онион_его_сервера,
которые не требуя регистрации, просто будут пересылать все анонимно входящие письма по указанному в них адресу на другой сервер получателя. Получатель анонимно подключается к своему серверу, сообщает свой онион и говорит, что готов считать свою почту, затем рвет соединение. Сервер сам соединяется по указанному онион_получателя, отправляет ему накопленные для него письма и удалает их с хранилища.
Поверх этого всего – описанный выше протокол типа Axolotl.
Те, что были до заражения, прочитать не получится, допустим. Но после заражения все последующие письма сразу по приходу могут копироваться и складироваться зловредом. Пользователь не узнает, когда его заразили, поэтому в полном смысле задача топикстартера не решается — безопасность отправленной корреспонденции целиком в руках получателя.
комментариев: 393 документов: 4 редакций: 0
Золотые слова.
После заражения это уже машина злоумышленника, а не получателя. В таком виде задача нерешаема по определению. Речь идет о полном блокировании доступа к переписке, проводимой перед заражением: возможности расшифровки перехваченного трафика. Т.е. – PFS. Отдельно – проблема отрицаемости: опять же после выполнения протокола нельзя показать, что он был выполнен. Но никак не во время его выполнения.
Да ну?