Misplaced Pages

Cryptographically Generated Address

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.

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:

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

Additionally, a security parameter Sec 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 Sec, the higher the level of security, but also the longer it generally takes to generate a CGA. For convenience, the intermediate Sec 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                                      // 14*8 = 112 leftmost bits
11
12      if Sec ≠ 0 and Hash2 ≠ 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                                       // 8*8 = 64 leftmost bits
25
26      intID := Hash1                                             // Hash1 becomes interface identifier...
27      intID := intID 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 ]
42  end procedure

The CGA's interface identifier is largely formed by Hash1, 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 Sec value and the reserved "u" and "g" bits (the seventh and eighth bit) are set to 0.

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

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 collCount is incremented by 1 and a new interface identifier is generated (lines 20 to 39). Because collCount is not used in calculating Hash2, it is not necessary to search for a new Hash2 when an address collision occurs. For a similar reason, subnetPrefix 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 Hash2.

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, ):
 2      if collCount > 2 or CGA ≠ 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                                   // 8*8 = 64 leftmost bits
11      Hash1 := Hash1 binary and 0x1c                   // ignore Sec and u/g bits
12
13      intID := CGA                                     // interface identifier (64 rightmost bits)
14      intID := intID binary and 0x1c                   // ignore Sec and u/g bits
15
16      if Hash1 ≠ intID:
17          return false
18      end if
19
20      Sec := CGA >> 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                                  // 14*8 = 112 leftmost bits
27
28      if Sec ≠ 0 and Hash2 ≠ 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 collCount from the CGA Parameters data structure has a valid value and if subnetPrefix 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, Hash1 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 (Sec) and the seventh and eighth bit ("u" and "g" bits) of both Hash1 and the interface identifier to 0 on lines 11 and 14 for easy comparison.

After extracting Sec from the CGA's interface identifier, Hash2 is calculated and the first 16 times Sec 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 Hash1 and Hash2 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 Hash1, only 59 are used in the interface identifier since 5 bits are being overwritten. For a CGA with Sec 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 ) {\displaystyle O(2^{59})} (in big O notation). A larger value of Sec, however, increases this cost by a factor of 2 16 × S e c {\displaystyle 2^{16\times Sec}} to O ( 2 59 + 16 × S e c ) {\displaystyle O(2^{59+16\times Sec})} because the first 16 times Sec bits of Hash2 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 Sec, but the cost of using and verifying a CGA remains constant.

Because Sec is not part of the CGA Parameters data structure but of the address itself, an attacker cannot use a Sec value smaller than that of the target address (like 0) in an attempt to skip (or scale down) the brute-force attack on Hash2. 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 Sec value is written to the interface identifier anyway, then Hash2 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 collCount 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 Hash2 each time a different value is tried.

By including the subnet prefix in the digest operation that results in Hash1, 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 subnetPrefix 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.

See also

References

  1. RFC 3972, Cryptographically Generated Addresses (CGA), T. Aura (March 2005)
  2. RFC 3971, Secure Neighbor Discovery (SEND), J. Arkko (ed.), J. Kempf, B. Zill, P. Nikander (March 2005)
Categories: