Hay tres casos que quizás quieras considerar:
- Desea utilizar TCP como el protocolo de transporte subyacente y puede permitirse la criptografía de clave pública.
- Desea utilizar TCP como el protocolo de transporte subyacente, pero no puede permitirse la criptografía de clave pública (porque sería demasiado lento, se aplica principalmente a los dispositivos IoT)
- Desea utilizar TCP, pero desea seguridad en un nivel inferior.
Ahora los dos primeros escenarios tienen la misma respuesta: desea utilizar Seguridad de la capa de transporte (TLS) v1.2 o más reciente (tan pronto como v1.3 se estandarice).
TLS ofrece múltiples ciphersuites , que definen qué métodos usar para el intercambio de claves, para la autenticación, para el cifrado buld y para la derivación de secretos compartidos.
La configuración general que desea utilizar es TLS-PSK en los dos primeros escenarios.
El conjunto de cifrado de elección es TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256
siempre que no haya TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
(que puede estar estandarizado pronto ). Esto solo usará claves previamente compartidas para la autenticación y ECDH para el acuerdo de claves, lo que le otorga claves diferentes para cada conexión (lo que es bueno).
En el segundo escenario, el conjunto de cifrado de elección es TLS_PSK_WITH_AES_128_GCM_SHA256
, lo que le brinda un moderno conjunto de cifrado. El inconveniente es que las claves no se negocian por separado, lo que significa que si alguna vez pierde el maestro-secreto, todas las conexiones (futuras y pasadas) se verán comprometidas, lo que no sería el caso con el escenario 1.
El último escenario es un poco más complicado y le sugiero encarecidamente que se limite a TLS.
Sin embargo, si no puede usar TLS (que está ampliamente disponible), debe usar IPsec , que también ofrece autenticación PSK. Esto asegurará la conexión a nivel de IP.