Cryptographically Generated Address

A Cryptographically Generated Address (CGA) is an Internet Protocol Version 6 (IPv6) address that has a host identifier computed from a cryptographic hash function. This procedure is a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery Protocol (SEND).

Characteristics
A Cryptographically Generated Address is an IPv6 address whose interface identifier has been generated according to the CGA generation method. The interface identifier is formed by the least-significant 64 bits of an IPv6 address and is used to identify the host's network interface on its subnet. The subnet is determined by the most-significant 64 bits, the subnet prefix.

Apart from the public key that is to be bound to the CGA, the CGA generation method takes several other input parameters including the predefined subnet prefix. These parameters, along with other parameters that are generated during the execution of the CGA generation method, form a set of parameters called the CGA Parameters data structure. The complete set of CGA Parameters has to be known in order to be able to verify the corresponding CGA.

The CGA Parameters data structure consists of:
 * : a random 128-bit unsigned integer;
 * : the 64-bit prefix that defines to which subnet the CGA belongs;
 * : an 8-bit unsigned integer that must be 0, 1, or 2;
 * : the public key as a DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo;
 * : an optional variable-length field (default length 0).

Additionally, a security parameter  determines the CGA's strength against brute-force attacks. This is a 3-bit unsigned integer that can have any value from 0 up to (and including) 7 and is encoded in the three leftmost bits of the CGA's interface identifier. The higher the value of, the higher the level of security, but also the longer it generally takes to generate a CGA. For convenience, the intermediate  values in the pseudocode below are assumed to be stored as 8-bit unsigned integers that cannot have a value greater than 7.

CGA generation method
The following piece of pseudocode represents the CGA generation method, which is used to create a new Cryptographically Generated Address.

1 procedure generateCGA(Sec, subnetPrefix, publicKey, extFields): 2     modifier := random(0x00000000000000000000000000000000,     // 16 octets (128 bits)  3                         0xffffffffffffffffffffffffffffffff) 4 5  label1 : 6     concat := concatenate(modifier, 0x000000000000000000,      // 9 zero octets  7                            publicKey, extFields) 8 9      digest := SHA1(concat) 10     Hash2 := digest[0:14]                                      // 14*8 = 112 leftmost bits 11 12     if Sec ≠ 0 and Hash2[0:2*Sec] ≠ 0:                         // 2*Sec*8 = 16*Sec leftmost bits 13         modifier := modifier + 1 14         goto label1 15     end if 16 17     collCount := 0x00                                          // 8-bit collision count 18 19 label2 : 20     concat := concatenate(modifier, subnetPrefix, collCount, 21                            publicKey, extFields) 22 23     digest := SHA1(concat) 24     Hash1 := digest[0:8]                                       // 8*8 = 64 leftmost bits 25 26     intID := Hash1                                             // Hash1 becomes interface identifier... 27     intID[0] := intID[0] binary and 0x1c binary or (Sec << 5)  // ...after writing Sec and u/g bits 28 29     CGA := concatenate(subnetPrefix, intID)                    // concatenate to form the CGA 30 31     if duplicate(CGA): 32         collCount := collCount + 1 33 34         if collCount = 3: 35             abort 36         end if 37 38         goto label2 39     end if 40 41     return [CGA, [modifier, subnetPrefix, collCount, publicKey, extFields]] 42 end procedure

The CGA's interface identifier is largely formed by, which is taken from the first 64 bits of the digested CGA Parameters data structure (lines 20 to 24). On line 27, the first three bits are overwritten by the  value and the reserved "u" and "g" bits (the seventh and eighth bit) are set to 0.

The  parameter implements a hash extension by enforcing the first 16 times   bits of another hash, , to be 0. This hash is the result of the digested CGA Parameters data structure with  and   essentially set to 0. A brute-force search is performed to find a suitable, incrementing the   by 1 each iteration (lines 6 to 15). Because more bits need to be 0 with a higher  value, the average time required to perform the search increases exponentially with the value of.

After concatenating the subnet prefix and the generated interface identifier to create the CGA, duplicate address detection may be performed. If the address is already in use, then the collision counter  is incremented by 1 and a new interface identifier is generated (lines 20 to 39). Because  is not used in calculating , it is not necessary to search for a new   when an address collision occurs. For a similar reason,  is not used either so that if the subnet prefix of the address changes but the host's public key does not, then the same modifier could be reused and there is no need to search for a new.

On line 41 the CGA is returned, along with the CGA Parameters data structure.

CGA verification method
A Cryptographically Generated Address is used to verify that received signed messages were sent by the host to which that address has been assigned. This is done by verifying that the key pair used for signing has been bound to the CGA. Because the authenticity of the public key can be verified this way, there is no need for a public key infrastructure. If the host itself is required to be authenticated as well, however, then the CGA itself needs to be authenticated beforehand since the bound public key cannot be trusted if the address is not trusted in such a case (assuming it has not been verified by other methods than CGA).

The CGA verification method, in which a public key is verified to be bound to a CGA, requires the corresponding CGA Parameters data structure as input and can be implemented as follows.

1 procedure verifyCGA(CGA, [modifier, subnetPrefix, collCount, publicKey, extFields]): 2     if collCount > 2 or CGA[0:8] ≠ subnetPrefix: 3         return false 4     end if 5 6      concat := concatenate(modifier, subnetPrefix, collCount,  7                            publicKey, extFields) 8 9      digest := SHA1(concat) 10     Hash1 := digest[0:8]                                   // 8*8 = 64 leftmost bits 11     Hash1[0] := Hash1[0] binary and 0x1c                   // ignore Sec and u/g bits 12 13     intID := CGA[8:16]                                     // interface identifier (64 rightmost bits) 14     intID[0] := intID[0] binary and 0x1c                   // ignore Sec and u/g bits 15 16     if Hash1 ≠ intID: 17         return false 18     end if 19 20     Sec := CGA[8] >> 5                                     // extract Sec from interface identifier 21 22     concat := concatenate(modifier, 0x000000000000000000,  // 9 zero octets 23                            publicKey, extFields) 24 25     digest := SHA1(concat) 26     Hash2 := digest[0:14]                                  // 14*8 = 112 leftmost bits 27 28     if Sec ≠ 0 and Hash2[0:2*Sec] ≠ 0:                     // 2*Sec*8 = 16*Sec leftmost bits 29         return false 30     end if 31 32     return true                                            // verification succeeded 33 end procedure

The method starts with checking if  from the CGA Parameters data structure has a valid value and if   from the same data structure matches the CGA's subnet prefix (on line 2). This is done for security reasons.

From line 6 to 18,  is calculated from the CGA Parameters data structure (which includes the public key and the subnet prefix) and the relevant bits are compared to those of the CGA's interface identifier. In this case, this is done by setting the first three bits and the seventh and eighth bit ("u" and "g" bits) of both   and the interface identifier to 0 on lines 11 and 14 for easy comparison.

After extracting  from the CGA's interface identifier,   is calculated and the first 16 times   bits of the hash are compared to 0 (lines 22 to 30). If all checks turn out well, then the public key has been verified to be bound to (i.e. to be valid for) that CGA.

Security
In order for an attacker to make a client believe it received a valid message from a certain CGA that isn't owned by the attacker, the attacker must find a hash collision for the relevant bits of  and   by performing a brute-force attack. If the attacker finds a set of CGA Parameters (including a public key for which the attacker knows the private key) that can be used to generate the same CGA as the target CGA, then the attacker can impersonate the host who actually owns the CGA without being detected (except perhaps when the client has contacted the host before and notices that the public key has changed but the CGA has not).

Of the 64 bits of, only 59 are used in the interface identifier since 5 bits are being overwritten. For a CGA with  equal to 0, this means that the cost of finding a set of CGA Parameters that yield the desired 59 bits is approximately $$O(2^{59})$$ (in big O notation). A larger value of, however, increases this cost by a factor of $$2^{16\times Sec}$$ to $$O(2^{59+16\times Sec})$$ because the first 16 times   bits of   then become relevant (i.e. it implements a hash extension by demanding those bits to be equal to 0). In the CGA generation process, the cost of generating an address is increased by the same factor depending on the value of, but the cost of using and verifying a CGA remains constant.

Because  is not part of the CGA Parameters data structure but of the address itself, an attacker cannot use a   value smaller than that of the target address (like 0) in an attempt to skip (or scale down) the brute-force attack on. This would namely yield a different CGA from the target CGA since at least one of the three leftmost bits of the interface identifier would not match. If the target  value is written to the interface identifier anyway, then   will (almost certainly) be found to lack the required amount of leftmost 0-bits during the verification process.

During the CGA generation process, it is very unlikely that three address collisions occur. If a duplicate address would be detected for the third time, then this would most likely be due to a configuration or implementation error or a denial-of-service attack. For this reason, the number of valid values for  is limited to the range from 0 to 2. This parameter must be verified to be in this range during the CGA verification process in order to prevent an attacker from exploiting it and trying all different values without the need to perform another brute-force search for  each time a different value is tried.

By including the subnet prefix in the digest operation that results in, it can be prevented that an attacker is able to use a single pre-computed database to attack addresses with different subnet prefixes. A verifier can also be sure that the public key has been bound to this exact address and not possibly to an address with the same interface identifier but a different subnet prefix. Since the CGA specification prescribes to use the  from the CGA Parameters data structure for the digest operations, it must be verified that it matches the subnet prefix of the CGA during the CGA verification process.