Patent Application
20050105735
The present invention relates to an information processing system and method, an information processing apparatus and method, a recording medium, and a program, and particularly to an information processing system and method, an information processing apparatus and method, a recording medium, and a program designed such that a service provider can enhance the efficiency and security of its authentication when authenticating a user.
Generally, a person who provides a pay service collects its charge from the other party to whom he/she provides the service.
For instance, a person who provides a service to the other party face-to-face with the party often collects cash from the other party at the time when he/she provides the service.
By contrast, a person who provides a pay service via communication such as the Internet often provides the service either by collecting the charge of the service later as a “credit” to the other party or after checking that the other party acquires the right to utilize the service by paying the charge, since electronic cash exchangeable via communication has not yet been commercialized. Therefore, the person who provides a pay service via communication needs to identify, i.e., to authenticate the other party to whom he/she provides the service, before providing the service.
When this authentication is performed, the authenticating party and the party to be authenticated need to have mutually corresponding information.
Note that when such authentication is performed, the party who has such mutually corresponding information and identifies the other party will be called as a verifier, whereas the party who is identified will be called as a certifier, hereinafter. Further, a technique used to have the certifier authenticated by the verifier will be called as an authentication technique.
Conventionally, password authentication, common key authentication, and public key authentication are known as authentication techniques.
Each of these authentication techniques, i.e., the password authentication, the common key authentication, and the public key authentication will be described below respectively.
(Password Authentication)
First, the password authentication will be described.
In the password authentication, a certifier registers a login name unique to each certifier, with a verifier beforehand, to fix his/her password. Further, the certifier and the verifier exchanges an agreement not to leak the password to anyone except themselves.
In this case, the person who knows the correspondence between the specific login name and the password is limited only to the certifier authenticated by that login name and the verifier, in principle. Therefore, the verifier judges that the person who is able to show the specific login name and the password corresponding thereto is the certifier who has made registration under that login name.
That is, the password authentication is a system in which the authentication is performed by the certifier directly showing the verifier the knowledge which only the verifier and the certifier know.
Therefore, it has a shortcoming that the password is susceptible to leakage at the time of authentication, but the login name and the password can be memorized directly by a person (certifier), and thus has a feature that no special apparatus is required for authentication. Hence, the password authentication is widely utilized.
In the password authentication, the verifier and the certifier have the same information, and thus it is possible to exchange their roles between the verifier and the certifier. Such authentication will hereinafter be called as bidirectional authentication. Provided that, in the password authentication, the bidirectional property is not usually used.
(Common Key Authentication)
Next, the common key authentication will be described.
Note that “Challenge & Response authentication” using common key cryptography will herein be called as common key authentication.
The common key cryptography is also called as symmetric cryptography, and is a cryptographic algorithm having a property that a cryptographic key for use in encrypting data and a cryptographic key for use in decryption are identical (or a property that even when the cryptographic keys are different, one of the cryptographic keys can be easily calculated from the other cryptographic key). As the common key cryptography, the DES(Data Encryption Standard) and the Triple DES adopted by the National Institute of Standards and Technology of the U.S. Department of Commerce, and FEAL(Fast Data Encipherment Algorithm) developed by NTT(Nippon Telegraph and Telephone Corporation (trade name)), and the like are known.
The common key authentication is a technique by which when each of a verifier and a certifier in authentication has an identical cryptographic key Kn for common key cryptography, the verifier checks that the certifier has the cryptographic key Kn without leaking that cryptographic key Kn to anybody other than the two parties having the cryptographic keys Kn.
A basic, specific example of the common key authentication will be described.
First, the verifier generates a random number r, and sends to the certifier (this step will hereinafter be written also as Challenge).
The certifier encrypts this random number r with a cryptographic key Kn, computes a value R=E(Kn, r) (wherein the E(Kn, r) means encryption of the random number r utilizing the key Kn), and returns to the verifier (this step will hereinafter be also written as Response).
The verifier decrypts the value R with the cryptographic key Kn, for comparison with the original random number r, and if the cryptographic key Kn matches with the original random number r, judges that the certifier has the cryptographic key Kn. Therefore, when a person having a specific cryptographic key Kn is identified to be only one certifier other than the verifier, authentication of that certifier becomes possible by the cryptographic key Kn.
For such common key authentication, a standard technique is defined in, for instance, ISO(International Organization for Standardization)/IEC(International Electro technical Commission) 9798-2. In the common key authentication, the verifier and the certifier have the same information, and thus the common key authentication is a bidirectional authentication technique.
In the above-mentioned password authentication, the password kept secret only to the verifier and the certifier is directly compared, and thus has the shortcoming that the password is susceptible to leakage at the time of authentication as mentioned above. By contrast, in the common key authentication, the cryptographic key(s) for the common key cryptography is used in the Challenge & Response authentication as mentioned above, and thus has a feature that the cryptographic key(s) is hard to leak out. Therefore, the common key authentication is superior in terms of security than the password authentication.
Provided that, in the common key authentication, it would be difficult for a person to perform calculations necessary for the Challenge & Response authentication, and thus the cryptographic key is usually held by a special apparatus called an IC(Integrated Circuit) card. Note that the IC card holding the cryptographic key for common key cryptography will be written as a CKC-IC card whenever appropriate in order to distinguish it from an IC card holding keys for public key cryptography to be described later.
The CKC-IC card internally has a function of performing calculations necessary for the common key authentication. Thus, as long as the common key authentication is performed by the CKC-IC card, there is only little possibility that the cryptographic key(s) will leak out. However, there is a possibility that the cryptographic key(s) will leak due to the CKC-IC card having been physically or logically analyzed, and there is also a possibility that the CKC-IC card itself will be stolen for abuse.
(Public Key Authentication)
Next, the public key authentication will be described.
Note that Challenge & Response authentication utilizing the public key cryptography will herein be called as public key authentication.
The public key cryptography is also called as asymmetric cryptography, and is an algorithm in which a cryptographic key for use in encrypting data (hereinafter called as a public key whenever appropriate) and a cryptographic key for use in decrypting (hereinafter called as a private key whenever appropriate) are different, and which has a property that it is very difficult to calculate one cryptographic key-from the other cryptographic key (to calculate the private key from the public key, or to calculate the public key from the private key).
The public key authentication is a technique by which when a certifier has a private key Sk and a verifier has a public key Pk paired with the private key Sk, the verifier can check that the certifier owns the private key Sk without knowledge of the private key Sk itself.
A specific example of a basic public key authentication technique will be described.
First, the verifier generates a random number r, encrypts it with a public key Pk, computes a value R=E(Pk, r) (wherein the E(Pk, r) means encryption of the r utilizing the public key Pk), and sends to the certifier (Challenge)
The certifier computes decrypted r′=D(Sk, R) of the value R (wherein the D(Sk, R) means decryption of the value R utilizing the private key Sk), and returns to the verifier (Response).
The verifier compares the random number r with the decrypted r′ of the value R, and when the random number r matches with those, judges that the certifier has the private key Sk.
Therefore, if a person having a specific private key Sk is identified to be one certifier, the verifier can perform the authentication of that certifier by the above-mentioned procedure.
As to the common key cryptography, a standard technique is defined in, for instance, the IEEE(The Institute of Electrical and Electronic, Inc)-P1363.
Further, as to the public key authentication, a standard technique is defined in, for instance, the ISO/IEC9798-3.
The public key authentication has a feature that an indefinite number of verifiers could exist as will be described later (as will be described by a public key authentication infrastructure to be described later).
Further, in the public key authentication, each of the verifier and the certifier has different information, and their roles are not exchangeable, and thus it is not authentication having bidirectionality. Such an authentication technique will hereinafter be called as unidirectional authentication as compared to bidirectional authentication.
The public key authentication can keep a private key which a certifier has cryptographically secure, similarly to the common key authentication. Therefore, the public key authentication is also superior to the password authentication in terms of security.
Provided that, in the public key authentication, it would be difficult for a person to perform calculations necessary for the Challenge & Response authentication, and thus the cryptographic keys for the public key cryptography are usually held by a special apparatus called as an IC card. Note that the IC card holding the cryptographic keys for the public key cryptography will be written as a PKC-IC card whenever appropriate in order to distinguish it from the above-mentioned CKC-IC card (IC card holding the key for the common key cryptography).
The PKC-IC card internally has a function of performing calculations necessary for the public key authentication. Thus, as long as the public key authentication is performed by the PKC-IC card, there is only a remote possibility that the cryptographic keys will leak out. However, there is a possibility that the encryption keys will leak due to the PKC-IC card having been physically or logically analyzed, and there is also a possibility that the PKC-IC card itself will be stolen for abuse.
In the authentication technique such as mentioned above, in order to perform authentication of many certifiers efficiently and securely, a technique is needed in which information necessary for authentication is arranged beforehand and managed. Such a technique will hereinafter be called as an authentication infrastructure.
Further, a person identified by an authentication infrastructure will be called as a user; a person who manages the authentication infrastructure will be called as a manager; and a person who identifies the user by utilizing the authentication infrastructure and provides a service to the identified user will be called as a service provider, hereinafter.
Conventionally, an individual account system, a general-purpose account system, and a public key authentication infrastructure are known as the authentication infrastructures.
However, each of these authentication infrastructures, i.e., the individual account system, the general-purpose account system, and the public key authentication infrastructure has the following problems.
(Problems of Individual Account System)
First, an outline of the individual account system and problems thereof will be described.
Among the authentication infrastructures, the most widely used conventionally is the individual account system. In the individual account system, authentication infrastructure is built for each service provider.
That is, a user makes an agreement on an authentication technique which he will utilize with the service provider either after registering information necessary for identifying and billing the user (e.g., information including his/her address, name, or credit card number) with the service provider, or having paid for a service to be provided, before receiving the service from the service provider.
Note that the authentication technique agreed between the service provider and the user and various information (information about the service provider and the user who are identified based on the authentication) utilized by the authentication technique will hereinafter be called as an account.
In this case, the service provider is a manager of this authentication infrastructure and a verifier for authentication of the user.
As the authentication techniques, all the above-mentioned three authentication techniques (the password authentication, the common key authentication, and the public key authentication) are applicable. For instance, in a Suica (trademark) system of JR East Japan Railway Company (trade name), the common key authentication is utilized as the authentication technique.
Provided that, when a technique other than the password authentication is applied, an IC card or the like for holding the authentication information is needed, and thus costs for developing an authentication infrastructure would increase. For this reason, when service provision via communication is intended, the password authentication is typically utilized.
In the individual account system, user authentication could only be initiated on condition that correspondence between a user and a password, a common key, or a public key which the service provider knows is correct (here is neither erroneous recognition nor leakage).
Since the individual account system can be implemented by the service provider's own operation, and thus can easily be introduced.
However, the individual account system has the following three problems.
A first problem is that a user needs to register information for identifying himself/herself with each service provider in order to prepare his/her account. Therefore, the user must spend time and labor in registration, and must also register information susceptible to abuse, such as his/her credit card number, even with an untrustworthy service provider.
A second problem is that when one user prepares an account with each of many service providers, management of many accounts (management, such as the user having to memorize many passwords or holding many IC cards) burdens the user.
A third problem is that it costs the service provider much to manage authentication information and personal information. That is, the authentication information and personal information need to be updated continuously. Particularly, credit card numbers, passwords, or cryptographic keys need to be handled carefully so as not to be leaked out.
(Problems of the General-Purpose Account System)
Next, an outline of the general-purpose account system and problems thereof will be described.
In order to solve the above-mentioned problems of the individual account system, a system in which each of many service providers performs user authentication by a single general-purpose account, i.e., a general-purpose account system is proposed. As the general-purpose account system, for instance, a Kerberos system RFC1510 and the like are known. The Kerberos is the name of a project conducted by Massachusetts Institute of Technology of the United States of America, and its standard is made open to the public as No. 1510 of the standard series called as RFC(Request For Comment). Note that the RFCs are provided by the IETF(Internet Engineering Task Force).
In the general-purpose account system, a person other than a service provider becomes a manager (such a manger will hereinafter be called as a general-purpose account manager)
When a service provider identifies a user, first, the general-purpose account manager authenticates the user, and the service provider authenticates the general-purpose account manager.
And the general-purpose account manager notifies the service provider of a result of the user authentication (identification of the user).
Thus, in the general-purpose account system, the service provider is not a verifier for user authentication, unlike in the individual account system.
For this reason, it is based on the following three points.
That is, as a first point, the service provider can authenticate the general-purpose account manager; as a second point, the general-purpose account manager is reliable (the authentication result to be notified is correct); and as a third point, the general-purpose account manager can authenticate the user.
In the general-purpose account system, the user is required to register his general-purpose account only once. Further, the account information is managed collectively by the general-purpose account manager. Therefore, the general-purpose account system can solve the above-mentioned problems of the individual account system.
However, the general-purpose account system has the following two problems, which are different from the above-mentioned problems of the individual account system.
That is, a first problem is that the importance of one authentication technique and the frequency of its use become excessive. As a result, chances for leakage of passwords and keys increase, and damage is likely to aggravate in case of their leakage.
A second problem is that authentication response deteriorates due to communication, since the communication with the general-purpose account manager needs to be involved at the time of authentication.
(Problems of the Public Key Authentication Infrastructure)
Next, an outline of the public key authentication infrastructure and problems thereof will be described.
As mentioned above, in the password authentication and the common key authentication, the verifier is related to the certifier on a one-to-one basis, but in the public key authentication, anyone can be a verifier since it is quite difficult for the verifier to guess a private key which the certifier has from a public key which he/she has himself/herself.
A combination of the property of such public key authentication with a method of obtaining a correspondence relation between a user and a public key is called as a public key authentication infrastructure.
Therefore, in the public key authentication infrastructure, the correspondence relation between a user and a public key can be obtained, and thus a service provider himself/herself can become a verifier, thereby making it possible to solve the above-mentioned second problem of the general-purpose account system.
It is generally considered that a manager who distributes a public key-incorporated IC card to the user knows the correspondence relation between a user and a public key. Note that the manager will hereinafter be called as an authentication center.
The authentication center issues a certificate that guarantees a relation between a user and a public key to a person who desires to obtain the correspondence relation between the user and the public key without inquiry to the authentication center (a person who desires to become verifiers).
Here, information that identifies the public key and the user (such as an ID and a name) and digital data including its expiration date, to which a digital signature is added by the authentication center are called as a certificate.
The digital signature is a kind of an application of public key cryptography. Therefore, the digital signature will be described so as to be corresponded to the above-mentioned public key cryptography.
For instance, when holding digital data M, the authentication center computes a signature SG(M)=E(Sk, h(M)) utilizing a private key Sk which the authentication center holds itself. Note that a function h( ) is supposed to be a unidirectional function, and is supposed to be a function having a property that it is very hard to know an input value from an output value. For instance, as the functions h( ), functions called as MD5 and SHA-1 in ISO/IEC10118, FIPS180-1, and the like could be applied.
The authentication center sends a set of data (M, SG(M)) to a verifier.
When holding a public key Pk paired with the private key Sk which the authentication center holds, the verifier checks whether or not h(M)=D(Pk, SG(M)) is satisfied, whereby to check that the digital data M is not tampered, that the signature SG(M) is added by the owner of the private key Sk (authentication center). Note that such a verifier's procedure will hereinafter be called as authentication of a digital signature.
In this way, the verifier in authentication verifies a digital signature added by the authentication center, and obtains a relation between the user and the public key from its certificate.
As to the digital signature, a standard technique is defined in, for instance, IEEE-P1363.
The verifier, if he/she knows the public key of the authentication center correctly and once he/she succeeds in verifying its digital signature, can obtain a relation between the user and the public key from the certificate.
When the scale of the authentication infrastructure increases, it would be difficult for one authentication center to know the relation covering all users and public keys. In such a case, a hierarchical structure is built among a plurality of authentication centers. The verifier has a certificate issued independently from each of the authentication centers, but as to the public keys, he/she handles only public keys which a small number of authentication centers called as root authentication centers have, whereby he/she verifies all the certificates.
In this way, the public key authentication infrastructure is a system in which correspondence between many users and public keys can be obtained, and is specified in ITU(International Telecommunication Union)-T Recommendation X.509. The public key authentication infrastructure can manage information for user authentication in a distributed manner, and thus is an authentication method adapted for environments where user management is not intensive such as for the Internet.
However, the relation between the user and the public key changes with time due to, for instance, the user losing the IC card, or being disqualified. That is, invalidation of an issued certificate occurs. As a result, the public key authentication utilizing certificates operates in the following four assumptions.
That is, as a first point, the service provider can verify a digital signature (including those traced from root authentication centers) of an authentication center in a certificate; as a second point, a certificate (including those traced from the root authentication centers) is not revoked; as a third point, an authentication center is reliable (the content of a certificate is correct); and as a fourth point, the correspondence between a user and a public key which an authentication center knows is correct (there are neither erroneous recognition nor leakage).
A person who best knows the invalidation status of a certificate is an authentication center which distributes a card to the user and issues the certificate. As a result, the verifier may query the authentication center about it when verifying the certificate in order to obtain the latest invalidation status. A communication protocol for such a query is specified as OSCP in RFC(Request For Comments) 2560. However, in this case, the verifier needs to query the authentication center when authenticating the user. That is, the same problem as the second problem of the general-purpose account system occurs.
For this reason, a method of terminating use of a revoked certificate is known in which the authentication center issues data called as a certificate invalidation list to users of certificates (such as service providers), and a user of a certificate terminates use of the certificate when the certificate is found revoked by comparison with the certificate invalidation list. The certificate invalidation list is specified by ITU-T Recommendation X.509. Provided that, since it is difficult to predict where in the distributed environments the certificate is used, it would be difficult for the authentication center to publicly announce the invalidation to the user of the certificate even when the certificate is revoked. Particularly, in order to accommodate abrupt invalidation of a certificate, the user of the certificate needs to collect related certificate invalidation lists constantly.
From the foregoing, the public key authentication infrastructure has the following two problems.
That is, a first problem is that the importance of one authentication technique increases excessively as in the general-purpose account system.
A second problem is that handling of invalidation information increases authentication costs, or decreases response. This is because the verifier (e.g., a service provider) needs to be able to verify invalidation or non-invalidation by gathering related certificate invalidation lists or query about the invalidation status via OSCP.
In this way, each of the individual account system, the general-purpose account system, and the public key authentication infrastructure has its peculiar problems.
That is, the individual account system, due to having the above-mentioned three problems, finds difficulty developing itself into a large-scale authentication infrastructure.
The general-purpose account system has many applications and thus can be easily developed as mentioned above, but since a service provider is not a direct verifier for user authentication, it has a problem that authentication response is decreased. This problem becomes conspicuous in situations where authentication is performed frequently.
In the public key authentication infrastructure, the verifier gathers the invalidation status of certificates related to the authentication in order to secure reliability of authentication as mentioned above, or queries to an authentication center at the time of authentication, and thus it has a problem that its authentication costs or response deteriorate. This problem would also become conspicuous in situations where authentication is performed frequently.
The present invention is made in view of such circumstances, and is designed such that a service provider can enhance the efficiency and security of its authentication when authenticating a user.
A first information processing system of the present invention is characterized in that: a first information processing apparatus generates a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which can be utilized by a predetermined authentication technique, sends the generated first cryptographic key to a second information processing apparatus, and sends the generated second cryptographic key to a third information apparatus; the second information processing apparatus receives the first cryptographic key sent by the first information processing apparatus, and holds; the third information processing apparatus receives the second cryptographic key sent by the first information processing apparatus, and holds; and the second information processing apparatus authenticates the third information processing apparatus by utilizing the held first cryptographic key and the second cryptographic key held by the third information processing apparatus, based on the authentication technique.
It can be designed such that the authentication technique is common key authentication, and the first cryptographic key and the second cryptographic key are identical cryptographic keys.
It can be designed such that the authentication technique is public key authentication and the first cryptographic key and the second cryptographic key are different cryptographic keys.
An information processing method for the first information processing system of the present invention is characterized in that: a first information processing apparatus generates a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which can be utilized by a predetermined authentication technique, sends the generated first cryptographic key to a second information processing apparatus, and sends the generated second cryptographic key to a third information processing apparatus; the second information processing apparatus receives the first cryptographic key sent by the first information processing apparatus, and holds; the third information processing apparatus receives the second cryptographic key sent by the first information processing apparatus, and holds; and the second information processing apparatus authenticates the third information processing apparatus by utilizing the held first cryptographic key and the second cryptographic key held by the third information processing apparatus.
In the first information processing system and method of the present invention, a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which can be utilized by a predetermined authentication technique are generated by the first information processing apparatus, and the first cryptographic key is sent to the second information processing apparatus and the second cryptographic key is sent to the third information processing apparatus. And the first cryptographic key held by the second information processing apparatus and the second cryptographic key held by the third information processing apparatus are utilized by the second information processing apparatus to authenticate the third information processing apparatus based on the authentication technique.
A first information processing apparatus of the present invention is characterized by including: generation means for generating a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which are utilized when another first information processing apparatus authenticates another second information processing apparatus based on a predetermined authentication technique; and sending means for sending the first cryptographic key generated by the generation means to the another first information processing apparatus, and sending the second cryptographic key generated by the generation means to the another second information processing apparatus.
It can be designed such that the authentication technique is common key authentication, and the first cryptographic key and the second cryptographic key generated by the generation means are identical cryptographic keys.
It can be designed such that the authentication technique is public key authentication, and the first cryptographic key and the second cryptographic key generated by the generation means are different cryptographic keys.
It can be designed such that identification means is further provided which identifies, when information for authentication is inputted or a predetermined apparatus utilized for authentication is connected, to the another second information processing apparatus, a user who inputs the information or the connected apparatus, wherein the generation means generates the first and the second cryptographic keys when the user who inputs the information to the another second information processing apparatus or the apparatus connected to the another second information processing apparatus is identified by the identification means.
It can be designed such that the identification means identifies the user who inputs the information to the another second information processing apparatus or the apparatus connected to the another second information processing apparatus, by using SSL(Secure Socket Layer), or TLS(Transport Layer Security).
It can be designed such that billing means is further provided which fixes a fee for a service provided to the another second information processing apparatus to be authenticated by the another first information processing apparatus, which is other party to whom the first cryptographic key is sent by the sending means, by utilizing the first and the second keys when the first and the second cryptographic keys are generated by the generation means, and which bills the user who inputs the information to the another second information processing apparatus, identified by the identification means, or a user identified by the apparatus connected to the another second information processing apparatus, identified by the identification means, for the fee for the service.
It can be designed such that the billing means bills the another second information processing apparatus for the fee for the service, and further, for a fee for the first and the second cryptographic keys generated by the generation means.
An information processing method for the first information processing apparatus of the present invention is characterized by including: a generation step of generating a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which are utilized when another first information processing apparatus authenticates another second information processing apparatus based on a predetermined authentication technique; and a sending step of sending the first cryptographic key generated by the generation step to the another first information processing apparatus, and sending the second cryptographic key generated by the generation means to the another second information processing apparatus.
A program in a first recording medium of the present invention is characterized by including: a generation step of generating a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which are utilized when another first information processing apparatus authenticates another second information processing apparatus based on a predetermined authentication technique; and a sending step of sending the first cryptographic key generated by the generation step to the another first information processing apparatus, and sending the second cryptographic key generated by the generation means to the another second information processing apparatus.
A first program of the present invention is characterized by causing a computer to execute: a generation step of generating a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which are utilized when another first information processing apparatus authenticates another second information processing apparatus based on a predetermined authentication technique; and a sending step of sending the first cryptographic key generated by the generation step to the another first information processing apparatus, and sending the second cryptographic key generated by the generation means to the another second information processing apparatus.
In the first information processing apparatus and method, the first recording medium, and the first program of the present invention, a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which the another first information processing apparatus utilizes when authenticating the another second information processing apparatus based on a predetermined authentication technique are generated, and the generated first cryptographic key is sent to the another first information processing apparatus and the generated second cryptographic key is sent to the another second information processing apparatus.
A second information processing apparatus of the present invention is characterized by including: receiving means for receiving, of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which are sent by another first information processing apparatus and which can be utilized by a predetermined authentication technique, at least the first cryptographic key; holding means for holding the first cryptographic key received by the receiving means; and authentication means for authenticating another second information processing apparatus by utilizing the first cryptographic key held by the holding means and the second cryptographic key held by the another second information processing apparatus, based on the authentication technique.
It can be designed such that the authentication technique is common key authentication, and the first cryptographic key and the second cryptographic key are identical cryptographic keys.
It can be designed such that the authentication technique is public key authentication, and the first cryptographic key and the second cryptographic key are different cryptographic keys.
An information processing method for the second information processing apparatus of the present invention is characterized by including: a receiving step of receiving, of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which are sent by another first information processing apparatus and which can be utilized by a predetermined authentication technique, at least the first cryptographic key; a holding step of holding the first cryptographic key received by the receiving step; and an authentication step of authenticating another second information processing apparatus by utilizing the first cryptographic key held by the holding step and the second cryptographic key held by the another second information processing apparatus, based on the authentication technique.
A program in a second recording medium of the present invention is characterized by including: a receiving step of receiving, of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which are sent by another first information processing apparatus and which can be utilized by a predetermined authentication technique, at least the first cryptographic key; a holding step of holding the first cryptographic key received by the receiving step; and an authentication step of authenticating another second information processing apparatus by utilizing the first cryptographic key held by the holding step and the second cryptographic key held by the another second information processing apparatus, based on the authentication technique.
A second program of the present invention is characterized by causing a computer to execute: a receiving step of receiving, of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which are sent by another first information processing apparatus and which can be utilized by a predetermined authentication technique, at least the first cryptographic key; a holding step of holding the first cryptographic key received by the receiving step; and an authentication step of authenticating another second information processing apparatus by utilizing the first cryptographic key held by the holding step and the second cryptographic key held by the another second information processing apparatus, based on the authentication technique.
In the second information processing apparatus and method, the second recording medium, and the second program of the present invention, of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which are sent by the another first information processing apparatus and which can be utilized by a predetermined authentication technique, at least the first cryptographic key is received and held. And another second information processing apparatus is authenticated by utilizing the held first cryptographic key and the second cryptographic key held by the another second information processing apparatus, based on the authentication technique
A third information processing apparatus of the present invention is characterized by including: receiving means for receiving, of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which are sent by another first information processing apparatus and which can be utilized by a predetermined authentication technique, at least the second cryptographic key; holding means for holding the second cryptographic key received by the receiving means; and response means for sending a predetermined response to another second information processing apparatus by utilizing the second cryptographic key held by the holding means, when the third information processing apparatus itself is authenticated by the another second information processing apparatus which holds the first cryptographic key, based on the authentication technique.
It can be designed such that the authentication technique is common key authentication, and the first cryptographic key and the second cryptographic key are identical cryptographic keys.
It can be designed such that the authentication technique is public key authentication, and the first cryptographic key and the second cryptographic key are different cryptographic keys.
It can be designed such that input means is further provided which inputs information for authentication by the another second information processing.
It can be designed such that connection means is further provided which connects a predetermined apparatus which is utilized when it is authenticated by the another second information processing apparatus.
It can be designed such that the apparatus connected to the connection means is an IC card.
It can be designed such that the holding means is tamper-proof.
An information processing method for the third information processing apparatus of the present invention is characterized by including: a receiving step of receiving, of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which are sent by another first information processing apparatus and which can be utilized by a predetermined authentication technique, at least the second cryptographic key; a holding control step of controlling holding of the second cryptographic key received by the receiving step; and a response step of sending a predetermined response to another second information processing apparatus by utilizing the second cryptographic key, holding of which is controlled by the holding control step, when the third information processing apparatus is authenticated by the another second information processing apparatus which holds the first cryptographic key, based on the authentication technique.
A program in a third recording medium of the present invention is characterized by including: a receiving step of receiving, of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which are sent by another first information processing apparatus and which can be utilized by a predetermined authentication technique, at least the second cryptographic key; a holding control step of controlling holding of the second cryptographic key received by the receiving step; and
A third program of the present invention is characterized by causing a computer to execute: a receiving step of receiving, of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which are sent by another first information processing apparatus and which can be utilized by a predetermined authentication technique, at least the second cryptographic key; a holding control step of controlling holding of the second cryptographic key received by the receiving step; and a response step of sending a predetermined response to another second information processing apparatus by utilizing the second cryptographic key, holding of which is controlled by the holding control step, when the information processing apparatus is authenticated by the another second information processing apparatus which holds the first cryptographic key, based on the authentication technique.
In the third information processing apparatus and method, the third recording medium, and the third program of the present invention, of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which are sent by the another first information processing apparatus and which can be utilized by a predetermined authentication technique, at least the second cryptographic key is received and held. And when the third information processing apparatus itself is authenticated by the another second information processing apparatus which holds the first cryptographic key based on the authentication technique, the predetermined response is sent to the second information processing apparatus by utilizing the held second cryptographic key.
A second information processing system of the present invention is characterized in that: a first information processing apparatus (it is not the above-mentioned first information processing apparatus, but is equivalent to a fourth information processing apparatus to be described later) generates request information for requesting generation of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which can be utilized by a predetermined authentication technique, for sending to a second information processing apparatus (it is not the above-mentioned second information processing apparatus, but is equivalent to a sixth information processing apparatus to be described later); the second information processing apparatus generates, when receiving the request information from the first information processing apparatus, each of the first cryptographic key and the second cryptographic key, sends the generated first cryptographic key to a third information processing apparatus, and holds the generated second cryptographic key; the third information processing apparatus (it is not the above-mentioned third information processing apparatus, but is equivalent to a fifth information processing apparatus to be described later) receives the first cryptographic key sent by the second information processing apparatus, and holds; and the third information processing apparatus authenticates the second information processing apparatus by utilizing the held first cryptographic key and the second cryptographic key held by the second information processing apparatus, based on the above-mentioned authentication technique.
It can be designed such that the authentication technique is common key authentication, and the first cryptographic key and the second cryptographic key are different cryptographic keys.
It can be designed such that the authentication technique is public key authentication, and the first cryptographic key and the second cryptographic key are different cryptographic keys.
An information processing method for the second information processing system of the present invention is characterized in that: a first information processing apparatus generates request information for requesting generation of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which can be utilized by a predetermined authentication technique, for sending to a second information processing apparatus; the second information processing apparatus generates, when receiving the request information from the first information processing apparatus, each of the first cryptographic key and the second cryptographic key, sends the generated first cryptographic key to a third information processing apparatus, and holds the generated second cryptographic key; the third information processing apparatus receives the first cryptographic key sent by the second information processing apparatus, and holds; and the third information processing apparatus authenticates the second information processing apparatus by utilizing the held first cryptographic key and the second cryptographic key held by the second information processing apparatus, based on the authentication technique.
In the second information processing system and method of the present invention, the request information for requesting generation of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which can be utilized by a predetermined authentication technique is generated by the first information processing apparatus, and sent to the second information processing apparatus. Then, each of the first cryptographic key and the second cryptographic key is generated by the second information processing apparatus, and the generated first cryptographic key is sent to the third information processing apparatus, and the generated second cryptographic key is held. And the first cryptographic key sent by the second information processing apparatus is received and held by the third information processing apparatus. In this state, the second information processing apparatus is authenticated by the third information processing apparatus by utilizing the held first cryptographic key and the second cryptographic key held by the second information processing apparatus.
A fourth information processing apparatus of the present invention is characterized by including: generation means for generating request information for requesting generation of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which are utilized when another first information processing apparatus authenticates another second information processing apparatus based on a predetermined authentication technique; and sending means for sending the request information generated by the generation means to the another second information processing apparatus.
It can be designed such that the authentication technique is public key authentication, and the first cryptographic key and the second cryptographic key generated by the generation means are different cryptographic keys.
It can be designed such that identification means is further provided which identifies, when information for authentication is inputted or a predetermined apparatus utilized for authentication is connected, to the another second information processing apparatus, a user who inputs the information or the connected apparatus, wherein the generation means generates the request information when the user who inputs the information to the another second information processing apparatus or the apparatus connected to the another second information processing apparatus is identified.
It can be designed such that the identification means identifies the user who inputs the information to the another second information processing apparatus or the apparatus connected to the another second information processing apparatus, by using SSL(Secure Socket Layer), or TLS(Transport Layer Security).
It can be designed such that billing means is further provided which fixes a fee for a service provided to the another second information processing apparatus to be authenticated by the another first information processing apparatus by utilizing the first key and the second key when the request information is sent to the another second information processing apparatus by the sending means, and which bills the user who inputs the information to the another second information processing apparatus, identified by the identification means, or a user identified by the apparatus connected to the another second information processing apparatus, identified by the identification means, for the fee for the service.
It can be designed such that the billing means bills the another second information processing apparatus for the fee for the service, and further, for a fee for the first and the second cryptographic keys generated by the another second information processing apparatus in response to the request information sent to the another second information processing apparatus by the sending means.
An information processing method for the fourth information processing apparatus of the present invention is characterized by including: a generation step of generating request information for requesting generation of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which are utilized when another first information processing apparatus authenticates another second information processing apparatus based on a predetermined authentication technique; and a sending step of sending the request information generated by the generation step to the another second information processing apparatus.
A program in a fourth recording medium of the present invention is characterized by including a generation step of generating request information for requesting another second information processing apparatus to generate a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which are utilized when another first information processing apparatus authenticates the another second information processing apparatus based on a predetermined authentication technique.
A fourth program of the present invention is characterized by including: a generation step of generating request information for requesting another second information processing apparatus to generate a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which are utilized when another first information processing apparatus authenticates the another second information processing apparatus based on a predetermined authentication technique; and a sending step of sending the request information generated by the generation step to the another second information processing apparatus.
In the fourth information processing apparatus and method, the fourth recording medium, and the fourth program of the present invention, the request information for requesting generation of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which the another first information processing apparatus utilizes when authenticating the another second information processing apparatus based on a predetermined authentication technique is generated, and the generated request information is sent to the another second information processing apparatus.
A fifth information processing apparatus of the present invention is characterized by including: receiving means for receiving, when another second processing apparatus generates a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which can be utilized by a predetermined authentication technique and sends the generated first cryptographic key at a request of another first information processing apparatus, the first cryptographic key; holding means for holding the first cryptographic key received by the receiving means; and authentication means for authenticating the another second information processing apparatus by utilizing the first cryptographic key held by the holding means and the second cryptographic key held by the another second information processing apparatus, based on the authentication technique.
It can be designed such that the authentication technique is public key authentication, and the first cryptographic key and the second cryptographic key are different cryptographic keys.
An information processing method for the fifth information processing apparatus of the present invention is characterized by including: a receiving step of receiving, when another second processing apparatus generates a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which can be utilized by a predetermined authentication technique and sends the generated first cryptographic key at a request of another first information processing apparatus, the first cryptographic key; a holding step of holding the first cryptographic key received by the receiving step; and an authentication step of authenticating the another second information processing apparatus by utilizing the first cryptographic key held by the holding step and the second cryptographic key held by the another second information processing apparatus, based on the authentication technique.
A program in a fifth recording medium of the present invention is a program for a computer that controls an information processing apparatus and is characterized by including an authentication step of authenticating another second information processing apparatus by utilizing, of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which can be utilized by a predetermined technique and which are generated by the another second information processing apparatus based on a request by another first information processing apparatus, the first cryptographic key held by the information processing apparatus itself and the second cryptographic key held by the another second information processing apparatus, based on the authentication technique.
A fifth program of the present invention is a program for a computer that controls an information processing apparatus and is characterized by including an authentication step of authenticating another second information processing apparatus by utilizing, of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which can be utilized by a predetermined technique and which are generated by the another second information processing apparatus based on a request by another first information processing apparatus, the first cryptographic key held by the information processing apparatus itself and the second cryptographic key held by the another second information processing apparatus, based on the authentication technique.
In the fifth information processing apparatus and method, the fifth recording medium, and the fifth program of the present invention, when the another second processing apparatus generates a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which can be utilized by the predetermined authentication technique and sends the generated first cryptographic key at the request of the another first information processing apparatus, the first cryptographic key is received and held by the fifth information processing apparatus. And the another second information processing apparatus is authenticated by utilizing the first cryptographic key held by the fifth information processing apparatus and the second cryptographic key held by the another second information processing apparatus, based on the above-mentioned authentication technique.
A sixth information processing apparatus of the present invention is characterized by including: receiving means for receiving request information, sent by another first information processing apparatus, for requesting generation of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which can be utilized by a predetermined authentication technique; key generation means for generating the first cryptographic key and the second cryptographic key based on the request information received by the receiving means; sending means for sending the first cryptographic key of the first cryptographic key and the second cryptographic key generated by the key generation means, to another second information processing apparatus; holding means for holding the second cryptographic key of the first cryptographic key and the second cryptographic key generated by the key generation means; and response means for generating a predetermined response by utilizing the second cryptographic key held by the holding means, when the information processing apparatus is authenticated by the another second information processing apparatus which holds the first cryptographic key sent by the sending means based on the authentication technique. The sending means sends the response generated by the response generation means to the another second information processing apparatus.
It can be designed such that the authentication technique is public key authentication, and the first cryptographic key and the second cryptographic key are different cryptographic keys.
It can be designed such that input means is further provided which inputs information for authentication by the another second information processing apparatus.
It can be designed such that connection means is further provided which connects a predetermined apparatus which is utilized when it is authenticated by the another second information processing apparatus.
It can be designed such that the apparatus connected to the connection means is an IC card.
It can be designed such that the holding means is tamper-proof.
An information processing method for the sixth information processing apparatus of the present invention is characterized by including: a receiving step of receiving request information, sent by another first information processing apparatus, for requesting generation of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which can be utilized by a predetermined authentication technique; a key generation step of generating the first cryptographic key and the second cryptographic key based on the request information received by the receiving step; a key sending step of sending the first cryptographic key of the first cryptographic key and the second cryptographic key generated by the key generation step, to another second information processing apparatus; a holding step of holding the second cryptographic key of the first cryptographic key and the second cryptographic key generated by the key generation step; a response generation step of generating a predetermined response by utilizing the second cryptographic key held by the holding step, when the information processing apparatus is authenticated by the another second information processing apparatus which holds the first cryptographic key sent by the key sending step, based on the authentication technique; and a response sending step of sending the response generated by the response step, to the another second information processing apparatus.
A program in a sixth recording medium of the present invention is a program for a computer that controls an information processing apparatus and is characterized by including: a key generation step of generating, based on request information sent from another second information processing apparatus to the information processing apparatus for requesting generation of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which can be utilized by a predetermined authentication technique, the first cryptographic key to be transmitted to another second information processing apparatus, and the second cryptographic key to be held by the information processing apparatus; and a response generation step of generating a predetermined response by utilizing the second cryptographic key held by the information processing apparatus, when the information processing apparatus is authenticated by the another second information processing apparatus which holds the transmitted first cryptographic key, based on the authentication technique.
A sixth program of the present invention is a program for a computer that controls an information processing apparatus and is characterized by including: a key generation step of generating, based on request information sent from another second information processing apparatus to the information processing apparatus for requesting generation of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which can be utilized by a predetermined authentication technique, the first cryptographic key to be transmitted to another second information processing apparatus, and the second cryptographic key to be held by the information processing apparatus; and a response generation step of generating a predetermined response by utilizing the second cryptographic key held by the information processing apparatus, when the information processing apparatus is authenticated by the another second information processing apparatus which holds the transmitted first cryptographic key, based on the authentication technique.
In the sixth information processing apparatus and method, the sixth recording medium, and the sixth program of the present invention, based on request information sent from the another second information processing apparatus to the information processing apparatus for requesting generation of a first cryptographic key and a second cryptographic key to be paired with the first cryptographic key which can be utilized by a predetermined authentication technique, the first cryptographic key to be transmitted to the another second information processing apparatus, and the second cryptographic key to be held by the information processing apparatus are generated by the sixth information processing apparatus. Thereafter, a predetermined response is generated by utilizing the second cryptographic key held by the sixth information processing apparatus and transmitted to the another second information processing apparatus, when the sixth information processing apparatus is authenticated by the another second information processing apparatus which holds the transmitted first cryptographic key based on the authentication technique.
(Business Models Supported by Authentication Key Allotment Systems)
First, a business model supported by an authentication key allotment system to which the present invention is applied will be described.
Note that in this example, a user User can be billed when identified by a general-purpose account system such as the Kerberos authentication key allotment system, or a public key authentication infrastructure.
Note that the number of participants is not particularly limited. However, in any of the cases of FIGS. 1 to 3, in this example, for instance, there are supposed to be only one key allotter KA, and plural users User and service providers SP.
Further, there could generally be plural managers at the authentication center of the public key authentication infrastructure or at the Kerberos authentication key allotment system, but in any of the cases of FIGS. 1 to 3, in this example, for instance, there are supposed to be only one general-purpose account manager KDC and only one authentication center CA.
In the business models of the present invention, users User and service providers SP conclude predetermined service utilization contracts first, and from then on, when a specific service provider SP authenticates a specific user User under restrictions, such as a predetermined number of times or a predetermined period, for instance, when the user User subscribes to news provided by the service provider SP or accesses a database for a certain period, the service provider SP can authenticate the user User efficiently.
That is, an authentication technique different from the general-purpose account or the public key authentication infrastructure is provided to two parties (a user User and a service provider SP) who frequently perform authentication. This authentication is efficient since it can be performed directly by the two parties. Further, in the case of terminating use of this authentication technique, it is easy to notify its invalidation since the authentication technique is used only between the specific service provider SP and user User. As a result, the above-mentioned second problem of the general-purpose account system and second problem of the public key authentication infrastructure can be solved.
As mentioned above, direct authentication is possible in the individual account system as well. However, in the business models of the present invention, a user User is identified utilizing the general-purpose account system or the public key authentication infrastructure only when a new authentication technique is allotted. As a result, time and labor involved in the registration required by the individual account system can be saved, and at the same time, the user can remain anonymous when utilizing a service.
Further, an authentication technique to be newly allotted is supposed to be the common key authentication or the public key authentication. The user User holds information necessary for the common key authentication in an apparatus having a function analogous to that of an IC card. As a result, allotment and selection of keys, and calculation for authentication can be automated. Therefore, the above-mentioned first and second problems of the individual account system can be solved.
Note that this apparatus having a function analogous to that of an IC card will hereinafter be called as a key holding apparatus. Further, in this example, the key holding apparatus is distributed to a user User from the key allotter KA. A contract will be concluded between the service provider SP and the key allotter KA, such that the key allotter KA performs key allotment to both the key holding apparatus of the user User and the service provider SP when requested by the service provider SP, and act as an agent to collect a service fee from the user User.
In this example, allotment of an authentication technique (key allotment) is performed by the key allotter KA when requested by the service provider SP for key allotment to a user User who will utilize a specific service.
Specifically, the key allotter KA identifies the user User using the general-purpose account or the public key authentication infrastructure, and performs key allotment in exchange for billing the user User (collecting a service utilization fee and a key allotment commission). Thereafter, the key allotter KA sends notice to the service provider SP that the key allotment is performed.
That is, when allotting an authentication technique, the key allotter KA generates cryptographic keys for a new authentication technique, and delivers the cryptographic keys to the service provider SP and the key holding apparatus held by the user User.
Alternatively, when allotting an authentication technique, the key allotter KA requests the key holding apparatus held by the user User to generate cryptographic keys for a new authentication technique. In response to the request, the key holding apparatus generates cryptographic keys for a new authentication technique by itself, and delivers the cryptographic keys to both the key allotter KA and the service provider SP.
Note that in the present specification, “the key holding apparatus generates cryptographic keys for a new authentication technique” includes not only a concept that “the key holding apparatus newly generates cryptographic keys for a new authentication technique when requested by the key allotter KA (generates on demand)”, but also a concept that “the key holding apparatus generates cryptographic keys for a new authentication technique by holding beforehand a plurality of cryptographic key candidates generated beforehand by the key holding apparatus itself or another apparatus different from the key holding apparatus, and by extracting (selecting) predetermined ones of the plurality of cryptographic key candidates which it holds when requested by the key allotter KA to make the keys as the cryptographic keys for the new authentication technique”.
Further, in an authentication technique to be allotted to both the key holding apparatus held by the user User and the service provider SP, a key allotted to the key holding apparatus will hereinafter be called as a certifying key, and a key allotted to the service provider SP will hereinafter be called as a verifying key.
As mentioned above, either the common key authentication or the public key authentication could be used as the authentication technique. When the common key authentication is used, the verifying key and the certifying key match (or are identical keys). By contrast, when the public key authentication is used, the verifying key is supposed to be a public key, and the certifying key is supposed to be a private key, and thus the verifying key and the certifying key are different keys.
What is important here is that the authentication technique allotted by the key allotter KA is not an authentication technique for billing the user User, but an authentication technique for providing a specific service. That is, a key allotment notice from the key allotter KA to the service provider SP needs to include neither information for identifying the user User nor a credit card number.
Therefore, the user User can remain anonymous to the service provider SP, and at the same time, possible illegal acts would be limited to the utilization of a service fixed at the time of key allotment even if the key(s) for the newly allotted authentication technique is leaked for some reason. As a result, it can be prevented that the importance of one authentication technique becomes excessive.
Authentication by the newly allotted authentication technique would be performed under the following three assumptions.
That is, a first assumption is that the key allotter KA could identify a service provider SP and a user User correctly by the general-purpose account or the public key authentication infrastructure; a second assumption is that the key allotter KA would be reliable (could allot keys to the service provider SP and the user User correctly); and a third assumption is that the key allotter KA would prohibit use of the allotted keys to any third party (including the key allotter KA itself) other than the key allottee. In this way, the key allotter KA would need to be so qualified as equivalent to the general-purpose account manager KDC or the authentication center CA in the general-purpose account system or the public key authentication system (so qualified as to execute the above-mentioned three points reliably).
Next, an operation of the present business models will be described.
First, the user User selects utilization of a service.
The service provider SP who can provide the service selected by the user User gives the user a key allotment application that notifies the key allotter KA about the content, amount of money, and the like of that service.
When the user User submits the key allotment application to the key allotter KA, the key allotter KA, in response thereto, inputs a certifying key for a new authentication technique and auxiliary information such as an identification number of the authentication technique, to a key holding apparatus held by the user User.
Alternatively, when the user User submits the key allotment application to the key allotter KA, the key allotter KA, in response thereto, inputs request information for requesting generation of cryptographic keys for a new authentication technique, to the key holding apparatus held by the user User. In response to this request information, the key holding apparatus generates cryptographic keys for a new authentication technique, i.e., a certifying key for the new authentication technique, and a verifying key to be paired therewith. And the key holding apparatus holds the certifying key by itself, and gives the verifying key to the key allotter KA.
When these keys are allotted, the key allotter KA identifies the user User who holds the key holding apparatus by the general-purpose account or the public key authentication infrastructure, and bills the user User so as to correspond with the service. Thereafter, the key allotter KA pays the service provider SP an amount of money obtained by subtracting a commission from the billed amount.
To this end, the key holding apparatus is provided with an input section for inputting a password necessary for the user User to be authenticated by the general-purpose account or the public key authentication infrastructure, a connection section for connecting the IC card, and the like.
Next, the key allotter KA prepares and gives to the key holding apparatus held by the user User a key allotment report for the service provider SP.
The key allotment report includes information about the allotted authentication technique (the identification number of the authentication technique, the verifying key for that authentication technique).
The key holding apparatus submits the key allotment report to the service provider SP, wherein the service provider SP obtains the verifying key for the new authentication technique and the auxiliary information. That is, the service provider SP obtains the verifying key for authenticating the user User to whom key allotment is performed.
When the user User utilizes the service after the authentication technique is allotted, the service provider SP performs authentication by the allotted authentication technique with respect to the key holding apparatus held by the user User. And when succeeding in this authentication, the service provider SP provides the service.
In this case (when the service is to be provided), cryptographic keys are temporarily shared between the key holding apparatus on which this authentication is performed (the key holding apparatus held by the user User) and the service provider SP, to encrypt their communication during service provision. As a result, spoofing of the user User and leakage of the content of the service can be prevented.
The authentication technique to be allotted has its expiration date and user determined by initially fixing its purpose of use. As a result, it can be deleted when its expiration date is passed. Further, when the use of the authentication technique should be terminated, the key allotter KA can notify the service provider SP about its invalidation.
(Authentication Key Allotment System)
Next, an authentication key allotment system to which the present invention is applied will be described.
Since the description would become complicated, the system will be described by dividing into the following first to six embodiments and individually in that order.
That is, as the first embodiment, an authentication key allotment system will be described, in which an authentication technique to be allotted is the common key authentication in a state where only the general-purpose account system (Kerberos) exists (a state corresponding to
As the second embodiment, an authentication key allotment system will be described, in which an authentication technique to be allotted is the public key authentication in a state where only the public key authentication infrastructure exists (a state corresponding to
As the third embodiment, an authentication key allotment system will be described, in which the general-purpose account system is utilized for user authentication, and a digital signature of a service provider is verified by the public key authentication infrastructure (when the public key authentication infrastructure and the general-purpose account system are utilized, and an authentication technique to be newly allotted is the public key authentication), in a manner corresponding to a state of
As the fourth embodiment, an authentication key allotment system will be described, in which the general-purpose account system is utilized for user authentication, and a digital signature of a key allotter is verified by the public key authentication infrastructure (when the public key authentication infrastructure and the general-purpose account system are utilized, and an authentication technique to be newly allotted is the public key authentication), in a manner corresponding to the state of
In the above first to fourth embodiments, cryptographic keys for a new authentication technique are generated by an apparatus kept by the key allotter KA (a key allotter terminal to be described later), but may also be generated by the key holding apparatus itself kept by the user User, as mentioned above.
Now, as the fifth and sixth embodiments, authentication key allotment systems will be described, in each of which the key holding apparatus kept by the user User generates cryptographic keys for a new authentication technique.
That is, as the fifth embodiment, an authentication key allotment system will be described, which is an embodiment corresponding to the second embodiment (the authentication key allotment system in which an authentication technique to be allotted is the public key authentication in the state (the state corresponding to
Further, as the sixth embodiment, an authentication key allotment system will be described, which is an embodiment corresponding to the fourth embodiment (in which the general-purpose account system is utilized for user authentication, and a digital signature of a key allotter is verified by the public key authentication infrastructure (when the public key authentication infrastructure and the general-purpose account system are utilized, and an authentication technique to be newly allotted is the public key authentication), in a manner corresponding to the state of
An authentication key allotment system to which the first embodiment of the present invention is applied will be described below with reference to the drawings.
As shown in
The type of the network is not particularly limited, but in this example, it is supposed to be, for instance, the Internet. Note that each of the user apparatus 11, the key allotter terminal 12, the service provider terminal 13, and the general-purpose account manager terminal 15 may directly communicate with the other apparatuses, not via the network 14. In this case, the network 14 can be omitted.
As will be described later, the user apparatus 11 is constituted by a user terminal 21, a key holding apparatus 22, and an IC card 23. Provided that, when the key holding apparatus 22 has a function of utilizing services provided by the service provider 13, and a function of communicating with other apparatuses via the network 14, the user terminal 21 can be omitted.
FIGS. 5 to 8 represent examples of data held by the key allotter terminal 12.
That is, in a memory (a storage section 88 or the like of
In the key allotment table of
The Key-ID represents an identification number of the allotted authentication technique, and is assigned to be unique.
An Acc-ID represents an identification number under the general-purpose account system of a user (an IC card kept by the user) who pays at the time the authentication technique is allotted.
An HW-ID represents an identification number of a key holding apparatus 22 to which the authentication technique is allotted.
An SP-ID represents an identification number of a service provider terminal 13 (service provider SP) who is allotted with the authentication technique.
An expiration date represents an expiration date for the authentication technique.
Service content represents the content of a service provided to the user terminal 21 (user User) from the service provider terminal 13 (service provider SP) by authentication utilizing that authentication technique.
A certifying key=verifying key represents a verifying key and a certifying key for the authentication technique. Note that the key held by the user User (key holding apparatus 22) and the key held by the service provider SP (service provider terminal 13) match in this example since the common key cryptography is utilized as the authentication technique.
In the service provider key table of
The SP-ID represents an identification number of the service provider terminal 13 (service provider SP) who concludes the contract, and is assigned to be unique at the time the contract is concluded.
An SP-address represents an address for making contact of the service provider terminal 13 (an e-mail address, an URL and the like). This is supposed to be where to make contact when invalidation of the authentication technique occurs or when an inquiry is to be made.
A unique cryptographic key represents a cryptographic key agreed upon between the service provider and the key allotter when the contract is concluded, and is used for guaranteeing the anonymity and integrity of communication between both parties.
In the key holding apparatus key table of
The HW-ID represents an identification number of the key holding apparatus 22, and is uniquely assigned to the key holding apparatus 22.
A unique cryptographic key represents a cryptographic key shared between a specific key holding apparatus 22 and the key allotter terminal 12, and is used for authentication and key sharing between both parties when a new authentication technique is allotted.
The key allotter account information of
That is, in a memory of the service provider terminal 13 (a storage section 108 or the like of
In the authentication information table of
Each of the Key-ID, an expiration date, and a verifying key represents a respective one of an identification number, an expiration date, and a verifying key of the authentication technique. Service content represents the content of a service provided to the user User (user terminal 21) who is authenticated by that authentication technique.
In the service provider unique information of
FIGS. 11 to 14 represent examples of data held by the user User.
That is, in a memory (a data storage section 53 or a key storage section 54 of
In the certifying key table of
The Key-ID represents an identification number of the authentication technique. A certifying key represents a certifying key of the authentication technique. An expiration date represents an expiration date for the authenticating key of the authentication technique. Service content represents the content of a service provided when authentication is performed by this authentication technique.
In the key holding apparatus unique information of
The user count information of
Note that in this example, the user terminal 15 is supposed to be a personal computer such as shown in
In
The RAM 33 also stores data and the like necessary for the CPU 31 to execute the various processing, as appropriate.
The CPU 31, the ROM 32, and the RAM 33 are interconnected via a bus 34. An input/output interface 35 is also connected to this bus 34.
The key holding apparatus 22 is also connected to the input/output interface 35.
The input/output interface 35 also connects to it an input section 36 configured of a keyboard and the like, an output section 37 configured of a display or the like, the storage section 38 configured of a hard disk and the like, and a communication section 39 that executes communication processing for intercommunication with other apparatuses via the network 14 (
Also connected to the input/output interface 35 is a drive 40 as necessary, to which a removable recording medium 41, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory or the like, is attached as appropriate, and a computer program read therefrom is installed to the storage section 38, as necessary.
In
This bus 60 also connects to it the data storage section 53 for storing the service information table of
This bus 60 is also provided with a computation processing section 56 that performs computation processing for authentication by utilizing a cryptographic key, the communication processing section 57 that performs communication processing with the user terminal 21, and an authentication processing section 58 that performs processing for identifying the user User who uses the key holding apparatus 22, based on control by the CPU 51.
When user authentication is performed by a login name and a password, the user User manipulates the keyboard (the input section 36 of
Note that the keyboard and the display are connected directly to the authentication processing section 58 if the key holding apparatus 22 is used independently without being connected to the user terminal 21 and if user authentication is performed by a login name and a password.
By contrast, when authentication based on the common key cryptography or the public key cryptography is utilized, the IC card 23 is connected to the authentication processing section 58. The Acc-ID and the registered cryptographic key of
In this example, the key holding apparatus 22 is supposed to be able to request the IC card 23 connected to the authentication processing section 58 to encrypt data or decrypt the encrypted data using the cryptographic key held on the IC card 23, and obtain auxiliary information (the user's identification number, a certificate and the like) necessary for authentication from the IC card 23.
As will be described later, since user identification is required only when a new authentication technique is allotted, the IC card 23 could otherwise be removed from the authentication processing section 58 in the case of authentication under the common key cryptography or the public key cryptography. Further, in the case of password authentication, various information related to the user authentication technique could be detached from the key holding apparatus 22 by causing the user to input the password every time the authentication is performed, without causing the key holding apparatus 22 to hold the password.
Note that each of the key storage section 54, the computation processing section 56, and the data management section 55 may preferably be made tamper-proof. In this case, internally held or processed data can be prevented from being acquired or altered from outside.
The IC card 23 may also be made tamper-proof in order to prohibit acquisition of internally held data and processed content from outside.
The IC card 23 is provided with a storage section 71 that stores a cryptographic key and auxiliary information (a cryptographic key for the common key cryptography in the case of the common key authentication, and a private key for the public key cryptography and a certificate in the case of the public key authentication) for use in authentication, a calculation processing section 72 that performs a calculation process for authentication utilizing the cryptographic key held on the storage section 71, and a communication processing section 73 that performs communication processing with the authentication processing section 58 (
In
Provided that, the above-mentioned data of FIGS. 5 to 8 are stored on, for instance, the storage section 88 and the like.
In
Provided that, the above-mentioned data of
In
Provided that, data such as shown in
In this example, an account management table of
A general-purpose account manager unique key of
Next, an operation of the authentication key allotment system 1 will be outlined with reference to a flowchart of
In step S1, when the user terminal 21 (user User) of
When the authentication technique is allotted as a result of step S1, the key holding apparatus 22 of the user User responds to authentication for service provision by utilizing the allotted authentication technique in step S2. When succeeding in this authentication, the service provider terminal 13 (service provider SP) provides the service to the user User who possesses the key holding apparatus 22 (to the user terminal 21 connected to the key holding apparatus 22). Note that such a series of processing will hereinafter be called as a “key use/service provision process”. Details of the “key use/service provision process” will be described later with reference to flowcharts of
Next, in step S3, each of the user apparatus 11, the key allotter terminal 12, and the service provider terminal 13 determines whether or not step S6 (a “key deletion process”) to be described later is performed.
A determination method for the process of step S3 is not particularly limited. However, in this example, for instance, supposing that a catalyst (trigger) for key deletion would be externally given to each of the user apparatus 11, the key allotter terminal 12, and the service provider terminal 13 as will be described later, then each of the user terminal 11, the key allotter terminal 12, and the service provider terminal 13 determines in step S3 to perform the “key deletion process” when it obtains this trigger.
In this case, an expiration date is set for the cryptographic key held by the key holding apparatus 22, and thus in step S6, information about the authentication technique the expiration date for which passes is deleted. Note that such a process will hereinafter be called as the “key deletion process”. Details of the “key deletion process” will be described later with reference to flowcharts of FIGS. 37 to 39.
On the other hand, if it is determined in step S3 that the “key deletion process” is not performed, the key allotter terminal 12 determines in step S4 whether or not the process of step S7 to be described later (a “key use termination process”) is performed.
A determination method for the process of step S4 is not particularly limited. However, in this example, for instance, if the key allotter terminal 12 detects leakage to the outside of the certifying key of the allotted authentication technique for some reason, or if it detects the fact that the key holding apparatus 22 is stolen (detection means is not shown), it determines in step S4 to perform the “key use termination process”.
In this case, a process of terminating the use of the authentication technique is executed in step S7. Specifically, the key allotter terminal 12 (key allotter KA) notifies the service provider terminal 13 (service provider SP) that it will terminate the use of the authentication technique, and causes it to terminate the use of the authentication technique in question. Note that such a process will hereinafter be called as the “key use termination process”. Details of the “key use termination process” will be described later with reference to flowcharts of
On the other hand, if it is determined in step S4 that the “key use termination process” is not performed, each of the key holding apparatus 22 and the service provider terminal 13 determines in step S5 whether or not the above-mentioned “key use/service provision process” is performed.
When it is determined in step S5 that the “key use/service provision process” is performed, the process returns to step S2 to execute the “key use/service provision process” again.
On the other hand, if it is determined in step S5 that the “key use/service provision process” is not performed, then the process returns to step S3 to repeat that step forward.
That is, the above-mentioned steps S1 to S7 represent processing performed by the authentication key allotment system 1 on one predetermined by-purpose authentication key, and when the above-mentioned “service selection/key allotment process” of step S1 is executed on that one by-purpose authentication key, that by-purpose authentication key is kept in a hold state until either the “key deletion process” of step S6 or the “key use termination process” of step S7 is executed, and the “key use/service provision process” of step S2 is executed for a plurality of times, as necessary.
In the authentication key allotment system 1, there are a plurality of such by-purpose authentication keys, and steps S1 to S7 are performed independently on each of these plurality of by-purpose authentication keys.
The details of the “service selection/key allotment process”, the “key use/service provision process”, the “key deletion process”, and the “key use termination process” will be described below individually in that order.
Referring first to the flowcharts of FIGS. 24 to 26 and the arrow chart of
Referring now to FIGS. 24 to 26, the “service selection/key allotment processes” by the user apparatus 11, the key allotter terminal 12, and the service provider terminal 13 will be described individually. However, a mutual relation among the processes by these apparatuses can easily be understood by reference to the corresponding steps of
Referring first to
In step S11, the CPU 31 of the user terminal 21 of
In this example, for instance, supposing that the storage section 38 stores application software for browsing Home pages and the like on the Internet, such as a Web Browser (such application software will hereinafter be called as a browser), the CPU 31 starts this browser to display a Home page managed by the service provider SP and stored in the service provider terminal 13 (the storage section 108 of
The user User browses this Home page to select a service which the user desires to utilize, and when the user inputs the selected service by manipulating the keyboard (the input section 36), the CPU 31 obtains the selected service, for transmission to the service provider terminal 13 via the communication section 39 and the network 14.
Note that the service selected by the user User in this way will hereinafter be called as simply the selected service.
Further, the CPU 31 (including the CPUs of the other apparatuses) transmits data in a predetermined format via the communication section 39 (including the communication sections of the other apparatuses) and the network 14 will hereinafter be called as simply the CPU 31 sends data.
Further, the CPU 31 (including the CPUs of the other apparatuses) receives data in a predetermined format from the other apparatuses via the network 14 and the communication section 39 (including the communication sections of the other apparatuses) will hereinafter be called as simply the CPU 31 receives data.
Specifically, for instance, by utilizing a method by which the user User selects a button displayed on a Home page with an input device such as a mouse and by which the CPU 31 gives notice about it via the communication section 39 and the network 14, the CPU 31 can send the selected service.
The selected service sent by the CPU 31 is supplied to the service provider terminal 13 via the network 14.
As will be described later, when receiving the selected service, the service provider terminal 13 prepares a key allotment application and transmits this to the user terminal 21 (steps S41 and S42 of
An application ID represents an identification number of an application added so as to be unique to the service provider terminal 13 (service provider SP) that issues this key allotment application.
An expiration date represents an expiration date necessary for an authentication technique the allotment of which is applied for by this key allotment application.
An SP-ID represents an identification number of the service provider terminal 13 (service provider SP), and is agreed upon beforehand at the time the service provider terminal 13 (service provider SP) concludes a contract with the key allotter terminal 12 (key allotter KA).
Service content represents the content of a service (service selected by the user terminal 21 (user User)) provided to the user User (key holding apparatus 22) who is authenticated by this authentication technique. Note that in this example, for instance, the service content includes, for instance, a service fee, an address of a service providing site and the like, besides the service content itself.
A message authentication code (MAC:Message Authentication Code) is generated for the key allotment application data by utilizing a unique cryptographic key (unique cryptographic key included in the service provider unique information of
The message authentication code allows tampering of data and identification of a message generator by using common key cryptography technology.
For instance, when there is data M, it is supposed that only a creator of the data M and an addressee of the data M share a cryptographic key K for the common key cryptography. At this time, the message authentication code for the data M is generated utilizing the cryptographic key K, as MAC(M)=E(K, h(M)) (encrypted data of h(M) by the key K). Note that h( ) is a unidirectional function (e.g., a Hash function or the like) shared in common by both sending side and the receiving side of the data.
The sending side sends the data M in the form of a set (M, MAC(M)), and the receiving side checks whether or not h(M)=D(K, h(M)) is satisfied, whereby it checks that the data M is not tampered and that a digital signature SG(M) is added by the owner of a secret key Sk. Such a series of processing will hereinafter be called as a check on a message authentication code.
Returning to
At the same time, the CPU 51 stores the key allotment application also on, for instance, the data storage section 53.
At this time, as will be described later, the key allotter terminal 12 receives the key allotment application, and verifies the message authentication code included therein. Further, it checks that other applications having the same application number are not received from the same service provider in the past. After these checks, the key allotter terminal 12 and the key holding apparatus 22 perform mutual authentication via the network 14 and the user terminal 21, to execute a process of sharing a cryptographic key Kses (steps S21 and S22 of
That is, the CPU 51 of the key holding apparatus 22 executes the “mutual authentication+key sharing process with the key allotter” in step S14.
Details of the “mutual authentication+key sharing process with the key allotter (step S14) (and the “mutual authentication+key sharing process with the key holding apparatus” (step S22 of
Note that in this example, the key allotter terminal 12 is supposed to know the correspondence between an identification number (HWIDb) of the key holding apparatus 22 and a unique cryptographic key KHWb owned by the key holding apparatus 22, from the key holding apparatus key table of
First, the CPU 51 (
As will be described later, when receiving it, the key allotter terminal 12 generates a random number Ra in step S22-1 of step S22, extracts a unique cryptographic key KHWb corresponding to the identification number HWIDb from the key holding apparatus table, and encrypts the linkage between the random number Rb and the identification number HWIDb utilizing the unique cryptographic key KHWb, for sending to the key holding apparatus 22 (to return encrypted data E (KHWb, Ra∥Rb∥HWIDb)). That is, mutual authentication based on the common key cryptography is performed by using the unique cryptographic key KHWb (step S22 of
When receiving it, the CPU 51 of the key holding apparatus 22 checks that the random number Rb and the identification number HWIDb sent a minute ago are correctly decrypted (it is checked that the data including the random number Rb is correctly encrypted by the unique cryptographic key KHWb) instep S14-2, whereby it checks that the other party is the key allotter terminal 12 (key allotter KA) who knows the unique cryptographic key KHWb corresponding to the identification number HWIDb.
And the CPU 51 of the key holding apparatus 22 generates a temporary shared cryptographic key (session key) Kses by utilizing the unique cryptographic key KHWb, links it with random numbers Rs, Rb, and encrypts and sends them (send data E(KHWb, Rb∥Ra∥Kses)) in step S14-3.
Note that in this example, for instance, encryption is performed by the computation processing section 56 of the key holding apparatus 22 (
The key allotter terminal 12 receives this encrypted data E(KHWb, Rb∥Ra∥Kses), and decrypts it to extract the common cryptographic key Kses (step S22 of
As a result, the common cryptographic key Kses can be shared between the key holding apparatus 22 and the key allotter terminal 12.
Note that as to the sending of the key allotment application from the user apparatus 11 to the key allotter terminal 12 performed in steps S13 and S21, the encryption may be performed by utilizing the common cryptographic key Kses after the common cryptographic key Kses is shared. That is, in this case, steps S13 and S14 in the user apparatus 11 shown in
Returning to
Note that such a process will be called as a “user authentication response process”. Further, “the process in which the key allotter terminal 12 identifies (authenticates) the key holding apparatus 22 (user User) who holds the shared cryptographic key Kses” by the key allotter terminal 12 will be called as a “key holding apparatus user authentication process”.
That is, the CPU 51 of the key holding apparatus 22 executes the “user authentication response process” in step S15, hereinafter.
Details of the “user authentication response process (step S15)” in the first embodiment is shown in
Note that an example in which the user is authenticated by the general-purpose account system, specifically, the Kerberos authentication is shown in
First, as will be described later, the key allotter terminal 12 sends an identification number (Acc-ID) IDKA under a general-purpose account thereof to the key holding apparatus 22 (step S23 of
When receiving it, the CPU 51 of the key holding apparatus 22 sends an authentication service request KRB_AS_REQ from the user User to the general-purpose account manager terminal 15 in step S15-1.
Specifically, in this example, for instance, the service request KRB_AS_REQ is supposed to be data UID∥E(KU, time), where UID represents the identification number of the user User (IC card 23), and E(KU, time) represents data in which a time time is encrypted by utilizing a user's registered cryptographic key KU.
The general-purpose account manager terminal 15 checks in step S51 that the service request KRB_AS_REQ is correct, i.e., that the time time included in the service request KRB_AS_REQ can be decrypted by the cryptographic key KU corresponding to the identification number UID and that a deviation from the current time is within a predetermined fixed range.
And the general-purpose account manager terminal 15 sends (returns) an authentication service reply KRB_AS_REP to the key holding apparatus 22 in step S52.
In this example, for instance, the authentication service reply KRB_AS_REP is supposed to be data E(KU, Kt)∥E(KKDC, Kt∥UID∥expire), where E(KU, Kt) represents data in which a temporary cryptographic key Kt is encrypted, which is decided by the general-purpose account manager terminal 15 (general-purpose account manager KDC) by utilizing the cryptographic key KU. E(KKDC, Kt∥UID∥expire) represents data in which linked data Kt∥UID∥ in which a cryptographic key Kt, the user's identification number UID, an expiration date expire are linked is encrypted by utilizing a cryptographic key KKDC of the general-purpose account manager terminal 15 (general-purpose account manager KDC). Note that E(KKDC, Kt∥UID∥expire) will hereinafter be written as a TGT.
When receiving the authentication service replay KRB_AS_REP, the CPU 51 of the key holding apparatus 22 decrypts the encrypted data E(KU, Kt) included in the authentication service reply KRB_AS_REP to extract the temporary key Kt, in step S15-2. Provided that, the CPU 51 cannot decrypt the TGT.
The CPU 51 of the key holding apparatus 22 sends a ticket approval service request KRB_TGS_REQ to the general-purpose account manager terminal 15 in step S15-3.
In this example, the ticket approval service request KRB_TGS_REQ is supposed to be, for instance, data IDKA∥E(Kt, UID∥time)∥TGT.
When receiving the service request KRB_TGS_REQ, the general-purpose account manager terminal 15 checks the expiration date for the TGT in step S53, and, if it is valid, extracts the cryptographic key Kt from the TGT, and compares the time time of what is decrypted from the encrypted data E(Kt, UID∥time) with the current time to check that it is within the predetermined range. When succeeding in that check, the general-purpose account manager terminal 15 generates a temporary key Kt2 to be shared between the key holding apparatus 22 and the key allotter terminal 12.
And the general-purpose account manager terminal 15 sends (returns) a reply KRB_TGS_REP to the key holding apparatus 22 in step S54.
In this example, the reply KRB_TGS_REP is supposed to be, for instance, E(Kt, Kt2∥IDKA)∥E(KKA, Kt2∥UID), where KKA represents the cryptographic key registered at the general-purpose account of the key allotter terminal 12 (key allotter (KA)).
When receiving the reply KRB_TGS_REP, the CPU 51 of the key holding apparatus 22 decrypts the encrypted data E(Kt, Kt2∥IDKA) to obtain Kt2, in step S15-4.
The CPU 51 of the key holding apparatus 22 sends data KRB_AP_REQ to the key allotter terminal 12 in step S15-5.
In this example, the data KRB_AP_REQ is supposed to be, for instance, K(Kses, Kt2)∥E(Kt2, UID∥time)∥E(KKA, Kt2∥UID).
When receiving the data KRB_AP_REQ, the key allotter terminal 12 decrypts the cryptographic key Kt2 of the user User (key holding apparatus 22) having the identifier UID from the encrypted data E(KKA, Kt2∥UID), and further compares the time time of what is decrypted from the encrypted data E(Kt2, UID∥time) with the current time to check that it is within the predetermined range, in step S23-2. And the key allotter terminal 12 identifies the possessor of the key holding apparatus 22 with whom it shares the cryptographic key Kses as being the user User (user terminal 21) having the identification number UID, from the encrypted data E(Kses, Kt2).
And the key allotter terminal 12 generates data KRB_AP_REQ representing the fact that the user User is identified, for sending to the key holding apparatus 22 in step S23-3.
Thereafter, as will be described later, the key allotter terminal 12 generates, for the key holding apparatus 22, an identification number KID of an authentication technique to be allotted and a new key Kr for use in authentication, for sending to the key holding apparatus 22 (step S24 of
Returning to
In this example, for instance, the identification number KID is supposed to be a number not used so far, and the new key Kr would be a random number generated by the key allotter terminal 12 at this time.
Specifically, for instance, the key allotter terminal 12 sends the identification number KID and the new key Kr as encrypted data E(Kses, KID∥Kr) to the key holding apparatus 22 by utilizing the above-mentioned temporary key Kses shared with the key holding apparatus 22.
At this time, the CPU 51 of the key holding apparatus 22 receives the encrypted data E(Kses, KID∥Kr) in which the identification number KID and the new key Kr are encrypted, and decrypts the identification number KID and the new key Kr by utilizing the temporary key Kses. And it adds a new record to the certifying key table of
Next, the key allotter terminal 12 prepares a key allotment report, for sending to the key holding apparatus 22 (step S25 of
In this case, since the verifying key and the certifying key are identical, leakage of the keys to anyone other than the service provider SP must be prevented. To this end, the key allotter terminal 12 sends the key allotment report including also the verifying key encrypted by a unique key KSP of the service provider terminal 13, to the key holding apparatus 22.
In the key allotment report of
An application ID represents an identification number of a key allotment application with which allotment of the current authentication technique is requested.
An SP-ID represents an identification number of the service provider terminal 13 (service provider SP).
An expiration date represents an expiration date for the allotted authentication technique.
An encrypted verifying key represents a verifying key Kr of the allotted authentication technique, and represents a format of the encrypted data E(KSP, Kr) encrypted by the unique key KSP of the service provider terminal 13 (service provider SP) to whom the allotment is applied for.
Further, the key allotter terminal 12 adds a new record to the key allotment table of
Returning to
At this time, as will be described later, the key allotter terminal 12 bills the authenticated user User (IC card 23) so as to correspond with the service (step S26 of
The CPU 51 of the key holding apparatus 22 sends the key allotment report received in step S17 to the service provider terminal 13 in step S18. Thereafter, the key holding apparatus 22 destroys the key allotment application and the key allotment report.
As will be described later, the service provider terminal 13 receives the key allotment report sent from the key holding apparatus 22 in this way (step S43 of
Referring next to
When the user terminal 21 sends the selected service to the service provider terminal 13 in step S11 of
And as mentioned above, the key holding apparatus 22 receives the key allotment application in step S12 of
Then, the CPU 81 of the key allotter terminal 12 of
After these checks, the CPU 81 executes the “mutual authentication+key sharing process with the key holding apparatus” in step S22, and it executes the “key holding apparatus user authentication process” in step S23.
Note that a description of the “mutual authentication+key sharing process with the key holding apparatus” in step S22 will be omitted here since it is described in detail with reference to the above-mentioned “mutual authentication+key sharing process with the key allotter” in step S14 of
Similarly, a description of the “key holding apparatus user authentication process” in step S23 will be omitted here since it is described in detail with reference to the above-mentioned “user authentication response process” in step S15 of
And the CPU 81 generates the new key Kr (and the identification number KID) and sends them to the key holding apparatus 22 in step S24.
As mentioned above, the key holding apparatus 22 receives this new key Kr (and the identification number KID) in step S16 of
Next, the CPU 81 prepares the key allotment report and sends it to the key holding apparatus 22 in step S25, and bills the user terminal 21 (user User) in step S26.
At this time, as mentioned above, the key holding apparatus 22 receives this key allotment report for sending to the service provider terminal 13 in steps S17 and S18 of
Referring next to
As mentioned above, the user terminal 21 sends the selected service to the service provider terminal 13 in step S11 of
Specifically, in this example, the storage section 108 of the service provider terminal 13 of
Thus, when accessed by the user terminal 21, the CPU 101 presents this Home page onto the browser of the user terminal 21.
When the user User browses the Home page presented via the user terminal 21 and selects the selected service as mentioned above, the user terminal 21 sends that selected service.
Then, the CPU 101 receives that selected service in step S41, generates the key allotment application, and sends to the user terminal 21 in step S42.
Thereafter, as mentioned above, after executing steps S12 to S17 of
Then, the CPU 101 receives the key allotment report in step S43. And the CPU 101 extracts the Key-ID, the expiration date, the service content, and the verifying key from the key allotment report and the key allotment application corresponding thereto, and adds the verifying key to the authentication information table of
Referring next to the flowcharts of
Referring first to
The CPU 51 (
Specifically, for instance, in this example, the CPU 51 provides the user terminal 21 with service content from the service information table of
And the CPU 51 obtains it via the communication processing section 57, whereby it selects the service.
The CPU 51 of the key holding apparatus 22 generates a service request, and sends to the service provider terminal 13 in step S62.
Note that in this example, the sending address is supposed to be included as part of the service content. In
As will be described later, the service provider terminal 13 receives the service request, extracts a verifying key corresponding to the Key-ID included in the service request from the authentication information table of
When determining that there is no record corresponding to the Key-ID in the authentication information table of
On the other hand, when determining that the verifying key selection+expiration date examination is acceptable, the service provider terminal 13 goes to step S83 of
At this time, the CPU 51 executes a “by-purpose authentication response process” corresponding to the “by-purpose authentication verification process” of step S83 in step S63.
Exemplary details of steps S63 and S83 are shown in
Referring thus to
In
At this time, when receiving this, the CPU 51 of the key holding apparatus 22 selects a certifying key (certifying key obtained from the certifying key table of
When receiving this, the service provider terminal 13 checks that the encrypted data E(Kr, Ra) can be decrypted by the verifying key Kr (can obtain the random number Ra) in step S83-2, whereby it checks that the key holding apparatus 22 has the verifying key Kr of the allotted authentication technique.
By contrast,
In
At this time, when receiving this, the CPU 51 of the key holding apparatus 22 generates a common key Kses in step S63-11. And the CPU 51 selects a certifying key (certifying key obtained from the certifying key table of
When receiving this, the service provider terminal 13 decrypts the encrypted data E(Kr, Ra∥Kses) by the verifying key Kr to check its matching with the random number Ra, in step S83-12, whereby it checks that the key holding apparatus 22 has the verifying key Kr of the allotted authentication technique, and also obtains the common key Kses (makes the common key Kses as a temporary shared cryptographic key).
Returning to
Details of the “service utilization process” in this example are shown in
In
Provided that, there may be some cases where there is no need to specify the command Cmd, depending on the purpose, and in that case, the command Cmd will be omitted.
When receiving the request Cmd∥Parm, the service provider terminal 13 performs a process corresponding thereto in step S85-1, and it returns (sends) a response Resp to the key holding apparatus 22 in step S85-2.
The CPU 51 receives the response Resp and obtains a result of the request Cmd∥Parm from the response Resp in step S64-2.
By contrast,
In
When receiving the encrypted data E(Kses, Cmd∥Parm), the service provider terminal 13 decrypts it with the common key Kses to obtain the request Cmd∥Parm to perform a process corresponding thereto, and generates a response Resp in step S85-11. And the service provider terminal 13 encrypts the response Resp by the common key Kses, and returns (sends) encrypted data E(Kses, Resp) to the key holding apparatus 22 (step S85 of
The CPU 51 receives the encrypted data E(Kses, Resp), and decrypts it by the common key Kses, and obtains a result thereof in step S64-12.
Note that as will be described later, the process by the service provider terminal (step S85) corresponding to the “service utilization process (step S64)” by the key holding apparatus 22 of
Referring next to
As mentioned above, the key holding apparatus 22 selects a service, generates a service request corresponding thereto, and sends to the service provider terminal 13 in steps S61 and S62 of
At this time, the CPU 101 (
The CPU 101 determines in step S82 whether or not the “authentication key selection+expiration date examination” is acceptable, and if it determines that the “authentication key selection+expiration date examination” is unacceptable (determined as not acceptable), then it ends the process.
On the other hand, if the CPU 101 determines in step S82 that the “authentication key selection+expiration date examination” is acceptable, then it executes the “by-purpose authentication verification process” in step S83.
Note that a description of the “by-purpose authentication verification process” in step S83 will be omitted here since it is described in detail with reference to the above-mentioned “by-purpose authentication response process” in step S63 of
The CPU 101 determines whether or not the authentication is successful as a result of step S83 in step S84, and if it determines that the authentication is unsuccessful (not successful), then it ends the process.
On the other hand, if the CPU 101 determines in step S84 that the authentication is successful, then it executes the “service provision process” in step S85, after which it ends the process.
Note that a description of the “service provision process” in step S85 will be omitted here since it is described in detail with reference to the above-mentioned “service utilization process” in step S64 of
Referring next to the flowcharts of FIGS. 37 to 39, the “key deletion process (process in step S6 of
Provided that, as shown in each of FIGS. 37 to 39, the respective “key deletion processes” by the user apparatus 11, the key allotter terminal 12, and the service provider terminal 13 are similar to one another, and thus only the “key deletion process” by the key allotter terminal 12 will herein be described with reference to
The CPU 81 (
In this example, for instance, supposing a trigger for key deletion is externally given via the input section 86 or the like, then the CPU 81 obtains this trigger as a key clearance request. Note that this trigger may be given periodically or at an arbitrary time.
The CPU 81 extracts a first record from the key allotment table of
When determining in step S123 that the key is not the one within the expiration date, the CPU 81 deletes that record in step S125, and determines whether or not that record (the deleted record) is the last record in step S126.
On the other hand, when determining in step S123 that the key is the one within the expiration date, the CPU 81 determines in step S126 whether or not that record (the deleted record) is the last record without deleting the record (without executing step S125).
When determining in step S126 that it is not the last record, the CPU 81 extracts a next record in step S124, and returns to step S123 to repeat the step forward.
That is, the CPU 81 determines sequentially whether or not the respective first to last records is within the expiration dates, and deletes any record which passes the expiration date. And when ending the process up to the last record (a loop of steps S123 to 125), the CPU 81 determines in step S126 that it is the last record, and thus ends the process.
Note that the table for deletion in the key deletion process by the service provider terminal 13 is supposed to be the authentication information table of
Referring next to the flowcharts of
Referring first to
When an allotted authentication technique needs to be revoked, the CPU 81 (
As shown in
The message authentication code is generated by utilizing a unique cryptographic key (unique cryptographic key obtained from the service provider key table of
And the CPU 81 deletes the key and its auxiliary information in step S162.
Specifically, the CPU 81 deletes a record corresponding to the authentication technique the use of which is to be terminated from the key allotment table of
Referring next to
As mentioned above, the key allotter terminal 12 sends, for instance, the key use termination request of
At this time, the CPU 101 (
The CPU 101 determines whether or not the request examination is acceptable, in Step S182, and if it determines that the request examination is acceptable, then it deletes the key and its auxiliary information in step S183, and ends the process.
Specifically, the CPU 101 deletes a record corresponding to the authentication technique having the specified identification number Key-ID from the authentication information table of
On the other hand, if it determines in step S182 that the request examination is unacceptable (not acceptable), the CPU 101 ends that process without executing step S183 (without deleting the key and its auxiliary information).
In this exemplary configuration, an authentication center terminal 211 is further connected to the network 14, in place of the general-purpose account manager terminal 15 of
In
That is, in the second embodiment, as shown in
Provided that, it is supposed that both the key allotter terminal 12 (key allotter KA) and the service provider terminal 13 (service provider SP) know the invalidation status of their certificates beforehand (periodically collect related CRL), and thus it is supposed that verification of the invalidation status is required only of the IC card (user User).
FIGS. 46 to 50 represent examples of data held by the key allotter terminal 12.
That is, in this example, for instance, in the memory (the storage section 88 or the like of
In this example, for instance, each of the key allotment table of
In the key allotment table of
The Key-ID represents an identification number of the allotted authentication technique, and is assigned to be unique.
An Acc-ID represents an identification number under the public key authentication infrastructure of the user terminal 21 (user User) who pays when the authentication technique is allotted.
An HW-ID represents an identification number of a key holding apparatus 22 to which the authentication technique is allotted.
A certifying key represents a certifying key (private key for the public key cryptography) of the authentication technique.
Each of a key allotment application and a key allotment report represents a key allotment application issued from the service provider terminal 13 (service provider SP) to whom allotment of an authentication technique corresponding to this record is applied for, and a key allotment report issued by the key allotter terminal 12 (key allotter KA) so as to correspond thereto.
An example of the key allotment application is shown in
In the key allotment application of
An expiration date represents an expiration date necessary for an authentication technique the allotment of which is applied for with this key allotment application.
An SP-ID represents an identification number of the service provider terminal 13 (service provider SP), and is agreed upon by the service provider terminal 13 (service provider SP) when the service provider concludes a contract with the key allotter terminal 12 (key allotter KA).
Service content represents the content of a service (service selected by the user User) to be provided to the user User (user terminal 21) who is authenticated by this authentication technique.
An SP digital signature represents a digital signature generated for the entire key allotment application by the service provider terminal 13, in order to prevent tampering of the key allotment application and prove that the key allotment application is generated by the service provider terminal 13 (service provider SP).
In the key allotment report of
Each of an application ID and an SP-ID represents a respective one of an identification number of the key allotment application with which allotment of the authentication technique is requested, and an identification number of the service provider terminal 13 (service provider SP).
An SP-Acc-ID represents an identification number of the service provider terminal 13 (service provider SP) under the public key authentication infrastructure.
An expiration date represents an expiration date for the allotted authentication technique.
A verifying key represents a verifying key (public key for the public key cryptography) of the allotted authentication technique.
A KA digital signature represents a digital signature added to the entire key allotment report by the key allotter terminal 12, in order to prevent tampering of the key allotment report and prove that the key allotment report is generated by the key allotter terminal 12 (key allotter KA)
In the service provider key table of
The SP-ID represents an identification number of the service provider terminal 13 (service provider SP) that concludes the contract, and is assigned to be unique.
An SP-address represents an address for making contact (a URL and the like) of the service provider terminal 13. This is supposed to be where to make contact when invalidation of the authentication technique occurs and when an inquiry is to be made.
An SP-Acc-ID represents an identification number of the service provider terminal 13 (service provider SP) under the public key authentication infrastructure.
Since the key holding apparatus key table of
The key allotter PKI information of
The CA public key information of
FIGS. 53 to 58 represent examples of data held by the service provider terminal 13.
That is, in this example, for instance, in the memory (the storage section 108 or the like of
In this example, for instance, each of the authentication information table of
In the authentication information table of
The Key-ID represents an identification number of the authentication technique.
A key allotment application represents the key allotment application of
A key allotment report represents the key allotment report of
In the service provider unique information of
The invalidation key table of
The service provider PKI information of
In the key sharing parameters of
The CA public key information of
FIGS. 59 to 63 represent examples of data held by the key holding apparatus 22 or the IC card 23 (user User).
That is, in this example, for instance, in the data storage section 53 or the key storage section 54 (
In this example, for instance, both the certifying key table of
A record in each of the certifying key table of
The Key-ID of each of
A certifying key of the certifying key table of
In the authentication information table of
A key allotment report represents the key allotment report of
Since the key holding apparatus unique information of
The user PKI information of
The CA public key information of
Specifically, the key storage section 54 of
The user PKI information of
That is, in this example, for instance, in a memory of the authentication center terminal 211 (a storage section 228 or the like of
The CA key information of
The CA public key represents a public key made open and held by a participant of the authentication key allotment system 201, such as the service provider terminal 13 (service provider SP), the key allotter terminal 12 (key allotter KA), or the key holding apparatus 11 (user User).
In this example, for instance, the certificate table of
In the certificate table of
The Acc-ID represents an identification number of an entity in the public key authentication infrastructure (in this example, each of the key holding apparatus 22 (user User), the service provider terminal 13 (service provider SP), and the key allotter terminal 12 (key allotter KA)), and is assigned to be unique.
A certificate represents the content of data on a certificate, and the certificate ID represents an identification number of the certificate.
In the certificate of
An expiration date represents an expiration date for the certificate.
A certificate ID represents an identification number of the certificate.
A public key represents a public key related to the user having the Acc-ID (i.e., the user having the Acc-ID has an IC card that holds a private key corresponding to a public key Kpub0).
Auxiliary information represents other information related to the user having the Acc-ID.
A CA signature represents a digital signature generated for the entire data of the certificate by the authentication center terminal 211 (authentication center CA).
Next, an operation of the authentication key allotment system 201 to which the second embodiment of the present invention is applied will be described.
An outline of the operation of the authentication key allotment system 201 is basically similar to that of the authentication key allotment system 1 to which the first embodiment of the present invention is applied.
Therefore, the operation of the authentication key allotment system 201 will also be described with reference to the flowchart of
First, a “service selection/key allotment process” is executed in step S1.
A flow of the “service selection/key allotment process” in the second embodiment is supposed to be basically similar to that of the first embodiment. That is, the “service selection/key allotment process” in the second embodiment is executed in accordance with the above-mentioned arrow chart of
Referring thus to the arrow chart of
As shown in
The service provider terminal 13 receives a notice thereabout in step S41, and generates the key allotment application of
The key holding apparatus 22 receives and holds this temporarily in step S12, and at the same time, sends it to the key allotter terminal 12 in step S13.
When receiving this, the key allotter terminal 12 verifies a digital signature of the service provider terminal 13 in the key allotment application in step S21. Specifically, a certificate of the service provider terminal 13 (service provider SP) is also sent together with the key allotment application of
Since step S22 (a “mutual authentication+key sharing process with the key holding apparatus”) and step S14 (a “mutual authentication+key sharing process with the key allotter) in the second embodiment are similar to those in the first embodiment, descriptions thereof will be omitted.
By contrast, step S23 (a “key holding apparatus user authentication process”) and step S15 (a “user authentication response process”) in the second embodiment are different from the steps shown in
Details of step S23 (the “key holding apparatus user authentication process”) and step S15 (the “user authentication response process”) in the second embodiment are shown in
Referring thus to
As shown in
Specifically, the key holding apparatus 22 (user apparatus 11) queries the authentication center terminal 211 about the invalidation status of a user's certificate obtained from the IC card 23 connected to the key holding apparatus 22 by an OCSP protocol (RFC2560).
When receiving the data OCSP_REQ, the authentication center terminal 211 examines the validity of the certificate corresponding to the identification number CID (checks that the certificate having the identification number CID is included in the certificate table of
Specifically, the authentication center terminal 211 sorts the received data by the identification number CID and a certificate status status (VALID/INVALID/UNKNOWN).
Note that the certificate status status (VALID/INVALID/UNKNOWN) is supposed to be a function that returns UNKNOWN when it is not a certificate issued by the authentication center terminal 211, returns VALID when there is a record having a matched certificate identification number in the certificate table of
The authentication center terminal 211 generates data CID∥status∥time∥Sig(CID∥status∥time) as the examination result OCSP_REP for sending to the key holding apparatus 22 in step S192.
Note that data in which the sorted identified person's number CID and certificate status status, and an examined time time are linked together is supposed to be CID∥status∥time, and a digital signature of the authentication center CA (authentication center terminal 211) put thereon is supposed to be Sig(CID∥status∥time).
When receiving the examination result OCSP_REP in step 15-12, the key holding apparatus 22 sends the examination result OCSP_REP and a user's certificate CERTb obtained from the IC card 23 connected thereto, to the key allotter terminal 12, in step S15-13.
When receiving them, the key allotter terminal 12 extracts a public key from the user's certificate CERTb, and checks the examination result OCSP_REP in step S23-11. That is, the key allotter terminal 12 verifies the examination result OCSP_REP and the digital signature on CERTb, to check that the certificate of the user User (IC card 23) is valid.
Note that the example in which the key holding apparatus 22 obtains the invalidation status of the user's certificate by using the OCSP protocol is described here. However, examples are not limited to this one. For instance, it may be designed such that the user User (key holding apparatus 22) sends only the user's certificate to the key allotter terminal 12, and the key allotter terminal 12 obtains the invalidation status of the certificate by using the same protocol.
And the key allotter terminal 12 generates a random number Ra for sending to the key holding apparatus 22 in step S23-12.
When receiving the random number Ra in step S15-14, the key holding apparatus 22 causes the IC card 23 to compute a digital signature Sig(Ra) for the random number Ra, by utilizing the private key of the user User in step S15-15. And the key holding apparatus 22 sends data Ra∥Sig(Ra) in which the random number Ra is linked with the digital signature Sig(Ra), to the key allotter terminal 12.
When receiving the data Ra∥Sig(Ra), the key allotter terminal 12 extracts the digital signature Sig (Ra) therefrom, for verification by the public key included in the certificate the validity of which is already verified, in step S23-13. If a verification result thereof is correct, the key allotter terminal 12 is successful in identifying the Acc-ID of the user User (IC card 23).
Returning to
Specifically, the key allotter terminal 12 encrypts the identification number KID and the certifying key (new key) Kpr as encrypted data E(Kses, KID∥Kpr) by using the above-mentioned temporary key Kses shared with the key holding apparatus 22 and sends it to the key holding apparatus 22.
The key holding apparatus 22 receives the encrypted data E(Kses, KID∥Kpr), and decrypts the identification number KID and the certifying key (new key) Kpr using the temporary key Kses, in step S16. And the key holding apparatus 22 adds a new record to the certifying key table of
Further, the key allotter terminal 12 generates the key allotment report of
At the same time, the key allotter terminal 12 adds to the key allotment table of
And the key allotter terminal 12 bills the user User having the identification number AID (who owns the IC card 23) in step S26 (
When receiving the key allotment report of
At the same time, the key holding apparatus 22 adds to the authentication information table of
The service provider terminal 13 receives the key allotment report in step S43. And the service terminator 13 verifies a key allotter's signature included in the key allotment report. The service provider terminal 13, if succeeding in the authentication, adds to the authentication information table of
Returning to
Details of the “key use/service provision process” in the second embodiment are shown in flowcharts of
Referring first to
The key holding apparatus 22 (specifically, the CPU 51 (
For instance, in this example, the key holding apparatus 22, for instance, displays service content from the service information table of
The key holding apparatus 22 sends a key allotment application and a key allotment report (hereinafter written as a key allotment application+key allotment report) for the selected record to the service provider terminal 13 in step S202. Note that in this example, the sending address is supposed to be included in, for instance, service content in a document of title.
As will be described later, the service provider terminal 13 receives the key allotment application+key allotment report. And the service provider terminal 13 examines the key allotment application+key allotment report.
This examination involves determination as to whether or not the key allotment application is correct in terms of the format of
When succeeding in the application report examination+verifying key extraction, the service provider terminal 13 executes a “by-purpose authentication verification process” (steps S221 to S223 of
At this time, the key holding apparatus 22 executes a “by-purpose authentication response process” corresponding to the by-purpose authentication verification process in step S203.
That is, authentication is performed by the allotted authentication technique between the key holding apparatus 22 (user User) and the service provider terminal 13 (service provider SP).
Details of the “by-purpose authentication response process” in the second embodiment are shown in
Referring thus to
As shown in
When receiving the data KID∥Ra, the key holding apparatus 22 extracts each of the KD and the random number Ra, and selects a certifying key corresponding to the KID (certifying key obtained from the certifying key table of
The key holding apparatus 22 sends linked data KID∥Sig (Ra) in which the digital signature Sig (Ra) is linked with the KID to the service provider terminal 13 in step S203-2.
When receiving this linked data, the service provider terminal 13 extracts each of the KID and the digital signature Sig(Ra), and verifies that the digital signature Sig(Ra) satisfies E(Kpub, Sig(Ra))=h(Ra), i.e., checks that the digital signature Sig (Ra) can be decrypted by the verifying key Kpub, in step S223-2. When the verification is successful, it means that the service provider terminal is successful in authentication by the allotted authentication technique.
By contrast,
As shown in
And the service provider terminal 13 sends data KID∥Ra∥g∥p∥ya in which these are linked with the Key-ID to the key holding apparatus 22.
When receiving the data KID∥Ra∥g∥p∥ya, the key holding apparatus 22 generates a random number rb in step S203-11.
And the key holding apparatus 22 computes yb=g{circumflex over ( )}Rb mod p (a remainder of the rbth power of p where p is the modulus) in step S203-12.
Further, the key holding apparatus 22 selects a certifying key Kpr corresponding to the received KID, computes a digital signature SIG (Ra)=D(Kpr, h(Ra)) on the received Ra by utilizing the certifying key Kpr, and sends linked data KID∥SIG (Ra)∥yb in which the digital signature SIG (Ra), KID, and the computed result yb are linked together, to the service provider terminal 13.
The service provider terminal 13 verifies the received digital signature SIG(Ra) by the verifying key Kpub, i.e., verifies that the E(Kpub, SIG(Ra))=h(Ra) is satisfied in step S223-2. When this verification is successful, it means that the service provider terminal is successful in authentication by the allotted authentication technique.
In that case, the key holding apparatus 22 makes a common key Kses=ya{circumflex over ( )}Rb mod p (a remainder of the Rbth power of ya where p is the modulus) as a temporary shared key in step S203-13, and the service provider terminal 13 makes a common key Kses=yb{circumflex over ( )}Ra mod p (a remainder of the Rath power of yb where p is the modulus) as a temporary shared key in step S223-3. As a result, the key holding apparatus 22 and the service provider terminal 13 can share the common key Kses with each other.
Returning to
Referring next to
As mentioned above, the key holding apparatus 22 selects a service in step S201 of
At this time, the service provider terminal 13 (specifically, the CPU 101 (
And the service provider terminal 13 executes the “application report examination+verifying key extraction” process in step S222, and determines whether or not the “application report examination+verifying key extraction” is successful.
If it is determined in step S222 that the “application report examination+verifying key extraction” fails (is not successful), then the process is brought to an end.
On the other hand, if it is determined in step S222 that the “application report examination+verifying key extraction” is successful, the service provider terminal 13 executes the “by-purpose authentication verification process” in step S223.
Note that details of the “by-purpose authentication verification process” are described (mentioned above) with reference to step S203 of
The service provider terminal 13 determines whether or not the authentication is successful in step S224, and if it determines that the authentication fails (is not successful), it ends the process.
On the other hand, if it determines in step S224 that the authentication is successful, the service provider terminal 13 executes the “service provision process” corresponding to
Returning to
Step S6 (a “key deletion process”) to which the second embodiment is applied is similar to that of the above-mentioned “key deletion process” to which the first embodiment is applied. That is, the “key deletion process” is executed according to any of the above-mentioned flowcharts of FIGS. 37 to 39.
Provided that, in the second embodiment, objects for deletion are supposed to be the key allotment table of
Step S7 (a “key use termination process”) to which the second embodiment is applied is similar to that of the above-mentioned “key use termination process” to which the first embodiment is applied. That is, the “key use termination process” is executed according to the above-mentioned flowcharts of
Provided that, in the second embodiment, in addition to an operation of deleting a record having a Key-ID specified by the key use termination request from the authentication information table of
Further, the key use termination request generated by the key allotter terminal 12 and sent to the service provider terminal 13 in step S161 of
The key use termination request of
Note that the key allotter terminal 12 can obtain, for the allotted authentication technique, an identification number SP-ID of the service provider who is allotted with the authentication technique from an item for “key allotment application” in the key allotment table of
In this way, in the authentication key allotment system 201 to which the second embodiment is applied, the authentication technique to be allotted is supposed to be the public key authentication system, and thus the steps (steps S221 to S224 of
In this exemplary configuration, the authentication center terminal 211 is further connected to the network 14, with respect to the authentication key allotment system 1 of
In the third embodiment, as shown in
Note that the key allotter terminal 12 (key allotter KA) knows the invalidation status of a certificate of the service provider terminal 13 (service provider SP) beforehand (periodically collects related CRL).
FIGS. 73 to 77 represent examples of data held by the key allotter terminal 12.
That is, in this example, for instance, in the memory (the storage section 88 or the like of
In this example, for instance, each of the key allotment table of
In the key allotment table of
The Key-ID represents an identification number of the allotted authentication technique, and is assigned to be unique.
An Acc-ID represents an identification number under the general-purpose account of the user User (key holding apparatus 22) who pays when the authentication technique is allotted.
An HW-ID represents an identification number of the key holding apparatus 22 to which the authentication technique is allotted.
An SP-ID represents an identification number of the service provider terminal 13 (service provider SP) that is allotted with the authentication technique.
An expiration date represents an expiration date for the authentication technique.
A verifying key represents a verifying key (a public key for the public key cryptography) of the allotted authentication technique.
A certifying key represents a certifying key (a private key for the public key cryptography) of the allotted authentication technique.
A document of title represents data generated by the service provider terminal 13 (service provider SP) in order to certify a service to be provided thereby, when key allotment is performed.
The document of title is constituted as shown in, for instance,
In the document of title of
In the service provider key table of
The SP-ID represents an identification number of the service provider terminal 13 (service provider SP) that concludes the contract with the key allotter terminal 12 (key allotter KA), and is assigned to be unique at the time the contract is concluded.
An SP-address represents a sending address (a URL and the like) of the service provider terminal 13. This is supposed to be where to make contact when invalidation of the authentication technique occurs and when an inquiry is to be made.
An SP-Acc-ID represents an identification number of the service provider terminal 13 (service provider SP) under the public key authentication infrastructure.
A unique cryptographic key represents a cryptographic key agreed upon between the service provider terminal 13 (service provider SP) and the key allotter terminal 12 (key allotter KA) when the contract is concluded, and this cryptographic key is used in order to guarantee the anonymity and integrity of communication between both parties.
Since the key holding apparatus key table of
Since the key allotter account information of
Since the CA public key information of
FIGS. 81 to 86 represent examples of data held by the service provider terminal 13.
That is, in this example, for instance, in the memory (the storage section 108 or the like of
In this example, for instance, the authentication information table of
In the authentication information table of
The Key-ID represents an identification number of the authentication technique. A document of title represents a document of title issued to the authentication technique on which key allotment is performed.
Since the service provider unique information of
Since each of the invalidation key table of
Since the CA public key information of
FIGS. 87 to 91 represent examples of data held by the key holding apparatus 22 or the IC card 23 (user User).
That is, in this example, for instance, in the data storage section 53 or the key storage section 54 (
In this example, for instance, the certifying key table of
Since each of the certifying key table of
In the authentication information table of
The Key-ID represents an identification number of the authentication technique. A document of title represents a document of title issued to the authentication technique on which key allotment is performed.
Since the CA public key information of
Specifically, the key storage section 54 of
The user count information of
In the memory (the storage section 128 or the like of
In the memory (the storage section 228 or the like of
Provided that, the entities involved in the public key authentication infrastructure, corresponding to the identification numbers represented by the Acc-ID of the certificate table of
Next, an operation of the authentication key allotment system 301 to which the third embodiment of the present invention is applied will be described.
An outline of the operation of the authentication key allotment system 301 is basically similar to that of the authentication key allotment system 1 to which the first embodiment of the present invention is applied (and the authentication key allotment system 201 to which the second embodiment of the present invention is applied).
Therefore, the operation of the authentication key allotment system 301 will also be described with reference to the flowchart of
First, a “service selection/key allotment process” is executed in step S1.
The “service selection/key allotment process” in the third embodiment is supposed to be basically similar to that of the first embodiment, but differs therefrom slightly.
Details of such “service selection/key allotment process” in the third embodiment are shown in flowcharts of FIGS. 92 to 94 and an arrow chart of
Therefore, referring to the arrow chart of
In
The service provider terminal 13 receives the selected service in step S341, and generates a key allotment application for sending to the key holding apparatus 22 in step S342.
The key holding apparatus 22 (user apparatus 11) receives and holds this temporarily in step S302, and at the same time, sends it to the key allotter terminal 12 in step S303.
When receiving the key allotment application, the key allotter terminal 12 verifies a digital signature of the service provider terminal 13 (service provider SP) in the key allotment application in step S321.
In the key allotment application of
An expiration date represents an expiration date necessary for an authentication technique the allotment for which is applied with this key allotment application.
An SP-ID represents an identification number of the service provider terminal 13 (service provider SP), and is agreed upon beforehand by the service provider terminal 13 (service provider SP) at the time the service provider concludes a contract with the key allotter terminal 12 (key allotter KA).
A message authentication code represents a code generated for the key allotment application data utilizing the service provider unique cryptographic key, and prevents tampering of the key allotment application and proves that the key allotment application is generated by the service provider terminal 13 (service provider SP).
Returning to
Note that each of steps S322 and S304 is basically similar to a respective one of the above-mentioned steps S22 and S14 of
At this stage, the key holding apparatus 22 and the key allotter terminal 12 share a temporary cryptographic key Kses.
And each of the key holding apparatus 22 and the key allotter terminal 12 executes step S323 (a “key holding apparatus user authentication process” on the key allotter terminal 12 side) or step S305 (a “user authentication response process” on the key holding apparatus 22 side).
Note that each of steps S323 and S305 is supposed to be basically similar to a respective one of the above-mentioned steps S23 and S15 of
At this stage, the key allotter terminal 12 can identify the user User (user terminal 21) who holds the key holding apparatus 22.
The key allotter terminal 12 generates a new key for sending to the key holding apparatus 22 in step 324.
Specifically, for instance, the key allotter terminal 12 decides an identification number KID of an authentication technique to be allotted to the key holding apparatus 22 so as not to be duplicate with previous one(s), and newly generates a pair (Kpr, Kpub) of a private key and a public key of the public key cryptography from a random number by an appropriate method. That is, this pair of keys (Kpr, Kpub) is supposed to be the new keys and used as a certifying key and a verifying key of the authentication technique to be newly allotted.
And the key allotter terminal 12 sends the identification number KID and the certifying key Kpr to the key holding apparatus 22. More specifically, the key allotter terminal 12 sends the identification number KID and the certifying key Kpr to the key holding apparatus 22 as encrypted data E(Kses, KID∥Kpr), using the temporary key shared with the key holding apparatus 22.
The key holding apparatus 22 receives the new key in step S306.
Specifically, the key holding apparatus 22 receives the encrypted data E(Kses, KID∥Kpr), and decrypts the identification number KID and the certifying key Kpr. And it adds a new record to the certifying key table of
And the key allotter terminal 12 generates a key allotment report for sending to the key holding apparatus 22 in step S325.
At the same time, the key allotter terminal 12 adds (leaving the part for document of title empty) to the key allotment table of
In the key allotment report of
An application ID represents an identification number of the key allotment application with which the current allotment of the authentication technique is requested.
An expiration date represents an expiration date for the allotted authentication technique.
A verifying key represents a verifying key of the allotted authentication technique.
A message authentication code represents a code generated to the key allotment report data by utilizing the unique cryptographic key of the service provider terminal 13 (service provider SP) (unique cryptographic key obtained from the service provider table of
Returning to
The service provider terminal 13 receives the key allotment report in step S343. And the service provider terminal 13 verifies the message authentication code of the key allotter in the key allotment report.
When succeeding in the authentication, the service provider terminal 13 generates the document of title of
At this time, the key holding apparatus 22 adds the identification number Key-ID of the authentication technique and the document of title as a new record to the authentication information of
The key allotter terminal 12 receives the document of title, and bills the user User (user terminal 21).
Specifically, the key allotter terminal 12, after checking that the digital signature on the received document of title is generated by the service provider terminal 13 (service provider SP), adds the document of title to the part for document of title in the record of the key allotment table of
And the key allotter terminal 12 bills the user User (user terminal 21) identified in the above-mentioned step S323 so as to correspond with the service content in the document of title and total of commissions for the key allotment.
Returning to
Details of a “key use/service provision process” in the third embodiment are shown in flowcharts of
Referring first to
The key holding apparatus 22 (specifically the CPU 51 (
For instance, in this example, the key holding apparatus 22 displays service content included in documents of title included in the authentication information table of
The key holding apparatus 22 sends the document of title (document of title of the selected record in the authentication information table of
As will be described later, the service provider terminal 13 receives the document of title. And the service provider terminal 13 examines the document of title.
This examination involves determination as to whether or not the document of title is correct in terms of the format of
When succeeding in the “document of title examination +verifying key extraction”, the service provider terminal 13 executes a “by-purpose authentication verification process” (steps S381 to S383 of
At this time, the key holding apparatus 22 executes a “by-purpose authentication response process” corresponding to the “by-purpose authentication verification process” in step S363.
That is, authentication is performed by the allotted authentication technique between the key holding apparatus 22 (user User) and the service provider terminal 13 (service provider SP).
Each of step S363 (the “by-purpose authentication response process”) and step S383 of
That is, authentication is performed by the allotted authentication technique between the key holding apparatus 22 and the service provider terminal 13 (service provider SP).
The key holding apparatus 22 executes the above-mentioned “service utilization process” corresponding to
Referring next to
As mentioned above, the key holding apparatus 22 selects a service in step S361 of
At this time, the service provider terminal 13 (specifically the CPU 101 (
And the service provider terminal 13 executes a “document of title examination+verifying key extraction” process in step S382, to determine whether or not the “document of title examination+verifying key extraction” is successful.
If it is determined in step S382 that the “document of title examination+verifying key extraction” fails (it is determined as not being successful), the process is brought to an end.
On the other hand, if it is determined in step S382 that the “document of title examination+verifying key extraction” is successful, the above-mentioned “by-purpose authentication verification process” is executed in step S383.
The service provider terminal 13 determines whether or not the authentication is successful, and if it determines that the authentication fails (is not successful), it ends the process in step S384.
On the other hand, if it determines in step S384 that the authentication is successful, the service provider terminal 13 executes the above-mentioned “service provision process” corresponding to
Returning to
Step S6 (the “key deletion process”) to which the third embodiment is applied is similar to the above-mentioned “key deletion process” to which the first embodiment is applied. That is, the “key deletion process” is executed according to any of the above-mentioned flowcharts of FIGS. 37 to 39.
Provided that, in the third embodiment, objects for deletion are supposed to be the key allotment table of
Step S7 (the “key use termination process”) to which the third embodiment is applied is similar to the above-mentioned “key use termination process” to which the second embodiment is applied. That is, the “key use termination process” is executed according to the above-mentioned flowcharts of
Further, the key use termination request generated by the key allotter terminal 12 and sent to the service provider terminal 13 in step S161 of
In this way, in the authentication key allotment system 301 to which the third embodiment is applied, the authentication technique to be allotted is supposed to be the public key authentication system, and thus the steps (steps S381 to S384 of
Further, as compared with the second embodiment, authentication requires only one certificate, whereby an advantage is obtained that data volume and processing time can be reduced.
A configuration of an authentication key allotment system to which the fourth embodiment of the present invention is applied is similar to the configuration of
In the fourth embodiment, the key allotter AP (key allotter terminal 12) generates digital signatures verifiable by the public key authentication infrastructure, and the user User (key holding apparatus 22) is authenticated by the general-purpose account system. An example in which an authentication technique for the public key authentication is newly allotted in this case will be described.
Note that the user User (key holding apparatus 22) and the service provider SP (service provider terminal 13) know the invalidation status of a certificate of the key allotter terminal 12 (key allotter KA) beforehand (periodically collect related CRL).
FIGS. 98 to 102 represent examples of data held by the key allotter terminal 12.
That is, in this example, for instance, in the memory (the storage section 88 or the like of
In this example, for instance, each of the key allotment table of
In the key allotment table of
The Key-ID represents an identification number of the allotted authentication technique, and is assigned to be unique.
An Acc-ID represents an identification number under the general-purpose account of the user User (user terminal 21) who pays when the authentication technique is allotted.
An HW-ID represents an identification number of the key holding apparatus 22 to which the authentication technique is allotted.
A certifying key represents a certifying key (private key for the public key cryptography) of the allotted authentication technique.
A document of title represents data generated by the service provider terminal 13 (service provider SP) to prove a service to be provided thereby, when key allotment is performed.
In the document of title of
Service content represents the content of a service provided to a user User (user terminal 21) (having the key holding apparatus 22) to be authenticated by an authentication technique having the Key-ID.
An SP-ID represents an identification number of the service provider terminal 13 (service provider SP) who provides the service, and is assigned to the service provider terminal 13 (service provider SP) so as to be unique at the time the service provider concludes a contract with the key allotter terminal 12 (key allotter KA).
A KA digital signature represents a digital signature generated for the entire data in the document of title by the key allotter.
Since each of the service provider key table of
Since the CA public key information of
FIGS. 105 to 108 represent examples of data held by the service provider terminal 13.
That is, in this example, for instance, in the memory (the storage section 108 or the like of
In this example, for instance, the invalidation key table of
Since each of the service provider unique information of
Since the CA public key information of FIG. .108 is supposed to have the same configuration as the CA publican key information of
FIGS. 109 to 113 represent examples of data held by the key holding apparatus 22 or the IC card 23 (user User).
That is, in this example, for instance, in the data storage section 53 or the key storage section 54 (
Since each of the certifying key table of
Since the CA public key information of
For instance, the key storage section 54 of
The user count information of
In the memory (the storage section 128 or the like of
In the memory (the storage section 228 or the like of
Provided that, the entity involved in the public key authentication infrastructure, corresponding to the identification number represented by the Acc-ID in the certificate table of
Next, an operation of the authentication key allotment system 301 to which the fourth embodiment of the present invention is applied will be described.
An outline of the operation of the authentication key allotment system 301 is basically similar to that of that (and the authentication key allotment system 1 to which the first embodiment of the present invention is applied and the authentication key allotment system 201 to which the second embodiment of the present invention is applied).
Therefore, the operation of the authentication key allotment system 301 to which the fourth embodiment of the present invention is applied will also be described with reference to the flowchart of
First, a “service selection/key allotment process” is executed in step S1.
The “service selection/key allotment process” in the fourth embodiment is supposed to be basically similar to that of the third embodiment, but differs therefrom slightly.
Details of such “service selection/key allotment process” in the fourth embodiment are shown in flowcharts of
Therefore, referring to the arrow chart of
In
The service provider terminal 13 receives the selected service in step S441, and generates a key allotment application for sending to the key holding apparatus 22 in step S442.
The key holding apparatus 22 (user apparatus 11) receives and holds this temporarily in step S403, and at the same time, sends it to the key allotter terminal 12 in step S402.
When receiving the key allotment application, the key allotter terminal 12 verifies a message authentication code of the service provider terminal 13 (service provider SP) in the key allotment application in step S421.
In the key allotment application of
An expiration date represents an expiration date necessary for an authentication technique the allotment for which is applied with this key allotment application.
Service content represents the content of a service which is planned to be provided by the service provider terminal 13 (service provider SP) to a user User (user terminal 21) to whom key allotment will be performed.
An SP-ID represents an identification number of the service provider terminal 13 (service provider SP), and is agreed upon beforehand by the service provider terminal 13 (service provider SP) at the time the service provider concludes a contract with the key allotter terminal 12 (key allotter KA).
A message authentication code represents a code generated for the key allotment application data by utilizing the service provider unique cryptographic key, and prevents tampering of the key allotment application and proves that the key allotment application is generated by the service provider terminal 13 (service provider SP).
Returning to
Note that each of steps S422 and S404 is supposed to be basically similar to a respective one of the above-mentioned steps S22 and S14 of
At this stage, the key holding apparatus 22 and the key allotter terminal 12 share a temporary cryptographic key Kses.
And each of the key holding apparatus 22 and the key allotter terminal 12 executes step S423 (a “key holding apparatus user authentication process” on the key allotter terminal 12 side) or step S405 (a “user authentication response process” on the key holding apparatus 22 side).
Note that each of steps S423 and S405 is supposed to be basically similar to a respective one of the above-mentioned steps S23 and S15 of
At this stage, the key allotter terminal 12 can identify the user User (user terminal 21) who holds the key holding apparatus 22.
The key allotter terminal 12 generates new keys for sending to the key holding apparatus 22 in step 424.
Specifically, the key allotter terminal 12 decides an identification number KID of an authentication technique to be allotted to the key holding apparatus 22 so as not to be duplicate with previous one(s) similarly to the above-mentioned third embodiment, and newly generates a pair (Kpr, Kpub) of a private key and a public key for the public key cryptography from a random number in an appropriate way. That is, this pair of keys (Kpr, Kpub) is supposed to be the new keys and used as a certifying key and a verifying key of the authentication technique to be newly allotted.
And the key allotter terminal 12 sends the identification number KID and the certifying key Kpr to the key holding apparatus 22. More specifically, the key allotter terminal 12 sends the identification number KID and the certifying key Kpr to the key holding apparatus 22 as encrypted data E(Kses, KID∥Kpr), by using the temporary key shared with the key holding apparatus 22.
The key holding apparatus 22 receives the new key in step S406.
Specifically, the key holding apparatus 22 receives the encrypted data E(Kses, KID∥Kpr), and decrypts the identification number KID and the certifying key Kpr. And it adds a new record to the certifying key table of
And the key allotter terminal 12 generates a document of title for sending to the key holding apparatus 22 in step S425.
That is, although the key allotter terminal 12 generates the key allotment report of
At this time, the key allotter terminal 12 adds to the key allotment table of
The key holding apparatus 22 receives the document of title in step S407.
And the key holding apparatus 22, after checking that the digital signature is generated by the key allotter terminal 12 (key allotter KA), on the received document of title, adds to the authentication information table of
Returning to
A flow of the “key use/service provision process” in the fourth embodiment is basically similar to that of the third embodiment. That is, the “key use/service provision process” in the fourth embodiment is also executed according to the flowcharts of
Provided that, in the fourth embodiment, a document of title examination (examination performed on the document of title received by the service provider terminal 13 in step S381 of
Returning to
Step S6 (the “key deletion process”) to which the fourth embodiment is applied is similar to the above-mentioned “key deletion process” to which the first embodiment is applied. That is, the “key deletion process” is executed according to any of the above-mentioned flowcharts of FIGS. 37 to 39.
Provided that, in the fourth embodiment, objects for deletion are supposed to be the key allotment table of
Step S7 (the “key use termination process”) to which the fourth embodiment is applied is similar to the above-mentioned “key use termination process” to which the second embodiment is applied. That is, the “key use termination process” is executed according to the above-mentioned flowcharts of
Provided that, in the “key user termination process” in the fourth embodiment, the service provider terminal 13 does not hold a table corresponding to the authentication information table of
Further, the key use termination request generated by the key allotter terminal 12 and sent to the service provider terminal 13 in step S161 of
In this way, in the authentication key allotment system 301 to which the fourth embodiment is applied, the authentication technique to be allotted is supposed to be the public key authentication system, and thus the steps (steps S381 to S384 of
Further, as compared with the third embodiment, an advantage can be obtained that the number of communication sessions required at the time of key allotment can be reduced. In the foregoing, the authentication key allotment systems to which the present invention is applied are described by division into the first to fourth embodiments. These authentication key allotment systems can provide advantages such as shown in items (1) to (6) below.
(1) It is arranged such that an exclusive authentication technique is allotted between two parties who require authentication to perform the authentication directly between the two parties, whereby the authentication can be performed efficiently compared to a method dependent on the authentication center such as the Kerberos system.
(2) It is arranged such that an exclusive authentication technique is allotted between two parties. Thus, even when the authentication technique needs to be revoked, the other party to be notified thereabout can be identified unlike in a case where only one authentication technique is used among an indefinite number of people such as in the public key authentication infrastructure. Consequently, the invalidation can be performed efficiently.
(3) It is arranged such that when an exclusive authentication technique is allotted between two parties, its intended use is fixed. Thus, the authenticating party does not have to directly identify the authenticated party thereby to limit services to be provided by each individual authentication technique. Consequently, damage can be suppressed when the authentication technique is abused, and the anonymity of the authenticated party can also be protected.
(4) It is arranged such that a user must be identified for billing purposes only when an exclusive authentication technique is allotted between two parties, and the user no longer have to be identified thereafter whenever using the authentication technique. This can help the user feel secure.
(5) A service provider no longer has to manage the content of a service to be provided and authentication means when the public key authentication is used as an authentication technique to be allotted between two parties.
(6) It is arranged such that a user can check an authentication technique allotted to the key holding apparatus by himself when the public key authentication is used as the authentication technique to be allotted between two parties. This permits the user to feel more secure.
As mentioned above, the fifth embodiment is an embodiment corresponding to the second embodiment, and a configuration of an authentication key allotment system to which the fifth embodiment of the present invention is applied is similar to the configuration of
By the way, in the second embodiment, the cryptographic keys for a new authentication technique are generated by the key allotter terminal 12, but in the fifth embodiment, the cryptographic keys for a new authentication technique are generated by the key holding apparatus 22 of the user apparatus 11.
Therefore, in the fifth embodiment, the key holding apparatus 22 further needs to have a function of generating cryptographic keys for a new authentication technique.
That is, also in the fifth embodiment, similar to the second embodiment, a pair of a private key and a public key for the public key cryptography (hereinafter called as a public key pair) (Kpr, Kpub) is used as the cryptographic keys for a new authentication technique. Therefore, the key holding apparatus 22 needs to further have a function of newly generating a public key pair (Kpr, Kpub) from a random number by, for instance, an appropriate method (methods are not particularly limited; a standard method is defined, for instance, in IEEE-P1363, and that method can be applied.)
Such a function is easily implementable also by the key holding apparatus 22 having the above-mentioned configuration of
Such generation of a random number can also be executed by hardware. In this case, the key holding apparatus 22 is designed to have, for instance, the above-mentioned configuration shown in
Note that in the first to fourth embodiments, the descriptions are given on the assumption that the key allotter terminal 12 generates a random number utilizing software (the CPU 81 of
Each of the other apparatuses in the fifth embodiment, i.e., the user terminal 21, the IC card 23, the key allotter terminal 12, the service provider terminal 13, and the authentication center terminal 211 has a basically similar function and configuration to a respective one of the corresponding apparatuses of the second embodiment. Therefore, descriptions of the other apparatuses will be omitted.
Further, each of the apparatuses constituting the authentication key allotment system to which the fifth embodiment is applied has data basically similar to the data held by a respective one of the corresponding apparatuses of the second embodiment, but differ therefrom slightly.
Thus, data held by each of the apparatuses constituting the authentication key allotment system to which the fifth embodiment is applied will be described below.
That is, also in the fifth embodiment, the key allotter terminal 12 holds a service provider key table such as shown in
Provided that, in the fifth embodiment, a certifying key is generated by the key holding apparatus 22 kept by the user User, and thus the key allotter terminal 12 keeps a key allotment table such as shown in
In the key allotment table of
That is, also in the fifth embodiment, for instance, each of the above-mentioned key allotment application shown in
The service provider terminal 13 keeps, also in the fifth embodiment, an authentication information table such as shown in
The key holding apparatus 22 or the IC card 23 (user User) keeps, also in the fifth embodiment, a certifying key table such as shown in
Furthermore, in the fifth embodiment, the key holding apparatus 22 keeps key holding apparatus PKI information such as shown in
The key holding apparatus PKI information of
That is, when the key holding apparatus 22 performs mutual authentication with the key allotter terminal 12 using SSL (Secure Socket Layer) and TLS (Transport Layer) in a “mutual authentication+key sharing process with the key allotter” in step S504 of
Note that details of the mutual authentication using SSL, TLS will be described later with reference to
Further, in the fifth embodiment, the key holding apparatus 22 generates cryptographic keys (a certifying key and a verifying key to be paired therewith) by itself, and thus keeps a temporal holding key table shown in
In detail, for instance, the key holding apparatus 22 generates the temporal holding key table of
Furthermore, the key holding apparatus 22 also keeps an authenticating key table such as shown in
In other words, in the authenticating key table of
The key holding apparatus 22 holds the thus generated authenticating key table of
And the key holding apparatus 22 generates and holds (keeps) the temporal holding key table of
Note that when the key holding apparatus 22 generates new keys, much of its processing is executed by the computation processing section 56 within the key holding apparatus 22. Further, the temporal holding key table of
The authentication center terminal 211 keeps, also in the fifth embodiment, a certificate table such as shown in
Further, the authentication center terminal 211 (authentication center CA) issues a certificate such as shown in
Next, an operation of the authentication key allotment system 201 (
An outline of the operation of the authentication key allotment system 201 in the fifth embodiment is basically similar to that of the second embodiment of the present invention.
Therefore, the operation of the authentication key allotment system 201 to which the fifth embodiment of the present invention is applied will be described with reference to the flowchart of
First, a “service selection/key allotment process” is executed in step S1.
The “service selection/key allotment process” in the fifth embodiment is supposed to be basically similar to that of the second embodiment, but differs therefrom slightly.
Details of such “service selection/key allotment process” in the fifth embodiment are shown in flowcharts of
Thus, referring to the arrow chart of
As shown in
The service provider terminal 13 receives the selected service in step S541, and generates the key allotment application of
The key holding apparatus 22 receives the key allotment application and holds it temporarily in step S502, and at the same time, sends it to the key allotter terminal 12 in step S503.
When receiving the key allotment application, the key allotter terminal 12 verifies the digital signature of the service provider terminal 13 in the key allotment application in step S521.
Each of the key holding apparatus 22 and the key allotter terminal 12 executes step S522 (a “mutual authentication+key sharing process with the key holding apparatus”) or step S504 (a “mutual authentication+key sharing process with the key allotter”).
In detail, for instance, if the key holding apparatus 22 does not keep the key holding apparatus PKI information of
On the other hand, for instance, when the key holding apparatus 22 keeps the key holding apparatus PKI information of
Note that step S522 (the “mutual authentication+key sharing process with the key holding apparatus”) and step S504 (the “mutual authentication+key sharing process with the key allotter”) by mutual authentication utilizing SSL, TLS will be described later with reference to
Thereafter, each of the key holding apparatus 22 and the key allotter terminal 12 executes step S523 (a “key holding apparatus user authentication process”) or step S505 (a “user authentication response process”).
Note that step S523 (the “key holding apparatus user authentication process”) and step S505 (the “user authentication response process”) are supposed to be similar to those of the above-mentioned second embodiment, and thus that descriptions thereof will be omitted.
By the way, as mentioned above, in the second embodiment, when the “key holding apparatus user authentication process (step S23 (
By contrast, in the fifth embodiment, as shown in
Note that of such mutual processes (key allotment processes) by the key allotter terminal 12 and the key holding apparatus 22, the process on the key allotter terminal 12 side (step S524 in the example of
Details of these “new key request and reception process (step S524)” and “new key generation and reception process (step S506)” are shown in an arrow chart of
Referring thus to the arrow chart of
As shown in
When the key allotter terminal 12 sends the linked data “GENERATE-KEY”∥MAC (“GENERATE-KEY”) in step S524-2, the user apparatus 11 (key holding apparatus 22) receives it in step S506-1.
The key holding apparatus 22 verifies the message authentication code in step S506-2, to verify the tampering and validity of the key generation request “GENERATE-KEY”.
When the verification is successful, the key holding apparatus 22 newly generates new keys, i.e., a public key pair (Kpr, Kpub) which is a pair of a private key and a public key for the public key cryptography in step S506-3. This public key pair (Kpr, Kpub) is used as a certifying key and a verifying key for an authentication technique to be newly allotted.
Specifically, for instance, when the key holding apparatus 22 is configured as shown in
And the computation processing section 56 generates the temporal holding key table of
Alternatively, for instance, when the key holding apparatus 22 is configured as shown in
And the computation processing section 56 writes IDn to an item for Index, private keys Kprn of the generated plurality of public key pairs (Kprn, Kpubn) to an item for certifying key (candidate), and public keys Kpubn of the generated plurality of public key pairs (kprn, Kpubn) to an item for verifying key (candidate) in the respective n records (rows) in the authenticating key table of
Note that in this case, all the cryptographic key candidates (certifying key (candidates) Kprn and verifying key (candidates) Kpubn) included in the authenticating key table of
With the authenticating key table of
When the verification is successful, the computation processing section 56 extracts a predetermined one (Kprk, Kpubk) (where k is a predetermined one of integer values represented by n) of the plurality of new key candidates, i.e., the plurality of public key pairs (Kprn, Kpubn) included in the respective records (rows) in the authenticating key table of
And the computation processing section 56 generates the temporal holding key table of
When the temporal holding key table of
Specifically, for instance, the key holding apparatus 22 generates a message authentication code MAC(Kpub) =E(Kses,h(Kpub) by using the verifying key Kpub of the public key pair (kpr, Kpub) generated in step S506-3 (held in the temporal holding key table of
The generated linked data Kpub∥MAC (Kpub) is sent from the user apparatus 11, and received by the key allotter terminal 12.
Then, the key allotter terminal 12 verifies the message authentication code MAC(Kpub)in the linked data Kpub˜MAC(Kpub)in step S524-4.
Returning to
At the same time, the key allotter terminal 12 adds to the key allotment table of
And the key allotter terminal 12 bills the user User (who owns the IC card 23) having the identification number AID in step S526.
When receiving the key allotment report of
Further, the key holding apparatus 22 adds to the authentication information table of
And the key holding apparatus 22 sends the key allotment report received in step S507 to the service provider terminal 13 in step S508.
At the same time, the key holding apparatus 22 deletes the certifying key Kpr and the verifying key Kpub held in the temporal holding key table of
The service provider terminal 13 receives the key allotment report in step S543. And the service terminator 13 verifies the key allotter's signature included in the key allotment report. When succeeding in the verification, the service provision terminal 13 adds to the authentication information table of
Referring next to
The SSL, TLS protocols are security technology capable of avoiding threat such as “eavesdropping”, “tampering” or “spoofing” over the Internet.
The SSL protocol is developed by NetScap Communications Corporation and is now widespread as a cryptographic communication protocol over the Internet. The TLS protocol is developed and its standardization is conducted by IETF, with RFC2246 being made open to the public.
The SSL, TLS protocols have features indicated in (a) to (d) below.
(a) Authentication of servers and certification of transmission by digital certificates (b) authentication of clients and certification of transmission by digital certificates (c) protection of secrecy of data by encryption (d) prevention of tampering of data by message authentication code (MAC).
As shown in
In this way, the SSL, TLS protocols are positioned immediately above the transport layer 413 for TCP, UDP and the like, and immediately below the application layer 415. That is, the SSL, TLS protocols use a function (socket) or the like provided by TCP, UDP, whereby to operate to provide data obtained therefrom with a security function, and deliver the result to an application. Thus, the SSL, TLS protocols have a feature that they can be utilized without dependence on applications. For instance, World Wide Web browsers and the like have that function incorporated as their standard function.
The layer 414 for SSL, TLS is, as shown in
The negotiation function is a function of executing some pre-processing such as checking that the other communicating party is an authentic party and checking cryptographic algorithms utilizable by both parties, prior to communication.
Referring now to an arrow chart of
That is,
First, when the user apparatus 11 (key holding apparatus 22) establishes an SSL connection, the key allotter terminal 12 sends a hello request message to the key holding apparatus in step S522-1.
When receiving the hello request message in step S504-1, the key holding apparatus 22 sends a client hello message to the key allotter terminal 12 in step S504-2.
Note that the client hello message is a message for notifying the key allotter terminal of information including an SSL version, a supporting cryptographic algorithm, a compression algorithm, and a time stamp.
When receiving the client hello message in step S522-2, the key allotter terminal 12 sends a server hello message to the key holding apparatus 22 in step S522-3.
The key holding apparatus 22 receives the server hello message in step S504-3.
Note that the server hello message is a message representing a response to the client hello message, and includes a cryptographic algorithm, a compression algorithm, and a session ID selected by the key allotter terminal 12.
Successively, the key allotter terminal 12 sends a server certificate message to which a certificate CERTKA in the key allotter PKI information of
When receiving the certificate CERTKA (server certificate message) in step S504-4, the key holding apparatus 22 verifies the certificate CERTKA, i.e., verifies the key allotter KA in step S504-5, to check whether or not it is the key allotter KA depending on whether or not the authentication is successful.
Note that when the key allotter terminal 12 does not hold the certificate and the like, a message such as server key exchange is sent from the key allotter terminal 12 in step S522-5, and received by the key holding apparatus 22 in step S504-6.
When the key allotter terminal 12 sends a message for requesting a certificate (such a message will also be called as a certificate request) in order to check the key holding apparatus 22 in step S522-6, the key holding apparatus 22 receives the message in step S504-7.
When the key allotter terminal 12 sends a server hello done message representing the end of a server's response in step S522-7, the key holding apparatus 22 receives the message in step S504-8.
The key holding apparatus 22 sends to the key allotter terminal 12 a server certificate message to which a certificate CERTHW0 included in the key holding apparatus PKI information of
The key allotter terminal 12 receives the certificate CERTHW0 (server certificate message) in step S522-8.
When the key holding apparatus 22 sends information from which a temporary cryptographic key Kssl for performing SSL cryptographic communication as a client key exchange message is derived, in step S504-10, the key allotter terminal 12 receives the message in step S522-9. That is, the key holding apparatus 22 and the key allotter terminal 12 share the information from which the temporary cryptographic key Kssl for performing SSL cryptographic communication is derived.
The key holding apparatus 22 sends a digital signature of the key holding apparatus 22 to the key allotter terminal 12 as a client verify message in step S504-11.
When receiving the client verify message in step S522-10, the key allotter terminal 12 performs verification of the certificate CERTHW0 received in step S522-8, i.e., performs verification of the key holding apparatus 22 in step S522-11, to check whether or not it is the key holding apparatus 22 depending on whether or not the verification is successful.
The key allotter terminal 12 generates a temporary cryptographic key Kssl (a session key Kssel to be shared with the key holding apparatus 22) for performing SSL cryptographic communication, based on the information corresponding to the Client key exchange message received in step S522-9 (information shared with the key holding apparatus 22), in step S522-12.
On the other hand, the key holding apparatus 22 also generates a temporary cryptographic key Kssl (a session key Kssel to be shared with the key allotter terminal 12) for performing SSL cryptographic communication, based on the information corresponding to the Client key exchange message sent instep S504-10 (information shared with the key allotter terminal 12), in step S504-12.
When the above processing is executed, each of the key allotter terminal 12 and the key holding apparatus 22 mutually sends and receives a finished message indicating the fact that the Handshake protocol ends, in a respective one of step S522-13 and step S504-13.
In this way, in SSL, each of the key allotter terminal 12 and the key holding apparatus 22 shares the temporary cryptographic key Kssl for SSL cryptographic communication at this point of time (at the end of step S522-13 and step S504-13).
Note that each of the messages described above is specified in RFC2246.
Furthermore, in the present invention, the key holding apparatus 22 generates a random number (temporary cryptographic key) Kses in step S504-14. The key holding apparatus 22 encrypts the generated cryptographic key (random number) Kses, by the cryptographic key Kssl (temporary cryptographic key Kssl for performing SSL cryptographic communication generated in step S504-12) shared with the key allotter terminal 12 through the SSL protocol. That is, the key holding apparatus 22 generates data E(Kssl, Kses). Further, the key holding apparatus 22 generates a message authentication code MAC(E(Kssl, Kses))=E(Kssl, E(Kssl, Kses)). The key holding apparatus 22 links data E(Kssl, Kses) with the message authentication code MAC(E(Kssl, Kses)). That is, the key holding apparatus 22 generates linked data E(Kssl, Kses)∥MAC(E(Kssl, Kses)) And the key holding apparatus 22 sends the linked data E(Kssl, Kses)∥MAC(E(Kssl, Kses)) to the key allotter terminal 12 in step S504-15.
Then, the key allotter terminal 12 receives the linked data E(Kssl, Kses)∥MAC(E(Kssl, Kses)) in step S522-14, and extracts the verifying random number Kses in the message authentication code MAC(E(Kssl, Kses)) (the temporary cryptographic key Kses generated by the key holding apparatus 22 in step S504-15). That is, the key allotter terminal 12 verifies the message authentication code MAC(E(Kssl, Kses)), and decrypts the verifying random number Kses for sharing with the key holding apparatus 22.
Note that the “mutual authentication+key sharing process with the key holding apparatus” and the “mutual authentication+key sharing process with the key allotter terminal” utilizing SSL, TLS shown in
Returning to
The key use/service provision process“in the fifth embodiment is similar to that of the second embodiment. That is, also in the fifth embodiment, the “key use/service provision process” is executed according to the above-mentioned flowcharts of
After step S2 (the “key use/service provision process”) ends, step S6 (a “key deletion process”) and step S7 (a “key use termination process”) are executed, as necessary.
The “key deletion process” (step S6) in the fifth embodiment is similar to that of the above-mentioned second embodiment. That is, also in the fifth embodiment, the “key deletion process” is executed according to any of the above-mentioned flowcharts of FIGS. 37 to 39.
Provided that, in the fifth embodiment, objects for deletion are supposed to be the key allotment table of
The “key use termination process” (step S7) in the fifth embodiment is similar to that of the above-mentioned second embodiment. That is, also in the fifth embodiment, the “key use termination process” is executed according to the above-mentioned flowcharts of
In this way, the authentication key allotment system 201 to which the fifth embodiment is applied is an embodiment correspond into the second embodiment, and thus, the advantages mentioned in (1) to (6) above can, of course, be provided.
Furthermore, the authentication key allotment system 201 to which the fifth embodiment is applied can provide the advantages shown in (7) to (10) below.
(7) An apparatus possessed by a user generates cryptographic keys (a public key pair) for an authentication technique when an exclusive authentication technique is allotted between two parties who require authentication, whereby there would be substantially no likelihood that a private key will be leaked out, and hence security can be improved.
(8) An apparatus possessed by the user generates cryptographic keys (a public key pair) for an authentication technique when an exclusive authentication technique is allotted between two parties who require authentication, whereby burden on the part of the key allotter can be reduced.
(9) Cryptographic keys for authentication are generated beforehand, whereby delay in processing key generation at the time of key allotment can be prevented.
(10) Should a private key be leaked, the location of the leakage source can be limited to the key holding apparatus possessed by the user.
As mentioned above, the sixth embodiment is an embodiment corresponding to the fourth embodiment, and a configuration of an authentication key allotment system to which the sixth embodiment of the present invention is applied is similar to the configuration of
By the way, in the fourth embodiment, the cryptographic keys for a new authentication technique are generated by the key allotter terminal 12, but in the sixth embodiment, the cryptographic keys for a new authentication technique are generated by the key holding apparatus 22 of the user apparatus 11.
Therefore, in the sixth embodiment, the key holding apparatus 22 further needs to have a function of generating cryptographic keys for a new authentication technique, similarly to the fifth embodiment.
That is, also in the sixth embodiment, similarly to the second and fifth embodiments, a public key pair (Kpr, Kpub) which is a pair of a private key and a public key for the public key cryptography is used as the cryptographic keys for a new authentication technique. Therefore, the key holding apparatus 22 needs to further have a function of newly generating a public key pair (Kpr, Kpub) from a random number by, for instance, an appropriate method (methods are not particularly limited; a standard method is defined, for instance, in IEEE-P1363, and that method can be applied.)
Such a function is easily implementable also by the key holding apparatus 22 having the above-mentioned configuration of
Note that also in the sixth embodiment, hardware can generate random numbers. In this case, the key holding apparatus 22 is designed to have the above-mentioned configuration shown in, for instance,
Each of the other apparatuses in the sixth embodiment, i.e., the user terminal 21, the IC card 23, the key allotter terminal 12, the service provider terminal 13, the general-purpose account manager terminal 15, and the authentication center terminal 211 has a basically similar function and configuration to a respective one of the corresponding apparatuses of the fourth embodiment. Therefore, descriptions of the other apparatuses will be omitted.
Further, each of the apparatuses constituting the authentication key allotment system to which the sixth embodiment is applied has data basically similar to the data held by a respective one of the corresponding apparatuses of the fourth embodiment, but differ therefrom slightly.
Thus, the data held by each of the apparatuses constituting the authentication key allotment system to which the fifth embodiment is applied will be described below.
That is, the key allotter terminal 12 keeps, also in the sixth embodiment, a service provider key table such as shown in
Provided that, in the sixth embodiment, a certifying key is generated by the key holding apparatus 22 kept by the user User, and thus the key allotter terminal 12 keeps a key allotment table such as shown in
Note that in the key allotment table of
That is, also in the sixth embodiment, for instance, the above-mentioned document of title shown in
The service provider terminal 13 keeps, also in the sixth embodiment, service provider unique information shown in
Further, the service provider terminal 13 generates the key allotment application of
The key holding apparatus 22 or the IC card 23 (user User) keeps, also in the sixth embodiment, a certifying key table such as shown in
Furthermore, also in the sixth embodiment, the key holding apparatus 22 keeps the above-mentioned key holding apparatus PKI information such as shown in
Further, in the sixth embodiment, the key holding apparatus 22 generates cryptographic keys (a certifying key and a verifying key to be paired therewith) by itself, and thus keeps the above-mentioned temporal holding key table shown in
That is, also in the sixth embodiment, the key holding apparatus 22 generates the temporal holding key table of
Furthermore, also in the sixth embodiment, the key holding apparatus 22 also keeps an authenticating key table such as shown in
That is, the key holding apparatus 22 holds beforehand the authenticating key table of
And the key holding apparatus 22 generates and holds (keeps) the temporal holding key table of
The account manager terminal 15 keeps, also in the sixth embodiment, the above-mentioned account management table of
The authentication center terminal 211 keeps, also in the sixth embodiment, CA key information such as shown in
Further, the authentication center terminal 211 (authentication center CA) issues a certificate such as shown in
Next, an operation of the authentication key allotment system 301 (
An outline of the operation of the authentication key allotment system 301 in the sixth embodiment is basically similar to that of the fourth embodiment of the present invention.
Therefore, the operation of the authentication key allotment system 301 to which the sixth embodiment of the present invention is applied will also be described with reference to the flowchart of
First, a “service selection/key allotment process” is executed in step S1.
The “service selection/key allotment process” in the sixth embodiment is supposed to be basically similar to that of the fourth embodiment, but differs therefrom slightly.
Details of such “service selection/key allotment process” in the sixth embodiment are shown in flowcharts of FIGS. 131 to 133 and an arrow chart of
Thus, referring to the arrow chart of
As shown in
The service provider terminal 13 receives the selected service in step S641, and generates the key allotment application of
The key holding apparatus 22 receives the key allotment application and holds it temporarily in step S602, and at the same time, sends it to the key allotter terminal 12 in step S603.
When receiving the key allotment application, the key allotter terminal 12 verifies a message authentication code of the service provider terminal 13 in the key allotment application in step S621.
When the key allotter terminal 12 receives the key allotment application, each of the key holding apparatus 22 and the key allotter terminal 12 executes step S622 (a “mutual authentication+key sharing process with the key holding apparatus” on the key allotter terminal 12 side) or step S604 (a “mutual authentication+key sharing process with the key allotter” on the key holding apparatus 22 side).
In detail, for instance, if the key holding apparatus 22 does not keep the key holding apparatus PKI information of
On the other hand, for instance, if the key holding apparatus 22 keeps the key holding apparatus PKI information of
And each of the key holding apparatus 22 and the key allotter terminal 12 executes step S623 (a “key holding apparatus user authentication process” on the key allotter terminal 12 side) or step S605 (a “user authentication response process” on the key holding apparatus 22 side).
Note that step S623 (the “key holding apparatus user authentication process”) and step S605 (the “user authentication response process”) in the sixth embodiment are supposed to be similar to those in the above-mentioned fourth embodiment, and thus that descriptions thereof will be omitted.
By the way, in the fourth embodiment, when the “key holding apparatus user authentication process (step S423 (FIG. 117) corresponding to step S623 (
By contrast, in the sixth embodiment, as shown in
Details of the “new key request and reception process (step S624)” and the “new key generation and reception process (step S606)” in the sixth embodiment are shown in an arrow chart of
Referring thus to the arrow chart of
As shown in
When the key allotter terminal 12 sends the linked data “GENERATE-KEY”∥MAC(“GENERATE-KEY”) in step S624-2, the user apparatus 11 (key holding apparatus 22) receives it in step S606-1.
And the key holding apparatus 22 verifies the message authentication code in step S606-2, to verify the tampering and validity of the key generation request “GENERATE-KEY”.
When the verification is successful, the key holding apparatus 22 newly generates new keys, i.e., a public key pair (Kpr, Kpub) which is a pair of a private key and a public key for the public key cryptography in step S506-3. This public key pair (Kpr, Kpub) is used as a certifying key and a verifying key for an authentication technique to be newly allotted.
Specifically, for instance, if the key holding apparatus 22 is configured as shown in
And the computation processing section 56 generates the temporal holding key table of
Alternatively, for instance, if the key holding apparatus 22 is configured as shown in
And the computation processing section 56 writes IDn to an item for Index, private keys Kprn of the generated plurality of public key pairs (Kprn, Kpubn) to an item for certifying key, and public keys Kpubn of the generated plurality of public key pairs (kprn, Kpubn) to an item for verifying key in the respective n records (rows) in the authenticating key table shown in
Note that in the current case, all the cryptographic key candidates (certifying key (candidates) Kprn and verifying key (candidates) Kpubn) included in the authenticating key table of
With the authenticating key table of
When the verification is successful, the computation processing section 56 extracts a predetermined one (Kprnk, Kpubk) (where k is a predetermined one of integer values represented by n) of the plurality of new key candidates, i.e., the plurality of public key pairs (Kprn, Kpubn) included in the respective records (rows) in the authenticating key table of
And the computation processing section 56 generates the temporal holding key table of
When the temporal holding key table of
Specifically, for instance, the key holding apparatus 22 generates a message authentication code MAC (Kpub) =E(Kses, h(Kpub)) by using the verifying key Kpub of the public key pair (Kpr, Kpub) generated in step S606-3 (held in the temporal holding key table of
The generated linked data Kpub∥MAC (Kpub) is sent from the user apparatus 11, and received by the key allotter terminal 12.
Then, the key allotter terminal 12 verifies the message authentication code MAC(Kpub) of the linked data Kpub∥MAC(Kpub) in step S624-4.
Returning to
At the same time, the key allotter terminal 12 adds to the key allotment table of
And the key allotter terminal 12 bills the user User (user terminal 21) identified in the “mutual authentication +key sharing process with the key holding apparatus” in step S622 so as to correspond with the content of the service in the document of title and the total of commissions for the key allotment, in step S626.
The key holding apparatus 22 receives the document of title in step S607.
And the key holding apparatus 22, after checking that the digital signature is generated by the key allotter terminal 12 (key allotter KA), on the received document of title, adds a new record configured of the identification number KID included in the document of title and the document of title Rcert to the authentication information table of
Further, the key holding apparatus 22 adds to the certifying key table of
Thereafter, the key holding apparatus 22 deletes the certifying key Kpr and the verifying key Kpub held in the temporal holding key table of
Returning to
The key use/service provision process” of the sixth embodiment is similar to that of the fourth embodiment. That is, also in the sixth embodiment, the “key use/service provision process” is executed according to the above-mentioned flowcharts of
After step S2 (the “key use/service provision process“) ends, step S6 (a “key deletion process”) and step S7 (a “key use termination process”) are executed, as necessary.
The “key deletion process” (step S6) of the sixth embodiment is similar to that of the above-mentioned fourth embodiment (i.e., that of the second embodiment). That is, also in the sixth embodiment, the “key deletion process” is executed according to any of the above-mentioned flowcharts of FIGS. 37 to 39.
Provided that, in the sixth embodiment, objects for deletion are supposed to be the key allotment table of
The “key use termination process” (step S7) of the sixth embodiment is similar to that of the above-mentioned fourth embodiment. That is, also in the fifth embodiment, the “key use termination process” is executed according to the above-mentioned flowcharts of
Provided that, in the “key use termination process” in the sixth embodiment, similarly to the fourth embodiment, the service provider terminal 13 does not hold a table corresponding to the authentication information table of
Further, the format of a key use termination request generated by the key allotter terminal 12 and sent to the service provider terminal 13 in step S161 of
In this way, the authentication key allotment system 301 to which the sixth embodiment is applied is an embodiment corresponding to the fourth embodiment, and thus, the advantages mentioned in (1) to (6) above can, of course, be provided.
Furthermore, the authentication key allotment system 301 to which the sixth embodiment is applied causes the key holding apparatus 22 kept by the user User to generate new keys similarly to that of the fifth embodiment, and thus it can, of course, provide the advantages shown in (7) to (10) above.
Further, an embodiment which corresponds to the first and third embodiments, and in which the key holding apparatus 22 held by the user User generates new keys is also easily implemental, similarly to the fifth and sixth embodiments.
That is, a technique by which the key holding apparatus 22 kept by the user User generates new keys can be applied further to the first and third embodiments, similarly to the fifth and sixth embodiments.
Note that a program for executing the above-mentioned series of processes is installed from a network and a recording medium. This recording medium is constituted by not only a program-recorded removable recording medium (package media) 41, 91, 111, 131, or 231, such as a magnetic disk (including a floppy disk), an optical disk (including a CD-ROM (Compact Disk-Read Only Memory), and a DVD (Digital Versatile Disk)), a magneto-optical disk (including a MD (Mini-Disk)), or a semiconductor memory, which is distributed in order to provide programs to owners and the like, separately from the main body of the apparatus as shown in
Note that in the present specification, the steps of executing the above-mentioned series or processes include not only processes performed time-serially in the written order, but also processes executed in parallel or individually, even through they are not necessarily processed time-serially.
Further, in the present specification, a system represents the entire part of an apparatus constituted by a plurality of apparatuses and processing sections.
Industrial Applicability
As in the foregoing, according to the present invention, the service provider can authenticate the user. Further, according to the present invention, when the service provider authenticates the user, the efficiency and security of its authentication can be enhanced.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2002-149925 | May 2002 | JP | national |
| 2003-69304 | Mar 2003 | JP | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/JP03/05605 | 5/2/2003 | WO |
