JP2005191646A - Interrupter, and anonymous public key certificate issuing apparatus, system, and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an interrupter and an anonymous public key certificate issuing apparatus capable of efficiently and surely issuing a disposable anonymous public key certificate to an apparatus using an anonymous address when a subnet prefix in x bits (x is less than 64) is assigned to a user. <P>SOLUTION: When a host 210 transmits a certificate request packet including the anonymous address to a CA 201, the interrupter 204 interrupts a different certificate request having the same sender address. Further, when the CA 201 transmits a packet including a certificate to the host 210, the interrupter 204 interrupts the different certificate packet having the same destination address and a certificate packet whose destination is an address not received before. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a blocking device and an anonymous public key certificate issuing system.

  Usually, Ethernet (registered trademark) is used for a link between an IPv6 compatible device and a network, a subnet prefix is assigned to the link, and an IPv6 address is assigned to the device. An interface ID is generated based on the IEEE identifier (MAC address) of Ethernet (registered trademark), and an IPv6 address is obtained by concatenating the subnet prefix and the interface ID. An address generated by this method is called an IEEE EUI-64 IPv6 address. The subnet prefix is usually included in the Router Advertisement (RA) sent by the default gateway of the link to the link.

  A gateway is a device that connects different networks, and a default gateway in a certain network is a gateway specified as a default destination of a packet in that network. The default gateway is often simply called a router.

  The address system such as details of IPv6 address and configuration method is described in RFC 2373 “IP Version 6 Addressing Architecture,” RFC 2374 “An IPv6 Aggregatabale Global Unicast Address Format,” RFC 2375 “IPv6 Multicast Address Assignment,” RFC 2450 “Proposed TLA and NLA Assignment Rule, “RFC 2461“ Neighbor Discovery for IP Version 6 (IPv6), ”RFC 2462“ IPv6 Stateless Address Autoconfiguration, ”etc.

  By the way, if information that corresponds to one-to-one is used in hardware like IEEE identifier (MAC address), it is regarded as information that corresponds one-to-one with the device or the user of the device, and the address There is a strong risk that privacy will be infringed by monitoring communications using.

  For this problem, a method for generating a random IPv6 address (more precisely, an interface ID) has been proposed in RFC3041 “Privacy Extensions for Stateless Address Autoconfiguration in IPv6,” and the like.

  Also described is a protocol (extension) that detects the generated random value if it is already in use, calculates / generates another random value, and defines a unique random value. This random IPv6 address is called a temporary address or anonymous address.

  Consider encryption communication using IPsec when the device uses an anonymous address. IPsec is a protocol in which two devices on the Internet share secret data that no one else knows and encrypt and authenticate based on the secret data, and secure the secret data and the IPv6 address of each other during communication. Need to share. Data such as secret data and mutual IPv6 addresses is called SA (Security Association).

  A protocol for securely sharing SA is called IKE (Internet Key Exchange) and is defined in RFC2409 “The Internet Key Exchange (IKE)”. Here, the meaning of safely sharing the SA means that the SA is securely shared only with the intended partner, and it is necessary to authenticate the partner securely. There are 4 types of IKE: 1) method using pre-shared key, 2) method using digital signature, 3) method using public key encryption, and 4) method using revised mode of encryption using public key encryption. Two authentication methods are specified.

  However, considering the situation where privacy protection (information that reveals identity is not given) is realized, for example, when a user performs IPsec communication with a shopping site, it is determined in advance from the viewpoint of the shopping site. Since it is actually impossible to share a pre-shared key with an unspecified number of communication partners prior to IPsec communication, the method using pre-shared key cannot be used.

  In the case of other methods, IKE can be executed between an unspecified number of communication partners if the information necessary for using digital signatures or public key cryptography (in many cases, public keys) can be obtained reliably. It is. For this purpose, the most promising environment and mechanism called PKI (Public-key Infrastructure) is the public key certificate that plays a central role.

  The public key certificate is used by a trusted third party to confirm the correspondence between an entity (communication entity, computer or human) and the public key of the entity, and to disclose it with the entity's ID information, etc. A digital signature issued by a trusted third party for the key combination. A trusted third party is called a CA (Certification Authority), and public keys for verifying the validity of a CA's digital signature are widely known.

  However, since publicly used public key certificates include ID information indicating the owner (Subject), for example, a fully qualified domain name (FQDN), privacy protection cannot be realized as it is.

  There is also a method of not including the owner's ID information in the public key certificate, which is called an anonymous public key certificate. However, the same problem as the above-mentioned IEEE identifier (MAC address) exists in the anonymous public key certificate. In other words, as long as you continue to use the same anonymous public key certificate, it is possible to link multiple communications (such as IPsec based on public key certificate), and the correspondence between the anonymous public key certificate and its owner even once When it becomes clear, privacy will be infringed, so privacy protection is still weak.

  For example, if it is possible to use different anonymous addresses and anonymous public key certificates when communicating with different communication partners, it is considered that strong privacy protection can be realized. These are called disposable IPv6 anonymous addresses and disposable anonymous public key certificates. There are several possible disposable intervals, such as using a new disposable IPv6 anonymous address each time the communication partner changes, or changing it for each packet.

  Patent Document 1 and Patent Document 2 describe methods for efficiently and reliably issuing a disposable anonymous public key certificate to a device capable of IPv6 communication (hereinafter, referred to as an IPv6-compatible device). “Issuing with certainty” means that when a device using an anonymous address executes IPsec using the anonymous address, it is not impersonated by another device or the public key of the device is replaced.

  Therefore, in Patent Document 1 and Patent Document 2, the CA is located on the same link as the certificate issuance target device or is connected to the same link for the purpose of detecting impersonation and replay using the information of the link layer. It was assumed that another device and the CA are in a trust relationship with each other. These methods are particularly suitable when the administrator manages each link and router, such as a company internal network.

  On the other hand, as an IPv6 network operation method, there is a method of assigning a 48-bit subnet prefix to a user. In this case, the user can freely use 80 (= 128-48) bits of the 128-bit IPv6 address, so it is said that 2 ^ 80 address blocks are allocated (a ^ b is a power of b) Means). Focusing on the subnet prefix, users can freely assign and use 16 (= 64-48) bits of the 64-bit subnet prefix, so any network configuration can be realized by freely defining subnets within the user's range. .

In such a case, the link to which the 64-bit subnet prefix is assigned and its default gateway are under the user, but there may be a case where it is not guaranteed that the device existing on the link is reliable (non-malicious).
Japanese Patent Application No. 2003-085335 Japanese Patent Application No. 2003-107534

  There is no known method for efficiently and reliably issuing a single-use anonymous public key certificate to a device when an x-bit (x is less than 64) subnet prefix is assigned to the user. Specifically, an efficient method for issuing so that different anonymous public key certificates including the same anonymous address do not exist is not known.

  In order to solve the above problems, the invention according to the present application is provided with means for monitoring packets, and when a user-managed device requests the issuance of a disposable anonymous public key certificate, the device issues a public key certificate. Monitor packets sent to the device. Further, when a packet having the same source address or the same destination address is detected, the transfer of the packet is interrupted.

  In the above configuration, the issuance request packet of the disposable anonymous public key certificate that the device under user management sends to the public key certificate issuing device is monitored, the anonymous address included in the transmission source address is recorded, and the issuance request packet is Transfer to public key certificate issuing device. When different issue request packets having the same anonymous address as the source address are sent to the public key certificate issuing device, the (second and subsequent) packets are not transferred to the public key certificate issuing device. Also, the anonymous public key certificate issuance packet sent from the public key certificate issuing device to the user management is monitored. If different anonymous public key certificate issuance packets are sent to the same anonymous address, the packet is forwarded. do not do.

  In addition, the public key certificate issuing device matches the anonymous address included in the disposable anonymous public key certificate request message sent from the user-managed device and the source address of the packet containing the request message. Make sure.

  Further, the invention according to the present application provides means for executing IKE using ID protection and a public key certificate between a user-managed device that uses an anonymous address and a public key certificate issuing device. Execute the request for issuance of a disposable anonymous public key certificate and the issuing protocol while confirming the communication partner.

  Further, the invention according to the present application performs IPsec communication between the packet monitoring and blocking means and the public key certificate issuing device, and when the device under user management requests the issuance of a disposable anonymous public key certificate from the device. Monitor packets sent to the public key certificate issuing device. Furthermore, when different certificate request packets having the same source address are detected, the transfer of the packets is interrupted.

  In the above configuration, the issuance request packet of the disposable anonymous public key certificate that the device under user management sends to the public key certificate issuing device is monitored, the anonymous address included in the transmission source address is recorded, and the issuance request packet is Transfer to public key certificate issuing device. When different issue request packets having the same anonymous address as the source address are sent to the public key certificate issuing device, the (second and subsequent) packets are not transferred to the public key certificate issuing device.

  Also, the anonymous public key certificate issuance packet sent from the public key certificate issuing device to the user management is monitored. If different anonymous public key certificate issuance packets are sent to the same anonymous address, the packet is forwarded. do not do.

  As described above, only one anonymous public key certificate including a certain anonymous address is issued.

  As described above, according to the present invention, when an x-bit (x is less than 64) subnet prefix is assigned to a user, a disposable anonymous public key certificate can be efficiently and reliably issued to a device. Can do.

  Specifically, it can be issued so that different anonymous public key certificates including the same anonymous address do not exist.

  According to the invention according to the present application, a node under the user management is fraudulent by monitoring packets having the same source address or destination address and blocking different packets having the same source address or the same destination address. It is possible to prevent a plurality of anonymous public key certificates including a certain anonymous address from being issued when working.

  Further, according to the invention of the present application, when a certificate request packet including an anonymous address is sent to the issuing device, the blocking device blocks when a different certificate request packet having the same source address is detected. The issuing device confirms that the anonymous address included in the certificate request packet matches the source address of the certificate request packet, and issues a certificate to the anonymous address. A node that does not necessarily send an anonymous public key certificate request packet to the public key certificate issuing device to prevent attacks that attempt to issue multiple anonymous public key certificates including the same anonymous address it can.

  Further, according to the invention of the present application, when a different certificate packet having the same destination address is detected, the blocking device blocks the packet to issue the anonymous public key certificate to the node under user management. It is possible to prevent multiple sending.

  In addition, when a certificate packet destined for an address that has not been monitored or recorded before is detected, the blocking device blocks it so that a packet requesting an anonymous public key certificate is not sent from that address. Thus, it is possible to prevent a packet for issuing an anonymous public key certificate from being sent.

  Further, according to the invention of the present application, the IKE is performed between the device requesting the public key certificate and the public key certificate issuing device to establish IPsec communication, and the anonymous public key certificate issuing protocol is executed. IKE ID protection function and public key certificate are used to confirm the communication partner, an anonymous address is used when IKE is executed, and the public key certificate issuing device is the source of the IKE packet By confirming that the address and the anonymous address included in the certificate request packet match, rewrite the address of the packet and send the packet requesting the anonymous public key certificate to the public key certificate issuing device, and the same anonymous address It is possible to prevent an attack that attempts to issue a plurality of anonymous public key certificates including.

  Further, according to the invention of the present application, when IPsec communication is performed between the blocking device and the public key certificate issuing device, and a certificate request packet including an anonymous address is sent to the issuing device, the packet When the blocking device monitors the source address and detects different certificate request packets having the same source address, the blocking device blocks the anonymous address and the certificate request included in the certificate request packet. The issuing device confirms that the source address of the packet matches and issues a certificate to the anonymous address. An attempt is made to issue an anonymous public key certificate by a method of rewriting the address of the packet. Attack can be prevented.

  Therefore, IPsec can be safely executed using an anonymous address in a user-managed network in an ADSL environment.

  The best mode for carrying out the present invention is realized by a system including a blocking device and a public key certificate issuing device.

  When the blocking device detects a different certificate request packet having the same source address by monitoring the source address of the packet when a certificate request packet including an anonymous address is sent to the issuing device Cut off. The issuing device confirms that the anonymous address included in the certificate request packet matches the source address of the certificate request packet and issues a certificate to the anonymous address.

  The blocking device monitors the source address and the destination packet of the packet when the packet including the certificate is sent from the public key certificate issuing device to the device that requested the public key certificate, When a different certificate packet having a destination address is detected, or when a certificate packet destined for an address not previously monitored or recorded is detected, the packet is blocked.

  Details will be described in the following examples.

  In the present embodiment, a case will be described in which a user-managed network is connected to the Internet via an ISP network. First, the current situation will be described, and then this embodiment will be described.

1. Assumed Environment FIG. 2 schematically shows an environment of this embodiment (an environment in which a user-managed network is connected to the Internet via an ISP network).

  A link 207 connects the Internet 202 to an ISP-managed network (area 206) and a user-managed network (area 216). A link is a facility or medium through which a device connected thereto can communicate, and touches the lower side of the IP layer. The link is Ethernet (registered trademark), wireless LAN (IEEE 802.11), PPP link using PSTN (Public Switched Telephone Network), ISDN (Integrated Services Digital Network), ADSL (Asymmetric Digital Subscriber Line), X. 25. Frame relay, ATM network, etc.

  Devices such as a user router 208, a host 210, a host 211, a user router 212, a host 213, and a host 214 are connected to a network 216 under user management via a link 209 and a link 215. The user router 212 functions as a default gateway for devices connected to the link 215, and the user router 208 functions as a default gateway for other devices connected to the link 209.

  The ISP management network 206 includes an ISP router 205, a detector 204 and an ISP core network 203, which will be described later, and connects the Internet 202 and a network 216 under user management.

  An IPv6-compatible device connected to a link is called a node. A typical example of the internal configuration of the node is shown in FIG. Note that a CA (Certification Authority) 201 and a detector (blocking device) 204 can also be configured by a computer as shown in FIG. The CA 201 is a certificate authority and is a public key certificate issuing device that issues public key certificates.

  Nodes include routers (205, 208, 212) and hosts (210, 211, 213, 214). Routers (205, 208, 212) forward packets that are not addressed to them, but hosts (210, 211, 213 and 214) are not transferred. As can be seen from FIG. 3, the node 300 includes a network interface 301, 302, CPU 303, ROM 304, RAM 305, HD (hard disk) 306, power supply 307, keyboard / pointing device interface 308, monitor interface 309, bus 310, etc. It is a computer that has. Some nodes do not have HD.

  The router (205, 208, 212) has a plurality of network interfaces 301, 302, whereas the host (210, 211, 213, 214) often has a single network interface 301. For example, the host 210 and the host 211 are connected via the network interface 301 via the link 209 to another node connected to the link 209, or via the user router 208 that is the default gateway in the link 209. Communicate with sites on the Internet 202.

  When a user is assigned a subnet prefix of x bits (x is less than 64), the user-managed network 216 may be composed of a plurality of subnets. For example, in FIG. 2, link 215 is connected to link 209 via user router 212, so link 209 and link 215 can be different subnets (different subnet prefixes are assigned).

  The following processing content (procedure) is realized as a program or module, and is executed by a node in which the program is stored in the ROM 304 or the HD 306, or executed by a node having the module. For example, when implemented as a program, the CPU 303, which is a computer, reads the program, and assigns an address to the interface 301 via the bus 310 while using the RAM 305 as a space for calculation as needed. The operation is performed. In the case of a module, an entity that executes an operation equivalent to the above-described operation that the program executes in cooperation with the CPU, RAM, or the like is realized as an LSI, for example, and incorporated in a node. An instruction is issued from the CPU of the node to the module (LSI), and the module operates as a trigger and executes the process.

  Here, the essence of the procedure will be described such that the node 300 assigns an address to the interface.

2. Operation of Each Device in Assumed Environment A case will be described below where the link 207 between the ISP network 206 and the user-managed network 216 is ADSL, and a 48-bit subnet prefix is assigned to the user from the ISP.

  The mechanism by which an ISP assigns a subnet prefix to a user is called prefix delegation, and a method using RFC3315, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)” has been proposed. DHCPv6 is a UDP protocol executed between a DHCP server and a DHCP client in order to transmit the IPv6 address that the node wants to use and the IPv6 address of the DNS server to the node (DHCP client).

  In brief, a DHCP client multicasts a Solicit message to identify a DHCP server. The DHCP server that received the Solicit message returns an Advertise message. Upon receiving the Advertise message, the DHCP client sends an a Request message to the DHCP server for an IPv6 address and other information. The DHCP server responds with a Reply message that includes the IPv6 address and other information. If a DHCP relay agent exists between the DHCP server and the DHCP client, the DHCP server and the DHCP client will function even if they are on different links.

  Prefix delegation using DHCPv6 adds prefix (es) to the information (Option) transmitted in the DHCPv6 protocol and executes only prefix delegation, or prefix with IPv6 address assignment and other information transmission It is a mechanism that makes it possible to execute delegation. As of November 2003, draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05.txt is the latest document. Below, this mechanism is referred to as DHCPv6-PD.

  In DHCPv6-PD, the user's router is the DHCP client and the ISP router is the DHCP server, and prefix (es) is transmitted. At this time, the user router is called a requesting router, and the ISP router is called a delegating router. In FIG. 2, the user router 208 is a requesting router, and the ISP router 205 is a delegating router.

  If the ISP-managed ISP router 205 and the user-managed user router 208 are connected via ADSL, electrical adjustments are made when both routers are turned on and the ADSL link 207 is established. The electric signal can be transmitted. Next, the ISP router 205 authenticates the user router 208 by PPP and can send and receive IP packets. Finally, DHCPv6-PD is executed, and the ISP router 205 (delegating router) assigns a 48-bit prefix (denoted as / 48 prefix) to the user router 208 (requesting router). The user router 208 (requesting router) that received / 48 prefix generates / 64 prefix and its own IPv6 address, assigns the latter to its own interface (network interface 302 connecting link 209), and assigns the former to RA. And flow to link 209.

  Since the user can access the Internet only after being authenticated by the ISP, some user authentication is performed in PPP. Currently, the ISP issues a user name and password in advance to the user, the user sets the user name and password in the user router 208, and uses CHAP as a user authentication protocol between the ISP router 205 and the user router 208. It seems that there are many cases where authentication is performed. CHAP is described in RFC1994, “PPP Challenge Handshake Authentication Protocol”. As a method for the ISP to authenticate the user, there is a method using not only the user name and password but also a public key certificate described later.

  Next, the operation of the host 210 connected to the link 209 will be described. When the host 210 is turned on, an interface ID is generated, the RA that is being sent to the link 209 is obtained, and the address in the IEEE EUI-64 format described above is generated from the / 64 prefix included in the RA. (The network interface 301 connecting the link 209). Also, the user router 208 (sending RA) is set as the default gateway. This establishes a (global) IPv6 address and allows communication with a remote communication partner via the Internet.

  As shown in FIG. 2, when different subnets are operated in the user-managed network 216, / 64 prefix assigned to link 209 and / 64 prefix assigned to link 215 are set to different values, and the former is a user router. Configure both user routers so that 208 flows on link 209 (included in RA) and the latter flows on link 215 (included in RA). Further, the user router 208 is set to operate as the default gateway of the link 209 and the user router 212 is set to operate as the default gateway of the link 215, and the program is operated so that route information is exchanged between both routers. These settings are usually made manually by the user.

  In addition, the DNS (Domain Name System) server address is manually set for each router and each host as necessary. The DNS server automatic setting method is not standardized at this time.

3. Anonymous Public Key Certificates Anonymous public key certificates are academically recognized by Kazuomi Oishi, Masahiro Mambo, Eiji Okamoto, “Anonymous Public Key Certificates and their Applications” IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences, E81-A, 1, pp. 56--64, 1998, the concept and a concrete realization method are proposed, and the basic realization method is also disclosed as USA patent 6,154,851. In these methods, the anonymity of the user of the certificate is kept computationally.

  As a method to provide stronger anonymity, Kazuomi Oishi, “Unconditionally anonymous public key certificates,” The 2000 Symposium on Cryptography and Information Security, SCIS2000- C32, 2000. In the present embodiment, any method described in the aforementioned papers Kazuomi Oishi, Masahiro Mambo, Eiji Okamoto, “Anonymous Public Key Certificates and their Applications” can be used. If it is acceptable to inferior efficiency, Scheme 1, Scheme 2, and Scheme 3 in the above paper can be used, and these are also included in the present invention.

  In this embodiment, a case where an anonymous public key certificate system having computational anonymity is used is taken as an example. For details, refer to the above-mentioned literature, and after defining and introducing symbols and the like necessary for the description, the protocol of this embodiment will be described.

  The entity CA that issues the anonymous public key certificate defines large prime numbers p and q as common parameters. q divides p-1. Determine the generator g and the hash function H of the order q. Generate a secret random number s_ca (1 to q) and calculate v_ca = g ^ (s_ca) mod p. Here, A = (B) ^ (C) mod D represents a calculation where integers A, B, C, and D are obtained by dividing B by the value C and dividing the remainder by A. CA publishes p, q, g, H, and v_ca.

  The entity i using the anonymous public key certificate generates a secret random number s_i (1 to q) and calculates v_i = g ^ (s_i) mod p. s_ca and s_i are called private keys, v_ca and v_i (and public parameters) are called public keys, and the private keys are managed so that no one other than yourself knows them. When the entity i starts using the anonymous public key certificate, the entity i registers its entity name (user name), password, and public key v_i with the CA. The CA confirms the identity of the entity by physical means as necessary, and stores the presented entity name (user name), password, and public key v_i. Instead of confirming the entity's identity by physical means etc., identification may be done by presenting a proof that you have a public key certificate issued by another trusted CA and the corresponding private key. .

  When issuing an anonymous public key certificate, the CA generates a random number r (1 to q) and (g ', v_i') = (g ^ r mod p, (v_i) ^ (r) mod p) Calculate Certificate management / attribute information such as public parameters, certificate expiry date, public key certificate (described later) for v_ca is X, and (g ', v_i') and a message (hash value) containing X A digital signature is generated for it. The CA can use a digital signature scheme based on the discrete logarithm problem, for example, a Schnorr signature scheme. This digital signature is denoted as Sig_ca (g ′, v_i ′, X). An anonymous public key certificate APC_ca (i) issued by the CA to the entity i is APC_ca (i) = (g ′, v_i ′, X, Sig_ca (g ′, v_i ′, X)).

  An entity i that has been issued an anonymous public key certificate APC_ca (i) = (g ', v_i', X, Sig_ca (g ', v_i', X)), among them, (g ', v_i', X ) And compute its hash value (e.g. H (g '| v_i' | X), where `| 'indicates concatenation) and Sig_ca (g', v_i ', X) is the correct digital for the hash value Check if it is a signature using v_ca. Also check v_i '= (g') ^ (s_i) mod p. If they are confirmed to be correct, public key cryptography or a digital signature based on the discrete logarithm problem can be used with g ′ and v_i ′ (and the common parameter p) as public keys and s_i as a secret key.

  The entity that received the anonymous public key certificate (g ', v_i', X, Sig_ca (g ', v_i', X)) takes out (g ', v_i', X) from it and obtains its hash value. It is calculated and whether or not Sig_ca (g ′, v_i ′, X) is a correct digital signature for the hash value is confirmed using v_ca. If it is confirmed that it is correct, public key cryptography based on the discrete logarithm problem and digital signature verification are performed using g ′ and v_i ′ (and a common parameter p).

  In the above description, the signature scheme based on the difficulty of the discrete logarithm problem on the multiplicative group (mod p) has been described, but it is also possible to apply a signature scheme based on the difficulty of the discrete logarithm problem on the elliptic curve. In that case, since the same level of security is expected with a key having a smaller number of bits than in the case of the multiplicative group, the efficiency is improved.

4). Premise of the present embodiment Next, the present embodiment will be described with reference to FIG. Fig. 1 shows the protocol performed between CA201, detector 204, ISP router 205, user router 208, and host 210, and the basic operations after the power is turned on are executed as described above. And The CA 201 plays a role related to the certificate issuance among the roles of the entity CA in the anonymous public key certificate. That is, the CA 201 is a public key certificate issuing device that issues an anonymous public key certificate.

  The detector 204 in FIG. 2 is a device managed by the ISP, and monitors and records IPv6 packets having a specific IPv6 address as a transmission source or destination. If necessary, the internal analysis of the IPv6 packet is performed, and when an IPv6 packet that matches the conditions is detected, the forwarding of the IPv6 packet is blocked. That is, the detector 204 is a shut-off device. The detector 204 is provided in a place (outside the user network 216) that is not under user management. The detector 204 monitors a packet sent from the device to the public key certificate issuing device CA201 when a device under user management (device in the user network 216) requests the issuance of a disposable anonymous public key certificate.

  The IPv6 address monitored and recorded by the detector 204 is set by the ISP. In the case of the present embodiment, the anonymous public key certificate request packet sent from the network 216 under the user management to the CA 201, which is set with the IPv6 address of the CA 201 and the / 48 prefix assigned to the user, is sent from the CA 201. Anonymous public key certificate issuance packets sent to the user-managed network 216 are monitored. The detecotor 204 stores the address of the CA 201 in the RAM 305 and compares it with the address of the received packet.

  As a premise, the host 210 (HD306) has a public key certificate (not anonymous) issued to the device or user, a private key corresponding to the certificate, and a public key certificate (not anonymous). It is assumed that the public key certificate of the entity that issued is stored and the private key is securely managed.

  In the case of a public key certificate issued to a device, a manufacturer generates a digital signature for a message including information on the device such as the device type, model number, serial number and the public key of the device, A combination of a message and the digital signature can be used as a public key certificate.

  In the case of a public key certificate issued to a user, an entity that has issued the public key certificate generates a digital signature for a message including information for identifying the user and the user's public key, and the message The set of digital signatures can be used as a public key certificate. When the ISP issues a public key certificate to the user, it is possible to execute authentication using public key cryptography instead of the user name and password in the user authentication in the PPP, so that security is improved. A public key certificate issued by the ISP to the user may be set in the device and used.

  Hereinafter, a device or a user is generically called an end entity.

  When the CA 201 obtains the public key certificate of the entity (manufacturer or ISP) that issued the public key certificate to the end entity, it verifies the validity of the public key certificate of the end entity using it. Suppose that it is possible. If CA201 knows the public key of another CA and the other CA has created the public key certificate of the entity (manufacturer or ISP) that issued the public key certificate to the end entity, this confirmation will be Easy to do.

  Note that the entity that issues the public key certificate (not anonymous) and the CA 201 that issues the anonymous public key certificate are not necessarily the same entity.

  The public key certificate issued to the end entity (not anonymous) is used by the CA 201 to identify the end entity. In the above-mentioned anonymous public key certificate paper, the CA had both the role of confirming the identity of each (end) entity by physical means and the role of issuing the anonymous public key certificate. The CA 201 in the present embodiment does not necessarily have a role of confirming the identity of each (end) entity by physical means, but a public key certificate (not anonymous) is used as a means of confirming the identity of the end entity. It can also be used. X.509v3 can be used as the certificate format. Since the format of the certificate is not essential, details are omitted. In the following description, it is assumed that the CA 201 does not have a role of confirming the identity of each end entity by physical means or the like.

  It is assumed that parameters such as p, q, g, and H used in the anonymous public key certificate are determined, and each device knows them in advance (stored in the HD 306).

  Also, the CA201 public key (or self-signed certificate) is pre-recorded on the host 210 (HD306), or the public key certificate (or self-signed certificate) along with the IP address or FQDN of CA201 is also described later If the DNS is available and the IPv6 address or FQDN of the CA201 is known, the CA201 public key (or self-signed certificate) is retrieved from the public key directory to obtain the CA201 public key. It shall be possible. Alternatively, the host sends a packet requesting to disclose the public key certificate of CA 201 to the IPv6 address of CA 201, and the host obtains the public key certificate of CA 201 as a response. In any case, there must be a method for the host 201 to obtain the public key (or self-signed certificate) of the CA 201, and there can be a plurality of methods. Therefore, in this embodiment, a specific method is not assumed, and it will be described that the method is obtained by any method.

5). Specific operation of the present embodiment By the step S101 in FIG. 1, the DHCPv6-PD described above is executed between the ISP router 205 and the user router 208, / 48 prefix is assigned, / 64 prefix and IPv6 address. Is set in the user router 208.

  In step S101, the FQDN or IPv6 address of the CA 201 is transmitted from the ISP router 205 (the network interface 302) to the user router 208 (the network interface 301). This transmission can be realized, for example, by adding the IPv6 address of the CA 201 to the DHCPv6 OPTION, and executing the DHCP as the ISP router 205 and the user router 208 as the DHCP client. By extending DHCPv6 OPTION, not only IPv6 addresses but also FQDNs can be transmitted, or public key certificates (or self-signed certificates) can also be transmitted. The IPv6 address and the like are registered in the ISP router 205 (HD 306).

  The IPv6 address of the CA 201 transmitted as described above is transmitted from the user router 208 (the network interface 302) to the host 210 (the network interface 301) in the extended RS / RA protocol described below. .

  Details of the protocol of RS (Router Solicitaion) and RA (Router Advertisement) are described in the above-mentioned RFC 2461 “Neighbor Discovery for IP Version 6 (IPv6)”, and are referred to. In the present embodiment, a description will be given of an extended part for transmitting the IPv6 address of the CA 201 from the user router 208 to the host 210.

  RS and RA are ICMPv6 packets, Option is defined in the message format, and Option extension is permitted. Five types of Option are defined. Source link-layer address is a valid option in RS, Source link-layer address, MTU, and Prefix Information are valid options in RA. It has been established. The type of Option is determined by the value stored in the Type field in Option. In this embodiment, a new value (for example, 6) is assigned to the Type field, and the IPv6 address or FQDN or public key certificate of the CA 201 is stored as an option when the value is the value. In Option, there are fields for storing Length and address in addition to Type field.

  Using the extended RS and the extended RA as described above, the address of the CA 201 is transmitted from the user router 208 to the host 210 by the following protocol.

  First, the host 210 sends an RS in which the new value is stored in Option (for example, an RS in which 6 is stored in the Type field in Option) from the network interface 301 to the link 209 (multicast to all routers). This corresponds to step S102 in FIG.

  When the user router 208 receives the RS at the network interface 302, the user router 208 analyzes the Option and knows that the address of the CA 201 is requested from the value. Therefore, RA that stores CA201's IPv6 address or FQDN or public key certificate in Option (for example, store 6 in the Type field in Option, and IPv6 address or FQDN or public key certificate of CA201 in the Data field in Option) RS is stored, and is sent from the network interface 302 to the host 210. This corresponds to step S103 in FIG.

  When the host 210 receives the RA at the network interface 301, the host 210 analyzes the option and obtains the address or FQDN of the CA 201 or a public key certificate.

  In step S104, the host 210 determines that the IPv6 address in IEEE EUI-64 format (called public address) from / 64 prefix and interface ID, and the temporary address (anonymous address) from the interface ID randomly generated by / 64 prefix and RFC3041 method. ) Is generated. Next, the address, FQDN, or public key certificate of CA201 is taken out from the RA expanded as described above. When the public key certificate of CA 201 cannot be obtained, the public key directory is accessed as described above, and the public key certificate of CA 201 is acquired from the address or FQDN of CA 201. Alternatively, the host 210 may send a packet requesting to disclose the public key certificate of the CA 201 to the IPv6 address of the CA 201, and a packet including the public key certificate of the CA 201 may be sent to the host 210 as a response.

  Then, the private key s_i and the public key v_i are generated as described above (assuming that the host 210 corresponds to the entity i), and an anonymous public key certificate request message is generated. Note that s_i and v_i may be generated and recorded only once at the beginning, and may be used for the second and subsequent anonymous public key certificate request messages. The anonymous public key certificate request message can be generated according to, for example, PKCS # 10.

  At this time, v_i and an anonymous address (temporary address) are included in the message. In the case of X.509v3, an anonymous public key certificate public key may be defined and stored as an extension. The IP address is already defined as extension (subjectaAltName). Specifically, the host 210 copies the content of the subject of its own (non-anonymous) public key certificate to the subject of the anonymous public key certificate request message, and uses the extension as the public key for the anonymous public key certificate (g And p) and v_i and subjectAltName, create a message containing the temporary address (temporary address, anonymous address). Note that “Subject” indicates an issuer (that is, owner) of the certificate.

  Next, a digital signature is generated for the message using a private key (of the host 210 or the user's public key certificate). A set of a message, a digital signature, and a public key certificate is an anonymous public key certificate request message. Other details follow the X.509v3 and PKCS # 10 specifications.

  Further, the host 210 encrypts the anonymous public key certificate request message so that the CA 201 can decrypt it. For the encryption, for example, a so-called hybrid method in which common key encryption and public key encryption are combined, or a method of direct encryption with the public key of CA 201 is used. In the present embodiment, this encrypted anonymous public key certificate request message is called CR (Certification Request).

  In step S105, the host 210 sends the CR to the IPv6 address of the CA 201. However, temporary address (anonymous address) is used as the source address. At this time, the transfer protocol is a protocol on IPv6, which is a method with no packet loss (retransmission control is possible) and can be understood by the detector 204. For example, TCP can be used. The transfer protocol to be used is determined in advance, and the other transfer protocols are blocked by the detector 204 except for a protocol determined separately.

  As a protocol separately defined, as described above, a protocol in which the host requests disclosure of the public key certificate of the CA 201 is conceivable. For this protocol, for example, TCP is used, and the format and value of TCP payload data are determined in advance, and the payload data is not encrypted. In this way, if the protocol is defined so that the detector 204 can grasp the exchanged data with certainty, it can be easily identified from the protocol to be blocked.

  The CR / CM protocol described later is called the CR / CM protocol, the protocol that is not required to be blocked is called the passage permission protocol, and the protocol other than the CR / CM protocol and the passage permission protocol is called the passage prohibition protocol. .

  In step S106, the detector 204 monitors a packet including the IPv6 address of the CA 201 as a destination address, and analyzes the protocol included in the payload. The detector 204 receives a packet from the host 210 via the network interface 302, and the CPU 303 analyzes the destination address and the protocol (if the destination address is the address of the CA 201). If the protocol to be monitored / analyzed is a protocol that prohibits passage, it is blocked without being forwarded (the packet is discarded and not forwarded). When the monitoring / analysis target protocol is a passage permission protocol and not a CR / CM protocol, it is transferred from the network interface 301.

  When the protocol of the monitoring / analysis target packet is the CR / CM protocol, the transmission source address is recorded in the RAM 305. If the source address is already recorded in the RAM 305, the IPv6 packet is blocked. If not recorded, the packet is transferred from the network interface 301 to the CA 201 in step S107.

  Since then, IPv6 packets with the same source address and destination address as the current IPv6 packet are continuously monitored, and whether the retransmission control is performed in TCP, for example, in the transfer protocol (CR / CM protocol) executed by the packet. Or whether a different connection is about to be started. For TCP, when a different connection is about to be started, IPv6-TCP packets with different values for the port pair (source port (destination port) and destination port (destination port)) in the TCP header are observed. Therefore, the transfer of the IPv6-TCP packet is blocked. However, in the case of retransmission control, since the set of port in the TCP header does not change, packet transfer is not blocked. In the following description, it is assumed that the CR / CM protocol is TCP. The monitored source address (and source port) is recorded in a database in the RAM 305.

  As described above, the detector 204 has a receiving means (network interface 302) for receiving a packet, and monitors packets having the same source address. The detector 204 is a blocking device having blocking means (CPU 303) that blocks different packets having the same source address. When the detector 204 sends a certificate request packet (message) CR including a temporary address from the (IPv6) device (host 210) using the temporary address to the public key certificate issuing device (CA201), the certificate request packet ( Message) Monitor the source address of CR. The CPU 303 which is a blocking means of the detector 204 blocks different certificate request packets having the same source address. That is, when a different issue request packet CR having the same anonymous address as the source address is sent to the public key certificate issuing device CA201, the detector 204 sends the (second and subsequent) packets to the public key certificate issuing device CA201. Do not forward to. However, if the same public key certificate request packet CR is retransmitted, it is transferred.

  The CPU 303 of the detector 204 performs the operation as described above by reading and processing the program stored in the HD 306 or the ROM 304.

  In step S108, the CA 201 receives the CR through the network interface 301. It is checked whether or not the decrypted anonymous public key certificate request message is correct as the anonymous public key certificate request message. In other words, confirm that the message to be signed, the digital signature, and the public key certificate are included in the anonymous public key certificate request message according to the format, and that the public key certificate is correct (the certificate was issued The public key included in the public key certificate confirms that the correspondence between the message to be signed and the digital signature is correct (with the public key of the entity that issued the certificate). The sender IP address used to send the CR (the sender address of the certificate request packet) and the subjectAltName IP address inside the signature target message (anonymous address included in the certificate request packet (message)) Confirm that they are equal.

  If these can be confirmed, it is determined that the message is a correct anonymous public key certificate request message, and the anonymous public key certificate APC_ca (i) is generated as described above from v_i (g and p) therein. At this time, the APC_ca (i) is generated by storing the IP address of the subjectAltName in X. That is, the CA 201 has a temporary address (anonymous address) included in a certificate request packet (message) CR sent from the host 210 which is a user-managed device and a source address of the certificate request packet (message) CR. It is a public key certificate issuing device that issues a certificate to a temporary address after confirming that they match. Note that the CA 201 may record which anonymous public key certificate is issued to which entity (host 210), its expiration date, anonymous address, and anonymous public key certificate request message.

  In step S109, the CA 201 sends APC_ca (i) to the temporary address (anonymous address) of the host 210. At this time, it may be encrypted so that only the host 210 can decrypt it. For the encryption, for example, a so-called hybrid method combining common key encryption and public key encryption, or a method of directly encrypting with the public key of the host 210 is used. In the present embodiment, this encrypted (or unencrypted) anonymous public key certificate APC_ca (i) is called CM (Certificate Message).

  In step S110, the detector 204 continues to monitor the TCP connection. When the host 210 or CA 201 is operating normally, the CM is sent to the host 210 in the TCP connection (as a CR / CM protocol) established at step S106, and the IP packet is blocked. There is nothing.

  At this time, when a new TCP connection is established from CA 201 to an address (not necessarily an anonymous address) existing in user-managed network 216 (it is an IP packet that establishes another CR / CM protocol, When a packet whose destination address belongs to the network 216 under user management is detected), the detector 204 blocks the IP packet. The detector 204 receives this IP packet at the network interface 301. Whether or not it is a new TCP connection can be determined by referring to the record in the database (in RAM 305) managed by the detector 204 and confirming whether or not a CM has been sent to that address and port in the past ( If so, it is a new TCP connection). A new TCP connection is also created when no CR has been sent from the address and port in the past.

  The detector 204 monitors the destination address (and destination port) of the certificate packet CM, and records the monitored destination address (and destination port) in the database in the RAM 305. Then, the detector 204 blocks the certificate packet CM in which the destination address (and destination port) monitored and recorded in the past is the destination address (and destination port).

  The detector 204 monitors the source address (and source port) of the certificate request packet CR, and records the monitored source address (and source port) in the database in the RAM 305. Then, the detector 204 blocks the certificate packet CM in which the source address (and source port) that has not been monitored and recorded in the past is the destination address (and destination port).

  As described above, the detector 204 transmits the packet CM by the network interface 301 when the packet CM including the certificate is sent from the public key certificate issuing device CA201 to the (IPv6) device (host 210) that uses the temporary address. Receive and monitor the destination address of the packet CM. The CPU 303 of the detector 204 blocks different certificate packets having the same destination address. That is, when different anonymous public key certificate issuance packets CM are sent to the same anonymous address, the packets CM are not transferred. The public key certificate issue packet CM addressed to the same destination address as the destination address of the public key certificate issue packet CM received or transferred in the past is blocked. However, if the same anonymous public key certificate issuance packet CM is retransmitted, it is transferred. Further, the CPU 303 of the detector 204 blocks a certificate packet whose destination is an address that has not been monitored or recorded before. That is, when the destination address of the received public key certificate issue packet CM does not match the source address of the public key certificate request packet CR received or transferred in the past, the public key certificate issue packet CM is blocked. A public key certificate issuance packet CM issued to an unrequested address is blocked.

  If not blocked, the detector 204 forwards the IP packet from the network interface 302.

  The CPU 303 of the detector 204 performs the operation as described above by reading and processing the program stored in the HD 306 or the ROM 304.

  In step S111, the CM reaches the host 210 via TCP by the IP packet not blocked in step S110.

  In step S112, the host 210 extracts APC_ca (i) from the received CM (decrypts if necessary) and confirms that it is correct as described above.

  In order to obtain the same effect, the CA 201 may perform monitoring performed by the detector 204, but in this case, the load on the CA 201 increases. In the method of this embodiment, since the ISP manages the detector 204, it is easy to be consistent with the actual CA or ISP business. In other words, the CA only needs to concentrate on the certificate issuance work, and the ISP can distribute the detector 204 to multiple or perform maintenance according to the configuration of the ISP network 206 that it manages. Easy to do.

  In the first embodiment, the detector 204 exists under ISP management. In this embodiment, a case where the CA has a function corresponding to the detector 204 will be described. As described in the first embodiment, the load on the CA is larger than that in the first embodiment, but the safety is improved as described next (safe against strong attacks).

  This embodiment assumes an attack in which a plurality of anonymous public key certificate request messages are sent to the CA 201 by some means, and the CA 201 issues a plurality of anonymous public key certificates.

  For example, there is a malicious attacker (not shown) on the Internet 202 in FIG. 2, and the attacker collaborates with the host 211 (user) existing in the network 216 under user management. Consider adding a DoS (Deniable of Service) attack. For example, an anonymous public key certificate request packet sent from the host 211 to the CA 201 is secretly sent to the attacker, and the request packet (including the CR) is sent from the attacker to the CA 201. At this time, the attacker rewrites the transmission source address of the request packet including the CR to the anonymous address used by the host 210 and sends it.

  Upon receiving this request packet, the CA 201 performs confirmation as described in the first embodiment, generates an anonymous public key certificate including the anonymous address, and sends a CM to the anonymous address. The attacker intercepts the packet containing the CM, rewrites the destination address to the address of the host 211, and forwards it.

  When different anonymous public key certificates including the same anonymous address exist, a plurality of IPsec communications using the same anonymous address may exist simultaneously. For example, when host 210 and host A are performing IPsec communication, if host 211 performs IPsec communication with host B using the anonymous address used by host 210, host 210 is anonymous from host A and host B. IP packets sent to the address must be processed. As a result, the load on the host 210 increases. Since the load on the host 210 increases as the number of IPsec communications using the same anonymous address increases, there is a possibility that communications desired by the host 210 may be hindered. That is, a DoS attack can be established.

  It is difficult to prevent attacks involving address rewriting as described above simply by providing an address monitoring / blocking device such as detector 204 in the ISP management network. On the other hand, IPsec provides a mechanism for detecting when an IP packet address is rewritten on a route.

  Therefore, when making an anonymous public key certificate issuance request using an anonymous address, IKE is executed between the host and the CA to establish IPsec communication, and the anonymous public key certificate request and issuance are issued in the communication. If this protocol is executed, the attack can be prevented.

  In this case, the protocol is as follows. The environment and assumptions are the same as in the first embodiment. This will be described with reference to FIG. However, the detector 204 is not necessary.

  Steps S401 to S404 are the same as steps S101 to S104 in the first embodiment.

  In step S405, the host 210 starts IKE communication with the CA 201. At this time, the host 210 uses an anonymous address (temporary address). Authenticate (confirm partner) with ID protection and public key certificate at IKE. For example, the partner confirmation based on the main mode and the digital signature is adopted. The public key certificate issued to the end entity is used. Since ID protection is effective, even if a third party on the Internet observes all IKE packets, the host's ID and public key certificate will not be intercepted.

  As described above, the CA 201 can confirm that a specific host is communicating using a certain anonymous address, and can detect the fact when the packet is falsified by a third party. IPsec communication becomes possible when step S405 is completed.

  Next, in step S406, the host 210 transmits an anonymous public key certificate request packet to the CA in IPsec communication. This includes anonymous addresses that are in use.

  In step S407, the CA 201 receives the packet, confirms its validity, and searches the database provided in the RAM 205 or HD 306 to confirm that an anonymous public key certificate including an anonymous address has not been issued.

  If an anonymous public key certificate including the anonymous address has already been issued, the continuation of the protocol is stopped. If not issued, an anonymous public key certificate including the anonymous address is generated, the fact is described in the database, and the certificate is transmitted to the anonymous address in step S408. Since the anonymous public key certificate has an expiration date, the record of the certificate whose expiration date has expired is deleted from the database.

  In step S409, the host 210 extracts APC_ca (i) from the received CM (decrypts if necessary) and confirms that it is correct as described above.

  As in the above protocol, a means for executing IKE using ID protection and public key certificate is provided between host 210, which is a user-managed device using an anonymous address, and public key certificate issuing device CA201, and IPsec In communication, a request for issuing a disposable anonymous public key certificate and an issuing protocol are executed while confirming the communication partner. That is, when IKE is executed between the IPv6 device (host 210) and the public key certificate issuing device CA201 to establish IPsec communication (S405) and the anonymous public key certificate issuance protocol is executed, IKE ID protection Confirm the communication partner using the function and public key certificate, use the temporary address of the IPv6 device (host 210) when executing IKE, and the public key certificate issuing device CA201 sends the IKE packet Confirm that the original address matches the temporary address included in the certificate request packet. The public key certificate issuing device CA201 uses the network interface 301 to establish an IPsec communication by executing IKE with the IPv6 device (host 210), and the CPU 303 issues an anonymous public key certificate. When executing the protocol, check the communication partner using the IKE ID protection function and public key certificate, and check that the source address of the IKE packet matches the temporary address included in the certificate request packet. .

  The CPU 303 of the CA 201 performs the operation as described above by reading and processing the program stored in the HD 306 or the ROM 304.

  Therefore, a plurality of anonymous public key certificates including the same anonymous address are not issued, and a secure certificate issuing protocol can be realized even against a strong attack such as DoS.

  In the first embodiment, the detector 204 exists under ISP management. In Example 2, the CA has a function corresponding to the detector 204. In the present embodiment, the load of ISP and CA increases as compared with the first embodiment, but the detector 204 exists under the management of the ISP, and a safe method against a strong attack is described as in the second embodiment.

  The attack described in the second embodiment is established because the attacker can send an anonymous public key certificate request packet to the CA 201 and the CA 201 does not confirm the validity. In the second embodiment, instead of confirming validity, IPsec communication is performed between the end entity and the CA, and duplication is checked in the database of the CA 201.

  In this embodiment, in order to confirm the validity, IPsec communication is performed between the ISP and the CA. As a result, since the CA can communicate only with a specific ISP, the attacker cannot send an anonymous public key certificate request packet, and the CA 201 does not need to perform a duplicate check in the database.

  In this case, the protocol is as follows. The environment and assumptions are the same as in the first embodiment. This will be described with reference to FIG.

  It is assumed that IPsec communication is performed between the ISP core network 203 and the CA 201 in FIG. For example, if a public key certificate is exchanged in advance, IPsec communication can be automatically performed using IKE. In FIG. 5, the detector 204 is regarded as an ISP core network for convenience.

  In step S500, IPsec communication is established between the detector 204 and the CA 201. The subsequent protocol (step S501 to step S512) is the same as that of the first embodiment (step S101 to step S112). For example, in step S506, the detector 204 monitors the issuance request packet CR of the disposable anonymous public key certificate that the host 210 that is a user-managed device sends to the public key certificate issuing device CA201, and is included in the source address thereof. The anonymous address is recorded, and in step S506, the issue request packet CR is transferred from the network interface 301 to the public key certificate issuing device CA201. When different issue request packets CR having the same anonymous address as the source address are sent to the public key certificate issuing device CA201, the (second and subsequent) packets are not transferred to the public key certificate issuing device CA201.

  Further, the detector 204 monitors the anonymous public key certificate issuance packet CM sent from the public key certificate issuing device CA201 to the user management (received by the network interface 301), and different anonymous publications addressed to the same anonymous address. When the key certificate issuance packet CM is sent, the packet is not transferred from the network interface 302. In addition, when the destination address of the received public key certificate issue packet CM does not match the source address of the public key certificate request packet CR received or transferred in the past, the detector 204 displays the public key certificate issue packet CM. Cut off.

  That is, in this embodiment, the detector 204, which is a blocking device, is in a position where it can grasp all communication between the IPv6 device (host 210) under user management that uses a temporary address (anonymous address) and the public key certificate issuing device CA201. Is provided. The detector 204 performs IPsec communication with the public key certificate issuing device CA201 using the network interface 301, and requests a certificate including a temporary address from a user-managed IPv6 device (host 210) that uses a temporary address. When the packet CR is sent to the public key certificate issuing device CA201, the CPU 303 of the detector 204 monitors the source address of the packet CR and blocks different certificate request packets having the same source address in step S506. . The public key certificate issuing device CA201 confirms that the temporary address included in the certificate request packet CR matches the source address of the certificate request packet CR, and issues a certificate to the temporary address.

  The CPU 303 of the detector 204 performs the operation as described above by reading and processing the program stored in the HD 306 or the ROM 304.

3 is an anonymous public key certificate issuance protocol diagram in Embodiment 1. FIG. It is a schematic diagram of an assumed network. It is a block diagram of a node. It is an anonymous public key certificate issue protocol figure in Example 2. It is an anonymous public key certificate issue protocol figure in Example 3.

Explanation of symbols

206 ISP-managed network 216 User-managed network

Claims (12)

  A blocking device comprising: a receiving unit that receives a packet; and a blocking unit that blocks different packets having the same source address or the same destination address. A system having a blocking device and a public key certificate issuing device,
When a certificate request packet including an anonymous address is sent from the device using the anonymous address to the public key certificate issuing device, the blocking device monitors the source address of the certificate request packet, and the same A different certificate request packet having a source address is blocked, and the public key certificate issuing device confirms that the anonymous address included in the certificate request packet matches the source address of the certificate request packet. A system for issuing public key certificates with anonymity, characterized by checking and issuing certificates to anonymous addresses.   When a certificate request packet that includes an anonymous address is sent from the receiving means that receives the packet and a device that uses the anonymous address to the public key certificate issuing device, different certificate request packets that have the same source address are blocked. A blocking device that issues a public key certificate having anonymity. A system having a blocking device and a public key certificate issuing device,
When a packet including a certificate is sent from the public key certificate issuing device to a device that uses an anonymous address, the blocking device monitors the destination address of the packet, and different certificates having the same destination address A system that issues public key certificates with anonymity characterized by blocking packets. A system having a blocking device and a public key certificate issuing device,
When a packet including a certificate is sent from the public key certificate issuing device to a device using an anonymous address, the blocking device blocks a certificate packet destined for an address that has not been received before. A system that issues public key certificates with anonymity that is characteristic.   Receiving means for receiving packets, and blocking means for blocking different certificate packets having the same destination address when a packet including a certificate is sent from a public key certificate issuing apparatus to a device using an anonymous address. A shut-off device comprising:   Receiving means for receiving a packet, and when a packet including a certificate is sent from a public key certificate issuing device to an IPv6 device using an anonymous address, a certificate packet destined for an address that has not been received before is blocked And a blocking device.   IKE ID protection function and public key when executing IKE between the device requesting the public key certificate and the public key certificate issuing device to establish IPsec communication and executing the anonymous public key certificate issuing protocol Confirm the communication partner using the certificate, use the anonymous address of the device that requests the public key certificate when executing the IKE, and the public key certificate issuing device uses the source address of the IKE packet A system for issuing a public key certificate having anonymity characterized by confirming that an anonymous address included in a certificate request packet matches.   Establishing IPsec communication by executing IKE with the communication partner, and confirming the communication partner using IKE's ID protection function and public key certificate when executing the anonymous public key certificate issuing protocol And a public key certificate for issuing a public key certificate having anonymity characterized by having a confirmation means for confirming that the source address of the IKE packet matches the anonymous address included in the certificate request packet Issuer. A system having a blocking device and a public key certificate issuing device,
When IPsec communication is performed between the blocking device and the public key certificate issuing device, a certificate request packet including an anonymous address is sent from the device using an anonymous address to the public key certificate issuing device. A blocking device monitors a source address of the packet and blocks different certificate request packets having the same source address, and the public key certificate issuing device includes an anonymous address included in the certificate request packet A system for issuing a public key certificate with anonymity, wherein the certificate request packet is confirmed to match the source address and is issued to an anonymous address.   The IPsec communication means for performing IPsec communication with the public key certificate issuing device, and the packet when the certificate request packet including the anonymous address is sent from the device using the anonymous address to the public key certificate issuing device. And a blocking unit that blocks different certificate request packets having the same source address by monitoring the source addresses of the packets.   A program for causing a computer to operate as the blocking device according to any one of claims 1, 3, 6, 7, and 11, or the public value certificate issuing device according to claim 9.

Images