Usar el certificado del cliente para autenticar una aplicación

  

No quiero que las personas le envíen solicitudes aleatorias utilizando wget o algo similar. [...] Cada copia de la aplicación tendrá el (mismo) certificado de cliente incluido.

Ok, esa es una mala idea. No funcionara En resumen: si un valor secreto se copia en más de dos lugares, entonces ya no es un secreto. En ese caso, si algunas personas tienen algún interés en "enviar solicitudes aleatorias usando wget", entonces solo tienen que extraer el certificado y la clave privada de cualquier copia de su aplicación, que es un episodio trivial de ingeniería inversa.

Piénselo: si se ocultara un valor secreto en una aplicación copiada, no habría posibilidad de realizar una extracción de DVD. Los editores de música no lamentarían ni rechinarían la idea de la piratería basada en software. No habría trampas en los juegos en línea.

La frase común utilizada para describir esta situación es: la seguridad aplicada por el cliente no funciona .

Sin embargo, cuida el contexto. Extraer una clave privada de una aplicación compilada que usa esa clave no es difícil; sin embargo , eso no significa que la gente lo hará. La apatía es una de las fuerzas más poderosas en el universo informático. Dicha ingeniería inversa ocurrirá solo si alguien, en algún lugar, se motiva lo suficiente como para invertir un par de horas de su tiempo (como máximo) en esa tarea. Esto puede suceder solo si hay algo que ganar, de hecho, "enviar solicitudes aleatorias con wget" a su servidor.

Muchos sistemas débiles, incluso las aplicaciones que intentan imponer la seguridad del lado del cliente, no pueden ser atacados simplemente porque nadie se molesta en hacerlo.

Su solución con respecto a la autenticación está bien, porque se basa en la autenticación mutua.

En caso de que esté utilizando Apache, se puede lograr fácilmente (después de configurar el material de la clave del cliente y la CA) agregando las siguientes líneas a la configuración:

SSLVerifyClient require

Para proteger el material de su clave en el teléfono móvil, debe guardar sus claves y certificados de forma segura.

En iOS, el llavero sería una ubicación adecuada o, de manera similar, el almacén de claves en Android.

Si una clave se pierde, aún puede ponerla en la lista de revocaciones (CRL).

¡Espera! Recuerde que si desea utilizar el TLS autenticado por el cliente, deberá incluir la clave privada y el certificado. Eso significa que la aplicación incluirá una clave privada y un certificado codificados. Así que aquí hay un par de riesgos que debes considerar:

1) ¿Qué sucede si alguien invierte la ingeniería de su aplicación y extrae la clave privada codificada?

2) ¿Qué sucede cuando caduca el certificado codificado?

La conclusión aquí es que cualquier cosa codificada en el código fuente es una mala idea.

Sería mejor si agregara un elemento de inscripción a su código de registro de usuario que le permita a un nuevo usuario generar el material clave y los certificados requeridos en asociación con su sitio web. La clave privada se debe generar en el dispositivo y el certificado debe estar firmado por su sitio web CA. No debe preocuparse por terceros de confianza, ya que solo su sitio debe confiar en los certificados de CA y de cliente.

También deberá incluir mecanismos para la revocación y la reemisión de nuevas claves, ya que deberá manejar los escenarios de dispositivos perdidos / rotos / robados.

Este enfoque es débil como control de seguridad y no agrega ningún valor de autenticación. Otros comentaristas tienen razón al decir que un actor malintencionado extrae fácilmente un certificado incrustado en una aplicación. SIN EMBARGO, hay una forma segura de hacerlo .

Su objetivo de ocultar la interfaz de la API del servidor detrás de una conexión TLS que requiere autenticación mutua para evitar que sea detectable y potencialmente atacable en toda la red es muy recomendable. Desafortunadamente, la sobrecarga para hacer esto correctamente es demasiado grande para casos de uso que no requieren una seguridad sólida.

El certificado del lado del cliente debe emitirse por usuario . Para hacer esto, debe tener los componentes PKI apropiados frente a Internet o ser contratado por una tercera parte que lo haga. La licencia y la instalación de la aplicación deben incluir un proceso para que el usuario se registre con la CA y reciba un certificado único que luego puede ser almacenado por la aplicación (utilizando un almacén de certificados encriptado del SO u otro medio seguro) y utilizado para la autenticación TLS exactamente como lo hace. Había pensado usar un certificado distribuido en la aplicación.

Además, es posible que deba pensar en la administración de la revocación de certificados, que su servidor web debería verificar como parte de la validación del certificado antes de completar el protocolo de enlace TLS. Por ejemplo, si su cliente está pagando una tarifa mensual por el servicio y usted emite certificados con un vencimiento de 1 año, probablemente debería revocar los certificados de los clientes que ya no reciben su servicio, pero los certificados de quién no han caducado.

Las grandes empresas están utilizando certificados para este y otros fines similares. Pueden hacer frente a las CA y la administración para ellos con bastante facilidad y justificar el costo en muchos casos de uso, incluida la protección de los servicios publicados en Internet de esta manera.