Как противостоять MITM и повторять атаки при отправке зашифрованных данных? - PullRequest
2 голосов
/ 04 мая 2009

Если предположить, что я безопасно обменялся ключами с другим компьютером (возможно, с использованием Диффи-Хеллмана), вот мое предварительное решение:

номер пакета + зашифрованные данные + код аутентификации сообщения (MAC)

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

Есть ли какой-то недостаток в моих рассуждениях здесь?

Ответы [ 4 ]

1 голос
/ 04 мая 2009

При условии, что я безопасно обменялся ключами с другим компьютером (возможно, с использованием Диффи-Хеллмана)

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

Проконсультируйтесь с Практическая криптография (или по Amazon ) Фергюсона и Шнайера для получения информации об этом.

0 голосов
/ 11 мая 2009

После обмена ключами данные не могут быть перехвачены или подделаны третьей стороной. (За исключением случаев, когда ваш счетчик пакетов # зацикливается. Гипотетически пакеты из старого окна могут быть воспроизведены как находящиеся в новом окне.) Решением этой проблемы является временная метка (как уже упоминали другие). Однако, опять же, это можно саботировать, если Злоумышленник может каким-то образом скомпрометировать системное время. (Если они человек посередине, они могут гипотетически имитировать NTP-сервер и таким образом изменять системное время клиента.)

Однако, что МОЖЕТ сделать подслушиватель, это вставить себя между двумя сторонами и разрушить канал. Это может вызвать новый обмен ключами, который можно наблюдать. Чтобы сделать обмен ключами по-настоящему безопасным, вы должны использовать проверку третьей стороной или предварительный общий ключ, который знают только два коммуникатора.

0 голосов
/ 04 мая 2009

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

0 голосов
/ 04 мая 2009

Вы описываете не человека в средней атаке, а атаку переигровки.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...