Dirección generada criptográficamente

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 seguro de vecinos (SEND). ^{[ 2 ]}

Una dirección generada criptográficamente (CGA, por sus siglas en inglés) es una dirección IPv6 cuyo identificador de interfaz se ha generado según el método CGA. El identificador de interfaz se forma con 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 se determina mediante los 64 bits más significativos, que constituyen el prefijo de subred.

Además de la clave pública que se vinculará al CGA, el método de generación de CGA requiere varios parámetros de entrada, incluido el prefijo de subred predefinido. Estos parámetros, junto con otros que se generan durante la ejecución del método de generación de CGA, conforman un conjunto de parámetros denominado estructura de datos de parámetros de CGA . Es necesario conocer el conjunto completo de parámetros de CGA para poder verificar el CGA correspondiente.

La estructura de datos de parámetros CGA consta de:

• modifier: un entero sin signo aleatorio 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 resistencia del CGA frente a ataques de fuerza bruta . Este parámetro es un entero sin signo de 3 bits que puede tener cualquier valor entre 0 y 7 (inclusive) y se codifica en los tres bits más a la izquierda del identificador de interfaz del CGA. Cuanto mayor sea el valor de este parámetro Sec, mayor será el nivel de seguridad, pero también mayor será el tiempo que generalmente se tarda en generar un CGA. Para mayor comodidad, se asume que los Secvalores 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(0x0000000000000000000000000000000, // 16 octetos (128 bits) 3 0xffffffffffffffffffffffffffffffff) 4 5 etiqueta1 : 6 concat := concatenar( modificador , 0x000000000000000000, // 9 octetos cero 7 publicKey , extFields ) 8 9 digest := SHA1( concat ) 10 Hash2 := digest [0:14] // 14*8 = 112 bits más a la izquierda 11 12 si Sec ≠ 0 y Hash2 [0:2* Sec ] ≠ 0: // 2*Sec*8 = 16*Sec bits más a la izquierda 13 modificador := modificador + 1 14 ir a la etiqueta1 15 fin si 16 17 collCount := 0x00 // Contador de colisiones de 8 bits 18 19 etiqueta2 : 20 concat := concatenar( modificador , subnetPrefix , collCount , 21 publicKey , extFields ) 22 23 resumen := SHA1( concatenar ) 24 Hash1 := digest [0:8] // 8*8 = 64 bits más a la izquierda 25 26 intID := Hash1 // Hash1 se convierte en el identificador de la interfaz... 27 intID [0] := intID [0] binario y 0x1c binario o ( Sec << 5) // ...después de escribir Sec y bits u/g 28 29 CGA := concatenar( subnetPrefix , intID ) // concatenar para formar el CGA 30 31 si duplicado( CGA ): 32 collCount := collCount + 1 33 34 si collCount = 3: 35 abortar 36 fin si 37 38 ir a la etiqueta2 39 fin si 40 41 devolver [ CGA , [ modificador , prefijo de subred , recuento de columnas , clave pública , campos externos ] ] 42 procedimiento final

El identificador de interfaz de CGA se forma principalmente a partir de Hash1, que se obtiene de los primeros 64 bits de la estructura de datos de parámetros de CGA procesada (líneas 20 a 24). En la línea 27, los tres primeros bits se sobrescriben con el Secvalor y los bits reservados "u" y "g" (el séptimo y el octavo bit) se establecen en 0.

El Secparámetro implementa una extensión de hash al forzar 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 digeridos con subnetPrefixy collCountesencialmente establecidos a 0. Se realiza una búsqueda por fuerza bruta para encontrar un adecuado Hash2, incrementando modifieren 1 en cada iteración (líneas 6 a 15). Debido a que se necesitan más bits a 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, el contador de colisiones se incrementa en 1 y se genera un nuevo identificador de interfaz (líneas 20 a 39). Como collCountno se utiliza en el cálculo de Hash2, no es necesario buscar un nuevo Hash2cuando ocurre una colisión de direcciones. Por una razón similar, subnetPrefixtampoco se utiliza para 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 Hash2.

En la línea 41 se devuelve el CGA, junto con la estructura de datos de parámetros del CGA.

Una dirección generada criptográficamente (CGA) se utiliza para verificar que los mensajes firmados recibidos fueron enviados por el host al que se le asignó dicha dirección. Esto se logra verificando que el par de claves utilizado para la firma esté vinculado a la CGA. Dado que la autenticidad de la clave pública se puede verificar de esta manera, no se requiere una infraestructura de clave pública . Sin embargo, si se requiere la autenticación del propio host, entonces la CGA debe autenticarse previamente, 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 mediante otros métodos distintos a la CGA).

El método de verificación CGA, en el que se verifica que una clave pública esté vinculada a un CGA, requiere como entrada la estructura de datos de parámetros CGA correspondiente y puede implementarse de la siguiente manera.

1 procedimiento verifyCGA( CGA , [ modificador , prefijo de subred , recuento de columnas , clave pública , campos externos ]): 2 si collCount > 2 o CGA [0:8] ≠ subnetPrefix : 3 devuelve falso 4 fin si 5 6 concat := concatenar( modificador , subnetPrefix , collCount , 7 publicKey , extFields ) 8 9 digest := SHA1( concat ) 10 Hash1 := digest [0:8] // 8*8 = 64 bits más a la izquierda 11 Hash1 [0] := Hash1 [0] binario y 0x1c // ignorar Sec y bits u/g 12 13 intID := CGA [8:16] // identificador de interfaz (64 bits más a la derecha) 14 intID [0] := intID [0] binario y 0x1c // ignorar Sec y bits u/g 15 16 si Hash1 ≠ intID : 17 devuelve falso 18 fin si 19 20 Sec := CGA [8] >> 5 // extraer Sec del identificador de interfaz 21 22 concat := concatenar( modificador , 0x000000000000000000, // 9 octetos cero 23 publicKey , extFields ) 24 25 resumen := SHA1( concatenar ) 26 Hash2 := digest [0:14] // 14*8 = 112 bits más a la izquierda 27 28 si Sec ≠ 0 y Hash2 [0:2* Sec ] ≠ 0: // 2*Sec*8 = 16*Sec bits más a la izquierda 29 devuelve falso 30 fin si 31 32 devuelve verdadero // verificación exitosa 33 procedimiento final

El método comienza comprobando si collCountla estructura de datos de parámetros de CGA tiene un valor válido y si subnetPrefixcoincide con el prefijo de subred de CGA (en la línea 2). Esto se hace por motivos 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 los bits relevantes se comparan con los del identificador de interfaz de CGA. En este caso, esto se hace estableciendo los tres primeros bits ( Sec) y el séptimo y octavo bit (bits "u" y "g") tanto del Hash1identificador de interfaz como de la clave pública a 0 en las líneas 11 y 14 para facilitar la comparación.

Tras extraer Secel identificador de la interfaz de la CGA, Hash2se calcula y los primeros 16 Secbits del hash se comparan con 0 (líneas 22 a 30). Si todas las comprobaciones resultan satisfactorias, se verifica que la clave pública está vinculada a (es decir, es válida para) esa CGA.

Para que un atacante logre que un cliente crea haber recibido un mensaje válido de un CGA que no le pertenece, debe encontrar una colisión de hash para los bits relevantes Hash1mediante Hash2un ataque de fuerza bruta . Si el atacante encuentra un conjunto de parámetros CGA (incluida una clave pública cuya clave privada conoce) que se pueden usar para generar el mismo CGA que el CGA objetivo, entonces puede suplantar la identidad del host que realmente posee el CGA sin ser detectado (excepto quizás si el cliente se ha puesto en contacto con el host anteriormente 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 5 bits se sobrescriben. 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${\displaystyle O(2^{59})}$(en notación O grandeSec ). Sin embargo, un valor mayor de aumenta este costo en un factor de${\displaystyle 2^{16\times Seg}}$a${\displaystyle O(2^{59+16\times Seg})}$porque los primeros 16 Secbits de Hash2entonces se vuelven relevantes (es decir, implementa una extensión de 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 por el mismo factor dependiendo del valor de Sec, pero el costo de usar y verificar un CGA permanece constante.

Dado que Secno forma parte de la estructura de datos de parámetros CGA, sino de la propia dirección, un atacante no puede usar un Secvalor menor que el de la dirección objetivo (como 0) para intentar eludir (o reducir) el ataque de fuerza bruta sobre Hash2. Esto daría como resultado un CGA diferente al 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 interfaz de todos modos, entonces Hash2(casi con seguridad) se encontrará que carece de 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 improbable que se produzcan tres colisiones de direcciones. Si se detectara una dirección duplicada por tercera vez, probablemente se debería a un error de configuración o implementación, o a un ataque de denegación de servicio . Por este motivo, el número de valores válidos collCountse limita al rango de 0 a 2. Este parámetro debe verificarse dentro de este rango durante el proceso de verificación de CGA para evitar que un atacante lo explote y pruebe diferentes valores sin necesidad de realizar una búsqueda por fuerza bruta Hash2cada vez que se pruebe un valor distinto.

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 a una dirección con el mismo identificador de interfaz pero con un prefijo de subred diferente. Dado que la especificación CGA prescribe usar la subnetPrefixestructura de datos de parámetros CGA para las operaciones de resumen, debe verificarse que coincida con el prefijo de subred de la CGA durante el proceso de verificación de la CGA.

• SHA-1