JP5780648B2 - Host device - Google Patents

Description

  The present invention relates to a host device that can have ID and locator information.

  Currently, the main methods of authentication involving a host device and the like are classified into three. Symmetric key-based authentication, public key-based authentication, and self-certifiable address authentication.

  Typical symmetric key-based authentication protocols are RADIUS (Non-patent document 1), Diameter (Non-patent document 2), OpenID (Non-patent document 3), and Kerberos (Non-patent document 4). These systems require a symmetric key given in advance, and many of them are used for ID authentication of registered users. Since these systems use a central server, they are not suitable for worldwide use, and the scale is limited. Therefore, it is not appropriate to be used in a name resolution system.

  The current typical public key-based authentication protocol is X.264. 509 (Non-Patent Document 5) and PGP (Non-Patent Document 7). X. In the 509 system, a hierarchical certification authority (CA) is used to establish an authentication chain by authentication between two devices. In addition, the globalized CA is accessed to confirm the validity of the communicator's public key. This again becomes a limitation of use in the name resolution system. The naming framework standard also limits acceptance in the Internet community. The current Internet provides another similar solution using Internet names for the Domain Name System (DNS). This is so-called DNSSEC (Non-Patent Document 6). Here, the security method will be described.

In the current Internet, DNS provides a mapping from host names to IP addresses. This is the name resolution system currently used. DNSs are organized as hierarchical servers, each responsible for a specific part of the DNS database. In the DNS security structure, authentication of data source and data validity are provided by DNSSEC. DNSSEC has adopted the concept of an approved domain. It uses an information resource record such as a DNS public key (DNSKEY), an information resource record signature (RRSIG), a next guarantee (NSEC), and optionally a proxy signer (DS) record. DS records establish an authentication chain between DNS domains. That is, DNSSEC also uses a certification chain to confirm the public key of the area used when signing the information resource record. The structure of the certification authority (CA) in DNSSEC is the X. It is similar to the basic structure of 509 public key. Since the public key infrastructure based on DNSSEC is only used to prove that the result of the solution is actually issued from a server with a specific name, the following problems arise.
1. DNSSEC has no authentication procedure framework for authenticating the identity of the person requesting name resolution in DNS.
2. DNSSEC cannot provide mutual authentication between two devices.
3. DNSSEC employs a chain of trust to establish a trust relationship. Therefore, it requires a well-structured hierarchical certification authority (CA) structure, thereby improving the reliability of the public key. This is inflexible and difficult to extend to future flat structures.
4). Additional access to the public key infrastructure is required in the authentication procedure. This means that each host needs to seek public proof from this infrastructure almost every time it seeks name resolution, which is costly.

  On the other hand, the authentication of the PGP system is based on a recommendation from a known friend, and the correctness of the ID confirmation cannot be completely guaranteed. Thus, it is unacceptable for use in a resolution system.

  All of the above security measures add to the network structure. In recent years, self-certifiable addresses have been designed to authenticate nearby when employing IPv6. This method can also be said to be public key-based, but naturally the public key is connected to the address so that the address can be self-certified. The protocol is an address (CGA; Non-Patent Document 8) generated by a so-called encryption technique. The basic idea of CGA is to obtain a cryptographic hash of a public key by calculation and generate an interface ID (for example, 64 bits on the right side of IPv6) from an IPv6 address. The obtained IPv6 address is called an address generated by an encryption technique. CGA is designed for authentication at the neighbor and authenticates the neighboring host. This is limited in scale.

International Publication No. 2011-088658 Pamphlet

C. Rigney, S. Willens, A. Rubens, W. simpson, “Remote Authentication Dial In User service (RADIUS)”, RFC 2865. P.Calhoun, J.Loughney, E.Guttman, G.Zorn, J.Arkko, “Diameter Base Protocol”, RFC 3588. OpenID, http://openid.net/ C. Neuman, T. Yu, S. Hartman, and K. Raeburn, “The Kerberos Network Authentication Service (V5)”, RFC 4120. R. Housley, W. Ford, W. Polk, and D. Solo, “Internet X.509 Public Key Infrastructure-Certificate and Profile”, RFC 2459. R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose, “DNS Security Introduction and Requirements”, RFC 4033, Mar. 2005. J.Callas, L.Donnerhache, H.Finney, D.Shaw, and R. Thayer, “OpenPGP Message Format”, RFC 4880. T. Aura, “Cryptographically Generated Addresses (CGA)”, RFC 3972, Mar. 2005.

  An object of the present invention is to provide a host device that can improve self-protection in a host device that can have ID and locator information.

  In order to solve the above problem, a host device according to an aspect of the present invention includes at least a second ID that is an ID of the own device and a session key based on a first ID that is an ID of a key server. Means for encrypting the first information to generate the first cipher information; means for sending the first cipher information to the key server; and the key server decrypting the first cipher information. The second information including at least the secret key generated by the key server corresponding to the second ID is converted into the second encryption information by encryption using the session key obtained by decryption by the key server. When the server signature, which is the signature of the key server, is attached and sent from the key server, the second cryptographic information and the means for receiving the server signature are verified, and the validity of the server signature is verified. Means, Based on the means obtained by decrypting the secret key with the session key from the second encryption information and the third ID as the ID of the registration resolution server that is a server for registering and solving the global host name of the local apparatus The third information including at least the global host name, the second ID, and the locator of the own device is encrypted to generate third encrypted information, and the third device information is signed to the third encrypted information. And means for sending the third encryption information and the device signature to the registration resolution server.

  In addition, the host device according to another aspect of the present invention attaches its own device signature to the first information including at least information indicating that resolution of the global host name of the destination device to be communicated is requested. Means for sending to a first registration resolution server that is a server for resolving a domain name; a first ID as an ID of a second registration resolution server that is a server for registering and resolving the global host name; The second information including at least the first locator which is the locator of the second registration resolution server is set as the first encryption information by encryption based on the second ID which is the ID of the own device, and the first information Means for receiving the first encryption information and the first server signature when the first server signature, which is a signature of the registration resolution server, is attached and sent from the first registration resolution server; Based on the first ID, means for verifying the validity of the first server signature, means for decrypting the first ID and the first locator from the first encryption information, Means for encrypting third information including at least information indicating that the global host name is requested to be resolved, and generating second encrypted information; and adding a signature of the device to the second encrypted information. 4th information including at least a second ID that is sent to the registration information server, a third ID that is an ID of the destination device, and a second locator that is a locator of the destination device. When it is sent from the second registration resolution server with the second server signature, which is the third encryption information by the encryption based on the ID and the signature of the second registration resolution server, The third encryption information and Means for receiving a second server signature; means for verifying the validity of the second server signature; and means for decrypting the third ID and the second locator from the third encryption information It is characterized by comprising.

  In addition, the host device according to still another aspect of the present invention includes the first information including at least the global host name of the own device that is the transmission source based on the first ID of the transmission destination device that is to communicate. Means for encrypting and generating first cipher information; means for attaching the device's own signature to the first cipher information and sending it to the destination device; a session key and a random number generated by the destination device The second information including at least a number is a second encryption by encryption based on a second ID which is an ID of the own device that the destination device can resolve the global host name using a name resolution system. Means for receiving the second encrypted information and the device signature when the information is sent and the device signature, which is a signature of the destination device, is sent from the destination device; rightfulness Means for verifying, means for obtaining the session key and the random number from the second encryption information, means for generating the third encryption information by encrypting the random number based on the session key And means for sending the third encryption information to the destination device.

  Further, the host device according to another aspect of the present invention includes means for attaching a signature of the device itself to the new locator information of the device itself and sending the information to the destination device, and the information of the new locator of the device itself. And a means for sending the information to the registration resolution server, which is a server for registering and resolving the global host name of the own apparatus.

  According to the present invention, self-protection can be improved in a host device that can have ID and locator information.

Explanatory drawing which shows the procedure in which the host apparatus which is embodiment performs registration and name resolution. Explanatory drawing which shows the procedure which performs the locator update of the host apparatus which is embodiment. The block diagram explaining the basic mechanism of ID base encryption (IBE). The block diagram explaining the basic mechanism of ID base signature (IBS). FIG. 3 is an explanatory diagram showing a structure of a proactively reliable ID / locator separation framework (PTISF) in which the host device according to the embodiment can be incorporated. Explanatory drawing (FIG. 6 (a)) which shows the structure of the domain name registry server (DNR) system in PTISF, and explanatory drawing which shows the structure of the edge network in PTISF (FIG.6 (b)). Explanatory drawing which shows the registration procedure to DNR of a host name registry server (HNR) in PTISF in time series. FIG. 4 is an explanatory diagram showing, in chronological order, a procedure for registering an HNR of a host apparatus according to an embodiment in PTISF. FIG. 9 is a continuation diagram of FIG. 8, and is an explanatory diagram showing, in chronological order, a registration procedure to the HNR of the host device according to the embodiment in PTISF. FIG. 3 is an explanatory diagram showing, in chronological order, procedures when a host device according to an embodiment performs name resolution in PTISF. FIG. 11 is a continuation diagram of FIG. 10, and is an explanatory diagram showing, in chronological order, procedures when the host apparatus according to the embodiment performs name resolution in PTISF. Explanatory drawing which shows the procedure when the host apparatus which is embodiment in PTISF performs mutual authentication with a transmission destination host apparatus in time series. Explanatory drawing which shows the procedure of the update of the locator to the transmission destination host apparatus performed when the host apparatus which is embodiment moves in PTISF in time series.

  Based on the above, embodiments of the present invention will be described below with reference to the drawings as appropriate.

(Preparations for explanation)
The current Internet structure cannot satisfy future social needs. It is necessary to redesign the Internet from the beginning and build a new generation network (NWGN). Toward the structure in NWGN, we proposed the concept of HIMALIS (Heterogeneity Inclusion and Mobility through Locator ID Separation). In HIMARIS, an ID (identifier) and a locator are separated.

  The HIMALIS structure provides a new naming framework that shapes host names and IDs. In HIMALIS, a global host name is formed by connecting a local host name and a domain name using a symbol “#” representing a connection, and becomes the only name in the world. For example, “sensor-temp-room-5-202 # my-domain.com”. The host ID is generated by connecting the encrypted hash value of the global host name and additional parameters to the prefix, scope, and version fields. That is, host ID = prefix + version + scope + hash (global host name, parameter). Hereinafter, the term “host name” simply means a global host name, not a local host name.

  HIMALIS mainly consists of a local edge (ie, access) network, a global information transfer network, and a unified logical control network. In HIMALIS, three configurations are introduced: a domain name registry server (DNR), a host name registry server (HNR), and an ID registry server (IDR). The DNR stores the correspondence between domain names and IDs and locators of HNRs that manage host names in several domains. The HNR stores a mapping between host names in several domains and their IDs and locators. The IDR stores and distributes the connection between the host ID and the locator of the mobile device. DNR and HNR are used to register names and resolve host names as locators at the initialization stage of communication. On the other hand, the IDR is used to update and distribute the connection between the host ID and the locator in the network. These configurations inherently integrate heterogeneous network layer protocols used in different edge networks into the global WWGN through network nodes, including gateways, and are independent of their temporal changes. The main functions of HIMALIS consist of name registration and resolution and locator update, which will be described next.

  The steps of host name registration and resolution are shown in FIG. The registration step includes step 1.1 and step 1.2. In step 1.1, the name of the HNR 21 and its ID and locator are registered in the DNR 31 belonging to the DNR system 3S. Step 1.2 registers the host name of the host 11 and its ID and locator in the HNR 21. The mapping procedure consists of two sub-procedures: domain name reference and host name reference, and is steps 2.1 to 2.4. In steps 2.1 and 2.2, the host 12 uses the DNR 31 to resolve the domain name of the host 11 as the ID and locator of the HNR 21 (= name resolution, which may be simply referred to as “resolution” below). In steps 2.3 and 2.4, the host 12 uses the HNR 21 to resolve the host name of the host 11 as a host ID and a locator.

  The step of updating the locator information of the host 11 is shown in FIG. FIG. 2 is an explanatory diagram illustrating a procedure for updating the locator of the host device according to the embodiment. This update step includes two procedures, corresponding node (CN) update and HNR update. The CN update is issued as an update request to the CN, as shown as steps 1.1 through 1.6, and the CN approves this request. As shown in steps 2.1 through 2.4, an HNR update is issued to the HNR, and the HNR approves this request. In FIG. 2, reference numerals 1N1, 1N2, and 1N3 are edge networks, respectively, and reference numeral 12 is a host that communicates with the host 11 (the same reference numerals shown in FIG. 1). Reference numerals 41, 42, and 43 are gateways that connect the edge networks 1N1, 1N2, and 1N3 to the logical control network 100, respectively. Reference numerals 51, 52, and 53 are IDRs corresponding to the gateways 41, 42, and 43, respectively. It is. The HNR 21 is the same as that shown in FIG.

  In order to make HIMALIS widely used in future networks, it is important to consider that these procedures provide reliable interaction between devices in the network. That is, it is preferable to remove the threat as a structural level at the stage of designing an ID / locator separation structure such as HIMALIS. Threats can arise in four steps: That is, when an HNR / host registers its ID and locator, when one host requests to resolve the name of another host as an ID and locator, when one host communicates with another host, and Is when the locator is updated. In these procedures, attackers may launch spoofing attacks, intermediate intervention attacks (MIMA), or repeated attacks.

  Impersonation attacks can have different forms in each of the above procedures. In the registration procedure, an attacker may hit a legitimate HNR or host and impersonate and register the ID, or hide the true identity against the legitimate DNR or legitimate HNR. There is a possibility to register for. In the name resolution procedure, an attacker may obtain a legitimate DNR or HNR, provide false information to the host, and perform a DoS attack or site hijacking. In addition, an attacker may hit a legitimate host and obtain information from the DNR or HNR illegally, or may fill a fake message so as to interrupt the operation of the DNR or HNR. Also, in the communication procedure, an attacker could impersonate a legitimate host and trick other personal hosts. Similarly, the attacker may notify the CN or HNR of fake locator update information and disconnect the normal mutual communication with a specific host.

  MIMA can be performed by tampering with outgoing messages by an attacker with intermediate intervention. For example, an attacker who intervenes between the host and the HNR may change the registration information of the host, and may change the mapping information in the transmitted resolution result. In repeated attacks, past packets are repeatedly sent because the attacker achieves his / her personal purpose.

  Embodiments of the present invention incorporate and embed security features in the HIMALIS structural design stage. This allows self-protection of the structure itself from the above attacks.

  In this embodiment, ID-based encryption technology including ID-based encryption (IBE) and ID-based signature (IBS) is used. This is because this technique has a great advantage in self-providing ID. Here, the basic function will be described.

  The basic mechanism of IBE is shown in FIG. With IBE, sender Alice can encrypt the message using the ID of recipient Bob (reference 1A). The recipient Bob can decrypt (decipher) the ciphertext using the secret key (PKBob) obtained from the key server (KS) 3 (reference numeral 2A). The basic functions in IBE are as follows. 1) Preparation: KS3 selects a bilinear group and public parameters (PPS) including hash function information, and generates a master key MK and a corresponding public key PubKKS. In FIG. 3, PubKKS and PPS are notified to both Alice and Bob. 2) Key generation: KS3 generates a secret key for the user using the function KeyGen (MK, ID) based on the ID of the user (Bob). In FIG. 3, Bob obtains its private key PKBob. PKBob is associated with Bob's ID, PubKKS and PPS. 3) Encryption: The communicator (Alice) encrypts the message using Bob's ID. In FIG. 3, Alice encrypts message M and obtains ciphertext C using Bob's ID. 4) Decryption: The communicator (Bob) decrypts the ciphertext using the secret key. In FIG. 3, Bob decrypts the ciphertext from Alice using his private key PKBob to obtain a plaintext message.

  The basic mechanism of IBS is shown in FIG. With IBS, the sender Alice signs the message M using the secret key, and sends the signed message SigAlice to the recipient Bob (reference numeral 1B). Recipient Bob can verify the validity of the signature using Alice's ID (reference 2B). The basic functions in IBS are as follows. 1) Preparation: KS3 selects a bilinear group and a PPS, and generates a master key MK and a corresponding public key PubKKS. 2) Key generation: KS3 generates a secret key for the user using the function KeyGen (MK, ID) based on the ID of the user (Alice). This function may be the same as or different from that in IBE. In FIG. 4, Alice obtains a secret key PKAlice corresponding to the ID. 3) Signature: The communicator (Alice) signs the message using the private key. In FIG. 4, Alice signs the message M, uses PKAlice, and obtains the signature SigAlice. 4) Authentication: The communicator (Bob) can verify the signature using Alice's ID. In FIG. 4, Bob verifies the signature from Alice using Alice's IDAlice. In the following description, for simplicity, the function KeyGen (MK, ID) is described as being the same as that in IBE. If they are not the same, two secret keys (for encryption and signature) are generated for the host.

  IBE and IBS have the advantageous feature that they can be authenticated without the intervention of a reliable third party. That is, after obtaining PubKKS, communicators can directly authenticate each other and can determine whether the communicators have a specific ID.

Abbreviations are described below for reference. This is also used in the following description.
1. KS: Key server PubKKS: the public key corresponding to the KS master key (does not belong to one specific host)
3. PPSX: Public parameters selected by KS currently held in device X IDX: ID of device X
5. PKX: private key of device X corresponding to IDX of device X SigX: its signature made using IBS signature technology with the private key PKX of device X7. {M} IDX: Message encrypted using IDE of device X using IBE encryption technology8. TM: Time stamp 9. Nk: random number generated at time k10. SK: Session key (symmetric key)
11. DNR: Domain name registry server (first registration resolution server: server that registers and resolves domain names)
12 HNR: Host name registry server (second registration resolution server: server that resolves global host names)
13. IDR: ID registry server 14. DomainTP: Domain trust point (key server for edge network)
15. DNR KS: Key server for domain name registry server system 16. GW: Gateway 17. {M} SK: Message encrypted by SK with symmetric encryption technology

(Confirmation of problems in the embodiment)
We intend to make HIMALIS, a new ID / locator separation system, self-protecting and embedding reliability in the entire system. Current technology is not compatible with HIMALIS systems due to various limitations such as scale and frequent access to the authentication infrastructure by add-ons. Therefore, it is desired to design a proactively reliable ID / locator separation structure that has immunity under various attacks. That is, the following procedure is designed.
1. Reliable registration: mutual authentication between the host and the HNR or between the HNR and the DNR is performed to ensure that the registration information between the host and the HNR is not tampered with by an intermediate device The past packet is not repeated. This is an attempt to avoid spoofing attacks, MIMA, and repeated attacks in the registration procedure.
2. Reliable ID / locator resolution: to ensure that mutual authentication between the host and the DNR and between the host and the HNR is done. This is to avoid impersonation attacks in the resolution procedure. It also includes trying to avoid MIMA and repeated attacks.
3. Mutual authentication between hosts: Ensuring that the owner of a communication host with one specific ID can be verified. This attempts to avoid spoofing attacks, MIMA, and repeated attacks.
4). Reliable locator update: Ensuring the correctness of the ID when the host notifies the move. This attempts to stop spoofing attacks, MIMA, and repeated attacks.

  From the above, it can be seen that this embodiment is intended for the design of a global authentication framework combined with an ID / locator separation system such as HIMALIS. Thereby, it is possible to notify each device of the true ID of the communication device that provides information with this structure.

(Direction of problem solving)
In order to embed self-protection in HIMALIS, a proactively reliable ID / locator separation framework (PTISF) is proposed. This allows each device used in the registration, resolution, communication, and locator update procedures to authenticate each other in order to obtain reliable information. In PTISF, if IBE and IBS are used as a basis, a reliable third party is not required, and the feature in ID authentication is ensured. Therefore, this is adopted as a basic security function.

  The overall structural layout of PTISF is shown in FIG. This is the same as HIMALIS in the following points. That is, this structure mainly consists of local edge (ie, access) networks 1N1, 1N2,..., 1N3, a global information transfer network 200, and a unified logical control network 100. In addition, the same code | symbol is attached | subjected to the same or equivalent thing as what was shown in the already demonstrated figure. The information transfer network 200 may include gateways 44, 45, 46,... In addition to the gateways 41, 42,.

  Next, two new devices are introduced in order to give HMALIS built-in security. .., 63 and a DNR key server (DNRKS) 71 shown in FIG. 5, and the HNR has some additional functions. Domain trust points (domain TP) 61, 62,..., 63 in FIG. 5 are key servers having IBE and IBS functions in one domain. For example, it can be a service provider of a local network, a logical management server of a corporate network, a physical domain control server, or the like. One edge network 1N1, 1N2,..., 1N3 may be provided with one or more domain TPs for one or more host groups. The domain TP holds a secret master key in the service destination domain, and notifies the corresponding public key PubKDomainTPs and public parameters PPs. It is also responsible for generating the private key PKHostx for the host that intends to register with the network service.

  As shown in FIG. 5, there is one or more domain TP61 (63) in the area that one HNR 21 (22) is in charge of. The HNR 21 (22) itself receives a service in one domain trusted by one domain TP61 (63). One domain TP 61 (63) serves only one HNR, serves a plurality of HNRs, or serves one HNR and many shared devices. The HNR 21 (22) also needs to notify the devices in the service area of the public key and PPs of the domain TP61 (63) to be serviced.

  The structure in which the domain TP services one domain and the HNR services a plurality of domains makes the setting for trusting the domain flexible. That is, the size of a domain and the physical or logical definition of the domain can be variously determined by different operators.

  Another new device DNR key server (DNRKS) 71 is a key server having functions of IBE (ID base encryption) and IBS (ID base signature) in the domain name registration system as shown in FIG. . This server 71 holds the master key and notifies its corresponding public keys PubKDNRKS and PPs in the DNR system to the HNR and to the host registered in the network service. Also, secret keys PKDNRX are generated for all DNRs 31 to 36 in the DNR system 3S.

  As shown in FIG. 5, the domains TP61, 62,..., 63, HNR21, 22, ..., and DNRKS 71 form the whole trusted system. The domains TP61, 62,..., 63 are for constructing a single trusted domain, and the HRNs 21, 22,... Serve a plurality of trusted domains, The DNRKS 71 gives reliability to the entire DNR system 3S. These three configurations provide reliability to the registration procedure, resolution procedure, communication procedure, and locator update procedure, so that the network structure naturally supports authentication. The PTISF of the embodiment consists of six main parts. 1. DNR system and reliable domain security settings. 2. Reliable registration. Here, secure registration of the HNR, the domain TP, and the host is performed. 3. Reliable solution and mutual authentication. Secure DNR name resolution, HNR name resolution, and global mutual authentication between two hosts are described. 4). Reliable locator update. Here, a procedure for secure update to the CN (corresponding node) and a procedure for secure update to the HNR are provided. 5. cancel. Here, the list of revoked hosts is maintained to avoid resolving names and connecting to compromised hosts. 6). caching. The host has a function of caching the ID, public key, and parameters of the frequently connected host. This allows for quick authentication and name resolution. Each of the above portions will be described in detail next.

(1. Setting of DNR system and reliable domain security)
The DNR system 3S is composed of hierarchical DNRs 31 to 36 that resolve domain names as HNR IDs and locators. For example, there are six DNRs 31 to 36 in the DNR system 3S shown in FIG. In order to enable the DNR system 3S to provide a reliable name resolution service, DNRKS 71 is introduced, and secret keys are generated for these DNRs 31 to 36 based on ID-based encryption technology. In this system 3S, the DNRKS 71 generates one master key and one public key corresponding thereto in the security functions of IBE and IBS. Then, the public keys PubKDNRKS and PPs are notified to all the DNRs 31 to 36. When a new DNR is added, a secret key corresponding to the ID based on the ID-based encryption technology is generated for this DNR, and PubKDNRKS and PPs are sent. After the basic configuration, in the DNR system 3S, each of the DNRs 31 to 36 holds PubKDNRKS, PPs, and their secret keys. For example, DNRX.A31 holds IDDNRX.A, PubKDNRKS, and PKDNRX.A. The communicator can encrypt the message sent to DNRX.A31 using IDDNRX.A, and DNRX.A31 uses PKDNRX.A to indicate that it is an authenticated source. Can sign.

  Similarly, the domain TP61,... Is responsible for generating a secret key and notifying the router, gateway, and host of the public key. After the basic configuration in FIG. 6B, the gateway 41 has PubKdomainTP and PKGW, the router 91 (R1) has PubKdomainTP and PKR1, and the access point 81 (AP1) has PubKDomainTP and PKAP1. The host 11 (X) has PubKDomainTP and PKHostX. The same applies to the routers 92 (R2), 93 (R3),.

  Further, since the HNR 21 needs to belong to one reliable domain, the private key PKHNR corresponding to the identifier IDHNR is acquired from the domain TP61. Furthermore, the domain TP 61 needs to register its own information in the HNR 21. The domain TP 61 serves only the HNR 21, services a plurality of HNRs, or services a single HNR with many devices including a GW, a router, and a host. Is to do.

(2. Reliable registration)
After basic security configuration settings, the HNR, domain TP, and host need to be registered so that they can be searched. When registering, the devices involved in registration need to authenticate each other to avoid the spoofing attacks already described. That is, when one HNR registers with DNRX.Y, it is necessary to confirm the ID of DNRX.Y, and DNRX.Y needs to confirm the correct configuration setting of this HNR. Similar requests occur in the domain TP and host registration procedures.

  FIG. 7 shows the HNR registration procedure. When one HNR tries to register with the DNR system, the HNR can obtain the PubKDNRKS and DNRS PPS from a trusted location such as a DNR service center. As shown in FIG. 7, since the HNRA does not know which DNR is serving for itself, the HNRA sends a registration request to the DNR system. The DNR system makes a decision that DNRX.Y will record HANRA, and DNRX.Y contacts HNRA to tell its identifier IDDNRX.Y to HANRA so that it can register. Here, an IBS signature is appended to the message to avoid spoofing attacks and MIMA. The random number Nl is used for authentication, and the time stamp TM1 is used to avoid repeated attacks. After receiving this information, HANRA can verify the validity of this IBS signature SigIDDNRX.Y using IDDNRX.Y and PubKDNRKS. By passing this check, the HNRA can be sure that the communicator is truly DNRX.Y. The HNRA includes {domain name, HNR ID and locator, PubKDomainTPHNRA, PPSHNRA, N1} encrypted with IDDNRX.Y, and N2 and TM2, and can send information with the signature SigHNRA . When DNRX.Y receives this information, the message is first decoded by the IBE decoding function to obtain PubKDomainTPHNR. Then, if this information exists, it is checked whether it matches the information already registered, and further, the validity of SigHNRA is verified by IBS confirmation. If all inspections are passed, all information of HANRA is registered. Finally, an acknowledgment (ACK) is returned to the HANRA.

  In the secure HNR registration procedure, mutual authentication of the HNR and the corresponding DNR is performed. Also, the DNR can check the validity of the information provided from the HNR, and MIMA and repeated attacks are avoided.

  When a domain is served by one HNR, the domain TP needs to be registered in the HNR by the domain TP registration procedure, which is the same as the registration of the HNR in the DNR. Domain TP first requests registration to HNR, HNR responds with its ID, and domain TP is HNR ID, domain name, domain TP ID and locator, PubKDomainTP, and random number Encrypt and sign the encrypted message. When the HNR receives this message, it decrypts it, obtains public information, and verifies the validity of the signature. Further, the domain TP information is registered in the HNR recording unit. The HNR then sends PubKDNRKS and PPSDNRKS to the domain TP. These can be used by the domain TP when performing host registration and when doing DNR resolution for the domain TP and host. Further, when a new domain TP is registered in the HNR, it is necessary to register the new domain information in the DNR so that the DNR can correctly resolve the host name. This procedure is the same as HNR registration, but different information such as {new domain name, HNR ID and locator, IDDomainTP, PubKDomainTP, PPSDomainTP} is registered.

  The host registration procedure has two phases. The first phase 1 is to obtain a secret key corresponding to the ID of the host from the domain TP as shown in FIG. The next phase 2 is to register the host information in the HNR and notify its existence as shown in FIG.

  FIG. 8 shows phase 1, which allows host A to obtain network services in the domain served by domain TP. When the owner of the host A receives service from the domain TP, it is necessary to obtain a home router (HR) from the service center. Alternatively, the owner of the host A can use the HR already provided in the house. After the home router B is provided as shown in FIG. 8, the host A can obtain from the home router B the IDDomainTP, PubKDomainTP, and PPSDomainTP that are preloaded in the home router B in the service center. The host A then services the domain TP by sending IDHostA (ID of its own device), SK, Nl, and TMl (encrypted information including the above) encrypted with the ID of the domain TP that is the key server. Request. The SK (session key) is a symmetric key, which is used for secure communication between the host A and the domain TP. When the domain TP receives this information, it decrypts the message using the IBE function and determines whether to accept the request. If the determination is yes, the domain TP uses the IBE and IBS key generation procedures to generate a secret key PKHostA corresponding to IDHostA toward the host A. The domain TP then sends {IDHost, PKHostA, PubKDNRKS, PPSDNRS, IDHNR, PubKHNR, PPSHNR, Nl, TM2} encrypted with the session key SK, along with the signature. PubKDNRKS is used to mutually authenticate host A and the DNR server when host A inquires about DNR resolution. On the other hand, IDHNR and PubKHNR are used in phase 2 of HNR registration. When this message is received by the host A, the host A verifies the signature of the domain TP, decrypts it with the session key, obtains its private key PKHostA, and installs it. Finally, host A sends IDHostA, N2, and TM3 with the IBS signature SigHostA attached. When the domain TP receives this message, the domain TP can verify the legitimacy of SigHostA and can be confident that PKhostA has been correctly installed by the host A.

  FIG. 9 shows phase 2, which allows Host A to register information with the HNR after completing the installation of its private key. Since the host A obtains the HNR information from the domain TP, the host A encrypts the information including the host name, the host ID and locator, IDDomainTP, PubKDomainTP, PPSDomainTP, Ni, and TMi with the HNR ID. Add signature SigHostA and send to HNR. The HNR checks whether domain TP information such as IDDomainTP is valid, and then verifies the validity of SigHostA. If all checks pass, the HNR stores the information of the host A including the information of the domain TP in the storage unit. The contents of the storage can be obtained by the correspondent during the resolution procedure and then used for mutual authentication.

(3. Reliable solution and mutual authentication)
When a host tries to communicate with another host, the host needs to request the network to resolve the name of the communicator as a locator. This is a so-called solution procedure and includes two phases, DNR resolution and HNR resolution, as already mentioned. Therefore, a reliable solution is also introduced in these two phases. That is, a secure DNR solution and a secure HNR solution.

  The procedure for secure DNR resolution is shown in FIG. In FIG. 10, Host1 # DomainX makes a resolution request for Host2 # DomainY (global host name of the destination device) to the DNR system. Host 1 sends its signed request message with a random number and timestamp to the DNR system. When the DNR system receives this message, it determines that DNRz will handle this request. DNRz obtains Domain X PubKDomainTPHNRX and PPSDomainTPHNRX from the DNR system. This is possible because PubKDomainTPHNRX is registered in the DNR system when domain TP registration is performed. Then, DNRz verifies the validity of SigHost1 by PubKDomainTPHNRX and IDHost1. If these checks are passed, the DNRZ searches for and obtains information on the HNRY serving the domain Y and encrypts it with the IDHost1. Finally, DNRZ adds its signature to the message and sends it to Host1. Upon receiving this packet, the host 1 verifies the validity of SigDNRZ, decodes the message, and acquires the HNR information of Host2 # DomainY.

  After the corresponding HNR information is obtained, secure HNR resolution is performed as shown in FIG. In the secure HNR resolution procedure, the host 1 has acquired IDHNRY, LocatorHNRY, PubKHNRY, and PPSHNRY. The host 1 requests the NRRY with a random number and a time stamp to resolve Host2 # DomainY encrypted with IDHNRY and accompanied by the signature SigHost1. When receiving this packet, the NRRY searches for the public key of the domain X locally and verifies the validity of SigHost1. When the verification is completed, the HANRY returns the information of the host 2 including IDHost2, LocatorHost2, PubKHost2, and PPSHost2 to the host 1. These pieces of information are encrypted with IDHost1 and accompanied by SigHNRY. The host 1 verifies the signature, decrypts the encrypted information, and finally acquires the information of the host 2.

  In many cases, mutual authentication is required for reliable communication. In the above resolution procedure, the source host obtains the ID, locator, public key, and public parameters of the destination host, which is confirmation of the source for the destination host. However, in this procedure, the transmission destination host cannot confirm the ID of the transmission source host. This is because if only one-way resolution is performed, the destination host cannot have information on the source host that can be confirmed. The destination host also executes a resolution procedure in the other direction so that the information of the source host can be acquired. As a result, the destination host can acquire the ID, locator, and public key of the source host by PTISF. Then, mutual authentication between the transmission source host and the transmission destination host can be performed smoothly. The authentication procedure is shown in FIG.

  In order to perform mutual authentication, the host 1 generates a random number N1, adds information such as the global host name of the host 1 as shown in the figure, and further encrypts it with IDHost2 by the IBE encryption function. The host 1 sends this information to the host 2 with a signature. Upon receiving this information, the host 2 resolves Host1 # DomainX, obtains its public key, IDHost1, PubKHost1, and further verifies SigHost1. When the verification is completed, the host 2 generates a symmetric session key (SK) and a random number N2 encrypted with the ID Host1 and accompanied by the signature. Host 1 verifies and decrypts SigHost2 and obtains SK and N2. Then, N2 is encrypted by SK and sent to the host 2, whereby a secure communication channel is established between them.

(4. Reliable locator update)
If host 1 moves from one location of the network to a different location, host 1 needs to update its new locator for CN, host 2 and the responsible HNR.

  Regarding the locator update to the host 2 in FIG. 13, the host 1 sends out a new locator Locator 2 with the signature. Upon receiving this packet, the host 2 verifies the validity of this signature. If the verification is successful, the host 2 replaces the locator Locator1 of the old host 1 with the new locator Locator2.

  The same procedure is executed when updating the locator to the HNR. Since the public key of the host 1 is known to the HNR, the HNR can easily confirm the legitimacy of the host 1 and update its locator.

(5. Cancellation)
When a host's private key is compromised, a revocation procedure is necessary. For this, two methods can be employed. One is that an expiration time is added to the host ID, and the host ID is automatically invalidated after that point. The other is that each HNR maintains a revocation list of hosts, and the HNR only maintains a list of revoked hosts that have been serviced in that service area. In this cancellation list, all canceled host names and IDs are accumulated. In the resolution procedure, even if the DNR resolution is successful, the HNR checks whether the requested destination host is on the revocation list. Then, the latest ID of the destination host is confirmed. If it is on the revocation list or if the latest ID has expired, an error message is returned to the originating host. Otherwise, normal HNR resolution is performed.

(6. Caching)
In order to improve mutual authentication operations, each host maintains a memory that caches the ID and locator of the responsible HNR, the public key, and parameters of the host that communicates to some degree frequently. When one host tries to start communication with another host, it checks whether the information exists in the memory. If the source host information is cached in the destination host, the HNR resolution and mutual authentication are performed directly using the cache information without mutual resolution.

(Effect of embodiment)
According to the present embodiment, the following effects can be obtained.
1. The host and HNR can register such information in the network system with high reliability. This is because mutual authentication between HNR and DNR or between host and HNR is possible, and MIMA and repeated attacks can be avoided.
2. The source host is reliable and can resolve the name of the destination host as its ID / locator and corresponding public key. This is because mutual authentication between the transmission source host and the DNR and mutual authentication between the transmission source host and the transmission destination host are performed. The source host can also authenticate the true ID of the destination node.
3. Mutual authentication between hosts can be performed. After the mutual name resolution procedure, the two hosts can obtain the identity of the communicator and the public key of its domain TP. Thereby, mutual authentication is smoothly performed before communication is started.
4). The connection between ID and locator can be updated with high reliability. This is because the CN and the corresponding HNR know the ID and public key of the host that needs to be updated. Therefore, the CN and the corresponding HNR can easily confirm the validity of the received update packet.

  1N1, 1N2, 1N3 ... edge network, 3 ... key server, 3S ... domain name registry server system (DNR system), 11, 12 ... host, 21, 22 ... host name registry server (HNR), 31, 32, 33, 34, 35, 36 ... Domain name registry server (DNR), 41, 42, 43, 44, 45, 46 ... Gateway, 51, 52, 53 ... ID registry server, 61, 62, 63 ... Domain trust point, 71 ... DNR key server, 81 ... access point, 91, 92, 93 ... router, 100 ... unified logical control network, 200 ... global information transfer network.

Claims (6)

Means for generating first encrypted information by encrypting first information including at least a second ID that is an ID of the own device and a session key based on a first ID that is an ID of the key server;
Means for sending the first cryptographic information to the key server;
The key server decrypts the second information including at least the secret key generated by the key server corresponding to the second ID obtained by decrypting the first encryption information by the key server. When the second encryption information is encrypted by the session key and is sent from the key server with the server signature being the signature of the key server, the second encryption information and the server A means of receiving a signature;
Means for verifying the validity of the server signature;
Means for decrypting the secret key with the session key from the second encryption information;
Based on a third ID that is an ID of a registration resolution server that is a server that registers and resolves the global host name of the own device, the global host name of the own device, the second ID, and a locator of the own device are at least Means for encrypting the third information to generate third encrypted information and attaching the device signature to the third encrypted information;
A host device comprising: means for sending the third encryption information and the device signature to the registration resolution server. The first encryption information is encryption information obtained by encrypting information obtained by further including a random number and a time stamp in the first information,
The third cipher information encrypts information obtained by further including a second random number different from the random number and a second time stamp different from the time stamp in the third information. The host device according to claim 1, wherein the encryption information is obtained by converting the encryption information. A first registration which is a server for registering and resolving a domain name by attaching its own device signature to first information including at least information indicating that a resolution of a global host name of a destination device to be communicated is requested Means for sending to the resolution server;
Second information including at least a first ID that is an ID of a second registration resolution server that is a server that resolves the global host name and a first locator that is a locator of the second registration resolution server, The first registration resolution is performed by encryption based on the second ID, which is the ID of the own device, and the first encryption information is added, and the first server signature, which is the signature of the first registration resolution server, is added. Means for receiving the first cryptographic information and the first server signature when sent from a server;
Means for verifying the validity of the first server signature;
Means for decrypting the first ID and the first locator from the first cryptographic information;
Means for generating second encrypted information by encrypting third information including at least information requesting resolution of the global host name based on the first ID;
Means for attaching a self-signature to the second encryption information and sending it to the second registration information server;
The fourth information including at least a third ID which is an ID of the destination device and a second locator which is a locator of the destination device is encrypted based on the second ID, and third encrypted information is obtained. And when the second server signature, which is the signature of the second registration resolution server, is attached and sent from the second registration resolution server, the third encryption information and the second encryption information A means of receiving a server signature;
Means for verifying the validity of the second server signature;
Means for decrypting the third ID and the second locator from the third encryption information. The first information is information further including a random number and a time stamp;
In addition to the device signature, a second random number different from the random number and a second time stamp different from the time stamp are attached to the second encryption information, and the second registration information server 4. The host device according to claim 3, wherein transmission is performed. Means for encrypting the first information including at least the global host name of its own device as a source based on the first ID of the destination device to be communicated, and generating the first encrypted information;
Means for attaching the device's own signature to the first encryption information and sending it to the destination device;
Second information including at least a session key and a random number generated by the destination device is the ID of the own device that the destination device can resolve the global host name using a name resolution system. The second encryption information and the second encryption information when the second encryption information is sent from the destination device with the device signature being the signature of the destination device. A means of receiving a device signature;
Means for verifying the validity of the device signature;
Means for decrypting the session key and the random number from the second cryptographic information;
Means for encrypting the random number to generate third encrypted information based on the session key;
Means for sending the third cipher information to the destination device. Means for attaching the self-device signature to the information of the new locator of the self-device and sending it to the destination device;
A host apparatus comprising: means for attaching the self apparatus signature to the information of a new locator of the self apparatus and sending the information to a registration resolution server that is a server for resolving the global host name of the self apparatus. .

Images