Usar firmas digitales para identificar a los usuarios

En mi opinión, tus pensamientos van en la dirección correcta, aunque espero poder convencerte de que tomes una ruta ligeramente diferente.

Analicemos sus requisitos:

• Desea garantizar solicitudes autenticadas mutuamente para el procesamiento de pagos, es decir, un cliente que inicie dicho proceso querrá estar seguro de hablar con el servidor correcto, y un servidor que acepte una solicitud desearía estar seguro de la identidad del par Por lo tanto, la solución debe tener autenticación de servidor más autenticación de cliente

• La integridad de las solicitudes es otra obligación: nadie debe tener la oportunidad de alterar nada en la solicitud mientras está en camino

Estos fueron los principales requisitos que enumeró. También agregaría privacidad a la combinación: posiblemente no quiera que nadie que escuche el tráfico pueda aprender lo que el cliente compró o la cantidad de dinero que paga.

Y ahora viene la parte difícil. De hecho, puede lograr estos objetivos con una mezcla de criptografía asimétrica y simétrica. Pero creo que un esquema manual no es apropiado aquí, y aquí están las razones por las que:

• Está intentando asegurar el transporte y la protección es efímera: una vez que se realiza la transacción, ya no necesita conservar los datos de la solicitud (a menos que intente establecer una pista de auditoría)

• Al asegurar el transporte, en realidad está diseñando un protocolo de seguridad aquí. Y corregirlos es probablemente uno de los problemas más difíciles en criptografía. Si leyó sobre el protocolo Needham-Schroeder : fueron muy serios acerca de este protocolo para una pareja De años, convencido de que estaba perfectamente bien. Y tenían todo el derecho de hacerlo, siendo criptógrafos decorados y todo. Pero tres años después, se les presentó un ataque válido ... probablemente sepas a dónde me dirijo y tú mismo ya mencionaste las diversas cosas que tendrías que preocuparte al tratar de hacer esto seguro ...

Pero no todo está perdido, porque hay un protocolo perfectamente bueno que ya hace todo lo anterior y mucho más para ti. ¡Es TLS! Es compatible con todos sus requisitos y ha sido probado por millones, por lo que es muy probable que su solución manual no pueda competir con ella de todos modos. Y en el lado positivo, también es compatible con todos los lenguajes de programación populares, no es necesario que inventes nada.

PS : cuándo usar firmas y cuándo usar TLS: siempre me ha ayudado a analizar mi situación haciéndome esta pregunta: "¿Quieres asegurar el transporte?" vs. "¿Desea proteger los datos / documentos?"

Lo que estás tratando de lograr se llama no repudio (consulta enlace ).

La firma con un certificado de clave privada proporcionará una fuente para el no repudio. La firma digital normalmente se considera personal, por lo que recomendaría que cada persona tenga un certificado separado para la firma digital. Esto también elimina cualquier confusión sobre quién firmó la solicitud, ya que cada persona solo puede firmar por sí misma. Los certificados de firma pueden generarse a partir de una Autoridad de Certificación (CA) interna donde vive el sistema o el usuario lo proporciona una autoridad emisora externa.

En resumen:

  

Bob sabe que Alice envió la solicitud de pago.   Alice no puede negar que envió la solicitud de pago.

Esto se debe a que:

• Alicia envió la solicitud de pago que está grabada (para protegerla contra la manipulación) y luego se codifica con la clave privada de Alicia, creando una firma de la solicitud original. La solicitud contendría los detalles de Alice o la ID de usuario en el sistema. El hash y la firma solo aseguran que no se modifique de ninguna manera.

• Bob tiene la clave pública de Alice (que probablemente estaría almacenada en el sistema) para poder codificar la solicitud original y descifrar la firma de la solicitud. Esto le permite a Bob saber que la solicitud fue enviada por Alice al comparar los dos hashes (porque su nombre está en la solicitud y su clave pública descifra el hash) y la solicitud no se ha modificado.

• Bob puede comparar los campos del certificado para determinar que Alice es de la compañía que dice que es.

Consulte aquí para obtener una referencia visual: enlace

Nota:

• Esto no garantiza que solo Bob y Alice puedan leer la solicitud, eso sería cifrado (ya sea mensaje o transporte).
• Firmar con una clave privada de certificado garantiza que el mensaje no se modifique.
• Los metadatos en la solicitud / mensaje identificarán que Alice envió la solicitud.

Además, si emite desde una CA interna, también podría extender los atributos del certificado para incluir un límite de delegación que a menudo es importante en materia financiera. es decir, el certificado dice que Alice solo puede pedir $ 30,000 o menos.