Una dirección generada criptográficamente ( CGA ) es una dirección IPv6 ( Protocolo de Internet versión 6 ) 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]
Metodología
Una dirección generada criptográficamente se forma reemplazando los 64 bits menos significativos de la dirección IPv6 de 128 bits con el hash criptográfico de la clave pública del propietario de la dirección. Los mensajes están firmados con la clave privada correspondiente. Solo si se conocen la dirección de origen y la clave pública, el verificador puede autenticar el mensaje del remitente correspondiente. Este método no requiere una infraestructura de clave pública . Cualquier remitente, incluido un atacante potencial, puede generar CGA válidos, pero no puede utilizar ningún CGA existente.
Caracteristicas
Una dirección generada criptográficamente es una dirección IPv6 cuyo identificador de interfaz se ha generado de acuerdo con el método de generación de 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.
Formato de dirección IPv6 bits 64 64 campo prefijo de subred identificador de interfaz
Además de la clave pública que se vinculará a la 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 llamado estructura de datos de parámetros de CGA. Se debe 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 sin signo aleatorio de 128 bits ;subnetPrefix
: el prefijo de 64 bits que define a qué subred pertenece la CGA;collCount
: un entero de 8 bits sin signo 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 de longitud variable opcional (longitud predeterminada 0).
Además, un parámetro de seguridad Sec
determina la fuerza de la 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 de la CGA. Cuanto mayor sea el valor de Sec
, mayor será el nivel de seguridad, pero también más tiempo generalmente se tarda en generar una CGA. Por conveniencia, Sec
se 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 superior a 7.
Método de generación de CGA
La siguiente pieza 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 (0x000000000000000000000000000000000000, // 16 octetos (128 bits) 3 0xffffffffffffffffffffffffffffffff) 4 5 etiqueta1 : 6 concat : = concatenar ( modificador , 0x000000000000000000, // 9 cero octetos 7 publicKey , extFields ) 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 label115 finaliza sidieciséis17 collCount : = 0x00 // recuento de colisiones de 8 bits1819 etiqueta2 :20 concat : = concatenar ( modificador , subnetPrefix , collCount ,21 publicKey , extFields )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 : = concatenar ( subnetPrefix , intID ) // concatenar para formar el CGA3031 si está duplicado ( CGA ):32 collCount : = collCount + 13334 si collCount = 3:35 abortar 36 finalizar si3738 ir a label239 terminar si4041 return [ CGA , [ modifier , subnetPrefix , collCount , publicKey , extFields ]]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 digeridos (líneas 20 a 24). En la línea 27, los primeros tres bits se sobrescriben con el Sec
valor y los bits reservados "u" y "g" (el séptimo y octavo bit) se ponen a 0.
El Sec
parámetro implementa una extensión hash haciendo que los primeros 16 Sec
bits de otro hash Hash2
sean 0. Este hash es el resultado de la estructura de datos de los parámetros CGA digeridos con subnetPrefix
y collCount
esencialmente establecido en 0. Se realiza una búsqueda de fuerza bruta para encontrar un adecuado Hash2
, incrementando modifier
en 1 cada iteración (líneas 6 a 15). Debido a que más bits deben ser 0 con un Sec
valor 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 collCount
se incrementa en 1 y se genera un nuevo identificador de interfaz (líneas 20 a 39). Dado collCount
que no se utiliza para calcular Hash2
, no es necesario buscar una nueva Hash2
cuando se produce una colisión de direcciones. Por una razón similar, subnetPrefix
tampoco 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 uno nuevo Hash2
.
En la línea 41 se devuelve el CGA, junto con la estructura de datos de los parámetros de CGA.
Método de verificación 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 firmar se haya 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 se requiere que el host en sí también esté autenticado, entonces la CGA misma debe ser autenticada de antemano, ya que no se puede confiar en la clave pública vinculada si la dirección no es confiable en tal caso (asumiendo que no ha 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 verifyCGA ( CGA , [ modifier , subnetPrefix , collCount , publicKey , extFields ]): 2 si collCount > 2 o CGA [0: 8] ≠ subnetPrefix : 3 devolver falso 4 finaliza si 5 6 concat : = concatenar ( modificador , subnetPrefix , collCount , 7 publicKey , extFields ) 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] binary y 0x1c // ignora los bits Sec y u / g1516 si Hash1 ≠ intID :17 devuelve falso18 terminar si1920 seg : = CGA [8] >> 5 // extraer seg del identificador de interfaz2122 concat : = concatenar ( modificador , 0x000000000000000000, // 9 cero octetos23 publicKey , extFields )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 devolver falso30 finaliza si3132 devuelve verdadero // verificación exitosa33 finalización del procedimiento
El método comienza verificando si collCount
la estructura de datos de los parámetros de CGA tiene un valor válido y si subnetPrefix
de la misma estructura de datos coincide con el prefijo de subred de la CGA (en la línea 2). Esto se hace por razones de seguridad .
De la línea 6 a la 18, Hash1
se 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 (bits "u" y "g") de ambos Hash1
y el identificador de interfaz en 0 en las líneas 11 y 14 para facilitar la comparación.
Después de extraer Sec
del identificador de interfaz de la CGA, Hash2
se calcula y las primeras 16 veces los Sec
bits del hash se comparan con 0 (líneas 22 a 30). Si todas las comprobaciones resultan bien, entonces se ha verificado que la clave pública está vinculada (es decir, que es válida para) esa CGA.
Seguridad
Para que un atacante haga creer a un cliente que recibió un mensaje válido de cierto CGA que no es propiedad del atacante, el atacante debe encontrar una colisión hash para los bits relevantes de Hash1
y Hash2
realizando 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 usar para generar la misma CGA que la CGA objetivo, entonces el atacante puede hacerse pasar por el host que realmente posee la CGA sin siendo detectado (excepto quizás cuando el cliente se ha puesto en contacto con el host antes y se da cuenta de que la clave pública ha cambiado pero la 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 Sec
igual 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 ). Sec
Sin embargo, un valor mayor de aumenta este costo en un factor de a porque las primeras 16 veces los Sec
bits de Hash2
entonces se vuelven relevantes (es decir, implementa una extensión hash exigiendo 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 Sec
, pero el costo de usar y verificar un CGA permanece constante.
Debido a Sec
que no es parte de la estructura de datos de los parámetros de CGA sino de la dirección en sí, un atacante no puede usar un Sec
valor menor que el de la dirección de destino (como 0) en un intento de omitir (o reducir) el ataque de fuerza bruta Hash2
. Es decir, 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 Sec
valor objetivo se escribe en el identificador de interfaz de todos modos, entonces Hash2
(casi con certeza) se encontrará que carece de la cantidad requerida de 0 bits más a la izquierda durante el proceso de verificación.
Durante el proceso de generación de CGA, es muy poco probable que ocurran 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 un ataque de denegación de servicio . Por esta razón, el número de valores válidos para collCount
está limitado al rango de 0 a 2. Este parámetro debe verificarse para estar en este rango durante el proceso de verificación de 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 Hash2
cada vez que se prueba un valor diferente.
Al incluir el prefijo de subred en la operación de resumen resultante 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 subnetPrefix
de la estructura de datos de los parámetros de 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 de la CGA.