Безопасная передача двоичных данных с помощью асинхронных сокетов в C#/.Net

У нас есть сервер сокетов TCP/IP, написанный на C#, который используется для передачи двоичных файлов клиентам. например, клипы, изображения. Асинхронный режим BeginSend/EndSend с обратными вызовами используется для отправки буферов byte[].

Новым требованием является шифрование передаваемых данных. Каждое клиентское соединение будет предоставлять ключ шифрования для использования сервером. Фактический алгоритм шифрования не так важен, т. Е. Цель состоит в том, чтобы просто гарантировать, что данные не будут отправлены в открытом виде. Хватило бы даже RC2CryptoServiceProvider с 40-битными ключами... RijndaelManaged со 128-битными ключами — это излишество и большая нагрузка на ЦП по сравнению с RC2.

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

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


.net c# sockets cryptography asyncsocket
person alexg    schedule 19.08.2013    source источник
comment
С# на С#? Вы должны использовать WCF.   -  person halfbit    schedule 19.08.2013
comment
Как вы сообщите своим клиентам ключи, которыми шифруются данные? Если не HTTPS/SSL, вы делаете это неправильно.   -  person halfbit    schedule 19.08.2013
comment
Просто используйте TLS и при необходимости используйте шифр RC4.   -  person ntoskrnl    schedule 19.08.2013
comment
У нас есть еще один сервер WCF на той же машине. Этот сервер фактически генерирует необходимые ресурсы контента (изображения, клипы и т. д.). Когда ресурсы доступны, в ответ на запросы клиентам выдаются обратные вызовы WCF с ключами для клиентов. использовать. Фактические передачи НЕ выполняются через WCF — мы сравнивали двоичные передачи, и накладные расходы для WCF имеют свои штрафы. Вместо этого наш сервер сокетов TCP использует асинхронный ввод-вывод с перекрытием для передачи двоичного содержимого...   -  person alexg    schedule 19.08.2013
comment
От каких атак вы хотите защититься? Если вы отправляете ключ вместе с данными, то шифрование бесполезно даже против простейших подслушивающих атак. Или вы имеете в виду что-то более конкретное?   -  person ntoskrnl    schedule 20.08.2013
comment
Ключ отправляется в совершенно отдельном сеансе через безопасный обратный вызов WCF (безопасность на транспортном уровне с EncryptAndSign с использованием сертификата). Ключ будет включен в запрос только в том случае, если пользователи решат запросить фактические данные. Основная проблема связана с конфиденциальностью данных клиентов (изображений и клипов), а не с атаками. Некоторые из наших клиентов используют защищенные VPN-туннели, поэтому для них это не проблема; у других клиентов не будет sec-туннеля, следовательно, это необходимо сделать...   -  person alexg    schedule 20.08.2013
comment
Для меня проблемы конфиденциальности требуют полного набора безопасности, предлагаемого TLS. Вы уверены, что RC4 работает слишком медленно? Вы действительно проверяли это?   -  person ntoskrnl    schedule 20.08.2013

Ответы (1)


arrow_upward
6
arrow_downward

Есть несколько способов сделать это. Вот некоторые:

  • Инфраструктура: установите SSL/TLS VPN с вашим клиентом. Используйте новую частную сеть для подключения к сети вашего клиента. Pro: в коде практически нет изменений, в зависимости от вашей текущей реализации. Против: в зависимости от инфраструктуры вашего клиента (и вашей!), это может быть невозможно.

  • SSL: установите прямое безопасное соединение на уровне сокетов между клиентом и вашим сервером. Pro: легко реализовать. В CodeProject есть пример того, как реализовать его через MS SSPI SSL и OpenSSL, которые вы можете использовать в качестве основы для своей собственной реализации; вот ссылка. Против: у SSL есть некоторые хорошо известные проблемы с безопасностью. следует знать, прежде чем рассматривать возможность его реализации.

  • Распространенные алгоритмы (AES, DES, Triple DES, Blowfish): внутренние реализации, которые вы можете использовать перед отправкой и после получения пакетов на вашем коммуникационном уровне. Pro: множество общедоступных библиотек, некоторые изначально доступны, начиная с .NET 3.5 и выше. Против: Как вы упомянули, некоторые из них могут быть излишними.

  • Пользовательские алгоритмы: создайте свой собственный! Встряхните эти кусочки. Pro: он может быть настолько легким, насколько вы хотите; общедоступные инструменты взлома были бы почти бесполезны. Здесь приведен пример простого пользовательского протокола шифрования для 32 -битные целые числа, легко адаптируемые для большего содержания. Против. Общедоступные алгоритмы тщательно тестируются и проверяются и обеспечивают уровень безопасности, которому ваша реализация может не соответствовать; мало веских причин для изобретения велосипеда.

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

person OnoSendai    schedule 19.08.2013
comment
Все текущие уязвимости в TLS 1.1 и 1.2 носят чисто теоретический характер и определенно незначительны по сравнению с проблемами в других упомянутых вами подходах. Невозможно создать безопасный протокол из криптографических примитивов, если вы не являетесь командой криптографов мирового класса. Создание собственного алгоритма – тем более. - person ntoskrnl; 19.08.2013
comment
Хотя в целом это правильно, я полагаю, что вы, возможно, упустили из виду точку зрения ОП: по его собственным словам, «RijndaelManaged со 128-битными ключами является излишним» для его конкретных нужд. Дискуссия не о том, какой метод более безопасен, ему нужен разумный баланс между шифрованием и производительностью. - person OnoSendai; 19.08.2013
comment
Проблема в том, что сделать что-то нестандартное будет сложнее и потребует больше работы, чем работа со стандартами. Также обратите внимание, что ИТ-безопасность — это бинарная вещь: безопасность либо есть, либо ее нет. Ложное чувство безопасности хуже, чем отсутствие безопасности. - person ntoskrnl; 19.08.2013
comment
Я могу немного согласиться с вами по первой теме. С другой стороны, хорошо демистифицировать криптографию; Это инструмент, доступны инструменты разных размеров, и вы даже можете сами стать мастером, если достаточно понимаете, чего хотите. Но я полностью согласен с ИТ-безопасностью, и я бы даже дополнил это, сказав, что это бинарная константа, установленная в false: НЕТ безопасной системы - что бы кто-то ни создал, кто-то другой может сломать, имея достаточно времени и ресурсов. Тем не менее, существуют приемлемые промежуточные уровни безопасности, которые могут удовлетворить ваши потребности. - person OnoSendai; 20.08.2013
comment
Невозможно нарушить (правильно реализованные) стандарты, такие как PGP или TLS, пока закрытые ключи остаются закрытыми. Вы можете подумать о грубой силе, но это не считается жизнеспособной атакой, поскольку мы говорим о миллиардах лет времени с достаточной длиной ключа. И я все еще думаю, что безопасность - это логическое значение. Промежуточные уровни безопасности — это почти всегда просто запутывание. - person ntoskrnl; 20.08.2013
comment
Должен признаться, что я больше думал о линии боковых атак — части «до тех пор, пока». Но похоже, что АНБ может не согласиться с вами в логической части. Цитируя статью в Википедии для AES, раздел «Безопасность»: «Конструкция и надежность всех длин ключей алгоритма AES (т. е. 128, 192 и 256) достаточны для защиты секретной информации до уровня СЕКРЕТ». СОВЕРШЕННО СЕКРЕТНО информация потребует использования ключей длиной 192 или 256». Так что да, похоже, они следуют по крайней мере шаблону откусывания. Но не поймите меня неправильно - я во многом с вами согласен. - person OnoSendai; 20.08.2013