Secure network address

Abstract

A computer implementation method for generating a network address for a network, the method being performed by an address generator, comprising the steps of: generating an interface identifier, the interface identifier being based on a hash value, the hash value being based on at least a modifier value, a subnet prefix, a collision count value, and a hash of 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, the private key used to generate the signature corresponding to the public key.

Description

[Technical Field]

[0001] This disclosure relates to the generation of network addresses, such as IP addresses, including IPv6 addresses. [Background technology]

[0002] Cryptographically Generated Addresses (CGAs) were introduced as part of the Secure Neighbor Discovery (SEN) protocol to enable nodes to join subnets and locally generate their own IPv6 addresses. The addresses are bound to the node's public key using a cryptographic one-way hash function. CGAs provide a secure way for nodes to prove they are the legitimate owners of advertised IPv6 addresses without relying on any security infrastructure. Their purpose is to prevent spoofing and denial-of-service (DoS) attacks that protocols such as the Neighbor Discovery Protocol (NDP) are susceptible to.

[0003] Bos et al., 2009, “Analysis and Optimization of Cryptographically Generated Addresses”, Information Security (p.17-32), Springer Berlin. Heidelberg presents a complete analysis of CGA and highlights some of its vulnerabilities. As a result, a new technique called CGA++ has been proposed to address these vulnerabilities. This technique is primarily based on CGA and introduces digital signatures to directly add authentication to the address verification process. [Overview of the project]

[0004] The introduction of digital signatures in CGA++ significantly degrades the security of the underlying CGA technology. To mitigate this problem, this disclosure provides a set of techniques (referred to in this specification as Extended CGA++) that significantly improve the security of CGA++ while retaining the benefits provided by it. This is done without introducing extra complexity during address generation or address verification.

[0005] According to one aspect disclosed in this specification, a computer implementation method for generating a network address for a network, the method being performed by an address generator, A step of generating an interface identifier, wherein the interface identifier is based on a hash value, and the hash value is based on at least a modifier value, a subnet prefix, a collision count value, and a hash of the public key. The steps include generating the network address based on the subnet prefix and the interface identifier, A step of generating a signature based on the aforementioned network address, wherein the private key used to generate the signature corresponds to the public key, A method including this is provided.

[0006] According to another aspect disclosed in this specification, a computer implementation method for verifying a network address for a network, the method being performed by an address verifier, A step of 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. The steps include verifying the candidate signature using the target public key, A step of generating a candidate interface identifier based on a hash value, wherein the hash value is generated based on at least the candidate modifier value, the subnet prefix, the candidate collision count value, and the hash of the target public key. A step of verifying that the candidate interface identifier corresponds to the interface identifier, A method including this is provided.

[0007] It should be noted that embodiments of this disclosure can be used in general to generate and verify network addresses, and are not limited to generating and verifying specific types of network addresses, such as IPv6 addresses. [Brief explanation of the drawing]

[0008] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments may be carried out, the following appended drawings are referenced only as examples. [Figure 1] The format of an IPv6 address is shown in general terms. [Figure 2] The CGA generation algorithm flow is outlined below. [Figure 3] The flow of the CGA++ generation algorithm is outlined below. [Figure 4] This document outlines a system for generating and verifying network addresses. [Figure 5] The flow of the CGA++ generation algorithm is outlined below. [Figure 6] The flow of an alternative extended CGA++ generation algorithm is outlined below. [Modes for carrying out the invention]

[0009] 1. Background of related cryptography 1.1 Cryptographically Generated Addresses (CGA) An IPv6 address is a 128-bit address, with the leftmost 64 bits forming the subnet prefix and the rightmost 64 bits forming the interface identifier. The subnet prefix is ​​used to determine the host's location in the internet topology, and the interface identifier is used as the identity of the host within the subnet. Figure 1 shows the IPv6 address format.

[0010] A cryptographically generated address (CGA) is an IPv6 address in which an interface identifier is generated by applying a cryptographic hash function to a public key and additional auxiliary parameters. A host can prove ownership of the IPv6 address it is communicating with by signing messages using the associated private key. Verification of address ownership can be performed independently of any security infrastructure by verifying the signature and recalculating the binding between the public key and the address.

[0011] CGA is used in the SEND protocol to prevent impersonation and DoS attacks. An impersonation attack occurs when an attacker within the local network forges router advertisement messages, resulting in packets destined for a legitimate host being redirected to another link-layer address. In a DoS attack, the attacker disrupts the Duplicate Address Detection (DAD) protocol by responding to every DAD attempt made by the intruder host. Thus, a new, legitimate host cannot obtain an address. CGA is designed to mitigate these attacks by giving hosts a way to prove address ownership.

[0012] With technological advancements, it was quickly recognized that 64-bit interface identifiers were insufficient to protect CGA from spoofing attacks. In CGA, spoofing attacks occur when an attacker attempts a brute-force attack to obtain another valid public / private key that yields a target address. This gives the attacker the ability to misrepresent themselves as another host by presenting a public key that correctly binds to the target address. To mitigate this attack, CGA added hash extension techniques to new address generation. This technique requires the host to solve a PoW-like puzzle whose difficulty depends on parameterizable security parameters. This technique increases the cost of both address generation and spoofing attacks by the same factor, but maintains the cost of address usage and verification.

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

[0014] The modifier is used during CGA generation to enhance privacy by implementing hash extension techniques and adding randomness to addresses. The collisionCount can only have a value of 0, 1, or 2. This is incremented during CGA generation to recover from address collisions detected by the DAD. The pubKey is the public key as a DER-encoded ASN.1 structure of SubjectPublicKeyInfo as defined in the Internet X.509 authentication profile. extensionFields are optional variable-length fields that can be used for additional data items and have a default length of 0.

[0015] The CGA also has a 3-bit security parameter sec, encoded in the leftmost 3 bits of the interface identifier. This parameter determines the CGA's strength against spoofing attacks. It can have a value from 0 (lowest security) to 7 (highest security).

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

[0017] Figure 2 shows the CGA generation algorithm. The interface identifier bits are numbered starting from bit 0 on the left. The upper part corresponds to hash extension technology. This requires the host to solve a cryptographic puzzle by iterating through the modifier value until the leftmost 16 × sec bits of Hash2 are equal to zero. If sec=0, this part is skipped. The interface identifier of the address is derived from Hash1 by taking the leftmost 64 bits of Hash1, setting bits 6 (u "universal") and 7 (g "individual / group") to zero, and encoding the sec parameter in the leftmost 3 bits. When using CGA, the u and g bits are ignored. Setting them to 0 is an optional arrangement.

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

[0019] The advantage of not including subnet prefixes as input to Hash2 is that it allows mobile hosts moving from one subnet to another to reuse 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 an attacker to construct a time-memory trade-off attack to pose as the address of a random host in the network for any subnet prefix.

[0020] The CGA verification algorithm accepts an address and a CGA parameter data structure as input and operates as follows: 1. Check that collisionCount is equal to 0, 1, or 2; 2. Check that subnetPrefix is ​​equal to the subnet prefix of the address; 3. Calculate Hash1 and check that it is equal to the interface identifier of the address. The leftmost 3 bits and the difference between the u and g bits are ignored; 4. Calculate Hash2 and check that the leftmost 16 × sec bits of the resulting hash value are zero.

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

[0022] The property of the hash functions used in Hash1 and Hash2 to prevent impersonation attacks is called second preimage resistance. Second preimage resistance for 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 an attacker can impersonate a CGA is by brute-forcing it.

[0023] The cost of spoofing an address by brute-forcing the CGA can be calculated as follows: Of the 64 bits of Hash1, the 5 bits corresponding to the sec, u, and g bits are ignored during CGA verification. If sec=0, finding the set of CGA parameters that yields the desired CGA takes O(2 59 ) hash function evaluations are required. Hash extension techniques require the leftmost 16 × sec bits of the Hash2 value to be zero, which reduces the cost of address generation to approximately 2 16×sec It increases by a multiple of . This also increases the cost of a spoofing attack by the same multiple. In other words, to spoof an address by a brute-force attack, it takes O(2 59+16×sec ) hash function evaluations are required.

[0024] 1.1.1 Restrictions This subsection discusses two attacks against CGA.

[0025] 1.1.1.1 Time-Memory Trade-off Attack The subnet prefix is ​​not included as input to Hash2 in order for mobile hosts to efficiently generate new addresses when their location changes. This weakness can be exploited to construct a time-memory trade-off attack to spoof the address of a random host in the network for an arbitrary subnet prefix.

[0026] To initiate this attack, the attacker begins by generating a valid public / private key pair. This only needs to be done once. For a network of size 2 n , the attacker generates a database of 2 59-n modifier values such that the leftmost 16×sec bits of Hash2 are zero. Creating such a database requires O(2 59+16×sec-n ) hash function evaluations. Using this database, the attacker needs O(2 59-n ) hash function calls and hash value comparisons to find a modifier value that yields the address of a random host within the network. Since the subnet prefix is not included as input to Hash2, the database can be reused for any subnet prefix. Once the database is created, the cost of the attack is independent of the sec parameter, so in the long run, this attack nullifies the effect of the hash extension technique.

[0027] As an example, if an attacker wants to impersonate the address of a random host within a network of size 2 16 using sec = 1, the database is constructed with O(2 59 ) hash function evaluations and requires approximately 128TB of space. This is significant but not impractical. Next, the attacker needs O(2 43 ) hash function evaluations and comparisons to find the appropriate modifier value.

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

[0029] An attacker can obtain a public key belonging to another host and use a different subnet prefix or modifier to generate another valid address. While they cannot sign new messages, they can replay messages signed by the host, potentially misleading other hosts into believing they own the address.

[0030] This type of replay attack can also target addresses that already exist within the network. For a specific security parameter sec, an attacker can collect many valid modifier values ​​and public keys along with 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 a match in one of the existing addresses within the subnet and initiate message replay.

[0031] Another example of such a replay attack targeting existing addresses is searching for addresses with a non-zero collisionCount. An attacker could generate an existing address in the network by using a valid modifier value and public key associated with the target address, and then using a collisionCount equal to 0. Nevertheless, this type of attack is extremely unlikely to occur because the probability of collisions in interface identifiers is low.

[0032] 1.2 Cryptographic Generation Address++ (CGA++) A new technique called CGA++ (Cryptographically Generated Addresses++) has been proposed to address the aforementioned limitations. The main difference is the introduction of signatures into the calculation of Hash1. In addition to guaranteeing the binding between the public key and the address, CGA++ directly introduces authentication in address verification. This further reduces the efficiency of address generation, but not by a significant amount. Furthermore, CGA++ directly incorporates the subnet prefix into the calculation of Hash2. This has the effect of eliminating the time-memory trade-off attack that CGA suffers from. At the same time, when changing subnets, it forces the host to repeatedly search for a valid modifier value. Therefore, this technique is not suitable for mobile hosts where operations such as handovers should be completed within milliseconds.

[0033] The CGA++ generation algorithm takes the subnet prefix, the public / private keys of the address owner, and the security parameter sec as input. The algorithm is shown in Figure 3 and operates as follows: 1. Set modifier to a random 128-bit value; 2. Hash2 is calculated by hashing the concatenation of modifier, subnetPrefix, and pubKey, and taking the leftmost 112 bits of the resulting hash value; 3. Check if the leftmost 16 × sec bits of Hash2 are zero. If so, proceed to step 4. Otherwise, increment the modifier by 1 and return to step 2; Set the 4.8-bit collisionCount to zero; 5. Sign the modifier, collisionCount, and subnetPrefix with the private key corresponding to the pubKey; 6. Calculate Hash1 by hashing the concatenation of pubKey and signature, and taking the leftmost 64 bits of the resulting hash value; 7. Constitute the interface identifier from Hash1 by encoding the value of sec into the leftmost 3 bits, and by setting the u and g bits (bits 6 and 7 if starting from 0 from the left) to zero; A 128-bit IPv6 address is formed by concatenating an 8.64-bit subnet prefix with a 64-bit interface identifier; 9. Perform DAD as needed. If an address collision is detected, increment collisionCount by 1 and return to step 5. After 3 collisions, stop and report an error.

[0034] The CGA++ verification algorithm takes an address, signature, collisionCount, modifier, subnetPrefix, and public key (pubKey) as input and operates as follows: 1. Check that the signature is correct; 2. Check that collisionCount is equal to 0, 1, or 2; 3. Check that subnetPrefix is ​​equal to the subnet prefix of the address; 4. Calculate Hash2 and check that the leftmost 16 × sec bits of the resulting hash value are zero; 5. Calculate Hash1 and check that it is equal to the interface identifier of the address. The leftmost 3 bits and the differences between the u and g bits are ignored.

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

[0036] 1.2.1 Analysis To compare CGA++ with CGA, Bos et al. reported the computational cost of signing messages from the perspective of hash function evaluation using the ECRYPT Benchmarking of Cryptographic Systems (eBACS). The results are shown in Table 2. The hash function obtained from the benchmark is SHA-1, and the public key signing scheme is RSA. Table 2: Signature time is expressed in units of SHA-1 hash function evaluation for different RSA key sizes. [Table 2]

[0037] Table 3 summarizes the comparison between CGA and CGA++. The efficiency of address generation and verification decreases when moving from CGA to CGA++. This is due to the additional computation required to generate and verify signatures. Furthermore, the time required to update addresses when moving to different subnets increases exponentially in seconds. In return, the security of CGA++ is improved compared to CGA. Global time-memory trade-off attacks are prevented in CGA++ by including the subnet prefix as input to Hash2. Additionally, an extra authentication mechanism is introduced by using direct signatures in address generation. According to BOS et al., the cost of a spoofing attack is 2 in CGA++. 59 (2 16×sec +S gen This results in a hash function evaluation of S (+1). gen This is the signature generation time expressed in units of hash function evaluation. Table 3: Comparison of IPv6 CGA and CGA++ using a 1024-bit RSA key. All timings are expressed in units of hash function evaluation. [Table 3]

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

[0039] BLS relies on groups of groups that are difficult to handle computationally but can efficiently solve deterministic Diffie-Hellman problems. These groups are called gap groups.

[0040] The existence of Weil connections in several groups of elliptic curves makes the definitive Diffie-Hellman problem trivial. In other words, it is possible to show a group G having generators g and a function e: G×G→GT. Here, G, G T This is a group of prime numbers of the following order: (g,g x ,g y If ) is given, g xy The calculation is difficult; (g z ,g x ,g y If ) is given, e(g x ,g y )=e(g,g) xy and e(g,g z )=e(g,g) z This is obtained. By comparing these two values, we can determine whether xy = z; The function e is obtained from a Weil joint, which can be computed using the Miller algorithm.

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

[0042] The secret key x is generated by randomly selecting an integer in the following equation:

number

[0043] The corresponding public key is provided in gx.

[0044] Given a private key x and a message m, the signature σ is obtained by hashing m as h=H(m) and σ=h x It is calculated by calculating [this].

[0045] Signature σ and public key g x Given, e(σ,g)=e(H(m),g x It is verified that this is the case.

[0046] 1.4 CGA++ Attack This section demonstrates that the security analysis conducted in the original CGA++ paper by Bos et al. was flawed and describes effective impersonation attacks against CGA++.

[0047] In the following analysis, all timings are expressed in units of hash function evaluation. S gen This indicates the time required to generate a signature represented by hash function evaluation. Assume Sgen < 216. gen <2 16 Let's assume that...

[0048] BOS et al. state that the cost of an impersonation attack in CGA++ is 2 59 (S gen +1+2 16×sec ) they claim. 2 59 × (S gen +1)+2 16×sec We will demonstrate that this claim is false by presenting an efficient impersonation attack that can be performed at the cost of . As a result, in CGA++, the hash extension technique is multiplicative, whereas in CGA it was multiplicative, but 2 16×secThe additive factor increases the cost of impersonation attacks. The hash extension techniques used to protect CGA are no longer effective in CGA++, thereby making CGA++ far more vulnerable to impersonation attacks than CGA.

[0049] This attack utilizes the signature used in calculating Hash1 to perform a brute-force attack on existing addresses generated by CGA++. The attacker has a cost of 2 16×sec The attacker begins by searching for a modifier value that satisfies the condition of Hash2 having the following: gen Compute a Hash1 with +1. As noted by BOS et al., "CGA++ is independent of the signature scheme used." Therefore, for example, if a Digital Signature Algorithm (DSA) is used, an attacker can iterate through the temporary key until they generate a Hash1 value whose resulting signature matches the target address. This averages 2 59 This requires multiple attempts. Therefore, this attack is similar to Attack 2 described by Bos et al. 59 (S gen +1+2 16×sec ) vs. 2 59 × (S gen +1)+2 16×sec It has the cost of [amount]. Note that the attack of the present invention works against any non-deterministic signature scheme. Therefore, the following lemma can be derived.

[0050] Lemma Theorem 1. Given a network, assume that addresses are generated and verified by CGA++ with security parameter sec. gen This indicates the time required to generate a signature, expressed as a unit of hash function evaluation, and S gen <2 16 Therefore, the number of required hash function evaluations needed to impersonate a specific host is T=2 59 ×S gen +2 16×sec That is the case.

[0051] 2. Generating a Secure Network Address Figure 4 shows an exemplary system 400 for carrying out embodiments of the present disclosure. The system 400 includes a generating party 401 configured to generate a network address for a network, a verifying party 402 configured to verify the network address, and one or more users 403 of the network. The generating party and the verifying party may also be users of the network. The network may be a packet-switched network, such as a wide area network like the Internet.

[0052] Each party (Generating Party 401, Verification Party 402, and Network User 403) operates its own computer equipment. Each party's computer equipment includes its own processing unit, which contains one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each party's computer equipment further includes memory, i.e., computer-readable storage device in the form of a non-temporary computer-readable medium or a plurality of media. This memory may include one or more memory units using one or more memory media, e.g., magnetic media such as a hard disk, an SSD, an electronic medium such as flash memory or EEPROM, and / or optical media such as an optical disc drive. The memory on each party's computer equipment can store software, which includes each instance of at least one client application arranged to run on the processing unit. It will be understood that any operation attributed to a given party in this specification may be performed using software running on the processing unit of each computer equipment. Each party's computer equipment includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. A given party's computer equipment may include one or more other networked resources, such as cloud computing resources accessed via user terminals.

[0053] The client application may first be provided to any given party's computer equipment on a suitable computer-readable storage medium or multiple media, for example, downloaded from a server, or provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk, such as a CD or DVD ROM, or removable optical drive.

[0054] The generating party 401 (also referred to as the address generator in this specification) is configured to generate addresses linked to a public key. The public key may be called the “target public key”. The address generator 401 has access to the private key corresponding to the public key. The address generator may own its own private key. The address includes a subnet prefix and an interface identifier. The subnet prefix determines the location of the user (i.e., the owner of the address) in the internet topology, and the interface identifier is used as the identity of the user within the subnet.

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

[0056] The address generator 401 then hasches a message containing or based on the target public key and signature. The message may be a concatenation of the target public key and signature. An interface identifier is generated based on the resulting hash. For example, the interface identifier may be based on a portion (e.g., n bits) of the resulting hash. In some examples, one or more bits of the resulting hash may be modified, for example, to encode security parameters or to set one or more bits to a specific value, e.g., 0.

[0057] Next, the address is generated based on the subnet prefix and interface identifier (concatenation). The address generator 401 can generate an address (e.g., an IPv6 address) according to the CGA++ generation algorithm shown in Figure 3, except that the signature algorithm is a deterministic signature algorithm.

[0058] The address generator 401 may share an address with one or more network users 403 and / or verification parties (also called address verifiers) 402. The address generator 402 may share a signature with the address verifier 402.

[0059] From the perspective of address verifier 402, it obtains a "candidate address" for the target public key (for example, received from address generator 401). Here, "candidate" refers to an address that has not yet been verified as a valid address for the public key. The candidate address includes the subnet prefix and interface identifier. Address verifier 402 also obtains a candidate signature (for example, received).

[0060] The address verifier 402 verifies that the candidate signature is a valid signature for the target public key. The address verifier 402 also generates a candidate interface identifier using the same method as used by the address generator 401 (if the address is valid) and checks that the candidate interface identifier matches that of the candidate address.

[0061] In some examples, the address verifier 402 may verify that a signature signs a message based on a collision count that takes one of a predetermined set of values, for example, 0, 1, or 2.

[0062] The address verifier 402 may obtain a candidate modifier value and use it together with the target public key and subnet prefix to generate a candidate hash value. The address verifier 402 verifies that the candidate hash value contains the minimum number of leading zero bits.

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

[0064] In the second embodiment, the address generator 402 first generates a network address and then signs the network address. The address includes a subnet prefix and an interface identifier, similar to the first embodiment. 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 may be randomly selected. The interface identifier may be based on a portion (e.g., n bits) of the resulting hash. In some examples, one or more bits of the resulting hash may be modified, for example, to encode security parameters or to set one or more bits to a specific value, e.g., 0.

[0065] Next, the address is generated based on the subnet prefix and interface identifier (concatenated).

[0066] The address generator 401 signs the network address using the private key corresponding to the target public key. Any suitable signing scheme may be used.

[0067] The address generator 401 can generate addresses (e.g., IPv6 addresses) according to the generation algorithm shown in Figure 5.

[0068] The address generator 401 may share an address with one or more network users 403 and / or verification parties (also called address verifiers) 402. The address generator 402 may share a signature with the address verifier 402.

[0069] From the perspective of address verifier 402, address verifier 402 obtains a "candidate address" for the target public key (for example, received from address generator 401). The candidate address includes the subnet prefix and interface identifier. Address verifier 402 also obtains a candidate signature (for example, received). Address verifier 402 also obtains a candidate modifier value and a candidate collision count (for example, received).

[0070] The address verifier 402 verifies that the candidate signature is a valid signature for the target public key; that is, the address verifier 402 confirms that the candidate signature signs the candidate address. The address verifier 402 also generates a candidate interface identifier using the same method used by the address generator 401 (if the address is valid) and checks that the candidate interface identifier matches that of the candidate address.

[0071] In some examples, the address verifier 402 may verify that the candidate collision count used to generate the candidate interface identifier takes one of a predetermined set of values, for example, 0, 1, or 2.

[0072] The address verifier 402 can generate a candidate hash value using the candidate modifier value, target public key, and subnet prefix. The address verifier 402 verifies that the candidate hash value contains the minimum number of leading zero bits.

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

[0074] In the third embodiment, the address generator 401 generates a network address by generating a signature based on the subnet prefix and using the signature to generate an interface identifier, with the subnet prefix and interface identifier together forming the address.

[0075] The address generator 401 signs the subnet prefix using the private key corresponding to the target public key. Any non-deterministic signature scheme, such as ECDSA, can be used.

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

[0077] Next, the address is generated based on the subnet prefix and interface identifier (concatenated).

[0078] In some examples, the signatures generated by address generator 401 must satisfy the requirement that, when hashed, they produce a hash value that starts with a minimum number of zero bits. This may involve generating multiple signatures until the condition is met. Each signature may be generated using the same private key, or a different private key may be used for each signature. That is, the first signature may be generated using the first private key. If that signature does not satisfy the requirement, a second signature is generated using a second different private key. This process, repeated through different private keys, is repeated until a signature that satisfies the requirement is generated. In some examples, each new private key is based on the previous private key, i.e., the second private key is based on the first private key. For example, the new private key may be the sum of the previous private key and the number 1, as will be described in more detail below.

[0079] The address generator 401 can generate addresses (e.g., IPv6 addresses) according to the generation algorithm shown in Figure 6.

[0080] The address generator 401 may share an address with one or more network users 403 and / or verification parties (also called address verifiers) 402. The address generator 402 may share a signature with the address verifier 402.

[0081] From the perspective of address verifier 402, address verifier 402 obtains a "candidate address" for the target public key (for example, receives it from address generator 401). The candidate address includes the subnet prefix and interface identifier. Address verifier 402 also obtains a candidate signature (for example, receives it). Address verifier 402 also obtains a candidate collision count (for example, receives it).

[0082] The address verifier 402 verifies that the candidate signature is a valid signature for the target public key. That is, the address verifier 402 confirms that the candidate signature signs the subnet prefix of the candidate address. The address verifier 402 also generates a candidate interface identifier using the same method used by the address generator 401 (if the address is valid) and checks that the candidate interface identifier matches that of the candidate address.

[0083] In some examples, the address verifier 402 may verify that the candidate collision count used to generate the candidate interface identifier takes one of a predetermined set of values, for example, 0, 1, or 2.

[0084] The address verifier 402 may generate a candidate hash value using a candidate signature. The address verifier 402 verifies that the candidate hash value contains the minimum number of leading zero bits.

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

[0086] 2.1 Extended CGA++ This section describes further specific examples of the embodiments described above. The examples described in this section are referred to in this specification as “Extended CGA++”.

[0087] 2.1.1 Extended CGA++: Use of Deterministic Signature Schemes Security issues in CGA++ arise from the non-deterministic nature of most digital signature schemes. To address this issue, CGA++ can be modified (according to the first embodiment described above) by requiring the signature given as input to Hash1 to be generated using a deterministic signature scheme such as BLS, EdDSA, or RSA PKCS1 v1.5. Thus, brute-force attacks on addresses become impossible for an attacker by repeatedly generating different signatures given as input to Hash1 from the message.

[0088] Lemma Theorem 2. Given a network, assume that addresses are generated and verified by the extended CGA++ with security parameter sec. gen This indicates the time required to generate a signature expressed in units of hash function evaluation. Therefore, the number of requested hash function evaluations required to impersonate a particular host is given by the following equation:

number

[0089] Proof: To spoof the target address, we need to find a valid parameter such that (1) the leftmost 16 × sec bits of Hash2 are zero, and (2) the value of Hash1 gives us the target address.

[0090] Starting from condition (1), the attacker needs to find the appropriate modifier. 16×sec It is expected that a hash function evaluation will be performed. The probability that the signature given as input to Hash1 yields the target address is 2 -59 Therefore, this process takes an average of 2 59 It needs to be repeated a certain number of times. Starting from condition (1), the total cost for disguise is 2 59 (S gen +1+2 16×sec )

[0091] Starting from condition (2), the attacker generates signatures as input to Hash1 until condition (2) is met. 59 × (S gen It is expected that this will require +1) hash function evaluations. Next, the attacker computes Hash2 and verifies that condition (1) is satisfied, which means that 2 -16×sec This occurs with a certain probability. In total, the attacker has two Hash2s before condition (1) is met. 16×sec It is expected that calculations will be performed 2 times. Therefore, starting from condition (2), the total cost for the disguise is 2 16×sec (2 59 × (S gen It becomes +1)+1).

[0092] For all sec>0, the cost of disguise is lower when starting with condition (1) than with condition (2). The case sec=0 is trivial.

[0093] 2.1.2 Extended CGA++: Moving the signature outside the address generation process Another security improvement involves moving the signature outside the address generation process. Verification then checks that the signature was generated correctly to ensure authentication. This variation is more flexible than the previous one, as it works with any signature scheme.

[0094] The address generation algorithm takes the subnet prefix, the address owner's public / private keys, and the security parameter sec as input. The algorithm is shown in Figure 5 and operates as follows: 1. Set modifier to a random 128-bit value; 2. Hash2 is calculated by hashing the concatenation of modifier, subnetPrefix, and pubKey, and taking the leftmost 112 bits of the resulting hash value; 3. Check if the leftmost 16 × sec bits of Hash2 are zero. If so, proceed to step 4. Otherwise, increment the modifier by 1 and return to step 2; Set the 4.8-bit collisionCount to zero; 5. Calculate Hash1 by hashing the concatenation of modifier, subnetPrefix, collisionCount, and pubKey, and taking the leftmost 64 bits of the resulting hash value; 6. Constitute the interface identifier from Hash1 by encoding the value of sec into the leftmost 3 bits, and by setting the u and g bits (bits 6 and 7 if starting from 0 from the left) to zero; 7. A 128-bit IPv6 address is formed by concatenating a 7.64-bit subnet prefix with a 64-bit interface identifier; 8. Perform DAD as needed. If an address collision is detected, increment collisionCount by 1 and return to step 5. After 3 collisions, stop and report an error; 9. Finally, sign the address with the private key corresponding to the pubKey.

[0095] The verification algorithm takes the address, signature, modifier, subnetprefix, collisionCount, and public key (pubKey) as input and operates as follows: 1. Check that the signature correctly signs the address; 2. Check that collisionCount is equal to 0, 1, or 2; 3. Check that subnetPrefix is ​​equal to the subnet prefix of the address; 4. Calculate Hash2 and check that the leftmost 16 × sec bits of the resulting hash value are zero; 5. Calculate Hash1 and check that it is equal to the interface identifier of the address. The leftmost 3 bits and the differences between the u and g bits are ignored.

[0096] If verification is successful, the binding between the public key and the address is verified. If sec=0, step 4 may be skipped.

[0097] Lemma Theorem 3. Given a network, assume that addresses are generated and verified by the extended CGA++ (modified 2) with the security parameter sec. Thus, the number of request hash function evaluations required to impersonate a particular host is given by the following equation:

number

[0098] Proof: To spoof the target address, we need to find a valid parameter such that (1) the leftmost 16 × sec bits of Hash2 are zero, and (2) the value of Hash1 gives us the target address.

[0099] Starting from condition (1), the attacker needs to find the appropriate modifier. 16×sec ×S gen It is expected that the hash function evaluation will be performed a certain number of times. The probability that the parameter yields the target address is 2. -59 Therefore, this process takes an average of 2 59 It needs to be repeated a certain number of times. Starting from condition (1), the total cost for spoofing is 2 59+16×sec +2 59 This is the result.

[0100] Starting from condition (2), the attacker repeatedly inputs modifier to Hash1 until condition (2) is met. 59 It is expected that this will require two hash function evaluations. Next, the attacker computes Hash2 and verifies that condition (1) is satisfied, which means that 2-16×sec This occurs with a certain probability. In total, the attacker has two Hash2s before condition (1) is met. 16×sec It is expected that calculations will be performed 2 times. Therefore, starting from condition (2), the total cost for spoofing is 2 59+16×sec +2 16×sec This is the result.

[0101] 2.1.3 Extended CGA++: Using signatures as input to Hash2 In addition to including the signature as input to Hash1, another improvement can be made by including the signature as input to Hash2. Therefore, it is no longer possible for an attacker to brute-force the addresses by repeatedly replaying the signature without having to recalculate Hash2.

[0102] In this modification, the source of randomness necessary to satisfy the conditions for Hash2 originates from the signature. Therefore, the modifier value is no longer used in address generation. This has the effect of reducing the size of the data sent to the address verifier by 128 bits.

[0103] The address generation algorithm takes the subnet prefix, the address owner's public / private keys, and the security parameter sec as input. The algorithm is shown in Figure 6 and operates as follows: 1. Sign the subnetPrefix with the private key corresponding to the pubKey; 2. Calculate Hash2 by hashing the signature; 3. Compare the leftmost 16 × sec bits of Hash2 with zero. If they are all zero, proceed to step 4. Otherwise, return to step 1; Set the 4.8-bit collisionCount to zero; 5. Calculate Hash1 by hashing the concatenation of the signature and collisionCount, and taking the leftmost 64 bits of the resulting hash value; 6. Constitute the interface identifier from Hash1 by encoding the value of sec into the leftmost 3 bits, and by setting the u and g bits (bits 6 and 7 if starting from 0 from the left) to zero; 7. A 128-bit IPv6 address is formed by concatenating a 7.64-bit subnet prefix with a 64-bit interface identifier; 8. Perform duplicate address detection (DAD) as needed. If an address collision is detected, increment collisionCount by 1 and return to step 5. After 3 collisions, stop and report an error.

[0104] The verification algorithm takes the address, signature, collisionCount, subnetPrefix, and public key (pubKey) as input and operates as follows: 1. Check that the signature correctly signs the subnetprefix; 2. Check that collisionCount is equal to 0, 1, or 2; 3. Check that subnetPrefix is ​​equal to the subnet prefix of the address; 4. Calculate Hash2 and check that the leftmost 16 × sec bits of the resulting hash value are zero; 5. Calculate Hash1 and check that it is equal to the interface identifier of the address. The leftmost 3 bits and the differences between the u and g bits are ignored.

[0105] If verification is successful, the binding between the public key and the address is verified. If sec=0, step 4 may be skipped.

[0106] Since satisfying the conditions of Hash2 requires iteratively calculating the signature, generating addresses using this technique is more expensive than using CGA++. Compared to CGA, the cost of address generation in CGA++ is an additive factor S.gen It increased due to the multiplicative factor S gen It increases due to this.

[0107] The following describes a method that can make the cost of address generation equivalent to that of CGA++. We assume that the signature is generated using a Digital Signature Algorithm (DSA) such as ECDSA, although this method can also work with other signature algorithms. In this method, the public / private keys are not fixed as inputs to the address generation algorithm, but are given as outputs to the algorithm. Therefore, this method is not suitable if the public key must be fixed, such as having been previously authenticated. We indicate the private key of the address owner by privKey. In ECDSA, the signature for message m is given by a tuple (r,s), where s=(k -1 .H(m)+k -1 .privKey.r) mod p, where k is a temporary key randomly selected from the following equation:

number

[0108] Lemma Theorem 4. Given a network, assume that addresses are generated and verified by the extended CGA++ (modified 3) with security parameter sec. S genIndicates the time required to generate a signature represented in units of hash function evaluation. Therefore, the number of required hash function evaluations for impersonating a specific host is as follows: [Number]

[0109] Proof: To forge the target address, it is necessary to find valid parameters such that (1) the leftmost 16×sec bits of Hash2 are zero and (2) the value of Hash1 yields the target address.

[0110] Starting from condition (1), the attacker is expected to perform 2 16×sec ×(S gen +1) hash function evaluations to find a suitable signature. Since the probability that the signature yields the target address is 2 -59 , this process needs to be repeated 2 59 times on average. Starting from condition (1), the total cost for spoofing is 2 59 (2 16×sec (S gen +1)+1).

[0111] Starting from condition (2), the attacker generates a signature as the input to Hash1 until condition (2) is satisfied. This is expected to require 2 59 ×(S gen +1) hash function evaluations. Next, the attacker calculates Hash2 and verifies that condition (1) is satisfied, which occurs with a probability of 2 -16×sec . In total, the attacker is expected to calculate Hash2 2 16×sec times before condition (1) is satisfied. Therefore, starting from condition (2), the total cost for spoofing is 2 16×sec (2 59 (S gen +1)+1).

[0112] 2.2 Analysis and Comparison Similar to CGA++, Enhanced CGA++ directly introduces authentication into the verification process with the help of signature verification. This eliminates the possibility of the aforementioned replay attack. Furthermore, the global time-memory trade-off attack described by BOS et al. is also impossible with Enhanced CGA++. This is due to including the subnet prefix as input to Hash2. Doing so eliminates the possibility of an attacker creating a database of valid modifier / public key pairs and using it to translate addresses of arbitrary subnet prefixes.

[0113] Table 4 summarizes the comparison between CGA++ and Extended CGA++ when sec > 0. ver S' indicates the time required to verify the signature expressed by the hash function evaluation. For simplicity of notation, S' represents the time required to generate the signature and perform one hash function evaluation. gen Represented as S' gen= S gen Let's add +1. In each variation, impersonation attacks are significantly more difficult than with CGA++. In particular, in each variation, hash extension techniques reduce the cost of impersonation attacks by 2 16×sec It is increased by a multiplicative factor. This restores the effect of hash extension techniques. Table 4: Comparison of CGA++ and Extended CGA++ for IPv6. All timings are expressed in units of hash function evaluation. [Table 4]

[0114] 3. Other Notes Other variations or uses of the disclosed technology may become apparent to those skilled in the art upon disclosure in this specification. The scope of this disclosure is not limited by the embodiments described, but is limited only by the appended claims.

[0115] It will be understood that the embodiments described above are merely illustrative. More generally, methods, apparatus, or programs can be provided in accordance with any one or more of the following statements.

[0116] (Statement 1) A computer implementation method for generating a network address for a network, wherein the method is performed by an address generator, A step of generating an interface identifier, wherein the interface identifier is based on a hash value, and the hash value is based on at least a modifier value, a subnet prefix, a collision count value, and a hash of the public key. The steps include generating the network address based on the subnet prefix and the interface identifier, A step of generating a signature based on the aforementioned network address, wherein the private key used to generate the signature corresponds to the public key, A method that includes this.

[0117] (Statement 2) The method according to Statement 1, wherein the step of generating the interface identifier includes the step of encoding a security parameter into the hash value, and / or setting one or more bits of the hash value to zero.

[0118] (Statement 3) The method according to any one of Statements 1 to 2, wherein the network address is an IPv6 address.

[0119] (Statement 4) The network address is available to one or more parties as described in any of Statements 1 to 3.

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

[0121] (Statement 6) The method of Statement 5, which includes the step of making the signature available to the address verifier.

[0122] (Statement 7) A computer implementation method for verifying a network address for a network, the method being performed by an address verifier, A step of 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. The steps include verifying the candidate signature using the target public key, A step of generating a candidate interface identifier based on a hash value, wherein the hash value is generated based on at least the candidate modifier value, the subnet prefix, the candidate collision count value, and the hash of the target public key. A step of verifying that the candidate interface identifier corresponds to the interface identifier, A method that includes this.

[0123] (Statement 8) The method of Statement 7, which includes the step of verifying that the candidate collision count value is equal to one of a predetermined set of values.

[0124] (Statement 9) A step of generating a candidate hash value based on at least the candidate modifier value, the subnet prefix, and the hash of the target public key, The step of verifying that the candidate hash value contains a predetermined number of leading zeros, The method described in Statement 7 or 8, including the method described in Statement 7 or 8.

[0125] (Statement 10) The method according to any one of Statements 7 to 9, wherein the acquisition step includes receiving one or more of the candidate network address, the target public key, the candidate subnet prefix, and the candidate signature from an address generator configured to generate the candidate network address.

[0126] (Statement 11) The method of any one of statements 7 to 10, which includes the step of transmitting data over the network addressed to the network address in response to verifying the network address.

[0127] (Statement 12) Computer equipment, Memory containing one or more memory units, A processing device including one or more processing units, Includes, A computer device in which the memory stores code configured to be executed on the processing device, and the code is configured to perform the method described in any of statements 1 to 11 when executed on the processing device.

[0128] (Statement 13) A computer program that is embodied on a computer-readable storage device and configured to perform any of the methods described in Statements 1 to 11 when executed on one or more processors.

[0129] Another aspect disclosed in this specification may provide a method including the operation of an address generator and an address verifier. Another aspect disclosed in this specification may provide a system including computer equipment for an address generator and an address verifier.

Claims

1. A computer implementation method for generating network addresses for a network, wherein the method is performed by an address generator, A step of generating an interface identifier, wherein the interface identifier is based on a hash value, and the hash value is based on at least a modifier value, a subnet prefix, a collision count value, and a hash of the public key. The steps include generating the network address based on the subnet prefix and the interface identifier, A step of generating a signature based on the aforementioned network address, wherein the private key used to generate the signature corresponds to the public key, A method that includes this.

2. The method according to claim 1, wherein the step of generating the interface identifier includes the step of encoding a security parameter into the hash value, and / or setting one or more bits of the hash value to zero.

3. The method according to claim 1, wherein the network address is an IPv6 address.

4. The method according to claim 1, wherein the network address is available to one or more parties.

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

6. The method according to claim 5, further comprising the step of making the signature available to the address verifier.

7. A computer implementation method for verifying a network address for a network, wherein the method is performed by an address verifier. A step of 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. The steps include verifying the candidate signature using the target public key, A step of generating a candidate interface identifier based on a hash value, wherein the hash value is generated based on at least the candidate modifier value, the subnet prefix, the candidate collision count value, and the hash of the target public key. A step of verifying that the candidate interface identifier corresponds to the interface identifier, A method that includes this.

8. The method according to claim 7, comprising the step of verifying that the candidate collision count value is equal to one of a predetermined set of values.

9. The steps include generating a candidate hash value based on at least the candidate modifier value, the subnet prefix, and the hash of the target public key, The step of verifying that the candidate hash value contains a predetermined number of leading zeros, The method according to claim 7, including the method described in claim 7.

10. The method according to claim 7, wherein the acquisition step 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.

11. The method according to claim 7, comprising the step of transmitting data over the network addressed to the network address in response to verifying the network address.

12. Computer equipment, Memory containing one or more memory units, A processing device including one or more processing units, Includes, A computer device wherein the memory stores code configured to be executed on the processing device, and the code is configured to perform the method according to claim 1 when executed on the processing device.

13. Computer equipment, Memory containing one or more memory units, A processing device including one or more processing units, Includes, A computer device wherein the memory stores code configured to be executed on the processing device, and the code is configured to perform the method according to claim 7 when executed on the processing device.

14. A computer program that is implemented on a computer-readable storage device and is configured to perform the method described in claim 1 when executed on one or more processors.

15. A computer program that is implemented on a computer-readable storage device and is configured to perform the method described in claim 7 when executed on one or more processors.

Images