Una dirección generada criptográficamente ( CGA ) es una dirección de protocolo de Internet versión 6 (IPv6) que tiene un identificador de host calculado a partir de una función hash criptográfica . [1] Este procedimiento es un método para vincular una clave de firma pública a una dirección IPv6 en el Protocolo de descubrimiento de vecinos seguro (SEND). [2]
Una dirección generada criptográficamente es una dirección IPv6 cuyo identificador de interfaz se ha generado según el método de generación CGA. El identificador de interfaz está formado por los 64 bits menos significativos de una dirección IPv6 y se utiliza para identificar la interfaz de red del host en su subred. La subred está determinada por los 64 bits más significativos, el prefijo de subred.
Además de la clave pública que se vinculará al CGA, el método de generación de CGA toma varios otros parámetros de entrada, incluido el prefijo de subred predefinido. Estos parámetros, junto con otros parámetros que se generan durante la ejecución del método de generación CGA, forman un conjunto de parámetros denominado estructura de datos de parámetros CGA. Es necesario conocer el conjunto completo de parámetros CGA para poder verificar el CGA correspondiente.
La estructura de datos de los parámetros CGA consta de:
modifier: un entero aleatorio de 128 bits sin signo ;subnetPrefix: el prefijo de 64 bits que define a qué subred pertenece el CGA;collCount: un entero sin signo de 8 bits que debe ser 0, 1 o 2;publicKey: la clave pública como una estructura ASN.1 codificada en DER del tipo SubjectPublicKeyInfo;extFields: un campo opcional de longitud variable (longitud predeterminada 0).Además, un parámetro de seguridad Secdetermina la fortaleza del CGA contra ataques de fuerza bruta . Este es un entero sin signo de 3 bits que puede tener cualquier valor desde 0 hasta (incluido) 7 y está codificado en los tres bits más a la izquierda del identificador de interfaz del CGA. Cuanto mayor sea el valor de Sec, mayor será el nivel de seguridad, pero también más tiempo lleva generar un CGA. Por conveniencia, Secse supone que los valores intermedios en el pseudocódigo siguiente se almacenan como enteros sin signo de 8 bits que no pueden tener un valor mayor que 7.
El siguiente fragmento de pseudocódigo representa el método de generación CGA, que se utiliza para crear una nueva dirección generada criptográficamente.
1 procedimiento generarCGA ( Sec , subnetPrefix , publicKey , extFields ): 2 modificador : = aleatorio (0x00000000000000000000000000000000, // 16 octetos (128 bits) 3 0xffffffffffffffffffffffffffffffff) 4 5 etiqueta1 : 6 concat := concatenar( modificador , 0x000000000000000000, // 9 cero octetos 7 clave pública , campos ext ) 8 9 resumen : = SHA1 ( concat )10 Hash2 := resumen [0:14] // 14*8 = 112 bits más a la izquierda1112 si Sec ≠ 0 y Hash2 [0:2* Sec ] ≠ 0: // 2*Sec*8 = 16*Sec bits más a la izquierda13 modificador : = modificador + 114 ir a etiqueta115 final si1617 collCount := 0x00 // recuento de colisiones de 8 bits1819 etiqueta2 :20 concat := concatenar( modificador , subnetPrefix , collCount ,21 clave pública , campos externos )2223 resumen : = SHA1 ( concat )24 Hash1 := resumen [0:8] // 8*8 = 64 bits más a la izquierda2526 intID := Hash1 // Hash1 se convierte en identificador de interfaz...27 intID [0] := intID [0] binario y 0x1c binario o ( Sec << 5) // ...después de escribir bits Sec y u/g2829 CGA := concatenar( subnetPrefix , intID ) // concatenar para formar el CGA3031 si está duplicado ( CGA ):32 conteo de coll : = conteo de coll + 13334 si collCount = 3:35 abortar 36 terminar si3738 ir a etiqueta239 final si4041 retorno [ CGA , [ modificador , subnetPrefix , collCount , publicKey , extFields ]]42 finalizar el procedimiento
El identificador de interfaz de CGA está formado en gran medida por Hash1, que se toma de los primeros 64 bits de la estructura de datos de parámetros de CGA resumida (líneas 20 a 24). En la línea 27, los primeros tres bits se sobrescriben con el Secvalor y los bits reservados "u" y "g" (el séptimo y octavo bit) se establecen en 0.
El Secparámetro implementa una extensión de hash al hacer cumplir que los primeros 16 Secbits de otro hash, Hash2, sean 0. Este hash es el resultado de la estructura de datos de parámetros CGA digerida subnetPrefixy collCountesencialmente establecida en 0. Se realiza una búsqueda de fuerza bruta para encontrar a adecuado Hash2, incrementando modifieren 1 cada iteración (líneas 6 a 15). Debido a que es necesario que más bits sean 0 con un Secvalor más alto, el tiempo promedio requerido para realizar la búsqueda aumenta exponencialmente con el valor de Sec.
Después de concatenar el prefijo de subred y el identificador de interfaz generado para crear el CGA, se puede realizar la detección de direcciones duplicadas . Si la dirección ya está en uso, el contador de colisiones collCountse incrementa en 1 y se genera un nuevo identificador de interfaz (líneas 20 a 39). Debido a que collCountno se utiliza en el cálculo Hash2, no es necesario buscar una nueva Hash2cuando se produce una colisión de direcciones. Por una razón similar, subnetPrefixtampoco se usa, de modo que si el prefijo de subred de la dirección cambia pero la clave pública del host no, entonces se podría reutilizar el mismo modificador y no hay necesidad de buscar un nuevo archivo Hash2.
En la línea 41 se devuelve el CGA, junto con la estructura de datos de los Parámetros del CGA.
Una dirección generada criptográficamente se utiliza para verificar que los mensajes firmados recibidos fueron enviados por el host al que se asignó esa dirección. Esto se hace verificando que el par de claves utilizado para la firma esté vinculado al CGA. Como la autenticidad de la clave pública se puede verificar de esta manera, no hay necesidad de una infraestructura de clave pública. Sin embargo, si también se requiere autenticar al propio host, entonces el propio CGA debe autenticarse de antemano, ya que no se puede confiar en la clave pública vinculada si en tal caso no se confía en la dirección (suponiendo que no haya sido verificada por otros). métodos que CGA).
El método de verificación CGA, en el que se verifica que una clave pública esté vinculada a un CGA, requiere la estructura de datos de parámetros CGA correspondiente como entrada y se puede implementar de la siguiente manera.
1 procedimiento verificarCGA ( CGA , [ modificador , subnetPrefix , collCount , publicKey , extFields ]): 2 si collCount > 2 o CGA [0:8] ≠ subnetPrefix : 3 retorno falso 4 terminar si 5 6 concat : = concatenar ( modificador , subnetPrefix , collCount , 7 clave pública , campos ext ) 8 9 resumen : = SHA1 ( concat )10 Hash1 := resumen [0:8] // 8*8 = 64 bits más a la izquierda11 Hash1 [0] := Hash1 [0] binario y 0x1c // ignorar los bits Sec y u/g1213 intID := CGA [8:16] // identificador de interfaz (64 bits más a la derecha)14 intID [0] := intID [0] binario y 0x1c // ignorar bits Sec y u/g1516 si Hash1 ≠ intID :17 retorno falso18 final si1920 segundos := CGA [8] >> 5 // extrae segundos del identificador de interfaz2122 concat := concatenar( modificador , 0x000000000000000000, // 9 cero octetos23 clave pública , campos externos )2425 resumen : = SHA1 ( concat )26 Hash2 := resumen [0:14] // 14*8 = 112 bits más a la izquierda2728 si Sec ≠ 0 y Hash2 [0:2* Sec ] ≠ 0: // 2*Sec*8 = 16*Sec bits más a la izquierda29 devuelve falso30 final si3132 devuelve verdadero // verificación exitosa33 finalizar el procedimiento
El método comienza verificando si collCountla estructura de datos de los parámetros de CGA tiene un valor válido y si subnetPrefixla misma estructura de datos coincide con el prefijo de subred de CGA (en la línea 2). Esto se hace por razones de seguridad.
De la línea 6 a la 18, Hash1se calcula a partir de la estructura de datos de los parámetros de CGA (que incluye la clave pública y el prefijo de subred) y los bits relevantes se comparan con los del identificador de interfaz de CGA. En este caso, esto se hace estableciendo los primeros tres bits ( Sec) y el séptimo y octavo bit ("u" y "g") de ambos Hash1y el identificador de interfaz en 0 en las líneas 11 y 14 para facilitar la comparación.
Después de extraer Secel identificador de la interfaz del CGA, Hash2se calcula y los primeros 16 Secbits del hash se comparan con 0 (líneas 22 a 30). Si todas las comprobaciones salen bien, entonces se ha verificado que la clave pública está vinculada a (es decir, que es válida para) ese CGA.
Para que un atacante haga creer a un cliente que recibió un mensaje válido de un determinado CGA que no es propiedad del atacante, el atacante debe encontrar una colisión hash para los bits relevantes Hash1y Hash2realizar un ataque de fuerza bruta . Si el atacante encuentra un conjunto de parámetros CGA (incluida una clave pública cuya clave privada conoce) que puede usarse para generar el mismo CGA que el CGA objetivo, entonces el atacante puede hacerse pasar por el host que realmente posee el CGA sin siendo detectado (excepto quizás cuando el cliente se haya puesto en contacto con el host antes y se dé cuenta de que la clave pública ha cambiado pero el CGA no).
De los 64 bits de Hash1, sólo 59 se utilizan en el identificador de interfaz ya que se sobrescriben 5 bits. Para un CGA Secigual a 0, esto significa que el costo de encontrar un conjunto de parámetros CGA que produzcan los 59 bits deseados es aproximadamente (en notación O grande ). Sin embargo, un valor mayor de , aumenta este costo en un factor de porque los primeros 16 bits de luego se vuelven relevantes (es decir, implementa una extensión hash al exigir que esos bits sean iguales a 0). En el proceso de generación de CGA, el costo de generar una dirección aumenta en el mismo factor dependiendo del valor de , pero el costo de usar y verificar un CGA permanece constante.SecSecHash2Sec
Debido a que Secno es parte de la estructura de datos de los parámetros CGA sino de la dirección misma, un atacante no puede usar un Secvalor menor que el de la dirección objetivo (como 0) en un intento de omitir (o reducir) el ataque de fuerza bruta Hash2. En concreto, esto produciría un CGA diferente del CGA objetivo, ya que al menos uno de los tres bits más a la izquierda del identificador de interfaz no coincidiría. Si el Secvalor objetivo se escribe en el identificador de la interfaz de todos modos, Hash2(casi con seguridad) se descubrirá que falta la cantidad requerida de bits 0 situados más a la izquierda durante el proceso de verificación.
Durante el proceso de generación de CGA, es muy poco probable que se produzcan tres colisiones de direcciones. Si se detecta una dirección duplicada por tercera vez, lo más probable es que se deba a un error de configuración o implementación o a un ataque de denegación de servicio . Por esta razón, el número de valores válidos para collCountestá limitado al rango de 0 a 2. Se debe verificar que este parámetro esté en este rango durante el proceso de verificación CGA para evitar que un atacante lo explote y pruebe todos los valores diferentes sin la necesidad de realizar otra búsqueda de fuerza bruta Hash2cada vez que se intenta un valor diferente.
Al incluir el prefijo de subred en la operación de resumen que resulta en Hash1, se puede evitar que un atacante pueda usar una única base de datos precalculada para atacar direcciones con diferentes prefijos de subred. Un verificador también puede estar seguro de que la clave pública se ha vinculado a esta dirección exacta y no posiblemente a una dirección con el mismo identificador de interfaz pero con un prefijo de subred diferente. Dado que la especificación CGA prescribe el uso de subnetPrefixla estructura de datos de parámetros de CGA para las operaciones de resumen, se debe verificar que coincida con el prefijo de subred de CGA durante el proceso de verificación de CGA.
