Una dirección generada criptográficamente ( CGA ) es una dirección del 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 seguros (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 debe 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 de CGA, forman un conjunto de parámetros denominado estructura de datos de parámetros de CGA. Se debe conocer el conjunto completo de parámetros de CGA para poder verificar el CGA correspondiente.
La estructura de datos de los parámetros CGA consta de:
modifier:un entero aleatorio sin signo de 128 bits ;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 . Se trata de un entero sin signo de 3 bits que puede tener cualquier valor desde 0 hasta 7 (incluido) 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 se tarda generalmente en generar un CGA. Para mayor comodidad, 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 de CGA, que se utiliza para crear una nueva dirección generada criptográficamente.
1 procedimiento generateCGA( Sec , subnetPrefix , publicKey , extFields ): 2 modificador := aleatorio(0x0000000000000000000000000000000000, // 16 octetos (128 bits) 3 0xffffffffffffffffffffffffffffffff) 4 5 etiqueta1 : 6 concat := concatenar( modificador , 0x000000000000000000, // 9 octetos cero 7 clave pública , campos externos ) 8 9 resumen := SHA1( concat )10 Hash2 := digest [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 fin si1617 collCount := 0x00 // Recuento de colisiones de 8 bits1819 etiqueta2 :20 concat := concatenar( modificador , prefijoDeSubred , conteoDeColl ,21 clave pública , campos externos )2223 resumen := SHA1( concat )24 Hash1 := digest [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 los bits Sec y u/g2829 CGA := concatenate( subnetPrefix , intID ) // concatenar para formar el CGA3031 si está duplicado ( CGA ):32 recuentoDeColls := recuentoDeColls + 13334 si collCount = 3:35 abortar 36 finalizar si3738 ir a etiqueta239 fin si4041 devuelve [ CGA , [ modificador , prefijoDeSubred , collCount , clavePublica , camposExt ]]42 procedimiento final
El identificador de interfaz de CGA está formado en gran parte por Hash1, que se toma de los primeros 64 bits de la estructura de datos de parámetros de CGA (líneas 20 a 24). En la línea 27, los primeros tres bits se sobrescriben con el Secvalor y los bits "u" y "g" reservados (el séptimo y octavo bit) se establecen en 0.
El Secparámetro implementa una extensión de hash al hacer 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 con subnetPrefixy collCountesencialmente configurados en 0. Se realiza una búsqueda de fuerza bruta para encontrar un Hash2, incrementando el modifieren 1 en cada iteración (líneas 6 a 15). Debido a que más bits deben ser 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 duplicadascollCount . Si la dirección ya está en uso, entonces el contador de colisiones se incrementa en 1 y se genera un nuevo identificador de interfaz (líneas 20 a 39). Debido a que collCountno se utiliza para calcular Hash2, no es necesario buscar uno nuevo Hash2cuando ocurre una colisión de direcciones. Por una razón similar, subnetPrefixtampoco se utiliza 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 uno nuevo 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 le ha asignado esa dirección. Esto se hace verificando que el par de claves utilizado para la firma se ha vinculado a la CGA. Debido a que 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 que el host mismo se autentique, entonces la CGA en sí debe autenticarse de antemano, ya que no se puede confiar en la clave pública vinculada si la dirección no es confiable en tal caso (suponiendo que no se haya verificado por otros métodos que no sean CGA).
El método de verificación CGA, en el que se verifica que una clave pública esté vinculada a una 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 , prefijoDeSubred , collCount , clavePublica , camposExt ]): 2 si collCount > 2 o CGA [0:8] ≠ subnetPrefix : 3 devuelve falso 4. Fin si 5 6 concat := concatenar( modificador , prefijoDeSubred , conteoDeColecciones , 7 clave pública , campos externos ) 8 9 resumen := SHA1( concat )10 Hash1 := digest [0:8] // 8*8 = 64 bits más a la izquierda11 Hash1 [0] := Hash1 [0] binario y 0x1c // ignora 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 // ignora los bits Sec y u/g1516 si Hash1 ≠ intID :17 devuelve falso18 fin si1920 Sec := CGA [8] >> 5 // extrae Sec del identificador de interfaz2122 concat := concatenar( modificador , 0x000000000000000000, // 9 octetos cero23 clave pública , campos externos )2425 resumen := SHA1( concat )26 Hash2 := digest [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 fin si3132 devuelve verdadero // verificación exitosa33 procedimiento final
El método comienza verificando si collCountla estructura de datos de parámetros de CGA contiene 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 parámetros de CGA (que incluye la clave pública y el prefijo de subred) y se comparan los bits relevantes con los del identificador de interfaz de CGA. En este caso, esto se hace configurando los primeros tres bits ( Sec) y el séptimo y octavo bit (bits "u" y "g") de ambos Hash1y del identificador de interfaz a 0 en las líneas 11 y 14 para facilitar la comparación.
Después de extraer Secel identificador de la interfaz de la CGA, Hash2se calculan los primeros 16 Secbits del hash y se comparan con 0 (líneas 22 a 30). Si todas las comprobaciones resultan bien, se ha verificado que la clave pública está vinculada a (es decir, que es válida para) esa CGA.
Para que un atacante haga creer a un cliente que recibió un mensaje válido de un CGA determinado que no es de su propiedad, el atacante debe encontrar una colisión de hash para los bits relevantes de Hash1y Hash2mediante la realización de un ataque de fuerza bruta . Si el atacante encuentra un conjunto de parámetros CGA (incluida una clave pública para la que el atacante conoce la clave privada) que se puede utilizar para generar el mismo CGA que el CGA de destino, entonces el atacante puede hacerse pasar por el host que realmente posee el CGA sin ser detectado (excepto quizás cuando el cliente se ha puesto en contacto con el host antes y nota que la clave pública ha cambiado pero el CGA no).
De los 64 bits de Hash1, solo 59 se utilizan en el identificador de interfaz ya que se sobrescriben 5 bits. Para un CGA con 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 mayúscula ). Sin embargo, un valor mayor de , aumenta este costo en un factor de a porque los primeros 16 bits de entonces 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 de CGA sino de la dirección misma, un atacante no puede usar un Secvalor menor que el de la dirección de destino (como 0) en un intento de omitir (o reducir) el ataque de fuerza bruta en Hash2. Esto produciría un CGA diferente del CGA de destino ya que al menos uno de los tres bits más a la izquierda del identificador de interfaz no coincidiría. Si el Secvalor de destino se escribe en el identificador de interfaz de todos modos, entonces Hash2(casi con certeza) se encontrará que falta la cantidad requerida de bits 0 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 este motivo, la cantidad de valores válidos para collCountestá limitada al rango de 0 a 2. Se debe verificar que este parámetro se encuentre en este rango durante el proceso de verificación de CGA para evitar que un atacante lo aproveche y pruebe todos los valores diferentes sin la necesidad de realizar otra búsqueda de fuerza bruta Hash2cada vez que se pruebe un valor diferente.
Al incluir el prefijo de subred en la operación de resumen que da como resultado 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 CGA para las operaciones de resumen, se debe verificar que coincida con el prefijo de subred de la CGA durante el proceso de verificación CGA.
