У меня есть приложение, в котором я должен отправлять несколько небольших данных в секунду через сеть, используя UDP. Приложение должно отправлять данные в режиме реального времени (без ожидания). Я хочу зашифровать эти данные и убедиться, что то, что я делаю, максимально безопасно.
Поскольку я использую UDP, невозможно использовать SSL/TLS, поэтому я должен зашифровывать каждый пакет самостоятельно, поскольку протокол является бесконтактным/ненадежным/нерегулируемым.
В настоящее время я использую 128-битный ключ, полученный от кодовой фразы от пользователя, и AES в режиме CBC (PBE с использованием AES-CBC). Я решил использовать случайную соль с кодовой фразой для вывода 128-битного ключа (запретить атаку словаря на кодовую фразу) и, конечно же, использовать IVs (чтобы предотвратить статистический анализ пакетов).
Однако меня беспокоит несколько вещей: Каждый пакет содержит небольшой объем данных (например, пару целочисленных значений для каждого пакета), которые сделают зашифрованные пакеты уязвимыми для известных атак с открытым текстом (что приведет к упрощению взлома ключа). Кроме того, поскольку ключ шифрования получен из кодовой фразы, это сделает пространство ключа меньше (я знаю, что соль поможет, но я должен отправить соль через сеть один раз, и любой может ее получить). Учитывая эти две вещи, каждый может понюхать и сохранить отправленные данные и попытаться взломать ключ. Хотя этот процесс может занять некоторое время, как только ключ будет взломан, все сохраненные данные будут дешифрованы, что станет реальной проблемой для моего приложения.
Итак, мой вопрос: каковы наилучшие методы для отправки/шифрования непрерывных небольших данных с использованием протокола без установления соединения (UDP)? Мой способ - лучший способ сделать это?... потекла?... Overkill?
Обратите внимание, что я не прошу о 100% -ом безопасном решении, так как такой вещи нет.
У вас есть несколько вариантов. Вы можете использовать DTLS, который является версией TLS, адаптированной для дейтаграмм. Он указан в RFC и реализован в библиотеке openssl. Вы также можете использовать протокол IKE/IPsec и использовать инкапсуляцию UDP части IPsec. Обычно IPsec доступен на уровне ОС. Вы также можете использовать OpenVPN, который выглядит как гибрид TLS для обмена ключами и проприетарный протокол шифрования пакетов на основе UDP.
Если ваша проблема в том, что данные слишком малы, как насчет расширения данных со случайными байтами? Это сделает текст гораздо сложнее догадаться.
Этот вопрос немного стар, но как насчет использования подхода One Time Pad? Вы можете использовать безопасный надежный механизм транспорта (например, HTTPS) для передачи одноразовых ключей с сервера на ваш клиент. Могут быть два набора ключей - один для клиента для разрыва и один для сервера для клиента. Каждая датаграмма будет включать в себя порядковый номер (используемый для идентификации ключа времени), а затем зашифрованное сообщение. Поскольку каждый ключ используется только для одной дейтаграммы, вы не должны подвергаться небольшой проблеме с данными. Тем не менее, я не эксперт в этом, так что обязательно проверьте эту идею, прежде чем использовать ее...
Используйте обмен ключами 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) до предела.