Безопасность UDP и определяющий входящие данные
Я создавал приложение с помощью UDP для передачи и получения информации. Проблемой, с которой я сталкиваюсь, является безопасность. Прямо сейчас я использую IP/socketid в определении, какие данные принадлежат кого.
Однако я читал о том, как люди могли просто имитировать свой IP, затем просто отправьте данные как определенный IP. Таким образом, это, кажется, неправильный способ сделать это (небезопасный). Таким образом, как еще, я предполагаю для идентификации, какие данные принадлежат какой пользователи? Например, у Вас есть 10 соединенных пользователей, у всех есть определенные данные. Сервер должен был бы соответствовать пользовательским данным к этим данным, которые мы получили.
Единственный путь I видит, чтобы сделать, это должно использовать своего рода клиент-серверную ключевую систему и зашифровать данные. Мне любопытно относительно того, как другие приложения (или игры, так как это - то, что это приложение) удостоверяются, что их данные являются подлинными. Также существует то, что шифрование берет намного дольше для обработки, чем незашифрованный. Хотя я не уверен тем, насколько это будет влиять на производительность.
Любая информация ценилась бы.Спасибо.
5 ответов
Если вам абсолютно необходимо убедиться, что конкретный пользователь является конкретным пользователем, вам необходимо использовать некоторую форму шифрования, при которой пользователь подписывает свои сообщения. Это можно сделать довольно быстро, потому что пользователю нужно только сгенерировать хеш своего сообщения, а затем подписать (зашифровать) хеш.
Для вашего игрового приложения вам, вероятно, не стоит об этом беспокоиться. Большинство интернет-провайдеров не разрешают своим пользователям подделывать IP-адреса, поэтому вам нужно беспокоиться только о пользователях, находящихся за NAT, в которых у вас может быть несколько пользователей, работающих с одного и того же IP-адреса. В этом и общем случае вы можете довольно безопасно идентифицировать уникальных пользователей на основе кортежа, содержащего IP-адрес и порт UDP.
Вы можете посмотреть на HMAC
Википедия:
В криптографии, HMAC (Hash-based Message Authentication Code), является специфическая конструкция для вычисления кода аутентификации сообщения (MAC) с использованием криптографической хэш функции в сочетании с секретным ключом. Как и любой другой MAC, он может быть использован для одновременной проверки как целостности данных целостности и подлинности сообщения.
Каждый клиент должен получить уникальный токен, который известен только ему. Каждое сообщение, которое они отправляют, они составляют хэш на основе маркера и сообщения и отправляют его вместе с самим сообщением. Тогда вы сможете проверить, что сообщение пришло от конкретного клиента.
Я разбиваю это на четыре уровня безопасности.
Чрезвычайно небезопасный - Любой человек в сети может подделать действительный запрос / ответ с общедоступными предварительными знаниями. (т.е. системный журнал)
Очень небезопасный - Любой пользователь в сети может подделать действительный запрос / ответ только в том случае, если у него есть хотя бы доступ на чтение к проводу. (Пассивный MITM) (т.е. http доступный форум с файлами cookie браузера)
Несколько небезопасный - Любой человек в сети может подделать действительный запрос / ответ, если он может прочитать И внести изменения в провод (Active MITM) (т.е. https сайт с самозаверяющим сертификатом)
Безопасный - Запросы / Ответы не могут быть подделены даже при полном доступе к проволока. (т.е. https доступный сайт электронной коммерции)
Для интернет-игр очень небезопасное решение может быть на самом деле приемлемым (это был бы мой выбор) Оно не требует криптографии. Просто поле в вашем приложении UDP формата пакетов с каким-то случайным, практически неугадываемым идентификатором сеанса, перемежаемым на протяжении всей игры.
Несколько небезопасный требует немного криптографии, но ни одного доверия / PKI / PSK, необходимого для предотвращения Active-MITM безопасного решения. При некоторой небезопасности, если полезные данные не были конфиденциальными, вы могли бы использовать шифр только целостности с (TCP) TLS / (UDP) DTLS, чтобы уменьшить накладные расходы на обработку и задержку на клиенте и сервере.
Для игр UDP является огромным преимуществом, потому что если есть потеря пакетов, вы не хотите, чтобы стек IP тратило время на ретранслиацию устаревшего состояния - вы хотите отправить новое состояние. С UDP существует ряд умных схем, таких как непризнанные кадры (детали мира, которые не имеют большого значения, если они потеряны) и статистические методы дублирования важных данных о состоянии для противодействия предсказуемым уровням наблюдаемых потерь пакетов.
В конце концов, я бы порекомендовал идти очень небезопасно или несколько небезопасно /w DTLS только.
Одним из решений является использование TCP, так как он защищен от подделки адреса источника в открытом Интернете благодаря трехстороннему рукопожатию (Подробнее о том, почему подделка адреса источника TCP невозможна). Если вы все еще хотите использовать UDP, вы можете использовать имитацию трехстороннего рукопожатия для начала соединения. Затем идентификатор сессии может быть добавлен к каждому UDP-пакету. Это увеличит накладные расходы на соединение на 2 пакета и несколько бит на пакет, однако вы все равно выиграете от скорости UDP в течение оставшейся части сессии по сравнению с tcp.
Однако использование TCP или UDP в качестве транспортного уровня все равно оставляет вас открытым для других атак, таких как Sniffing и Man in The Middle атаки с использованием arp spoofing или dns cache poising. Другая проблема - если атакующий и геймер находятся на одной локальной сети, например, в беспроводной сети или другой широковещательной сети, то вы можете получать трафик независимо от адреса источника/назначения, и ТОЛЬКО ТАК подмена трехстороннего рукопожатия становится возможной (и hmac не поможет!). Лучшим решением является использование SSL/TLS в качестве транспортного уровня, который решает все эти проблемы.
Не стоит изобретать колесо, но если вам по какой-то причине нужно зашифровать UDP, вы должны использовать потоковый шифр типа RC4-drop1024 или даже лучше блочный шифр типа AES 256 в OFB Mode. Это сэкономит полосу пропускания по сравнению с другими режимами шифрования, поскольку они округляют до наибольшего размера блока.
РЕДАКТИРОВАТЬ: Основываясь на комментарии Marts для (Datagram Transport Layer Security) DTLS, я немного покопался и обнаружил, что существует официальный RFC и он поддерживается OpenSSL и должен быть открыт с помощью библиотеки pyOpenSSL. Я рекомендую использовать набор шифров RC4-SHA для снижения накладных расходов, этот набор поддерживается в SSL 3.0 (самая новая версия). Однако DTLS, вероятно, будет иметь больше накладных расходов (LAG!), чем TCP.
DTLS, вероятно, лучшее решение, однако, похоже, очень плохо документировано. Я уже некоторое время искал подобное решение, и все ссылки, которые я видел на реализацию OpenSSL DTLS, говорят о том, что вам нужно будет покопаться в примерах и исходном коде OpenSSL, чтобы понять, как его использовать. .. что для меня означает, что я сделаю 10 серьезных ошибок безопасности, когда попытаюсь установить его. Кроме того, я не верю, что библиотека pyOpenSSL экспортирует эту функциональность.
Я рассматривал альтернативу Secure Remote Password Protocol . Преимущество этого решения заключается в том, что оно обеспечивает надежную взаимную аутентификацию (наравне с безопасностью Kerberos в соответствии с документами) и, что не менее важно в вашем случае, предоставляет обоим концам общий ключ сеанса, который можно использовать для шифрования. .
Учитывая общий ключ, каждый пакет может содержать AES256_CBC (<случайный стартовый блок для CBC> Если расшифровка успешно предоставит ожидаемому пользователю- id, пакет аутентифицируется как исходящий от вашего пользователя, и порядковый номер может использоваться для предотвращения атак повторного воспроизведения.
Одним из недостатков SRP является то, что в Python обработка чисел выполняется довольно медленно. Я изменил демонстрационный код Python на что-то более удобное и обнаружил, что для выполнения одного обмена SRP клиент-сервер (процессор 2 ГГц) требуется около 300 мс. Однако прямая реализация алгоритма SRP на C ++ с использованием поддержки BigNumber в OpenSSL заняла всего 2 мс.Итак, если вы собираетесь пойти по этому пути, я настоятельно рекомендую использовать реализацию алгоритма C / C ++ для производственного кода. В противном случае вы, вероятно, сможете обрабатывать только несколько входов в систему в секунду.