¿Cómo utilizo un ID contable para la autenticación?

Dadas sus premisas, el problema no se puede resolver de la forma que desea. Usted ha dicho que (1) el ID del dispositivo es adivinable, (2) el ID del dispositivo es el único secreto que desea permitirnos usar, (3) que desea autenticar con el ID del dispositivo. Bueno, eso no es solucionable. Si puedo adivinar el ID del dispositivo de Alice, entonces conozco todos los secretos necesarios para disfrazarse de Alicia, y tu sistema no podrá distinguirme de Alicia.

Mencionas algo sobre el cifrado con una clave criptográfica, pero si tuvieras una forma segura de compartir la clave criptográfica solo con Alice (de una manera que me impida aprenderla), simplemente podrías usar esa clave para la autenticación. no necesitarías usar la identificación del dispositivo. Sin embargo, esto está descartado por sus reglas de que no se permite ningún otro secreto. Así que realmente no entiendo lo que está preguntando o cuáles son las restricciones reales aquí.

¿Por qué no nos dice sobre el dominio de la aplicación y lo que está tratando de lograr y por qué cree que la ID del dispositivo es lo único que puede usar para la autenticación? Es posible que podamos encontrar algunos enfoques o soluciones que no se le hayan ocurrido.

Por ejemplo, aquí hay un enfoque que podría considerar. Cuando el dispositivo se registra por primera vez en su servicio, genera un par de llaves público / privado nuevo, único, almacena la clave privada en el dispositivo y envía la clave pública a su servidor central. Puede haber algún procedimiento de registro seguro en el que la clave pública se envíe al servidor central y se registre y asocie con la cuenta de Alice. En el futuro, cuando el usuario quiera sincronizar en una máquina e invocar su API central, el dispositivo puede establecer una conexión segura con su servidor central y autenticarse usando su clave privada (piense en los certificados de cliente y SSL), luego enviar esos API. llamadas La comunicación cifrada se puede enrutar a través de la máquina / escritorio, de modo que no requiere confianza en la máquina / escritorio. La clave privada nunca dejaría el dispositivo. Tenga en cuenta que esto es solo un ejemplo de un posible enfoque: dependiendo de sus requisitos, puede o no cumplir con sus requisitos. Por favor, no se deje atrapar por los detalles de este ejemplo en particular. Más bien, lo que quiero decir es que si tenemos claros sus requisitos y limitaciones, podremos ofrecerle algunas sugerencias sobre la mejor manera de resolver su problema, dentro de las limitaciones que enfrenta.

Si su software se ejecuta en una computadora, en la cual el usuario puede ejecutar software no confiable (por ejemplo, una PC estándar, un teléfono inteligente con raíz), podrá manipular su software .

Puedes usar técnicas anti-depuración, pero eso hace que sea un poco más difícil para el atacante. Hubo una charla muy interesante llamada Aguja de plata en Skype , que explica cómo se analizó Skype, a pesar de su uso de técnicas anti-depuración.

La firma de su software para evitar modificaciones tampoco funciona: el código que verifica la firma se puede modificar reemplazando el salto condicional. Esta es una técnica que se entiende bien durante décadas porque el software copiado de craqueo funciona de la misma manera.

Usted propuso firmar el ID de dispositivo con una clave privada dentro de su software. Hay varios vectores de ataque aquí:

• Un atacante puede extraer la clave privada del software y firmar la suya propia. valor
• Un atacante puede usar un depurador para cambiar la variable, que almacena la identificación del dispositivo después de haberla leído desde el dispositivo y antes de que se entregue a la subrutina, que realiza la firma.
• Un atacante puede manipular el controlador del dispositivo o el kernel, de modo que la llamada del sistema para leer la identificación del dispositivo devuelva otro número.
• ...

TL; DR: No confíes en el cliente.