Cómo crear una clave de serie (Clave de registro)

Dirijo esta respuesta a lo que se puede lograr de manera realista en un microprocesador PIC.

Generaría un número aleatorio en el PIC, la forma común de hacerlo es usar A2D como generador de ruido y muestrea repetidamente el LSB . Una vez que tenga esto, agregue un dígito de control o dos y muéstrelo al usuario. Los dígitos de verificación le permitirán (en el servidor que recibe el texto) protegerse contra la facturación al usuario por un código mal escrito.

En el servidor, tome el código de los usuarios, quite los dígitos de verificación, ejecútelo a través de un Registro de desplazamiento de comentarios lineales que Se carga previamente con un valor secreto. Cargue al usuario, si el pago se cancela, envíe un mensaje de texto con el código de salida.

Tu chip PIC también necesita conocer el secreto y repite el cálculo. Es posible que desee probar Microchips hardware del generador CRC , por ejemplo. AN1148 muestra cómo usar el hardware LSFR. Carga el secreto, luego registra el desafío aleatorio. Compare esto con lo que el usuario ingresa, un resultado que coincida probablemente significa una compra.

Tendría un modo supervisor si este es un quiosco, en lugar de un solo dispositivo, para permitir la recarga de otro código secreto, o patrón de tomas LFSR, asegurado por el acceso físico y almacenar esto en la NVRAM. De esta manera, al menos puede cambiar la codificación a lo largo del tiempo, o en respuesta a una interrupción. Agregue contadores NVRAM para comparar las compras locales con las aprobaciones del servidor para monitorear el deslizamiento. ¡Sin embargo, ten cuidado con tu nivel de desgaste!

Esto es solo tan "seguro" como su secreto y su técnica de privacidad. Sería relativamente trivial para cualquier persona que pueda volcar una imagen hexadecimal de su máquina para revertir el algoritmo del ensamblador, aunque probablemente cualquier persona con acceso físico tenga técnicas más simples para obtener el producto sin pagar. Del mismo modo, cualquiera que esté dispuesto a adivinar la técnica, comprar un código y otro para validación podría adivinar la técnica y hacer una búsqueda de la fuerza bruta por el secreto.

No creo que la criptografía de clave pública completa sea viable en estas máquinas, por lo que este es un compromiso. Portar OpenSSL no será trivial y consumirá una parte significativa de su tiempo de desarrollador y espacio de código. Si no es un código de lanzamiento de misiles, o si necesita proteger los datos de los usuarios o garantizar los votos en una elección, la criptografía de clave pública probablemente sea más que necesaria para su caso de protección de ingresos. Cavtor emptor.

Utiliza un hash MD5 . Esto creará una clave de 128 bits, por lo que puede representar eso como 32 caracteres hexadecimales. Un hash nunca puede garantizar la singularidad, pero la longitud disminuirá las posibilidades de que coincidan los hashes. Si 32 caracteres hexadecimales son demasiado largos, puede truncarlos a la longitud deseada.

Si necesita una clave de serie única, debe agregar un número único, como el número de cliente, a los datos de usuario con hash, para que no se incluya en el cálculo de hash.

Si un código de registro debe funcionar en un y solo un dispositivo y no en otros, entonces este podría ser un buen uso para la arquitectura de clave pública / privada.

Funciona así: su servidor tendrá una clave pública y una clave privada. La clave privada siempre se mantiene en secreto. La clave pública es visible para cualquier persona que quiera verla (aunque no necesitaremos hacerlo en este caso). Si el servidor cifra algo con su clave privada, entonces solo su clave pública puede descifrarlo. Si alguien más encripta algo con su clave pública, entonces solo el servidor puede descifrarlo con su clave privada.

Esto logra dos cosas

1. Al tener el servidor cifrado ("firmar") algo con su privado Clave, podemos verificar que realmente viene del servidor Descifrando con su clave pública. Podemos autenticar la fuente. del mensaje.

2. Si ciframos algo con su clave pública, solo el servidor alguna vez podemos descifrarlo, por lo tanto podemos enviarle mensajes que nadie más pero el servidor puede leer.

Si tenemos el dispositivo tenemos su propio conjunto de claves públicas y privadas, y una copia de la clave pública del servidor, entonces podemos establecer mensajes entre los dos que nadie más puede leer.

Para que puedas tener un sistema que funcione así:

Lado del servidor, un esquema de base de datos que asigna los números de serie del dispositivo a sus claves públicas. Cuando alguien hace una compra, debe proporcionar este número de serie. Cuando llega una solicitud de compra a través de SMS, el servidor almacena el número de teléfono y busca la clave pública del dispositivo en el número de serie proporcionado. Cuando se encuentre, aparecerá un hash, luego cifrará el número de teléfono SMS mediante la clave pública del dispositivo, luego todo el cifrado se cifrará nuevamente utilizando la clave privada del servidor. Envía esto al usuario a través de SMS.

Cuando el usuario pincha en esta cadena hexadecimal, el dispositivo primero se descifra usando la clave pública del servidor, esto es para asegurar que realmente proviene del servidor. Eso elimina la primera capa. Luego se descifra usando su propia clave privada secreta, esto debería darle el número de hash SMS. Haga que el usuario ingrese su número de teléfono y lo haga. Si los hashes coinciden, entonces proceda.

Si necesita tener sesiones que expiren, incluya una marca de tiempo junto con un número de teléfono antes del cifrado en el lado del servidor y haga que el dispositivo tome la decisión de si esa clave todavía está nueva o no.

Aquí hay una introducción a la arquitectura de clave pública / privada: enlace

Lo que te interesa es:

1. Elegir un método para generar pares de claves públicas / privadas
2. Elegir un método de cifrado para cifrar datos usando estas claves.

Si el sistema tendrá un número de serie que usted genera grabado en un área protegida del espacio de código, simplemente puede programar cada unidad con una clave de activación junto con el número de serie. Esto requeriría que se asegure de mantener un registro de los números de serie emitidos y los códigos de activación asociados, pero si los códigos se generan de forma aleatoria, podría evitar el riesgo de que alguien descubra el algoritmo utilizado para generar las claves. Si no quiere preocuparse por realizar un seguimiento de todas las claves emitidas, puede usar un algoritmo para generarlas, y establecer un atributo de algoritmo diferente para cada lote de dispositivos (podría, por ejemplo, cifrar las claves). para cada lote con un resumen de los números de lotería extraídos para el Lotto del Estado de Nueva York el viernes anterior a la producción del lote. Incluso si sus propios registros fueron destruidos, podría regresar y averiguar cuáles fueron los números, pero es Es poco probable que alguien pudiera realizar ingeniería inversa sobre el hecho de que los números de lotería eran los datos de origen del hash, especialmente porque la cantidad de lotes discretos sería pequeña en comparación con la cantidad de unidades.

Si va a utilizar un número de serie que no está suministrando (por ejemplo, un número de serie del dispositivo grabado en un chip flash), tiene dos opciones principales: hacer que el dispositivo use el número de serie para calcular cuál debe ser la clave, o tiene un software en la fábrica (fuera del dispositivo) munge el número de serie de manera confidencial para obtener una clave que, cuando el dispositivo la munge de cierta manera, proporcionará el número de serie. Este último enfoque tiene la ventaja de que incluso si alguien fuera a aplicar ingeniería inversa al código de validación de la clave en el dispositivo, no podría generar claves que funcionen para números de serie arbitrarios. Sin embargo, tendría la desventaja de que las claves probablemente deberían tener un mínimo de 128 bytes para tener algo parecido a la seguridad (dados los avances actuales en tecnología de CPU, 256 bytes serían mejores). No es un problema si su dispositivo se conectaría a una PC o dispositivo de memoria portátil para fines de activación, pero no tanto si las personas ingresan un código con la ruedecilla.

Puede generar una firma digital a partir del correo electrónico del usuario del usuario y / o el número de teléfono usando OpenSSL libary que tiene criptografía de clave pública funciones que serían adecuadas. Puede ser difícil encontrar espacio para el código de verificación en un chip PIC en cuyo caso un sistema más simple y mucho menos seguro basado en una suma de comprobación / hash en el correo electrónico / número de teléfono puede tener que ser suficiente; en ese caso, asegúrese de salt el correo electrónico / número de teléfono para evitar que los usuarios descubran el algoritmo de suma de comprobación por prueba y error.