JP2015208043A - host device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a host device capable of improving the self protection property.SOLUTION: An own device signature is added to first information at least including information that requests for resolution of a name held by an origination destination device to be reached. The first information and the own device signature are transmitted to a system structured to include a registration server for registering second information related to the origination destination device so that the system can find the registration server. When the second information is transmitted from the registration server after transformed to encrypted information by encryption based on an ID of the own device and incorporated with a server signature that is a signature of the registration server, the encrypted information and the server signature are received, and justifiability of the server signature is verified, and then, the second information is obtained by decryption from the encryption information.

Description

  The present invention relates to a host device that may have relevant necessary information such as an IP address and a locator.

  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 highly reliable NMS (Name Mapping System).

  The current typical public key-based authentication protocol is X.264. 509 (Non-Patent Document 5) and PGP (Pretty Good Privacy: 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. In the current Internet, another similar solution using the Internet name is provided for the domain name system (DNS: Non-Patent Document 9). This is so-called DNSSEC (Non-Patent Document 6).

DNSSEC provides data origin authentication and data validity for DNS. 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 lacks flexibility.
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.

  Next, as NMS, the basic specification of LISP + ALT is provided in Non-Patent Document 10. The protection method is mainly sBGP (Non-Patent Document 11) or soBGP (Non-Patent Document 12). They also use a structured CA, which provides a reliable registration of distributed routing information. Similarly, access to the basic structure of the additional public key is required to protect against information exchange in the ALT subsystem.

  As described above, X.X. It is clear that 509 CA systems, DNSSEC, LISP + ALT all have significant limitations in achieving security requirements on the NMS. In other words, it requires the intervention of a reliable third party and does not function simply.

  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. Therefore, it is not acceptable for use with NMS.

  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. Since NMS is a global name resolution system, this is a limitation 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. P. Mockapetris, “Domain Names-Concepts and Facilities”, RFC 1034, Nov. 1987. D. Farinacci, V. Fuller, D, Meyer, and D. Lewis, “LISP Alternative Topology (LISP + ALT)”, draft-fuller-lisp-alt-05.txt, Feb. 24, 2009. S. Murphy, “BGP security Analysis”, draft-murphy-bgp-sccr-04 (work in progress), November 2001. R. White, “Architecture and Deployment Considerations for Secure Origin BGP (soBGT)”, draft-white-sobgparchitecture-00 (work in progress), May 2004.

  An object of the present invention is to provide a host device capable of improving self-protection in a host device that can have related necessary information such as an IP address and a locator.

  The host device which is a reference mode encrypts the first information including at least the name of the device and the session key based on the first ID which is the ID of the key server, and generates the first encrypted information And means for sending the first encryption information to the key server, and the key server generates the first encryption information for the device corresponding to the name obtained by decrypting the first encryption information by the key server. The second information including at least the second ID that is the ID and the secret key generated by the key server corresponding to the second ID is based on the session key obtained by decrypting the key server When it is sent from the key server with the first server signature, which is the second cryptographic information by encryption and the signature of the key server, the second cryptographic information and the first Hand that receives the server signature Means for verifying the validity of the first server signature, means for decrypting the secret key with the session key from the second encryption information, and a registration server as a server for registering information about the host Means for sending information to request registration of the own device to the structured system including the second ID, and at least a third ID that is an ID of the registration server Means for receiving the third information and the second server signature when the third information is sent from the registration server with the second server signature being the signature of the registration server; And means for verifying the validity of the second server signature, and based on the third ID, encrypts fourth information including at least the name of the own device to generate third encrypted information, And based on the secret key Comprises means for generating the self-device signature, and means for sending the third cipher information and the own-device signature to the registration server.

  In addition, the host device according to one aspect of the present invention attaches its own device signature to the first information including at least information indicating that the name of the destination device to be communicated is requested, and The system can find the registration server with respect to a structured system including a registration server for registering the second information, which is information related to the first device and the second device information relating to the destination device. And the second information is sent from the registration server with the server signature that is the signature of the registration server added to the encryption information based on the ID of the own device. Sometimes, means for receiving the encryption information and the server signature, means for verifying the validity of the server signature, and means for decrypting the second information from the encryption information.

  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 the name of the destination device to be communicated is requested, and Means for sending to a hierarchical system including a registration server for registering second information which is information relating to the destination device, and a first high-order server as a server located above the registration server in the system The second information, which is the information related to the server, is the first encryption information obtained by encryption based on the first ID, which is the ID of the own device, and is positioned higher in the hierarchy than the first upper server. Means for receiving the first encryption information and the first server signature when the first server signature, which is a signature of the upper server, is attached and sent from the second upper server; 1 server Means for verifying the validity of the name; means for decrypting the third information from the first encrypted information; and attaching the device signature to the first information, The means for sending to the server and the fourth information, which is information relating to the registered server, are the second encryption information by encryption based on the first ID and are the signatures of the first host server. Means for receiving the second encryption information and the second server signature when the server signature of 2 is sent from the first host server, and the validity of the second server signature Means for verifying, means for obtaining the fourth information from the second encrypted information, means for attaching a self-device signature to the first information, and sending to the registration server; The second information is encrypted based on the first ID and becomes the third encryption information. And means for receiving the third encryption information and the third server signature when a third server signature, which is a signature of the registration server, is attached and sent from the registration server; Means for verifying the validity of the server signature, and means for decrypting the second information from the third encryption information.

  In addition, the host device according to still another aspect of the present invention includes an ID including information on the first name that is the name of the own device, and a second name that is the name of the destination device to be communicated. Means for attaching the device signature to the first information including at least the first information and sending it to the destination device, and second information including at least a session key and a random number generated by the destination device, After the device applies the first name to the name resolution system and the public key and public parameter of the own device are acquired by the destination device, the first encryption information is obtained by encryption based on the ID. Means for receiving the first encryption information and the device signature when a device signature, which is a signature of the destination device, is attached and sent from the destination device, and the validity of the device signature. Means to verify Means for decrypting the session key and the random number from the first encryption information; means for generating the second encryption information by encrypting the random number based on the session key; And means for sending the encrypted information of 2 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 structured system including a registration server which is a server for registering information related to the self apparatus with the self apparatus signature.

  According to the present invention, self-protection can be improved in a host device that can have related necessary information such as an IP address and a locator.

Regardless of the description below, the illustrations of FIGS. 9, 10, and 11 and the description referring to them are not related to the embodiments of the invention, but are shown and described as reference aspects. However, the content to be referred to as an embodiment of the invention is included.
Explanatory drawing which shows the general network structure provided with exclusive NMS including the positioning of a host apparatus. Explanatory drawing which shows the procedure of the registration and name resolution (in the case of a recursive system) which a host apparatus performs using DNS. Explanatory drawing which shows the procedure of the registration and name resolution (in the case of an iterative system) which a host apparatus performs using DNS. Explanatory drawing which shows the procedure of the name resolution which a host apparatus performs using LISP + ALT. 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. 2 is an explanatory diagram showing a general network structure with improved reliability in which the host device according to the embodiment can be incorporated. Explanatory drawing (FIG. 8 (a)) which shows the structure of the NMS subsystem in the network with improved reliability, and explanatory drawing (FIG. 8 (b)) which shows the structure of the edge domain (ED) in the network. FIG. 3 is an explanatory diagram showing, in chronological order, a registration procedure of a host apparatus according to an embodiment to an NMS subsystem in a network with improved reliability. FIG. 10 is a continuation diagram of FIG. 9, and is an explanatory diagram showing, in chronological order, a registration procedure of the host device according to the embodiment to the NMS subsystem in the network with improved reliability. Explanatory drawing which shows the information exchange procedure between the NMS apparatuses in the NMS subsystem SSi appearing in FIG. 10 in time series. FIG. 4 is an explanatory diagram showing, in a time series, procedures when a host device according to an embodiment performs name resolution (in the case of a recursive method) using a single subsystem in a network with improved reliability. FIG. 3 is an explanatory diagram showing, in a time series, procedures when a host apparatus according to an embodiment performs name resolution (in the case of an iterative method) using a single subsystem in a network with improved reliability. FIG. 14 is a continuation diagram of FIG. 13, illustrating a time series of procedures when the host device according to the embodiment performs name resolution (in the case of an iterative method) using one subsystem in a network with improved reliability. Figure. FIG. 15 is an explanatory diagram briefly illustrating FIG. 12, FIG. 13 and FIG. FIG. 3 is an explanatory diagram showing, in a time series, procedures when a host device according to an embodiment performs name resolution using a subsystem located in a preceding stage in a network with improved reliability. Description in chronological order of procedures when name resolution is performed using a subsystem in which the host device according to the embodiment is finally located in a network with improved reliability, which is performed following the procedure illustrated in FIG. Figure. FIG. 3 is an explanatory diagram showing, in chronological order, procedures when a host device according to an embodiment performs mutual authentication with a destination host device in a network with improved reliability. Explanatory drawing which shows the procedure of the locator update to the transmission destination host apparatus performed when the host apparatus which is embodiment moves in the network with improved reliability 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, NMS)
A typical network structure with a dedicated NMS is shown in FIG. As shown in FIG. 1, the network structure usually consists of a data plane and a control plane. The data plane used for data transfer includes an edge domain (ED) 1N1, 1N2,..., 1N3 and a global information transfer network (GTN) 200. The edge domains 1N1, 1N2,..., 1N3 provide convenience of network access and intra-domain information transfer to the hosts 11 and 12, which are end hosts. The edge domain 1N1 or the like may include a base station 81 or a router 91. On the other hand, the information transfer network 200 is a set of service provider backbone networks and is used for transferring information between domains. The information transfer network 200 is usually provided with gateways 41 to 49.

  The NMS 100 that is the control plane is designed to map the host name in the network of FIG. 1 to a host locator and other RNI (Related Necessary Information). The host name is a unique name assigned to the host, and the host locator is a connection (attach) point for the host to connect to the network.

  Naming methods can be classified into two categories: hierarchical naming and flat naming. Both have advantages and disadvantages depending on the situation. Hierarchical naming is adopted for possible future structures such as the Internet and LISP. On the other hand, other structures related to overlay technology (overlay technology) are named flat structures.

  The NMS 100 generally has a plurality of NMS subsystems. For example, as shown in FIG. 1, the NMS 100 includes an NMS SS1 that is one NMS subsystem 100A and an NMS SSk that is another NMS subsystem 100B. Different NMS subsystems have different roles throughout the NMS, and they act as a chain for name resolution. Typically, the first subsystem provides its RNI with the host name as input, the intermediate subsystem provides its further RNI with the RNI provided by the previous subsystem as input, and the last subsystem as the host Provide a locator and another additional RNI. These subsystems are optionally connected or disconnected. One NMS subsystem has one or more NMS devices (NMSE) used for name registration and resolution, and they are configured in a hierarchical structure or a flat structure. In FIG. 1, NMS devices 31h to 36h of NMS SS1 have a hierarchical structure, and NMS devices 31f to 35f of NMS SSk have a flat structure. The NMSE stores the correspondence (mapping) between the host name and the RNI of this host. Examples of RNI include an ID, a locator, a public key, a public parameter, an IP address, and an end point identifier. The host name, public key, and public parameter are positioned as basic information stored in the NMSE in the embodiment described below. To obtain the locator and RNI, the host name is attached to one or more resolution procedures in one subsystem or multiple subsystems.

  The fundamental function of the NMS subsystem is to respond to name resolution queries. As a common matter, there are two name resolution modes, recursive mode and iterative mode, for resolving names as RNI in one subsystem. On the other hand, the relationship between different subsystems is always an iterative mode. In one subsystem, in recursive mode, the NMSE issues a name resolution request to the corresponding NMSE that arrives in this subsystem directly in a recursive manner. In response to this, the corresponding NMSE returns the RNI of the target host to the requester or proxy requester. Hereinafter, for the sake of simplicity, the term “requester” includes both the first requester and the proxy requester. In one subsystem, in repeat mode, the NMSE then repeats responding the corresponding NMSE's locator to the requester multiple times, and finally the corresponding NMSE returns the target host's RNI to the requester. If the NMS has only one subsystem, the resulting RNI is the final requested RNI, such as an IP address in DNS. When the NMS includes a plurality of subsystems, the name resolution procedure needs to be further continued. Such continuous name resolution is performed as an iterative mode between different subsystems. That is, the name resolution result obtained from the previous subsystem is returned to the requester, and based on this, the requester initiates a new request to the new subsystem. Finally, the RNI of the target host is obtained as a resolution result by the last subsystem.

  Here, in order to explain the NMS described above with a general network structure, DNS and LISP + ALT will be described. These are typical NMS.

(DNS)
DNS is a core function of the Internet, and associates host names with IP addresses. DNS uses a DNS server (DNSS), which is equivalent to NMSE, which means a name server in DNS. Since DNS is one system, there are no other subsystems in this NMS. DNS employs a hierarchical naming scheme such as tokyo-u.ac.jp. DNS in DNS is hierarchically configured as a tree structure. The database is divided into sections called zones and distributed among the DNSS. Each DNSSS is responsible for zones that are adjacent areas in the DNS namespace. That is, the DNSS functions for a part of its subtree. The DNSS responds to queries about hosts in that zone.

  DNS supports both recursive and iterative modes. In the recursive mode, the DNSS performs a recursive operation and issues a name resolution request directly to the corresponding DNSS that has been reached. In response, the corresponding DNSS returns the IP address of the target host to the requester. In repeat mode, the DNSSS then repeatedly responds to the requester with the IP address of the corresponding DNSSS, and finally the corresponding DNSSS returns the IP address of the target host to the requester. The IP address is nothing else but the information requested from the host, so no separate subsystem is required for further name resolution (hereinafter “name resolution” may be simply referred to as “resolution”).

  An example of the host name registration resolution step in the DNS recursion mode is shown in FIG. In FIG. 2, the same or equivalent parts as shown in FIG. In FIG. 2, DNS servers 31 to 37 are provided corresponding to the NMSEs 31h to 37h. In step 1 which is a registration step, the host name and its IP address are registered in the DNS 110. DNSSSZ.A.X, which is a corresponding DNS server (DNSS) 37, is Host2.P, which is the name of the host 11P shown in FIG. Z. A. X is stored in association with the IP address information. In the name resolution procedure, first, a resolution query is sent to the local DNS server (LDDNSS) 30L. Next, the local DNS server 30L sends an inquiry to the base (root) server DNSS0 (DNS server 31). If the server cannot give an answer, it sends the query to the “closest known” trusted DNSS. Finally, the corresponding DNSSS (DNS server 37) returns the IP address of the host corresponding to the host name to the local DNS server 30L, and the local DNS server 30L transfers the resolution result to the requesting host. As shown in FIG. 2, the procedure for name resolution is steps 2.1 to 2.7.

  On the other hand, name resolution in the iterative mode in DNS is shown in FIG. 3 as an example. In FIG. 3, parts that are the same as or equivalent to those shown in the already described figures are given the same reference numerals. The procedure for name resolution is steps 2.1 to 2.10. First, Host1. K. C. The Y host 12 sends a resolution query to the local DNS server 30L in the DNS 120, and the local DNS server 30L sends the query to the base server (DNS server 31). In repeated queries, the DNSSS may return a list containing a plurality of DNSSSs to the local DNS server 30L each time. In that case, the local DNS server 30L selects one of them as the next DNSSS and sends the next inquiry. For simplicity, in the figure, a single IP address is specified as the next DNSSS. In this iterative mode procedure, the intermediate DNSSS returns the IP address of the next DNSSS, and the local DNS server 30L repeats the query accordingly. Finally, the local DNS server 30L obtains the IP address of the target host and provides this result to the requester (host 12).

  Note that the host may need to update its IP address when changing the connection while maintaining its name. In such a case, two procedures of updating to the corresponding host (CH) and updating to the DNS are necessary. To update the CH, an update request is sent to the CH, and the CH updates its address and acknowledges this request. For a DNS update, an update request is sent to the corresponding DNSSS, which updates the address and acknowledges this request.

(LISP + ALT)
LISP + ALT is another typical NMS example. In LISP + ALT, an endpoint identifier (EID) is used as a host ID, while a routing locator (RLOC) is used as a locator. EID and RLOC use hierarchical naming as their method. This NMS has two subsystems called DNS and an alternative topology (ALT) that function like the Internet. The DNS subsystem resolves the host name as host EID, while the ALT subsystem resolves the host EID as host RLOC. The NMSE in the DNS subsystem has a hierarchical structure, while the NMSE in the ALT subsystem has a flat structure.

  The DNS subsystem supports both recursive and iterative modes. On the other hand, in the ALT subsystem, an ETR (egress tunnel) in which the LISP uses BGP (Border Gateway Protocol) to send update information of the EID prefix and maintains the correspondence from the EID to the RLOC of the EID prefix • Operation occurs so that the request is forwarded to the router. That is, the ALT subsystem supports only recursive mode. After resolution by the DNS system, an intermediate RNI containing the target host EID is obtained by the requester. Then, an ITR (Ingress Tunnel Router) that is a proxy requester uses this EID to send a name resolution request to the ALT subsystem. The intermediate NMSE, the ALT server, recursively forwards this request until ETR is reached. The ETR returns the corresponding RLOC, which is the final request RNI for the host, to the requesting ITR. It should be noted that the two subsystems have different requesters. In the DNS subsystem, the requester is the host itself, while in the ALT subsystem there is a proxy requester ITR.

  An iterative resolution procedure with two subsystems in LISP + ALT is shown in FIG. 4 as an example. In FIG. 4, parts that are the same as or equivalent to those shown in the already described drawings are given the same reference numerals. The response resolution procedure in the DNS subsystem 130 includes steps 1.1 to 1.5. Host1. K. C. Y host 12 sends a resolution request to DNS subsystem 130 via local DNS server 30L, and DNS subsystem 130 performs a recursive or iterative procedure through Host DNS server 30L. K. C. It returns EIDHost2 to Y. Then, iteratively, the ITR 21 executes the response resolution procedure steps 2.1 to 2.3 in the ALT subsystem 140. The ITR 21 makes a request with the EID obtained in the initial response resolution procedure to the ALT subsystem 140, so that the ALT subsystem 140 performs recursive resolution, and RLOCHost2 which is the RLOC of the host 11P to the ITR 21 Reply. Reference numeral 22 denotes the ETR described above.

(threat)
Each NMS described above is vulnerable under various attacks. Such a threat can occur in the following five procedures. 1) When one host registers its name and RNI, 2) When NMSE exchanges registration information, 3) When one host requests name resolution of another host, 4) One When a host communicates with another host, 5) When one host updates its information. In these five procedures, an attacker may launch a spoofing attack, intermediate intervention attack (MIMA), or repeated attack.

  Impersonation attacks can have different forms in each of the above procedures. In the registration procedure, an attacker may hit a legitimate host and impersonate and register the hostname or RNI by impersonation, or register the host for the legitimate NMSE while hiding its true identity. There is a possibility to do. In the information exchange procedure, an attacker may attempt to hide the true identity and provide the legitimate NMSE with false information to other NMSEs, causing the NMS to malfunction. In the name resolution procedure, an attacker may hit a legitimate NMSE and provide fake information to the host to do a DoS attack or take over the site. In addition, an attacker may hit a legitimate host and obtain information from the NMS illegally, or may expose a fake message to interrupt the operation of the NMS. Also, in the communication procedure, an attacker could impersonate a legitimate host and trick other personal hosts. Similarly, the attacker may notify the CH or NMSE of a fake RNI and disconnect the legitimate 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 NMSE 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 into a typical worldwide NMS structure. This allows self-protection of the structure itself from the above attacks.

(IBE, IBS)
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 message M 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. 5, 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. 5, Bob obtains its secret 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. 5, 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. 5, Bob decrypts the ciphertext from Alice using the secret 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 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. 6, Alice obtains a secret key PKAlice corresponding to the ID. 3) Signature: The communicator (Alice) signs the message using the private key. In FIG. 6, 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. 6, Bob verifies the signature from Alice using Alice's IDAlice.

  The master key, public key, public parameter, and key generation function may be the same or different between IBE and IBS. In the following description, for the sake of simplicity, they will be described as being the same in IBE and IBS.

  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 and PPsKS, the communicator can directly authenticate each other and can determine whether the communicator has a specific ID.

(Abbreviation)
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 parameter selected by KS currently held in device X4. NameX: Host name of device X IDX: ID of the device X, which has a format in which an expiration time is added to NameX.
6). 6. PKX: device X private key corresponding to device X IDX SigX: its signature made using the IBS signature technology with the private key PKX of device X8. {M} IDX: Message encrypted using IDE of device X using IBE encryption technology9. TM: Time stamp Nk: random number generated at time k11. SK: Session key (symmetric key)
12 NMSE: NMS (Name Mapping System) device 13. RNI: Relevant necessary information registered in the MNS subsystem 14. RNISSiHostk: RNI of host k registered in NMS subsystem SSi
15. ED: edge domain 16. EDKS: edge domain key server 17. SS: NMS subsystem 18. SSKS: Key server for NMS subsystem 19. GW: Gateway 20. {M} SK: Message encrypted with symmetric encryption technology by SK 21. ||: Addition operator

(Confirmation of problems in the embodiment)
We intend to make the NMS self-protecting and embed reliability in the entire system. Current technology is not suitable due to various limitations such as scale and frequent access to the authentication infrastructure by add-ons. Therefore, it is desired to design a self-protectable secure NMS (S ² NMS) that has immunity under various attacks. That is, the following procedure is designed.
1. Reliable registration: Mutual authentication between the host and the NMSE is performed to ensure that the host registration information is not tampered with an intermediate device, while past packets are not repeated. This is an attempt to avoid spoofing attacks, MIMA, and repeated attacks in the registration procedure.
2. Reliable exchange of information within a subsystem or within an edge domain: This is to ensure that the information delivered in one SS or one ED was provided by a self-proclaimed one It is guaranteed. It also includes trying to avoid MIMA and repeated attacks.
2. Reliable name resolution: Ensuring that mutual authentication occurs between the host and the NMSE in one SS in recursive or iterative resolution. Also, make sure that iterative solutions across SSs are protected. 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 name can be verified. This attempts to avoid spoofing attacks, MIMA, and repeated attacks.
4). Reliable correspondence update: Ensuring that the host name is indeed its own name when the host notifies the move. This is intended to prevent 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 with NMS. Thereby, each apparatus can be made to know the true identity of the communication apparatus which provides information with this structure.

(Direction of problem solving)
An NMS (S ² NMS) having a self-protection property and high reliability by embedding self-protection property in the NMS structure is proposed. This enables the devices used in the registration, information exchange, resolution, communication, and correspondence update procedures to authenticate each other for reliable information acquisition. In this S ² NMS, if IBE and IBS are used as the basis, the feature in name authentication that a trusted third party is not necessary is guaranteed, and this is adopted as a basic security function.

The overall structural layout of the S ² NMS is shown in FIG. This is the same as a general network in the following points. That is, this structure includes, as a premise, local edge domains 1N1, 1N2,..., 1N3, a global information transfer network 200, and an NMS 100 that is a control plane. In addition, the same code | symbol is attached | subjected to the same or equivalent thing as what was shown in the already demonstrated figure.

  Next, two new devices are introduced to incorporate security into this NMS structure. , 63 and NMS subsystem key server (SSKS) 71, 72,... Shown in FIG. EDKS is a key server having functions of IBE (ID base encryption) and IBS (ID base signature) in one domain. For example, it can be a service provider of a local network, a logical management server of a corporate network, or a physical domain control server. Each of the edge domains 1N1, 1N2,..., 1N3 may be provided with one or more EDKSs for one or more host groups. The EDKS holds the secret master key in its service destination domain, and transmits the corresponding public key PubKEDKS and the public parameter PPsEDKS. It is also responsible for generating the private key PKHost for the host that is about to register with the network service.

  As shown in FIG. 7, an NMSSS key server (SSKS) 71, which is another new apparatus, is a key server having IBE and IBS functions in one NMSSS. The server 71 or the like holds the master key and notifies the corresponding public keys PubKSSKS and PPsSSKS in the NMS subsystem to the host registered in the network service. Also, secret keys PKNMSE are generated for all NMS devices 31h to 36h and 31f to 35f of the NMSSS (NMS subsystems 100A and 100B). There may be a plurality of SSKS in one SS. In the following, for simplification, it is assumed that there is one SSKS in one SS.

  As shown in FIG. 7, EDKS 61, 62,..., 63, and SSKS 71 are shaped so that the entire system is trusted. The EDKSs 61, 62,..., 63 are for constructing one trusted ED, while the SSKS 71 and the like are for imparting reliability to one NMSSS. These configurations provide reliability to the registration procedure, information exchange procedure, resolution procedure, communication procedure, and correspondence update procedure, so that the network structure is naturally supported for authentication.

The NMS (S ² NMS) structure of the embodiment is composed of the following six main parts (components). 1. ID format and security settings. An ID format capable of revoking the secret key is introduced. It also shows the security settings in the NMS and one trusted ED. 2. Reliable registration. Here, the host and EDKS secure registration will be described in detail. 3. Reliable information exchange with one SS or one ED. This information exchange is to allow the NMSE in one SS or the device in one ED to exchange correspondence and routing information securely. 4). Reliable solution and mutual authentication. A secure recursive or iterative resolution step is designed to avoid various attacks that can be set up during the name resolution procedure in one SS. It is also designed to perform an iterative solution between SSs to protect the entire solution chain. In addition, global mutual authentication between two hosts is detailed. 5. Reliable correspondence update. Here, a secure update procedure to the CH and a secure update procedure to the SS are provided. 6). cancel. Here, automatic revocation of private keys and maintenance of a list of revoked hosts are provided. This prevents resolving or connecting to a host that has been compromised. Each of these components will be described in detail next.

(1. ID format and security settings)
NMS is a system that associates a host name with a host RNI for communication. IBE and IBS are adopted as security mechanisms. When the host name is directly used as a host ID for authentication, a secret key corresponding to this host name is generated and used. However, for safety, the private key must be revoked at regular intervals, which means that the host name needs to be changed frequently. In the same way, if the private key corresponding to a name is compromised, this name will be almost unusable. If the host name is directly adopted as the host ID for authentication, this situation becomes unacceptable.

In order to solve this problem, the host name is not directly used as the host ID. That is, in the registration procedure, EDKS gives the host a host ID that is a NameHost with an expiration time as the host name as in the following format. The expiration time is the registration time plus the expiration period.
IDHost = NameHost || Expiration time (for example, IDHost1 = Host1.K.C.Y || 2011110081200)

  As an example of IDHost, the host name of the host 1 is Host1. K. C. When it is Y, IDHost1 expires at 12:00 on October 8, 2011, for example.

  This host ID and the corresponding private key are provided to the host by the EDKS performing the service. When registering the host name and RNI in the NMS subsystem (SS), this ID is used to authenticate the identity of the host, but it is not registered in the NMS as it is, but only the host name is registered. In the name resolution procedure, the mutual authentication procedure, and the locator update procedure, this ID is used for mutual authentication, but the name resolution itself uses the host name, that is, the host name portion of the ID.

  The above ID format is introduced, and then security settings for SS and ED are introduced. The SS has a hierarchical or flat structure NMSE for resolving host names or RNIs. For example, in the NMS subsystem 100K shown in FIG. 8A, there are six NMSEs 31h to 36h (these are hierarchical structures, but the same applies when a flat NMSE is provided. 36h). In order to enable the NMS to provide a reliable name resolution service, SSKS 71K is introduced into the NMS subsystem 100K, and secret keys are generated for these NMSEs 31h to 36h based on ID-based encryption technology. In this subsystem 100K, the SSKS 71 generates one master key and one public key corresponding to the master key, similarly to the security functions of IBE and IBS. The public key PubKSSKSk and its PPs, PPsSSKSk, are notified to all NMSEs 31h to 36h. When a new NMSE is added, the SSKS 71 generates an ID based on the name and the expiration time, and further generates a secret key corresponding to the ID for the NMSE 31h to 36h based on the ID-based encryption technology. Send PubKSSKSk and PPsSSKSk to NMSE. After the basic configuration, in the subsystem 100K, each of the NMSEs 31h to 36h holds IDNMSE, PubKSSKSk, PPsSSKSk, and its secret key PKNMSE. For example, NMSE36h which is NMSE6 holds IDNMSE6, PubKSSKSk, PPsSSKSk, PKNMSE6. The communicator can encrypt the message sent to NMSE 36h using IDNMSE6, and NMSE 36h can sign the message using PKNMSE6 to indicate that it is an authenticated source.

  Similarly, the ED key server 6M in one ED is responsible for generating an ID and a secret key and notifying the router, gateway, and host of the public key and public parameters. As illustrated in FIG. 8B, after the basic configuration, the gateway 4M has PubKEDKSm, PPsEDKSm, IDGW, and PKGW, and the router 91 (R1) has PubKEDKSm, PPsEDKSm, IDR1, and PKR1, The base station 81 (BS1) has PubKEDKSm, PPsEDKSm, IDBS1, and PKBS1, and the host 11 (X) has PubKEDKSm, PPsEDKSm, IDHostX, and PKHostX. The same applies to the routers 92 (R2), 93 (R3),.

(2. Reliable registration)
After basic security configuration settings, the host and EDKS need to be registered so that they can be retrieved. Different RNIs can be registered in different subsystems, but when registered in one subsystem, the devices involved in registration need to authenticate each other to avoid the spoofing attacks already described. That is, when a host registers with NMSEk, which is the NMSE serving it, that host needs to confirm the identity of NMSEk, and NMSEk needs to confirm the correct configuration of this host. A similar request occurs in the EDKS registration procedure.

  The host registration procedure has two phases. As shown in FIG. 9, the first phase 1 is to obtain the ID of the own apparatus and the corresponding private key from EDKS. In the next phase 2, as shown in FIG. 10, the host name and RNI are registered in the subsystem and the existence thereof is notified.

FIG. 9 shows an example of phase 1, which allows the host 1 named NameHost1 to obtain network services in the ED served by EDKSm. In order for the owner of the host 1 to receive a service from the ED, it is first necessary to obtain a home router (HR) from the service center. Alternatively, the owner of the host 1 can use the HR already provided in the house. After the home router B is provided as shown in FIG. 9, the host 1 can obtain IDEDKSm, PubKEDKSm, and PPsEDKSm preloaded in the home router B in the service center from the home router B. The host 1 then requests service from the EDKSm by sending the host 1 name, SK, Nl, and TMl (encrypted information including the above) encrypted with the ID of the key server EDKSm. The SK (session key) is a symmetric key, which is used for secure communication between the host 1 and EDKSm. When EDKSm receives this information, it uses the IBE function to decrypt the message and determine whether to accept the request. If the decision is yes, EDKSm generates an ID such as IDHost1 = NameHost1 || expiration time for host 1, and then uses the IBE and IBS key generation procedures to create a private key corresponding to IDHost1. Generate PKIDHost1. Then, the EDKSm sends {IDHost1, PKIDHost1, PubKSSKSl, PPsSSKSl, N1, TM2} encrypted with the session key SK along with the signature SigIDEDKSm. Here, PubKSSKSl and PPsSSKSl are generalized meanings of public keys and public parameters required in each subsystem. Hereinafter, for the sake of simplicity, it is assumed that PubKSSKSl and PPsSSKSl represent each. PubKSSKSl and PPsSSKSl are used for mutual authentication between the host 1 and the NMSE in the SSl when the host 1 requests registration and name resolution from the SSl. When the host 1 receives the message with the signature SigIDEDKSm, the host 1 verifies the signature and decrypts it with the session key to obtain the ID Host1 that is the ID and the secret key PKIDHost1, and installs it. Finally, the host 1 sends IDHost1, N2, and TM3 with the IBS signature SigIDHost1 attached. When this message is received by EDKSm, EDKSm can verify the validity of SigIDHost1, which provides confirmation that host 1 has correctly installed PKIDhost1.

  FIG. 10 shows phase 2, whereby the host 1 registers its information in one subsystem after completing the installation of its ID and corresponding private key. Since the registration procedure to another subsystem is the same, the registration procedure to SSi will be described as an example in the illustration of the procedure. In this procedure, the host 1 first sends a registration request to the SSi, which is the NMS subsystem, with its ID ID Host1. The SSi discovers the NMSEk which is the NMSE that performs the service correspondingly, and the NMSEk returns IDNMSEk, Ni, and TMi to the host 1 with the signature SigIDNMSEk. The host 1 verifies the signature SigIDNMSEk by using IDNMSEk and verifies the validity of this information. Then, the host 1 generates information including the signature SigIDHost1, including {name of the host 1, RNI of the host 1, PubKEDKSHost1, PPsEDKSHost1, Ni} encrypted with IDNMSEk, and TMj. Send to NMSEk. On the other hand, NMSEk verifies the validity of SigIDHost1, decrypts the message, and checks whether the host name and EDKS information are valid. If all inspections are passed, all information of the host 1 including EDKS information is registered. The EDKS information can be obtained by the communication device in the name resolution procedure and is then used for mutual authentication.

  The host name, public key, and public parameters are basic registration information, and these need to be registered in all subsystems (SS). Note that different RNIs can be registered in different SSs. For example, in a LISP + ALT NMS, EID information is registered in the DNS subsystem, while RLOC routing information is registered in the ALT subsystem.

  In the secure host registration procedure, mutual authentication of the host and its corresponding NMSE is performed. At that time, the NMSE can check the validity of the information provided from the host, and MIMA and repeated attacks are also avoided by using random numbers and time stamps.

  When an ED is intended to be serviced by one EDKS, the EDKS needs to be registered with the NMS subsystem by an EDKS registration procedure. This is similar to the registration of the host to the NMS. PubKSSKSi and PPsSSKSi are pre-loaded into EDKS. EDKS makes a registration request to the NMS subsystem, to which the specific NMSE of SSi responds with its ID, so EDKS returns the ED name, EDKS name, EDKS locator, PubKEDKS, PPsEDKS, and random number Encrypt with the NMSE ID and attach the signature. When the NMSE receives this message, it decrypts it, obtains public information, and verifies the validity of the signature. Then, EDKS information is registered. Similarly, EDKS registers that information in all subsystems.

(3. Reliable information exchange within one SS or one ED)
The registered RNI may be other possible information in addition to ID, locator, and routing information. The situation of information exchange within one SS can occur in response to the need to share the RNI within that SS. Therefore, performing identity authentication for an information provider within one SS is provided by secure information exchange.

  In one SS, there is one key server SSKS that generates a key for the NMSE existing therein and notifies a public key and public parameters. So all NMSEs have the same public key PubKSSKS and public parameters PPsSSKS. A reliable information exchange procedure is shown in FIG. In FIG. 11, the NMEx in the SSi tries to provide information to the NMSEk, and sends out the information to be provided, IDNMSEx that is the current ID, and Nj and TMj together with the signature SigIDNMSEx. When NMSEk receives this message, it verifies SigIDNMSEx and registers the provided information after passing the verification.

  Even within one ED, similar procedures can be performed when exchanging routing information between devices such as routers, GWs, and other devices.

(4. Reliable solution and mutual authentication)
When a host tries to communicate with another host, the host needs to request the NMS to resolve the name of the communicator as a locator. This is a so-called solution procedure. Since the NMS has one or more subsystems, the solution procedure is either a single SS solution or a continuous solution in multiple SSs. There can be two methods for resolving mode within one SS: recursive method and iterative method. On the other hand, as already described, when spanning between SSs, only the iterative method is used as the relationship with them. Because of these, a reliable solution in NMS is also realized as three parts. That is, reliable recursive and iterative solutions within one NMS subsystem and reliable iterative solutions between NMS subsystems.

  FIG. 12 shows a procedure for secure name resolution in the case of the recursive method in one NMS. In FIG. 12, the host 1 makes a request for resolution of NameHost2, which is the name of the host 2 (destination apparatus), to SSi which is one NMS subsystem. The key server of this subsystem is SKSSi. Host 1 sends a request message with its signature SigIDHost1 along with IDHost1, NameHost2, N1 and TM1 to NMSEm. When NMSEm receives this message, it forwards this request to the next NMSE0. Due to the transfer of such a request, the request finally arrives at the NMEx that performs the corresponding service. NMEx obtains PubKEDKSHost1 and PPsEDKSHost1 from this subsystem. This is possible because the host and EDKS are already registered in the subsystem when they are registered. Then, NMEx verifies the validity of SigIDHost1 using PubKEDKSHost1, PPsDEKSHot1, and IDHost1. If this is passed, NMEx searches and acquires the RNI of host 2 and encrypts NameHost2, PubKEDKSHost2, PPsEDKSHost2, and N1 with IDHost1. Finally, NMSEx adds the time stamp and signature SigIDNMSEx to the encrypted message and sends it to the host 1. When the host 1 receives this packet, it already has PubKSSKSi and PPsSSKSi, and can use this to verify the validity of SigIDNMSEx. Then, the encrypted message is decrypted, and RNIHost2, PubKEDKSHost2, and PPsEDKSHost2 which are information regarding the host 2 are acquired.

  When iterative mode is utilized within a subsystem, a reliable iterative solution needs to be made, as shown in FIGS. In a reliable iterative solution procedure, there are multiple iteration steps before the corresponding NMSE is reached. As shown in the iterative steps shown in FIG. 13, the host 1 sends a resolution request with IDHost1, NameHost2, N1, and TM1 to the NMSEm with the signature SigIDHost1. Here, the notation NMSEm is a generalized representation of the NMSE on the way from the first NMSE to the last NMSE that performs service. This is because the same sequence of messages is sent to these NMSEs. When NMSEm receives this request, it returns a list of NMSE names and locators that can be sent the next request, encrypted with IDHost1, with NMSEm's signature. Here, for simplicity, it is assumed that a single NMSE name and locator is sent instead of such a list. In any case, the host 1 selects one of them and sends a request to it. When host 1 receives this message, it verifies SigIDNMSEm and decrypts the message to obtain the name and locator of the next NMSE. Next, the host 1 performs the same operation by making this NMSE correspond to the NMSEm.

  As shown in FIG. 14, the request message reaches the last serving NMSE and the last resolution step is performed. In this step, the host 1 requests the resolution of NameHost2 to NMEx which is the last NMSE. The host 2 exists in the NMSEx service area that holds the RNI. Therefore, NMSEx provides RNIHost2, PubKEDKSHost2, and PPsEDKSHost2 encrypted with IDHost1 with SigIDNMSEx to host 1. The host 1 verifies the signature and finally obtains information on the host 2.

  From the above description, it can be seen that the host 1 can securely obtain the RNI, public key, and public parameters of the host 2 from the NMS subsystem SSi in both recursive and iterative solutions. FIG. 15 is a simplified drawing of a reliable solution procedure in one subsystem. As shown in FIG. 15, the host 1 sends a resolution request to the SSi with the signature, and the SSi returns the RNI, public key, and public parameters of the host 2.

  Following the description of reliable name resolution in one NMS subsystem, reliable iterative resolution between NMS subsystems will be described with reference to FIGS. Since the iterative resolution procedure between NMS subsystems includes a plurality of subsystems, there are a plurality of iterative steps until the resolution in the last NMS subsystem is reached. In the iteration step shown in FIG. 16, the host 1 sends a resolution request with IDHost1, NameHost2, Nk, and TMk to SSi with the signature SigIDHost1. SSi is a generalized representation of the SS located before the last SS. This is because messages in the same sequence are handled by each SS. Upon receiving this request, SSi returns RNISiHost2, PubKEDKSHost2, and PPsEDKSHost2 encrypted with IDHost1 to host 1 along with SigIDNMSEx. Here, RNISSiHost2 is the RNI of host 2 registered in SSi. Therefore, the host 1 verifies the obtained signature and acquires the RNI of the host 2. A similar procedure is performed if another SS exists before the last SS.

  When Host 1 sends a request to SSk, which is the last NMS subsystem, the last resolution step as shown in FIG. 17 is executed. In this step, the host 1 requests the last SS, SSk, to resolve based on the RNI obtained in the previous subsystem. The host 2 exists in the service area of the NMSEy that holds the RNI of the host 2 in SSk. Therefore, NMSEy provides RNISSkHost2, PubKEDKSHost2, and PPsEDKSHost2 in SSk encrypted with IDHost1 to host 1 with SigIDNMSEy. The host 1 verifies the obtained signature and obtains the last resolution information for the host 2.

In many cases, mutual authentication is required for reliable communication. In the above one-way resolution procedure, the source host obtains the name, locator, public key, and public parameters of the destination host. This is obtained by confirming the current ID of the destination host from the source host. Is possible. However, in this procedure, the destination host cannot confirm the identity of the 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. In the S ² NMS, the destination host executes the resolution procedure in the other direction so that the source host name, RNI, public key, and public parameters can be acquired. As a result, mutual authentication between the transmission destination host and the transmission source 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, and sends the current ID, IDHost1, NameHost2, N1, and TM1 to the host 2 with the signature SigIDHost1. When the host 2 receives this information, it resolves NameHost1, which is part of IDHost1, using NMS, and acquires PubKEDKSHost1 and PPsEDKSHost1 of host1. Then, SigIDHost1 is verified. After passing the verification, the host 2 generates the symmetric key SK, and further generates the encryption information of the symmetric keys SK, N1, and N2 encrypted by the IDHost1 by the IBE encryption function. IDHost2 and TM2 are added and sent to the host 1 with the signature SigIDHost2. The host 1 verifies SigIDHost2 and further decrypts the message to obtain SK. Then, N2 is encrypted by SK and sent to the host 2, whereby a secure communication channel is established between them.

(5. Reliable response update)
Assume that the host name is intended to be maintained when the host 1 moves from one attachment point of the network to a different attachment point. Under this circumstance, host 1 needs to update its new locator to its CH host 2 and the corresponding NMS subsystem.

  19, the host 1 sends the ID SigIDHost1, its ID Host1, the old locator Locator1, and the new locator Locor2 to the host 2 with the signature SigIDHost1. . Upon receiving this packet, the host 2 has already obtained the public key and public parameters of the host 1 in the resolution procedure, so that the validity of this signature can be directly verified. If the verification is successful, the host 2 replaces the old locator Locator1 of the host 1 with the new locator Locator2.

  A similar procedure is performed when locator update is performed for a corresponding NMS subsystem. Since the public key of the host 1 is known to the NMS subsystem, the NMSE can easily verify the validity of the signature of the host 1 and update its locator.

(6. Cancellation)
In S ² NMS, two methods are adopted for cancellation. One is automatic revocation based on ID, and the other is maintenance of a black list. As already described, the host ID is issued to the host by the registration procedure in the form of a host name with an expiration time. This ID can be used before the time indicated by the expiration time. Before the expiration time is reached, the host needs to request the corresponding EDKS to issue a new ID and new secret key with an extended expiration time for further authentication. However, since the ID and the expiration time are not information registered in the NMS, there is no need to redo the registration in the NMS.

  On the other hand, it is necessary to consider the case where the ID and the corresponding private key are compromised (decrypted) before the expiration time. If a host's current private key is compromised, a revocation procedure is required. Thus, the corresponding NMSE maintains a revocation list for the host. Each NMSE maintains a revocation host list for only those hosts that are serviced in its service area. The canceled host list records the canceled host name and the expiration time. Therefore, in the resolution procedure, even if the NMS resolution is successful, the corresponding NMSE checks whether the requested destination host is on the revocation list. If it is in the list, an error message is sent back to the originating host. Otherwise, normal NMS resolution is performed. Also, these revoked names are deleted when the expiration time is reached.

(Effect of embodiment)
According to the present embodiment, the following effects can be obtained.
1. The host can register the information with the NMS with high reliability. This is because mutual authentication between the host and the NMSE is possible, and MIMA and repeated attacks can be avoided.
2. Each device in the NMSE in the NMS and in the ED can exchange registration information or routing information with high reliability. Also, MIMA and repeated attacks can be prevented.
3. The source host can reliably resolve the name of the destination host as its locator, public key, and further RNI. This is because mutual authentication is performed in a recursive or iterative mode between the originating host and the NMSE, and a reliable solution is made in the iterative mode between the NMS subsystems.
4). Mutual authentication between hosts can be performed. After the mutual name resolution procedure, the two hosts can obtain the current ID of each other's communicators, as well as the public key and public parameters of the EDKS that performs the service. Thereby, mutual authentication is smoothly performed before communication starts.
5. Mapping correspondence information can be updated with high reliability. This is because the CH and the corresponding NMSE know the host's public key that needs to be updated. Therefore, the CH and the corresponding NMSE can easily confirm the validity of the received update packet.

  1N1, 1N2, 1N3, 1NM ... Edge Domain (ED), 3 ... Key Server (KS), 11, 11P, 12 ... Host, 21 ... ITR, 22 ... ETR, 30L ... Local DNS Server (LDNSS), 31, 32 , 33, 34, 35, 36 ... DNS server (DNSS; example of hierarchical NMS device), 31h, 32h, 33h, 34h, 35h, 36h, 37h ... hierarchical NMS device (hierarchical NMSE), 31f , 32f, 33f, 34f, 35f, 31g, 32g, 33g, 34g, 35g, 36g ... flat structure NMS device (flat structure NMSE), 41, 42, 43, 44, 45, 46, 47, 48, 49 , 4M ... Gateway (GW), 61, 62, 63, 6M ... ED key server (EDKS), 71, 72, 71K ... NMS sub Stem key server (NMSSSKS), 81 ... base station, 91, 92, 93 ... router, 100 ... NMS, 100A, 100B, 100K ... NMS subsystem, 110, 120 ... DNS (domain name system), 130 ... DNS subsystem 140 ... ALT subsystem 200 ... Global information transfer network.

Claims (4)

A self-device signature is attached to the first information including at least information indicating that the name of the destination device to be communicated is requested to be resolved, and the first information and the self-device signature are added to the destination. Means for sending to a structured system including a registration server for registering second information which is information about the device so that the system can find the registration server;
When the second information is sent from the registration server with the server signature that is the signature of the registration server added to the encryption information by encryption based on the ID of its own device, and Means for receiving the server signature;
Means for verifying the validity of the server signature;
Means for decrypting the second information from the encryption information. Affixing its own device signature to the first information including at least information indicating that the name of the destination device to be communicated is requested, and registering the second information as information on the destination device Means for sending to a hierarchical system including a registration server for
In the system, the third information, which is information related to the first upper server that is a server positioned higher in the hierarchy of the registration server, is encrypted with the first encryption information based on the first ID that is the ID of the own device. And when the first server signature, which is a signature of a second upper server positioned higher in the hierarchy than the first upper server, is attached and sent from the second upper server, Means for receiving a piece of cryptographic information and the first server signature;
Means for verifying the validity of the first server signature;
Means for decrypting the third information from the first encryption information;
Means for attaching a device signature to the first information and sending it to the first host server;
The fourth information, which is information related to the registration server, is converted into second encryption information by encryption based on the first ID, and a second server signature, which is a signature of the first upper server, is added. Means for receiving the second encryption information and the second server signature when sent from the first host server,
Means for verifying the validity of the second server signature;
Means for decrypting the fourth information from the second encryption information;
Means for attaching a device signature to the first information and sending it to the registration server;
The second information is transmitted from the registration server with the third server signature, which is the signature of the registration server, as third cipher information by encryption based on the first ID. Sometimes means for receiving the third cryptographic information and the third server signature;
Means for verifying the validity of the third server signature;
Means for decrypting the second information from the third encryption information. A self-signature is attached to first information including at least an ID including information of a first name that is the name of the self-device and a second name that is a name of a destination device to be communicated Means for sending to the destination device;
The second information including at least a session key and a random number generated by the destination device is applied to the name resolution system by the destination device so that the public key and public parameter of the own device are When it is sent from the destination device after being acquired by the destination device and having been made the first encryption information by the encryption based on the ID and having a device signature which is the signature of the destination device Means for receiving the first cryptographic information and the device signature;
Means for verifying the validity of the device signature;
Means for decrypting the session key and the random number from the first cryptographic information;
Means for encrypting the random number to generate second encrypted information based on the session key;
Means for sending the second encryption 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;
Means for attaching the self-device signature to the information of the new locator of the self-device and sending it to a structured system including a registration server as a server for registering information relating to the self-device. Host device to perform.

Images