¿Se puede asegurar un protocolo mediante encriptación?

Question

Esto es algo que siempre quise aprender. Cuando diseño un sistema (software o hardware) en el que varios componentes se comunican entre sí, ¿cómo puedo implementar un cifrado simple u otras funciones en el protocolo para una seguridad básica?

De todos modos, puedo cambiar el protocolo, ya que tengo acceso de bajo nivel a la serie de bytes que se transmiten / reciben.

Editar: Estoy interesado en la programación integrada, el cifrado simple por cable para la seguridad del protocolo.

Answer 1

Usted dice "seguridad básica" Pero eso no significa mucho. ¿Cuál es tu modelo de amenaza? ¿De qué tipo de ataque estás defendiendo? Si está transmitiendo datos de la tarjeta de crédito, necesitará utilizar un cifrado robusto, como RSA. Pero no puedo pensar en un ejemplo que necesite "menos". proteccion. Si te preocupa que los hackers desarmen tu código, ya se acabó el juego; si es interesante o valioso, lo piratearán. Si no, perdiste el tiempo implementándolo.

Answer 2

La solución más simple, con mucho, es usar un socket SSL en lugar de uno normal, al estilo HTTPS / FTPS.

No hay ninguna diferencia en el protocolo entre HTTP y HTTPS, la única diferencia es que operan en diferentes puertos (80 vs 443 normalmente), y uno usa un socket normal, y el otro usa un socket encriptado SSL.

Answer 3

No implemente el cifrado básico en el sentido de diseñarlo desde cero. Es MUY difícil implementar correctamente el cifrado correctamente.

En cambio, concéntrese en usar el cifrado disponible en su plataforma ... ¿cuál es su plataforma?

EDITAR:

Consulte esta SO post para obtener una lista de cifrado alternativas, algunas de las cuales deberían funcionar bastante bien en un entorno integrado (por ejemplo, CryptoPP y TomCrypt ).

Answer 4

OAuth puede ser interesante para usted, a fin de permitir el control de acceso entre varias API.

Si solo quiere un canal de datos encriptado, es mejor colocar esa capa encima de su protocolo; pasar por SSL o SSH.

Answer 5

Si está haciendo programación incrustada, ¿dónde está el problema del cifrado?

Mientras permanezca en el mismo procesador, por ejemplo, el cifrado es inútil.

Si le preocupan los procesadores en el dispositivo, el cifrado puede ser difícil, ya que un dsp no necesariamente tendrá el espacio libre para cualquier cifrado de cualquier complejidad.

Si quieres rápido, entonces un algoritmo simétrico es tu mejor opción, y hay muchos que puedes hacer que son buenos, como Blowfish o IDEA. Puede almacenar una clave simétrica única, por lo que si pueden desarmar el dispositivo, solo se descubrirá una clave, pero cada dispositivo debe tener su propia clave.

Simplemente ate cada clave al número de serie, de modo que si se está comunicando con un servidor, pase el número de serie con el paquete y el servidor web pueda buscar la clave simétrica correcta y descifrarla rápidamente.

Si quisiera hacer un cifrado de hardware rápido, para mi tesis de MSEE desarrollé una familia de cifrado que usa cálculo de orden arbitrario, lo que sería difícil determinar la clave, ya que puede estar en el circuito de hardware usando microstrip, ya que hay sin procesamiento, se conectaría directamente antes de la antena y todo lo que pasara se cifraría.

Answer 6

Hay muchas cosas a tener en cuenta al diseñar un sistema seguro. Solo por mencionar algunos:

• Elección de esquemas de cifrado simétrico / asimétrico
• Algoritmo de cifrado (AES, Blowfish, DES)
• Elección de protocolos conocidos (por ejemplo, SSL)
• Gestión y distribución de claves
  • Una sola clave maestra (si se piratea, todo el sistema se ve comprometido)
  • Clave por dispositivo (la distribución de claves puede ser más difícil)
  • Protección de los canales de distribución clave
• ¿Tendrá un hacker potencial acceso fácil a los dispositivos de muestra? P.ej. producto de consumo como X-box frente a una caja bloqueada en una central telefónica. Es más difícil protegerse contra la piratería si el hacker tiene acceso físico.
• Factores humanos: ingeniería social, etc.
• Un sistema es tan seguro como su eslabón más débil.

Le sugiero que lea material de Bruce Schneier para empezar.

Answer 7

OAuth es definitivamente una consideración. Además de eso, es posible que desee considerar WS-Security . Al transmitir a través de un servicio web, mantiene todo lo independiente de la plataforma y el lenguaje, y agregar WS-Security significa que el cifrado y el descifrado se encuentran en la capa de la aplicación (de extremo a extremo). Por lo tanto, siempre y cuando confíe en que los mensajes estarán seguros una vez que dejen al remitente, sabrá que permanecerán seguros hasta que el cliente realmente reciba el mensaje (esto significa que el servidor no lo descifrará y ENTONCES pasará al cliente / receptor, pero DESPUÉS de que la aplicación receptora tenga el mensaje).

Entonces, básicamente, OAuth aseguraría / autenticaría las diversas aplicaciones y WS-Security para proteger los mensajes que pasan entre ellas.