Administración de claves / sistema de almacenamiento

Debes reelaborar todo tu sistema. Es inherentemente mucho menos seguro de lo que debería ser. No hay una buena razón por la que deba almacenar las claves de cifrado que podrían usarse para suplantar sus dispositivos en sus servidores. En su lugar, debe proporcionar a cada dispositivo un certificado firmado (de una CA privada que pueda operar de manera segura usando las mejores prácticas de CA). Esto le confirma que a) cada dispositivo realmente está utilizando un par de claves pública / privada autorizado por usted yb) le permite verificar cada dispositivo desde el certificado público que puede almacenar de forma clara (o incluso ser transmitido por el dispositivo a el inicio de cada conexión y no se almacena en sus servidores en absoluto).

Para hablar con sus servidores, solo necesita tener una clave privada utilizada para todas las comunicaciones y una clave pública utilizada por los dispositivos para verificar su servidor. AES aún se puede usar para las sesiones individuales entre el cliente y el servidor, pero la clave se puede generar sobre la marcha, intercambiarse utilizando el sistema asimétrico y luego descartarse al final de la sesión.

Bajo esta configuración, solo necesitas almacenar de 2 a 4 claves de manera segura en lugar de necesitar una infraestructura completa para administrar las claves cuyo único valor irreemplazable es para los atacantes que intentan comprometer tu sistema.

Actualización: si realmente no puede usar una infraestructura de clave distribuida adecuada, entonces necesitará usar el encadenamiento de claves para minimizar los datos confidenciales. Cifre cada una de las claves con una clave maestra, permitiendo así que se almacenen de forma segura en cualquier lugar. Configure un servidor extremadamente bloqueado con la clave maestra y haga que brinde servicios de cifrado y descifrado para el sistema para que las claves nunca se descifren fuera de ese sistema. Ese sistema básicamente funcionaría como un HSM (si puede obtener un HSM real, eso sería preferible). Las conexiones se enviarían a ese sistema junto con su clave de cifrado cifrada. El sistema descifraría el tráfico y se lo devolvería al solicitante. Además, necesitaría algún tipo de seguridad para autenticar los servicios que realizan las solicitudes del servidor de cifrado / descifrado, aunque las necesidades específicas dependen en gran medida del tipo de seguridad que necesite para los datos en su sitio.

Como lo mencionó AJ Henderson, si necesita usar claves de esta manera, entonces realmente deberían estar almacenadas en un HSM. Si simplemente almacena las claves en un servidor separado, esto no proporciona mucha seguridad adicional, si es que la hay. Si uno de sus servidores está comprometido, debe asumir que sus otros servidores también podrían estar comprometidos, y una vez que esta máquina se haya comprometido, cualquier dato clave puede leerse simplemente desde la unidad o desde la memoria.

Por otro lado, si las claves se almacenaron en un HSM, sería imposible que alguien acceda a los datos clave, incluso si tienen el control completo de todas las máquinas host. Los datos clave no se pueden exportar desde el módulo (al menos, no sin autorización física, dependiendo del tipo de HSM), e incluso el acceso físico al HSM no permitiría leer los datos clave ya que los dispositivos usualmente utilizan algún tipo de la cobertura de los componentes, de manera que cualquier intento de acceder a ellos destruirá el hardware.

Dependiendo del tipo de HSM que use, generalmente proporcionarán una API estándar que puede usar para acceder a las teclas y funciones criptográficas. El más común de estos es PKCS11, que puede usarse desde C # a través de varios envoltorios, aunque también hay CryptoAPI de Microsoft (CAPI), Capi NextGen (CNG), Java JCE, etc.