Asegurar las API de máquina a máquina que no son consumidores con cifrado sobre SSL

Es necesario separar la autenticación de la autorización. OAuth 2.0 y OpenID Connect es un sistema para administrar principalmente la autorización, no la autenticación.

HMAC es un método para la firma simétrica. Te da integridad y autenticación parcial, pero no el no repudio.

El cifrado de clave pública es un cifrado asimétrico. Te da confidencialidad. Sin embargo, tenga en cuenta que el cifrado por sí mismo no garantiza la integridad o la autenticación. Para agregar estos aspectos a un sistema de cifrado PKI, se utilizan la firma digital y los certificados. La firma digital también proporciona un no repudio limitado.

Realmente no hay diferencia entre usuarios a máquinas, usuario a usuario o máquinas a máquinas auth. Es menos probable que una comunicación máquina a máquina se queje por los inconvenientes de algunos esquemas, pero las tácticas utilizadas para mitigar los modelos de amenazas específicas son exactamente las mismas.

La mayoría de la autenticación de usuario a máquina utiliza una contraseña. En la máquina a máquina, esto se denomina autenticación de clave precompartida (PSK). TLS se puede configurar para usar TLS-PSK, aunque esta es una configuración relativamente rara.

También se puede utilizar un PSK para crear un código de autenticación de mensaje (MAC). Un MAC afirma que los datos no se han alterado en tránsito. TLS firma los datos con MAC por integridad, o puede agregar HMAC a cualquier mensaje en cualquier protocolo, pero no es un reemplazo para la firma no repudiable.

En algunas configuraciones de seguridad más altas, el sistema puede necesitar un esquema que evite que las solicitudes / documentos se manipulen y evita que el usuario / la máquina deniegue posteriormente la solicitud / documento. Este no repudio es proporcionado por la firma digital. Puede utilizar la firma GPG o S / MIME para esto. Tenga en cuenta que existe una limitación sobre el no rechazo de la firma digital, ya que el firmante solo puede reclamar que su clave privada está comprometida. En muchas situaciones, reclamar un compromiso clave a menudo tiene consecuencias menos graves que admitir haber firmado la solicitud / documento.

Se puede utilizar un cifrado asimétrico siempre que necesite capacidad asimétrica. Por ejemplo, si desea permitir que una máquina pueda escribir en un almacenamiento de datos, pero evitar que dicha máquina lea los datos almacenados en el futuro (o evitar que se comprometa dicha máquina para permitir que el atacante descifre los datos almacenados), entonces Puede utilizar cifrado asimétrico.

En muchos escenarios de sistemas distribuidos, también querría poder probar la secuencia o el tiempo de los eventos. Muchos sistemas utilizan blockchain para probar la secuencia de mensajes. Alternativamente, algunos pueden usar una autoridad de sellado de tiempo. Una cadena de bloques ampliamente distribuida, como la cadena de bloques de bitcoin, también se puede utilizar como una autoridad de sello de tiempo descentralizada.

  

Cualquiera de las opciones estaría sobre TLS con verificación de certificado. ¿Estoy reinventando la rueda aquí? ¿Hay algún estándar comparable de reglas a seguir para este caso de uso?

Su preocupación básica parece ser una contra la que podría protegerse mediante el uso de fijación de teclas , que protegería contra tipo de MITM / spoofing que menciona en su pregunta.

Suponiendo que, por supuesto, está implementado correctamente.

Aunque agregar otra capa de cifrado por el simple hecho de que parezca redundante, puede haber casos en los que pueda estar justificado: debe ver si este es su caso. Por ejemplo, puedo imaginar que puede haber casos en los que desee almacenar algunos datos en su forma cifrada, de modo que solo los consumidores autorizados puedan leerlos.

Eso, sin embargo, no tiene nada que ver con la razón por la que querría usar TLS.

Podría considerar tokens web JSON para algunas de sus necesidades subyacentes dentro de su aplicación. Parecería ser una coincidencia bastante cercana para:

  

un token HMAC en el encabezado de Autorización de la solicitud en el que los detalles de la solicitud están codificados y firmados con una clave que la aplicación cliente recibió una vez