Усложнение атаки на PKI на основе двух предположений

Защита от MITM нереализуема принципиально без использования подписывания ключей, наличия общего знания, или довереного канала.
Начиная общаться с человеком которого мы раньне никогда не знали, и с коротим не имеем ничего общено, мы не можем аутентифицировать его личность без довереного посредника. Например ко мне в Jabber стучит человек и говорит что он Вася. Лично я этого Васю не знаю, и никогда с ним не общался. Где гарантия, что его на самом деле зовут Вася, и что между нами на канале связи не сидит злой майор Петренко?

1) Обмен открытыми ключами
2) Обмен закрытыми ключами зашифрованными открытыми ключами xor ключами предыдущих итераций
3) Бесконечный обмен информацией зашифрованной открытыми xor закрытыми ключами xor ключами предыдущих итераций.

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

атакующий не может вклиниться в любой момент и произвести атаку на PKI

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

При более подробном изложении, кажется я понял, что предлагает Мухтар.

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

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

Тогда Мэллори должен не ошибиться ни разу. Пусть вероятность ошибки Мэллори на одном шаге – 10%, Pr=0.1 тогда вероятность его успеха Pr=1-0.1=0.9,
но после десяти шагов Pr=П(1...10)*0.9=0.9*0.9x...x0.9=0.3486784401

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

Нечто подобное используется в различных протоколах – увеличение безопасности за много проходов. Это называется "privacy amplification".
Только здесь происходит "амплификация" не privacy, а authentity или как-то так.
Теоретически можно подобрать значение числа проходов так, чтобы оно было за пределами возможностей любого противника.

Проблема в том, что подобрать это значение сложно. Как видно из простейшего примера, возрастание преимущества над Мэллори даже после десяти шагов не очень велико. А ведь он может иметь ресурсы более мощные, чем 10% ошибка на один шаг. Кроме того, если стороны по случайности (связь оборвалась в ответственный момент, буквы при диктовке перепутали) или после неудачного вмешательства Мэллори не смогут согласовать очередной сеансовый ключ, то им нельзя просто откатиться на шаг назад, а придётся выстраивать доверие с нуля, что несколько неудобно.

При допущении, что ошибки сторон при определении друг друга намного меньше ошибок Мэллори, а его ошибки достаточно велики и число шагов тоже достаточно велико, то модель работать будет.

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

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

Вот зачем Вы создали две идентичные темы?
Просто чтобы понять приходится читать и одну и вторую. Как их склеивать теперь?
Плюс терминология путанная, при чём здесь PKI, если речь идёт об одном на две стороны, немасштабируемом доверии? Какая тут инфраструктура?

Обобщая предыдущие ответы, если стороны что-то знают друг о друге и могут распознавать подделку голоса или смысла сообщений при попытке вклиниться в канал и у них есть небольшое преимущество в скорости (VoIP связь, видео), то при вероятности успеха атаки MITM на каждом шаге равной S [0...1],
то за n шагов стороны могут снизить эту вероятность до Sⁿ, если будут каждый раз проводить новое согласование ключей с новой аутентификацией и вырабатывать новый текущий ключ на основе всех предыдущих сеансов аутентификации.

Но это непрактично при S близком к единице, даже при S>0.9 уже смысла нет, плюс это весьма утомительно и велика вероятность ошибочных подозрений сторон, при которой прридётся откатываться назад и проходить много шагов заново.

Хотя право на существование в определённых условиях схема иметь может.

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

Я вижу следующую схему взаимодействия:
Удаленные системы должны все время быть в онлайне и продолжать обмениваться ключами много раз в секунду. Даже если реального сеанса обмена данными не происходит. Перед передачей секретных данных, либо при каждом коммуникационном сеансе следует проводить защиту от mitm. Например, если обмен ключами происходит 3 раза в секунду, то защищаться от mitm можно и раз в час или же периодически. Каждый этап защиты от mitm подтвердит верность всех предыдущих открытых ключей, а не только лишь текущих.

Смысл этого, как вы уже догадались, в допущении, что атакующий умеет взламывать открытые ключи за полиномиальное время (например на квантовом компьютере) но мы осведомлены о вычислительных мощностях атакующего.

Слабость возможна в виду не достаточно доказанной стойкости openkey1 xor openkey2 xor privatekey1 xor privatekey2. Вместо xor применять более стойкую функцию. Тут еще нужна доработка.