Esto no se me había ocurrido, y me parece muy interesante, emplear un diccionario de palabras y por frase almacenar el código de cada palabra.
Las frases, viene a tener unas 20 palabras máximo. Con tú sistema, el espacio ocupado podría ser 4 veces menor por frase, creo que lo haré así.
Con 255 palabras, creo que habrá suficiente, además muchas palabras se repiten constantemente, en las frases, ya que la temática está muy restringida.
Por cierto alguien me puede recomendar un buen libro de VC++ ? Tengo los de VB de Ceballos, que me parecen bastante buenos, y pensaba comprar el de VC++ del mismo autor.
"KT88" schreef in bericht news: snipped-for-privacy@uni-berlin.de...
mensajes
fabricantes),
tiempo
protegeras
contenido
Hombre claro que lo se! y es justamente por eso que no le veo mucho sentido encriptar el contenido. Si hablas de una serial eprom entonces tendras seguro un micro (controlador o procesador) que leera en contenido. DOS partes entonces, memoria de datos
micro con programa.
Para clonar un aparato con un micro es necesario leer el programa. Logrando esto ya se podria clonar el aparato. Pues no es ningun misterio leer una memoria con I2C. y que importa si los datos estan encriptados? total ya esta copiado el programa que los interpreta.
Pero solo fue un comentario.
Que parezca lo que tu quieras que parezca pero es verdad. Veo que no entendiste mi opinion.
sin
para
"volcase la Flash" ¿te refieres a copiar el programa del micro? Si alguien lograra hacer eso te repito no necesitaria desencriptar la memoria, con solo copiarla asi como esta seria suficiente.
Que verguenza. Estos chicos de ARROW quieren hacerse millonarios solo con venderte esos micros a ti.. y eso no puede ser.
Vas a tener muchos problemas con el algoritmo de cifrado si lo haces así, a menos que emplees un cifrado extremedamente simple (débil por tanto).
Lo mínimo que se le puede pedir a un cifrado para eso es que no cifre siempre igual el mismo caracter, por ejemplo que la U no la convierta siempre en 0x12, porque si lo haces así cuando alguien tenga dos frases podrá descifrar el resto sin mucho esfuerzo.
Para que eso no ocurra tu sistema de cifrado debe depender de la posición del caracter en la frase (por ejemplo). Si usas un diccionario (listado de palabras) cada palabra deberá cifrarse igual para todas las frases que la empleen, ocupe el lugar que ocupe.
Se puede idear un algoritmo que sea medianamente seguro, claro, pero no será fácil.
Saludos.
--
·········································································
·· Reinoso G. EA4BAO r einoso.bao@wanadoo.e s ··
·· http://perso.wanadoo.es/reinoso.bao ··
·········································································
Bueno, no necesariamente, ¿ y si a cada palabra, según su posición en la frase le aplico un algoritmo distinto ?
Es decir a todas las palabras, que ocupen la posición 1 en la frase les aplico un algoritmo, a las que ocupen la posicion 2, otro algoritmo etc..etc...
De esa manera la misma palabra, según la posición que ocupe en la frase, tendrá una encriptación diferente, y no se repetirá. Además el diccionario, también estará encriptado, o mejor aún, podría estar en el programa en vez de en memoria externa, con lo que aún en el supuesto (dificil) de descifrar el algoritmo, empleado en las frases ,solo obtendrías números.
Tampoco voy a montar la obra del escorial, quien tenga medios, para descubrir los algoritmos, seguro que tiene más medios para realizar su propio desarrollo, en algo, que con la documentación adecuada, no es muy complejo.
Lo que no quiero es que 4 espabilaos analfabetos, me fusilen los textos y monten algo similar, sin despeinarse el tupe, que hay por ahí, suelto, mucho crío sanguijuela.
Eso es un algoritmo basado en sustitución, la única forma que sea algo seguro es usar una clave oculta aleatoria y de la misma longitud que el texto a cifrar. En esta aplicación creo que no es lo más adecuado dada la memoria limitada que se dispone. Si en el algoritmo mezclamos sustitución con traslación, mejoramos la seguridad en el sentido que cada carácter que se pretende encriptar tiene efecto en múltiples caracteres en la salida. Por este camino ya nos iríamos a implementar el DES o el AES, que son algoritmos considerados seguros. Quizá valdría la pena prestar atención al LFSR por adaptarse mejor a entornos con pocos recursos.
La forma habitual de romper una encriptación en un sistema de clave privada es un ataque de fuerza bruta. Habrá que probar de media, la mitad de todas las posibles claves, o sea que con una clave lo suficientemente grande puede considerarse seguro. Por otro lado la forma de determinar si una clave es la correcta es desencriptar y ver si la salida es algo con el formato que se esperaba, si encriptamos texto directamente ponemos las cosas fáciles al atacante, si en vez de texto encriptamos las entradas al diccionario de palabras, puede que ya no sea tan inmediato romperlo si el atacante no conoce como está estructurada la cosa. Eso sí, las palabras de texto en claro es mejor pasarlas por algún tipo de proceso que las "oscurezca" de manera que el atacante no pueda discernir texto en claro si hace un ataque. Todo esto asume que el algoritmo de desencriptar es conocido por el atacante. Si le añadimos que el algoritmo y la estructura utilizada por los datos estarán ocultas en el código del PIC, creo que un atacante lo tiene bastante difícil. Quizá se podría utilizar una versión modificada del DES o LFSR.
Tal como yo lo entiendo, lo que quieres encriptar (o codificar, o enmascarar, o como querais llamarle) son las palabras del "diccionario" que implementarás en la EEPROM externa. Si es así, no puedes codificarlas de diferente manera según la posición que ocuparán en cada frase, porque así las estarás repitiendo tantas veces como el número de frases en el que aparece cada palabra, con lo que no sólo no ahorrarás espacio de EEPROM, sino que lo incrementarás aún más. Y (de ahí que me haya liado) si las encriptas en el firmware de tu producto según la posición en la frase donde las vayas a utilizar, estarás perdiendo de vista tu objetivo que era mantener a prueba de espías las tablas de errores, porque las leerá de la EEPROM sin encriptar y las encriptará por programa en tiempo de ejecución (de que te serviría eso?)
Yo creo que esta es la mejor solución, si el diccionario te cabe en el PIC. Así solo te tienes que preocupar de encriptar los punteros a palabras, como no son texto claro y el atacante no conoce el funcionamiento interno del sistema, no va a poder sacar nada ni con un ataque a fuerza bruta ni con un análisis frecuencial. Luego para encriptar el contenido de la memoria puedes utilizar un algoritmo de sustitución y trasposición (como el DES, aunque quizá haya otro más simple que también sea lo bastante bueno para esto), y como clave algo aleatorio que guardas en el PIC, por ejemplo el checksum de la frase original que de paso te sirve para verificar la integridad de los datos.
Uhis... XDDDDDDDDDDDD Franois malo Franois malo.. XDDDDDDDDDDDDDDD WAITING THREAT DE LA OSTIAAAAAA!
-- "Por cierto, de sobra es conocido que no hay quien entienda lo que escriben los médicos a mano, pero resulta curioso comprobar que tampoco se les entiende al escribir a máquina." J. M. García
Saludos.
formatting link
El monstruito toma "forma", f*ck it...
snipped-for-privacy@ozu.es Spam-Mail
"Franois" escribió en el mensaje news: snipped-for-privacy@uni-berlin.de...
-- "Por cierto, de sobra es conocido que no hay quien entienda lo que escriben los médicos a mano, pero resulta curioso comprobar que tampoco se les entiende al escribir a máquina." J. M. García
Saludos.
formatting link
El monstruito toma "forma", f*ck it...
snipped-for-privacy@ozu.es Spam-Mail
"Cris" escribió en el mensaje news: snipped-for-privacy@uni-berl>
El dia del senyor de Dissabte 03 Juliol 2004 20:49, al grup de news es.ciencia.electronica, en Reinoso G. va escriure:
Análisis criptográfico del sistema:
Tenemos una conjunto de dos elementos, uno es una memoria con mensajes, el otro es un desencriptador realizado con un uC que lee la memoria y te entrega el mensaje.
No sabemos como está realizado el programa del uC.
Fases para obtener el algoritmo:
1º Leer la memoria y hacer una copia
2º Obtener algunos mensajes del sistema haciendo funcionar el programa mientras el programa lo hace, se monitorizan las comunicaciones con la memoria para observar que bytes se leen de la misma.
3º Modificar algunos bytes de la memoria de los que se leerán, y obtener el resultado.
4º Repetir 3º hasta obtener un mapa completo de como funciona el algoritmo de desencriptado.
5º Implementar el algoritmo en un uC nuevo, procediendo a la lectura directa de toda la memoria.
Para que no se pueda obtener el mensaje de la memoria debes de asegurarte de que el paso 3 no se pueda repetir. Si utilizas un uC con flash, puedes comprobar un checksum de los mensajes, o de toda la memoria ( un CRC32 por ejemplo), y al tercer error de lectura borrar el programa del uC.
Seria también recomendable que leyeses TODA la memoria secuencialmente en cada generación de mensaje, para no indicar la manera en que se encuentran situados en la memoria. De paso puedes calcular el crc32, y obtener los datos del mensaje.
Puedes tener un mapa de bytes aleatorios en la rom, de manera que sean la plantilla para desencriptar la memoria, con un xor o con una suma, así aplicas un nivel secundario de seguridad al encriptar mediante una clave que no es accesible desde el exterior. Una clave de 512 bytes seria adecuada. *No* utilizes el código del programa como clave, ya que expones el programa y los datos.
Aun así, siempre pueden coger el sistema, tal y como está, y empezar a darle todos los códigos de error, uno tras otro, hasta que el propio sistema les haya entregado todos los mensajes. Lento pero seguro.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.