Secure network address

Abstract

A computer-implemented method of generating a network address of a network, where the method is performed by an address generator and comprises: generating an interface identifier, where the interface identifier is based on a hash value, where the hash value is based on a hash of at least a modifier value, a subnet prefix, a conflict count value, and a public key; generating a network address based on the subnet prefix and the interface identifier; and generating a signature based on the network address, wherein the private key for generating the signature corresponds to the public key.

Description

Technical Field

[0001] This disclosure relates to generating network addresses, such as IP addresses like IPv6 addresses. Background Technology

[0002] Cryptographic Address Generation (CGA) was introduced as part of the Secure Neighbor Discovery (SEND) protocol to enable nodes to join subnets and generate their own IPv6 addresses locally. The address is bound to the node's public key using a cryptographic one-way hash function. CGA provides nodes with a secure way to prove they are the rightful owners of the advertised IPv6 addresses without relying on any security infrastructure. Its purpose is to prevent spoofing and denial-of-service (DoS) attacks that can occur with protocols such as Neighbor Discovery Protocol (NDP).

[0003] Bos et al., in their 2009 paper "Analysis and Optimization of Encrypted Address Generation" published in Springer Berlin Heidelberg's *Information Security* (pp. 17-32), provided a comprehensive analysis of CGA and pointed out several vulnerabilities. Therefore, they proposed a new technique called CGA++ to address these vulnerabilities. This technique, primarily based on CGA, introduces digital signatures into the address verification process to directly provide authentication functionality. Summary of the Invention

[0004] Introducing digital signatures into CGA++ significantly reduces the security of the underlying CGA technology. To mitigate this problem, this disclosure provides a set of techniques (referred to herein as...) Enhanced CGA++ The aforementioned set of techniques retains the advantages offered by CGA++ while significantly improving its security. This does not introduce additional complexity during address generation or address verification.

[0005] According to one aspect disclosed herein, a computer-implemented method for generating network addresses of a network is provided, wherein the method is performed by an address generator and includes: generating an interface identifier, wherein the interface identifier is based on a hash value, wherein the hash value is based on a hash of at least a modifier value, a subnet prefix, a collision count value, and a public key; generating the network address based on the subnet prefix and the interface identifier; and generating a signature based on the network address, wherein a private key used to generate the signature corresponds to the public key.

[0006] According to another aspect disclosed herein, a computer-implemented method for verifying network addresses is provided, wherein the method is performed by an address verifier and includes: obtaining a candidate network address, a target public key, a candidate modifier value, a candidate signature, and a candidate collision count value, wherein the candidate network address includes a subnet prefix and an interface identifier; verifying the candidate signature using the target public key; generating a candidate interface identifier based on a hash value, wherein the hash value is generated based on a hash of at least the candidate modifier value, the subnet prefix, the candidate collision count value, and the target public key; and verifying whether the candidate interface identifier corresponds to the interface identifier.

[0007] It should be noted that the embodiments of this disclosure can generally be used to generate and verify network addresses, but are not limited to generating and verifying only specific types of network addresses, such as IPv6 addresses. Attached Figure Description

[0008] To aid in understanding embodiments of this disclosure and to show how such embodiments can be implemented, descriptions will now be provided by way of example only, with reference to the accompanying drawings, in which: Figure 1 The format of an IPv6 address is illustrated schematically; Figure 2 The flow of the CGA generation algorithm is illustrated schematically; Figure 3 The flow of the CGA++ generation algorithm is illustrated schematically; Figure 4 A system for generating and verifying network addresses is illustrated schematically; Figure 5 The flowchart of the enhanced CGA++ generation algorithm is illustrated schematically; and Figure 6 The flowchart of the alternative enhanced CGA++ generation algorithm is illustrated schematically. Detailed Implementation

[0009] 1. Relevant Encryption Background 1.1 Encrypted Address Generation (CGA) An IPv6 address is a 128-bit address, where the leftmost 64 bits form the subnet prefix and the rightmost 64 bits form the interface identifier. The subnet prefix is ​​used to determine the host's location in the Internet topology, and the interface identifier is used to identify the host within the subnet. Figure 1 The IPv6 address format is shown.

[0010] Cryptographically generated addresses (CGAs) are IPv6 addresses that generate interface identifiers by applying a cryptographic hash function to a public key and additional auxiliary parameters. A host can then use the associated private key to sign a message, thus proving its ownership of the IPv6 address it is communicating with. Address ownership verification can be performed independently of any security infrastructure; it simply involves verifying the signature and recalculating the binding between the public key and the address.

[0011] CGA is used in the SEND protocol to prevent spoofing and DoS attacks. A spoofing attack occurs when an attacker on the local network manages to impersonate a router advertisement message, causing packets destined for a legitimate host to be redirected to an alternative link-layer address. In a DoS attack, the attacker compromises the DAD protocol by responding to every Duplicate Address Detection (DAD) attempt entering the host. In this way, new legitimate hosts cannot acquire addresses. CGA aims to mitigate these attacks by providing hosts with a way to prove address ownership.

[0012] With technological advancements, it was quickly realized that a 64-bit interface identifier was insufficient to protect the CGA from spoofing attacks. In the CGA, spoofing occurs when an attacker manages to brute-force another valid public / private key that generates the target address. This allows the attacker to mistakenly identify themselves as another host by providing a public key correctly bound to the target address. To mitigate this attack, the CGA incorporates a hash expansion technique in new address generation. This technique requires the host to solve a Proof-of-Work (PoW) puzzle, the difficulty of which depends on parameterizable security parameters. This technique increases the cost of address generation and spoofing attacks by the same factor, but keeps the cost of address usage and verification unchanged.

[0013] Each CGA is associated with a set of auxiliary parameters, called the CGA parameter data structure, as shown in Table 1.

[0014]

[0015] Table 1: CGA Parameter Data Structure The modifier is used during CGA generation to implement hash expansion techniques and enhance privacy by adding randomness to addresses. `collisionCount` can only have values ​​of 0, 1, or 2. It increments during CGA generation to recover from address collisions detected by DAD. `pubKey` is the public key, a DER-encoded ASN.1 structure of type `SubjectPublicKeyInfo` defined in the Internet X.509 certificate configuration file. `extensionFields` are optional variable-length fields that can be used to append data items. By default, its length is 0.

[0016] CGA also has a 3-bit security parameter, sec, encoded in the leftmost three bits of the interface identifier. This parameter determines the strength of CGA's resistance to spoofing attacks. It can have a value from 0 (minimum security) to 7 (maximum security).

[0017] The CGA generation algorithm involves calculating two hash values ​​using a portion of the CGA parameter data structure. Hash1 contains the leftmost 64 bits of the hash digest calculated using the CGA parameter data structure. Hash2 contains the leftmost 112 bits of the hash digest calculated using the CGA parameter data structure (where the subnet prefix and collision count are set to 0).

[0018] Figure 2 The CGA generation algorithm is shown. The bits of the interface identifier are numbered starting from zero on the left. The top part corresponds to the hash expansion technique. It requires the host to solve the cryptographic puzzle by iterating over the modifier values ​​until the leftmost 16×sec bits of Hash2 are equal to zero. It should be noted that if sec=0, this part is skipped. The interface identifier for the address is derived from Hash1 as follows: take the leftmost 64 bits of Hash1, set bits 6 (u, meaning "general") and 7 (g, meaning "personal / group") to zero, and encode the sec parameter in the leftmost 3 bits. When using CGA, the u and g bits are ignored. Setting them to 0 is merely an arbitrary convention.

[0019] Using the subnet prefix as input to Hash1 means that different interface identifiers will be generated from the same public key in different subnets. Therefore, an attacker cannot brute-force all CGAs with the same interface identifier but different subnet prefixes at once.

[0020] The advantage of not using subnet prefixes as input to Hash2 is that it allows mobile hosts to move from one subnet to another, reusing old modifier values ​​to generate new addresses. However, reusing modifier values ​​can make it easier for observers to link two addresses together. This also allows attackers to construct time-memory trade-off attacks, using the addresses of random hosts in the network to obtain any subnet prefix.

[0021] The CGA verification algorithm takes the address and CGA parameter data structure as input, and its working principle is as follows: 1. Check if collisionCount is equal to 0, 1 or 2.

[0022] 2. Check if subnetPrefix is ​​equal to the subnet prefix of the address.

[0023] 3. Calculate Hash1 and check if it equals the interface identifier of the address. Ignore the leftmost three bits and the differences between the u and g bits.

[0024] 4. Calculate Hash2 and check if the leftmost 16×sec bit of the resulting hash value is zero.

[0025] If verification is successful, the binding between the pubKey and the address is verified. The verification algorithm is relatively fast and always requires at most two hash calculations. If sec=0, step 4 can be skipped, and verification only requires one hash calculation.

[0026] The property of the hash functions used to prevent spoofing attacks in Hash1 and Hash2 is called the second anti-spoofing property. The second anti-spoofing property of a hash function H means that, given a message M, it is difficult to find another message M' such that H(M) = H(M'). If a hash function has this property, the only way for an attacker to spoof a CGA is to brute-force it.

[0027] The cost of spoofing an address by brute-forcing the CGA can be calculated as follows. In the 64 bits of Hash1, 5 bits are ignored during CGA verification, corresponding to the sec bit, the u bit, and the g bit. If sec=0, finding a set of CGA parameters to generate the desired CGA requires O(2^35) time. 59 ) times hash function evaluation. The hash expansion technique requires the leftmost 16×sec bits of the Hash2 value to be zero, which takes approximately 2 16×sec The cost of address generation increases exponentially. This also increases the cost of spoofing attacks by the same factor. In other words, spoofing an address via brute force requires O(2^35) time. 59+16×sec ) times hash function evaluation.

[0028] 1.1.1 Limitations This section discusses two types of attacks against the CGA.

[0029] 1.1.1.1 Time-Storage Tradeoff Attack To efficiently generate new addresses when mobile hosts change locations, subnet prefixes are not used as input to Hash2. This weakness can be exploited to build time-to-store tradeoff attacks, using the addresses of random hosts on the network to obtain any subnet prefix.

[0030] To launch this attack, the attacker first generates a valid public / private key pair; this only needs to be done once. For a size of 2... n The attacker created a network with 2 59-n A database of modifier values ​​such that the leftmost 16×sec bits of Hash2 are zero. Creating such a database requires O(2^35) time. 59+16×sec-n The hash function is evaluated 2^(n-1) times. Using this database, the attacker then only needs to call O(2^(n-1)) hash functions. 59-nBy performing a hash function and comparing the hash values, the modifier value that generates the address of a random host in the network can be found. Since the subnet prefix is ​​not used as input to Hash2, the database can be reused for any subnet prefix. In the long run, this attack eliminates the impact of hash expansion techniques because once the database is created, the cost of the attack is independent of the sec parameter.

[0031] For example, if an attacker wants to impersonate someone using a size of 2 with sec=1 16 If the address of a random host in the network is used, then the database will need to construct an O(2) database. 59 The hash function evaluates and occupies approximately 128TB of space, which is enormous but not impractical. Then, the attacker would need O(2^3) time to perform the operation. 43 The hash function is evaluated and compared 2 times to find the appropriate modifier value.

[0032] 1.1.1.2 Replay Attack The purpose of CGA is to cryptographically bind public keys to IPv6 addresses. However, the authentication process in CGA does not provide a mechanism to actually prove that the host controls the public key. This leads to a large number of replay attacks.

[0033] An attacker can obtain a public key belonging to another host and generate a different valid address using a different subnet prefix or modifier. The attacker cannot sign the new message, but can replay the message signed by that host and mislead other hosts by making them believe that the attacker owns the address.

[0034] This type of replay attack can also target addresses that already exist on the network. For a specific security parameter `sec`, an attacker can collect numerous valid modifier values ​​and public keys, along with the signed messages sent by these hosts. After selecting a subnet prefix, the attacker can use the collected modifier values ​​and public keys to search for matches among existing addresses within the subnet and begin replaying the messages.

[0035] Another example of this type of replay attack targeting existing addresses is searching for addresses with a non-zero collisionCount. An attacker can generate an address that already exists on the network using a valid modifier value associated with the target address and a public key, by using a collisionCount equal to zero. However, this type of attack is less likely to occur because the probability of collisions in interface identifiers is low.

[0036] 1.2 Encryption of address++ (CGA++) A new technique called CGA++ is proposed to address the aforementioned limitations. The main difference lies in the introduction of a signature into the calculation of Hash1. Besides ensuring the binding of the public key to the address, CGA++ also directly introduces authentication into address verification. This further reduces the efficiency of address generation, but the reduction is not significant. Furthermore, CGA++ directly includes the subnet prefix in the calculation of Hash2. This eliminates time-store tradeoff attacks suffered by CGA. Simultaneously, it forces the host to repeatedly search for valid modifier values ​​when changing subnets. Therefore, this technique is not suitable for mobile hosts that should complete operations such as handovers within milliseconds.

[0037] The CGA++ generation algorithm takes the subnet prefix (subnetPrefix), the address owner's public / private key, and the security parameter (sec) as input. The algorithm is as follows: Figure 3 As shown, its working principle is as follows: 1. Set the modifier to a random 128-bit value.

[0038] 2. Calculate Hash2 by hashing the concatenation of modifier, subnetPrefix, and pubKey and taking the leftmost 112 bits of the resulting hash value.

[0039] 3. Check if the leftmost 16×sec bit of Hash2 is zero. If it is, proceed to step 4. Otherwise, increment the modifier and return to step 2.

[0040] 4. Set the 8-bit collisionCount to zero.

[0041] 5. Sign modifier, collisionCount, and subnetPrefix using the private key corresponding to pubKey.

[0042] 6. Calculate Hash1 by hashing the concatenation of pubKey and signature and taking the leftmost 64 bits of the resulting hash value.

[0043] 7. The interface identifier is constructed from Hash1 by encoding the value of sec to the leftmost three bits and setting the u and g bits (bits 6 and 7 when starting from 0 on the left) to zero.

[0044] 8. Concatenate the 64-bit subnet prefix and the 64-bit interface identifier to form a 128-bit IPv6 address.

[0045] 9. If necessary, perform DAD. If an address conflict is detected, increment collisionCount and return to step 5. After three conflicts, stop and report an error.

[0046] The CGA++ verification algorithm takes the address, signature, collisionCount, modifier, subnetPrefix, and public key pubKey as inputs, and its working principle is as follows: 1. Check that the signature is correct.

[0047] 2. Check if collisionCount is equal to 0, 1 or 2.

[0048] 3. Check if subnetPrefix is ​​equal to the subnet prefix of the address.

[0049] 4. Calculate Hash2 and check if the leftmost 16×sec bit of the resulting hash value is zero.

[0050] 5. Calculate Hash1 and check if it equals the interface identifier of the address. Ignore the leftmost three bits and the differences between the u and g bits.

[0051] If verification is successful, the binding between the public key and the address is verified. If sec=0, step 4 can be skipped. Compared to CGA, CGA++ performs an additional signature verification in the verification algorithm.

[0052] 1.2.1 Analysis To compare CGA++ with CGA, Bos et al. reported the computational cost of signing messages based on hash function evaluations from the ECRYPT Cryptographic Systems Benchmark (eBACS). The results are shown in Table 2. The hash function used in the benchmark is SHA-1, and the public-key signature scheme is RSA.

[0053]

[0054] Table 2: Signature time represented in the SHA-1 hash function evaluation for different RSA key sizes.

[0055] Table 3 summarizes the comparison between CGA and CGA++. Migrating from CGA to CGA++ reduces the efficiency of address generation and verification. This is because generating and verifying signatures requires additional computation. Furthermore, in sec, the time required to update addresses increases exponentially when migrating to different subnets. Therefore, CGA++ offers improved security compared to CGA. By using the subnet prefix as input to Hash2, global time-to-storage tradeoff attacks are prevented in CGA++. Additionally, an additional authentication mechanism is introduced by directly using the signature in address generation. According to Bos et al., the cost of spoofing attacks becomes 2 in CGA++. 59 (2 16×sec + S gen+ 1) hash function evaluations, where S gen The signature generation time is represented by a hash function evaluation.

[0056]

[0057] Table 3: Comparison of CGA and CGA++ for IPv6 using a 1024-bit RSA key. All timings are represented by hash function evaluations.

[0058] 1.3 BLS Signature The Boneh-Lynn-Shacham (BLS) signature scheme is a digital signature scheme in which the signature is an element of an elliptic curve group, and signature verification uses the bilinear pairing property of the curves.

[0059] BLS depends on a group in which computationally difficult Diffie-Hellman problems are difficult to solve, but decisional Diffie-Hellman problems can be solved efficiently. Such a group is called a gap group.

[0060] Some elliptic curve groups exhibit Weil coupling, making the decisional Diffie-Hellman problem easier to solve. In other words, it can be represented by a generator g and a function e: G×G → G T A group G, where G, G T It is a prime group such that: Given (g, g x ,g y It is difficult to calculate g. xy ; Given (g) z ,g x ,g y ), can obtain e(g x ,g y ) = e(g,g) xy and e(g,g) z ) = e(g,g) z By comparing these two values, we can determine whether xy = z.

[0061] The function e is obtained from the Weil coupling, which can be computed using the Miller algorithm.

[0062] Let e: G×G → G T It is a non-degenerate, efficient, and computable bilinear pairing, where G, G T It is a p-group of prime order. Let g be the generator of G. Let H be a cryptographic hash function such that H:{0,1}*→G.

[0063] Through A random integer is selected from the given data to generate the private key x. The corresponding public key is generated via g. x Provided.

[0064] Given a private key x and a message m, hash m according to h=H(m) and calculate σ=h. x , to calculate signature σ.

[0065] Given a signature σ and a public key g x Verify whether e(σ,g)=e(H(m),g x ).

[0066] 1.4 CGA++ Attack This section demonstrates that the security analysis performed by Bos et al. in the original CGA++ paper was flawed, and describes an efficient spoofing attack against CGA++.

[0067] In the following analysis, all timings are represented by hash function evaluation. Let S... gen This represents the time required to generate a signature whose representation is evaluated using a hash function. Assume S... gen < 2 16 .

[0068] Bos et al. claimed that the cost of spoofing attacks in CGA++ is 2. 59 (S gen +1+2 (16×sec) By providing the ability to cost 2 59 ×(S gen +1)+2 (16×sec) An efficient spoofing attack is executed to prove the claim false. Therefore, in CGA++, the hash expansion technique increases the cost of the spoofing attack by an addition factor of 2. (16×sec) In contrast, CGA adds a multiplication factor. The hash extension technique used to protect CGA is no longer effective in CGA++, making CGA++ more vulnerable to spoofing attacks than CGA.

[0069] This attack exploits the signature used in calculating Hash1 to brute-force existing addresses generated using CGA++. The attacker first searches for modifier values ​​that satisfy the Hash2 condition, at a cost of 2. (16×sec) Next, the attacker calculates Hash1, which has a cost of S. gen +1. As Bos et al. stated, "CGA++ is independent of the signature scheme used." Therefore, if a digital signature algorithm (DSA) is used, for example, an attacker could iterate over the temporary key until the resulting signature produces a Hash1 value that matches the target address. This typically takes 2...59 This is the second attempt. Therefore, the cost of this attack is 2. 59 ×(S gen +1)+2 16×sec In contrast, the attack described by Bos et al. costs 2. 59 (S gen +1+2 16×sec It should be noted that this attack applies to any nondeterministic signature scheme. Therefore, the following auxiliary theorem can be derived: Auxiliary Theorem 1: Given a network, assume that addresses are generated and verified using CGA++ with the security parameter sec. Let S... gen Let S represent the time required to generate a signature that is evaluated using a hash function, and assume S... gen <2 16 Then, the number of hash function evaluations required to impersonate a specific host is T=2. 59 ×S gen +2 16×sec .

[0070] 2. Generate secure network addresses Figure 4 An exemplary system 400 for implementing embodiments of the present disclosure is shown. System 400 includes a generator 401 configured to generate network addresses for a network, a authenticator 402 configured to authenticate network addresses, and one or more users 403 of the network. The generator and authenticator may also be users of the network. The network may be a packet-switched network, such as a wide area network (WAN) like the Internet.

[0071] Each party (generator 401, verifier 402, and network user 403) operates its respective computer equipment. Each party's computer equipment includes a corresponding processing unit, comprising one or more processors, such as one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each party's computer equipment also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. This memory may include one or more memory cells in the form of one or more memory media, such as magnetic media like hard disks, electronic media like SSDs, flash memory, or EEPROMs, and / or optical media like optical disc drives. The memory on each party's computer equipment may store software, including corresponding instances of at least one client application configured to run on the processing unit. It should be understood that any action attributed herein to a given party can be performed by software running on the processing unit of the respective computer equipment. Each party's computer equipment includes at least one user terminal, such as a desktop or laptop computer, tablet, smartphone, or wearable device such as a smartwatch. A given party's computer equipment may also include one or more other network resources, such as cloud computing resources accessed through the user terminal.

[0072] Client applications can initially be provided to any given party's computer device, either by downloading from a server, or by a suitable computer-readable storage medium such as a removable SSD, flash key, removable EEPROM, removable disk drive, floppy disk or tape, optical disc such as a CD or DVD ROM, or a removable optical drive.

[0073] The generator 401 (also referred to as the address generator in this document) is configured to generate an address linked to a public key. This public key may be referred to as the "target public key". The address generator 401 has access to the private key corresponding to the public key. The address generator may possess the private key. The address includes a subnet prefix and an interface identifier. The subnet prefix determines the user's (i.e., the address owner's) location within the internet topology, and the interface identifier serves as the user's identifier within the subnet.

[0074] In the first embodiment, address generator 401 generates a network address by generating a signature based on a modifier value, subnet prefix, and collision count. That is, address generator 401 signs messages that include or are based on a modifier value, subnet prefix, and collision count (not necessarily in that order). The message can be a concatenation of modifier values, subnet prefixes, and collision counts. In some examples, the collision count is set to zero. The modifier value can be randomly chosen. A private key corresponding to the target public key is used to sign the message. Any deterministic signature scheme can be used, such as one of the following deterministic schemes: Boneh-Lynn-Shacham (BLS), Edwards Curve Digital Signature Algorithm (EdDSA), or the deterministic Rivest-Shamir-Adleman (RSA) scheme, such as RSA PKCS1 v1.5.

[0075] Then, address generator 401 hashes the message, which includes or is based on the target public key and signature. The message can be a concatenation of the target public key and signature. The interface identifier is generated based on the resulting hash. For example, the interface identifier can be based on a portion of the resulting hash (e.g., n bits). In some examples, one or more bits of the resulting hash can be modified, for example, to encode security parameters, or to set one or more bits to a specific value (e.g., zero).

[0076] Then, an address is generated based on the subnet prefix and interface identifier (e.g., a concatenation of the two). Address generator 401 can follow... Figure 3 The CGA++ generation algorithm shown is used to generate addresses (e.g., IPv6 addresses), but the signature algorithm is a deterministic signature algorithm.

[0077] Address generator 401 may share addresses with one or more network users 403 and / or verifiers (also known as address verifiers) 402. Address generator 402 may share signatures with address verifier 402.

[0078] From the perspective of address verifier 402, address verifier 402 acquires (e.g., receives from address generator 401) a "candidate address" for the target public key. Here, "candidate" refers to the concept of an address that has not yet been verified as a valid address for the public key. The candidate address includes a subnet prefix and an interface identifier. Address verifier 402 also acquires (e.g., receives) candidate signatures.

[0079] Address verifier 402 verifies whether the candidate signature is a valid signature of the target public key. Address verifier 402 also uses the same method (if the address is valid) used by address generator 401 to generate a candidate interface identifier and checks whether the candidate interface identifier matches the interface identifier of the candidate address.

[0080] In some examples, address verifier 402 can verify whether the signature is based on a collision count, which takes a value from a predetermined set of values ​​(e.g., zero, one, or two).

[0081] Address verifier 402 can obtain candidate modifier values ​​and use them with the target public key and subnet prefix to generate candidate hash values. Address verifier 402 verifies whether the candidate hash value includes the minimum number of leading zeros.

[0082] If address verifier 402 determines that the candidate address is a valid address for the target public key, then the address verifier can use the valid address to send data to that valid address, i.e., to the owner of the target public key (e.g., address generator 401).

[0083] In the second embodiment, address generator 401 first generates a network address and then signs it. Similar to the first embodiment, the address includes a subnet prefix and an interface identifier. The interface identifier is generated by hashing a modifier value, the subnet prefix, a collision count, and the target public key. In some examples, the collision count is set to zero. The modifier value can be randomly chosen. The interface identifier can be based on a portion of the resulting hash (e.g., n bits). In some examples, one or more bits of the resulting hash can be modified, for example, to encode security parameters, or to set one or more bits to a specific value (e.g., zero).

[0084] Then, the address is generated based on the subnet prefix and the interface identifier (e.g., a concatenation of the two).

[0085] The address generator (401) signs the network address using the private key corresponding to the target public key. Any suitable signing scheme can be used.

[0086] Address generator 401 can follow Figure 5 The algorithm shown is used to generate addresses (e.g., IPv6 addresses).

[0087] Address generator 401 may share addresses with one or more network users 403 and / or verifiers (also known as address verifiers) 402. Address generator 402 may share signatures with address verifier 402.

[0088] From the perspective of address verifier 402, address verifier 402 acquires (e.g., receives from address generator 401) a "candidate address" for the target public key. The candidate address includes a subnet prefix and an interface identifier. Address verifier 402 also acquires (e.g., receives) a candidate signature. Address verifier 402 also acquires (e.g., receives) a candidate modifier value and a candidate collision count.

[0089] Address verifier 402 verifies whether the candidate signature is a valid signature of the target public key. That is, address verifier 402 checks whether the candidate signature signs the candidate address. Address verifier 402 also uses the same method (if the address is valid) used by address generator 401 to generate a candidate interface identifier and checks whether the candidate interface identifier matches the interface identifier of the candidate address.

[0090] In some examples, address verifier 402 can verify whether the candidate conflict count used to generate candidate interface identifiers takes a value from a predetermined set of values ​​(e.g., zero, one, or two).

[0091] Address verifier 402 can generate candidate hash values ​​using candidate modifier values, the target public key, and the subnet prefix. Address verifier 402 verifies whether the candidate hash value includes the minimum number of leading zeros.

[0092] If address verifier 402 determines that the candidate address is a valid address for the target public key, then the address verifier can use the valid address to send data to that valid address, i.e., to the owner of the target public key (e.g., address generator 401).

[0093] In the third embodiment, the address generator 401 generates a signature based on the subnet prefix and uses the signature to generate an interface identifier, thereby generating a network address, wherein the subnet prefix and the interface identifier together constitute the address.

[0094] The address generator (401) signs the subnet prefix using the private key corresponding to the target public key. Any nondeterministic signature scheme (such as ECDSA) can be used.

[0095] Address generator 401 generates the interface identifier by hashing the signature and collision count. In some examples, the collision count is set to zero. The interface identifier can be based on a portion of the resulting hash (e.g., n bits). In some examples, one or more bits of the resulting hash can be modified, for example, to encode security parameters, or to set one or more bits to a specific value (e.g., zero).

[0096] Then, the address is generated based on the subnet prefix and the interface identifier (e.g., a concatenation of the two).

[0097] In some examples, the signature generated by address generator 401 might meet the following condition: when hashed, it produces a hash value starting with a minimum number of zero bits. This may involve generating multiple signatures until the condition is met. Each signature can be generated using the same private key. Alternatively, each signature can be generated using a different private key. That is, a first signature can be generated using a first private key. If that signature does not meet the requirements, a second, different private key is used to generate a second signature. This iterative process of using different private keys is repeated until a signature that does meet the requirements is generated. In some examples, each new private key is based on a previous private key, i.e., the second private key is based on the first private key. For example, a new private key could be the sum of a previous private key and the number one, as described in more detail below.

[0098] Address generator 401 can follow Figure 6 The algorithm shown is used to generate addresses (e.g., IPv6 addresses).

[0099] Address generator 401 may share addresses with one or more network users 403 and / or verifiers (also known as address verifiers) 402. Address generator 402 may share signatures with address verifier 402.

[0100] From the perspective of address verifier 402, address verifier 402 acquires (e.g., receives from address generator 401) "candidate addresses" for the target public key. The candidate addresses include a subnet prefix and an interface identifier. Address verifier 402 also acquires (e.g., receives) candidate signatures. Address verifier 402 also acquires (e.g., receives) candidate collision counts.

[0101] Address verifier 402 verifies whether the candidate signature is a valid signature of the target public key. That is, address verifier 402 checks whether the candidate signature signs the subnet prefix of the candidate address. Address verifier 402 also uses the same method (if the address is valid) used by address generator 401 to generate a candidate interface identifier and checks whether the candidate interface identifier matches the interface identifier of the candidate address.

[0102] In some examples, address verifier 402 can verify whether the candidate conflict count used to generate candidate interface identifiers takes a value from a predetermined set of values ​​(e.g., zero, one, or two).

[0103] Address verifier 402 can use candidate signatures to generate candidate hash values. Address verifier 402 verifies whether the candidate hash value includes a minimum number of leading zeros.

[0104] If address verifier 402 determines that the candidate address is a valid address for the target public key, then the address verifier can use the valid address to send data to that valid address, i.e., to the owner of the target public key (e.g., address generator 401).

[0105] 2.1 Enhanced CGA++ This section describes further specific examples of the embodiments described above. The examples described in this section are referred to herein as "Enhanced CGA++".

[0106] 2.1.1 Enhanced CGA++: Using a deterministic signature scheme The security issues in CGA++ stem from the nondeterminism of most digital signature schemes. To address this, CGA++ can be modified (according to the first embodiment described above) by requiring the generation of a signature given as input to Hash1 using a deterministic signature scheme (such as BLS, EdDSA, or RSA PKCS1 v1.5). Therefore, an attacker cannot repeatedly generate a signature from the message as input to Hash1. The different signatures given as input are used to brute-force the address.

[0107] Auxiliary Theorem 2: Given a network, assume that addresses are generated and verified using the security parameter sec via enhanced CGA++. Let S... gen This represents the time required to generate a signature represented by a hash function. Then, the number of hash function evaluations required to impersonate a specific host is... .

[0108] Proof: To fake the target address, we need to find valid parameters such that (1) the leftmost 16×sec bit of Hash2 is zero, and (2) the value of Hash1 generates the target address.

[0109] When starting from condition (1), the attacker is expected to execute 2 16×sec The hash function is evaluated to find a suitable modifier. Since the signature given as input to Hash1 has a probability of producing a target address of 2n... -59 Therefore, this process needs to be repeated an average of 2 times. 59 Therefore, when starting from condition (1), the total cost of counterfeiting becomes 2. 59 (S gen +1+2 16×sec ).

[0110] Starting from condition (2), the attacker generates a signature as input to Hash1 until condition (2) is met. This is expected to require 2 steps. 59 ×(S gen +1) hash function evaluations. Next, the attacker calculates Hash2 and verifies whether condition (1) is satisfied, which has a probability of 2. -16×sec Overall, attackers are expected to compute 2 hashes using Hash2. 16×sec Only after this process can condition (1) be satisfied. Therefore, when starting from condition (2), the total cost of counterfeiting becomes 2.16×sec (2 59 ×(S gen +1)+1).

[0111] For all cases where sec > 0, the cost of spoofing is smaller when starting from condition (1) than when starting from condition (2). For the case where sec = 0, the cost of spoofing is negligible.

[0112] 2.1.2 Enhanced CGA++: Signature shift-out address generation process Another security improvement involves removing the signature from the address generation process. Verification then checks whether the signature was generated correctly to ensure authentication. Because this variant works with any signature scheme, it is more flexible than the previous one.

[0113] The address generation algorithm takes the subnet prefix (subnetPrefix), the address owner's public / private key, and the security parameter (sec) as input. The algorithm is as follows: Figure 5 As shown, its working principle is as follows: 1. Set the modifier to a random 128-bit value.

[0114] 2. Calculate Hash2 by hashing the concatenation of modifier, subnetPrefix, and pubKey and taking the leftmost 112 bits of the resulting hash value.

[0115] 3. Check if the leftmost 16×sec bit of Hash2 is zero. If it is, proceed to step 4. Otherwise, increment the modifier and return to step 2.

[0116] 4. Set the 8-bit collisionCount to zero.

[0117] 5. Calculate Hash1 by hashing the concatenation of modifier, subnetPrefix, collisionCount, and pubKey and taking the leftmost 64 bits of the resulting hash value.

[0118] 6. The interface identifier is constructed from Hash1 by encoding the value of sec to the leftmost three bits and setting the u and g bits (bits 6 and 7 when starting from 0 from the left) to zero.

[0119] 7. Concatenate the 64-bit subnet prefix and the 64-bit interface identifier to form a 128-bit IPv6 address.

[0120] 8. If necessary, perform DAD. If an address conflict is detected, increment collisionCount and return to step 5. After three conflicts, stop and report an error.

[0121] 9. Finally, sign the address using the private key corresponding to the pubKey.

[0122] The verification algorithm takes the address, signature, modifier, subnetPrefix, collisionCount, and public key pubKey as input, and works as follows: 1. Check if the address is correctly signed.

[0123] 2. Check if collisionCount is equal to 0, 1 or 2.

[0124] 3. Check if subnetPrefix is ​​equal to the subnet prefix of the address.

[0125] 4. Calculate Hash2 and check if the leftmost 16×sec bit of the resulting hash value is zero.

[0126] 5. Calculate Hash1 and check if it equals the interface identifier of the address. Ignore the leftmost three bits and the differences between the u and g bits.

[0127] If the verification is successful, then verify the binding between the public key and the address. If sec=0, step 4 can be skipped.

[0128] Auxiliary Theorem 3: Given a network, suppose addresses are generated and verified using the security parameter sec via enhanced CGA++ (variant 2). Then, the number of hash function evaluations required to impersonate a particular host is... .

[0129] Proof: To fake the target address, we need to find valid parameters such that (1) the leftmost 16×sec bit of Hash2 is zero, and (2) the value of Hash1 generates the target address.

[0130] When starting from condition (1), the attacker is expected to execute 2 16×sec × S gen This hash function is evaluated. Since the probability of the parameters subsequently generating the target address is 2-1. -59 Therefore, this process needs to be repeated an average of 2 times. 59 Therefore, when starting from condition (1), the total cost of deception becomes 2. 59+16×sec +2 59 .

[0131] Starting from condition (2), the attacker iterates through the modifier as input to Hash1 until condition (2) is satisfied. This is expected to require 2 steps. 59Next, the attacker calculates Hash2 and verifies whether condition (1) is satisfied, which has a probability of 2. -16×sec Overall, attackers are expected to compute 2 hashes using Hash2. 16×sec Only after several attempts can condition (1) be satisfied. Therefore, when starting from condition (2), the total cost of deception becomes 2. 59+16×sec +2 16×sec .

[0132] 2.1.3 Enhanced CGA++: Moving signature as input to Hash2 In addition to using the signature as input to Hash1, this can be improved by using the signature as input to Hash2. Therefore, it is no longer possible for an attacker to brute-force the address by repeatedly regenerating the signature without recalculating Hash2.

[0133] In this variant, the source of randomness necessary to satisfy the Hash2 condition is the signature. Therefore, address generation no longer uses modifier values. This reduces the size of the data to be transmitted to the address verifier by 128 bits.

[0134] The address generation algorithm takes the subnet prefix (subnetPrefix), the address owner's public / private key, and the security parameter (sec) as input. The algorithm is as follows: Figure 6 As shown, its working principle is as follows: 1. Sign the subnetPrefix using the private key corresponding to the pubKey.

[0135] 2. Calculate Hash2 by hashing the signature.

[0136] 3. Compare the leftmost 16×sec bits of Hash2 with zero. If both are zero, proceed to step 4. Otherwise, return to step 1.

[0137] 4. Set the 8-bit collisionCount to zero.

[0138] 5. Calculate Hash1 by hashing the concatenation of the signature and collisionCount and taking the leftmost 64 bits of the resulting hash value.

[0139] 6. The interface identifier is constructed from Hash1 by encoding the value of sec to the leftmost three bits and setting the u and g bits (bits 6 and 7 when starting from 0 from the left) to zero.

[0140] 7. Concatenate the 64-bit subnet prefix and the 64-bit interface identifier to form a 128-bit IPv6 address.

[0141] 8. If necessary, perform Duplicate Address Detection (DAD). If an address collision is detected, increment collisionCount and return to step 5. After three collisions, stop and report an error.

[0142] The verification algorithm takes the address, signature, collisionCount, subnetPrefix, and public key pubKey as input, and works as follows: 1. Check if the signature correctly signs the subnetPrefix.

[0143] 2. Check if collisionCount is equal to 0, 1 or 2.

[0144] 3. Check if subnetPrefix is ​​equal to the subnet prefix of the address.

[0145] 4. Calculate Hash2 and check if the leftmost 16×sec bit of the resulting hash value is zero.

[0146] 5. Calculate Hash1 and check if it equals the interface identifier of the address. Ignore the leftmost three bits and the differences between the u and g bits.

[0147] If the verification is successful, then verify the binding between the public key and the address. If sec=0, step 4 can be skipped.

[0148] Since satisfying the Hash2 condition now requires repeated signature computation, using this technique to generate addresses is more expensive than using CGA++. The cost of address generation increases by a multiplication factor S compared to CGA. gen In CGA++, an addition factor S is added. gen .

[0149] The following describes a method that makes address generation cost comparable to CGA++. It assumes the signature is generated using a Digital Signature Algorithm (DSA) such as ECDSA, although this method may be equally effective with other signature algorithms. In this method, the public / private key is not fixed as input to the address generation algorithm, but rather given as its output. Therefore, this method is not suitable when the public key must be a fixed public key (such as a previously authenticated public key). Let privKey represent the address owner's private key. In ECDSA, the signature of message m is given by the tuple (r, s), where s = (k... -1 H(m)+k -1 .privKey.r) mod p, where From A temporary key is randomly selected from the data. When attempting to satisfy the Hash2 condition, this method uses item k...-1 Instead of regenerating r and s from scratch, the value is recalculated by adding .r to the value s. A new private key 'privKey' valid for the new signature is given by 'privKey' = privKey + 1. This process is repeated until the Hash2 condition is met. In other words, the value r and the signed message are fixed, so the host iterates over the private key until the resulting signature satisfies the Hash2 condition. The public key is then obtained from the final private key value as the output of the address generation algorithm.

[0150] Auxiliary Theorem 4: Given a network, assume that addresses are generated and verified using the security parameter sec via enhanced CGA++ (variant 3). Let S... gen This represents the time required to generate a signature represented by a hash function. Then, the number of hash function evaluations required to impersonate a specific host is... .

[0151] Proof: To fake the target address, we need to find valid parameters such that (1) the leftmost 16×sec bit of Hash2 is zero, and (2) the value of Hash1 generates the target address.

[0152] When starting from condition (1), the attacker is expected to execute 2 16×sec ×(S gen +1) hash function evaluations are performed to find a suitable signature. Since the probability of the signature subsequently generating the target address is 2-1. -59 Therefore, this process needs to be repeated an average of 2 times. 59 Therefore, when starting from condition (1), the total cost of deception becomes 2. 59 (2 16×sec (S gen +1)+1).

[0153] Starting from condition (2), the attacker generates a signature as input to Hash1 until condition (2) is met. This is expected to require 2 steps. 59 ×(S gen +1) hash function evaluations. Next, the attacker calculates Hash2 and verifies whether condition (1) is satisfied, which has a probability of 2. -16×sec Overall, attackers are expected to compute 2 hashes using Hash2. 16×sec Only after several attempts can condition (1) be satisfied. Therefore, when starting from condition (2), the total cost of deception becomes 2. 16×sec (2 59 (S gen +1)+1).

[0154] 2.2 Analysis and Comparison Similar to CGA++, Enhanced CGA++ incorporates authentication directly into the verification process using signature verification. This eliminates the possibility of replay attacks. Furthermore, the global time-to-storage tradeoff attack described by Bos et al. is also impossible in Enhanced CGA++. This is because the subnet prefix is ​​used as input to Hash2. This eliminates the possibility of an attacker creating a database of valid modifier / public key pairs and using them to reverse addresses with any subnet prefix.

[0155] Table 4 summarizes the comparison between CGA++ and enhanced CGA++ when sec > 0. Using S... ver This represents the time required to verify the signature of the representation using a hash function. For simplicity, let S be the time required. gen ' represents the time required to generate a signature and perform a hash function evaluation once, such that S gen '=S gen +1. In each variant, spoofing attacks are significantly more difficult than in CGA++. Specifically, in each variant, the hash expansion technique increases the cost of spoofing attacks by a multiplication factor of 2. 16×sec This restores the effectiveness of the hash expansion technique.

[0156]

[0157] Table 4: Comparison of CGA++ and Enhanced CGA++ for IPv6. All timings are represented by hash function evaluation.

[0158] 3. Further comments Once the disclosure herein is given, other variations or use cases of the disclosed technology may become apparent to those skilled in the art. The scope of this disclosure is not limited to the described embodiments, but only to the appended claims.

[0159] It should be understood that the above embodiments are described by way of example only. More generally, a method, apparatus, or program can be provided based on any one or more of the following statements.

[0160] Statement 1. A computer-implemented method for generating network addresses of a network, wherein the method is performed by an address generator and includes: Generate an interface identifier, wherein the interface identifier is based on a hash value, wherein the hash value is based on at least a modifier value, a subnet prefix, a collision count value, and a public key; The network address is generated based on the subnet prefix and the interface identifier; and A signature is generated based on the network address, wherein the private key used to generate the signature corresponds to the public key.

[0161] Statement 2. The method according to Statement 1, wherein generating the interface identifier includes: encoding security parameters into the hash value; and / or setting one or more bits of the second value to zero.

[0162] Statement 3. The method according to any of the preceding statements, wherein the network address is an IPv6 address.

[0163] Statement 4. The method according to any of the preceding statements, the method comprising: providing the network address to one or more parties.

[0164] Statement 5. The method according to statement 4, wherein one or more parties include an address verifier configured to verify the network address.

[0165] Statement 6. The method described in statement 5, the method comprising: providing the signature to the address verifier.

[0166] Statement 7. A computer-implemented method for verifying network addresses of a network, wherein the method is performed by an address verifier and includes: Obtain candidate network addresses, target public keys, candidate modifier values, candidate signatures, and candidate conflict counts, wherein the candidate network addresses include subnet prefixes and interface identifiers; Use the target public key to verify the candidate signature; Candidate interface identifiers are generated based on hash values, wherein the hash values ​​are generated based on at least the candidate modifier values, the subnet prefix, the candidate collision count value, and the hash of the target public key; and Verify whether the candidate interface identifier corresponds to the interface identifier.

[0167] Statement 8. The method described in statement 7, the method comprising: verifying whether the candidate conflict count value is equal to a value in a predetermined set of values.

[0168] Statement 9. The method described according to statement 7 or 8, the method comprising: A candidate hash value is generated based on at least the candidate modifier value, the subnet prefix, and the hash of the target public key; and Verify whether the candidate hash value includes a predetermined number of leading zeros.

[0169] Statement 10. The method according to any one of statements 7 to 9, wherein the acquisition includes: receiving one or more of the candidate network address, the target public key, and the candidate signature from an address generator configured to generate the candidate network address.

[0170] Statement 11. The method according to any one of statements 7 to 10, the method comprising: in response to verifying the network address, transmitting data via the network addressing the network address.

[0171] Statement 12. A computer device, said computer device comprising: The memory includes one or more memory cells; and A processing apparatus comprising one or more processing units, wherein the memory stores code set to run on the processing apparatus, the code being configured to execute a method according to any one of statements 1 to 11 when run on the processing apparatus.

[0172] Statement 13. A computer program contained on a computer-readable storage medium and configured to perform the method according to any one of statements 1 to 11 when run on one or more processors.

[0173] According to another aspect disclosed herein, a method can be provided that includes the actions of the address generator and the address verifier. According to another aspect disclosed herein, a system can be provided that includes computer devices for the address generator and the address verifier.

Claims

1. A computer-implemented method for generating network addresses of a network, wherein the method is performed by an address generator and includes: Generate an interface identifier, wherein the interface identifier is based on a hash value, wherein the hash value is based on at least a modifier value, a subnet prefix, a collision count value, and a public key; The network address is generated based on the subnet prefix and the interface identifier; as well as A signature is generated based on the network address, wherein the private key used to generate the signature corresponds to the public key.

2. The method according to claim 1, wherein the generation of the interface identifier includes: Encode the security parameters into the hash value; And / or set one or more bits of the hash value to zero.

3. The method according to any of the preceding claims, wherein the network address is an IPv6 address.

4. The method according to any one of the preceding claims, wherein the method comprises: The network address is provided to one or more parties.

5. The method of claim 4, wherein one or more parties include an address verifier configured to verify the network address.

6. The method according to claim 5, wherein the method comprises: The signature is provided to the address verifier.

7. A computer-implemented method for verifying network addresses, wherein the method is performed by an address verifier and includes: Obtain candidate network addresses, target public keys, candidate modifier values, candidate signatures, and candidate conflict counts, wherein the candidate network addresses include subnet prefixes and interface identifiers; Use the target public key to verify the candidate signature; Candidate interface identifiers are generated based on hash values, wherein the hash values ​​are generated based on at least the candidate modifier values, the subnet prefix, the candidate collision count values, and the hash of the target public key; as well as Verify whether the candidate interface identifier corresponds to the interface identifier.

8. The method according to claim 7, wherein the method comprises: Verify whether the candidate conflict count value is equal to a value in a predetermined value set.

9. The method according to claim 7 or 8, wherein the method comprises: Candidate hash values ​​are generated based on at least the candidate modifier values, the subnet prefix, and the hash of the target public key; as well as Verify whether the candidate hash value includes a predetermined number of leading zeros.

10. The method according to any one of claims 7 to 9, wherein the acquisition comprises: The address generator, configured to generate the candidate network address, receives one or more of the candidate network address, the target public key, and the candidate signature.

11. The method according to any one of claims 7 to 10, the method comprising: In response to verifying the network address, data is transmitted over the network in a manner addressing the network address.

12. A computer device, the computer device comprising: The memory includes one or more memory units; as well as A processing apparatus comprising one or more processing units, wherein the memory stores code configured to run on the processing apparatus, the code being configured to execute the method according to any one of claims 1 to 11 when run on the processing apparatus.

13. A computer program, the computer program being contained on a computer-readable storage medium and configured to perform the method according to any one of claims 1 to 11 when run on one or more processors.

Images