Лучшие практики для шифрования непрерывных / малых данных UDP - PullRequest
19 голосов
/ 14 июня 2010

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

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

Сейчас я использую 128-битный ключ, полученный из ключевой фразы пользователя, и AES в режиме CBC (PBE, использующий AES-CBC). Я решил использовать случайную соль с парольной фразой для получения 128-битного ключа (предотвратить атаку по словарной фразе) и, конечно, использовать IV (для предотвращения статистического анализа пакетов).

Однако меня беспокоит несколько вещей: Каждый пакет содержит небольшой объем данных (например, пару целочисленных значений в каждом пакете), что делает зашифрованные пакеты уязвимыми для атак с использованием открытого текста (что упрощает взлом ключа). Кроме того, поскольку ключ шифрования является производным от ключевой фразы, это позволит уменьшить пространство для ключей (я знаю, что соль поможет, но мне нужно отправить соль через сеть один раз, и любой сможет ее получить). Учитывая эти две вещи, любой может прослушать и сохранить отправленные данные и попытаться взломать ключ. Хотя этот процесс может занять некоторое время, после взлома ключа все сохраненные данные будут расшифрованы, что станет реальной проблемой для моего приложения.

Итак, мой вопрос: каковы наилучшие практики для отправки / шифрования непрерывных небольших данных с использованием протокола без установления соединения (UDP)? Мой путь - лучший способ сделать это? ... потекла? ... Overkill?

Обратите внимание, что я не прошу о 100% -ном безопасном решении, поскольку такой вещи нет.

Ответы [ 4 ]

12 голосов
/ 15 июня 2010

У вас есть несколько вариантов. Вы можете использовать DTLS, который является версией TLS, адаптированной для дейтаграмм. Он указан в RFC и реализован в библиотеке openssl. Вы также можете использовать протокол IKE / IPsec и использовать UDP-инкапсуляцию части IPsec. Обычно IPsec доступен на уровне ОС. Вы также можете использовать OpenVPN , который выглядит как гибрид TLS для обмена ключами и собственного протокола шифрования пакетов на основе UDP.

3 голосов
/ 14 июня 2010

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

0 голосов
/ 24 ноября 2015

Используйте обмен ключами Ecdh (используйте пароль для шифрования закрытого ключа клиента; оставленный на клиенте) вместо пароля. Это очень сильный ключ.

Aes cbc вам не помогает; сообщения слишком короткие, и вы хотите предотвратить повторные атаки. Добавление 64-битного сообщения (два целых числа) со счетчиком (начиная с 0) 64-битное означает, что можно отправить 2 ^ 64 сообщения. Зашифруйте блок дважды (aes ecb) и отправьте e (k; m | count) | e (k; e (k; m | count)). Приемник принимает только монотонно увеличивающиеся числа, где второй блок является шифрованием первого. Это 32-байтовые сообщения, которые хорошо вписываются в пакет udp.

если 2 ^ 64 сообщения слишком мало; посмотрите, может ли ваше сообщение быть меньше (3-байтовые целые числа означают, что счетчик может быть 80 бит); или вернитесь к шагу 1 (новые закрытые ключи как минимум для одной стороны), как только вы приблизитесь (скажем, 2 ^ 64-2 ^ 32) к пределу.

0 голосов
/ 15 апреля 2014

Этот вопрос немного стар, но как насчет использования подхода типа One Time Pad ? Вы можете использовать безопасный надежный транспортный механизм (например, HTTPS) для передачи одноразовых ключей с сервера на ваш клиент. Там может быть два набора ключей - один для клиента, а другой для сервера к клиенту. Каждая дейтаграмма будет включать порядковый номер (используемый для идентификации одноразового ключа) и затем зашифрованное сообщение. Поскольку каждый ключ используется только для одной дейтаграммы, вы не должны сталкиваться с проблемой небольших данных. Тем не менее, я не эксперт в этом деле, поэтому обязательно ознакомьтесь с этой идеей, прежде чем использовать ее ...

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