Хочу обсудить вариант защиты от 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 с учетом подделки фингерпринтов и не довере сертификатам? Может быть этим никто не занимается? В смысле подделкой фингепринтов?
комментариев: 9796 документов: 488 редакций: 5664
К тому же мы не знаем, насколько быстро он работает. Вероятно обе стороны должны очень точно синхронизировать время от доверенного источника (на который тожен возможен MITM, для критически важных серверов времени в сети предусмотрена строгая аутентификация) или использовать атомные часы.
Может быть зашифрованные его хэшем?
Man-in-the-middle всё время находится на линии. Если он может подменить ключ, то он может придумать правдоподобное подставное сообщение, а затем изменять диалоги участников, раскрывающие его смысл.
Это сложнее для VOIP. Для видеосвязи описана такая идея: видеовыступление собеседника содержит очень низкопропускной скрытый "надсознательный канал": передачу аутентификационных данных в видеоречи (поворотами головы что ли) таким образом, что попытка её отредактировать будет заметна или приведёт к порче аутентификационных данных.
Тема эта в литературе описана, но всё довольно мутно и непрактично. Стойкость подобных схем доказать трудно, даже критериев оценки чётких не разработали.
Одним лишь усложнением протокола связи нельзя предотвратить возможность применения атаки типа MITM, если оставаться при этом в рамках одного канала, контролируемого противником.
Для защиты от атак типа MITM требуется другой, доверенный, канал, гарантированно не контролируемый противником.
Если таких каналов нет, и всё ваше взаимодействие с внешним миром контролируется противником (активным образом, т.е. с возможностью изменения информации, в отличие от пассивного прослушивания), гарантированная защита от MITM невозможна.
Если кто с утверждением не согласен, прошу оппонировать.
комментариев: 155 документов: 20 редакций: 5
В данном случае, время не нужно синхронизировать. Достаточно ожидать время ответа в нужное время, +/- несколько секунд, или даже десятков секунд. Тут лишь важно убедиться, что время прихода PKI подписанного хешем, раньше, чем удаленная сторона начала отправлять зашифорванное сообщение.
Достаточно, чтобы участники сообщения не были блондинками, и получали конкретные ответы на свои конкретные вопросы сразу, а не через сообщение.
Я руководствовался следующим: предсказать время для VOIP и угадать ключ это не одно и то же. Если ключ мы должны лишь расшифровать, не важно со скольких попыток, то время нужно угадать обязательно с первого раза, иначе сразу видно атаку
комментариев: 155 документов: 20 редакций: 5
комментариев: 9796 документов: 488 редакций: 5664
Строго говоря да. Можно доверять ключу, цифровому аутентификатору, но само доверие не транслируется. Получается, что вместо ресурсов вычислительной стойкости мы пытаемя лимитировать "человека посредине" ресурсами времени на принятие решений, семантическими связями (придумывание сообщений на ходу), а это плохо просчитывается.
Единственное, что пока реально работает как альтернатива – сети доверия, распределение и связывание доверия между пользователями. И то, это далеко не идеал.
комментариев: 9796 документов: 488 редакций: 5664
Сформулируйте пожалуйста точнее. Хэши сами по себе ничего не подписывают и не аутентифицируют (надеюсь речь не идёт о такой экзотике, как одноразовые подписи Лампорта на хэшах)?
Что значит "порча голоса", в какое время, как заданное?
Мне из вашего описания понятна только общая идея – гарантированно передать другой стороне непонятную для Мэллори информацию, получить доказательство о вручении, раскрыть информацию, дать другой стороне убедиться, что раскрытое соответствует ранее переданному.
Такие протоколы есть, но проблему MITM они сами по себе, как вы наверное правильно предположили, не решают. Вы решили укрепить это семантикой (определение смысла сообщения) или биометрикой (голос человека). Так?
комментариев: 155 документов: 20 редакций: 5
Типа, обменялись открытыми ключами. Потом, каждый раз присылаем перед сообщением openkey1 xor openkey2 xor hash(message). xor тут чисто условно
лемитированное в стандартный промежуток, но внутри него случайное.
Примерно как пытается ее решить Short Authentication String в Zfone. Какой человек будет использовать неудобные рекомендации по самостоятельному семантическому шифрованию произносимой ключевой фразы? Я предлагаю контроллировать этот процесс автоматически, интуитивно понятно для простого человека.
комментариев: 9796 документов: 488 редакций: 5664
Как это должно звучать-то? Нужно пропеть или промычать что-то неестественным голосом в определённое время?
Или испортить его каким-то сигналом? Каким? Почему этот сигнал не может имитировать третья сторона?
Вот как раз шифрования там нет. Это кодирование. И оно биометрическое, а не семантическое.
комментариев: 9796 документов: 488 редакций: 5664
Хорошо, что только условно. И xor и хэш. Ведь простой хэш ничего не аутентифицирует. Тогда хотя бы HMAC (openkey1 || openkey2 || (message)). Но смысл? Если есть общий секрет, то из него можно получать HMAC (Hash Message Authentication Code) для сообщения. Но чтобы его получить надо чтобы изначально не было MITM.
Он просто даёт привязку к первому сеансу и его ещё придётся хранить в секрете.
комментариев: 9796 документов: 488 редакций: 5664
Так если Мэллори вклиниться в канал, то и сообщения он будет подменять сразу, а не ждать следующего. Но в приципе методы такого рода есть. Внедрить в сообщение нечто, говорящее о подлинном ключе, надеясь, что Мэллори не знает как это изменить.
Но это не было изобретенов полной мере, за исключением отдельных уловок – ведь это должен быть метод шифрования, стеганографии или аутентификации как бы без ключа.
Вы кажется пытаетесь использовать временной канал – в процессе непринуждённой беседы, стороны подают друг другу знаки так что Мэллори не знает, когда собственно начинается передача ключа и когда ему уже пора подменять?
комментариев: 155 документов: 20 редакций: 5
Третья сторона не знает, когда этот сигнал произойдет. А в случае MITM произойдет наложение во времени двух сигналов, со всеми вытекающими последствиями. Не спорю, для действенной защиты нужно дополнительно передавать автоматическую стенограмму разговора на дисплей принимающей стороны. Если канал не достаточен для передачи качественного голоса.
Варианта два: непринужденное семантическое распознование удаленной стороны, атакующий может в любой момент ошибиться (например натренированный переводчик). Или непринужденное завязывание знакомства. Мэллори тогда вообще нет смысла атаковать. Проще использовать подставное лицо. Но даже тогда правильная тактика защищающихся может в любой момент вскрыть Мэллори.
Крипто-ключ передается в самом начале. Весь последующий разговор либо полностью зашифрован, либо полностью сфабрикован. Когда начать говорить секреты – решать защищающимся. Но Мэллори может провалиться в любое время.
комментариев: 155 документов: 20 редакций: 5
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 11558 документов: 1036 редакций: 4118