Простое рукопожатие для зашифрованного сокета - PullRequest
0 голосов
/ 03 августа 2011

Мне нужно защитить сокетное соединение между моим клиентом и сервером. К сожалению, SSL / TLS недоступен на клиентской платформе (, поэтому для тех, кто автоматически отвечает «не ругайте свою собственную безопасность»: не :-)), и мне нужно что-то создать самому , Я придумал эту простую схему (основываясь на моих небольших, вероятно, устаревших знаниях SSL):

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

Насколько я вижу, это безопасно. MITM невозможен, потому что он не может расшифровать сгенерированный ключ. Само клиентское программное обеспечение загружается с веб-сайта HTTPS. Единственный «недостаток» заключается в том, что анализатор по-прежнему может видеть объем и размер отправляемых сообщений, но это не проблема.

Каковы ваши экспертные мнения?

Мне нужно изучить конкретные используемые шифрования (в зависимости от того, что доступно на клиенте), но я предполагаю, что RSA и AES-256 являются безопасным выбором?

Ответы [ 2 ]

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

Да, это основная (упрощенная) идея для SSL.Что касается длины ключа, AES-256 подходит для симметричного, а RSA с 2048 должен подойти в это время.Не уверен, как долго будут работать системы, но вы можете подумать о том, как быстро шифруются (увеличиваются) размеры ключей, которые постоянно нарушаются.Так что это может быть проблемой для вашей идеи жесткого кодирования, вместо того, чтобы оставить это как заданное пользователем.

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

Рассматривали ли вы шифрование эллиптической кривой на асимметричной стороне?Не уверен, что это за клиент, но ECC становится популярным (особенно на мобильных устройствах), поскольку он использует значительно меньшие размеры ключей, чем RSA, и, следовательно, требует меньше ресурсов для обработки.

0 голосов
/ 03 августа 2011

RSA и AES-256 - безопасный выбор, если вы предоставите достаточно длинный ключ.

...