Aleatoriedad

Iniciado por Lewert, 3 Junio 2009, 00:28 AM

0 Miembros y 1 Visitante están viendo este tema.

Lewert

Buenas. Ultimamente me ha surgido la duda de cómo se genera el IN_RAND. Sé que es un numero de 128 bits aleatorio, pero he leido que resulta no ser tan aleatorio y eso me pica la curiosidad.
¿Todas las marcas de móviles utilizan la misma función para hacer el random?
A pesar de ser un random de 128 bits deberá seguir un patrón...¿no?
Crack the bytes, crack yourself

SirGraham

Hola,

Depende mas bien del fabricante del Modulo Bleutooth. Eso no lo calcula el Stack de Bluetooth si no lo hace el propio modulo en la capa de seguridad.

Hombre, normalmente la gestion de numeros "seudo-aleatorios" en un sistema embebido (como es un modulo de Bluetooth) se basan en el timer o clock del propio dispositivo. Si que tendran cierta pauta, pero complicado me parece que puedas determinarla de foma clara y ademas para todas las marcas de modulos (un fabricante como Nokia (ejm) usa varias marcas de modulos bluetooth: Murata, Nokia, Texas instruments).

Puede ser una idea, pero es complicada de mirar....

Saludos,
Sir Graham.
   

Lewert

Hola SirGraham. Como siempre tan explicativo ;D

Como bien dices, la IN_RAND se basa en el clock-offset del dispositivo... así que depende del timestamp.
Lo que me interesa por ahora es conocer cómo los módulos bluetooth generan el IN_RAND. ¿Hay alguna forma de llegar a esa información? :( :-\

Saludos maestro :D
Crack the bytes, crack yourself

SirGraham

#3
Hola,

Supongo que la unica forma es desemsamblando el codigo Flash de alguno de ellos. El mas accesible es el de CSR.

Aqui empiezan las pegas: El micro de estos modulos suele ser un RISC bastante rarito. Abria que encontrar un desesamblador que pueda con eso (El IDA disamsambler o algo asi).  

No obstante, asi todo es "complicado".... :-\

Saludos,
Sir Graham.
   

Lewert

Asi que habria que desamblar, mmm... :rolleyes: :rolleyes:
Se me ocurren otras formas de conocer cómo se genera el IN_RAND...
No se a que te refieres con lo del RISK, explicate :-\
Crack the bytes, crack yourself

SirGraham

Hola,

Microprocesador con instrucciones RISC:

http://es.wikipedia.org/wiki/Conjunto_de_instrucciones_reducidas_de_computaci%C3%B3n

Me he equivocado en la ultima letra.  :-[

Ten encuenta que el movimiento y generacion del IN_RAND es dentro del programa. Con un un sniffer bluetooth podrias obtener diferentes combinaciones del mismo (diferentes emparejados), pero el clock si es interno...

Saludos,
Sir Graham.

   

Lewert

Podria analizar los diferentes resultados aunque necestaria muchos datos, mucho esfuerzo y algo de suerte. Por ahora me quedo en la teoría de las ideas que me vienen a la mente y ya las implantaré :P
Sólo una cosa: entre un intento de autenticación y otro, el tiempo de espera aumenta exponenecialmente para evitar ataques replay (espero que me entiendas :P). ¿El tiempo de espera es para todos los dispositivos? Es decir, el M1 intenta conectarse al M2, y fallan... bien, pues M1 tiene que esperar cierto tiempo para intentar conectarse otra vez con M2. ¿Pero si al fallar el M1 intento un M3 conectarse al M2, tambien debe esperar cierto tiempo (a causa del fallo del M1)?

Espero que no haberte mareado mucho :-[
Crack the bytes, crack yourself

SirGraham

#7
Hola,

Entiendo lo que quieres decir. Que yo sepa no.

Esto es por que el dominio de combinaciones de la clave es altisimo 2^128, aunque probaras millones de combinaciones por segundo tardarias siglos en probar todas... (Cosa que ademas por radio no es factible hacer intentos tan rapido)  

:huh:

Para que nos pongamos en situacion. 2^128 combinaciones da un numero mucho mayor que el de granos de arena en una playa ....

:o

Por eso no necesita esperar entre intentos....

Saludos,
Sir Graham.

   

Lewert

#8
Asi que el incremento exponencial del tiempo entre un intento y otro no existe.

Citar
el dominio de combinaciones de la clave es altisimo
¿A que clave te refieres? ¿Al PIN para conectarse a un dispositivo?
Si es así, un simple PIN de 4 digitos es facilmente crackeable en cuestión de segundos (10.000 combinaciones posibles).
Crack the bytes, crack yourself

SirGraham

Hola,

noooo, noo.... el PIN que introduce el usuario solo es semilla para la autentificacion. Aqui lo que cuenta es la clave de autentificacion y esa me temo (por que esta bien echo) es de 2^128 combinaciones (16 bytes de largo).

Mirate todo el esquema de autentificacion del E22 y entenderas lo que quiero decir.

Saludos,
Sir Graham.