Шифрование на стороне клиента через HTTP с помощью обмена ключами Диффи-Хеллмана и AES

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

Короче говоря, без SSL вы уязвимы для атак типа «злоумышленник в середине». Никакая криптографическая реализация JavaScript на основе браузера не может преодолеть этот факт.

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

Давайте разделим контрольный вопрос на две части.

1. Насколько безопасен обмен ключами?
2. Насколько безопасно шифрование, которое вы используете после того, как у вас есть общий ключ?

Позвольте мне сначала ответить (2), так как это будет самым простым. Это будет ужасно небезопасно, если вы не станете умнее всех людей, которые работали и изучали TLS на протяжении многих лет. TLS до версии 1.2 (которую используют несколько сайтов) в принципе уязвим для атак с выбранным зашифрованным текстом (CCA) и для BEAST-атака на практике в зависимости от выбора шифровального костюма. А SSL 2.0 еще хуже сломан.

Дело в том, что очень-очень умные люди, годами работавшие над этими протоколами, ошибались. Есть все основания полагать, что вы есть. Я, работая над подобными вещами самостоятельно, совершаю огромные ошибки. Основные алгоритмы шифрования в порядке. Они не сломаны. Но протоколы есть.

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

Теперь к вопросу (2). Здесь есть две проблемы. (a) Diffie-Hellman не предназначен для обеспечения того типа безопасности, который вам, вероятно, нужен; и (б) я не думаю, что вы правильно реализовали DH.

2.a:

Обмен ключами Диффи-Хеллмана, если все сделано правильно, безопасен для обмена ключами, но ничего не делает для аутентификации. Вот почему вопрос «безопасно ли» часто оказывается неправильным. Он безопасен для одних целей, но крайне небезопасен для других, поскольку не предназначен для других целей.

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

После такой настройки Мэллори может действовать как Человек посередине между Сэмом и Чарли. Когда Чарли отправляет данные, предназначенные Сэму, Мэллори расшифровывает их, используя общий ключ между C и M, считывает его (и, возможно, изменяет его), а затем повторно зашифрует его общим ключом между M и S и отправляет его S. .

Чтобы решить проблему аутентификации, вам нужна какая-то инфраструктура открытого ключа (PKI), и это действительно проблема. Система центров сертификации и тому подобное, что у нас есть с SSL / TLS, чревата проблемами, но она остается лучшей системой.

2.b:

512-битный общедоступный модуль вместе с 512-битными закрытыми ключами недостаточно сильны. Ключи DH должны быть больше. Я бы не стал использовать меньше 2048 бит. Вам может сойти с рук 1024 бит, и вы не беспокоитесь о том, что кто-то сможет раскрыть сегодняшние секреты через пять лет.

Вы не предоставили достаточно информации о том, как были выбраны ваши простые числа. Не каждый прайм будет работать. Вам необходимо использовать «безопасное простое число» для вашего модуля, в противном случае злоумышленник может воспользоваться сокращениями для вычисления дискретного логарифма.

Если вы хотите обойти SSL-сертификат и решить проблему человека, вы можете использовать блокчейн биткойнов. (Или блокчейн альткойнов.)

Огромное предостережение: клиент должен либо загрузить, либо сохранить весь файл цепочки блоков.

Есть две пары открытого / закрытого ключей:

CERTpublic CERTprivate

КЛИЕНТПубличный КЛИЕНТЧастный

РЕГИСТРАЦИЯ ИМЕНИ:

Server -> CERTpublic and name_to_register -> Bitcoin Blockchain

АУТЕНТИЧНОЕ СОЕДИНЕНИЕ:

Client <- CERTpublic <- Bitcoin Blockchain
Client -> CERTpublic(CLIENTpublic) -> Server or Adversary
Client <- No_response_or_incorrect <- Adversary 
Client <- CLIENTpublic(CERTprivate(content)) <- Server