¿Hay algún problema grave con este método para generar tokens de un solo uso?

Navega tus respuestas
3

Necesito su consejo sobre la seguridad de este diseño.

Tengo un escenario en el que una aplicación de servidor y una aplicación de tarjeta inteligente necesitan compartir un valor, por ejemplo. 52, que se ha codificado en un token decimal largo pero no hay conexión de red directa entre las dos aplicaciones.

El token tiene 20 dígitos y se transmite por SMS a un destinatario que lo introduce en un terminal, que lo transmite a la tarjeta inteligente.

La pregunta es cuál es la mejor manera de autenticar el token.

Esto es lo que se me ocurrió:

  1. Creamos una clave simétrica única (K) y la almacenamos de forma segura en el servidor y en el elemento seguro de la tarjeta inteligente.
  2. Generamos 10000 números aleatorios de 32 dígitos y los almacenamos de forma segura en el servidor y en el elemento seguro de la tarjeta inteligente.
  3. Para generar un token, el servidor selecciona un índice (n) de los 10000 números aleatorios, por ejemplo, 4821
  4. Asigna su valor (v) a 7 índices separados (x0, x1 ... x6) en el formato base64 de la clave simétrica (K).
  5. Finalmente, crea el token agregando
    • la base 10 forma de los 7 caracteres (K [x0], K [x1] ... K [x6]),
    • el índice (n), y
    • el valor original de dos dígitos, es decir, 52

Por ejemplo, si los 7 caracteres en el paso 5 están representados por "19-24-45-22-34-99-45", entonces el token final será "19-24-45-22-34-99- 45-48-21-52 "

La tarjeta inteligente autentica el token realizando los pasos 3-5 utilizando 4821 como su valor para n, luego comparando su token con el token entrante.

Nota: para evitar las repeticiones, tanto el servidor como la tarjeta inteligente anularán el índice 4821, por lo que el conjunto de caracteres asignados a él no se podrá seleccionar ni usar nuevamente.

Esencialmente, lo que creo que hemos logrado es la capacidad de transferir un token de uso único autenticado de 20 dígitos.

Suponiendo que los datos almacenados en el servidor y en el elemento seguro de la tarjeta inteligente sean seguros, ¿hay algún problema en la armadura que deba conocer?

Cualquier consejo será bienvenido.

Gracias

- - - EDITAR (24 de abril de 2013 14:45 pm GMT) - - -

Debió haber sido un día largo y una noche tarde y después de leer todas las respuestas geniales (es decir, los controles de cordura) a continuación, parece que volví a mis cabales y descarté la idea criptográfica casera mal pensada. :)

Como parte de los antecedentes, esta solución está pensada para ser utilizada en áreas rurales con poca o ninguna cobertura de red 3G o GPRS, y prácticamente todo el mundo tiene teléfonos con características baratas que solo admiten GSM y SMS (a diferencia de los teléfonos inteligentes). ). Además, las redes son muy poco confiables.

De todos modos, esto es lo que tengo ahora:

Configurar

  1. Generar una clave simétrica compartida única (K)
  2. Generar un archivo (S) de TAN (número de autenticación de transacción)
  3. Copie K y S en la base de datos del servidor y en el elemento seguro de la tarjeta inteligente

Transaction

Si un servidor necesita enviar una cantidad (v) a una tarjeta inteligente,

  1. Carga el archivo S y selecciona un nonce (n), es decir, n = S[0]
  2. Anula el nonce al eliminarlo del archivo S (evita los ataques de reproducción)
  3. Crea un mensaje concatenando la cantidad y el nonce, es decir, m = v || n
  4. Crea un texto cifrado (e1), es decir, e1 = H(K,m) donde H="HMAC-SHA-1" o "CBC-MAC-Y", es decir, ISO / IEC 9791-1 Algoritmo 3
  5. Convierte el texto cifrado en base 10 y lo envía (a través de SMS) al teléfono móvil del usuario
  6. Deduce la cantidad del saldo del lado del servidor del usuario

Cuando el usuario 'recibe el código por SMS, escribe la cantidad (v) y el código en el terminal que lo transmite a la aplicación de tarjeta inteligente, que a su vez hace lo siguiente:

  1. Carga el archivo S y selecciona un nonce (n), es decir, n = S[i] donde i = 0
  2. Crea un mensaje al concatenar la cantidad y el nonce, es decir, m = v || n
  3. Crea un texto cifrado (e2), es decir, e2 = H(K,m) , donde H="HMAC-SHA-1" o "CBC-MAC-Y", es decir, ISO / IEC 9791-1 Algoritmo 3
  4. Si es e1 != e2 , repite los pasos (1) - (3) mientras incrementa (i) hasta 20 veces (para permitir la deriva). Si no existe una coincidencia, si aparece un mensaje de error y se cierra
  5. Si es e1 == e2 , acepta el valor como un abono al saldo del lado del cliente del usuario
  6. Finalmente, invalida todos los nonces que se intentaron en el paso (1) al eliminarlos del archivo S

Archivos TAN

Un archivo TAN es una lista de 1000 números aleatorios, cada uno de los cuales es un número de autenticación hexadecimal (TAN) de 8 caracteres. Se utilizará para determinar el valor nonce que se agregará a un mensaje para garantizar su singularidad y evitar así los ataques de repetición.

    
pregunta Niyi 24.04.2013 - 02:55
fuente

2 respuestas

2

No sé las razones detrás de su diseño, pero sugeriría echar un vistazo a HMAC antes de implementar Una solución personalizada. Suponiendo que el servidor y la tarjeta inteligente compartan una clave segura, puede generar un código de autenticación de mensaje para su valor (más un índice incremental, para evitar repeticiones), por lo que tanto la autenticidad como la integridad del mensaje estar asegurado Sin embargo, esto no otorgará ninguna confidencialidad, pero tampoco su método propuesto, por lo que supongo que no es una preocupación en su caso.

Dicho esto, esto es lo que tengo que decir sobre su solución propuesta:

Por lo que entendí, en cada intercambio se expondrán algunas partes de su clave K , ¿verdad? ( K[x0], K[x1], ... ) Después de algunas iteraciones [1], un intruso habrá visto (con una alta probabilidad) todas las partes de su clave, aunque: a) no su orden, ya que los índices ( x0, x1, ... ) serán desconocidos; b) no importará, ya que los números aleatorios de 32 bits son los que hacen que su protocolo sea seguro (ya que nunca se reutilizan, es tan fuerte como una contraseña de un solo uso). Sin embargo, si el secreto de K es importante, sugeriría simplemente enviar el número de 32 bits (con su índice), ya que solo es suficiente para autenticar al remitente.

Además, si bien su protocolo es resistente a los ataques de repetición, el hombre en el medio sigue siendo una posibilidad [2]: suponga que el servidor envía a Alice "19-24-45-22-34-99-45-48 -21-52 "(anulando 4821 ) pero Mallory lo intercepta (por lo que la tarjeta inteligente aún acepta 4821 ). Luego Mallory envía a Alice "19-24-45-22-34-99-45-48-21- 42 ", quien la ingresa al terminal. La tarjeta inteligente lo aceptará con gusto, pero se ingresó el valor de Mallory ( 42 ), no el del servidor ( 52 ), aunque ambos coinciden en que el índice 4821 se usó solo una vez.

[1] ¿Cuántos dependerían del tamaño de K ? Una clave de 128 bits revelaría todas sus partes después de 12 iteraciones con > 97% de probabilidad, y esas partes se pueden volver a combinar con el mismo esfuerzo que con una clave de 65 bits para forzar la aplicación de la fuerza bruta. Una clave de 512 bits OTOH revelaría sus partes después de 50 iteraciones, pero el número de permutaciones necesarias para recombinar la clave es tan grande (más grande que la clave de fuerza bruta) que no importa.

[2] Suponiendo que uno puede realizar ataques MitM en SMS. No tengo suficiente conocimiento sobre este protocolo para decir si puede suceder o no, por lo que jugaría en el lado seguro ...

    
respondido por el mgibsonbr 24.04.2013 - 05:07
fuente
3

Esto es muy MUY bueno para ti y no es una buena idea. ¿Por qué el estándar existente de usar un hash de un cifrado de un valor derivado de marca de tiempo es suficiente para sus necesidades? El primer ataque que viene a la mente es simplemente hacerse pasar por el servidor para obtener códigos de la tarjeta. La víctima no tendría una buena manera de saber que no era el servidor y el servidor no tendría forma de saber que el código se había comprometido. Dado que no está vinculado a una ventana de tiempo en particular, el token podría reutilizarse en cualquier momento en el futuro.

    
respondido por el AJ Henderson 24.04.2013 - 05:04
fuente

Lea otras preguntas en las etiquetas

Cuando los proveedores de teléfonos celulares ofrecen "redes sociales ilimitadas", ¿cómo identifican el tráfico? ¿Cómo usar USB-Stick en lugar de frase de contraseña?