Хочу обсудить вариант защиты от MITM
Добрый день! Хотел бы обсудить вариант защиты от mitm для мессенджеров и VOIP: целесообразность, слабые места, удобство использования и т.п.
Для мессенджеров протокол примерно следующий:
1) Обмен сообщениями происходит в фиксированное время по полудуплексной схеме.
2) На написание сообщения отводится фиксированное время.
3) Посе сабмита сообщения сначала отправляются открытые ключи обернутые в хеш сообщения
4) Через фиксированное время отправляется зашифорванное сообщение
5) Принимающая сторона контроллирует время приема PKI и удостоверяется в правильности открытых ключей позже, после приема сообщения.
6) MITM не может подделать PKI, т.к. он не знает сообщение отправляющей стороны (оно отправляется позже), то есть цифровой подписью защишающей PKI является смысловая нагрузка сообщения
Для VOIP вариант следующий:
1) Удаленный терминал загадывает время и продолжительность порчи голоса (порядка 3-5 секунд)
2) Обмен открытыми ключами обернутыми во время порчи голоса
3) Передача голоса
4) Порча голоса в загаданное время
5) Принимающая стороны контроллирует сигнал порчи голоса
6) MITM и фабрикация голоса произносящего ключевую фразу (как в Zfone) невозможна, так как атакующий не знает что говорил человек во время порчи голоса
7) Люди общаются, и не доверяют моменту произношения секретной фразы как в Zfone, а просто периодически переспрашивают друг друга что они не услышали. С точки зрения психологии это проще и безопаснее
Я писал про это Циммерману, но в этот раз он не ответил, хотя примерно год назад он мне ответил что написал в Zfone FAQ о проблеме SAS voice impersonation
И вообще, насколько актуальная защита от MITM с учетом подделки фингерпринтов и не довере сертификатам? Может быть этим никто не занимается? В смысле подделкой фингепринтов?
ставка на время кажется нереалистичным допущением. Реальная сеть – это не идеализированный канал, где задержки могут возникать только из-за злоумышленника.
К тому же мы не знаем, насколько быстро он работает. Вероятно обе стороны должны очень точно синхронизировать время от доверенного источника (на который тожен возможен MITM, для критически важных серверов времени в сети предусмотрена строгая аутентификация) или использовать атомные часы.
Может быть зашифрованные его хэшем?
Man-in-the-middle всё время находится на линии. Если он может подменить ключ, то он может придумать правдоподобное подставное сообщение, а затем изменять диалоги участников, раскрывающие его смысл.
Это сложнее для VOIP. Для видеосвязи описана такая идея: видеовыступление собеседника содержит очень низкопропускной скрытый "надсознательный канал": передачу аутентификационных данных в видеоречи (поворотами головы что ли) таким образом, что попытка её отредактировать будет заметна или приведёт к порче аутентификационных данных.
Тема эта в литературе описана, но всё довольно мутно и непрактично. Стойкость подобных схем доказать трудно, даже критериев оценки чётких не разработали.
Мнение вслух.
Одним лишь усложнением протокола связи нельзя предотвратить возможность применения атаки типа MITM, если оставаться при этом в рамках одного канала, контролируемого противником.
Для защиты от атак типа MITM требуется другой, доверенный, канал, гарантированно не контролируемый противником.
Если таких каналов нет, и всё ваше взаимодействие с внешним миром контролируется противником (активным образом, т.е. с возможностью изменения информации, в отличие от пассивного прослушивания), гарантированная защита от MITM невозможна.
Если кто с утверждением не согласен, прошу оппонировать.
В данном случае, время не нужно синхронизировать. Достаточно ожидать время ответа в нужное время, +/- несколько секунд, или даже десятков секунд. Тут лишь важно убедиться, что время прихода PKI подписанного хешем, раньше, чем удаленная сторона начала отправлять зашифорванное сообщение.
Достаточно, чтобы участники сообщения не были блондинками, и получали конкретные ответы на свои конкретные вопросы сразу, а не через сообщение.
Я руководствовался следующим: предсказать время для VOIP и угадать ключ это не одно и то же. Если ключ мы должны лишь расшифровать, не важно со скольких попыток, то время нужно угадать обязательно с первого раза, иначе сразу видно атаку
и не точное время, а отсчет задержки
Строго говоря да. Можно доверять ключу, цифровому аутентификатору, но само доверие не транслируется. Получается, что вместо ресурсов вычислительной стойкости мы пытаемя лимитировать "человека посредине" ресурсами времени на принятие решений, семантическими связями (придумывание сообщений на ходу), а это плохо просчитывается.
Единственное, что пока реально работает как альтернатива – сети доверия, распределение и связывание доверия между пользователями. И то, это далеко не идеал.
Сформулируйте пожалуйста точнее. Хэши сами по себе ничего не подписывают и не аутентифицируют (надеюсь речь не идёт о такой экзотике, как одноразовые подписи Лампорта на хэшах)?
Что значит "порча голоса", в какое время, как заданное?
Мне из вашего описания понятна только общая идея – гарантированно передать другой стороне непонятную для Мэллори информацию, получить доказательство о вручении, раскрыть информацию, дать другой стороне убедиться, что раскрытое соответствует ранее переданному.
Такие протоколы есть, но проблему MITM они сами по себе, как вы наверное правильно предположили, не решают. Вы решили укрепить это семантикой (определение смысла сообщения) или биометрикой (голос человека). Так?
Типа, обменялись открытыми ключами. Потом, каждый раз присылаем перед сообщением openkey1 xor openkey2 xor hash(message). xor тут чисто условно
лемитированное в стандартный промежуток, но внутри него случайное.
Примерно как пытается ее решить Short Authentication String в Zfone. Какой человек будет использовать неудобные рекомендации по самостоятельному семантическому шифрованию произносимой ключевой фразы? Я предлагаю контроллировать этот процесс автоматически, интуитивно понятно для простого человека.
Как это должно звучать-то? Нужно пропеть или промычать что-то неестественным голосом в определённое время?
Или испортить его каким-то сигналом? Каким? Почему этот сигнал не может имитировать третья сторона?
Вот как раз шифрования там нет. Это кодирование. И оно биометрическое, а не семантическое.
Хорошо, что только условно. И xor и хэш. Ведь простой хэш ничего не аутентифицирует. Тогда хотя бы HMAC (openkey1 || openkey2 || (message)). Но смысл? Если есть общий секрет, то из него можно получать HMAC (Hash Message Authentication Code) для сообщения. Но чтобы его получить надо чтобы изначально не было MITM.
Он просто даёт привязку к первому сеансу и его ещё придётся хранить в секрете.
Так если Мэллори вклиниться в канал, то и сообщения он будет подменять сразу, а не ждать следующего. Но в приципе методы такого рода есть. Внедрить в сообщение нечто, говорящее о подлинном ключе, надеясь, что Мэллори не знает как это изменить.
Но это не было изобретенов полной мере, за исключением отдельных уловок – ведь это должен быть метод шифрования, стеганографии или аутентификации как бы без ключа.
Вы кажется пытаетесь использовать временной канал – в процессе непринуждённой беседы, стороны подают друг другу знаки так что Мэллори не знает, когда собственно начинается передача ключа и когда ему уже пора подменять?
Третья сторона не знает, когда этот сигнал произойдет. А в случае MITM произойдет наложение во времени двух сигналов, со всеми вытекающими последствиями. Не спорю, для действенной защиты нужно дополнительно передавать автоматическую стенограмму разговора на дисплей принимающей стороны. Если канал не достаточен для передачи качественного голоса.
Варианта два: непринужденное семантическое распознование удаленной стороны, атакующий может в любой момент ошибиться (например натренированный переводчик). Или непринужденное завязывание знакомства. Мэллори тогда вообще нет смысла атаковать. Проще использовать подставное лицо. Но даже тогда правильная тактика защищающихся может в любой момент вскрыть Мэллори.
Крипто-ключ передается в самом начале. Весь последующий разговор либо полностью зашифрован, либо полностью сфабрикован. Когда начать говорить секреты – решать защищающимся. Но Мэллори может провалиться в любое время.
Если две стороны сумели договориться о времени в тайне от третьей, почему бы им сразу не договориться о ключе шифрования?
Сегодня получил ответ от Циммермана. Сразу два письма :-) Посоветовал пройти ревью у товарищей из http://www.iacr.org/ Или отправиться на конференцию в Турцию. Другой вопрос, надо ли оно мне?
Ну, там-то (и у одних, и у других) Ваша идея будет подвергнута более предметному разбору. Возможно, она этот разбор переживёт, тогда сразу может стать предметом для реализации (хоть в том же Zfone, в чём Циммерман вполне заинтересован). Возможно, и более вероятно, что идею разнесут в пух и прах, но из этого станет ясно, куда двигаться для организации контрзащиты. Или придёте к заключению, что всё это на самом деле розовые мечты, и защиты от MITM в единственном канале не бывает.
Я тоже пытался[link1] что-то подобное придумать. Как можно видеть, не очень-то успешно.
Создавайте одну тему, мой ответ здесь[link2]
Unknown, так ведь это две разные темы, и не нужно их склеивать! В этой идется про защиту от MITM, а во второй про усилении надежности инфраструктуры открытых ключей при условии, что АНБ умеет взламывать открытые ключи за полиномиальное время.
А по поводу твоего последнего ответа, я и сам согласен, что практически, очень трудно взломать голосовой фингерпринт атакой фабрикации голоса. Хотя, за пол года 2-ух людей можно натренировать, что они будут щелкать людей как орешки. Но вот будут ли такой атакой ломать президентов – вопрос для меня не ясен.
Вообще сейчас есть программы которых можно научить говорить голосом любого человека если есть записи многих речей что он произнёс. Аналогично и про видео. Можно в реальном времени даже редактировать видеосъёмку – есть такие программы. Скоро тому что видим/слышим с компа уже вообще нельзя будет доверять :)
Об этом есть худ.фильм S1M0NE[link3]("Симона")
Артисты в некоторых рекламных роликах выглядят уж очень неестественно. Возможно, что это уже только их компьютерные модели. Так, вероятно, даже дешевле будет.
Вобщем, ещё немного лет, и очередной уловень матрицы замкнётся...
поправка: HMAC = Hugo's Message Auth. Code
Who is Hugo?