Hola,
Para hacerlo más dificil, pero no serviría en PICs pequeños por su capacidad, yo implementaría un algoritmo MD5 en el PIC.
Desde el PC le envías una cadena de bytes y el PIC te lo retorna operandolo con una ID que tu definas (tipo "secreto") y en MD5.
En el PC haces el mismo proceso y verificas la palabra retornada.
Claro está que la lectura del PIC ha de estar protegida.
Si tu palabra "secreta" solo la sabes tú, aunque tu código esté disponible, no podrán suplantarlo. A no ser que apliquen ingeniería inversa al software.
Si tu pic solo envía una ID es fácilmente suplantable por otro firm que haga lo mismo y con un simple analizador lógico lo habremos identificado.
Si usas un algoritmo de respuesta basado en operaciones lógicas, sustitución, desplazamientos de una palabra enviada al PIC, se puede romper con fuerza bruta o creando una pequeña red neuronal que "aprenda" y lo acabe rompiendo.
El tema está en el tipo de protección que quieras darle a tu dispositivo.
Puedes proteger el PIC todo lo que quieras, pero por 1500$US hay empresas que te leen el código fuente usando técnicas de laboratorio.
Si simplemente quieres identificar los pics, pues puedes usar una rutina de tipo Acknowledge (PC:"Eres de los mios?" --- PIC:"Si, soy el hDA3FE2"
SI quieres seguridad sin pensar en que te copien el PIC , pues una rutina de encriptación (MD5 está muy bien) o un sistema de clave pública-privada.
Pero ten en cuenta que puedes proteger el PIC, pero si no proteges el sistema con el que se comunica (soft del PC) no has conseguido nada.
Un caso propio:
Hace un par de meses, actualicé una versión de software de un dispositivo que tengo de hace algún tiempo.
El "suministrador" me dice que esta versión, debido a sus nuevas funciones necesita un hardware diferente al que ya tengo (incremento de precio).
Cuando me llega el nuevo hardware, es el mismo de siempre pero incorpora un chip a mayores: un AT88SC02.
Busco en internet y resulta que es una criptomemoria recien salida al mercado de la que casi no hay ni información en Atmel.
Problemas. Necesito hacer varios dispositivos que me funcionen con el soft que he pagado a precio de oro, pero el nuevo soft hace una verificación de un número de serie encriptado en el AT88SC02.
El tío ha estado fino. Ahora si quiero manejar más cacharros, debo pagarle el software completo y el hardware de cada uno.
¿Atacar la criptomemoria?-.... Imposible. No con mis medios.
La solución: Ingeniería inversa en el software.
Analizo y encuentro:
Programa hecho en Delphi sin ningún tipo de empaquetado, no hay ofuscación de código ni nada parecido.
Parece chupado. Un par de vueltas con el Olly y aparece mi serial encriptado.
Me encuentro que al modificar un byte del soft me salta un error de integridad en el programa. Es una rutina de chequeo de CRC.
Busco el salto condicional en el test del byte del CRC y lo modifico.
Hago pruebas con el serial, pero no estoy por la labor de identificar el algoritmo, así que me cargo todos los saltos condicionales en los chequeos del serial.
Es tan mala la protección, que hace la llamada a la rutina de comprobación del serial en cada comando, menú o botón al que se le llama, y como en cualquier compilador, el Delphi crea una especie de macro que se repite en cada rutina muy fácil de localizar e identificar.
Después de un par de horas, el AT88SC02 se ha convertido en un trozo de plástico en la placa.
Finalmente se han gastado recursos en proteger el hardware dejando totalmente desprotegido el software, con lo que la protección no ha servido de nada.
Es algo a tener en cuenta a la hora de proteger. Debemos aplicar los mismos recursos en ambos lados de la comunicación.
De nada sirve poner guardias armados en la puerta principal, si la puerta de servicio está entornada.
Salu2
