US20020108042A1 - Public key certificate issuing system, Public key certificate issuing method, digital certification apparatus, and program storage medium - Google Patents

Public key certificate issuing system, Public key certificate issuing method, digital certification apparatus, and program storage medium Download PDF

Info

Publication number
US20020108042A1
US20020108042A1 US10/041,964 US4196402A US2002108042A1 US 20020108042 A1 US20020108042 A1 US 20020108042A1 US 4196402 A US4196402 A US 4196402A US 2002108042 A1 US2002108042 A1 US 2002108042A1
Authority
US
United States
Prior art keywords
signature
public key
certificate
key certificate
authority
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/041,964
Other languages
English (en)
Inventor
Makoto Oka
Yoshihito Ishibashi
Shinako Mastuyama
Hideaki Watanabe
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Assigned to SONY CORPORATION reassignment SONY CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: OKA, MAKOTO, ISHIBASHI, YOSHIHITO, MATSUYAMA, SHINAKO, WATANABE, HIDEAKI
Publication of US20020108042A1 publication Critical patent/US20020108042A1/en
Priority to US12/659,289 priority Critical patent/US8214637B2/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Definitions

  • the present invention relates to a public key certificate issuing system, a public key certificate issuing method, a digital certification apparatus, and a program storage medium for processing the issuance of a public key certificate proving the validity of a public key used by an electronic delivery system in transmitting encrypted data. More particularly, the invention relates to a public key certificate issuing system, a public key certificate issuing method, a digital certification apparatus, and a program storage medium for use by a certificate authority (CA) that issues a public key certificate compatible with a plurality of signature algorithms, whereby entities utilizing such public key certificates are afforded enhanced convenience.
  • CA certificate authority
  • Encrypted data are decrypted to plain text data by use of a predetermined procedure.
  • Various methods for encrypting and decrypting information using an encryption key and a decryption key respectively have been known.
  • One of the diverse methods of data encryption and decryption based on encryption and decryption keys is so-called public key cryptosystem.
  • This system involves a transmitting party having one key and a receiving party possessing another key, one of the keys being used as a public key for use by indefinite users, the other key being kept private.
  • a data encryption key may be used as a public key and a decryption key as a private key.
  • an authentication code generation key may be used as a private key and an authentication code decryption key as a public key.
  • the public key cryptosystem is advantageous in terms of key management in that the private key need only be possessed by one particular person. Because of its lower data processing speed than the common key cryptosystem, the public key cryptosystem is more often utilized in applications involving limited amounts of data such as delivery of private keys and digital signatures.
  • a representative example of the public key cryptosystem is RSA (Rivest-Shamir-Adleman) cryptosystem. The system uses a product of two very large prime numbers (e.g., of 150 digits each), taking advantage of the difficulty in factorizing the product of two large prime numbers into prime factors (and in obtaining the discrete logarithm of the product).
  • ECC elliptic curve cryptography
  • the public key cryptosystem is structured to offer public keys for use by an indefinite number of people. As such, the system most often utilizes what is known as a public key certificate proving that a distributed public key is valid. For example, suppose that a user A generates a key pair consisting of a public key and a private key and sends the generated public key to a certificate authority. In turn, the certificate authority sends back a public key certificate to the user A. The user A then discloses the public key certificate thus obtained to the public. An indefinite number of users go through a predetermined procedure to acquire the public key from the public key certificate, encrypt documents or other desired data using the acquired public key, and transmit what is encrypted to the user A.
  • the user A decrypts the encrypted documents or data received using the previously generated private key.
  • the user A also attaches signatures to the documents using the private key.
  • the indefinite number of users go through the predetermined procedure to obtain the public key from the public key certificate and have the attached signatures verified.
  • the public key certificate is a certificate issued by a certificate authority (CA; also called an issuing authority or IA) on public key cryptosystem.
  • CA certificate authority
  • IA issuing authority
  • a typical public key certificate shown in FIG. 1 includes: a certificate version number; a serial number allocated to a certificate user by a certificate authority (CA); algorithm and parameters used for signature by the RSA, ECDSA, etc.; a certificate authority name; the period of certificate validity; the certificate user's name (user ID); the user's public key; and a digital signature.
  • CA certificate authority
  • the digital signature is generated to attest the whole range of certified items: certificate version number, certificate authority serial number, signature algorithm and parameters, certificate authority name, certificate validity, user ID, and user's public key.
  • a hash value is generated using hash function, and the certificate authority's private key is applied to the hash value to generate the signature.
  • the certificate authority issues public key certificates such as the one shown in FIG. 1, updates expired public key certificates; and creates, manages and distributes a certificate revocation list that repudiates unscrupulous users.
  • the certificate authority also generates public and private keys as needed.
  • a user When utilizing a public key certificate, a user gets a digital signature on his public key certificate verified using a certificate authority's public key in his possession. After the successful verification of the digital signature, the user utilizes the public key by extracting it from the public key certificate. It follows that all users employing public key certificates must have a common public key of the certificate authority.
  • a data transmission system may include a public key cryptosystem like the above-described scheme using public key certificates issued by the certificate authority.
  • the system allows each user to have the digital signature of his public key certificate verified and to extract the public key from the public key certificate after the successful signature verification. The user is then allowed to carry out a certification process based on the public key cryptosystem or to encrypt or decrypt outgoing or incoming data using the cryptosystem.
  • the problem is that end entities such as user devices performing various processes based on the public key cryptosystem are rarely compatible with all of such diverse encryption algorithms as the ECDSA, RSA and others. In most cases, each entity is capable of dealing with only one algorithm (ECDSA algorithm or RSA algorithm in particular).
  • Such devices each compatible with only a specific encryption algorithm can only be used with public key certificates based on that algorithm alone. Public key certificates signed by use of any other algorithm cannot be verified upon receipt.
  • HSM hardware security modules
  • an ECDSA end entity (device) 23 requests an ECDSA registration authority (ECDSA-RA) 22 (performing a signature process based on the ECDSA algorithm) to issue or update a public key certificate.
  • the ECDSA registration authority 22 certifies entities or devices taking part in various services, receives public key certificate issuance requests from these entities or devices, and forwards the requests to an ECDSA certificate authority (ECDSA-CA) 21 that performs a signature process based on the ECDSA algorithm.
  • the ECDSA certificate authority 21 issues public key certificates based on the signature process using the ECDSA algorithm, and distributes the certificates to the ECDSA end entities 23 via the ECDSA registration authority 22 .
  • an RSA end entity (device) 33 requests an RSA registration authority (RSA-RA) 32 (performing a signature process by use of the RSA algorithm) to issue or update a public key certificate.
  • the RSA registration authority 32 certifies entities or devices participating in diverse services, receives public key certificate issuance requests from these entities or devices, and forwards the requests to an RSA certificate authority (RSA-CA) 31 that performs a signature process based on the RSA algorithm.
  • RSA-CA RSA certificate authority
  • the RSA certificate authority 31 issues public key certificates based on the signature process using the RSA algorithm, and distributes the certificates to the RSA end entities 33 via the RSA registration authority 32 .
  • Each processing block constitutes a closed system wherein a public key cryptosystem specific to that block alone is used to effect certification and transmit encrypted data.
  • the ECDSA end entity 23 is incapable of verifying a public key certificate received from the RSA device 33 with a signature in RSA algorithm.
  • the received public key certificate will not serve as a certificate as long as its validity is not established.
  • the RSA end entity 33 cannot verify a public key certificate received from the ECDSA end entity 23 with a signature in ECDSA algorithm; the validity of the public key certificate remains uncertain following its receipt.
  • the ECDSA end entity 23 and RSA end entity 33 in FIG. 2 were to verify the validity of a public key certificate coming from the other party, each party must resort to a circuitous validation procedure: the received public key certificates are first transmitted respectively to the ECDSA registration authority 22 and RSA registration authority 32 , and forwarded from there to the ECDSA certificate authority 21 and RSA certificate authority 31 . The ECDSA certificate authority 21 and RSA certificate authority 31 then exchange queries about the respective certificates. The results of the queries are sent back finally to the respective end entities for certification purposes.
  • a public key certificate issuing system including: a certificate authority for issuing a public key certificate used by an entity; and a registration authority which, on receiving a public key certificate issuance request from any one of entities under jurisdiction thereof, transmits the received request to the certificate authority; wherein the certificate authority, having a plurality of signature modules each executing a different signature algorithm, selects at least one of the plurality of signature modules in accordance with the public key certificate issuance request from the registration authority, and causes the selected signature module to attach a digital signature to message data constituting a public key certificate.
  • the certificate authority may have a plurality of signature modules and a certificate authority server for outputting a signature processing request to the plurality of signature modules;
  • the certificate authority server may receive the public key certificate issuance request from the registration authority, select at least one of the plurality of signature modules in response to the public key certificate issuance request, and output the signature processing request to the selected signature module; and each of the plurality of signature modules may attach a digital signature to the message data constituting the public key certificate in response to the signature processing request received from the certificate authority server.
  • the certificate authority may have a registration authority management database which stores registration authority management data for associating registration authorities issuing public key certificate issuance requests with a signature algorithm specific to each of the registration authorities; and given a public key certificate issuance request from any registration authority, the certificate authority may select the signature module associated with the relevant signature algorithm based on the registration authority management data.
  • the registration authority management data may include key length and parameter information applicable to signatures.
  • the registration authority management data may include signature module identification information applicable to signatures.
  • the registration authority may transmit signature algorithm designation information along with the public key certificate issuance request to the certificate authority; and the certificate authority, based on the signature algorithm designation information received along with the public key certificate issuance request, may select a signature module applicable to the designated signature algorithm.
  • the signature algorithm designation information may include key length and parameter information applicable to signatures.
  • the certificate authority may have a verification key database which stores keys for signature verification in association with each of the plurality of signature modules; and the certificate authority may verify signatures generated by each of the plurality of signature modules.
  • the certificate authority may use at least two of the plurality of signature modules to attach at least two different digital signatures to one public key certificate.
  • the certificate authority may select at least two of the plurality of signature modules in order to have signature processing executed in steps by each of the selected signature modules used in concert for digital signature generation.
  • the certificate authority and the registration authority may each have a signature module structure management table which associates signature algorithm identifiers with identifiers of the plurality of signature modules; the registration authority may issue to the certificate authority a public key certificate issuance request designating a signature algorithm identifier in accordance with the signature module structure management table; and the certificate authority, upon receipt of the signature algorithm identifier from the registration authority, may select the signature module applicable to the received identifier from the signature module structure management table.
  • At least part of the plurality of signature modules may have a common signature key stored therein.
  • a plurality of signature algorithms may be executed by each of the plurality of signature modules.
  • a public key certificate issuing method for use with a certificate authority for issuing a public key certificate used by an entity, and with a registration authority which, on receiving a public key certificate issuance request from any one of entities under jurisdiction thereof, transmits the received request to the certificate authority, the method comprising the steps of: causing the certificate authority selects, from among a plurality of signature modules each executing a different signature algorithm, at least one of the signature modules in accordance with the public key certificate issuance request from the registration authority; and causing the selected signature module to attach a digital signature to message data constituting a public key certificate.
  • the public key certificate issuing method may further comprise the steps of: causing a certificate authority server to receive a public key certificate issuance request from the registration authority; causing the certificate authority server to select at least one of the plurality of signature modules in response to the public key certificate issuance request; and causing the certificate authority server to output a signature processing request to the selected signature module.
  • the step involving the certificate authority server selecting the signature module may include selecting the signature module based on a registration authority management database which stores registration authority management data for associating registration authorities issuing public key certificate issuance requests with a signature algorithm specific to each of the registration authorities.
  • the step involving the certificate authority server selecting the signature module may include selecting the signature module based on signature algorithm designation information received along with the public key certificate issuance request.
  • the public key certificate issuing method may further include the step of causing the certificate authority to verify signatures generated by each of the plurality of signature modules.
  • the public key certificate issuing method may further include the step of causing the certificate authority to use at least two of the plurality of signature modules to attach at least two different digital signatures to one public key certificate.
  • the public key certificate issuing method may further include the step of causing the certificate authority to select at least two of the plurality of signature modules in order to have signature processing executed in steps by each of the selected signature modules used in concert for digital signature generation.
  • the certificate authority and the registration authority may each have a signature module structure management table which associates signature algorithm identifiers with identifiers of the plurality of signature modules
  • the public key certificate issuing method may further comprise the steps of: causing the registration authority to issue to the certificate authority a public key certificate issuance request designating a signature algorithm identifier in accordance with the signature module structure management table; and causing the certificate authority, upon receipt of the signature algorithm identifier from the registration authority, to select the signature module applicable to the received identifier from the signature module structure management table.
  • the public key certificate issuing method may further comprise the step of having a plurality of signature algorithms executed by each of the plurality of signature modules.
  • a digital certification apparatus for constituting a certificate authority which issues a public key certificate used by an entity: wherein the digital certification apparatus, having a plurality of signature modules each executing a different signature algorithm, selects at least one of the plurality of signature modules in accordance with a public key certificate issuance request received from outside, and causes the selected signature module to attach a digital signature to message data constituting a public key certificate.
  • the digital certification apparatus may further comprise a plurality of signature modules and a certificate authority server for outputting a signature processing request to the plurality of signature modules; wherein the certification authority may receive the public key certificate issuance request, select at least one of the plurality of signature modules in response to the public key certificate issuance request, and output the signature processing request to the selected signature module; and wherein each of the plurality of signature modules may attach a digital signature to the message data constituting the public key certificate in response to the signature processing request received from the certificate authority server.
  • the digital certification apparatus may further comprise a registration authority management database which stores registration authority management data for associating registration authorities issuing public key certificate issuance requests with a signature algorithm specific to each of the registration authorities; wherein, given a public key certificate issuance request from any registration authority, the digital certification apparatus may select the signature module associated with the relevant signature algorithm based on the registration authority management data.
  • the registration authority management data may include key length and parameter information applicable to signatures.
  • the registration authority management data may include signature module identification information applicable to signatures.
  • the digital certification apparatus may, based on signature algorithm designation information received along with the public key certificate issuance request, select a signature module applicable to the designated signature algorithm.
  • the signature algorithm designation information may include key length and parameter information applicable to signatures.
  • the digital certification apparatus may further comprise a verification key database which stores keys for signature verification in association with each of the plurality of signature modules; wherein the digital certification apparatus may verify signatures generated by each of the plurality of signature modules.
  • the digital certification apparatus may use at least two of the plurality of signature modules to attach at least two different digital signatures to one public key certificate.
  • the digital certification apparatus may select at least two of the plurality of signature modules in order to have signature processing executed in steps by each of the selected signature modules used in concert for digital signature generation.
  • the digital certification apparatus may further comprise a signature module structure management table which associates signature algorithm identifiers with identifiers of the plurality of signature modules; wherein the digital certification apparatus may, upon receipt of a signature algorithm identifier along with the public key certificate issuance request, select the signature module applicable to the received identifier from the signature module structure management table.
  • At least part of the plurality of signature modules may have a common signature key stored therein.
  • a plurality of signature algorithms may be executed by each of the plurality of signature modules.
  • a program storage medium which stores a computer program executed by a computer system in carrying out public key certificate issuance processing to issue a public key certificate for use by an entity, the computer program comprising the steps of: selecting, from among a plurality of signature modules each executing a different signature algorithm, at least one of the signature modules in accordance with a public key certificate issuance request; and causing the selected signature module to attach a digital signature to message data constituting a public key certificate.
  • the program storage medium according to the fourth aspect of the invention is a medium that offers a computer program in computer-readable format for use on a general-purpose computer capable of executing diverse program codes.
  • the medium may be any one of such storage media as CDs (compact discs), FDs (floppy discs) and MOs (magneto-optical discs); or of transmission media such as networks, and others.
  • the above type of program storage medium retains definitions of structural or functional relations of cooperation between the medium carrying the computer program on the one hand, and the computer program for implementing necessary computer program functions on the computer system on the other hand. That is, once the computer program is installed into the computer system by means of the program-carrying medium, the computer system performs cooperative operations based on the program providing the same effects as those of the other aspects of the present invention.
  • FIG. 1 is a schematic view of a typical public key certificate
  • FIG. 2 is a schematic view outlining a conventional public key certificate issuing system
  • FIG. 3 is a schematic view outlining a public key certificate issuing system according to this invention.
  • FIG. 4 is a tabular view detailing a data structure of a public key certificate
  • FIG. 5 is another tabular view detailing the data structure of the public key certificate
  • FIG. 6 is a flowchart of steps constituting an ECDSA signature generation process
  • FIG. 7 is a flowchart of steps constituting an ECDSA signature verification process
  • FIG. 8 is a flowchart of steps carried out to generate keys necessary for RSA signature processing
  • FIG. 9A is a flowchart of steps constituting an RSA signature generation process
  • FIG. 9B is a flowchart of steps constituting an RSA signature verification process
  • FIG. 10 is a block diagram showing a typical structure of a certificate authority (CA) server
  • FIG. 11 is a tabular view depicting a typical structure of a registration authority (RA) management database owned by the certificate authority server;
  • RA registration authority
  • FIG. 12 is a tabular view indicating a typical structure of a verification key database owned by the certificate authority server;
  • FIG. 13 is a block diagram illustrating a typical HSM (hardware security module) structure including a signature module;
  • FIG. 14 is a schematic view of a setup where the same signature key is shared by a plurality of signature modules
  • FIG. 15 is a flowchart of steps constituting the process of having the same signature key shared by a plurality of signature modules
  • FIG. 16 is another flowchart of steps constituting the process of having the same signature key shared by a plurality of signature modules
  • FIG. 17 is yet another flowchart of steps constituting the process of having the same signature key shared by a plurality of signature modules;
  • FIG. 18 is a flowchart of steps constituting the process of storing a signature key into a signature module
  • FIG. 19 is a flowchart of steps constituting a signature process performed by a signature module using a signature key
  • FIG. 20 is a flowchart of steps constituting a signature module determining process performed by a signature module during signature process execution;
  • FIG. 21 is a schematic view with subfigures for explaining a typical signature process performed by signature modules (as example 1);
  • FIG. 22 is a schematic view with subfigures for explaining another typical signature process performed by signature modules (as example 2);
  • FIG. 23 is a schematic view with subfigures for explaining another typical signature process performed by signature modules (as example 3);
  • FIG. 24 is a schematic view with subfigures for explaining another typical signature process performed by signature modules (as example 4);
  • FIG. 25 is a schematic view of a typical setup for privately managing a signature module structure.
  • FIG. 26 is a schematic view of the process of getting a plurality of signature modules to perform signature processes in cooperation.
  • a certificate authority is an organ that creates and issues public key certificates.
  • a registration authority is an organ that performs registration work for issuing public key certificates.
  • the registration authority is requested to issue a public key certificate by a user, a service provider, a server or other party (called an end entity, to be defined later) desirous of utilizing a public key certificate.
  • the registration authority sends a public key certificate issuance request to the certificate authority.
  • the certificate authority issues a public key certificate to the registration authority which then forwards the certificate to the requesting party.
  • a hardware security module is a piece of dedicated hardware for retaining a signature key and attaching it to a certificate.
  • An end entity is a subject to which a public key certificate is issued.
  • the end entity may be a device, a server, a user, a service provider, or any other entity utilizing the certificate.
  • CA certificate authority
  • One of the challenges in establishing the certificate authority is how to store private keys securely in a system based on a public key cryptosystem while ensuring security in providing signatures.
  • Another challenge is how to improve the computing speed of signature provision, which is conducive to boosting system performance of the certificate authority.
  • the inventive system comprises a certificate authority (CA) capable of accommodating a plurality of different signature algorithms, key lengths and parameters. More specifically, the certificate authority is structured to include a plurality of signature modules implemented either by dedicated hardware (HSM) or by software executing different signature algorithms.
  • CA certificate authority
  • HSM dedicated hardware
  • FIG. 3 is a schematic view showing how a certificate authority acting as a digital certification apparatus (CA) comprising a plurality of signature modules typically operates.
  • a CA server 71 in a certificate authority 70 receives via registration authorities (RA) 81 through 85 a public key certificate issuance request sent from any one of various end entities (EE) such as servers, users and service providers wishing to utilize a public key certificate.
  • EE end entities
  • the registration authorities 81 through 85 each have a specific signature algorithm such as Rivest-Shamir-Adleman (RSA) cryptosystem or elliptic curve cryptography (ECC) ready to be applied to a public key certificate that may be issued for use by end entities (EE) under jurisdiction of the registration authority in question.
  • RSA Rivest-Shamir-Adleman
  • ECC elliptic curve cryptography
  • One or more algorithms are selectively designated in a public key certificate issuance request bound for the certificate authority 70 .
  • the request with a specific signature algorithm designated therein requires having a signature executed in the specified algorithm.
  • one of the registration authorities (RA) 81 through 85 forwards the request to the certificate authority 70 , calling on the latter to issue a public key certificate with the signature in the specified encryption algorithm.
  • the public key certificate thus issued is sent to and subsequently verified by the end entity in question.
  • the applicable signature algorithm varies from one registration authority to another.
  • Public key certificate issuance requests from registration authorities are accepted by the CA server 71 in the certificate authority (CA) 70 .
  • the CA server 71 selects some of signature modules 72 a through 72 n in accordance with a table that associates each of the registration authorities (RA) 81 through 85 owned by the CA server 71 with a specific signature algorithm.
  • the CA server 71 generates public key certificates and sends them to the selected modules along with a signature execution instruction each.
  • the signature modules in question Upon receipt of the public key certificates along with the signature execution instruction, the signature modules in question carry out their respective signature processes using the applicable signature algorithms (e.g., RSA, ECDSA).
  • the signed public key certificates are returned to the CA server 71 .
  • the CA server 71 on receiving the signed public key certificates from the modules involved, forwards the certificates to the requesting registration authorities (RA) 81 through 85 .
  • RA requesting registration authorities
  • Each of the signature modules 72 a through 72 n either receives externally or generates internally a certificate authority signature key in accordance with a particular signature algorithm for signature execution.
  • the signature modules 72 a through 72 n each comprise a hardware security module (HSM), i.e., a dedicated piece of hardware for signature execution; or a dedicated processor or CPU for carrying out a signature by use of a program capable of executing the applicable signature algorithm. Tamper-resistant, the signature modules 72 a through 72 n use signature keys to sign messages based on the components of a public key certificate generated by the CA server 71 .
  • HSM hardware security module
  • the HSM constituting a processing unit comprising a signature module may be replaced either by a dedicated processor for executing a signature using a program capable of executing the relevant signature algorithm, or by a CPU-equipped module carrying out a software-based signature process.
  • Typical signature processes performed by the signature modules 72 a through 72 n include Rivest-Shamir-Adleman (RSA) cryptosystem and elliptic curve digital signature algorithm (ECDSA). With each cryptosystem, different key lengths entail different computing speeds and afford different levels of security. The most-often utilized key lengths are 512 bits, 1,024 bits or 2,048 bits for the RSA cryptosystem; and 160 bits, 192 bits or 224 bits for the ECDSA.
  • RSA Rivest-Shamir-Adleman
  • EDSA elliptic curve digital signature algorithm
  • F(p)(p is a prime number or 2 to an n-th power) characteristic “p,” orders “r, “a” and “b”; and by a base point (Gx, Gy) on the curve.
  • a public key certificate is issued by a third party called a certificate authority (CA) attesting to the validity of a public key for use by two parties for cross-certification in exchanging data or encryption data therebetween.
  • CA certificate authority
  • a typical format of the public key certificate adopted by the inventive system is described below in detail by referring to FIGS. 4 and 5.
  • the format example shown in FIGS. 4 and 5 is based on the public key certificate format X.509, V3.
  • a “version” field indicates the version of the certificate format in use.
  • a “serial number” field accommodates a serial number attached to a public key certificate by the certificate authority (CA).
  • a “signature algorithm identifier—algorithm, parameters” field records a signature algorithm and algorithm parameters used in the public key certificate in question.
  • the signature algorithm is typically elliptic curve cryptography (ECC), RSA, or others. If the ECC is in effect, parameters and a key length are recorded; if the RSA is in use, then a key length is recorded. If any other cryptosystem is adopted, the identifier of that cryptosystem is recorded in this field.
  • An “issuer” field records as a distinguished name the name of a public key certificate issuer, i.e., of the certificate authority (CA) in effect.
  • CA certificate authority
  • a “validity—not before, not after” field accommodates a starting date and time (Not Before) as well as an ending date and time (Not After).
  • a “subject” field records the name of a subject, i.e., of a user who utilizes the certificate. Specifically, the subject may be represented by the ID of a user device or of a service offering entity.
  • a “subject public key information-algorithm, subject public key” field contains a key algorithm as the user's public key information, and key information itself.
  • An “authority key identifier—key identifier, authority certificate issuer, authority certificate serial number” field contains information for identifying a certificate authority (CA) key.
  • a key identifier (octal number), the name of the certificate authority, and a certificate serial number are recorded in this field.
  • a “subject key identifier” field accommodates identifiers for identifying a plurality of keys for use in a public key certificate.
  • a “key usage” field designates the purpose of key usage selected from among the following: (0) for digital signature, (1) for repudiation prevention, (2) for key encryption, (3) for message encryption, (4) for distribution of a common key, (5) for verification of a certificate signature, or (6) for verification of a signature on a certificate revocation list.
  • a “private key usage period—not before, not after” field records the usage period of a private key owned by the user.
  • a “certificate policies” field records certificate issuance policies applicable to the certificate authority (CA) and registration authority (RA) in question. For example, IDs of certification policies based on the ISO/IEC 9384-1 are recorded in this field.
  • a “policy mappings—issuer domain policy, subject domain policy” field is used only when the certificate authority needs to be certified.
  • the field records mappings regarding the policy of the certificate authority as a certificate issuer, and the policy of the subject.
  • a “supported algorithms—algorithm identifier, intended usage, intended certificate policies” field defines attributes of a directory (X.500). Where the opposite party of communication is to use directory information, definitions in this field inform that party of the directory attributes in advance.
  • “subject alternative name” field records an alternative name of the user.
  • An “issuer alternative name” field records an alternative name of the certificate issuer.
  • a “subject directory attributes” field accommodates any attributes of the user.
  • a “basic constraints—CA, path length constraint” field is used to specify whether the public key subject to certification is to be used for signature by the certificate authority (CA) or by the user.
  • a “name constraints—permitted subtrees, base, minimum, maximum, excluded subtrees” field indicates effective domains of a certificate used only when the subject is the certificate authority.
  • a “policy constraints—require explicit policy, inhibit policy mapping” field describes constraints requiring explicit policy IDs and inhibit policy mapping for the remaining certification paths.
  • a “CRL (certificate revocation list) distribution points” field describes points at which the user, upon utilizing a certificate, references a certificate revocation list (CRL) to see whether the certificate is revoked.
  • a “signature” field contains the signature of the certificate authority (CA).
  • the above signature attached to a public key certificate is a digital signature executed onto data constituting the certificate through the use of a private key issued by a public key certificate issuer (certificate authority or CA).
  • a public key issued by the certificate authority the user of a public key certificate is able to check whether the certificate has been tampered with.
  • ECDSA elliptic curve digital signature algorithm
  • step S 1 it is assumed that “p” represents a characteristic; that “a” and “b” denote coefficients of an elliptic curve ( 4 a 3 + 27 b 2 ⁇ 0 (mod p)); and that “G” stands for a base point on the elliptic curve, “r” for the order of “G,” and “Ks” for a private key (0 ⁇ Ks ⁇ r).
  • a message is input to the hash function for compression into data of a predetermined bit length.
  • the compressed result is output as a hash value.
  • the hash function has a number of distinct characteristics: it is difficult to predict an input from a given hash value (output); a change of a single bit in the input data to the hash function leads to changes of numerous bits in the resulting hash value; and it is also difficult to find different input data having the same hash value.
  • the hash function most frequently used is MD 4 , MD 5 , or SHA- 1 ; it may also be DES-CBC.
  • the final output value MAC (check value, equivalent to ICV) makes up the hash value.
  • step S 3 a random number “u” (0 ⁇ u ⁇ r) is generated.
  • step S 4 a coordinate “V” (Xv, Yv) is calculated using the base point multiplied by “u.”
  • An addition and a diploid operation on the elliptic curve are defined as follows:
  • step S 6 If in step S 6 the value “c” turns out to be 0, then step S 3 is reached again in which another random number is generated. Likewise if the value “d” is found to be 0 in step S 8 , step S 3 is reached again and a new random number is generated.
  • step S 12 a check is made to see if the digital signature data “c” and “d” satisfy the conditions of 0 ⁇ c ⁇ r and 0 ⁇ d ⁇ r.
  • step S 17 a check is made to see if the point P is an infinite point. If the point P is not an infinite point, step S 18 is reached. In fact, whether the point P is an infinite point is determined in step S 16 .
  • step S 18 a calculation is made of “Xp mod r” for comparison with the digital signature data “c.” If there is a match between the compared values, step S 19 is reached in which the digital signature is judged valid.
  • step S 12 If in step S 12 the digital signature data “c” or “d” fail to satisfy the condition 0 ⁇ c ⁇ r or 0 ⁇ d ⁇ r, then step S 20 is reached. If in step S 17 the point P turns out to be an infinite point, step S 20 is also reached. A mismatch in step S 18 between the value “Xp mod r” and the digital signature data “c” also leads to step S 20 .
  • step S 20 the digital signature is judged invalid. That means the data have been tampered with or that the party in possession of the private key corresponding to the public keys has not generated the electronic signature.
  • FIG. 8 is a flowchart of steps for generating public and private keys used for signature generation and verification based on RSA cryptosystem.
  • FIG. 9A is a flowchart of steps constituting an RSA signature generation process
  • FIG. 9B is a flowchart of steps constituting an RSA signature verification process.
  • prime numbers “p” and “q” are first selected (of about 150 digits each) in step S 21 .
  • step S 24 a positive integer “e” less than “n” and not sharing a common factor with the value “L” is selected to let (n, e) be public keys.
  • FIGS. 9A and 9B Signature generation and verification using the above public and private keys are conducted as shown in FIGS. 9A and 9B.
  • each public key certificate determines its validity. As described above, verification of the signature requires executing encryption processing based on a signature algorithm.
  • the signature algorithm of interest must be executable by any device acting as an end entity.
  • a common signature algorithm is employed by end entities under control of each registration authority (RA).
  • the organ called the certificate authority (CA) issuing public key certificates takes the form of a digital certification apparatus which, possessing a plurality of signature modules as described, is capable of executing diverse signature algorithms including RSA and ECDSA. Structured to accommodate multiple, different signature algorithm and parameters, the certificate authority (CA) selects signature modules as requested by registration authorities (RA) and causes the selected modules to generate signatures based on the respective cryptosystems such as RSA cryptosystem and ECDSA signature algorithm before issuing a public key certificate containing the generated signatures.
  • RA registration authorities
  • a public key certificate issuance request is accepted by the CA server 71 of the certificate authority (CA).
  • Relevant modules 72 a through 72 n are selected as per the table that associates the registration authorities 81 through 85 under control of the CA server 71 with the assigned signature algorithms.
  • the selected signature modules are sent a public key certificate each along with a signature execution instruction.
  • each selected signature module Upon receipt of the public key certificate and signature execution instruction, each selected signature module generates a signature based on the applicable signature algorithm (e.g., RSA, ECC) and returns the signed public key certificate to the CA server 71 .
  • the CA server 71 transmits the signed public key certificate to the registration authority (one of RAs 81 through 85 ) that originated the public key certificate issuance request.
  • the certificate authority has a CA server 100 and a plurality of signature modules 150 executing as many signature algorithms.
  • the CA server 100 transmits a public key certificate including the above-described structure data (see FIGS. 4 and 5) to any of the signature modules (HSM) 150 .
  • the signature module 150 that received the public key certificate generates a signature and returns the signed public key certificate to the CA server 100 through the HSM interface 114 .
  • a PCI bus or a network such as the Ethernet may connect the CA server 100 with the signature modules 150 . All communication paths between the server and the modules are established as secure paths.
  • the CA server 100 includes three databases: an RA management database 121 that manages information about registration authorities (RA) under control of the CA server, a verification key database 122 that stores keys for verifying public key certificates, and a repository database 123 that accommodates issued public key certificates, a list of public key certificates, and public key certificate revocation list information. These databases are accessed via a database interface (DB-I/F) 116 .
  • RA management database 121 that manages information about registration authorities (RA) under control of the CA server
  • a verification key database 122 that stores keys for verifying public key certificates
  • a repository database 123 that accommodates issued public key certificates, a list of public key certificates, and public key certificate revocation list information.
  • the CA server 100 performs cross-certification with the registration authorities (RA) 181 through 183 to verify their identities before receiving a public key certificate issuance request from any of them via a network interface 115 .
  • the CA server 100 Given the issuance request from any registration authority, the CA server 100 generates a public key certificate containing the data items explained above and determines a signature algorithm or algorithms based on relevant information in the RA management database 121 or on the request itself. Thereafter, the CA server 100 selects the signature module 150 -x to execute the determined signature algorithm, and transmits to the selected module the generated public key certificate through the HSM interface 114 .
  • Data for signature generation such as a key length and parameters may also be sent along with the public key certificate if necessary.
  • the signature module 150 -x On receiving the public key certificate, the signature module 150 -x generates a signature based on its executable signature algorithm such as RSA or ECDSA and returns a signed public key certificate to the CA server 100 .
  • the CA server 100 retrieves an applicable verification key from the verification key database 122 to determine whether the certificate is correctly signed. After registration with the repository database 123 , the CA server 100 transmits the signed public key certificate to the registration authority (RA) that issued the request.
  • RA registration authority
  • a CPU 111 controls the above series of steps while a RAM 112 and a ROM 113 offer a storage area for accommodating processing program necessary for performing these processes and a work area in which the programs are carried out.
  • a display unit 117 and an input unit 118 are used by an operator entering and viewing data and commands.
  • FIG. 11 is a tabular view depicting a typical structure of the RA (registration authority) management database 121 .
  • This database contains a table that associates RA-specific signature algorithms with the registration authorities (RA) from which the certificate authority (CA) accepts public key issuance requests.
  • a registration authority identified as RA0001 is shown using the RSA cryptosystem as its signature algorithm with a key length of 1,024 bits. It is also shown that the RSA cryptosystem is executed by a signature module HSM-001.
  • RA0002 Another registration authority identified as RA0002 is shown using the RSA cryptosystem as its signature algorithm with a key length of 2,048 bits. It is indicated that the RSA cryptosystem is executed by a load-distributed setup that employs three modules HSM-002, HSM-003 and HSM-004 in combination.
  • a registration authority identified as RA0003 utilizes both RSA and ECC as its signature algorithms.
  • a circle in a “multiple-signature algorithm” column indicates that the registration authority in question permits execution of a plurality of signature algorithms.
  • the multiple-signature algorithm is implemented in one of two ways.
  • a registration authority may request the certificate authority (CA) to selectively execute, say, either an ECC signature or an RSA signature, and the certificate authority may comply with the request.
  • the certificate authority may furnish a single public key certificate with a plurality of signatures executed by as many signature algorithms.
  • the signature algorithm in use is the elliptic curve digital signature algorithm (ECDSA)
  • EDSA elliptic curve digital signature algorithm
  • the table contains elliptic curve parameters to be adopted in addition to the applicable key length.
  • a signature module for executing a signature is fixedly associated with key length data and a parameter, then the signature is executed by use of the key length and parameter assigned to the signature module in question. If a signature module is capable of executing signatures based on a plurality of key lengths or parameters, then the CA server retrieves the applicable key lengths or the relevant key lengths and parameters from the RA management database and transmits what is retrieved to the module in question so that the latter will execute signatures according to the key lengths or the key lengths and parameters received from the CA server.
  • FIG. 12 is a tabular view indicating a typical structure of the verification key database.
  • This database associates signature module identifiers identifying the signature modules for executing signatures, with keys for verifying the signatures executed by these modules.
  • the database contains HSM-IDs as signature module identifiers, names of signature algorithms executed by the associated modules, key lengths to be used, parameters, and verification keys, all listed in mutually associated relation.
  • the verification keys are public keys that correspond to the private keys generated by the signature modules as their signature keys.
  • the CA server receives the generated private keys from the signature modules and stores what is received into the verification key database.
  • the CA server retrieves the corresponding verification key (public key) from the verification key database 122 and verifies that the signature is valid before sending the certificate to the registration authority (RA) that originated the certificate issuance request.
  • RA registration authority
  • HSM hardware security module
  • Each HSM has a signature module that executes a specific signature algorithm. Designed to be tamper-resistant, the HSM has its stored information such as private key information for signature generation erased if tampered with.
  • the HSM 150 comprises: a communication interface 152 for exchanging data with a CA server; a CPU 151 for controlling processing within the HSM; a signature module 160 for executing a particular signature algorithm such as RSA or ECDSA; a nonvolatile memory 153 that stores various HSM-specific data such as an HSM identifier (ID); a ROM 154 that records processing programs for identifying signature algorithms and performing analyses in obtaining key lengths, parameter information and others from signature request data from the CA server; and a RAM 155 that accommodates variable settings such as private keys, signature algorithm identification information, key lengths, and parameter information either generated by the signature module or received from outside.
  • a communication interface 152 for exchanging data with a CA server
  • a CPU 151 for controlling processing within the HSM
  • a signature module 160 for executing a particular signature algorithm such as RSA or ECDSA
  • a nonvolatile memory 153 that stores various HSM-specific data such as an HSM identifier (ID)
  • a ROM 154
  • the signature module 160 includes a random number generation unit 161 , a signature generation unit 162 , and a hash calculation unit 163 .
  • the signature module carries out the steps constituting the process flow described above with reference to FIG. 6; if the RSA signature algorithm is to be performed, the signature module performs the steps making up the process flow explained above by referring to FIGS. 9A and 9B.
  • each signature module executes a signature based on a specific signature algorithm such as RSA or ECDSA.
  • a private key for signature execution by each signature module may be either generated internally by the module in question or acquired from a particular, external signature module that has generated its own key. Where a plurality of signature modules are to store a common key, an externally generated key may effectively be sent to the modules involved for storage therein.
  • Reading and writing of signature keys should preferably be subject to strict security rules to prevent leaks.
  • all operators should be certified using passwords or like means based on dedicated software, and any signature module to which to write a key should be ascertained by checking its ID number.
  • FIG. 14 is a schematic view of a setup where a signature key is generated by a signature module 1 and transmitted to a plurality of other signature modules 2 through n.
  • Dedicated software shown in FIG. 14 refers illustratively to a program held in a ROM of the CA server.
  • an operator may issue a key generation instruction to one particular signature module and causes a key (private key) generated by the module to be transmitted to the other multiple signature modules (HSMs).
  • HSMs multiple signature modules
  • a verification key (public key) corresponding to the generated private key is written to the verification key database in the CA server in association with each of the HSM identifiers involved.
  • a password-based certification process or other suitable steps should preferably be carried out between the transmitting and receiving parties to forestall illegal data transfers. Only when the parties involved are certified should the generated signature key and other related data or commands be allowed to be transmitted.
  • FIG. 15 is a flowchart of steps constituting a typical process performed by the CA server using dedicated software. This process involves having a key generation instruction issued to a specific signature module (signature module 1 ) to get a signature key generated by the module 1 before transmitting the key to other signature modules.
  • signature module 1 a specific signature module
  • step S 101 The operator who would perform steps to generate and store a signature key is first authenticated in step S 101 . Only a previously registered operator is authorized to carry out the signature key generation process. A check is made in step S 102 to see whether the submitted password, fingerprint data, etc., attest to the valid operator. If the operator is judged valid, step S 103 is reached in which a key generation-transmission instruction is issued to the signature module 1 (HSM 1 ) requesting the latter to generate the signature key.
  • HSM 1 signature module 1
  • step S 104 cross-certification is carried out between the signature module 1 (HSM 1 ) on the one hand, and the apparatus that has issued the key generation-transmission instruction (e.g., CA server) on the other hand.
  • the cross-certification is executed based on common key cryptosystem or public key cryptosystem. Keys for such certification are retained in advance by the devices involved.
  • the CA server waits for a signature key and a verification key to arrive from the signature module.
  • the verification key is stored into the verification key database in step S 107 .
  • step S 108 a signature key store instruction is output to another signature module (HSM) that will utilize the same signature key.
  • HSM signature module
  • step S 109 cross-certification is performed with the new signature module.
  • An acknowledgment received from the signature module in step S 111 indicates that the key has been normally stored inside, thus signaling the end of the key write operation to the current signature module.
  • Steps S 108 through S 111 are repeated on all signature modules to which the signature key is to be written. When the key is judged written to all signature modules involved in step S 112 , the process is terminated.
  • step S 121 the signature module 1 receives a key generation-transmission instruction.
  • step S 122 cross-certification is carried out between the signature module 1 and dedicated software (embodied by the CA server).
  • step S 123 the signature module 1 generates a key pair consisting of a signature key and a verification key in step S 124 .
  • step S 125 the signature key is retained by the device itself in step S 126 .
  • the generated signature key and verification key are further transmitted to the dedicated software (CA server) in step S 127 .
  • the transmission is judged successful in step S 128 , the process is terminated.
  • step S 131 the signature modules 2 through N receive a signature key store instruction each.
  • step S 132 cross-certification is carried out between the signature modules 2 through N on the one hand and the dedicated software (CA server) on the other hand.
  • CA server dedicated software
  • step S 133 the signature key is stored into each of the signature modules involved in step S 134 .
  • step S 135 a storage complete notice is transmitted to the dedicated software (CA server) in step S 136 .
  • step S 137 the transmission of the notice is judged successful in step S 137 , the process is terminated.
  • Processing by the CA server will now be described in two categories: (1) processing performed upon key generation by a signature module (HSM), and (2) processing carried out upon issuance of a public key certificate and upon signature execution.
  • HSM signature module
  • FIG. 18 The process by the CA server upon key generation by the signature module (HSM) is described below by referring to FIG. 18.
  • the process shown to the left is that which is performed by the CA server, while the process indicated to the right is carried out by an HSM having a signature module.
  • cross-certification steps are not shown in FIG. 18, these steps are still carried out between the CA server and the signature module in the same manner as FIG. 16 and 17 if they are interconnected in an externally accessible manner.
  • step S 201 the CA server issues a key generation instruction to the HSM.
  • the key generation instruction may include a key length and a parameter if necessary. It is possible to issue a plurality of key generation instructions based on different key lengths and different parameters.
  • the HSM On receiving the instruction in step S 211 , the HSM generates at least one key pair consisting of a signature key and a verification key in step S 212 .
  • the verification key is transmitted to the CA server in step S 214 .
  • the signature key is retained by the device itself in step S 215 .
  • the CA server Upon receipt of the verification key from the HSM in step S 202 , the CA server stores the received key into the verification key database in step S 203 . Where necessary, the RA management database and the repository database are updated in step S 204 .
  • the verification key database and other databases accommodate key lengths, parameters and other data with regard to each data entry.
  • step S 231 of FIG. 19 the CA server generates certificate data (see FIGS. 4 and 5) in response to a certificate issuance request from a registration authority.
  • step S 232 the CA server determines HSMs that should perform signature execution.
  • step S 251 of FIG. 20 the CA server receives a certificate issuance request from a registration authority (RA). Based on the identifier of the requesting registration authority, the CA server searches through the RA management database (see FIG. 11) in step S 252 . A check is first made to see if the requesting registration authority is subject to load distribution on the basis of the applicable load distribution entry in the RA management database. If the registration authority in question is judged subject to load distribution, step S 258 is reached. In step S 258 , a plurality of HSMs are selected according to predetermined criteria for sequential or parallel use of the selected HSMs.
  • RA registration authority
  • step S 254 a check is made by referencing the RA management database (FIG. 11) to see whether the registration authority in question corresponds to multiple signature algorithms. If in step S 254 the registration authority is judged corresponding to multiple signature algorithms, step S 255 is reached. In step S 255 , a search is made through the RA management database for data entries corresponding to the requested signature algorithms in the public key certificate issuance request. If relevant data entries are found in step S 256 , HSM identifiers associated with the RA identifier are acquired from the database, and the HSMs having the obtained HSM identifiers are determined as the signature modules.
  • the CA server may alternatively select HSMs by making a search through the RA management database in accordance with the designated signature algorithms, key lengths and parameters.
  • step S 233 of FIG. 19 is reached in which the generated public key certificate data are transmitted to the selected HSMs.
  • the HSMs execute signatures in step S 242 and transmit a signed certificate to the CA server in step S 243 .
  • the CA server Upon receipt of the signed certificate from the HSMs in step S 234 , the CA server retrieves verification keys associated with the HSM identifiers from the verification key database in step S 235 . In step S 236 , the CA server verifies the signatures using the retrieved verification keys. If the verification is judged successful in step S 237 , the CA server transmits the signed certificate to the requesting registration authority (RA), which terminates the process.
  • RA requesting registration authority
  • FIG. 21 illustrates a typical configuration including an end entity (EE) 300 , registration authorities (RA) 311 and 312 , a certificate authority (CA) server 321 ; and HSMs 331 , 332 and 333 having a signature module each.
  • the end entity 300 issues a public key certificate issuance request to the CA server 321 through the registration authority 311 or 312 .
  • the RA management database of the CA server contains data such as those shown in subfigure (a) of FIG. 21 and that the verification key database accommodates data listed illustratively in subfigure (b) of FIG. 21.
  • the registration authority 311 identified as RA 1 allows a signature module HSM 1 to execute a signature based on the RSA signature algorithm with a key length of 1,024 bits.
  • the verification key database contains signature algorithms, key lengths, parameter information, and verification keys corresponding to the HSMs configured.
  • the end entity (EE) 300 sends a public key certificate issuance request to a given registration authority (RA).
  • RA registration authority
  • FIG. 22 shows an example in which the end entity (EE) 300 outputs a public key certificate issuance request to the registration authority (RA 1 ) 311 .
  • Numerals (1) through (10) in FIG. 22 represent steps to be taken by the parties involved. These steps are described below in ascending order.
  • the end entity (EE) 300 transmits to the registration authority (RA 1 ) 311 data including user data necessary for issuing a public key certificate in the form of a public key certificate issuance request.
  • the registration authority (RA 1 ) 311 verifies that what is received is a legitimate certificate issuance request from the end entity (EE) 300 , registers the recasting user, and carries out other related steps.
  • the registration authority 311 then transmits the certificate issuance request to the CA server 321 , along with a certificate issuance request command, necessary message data including certificate storage data, and a registration authority identifier (ID).
  • the CA server 321 Upon receipt of the certificate issuance request, the CA server 321 references the RA management database to determine an HSM for signature execution.
  • a module HSM 1 is selected as the signature execution module in accordance with the RA management database entries shown in subfigure (a) of FIG. 21.
  • the CA server 321 outputs a signature generation instruction to the signature module (HSM 1 ) 331 .
  • the instruction as shown in subfigure (b) of FIG. 22, contains a signature generation instruction command and message data for a certificate to be generated. If the module HSM 1 is capable of generating variable length keys, the signature generation instruction may include data for specifying a key length.
  • the module (HSM 1 ) 331 performs signature execution in keeping with the signature generation instruction.
  • the module executes its signature based on the RSA algorithm
  • the module (HSM 1 ) 331 transmits a signed public key certificate to the CA server 321 .
  • the CA server 321 retrieves a verification key from the verification key database to check whether the signature on the received public key certificate is valid.
  • the CA server 321 sends the signed public key certificate to the requesting registration authority (RA 1 ) 311 .
  • the registration authority (RA 1 ) 311 forwards the signed public key certificate received to the requesting end entity (EE) 300 .
  • FIG. 23 shows another example in which the end entity (EE) 300 outputs a public key certificate issuance request to the registration authority (RA 2 ) 312 .
  • Numerals (1) through (10) in FIG. 23 represent steps to be taken by the parties involved. These steps are described below in ascending order.
  • the end entity (EE) 300 transmits to the registration authority (RA 2 ) 312 data including user data necessary for issuing a public key certificate in the form of a public key certificate issuance request.
  • the registration authority (RA 2 ) 312 verifies that what is received is a legitimate certificate issuance request from the end entity (EE) 300 , registers the requesting user, and carries out other related steps.
  • the registration authority 312 then transmits the certificate issuance request to the CA server 321 , along with a certificate issuance request command, necessary message data including certificate storage data, a registration authority identifier (ID); and data specifying a signature algorithm, a key length and parameters, as shown in subfigure (a) of FIG. 23.
  • the CA server 321 Upon receipt of the certificate issuance request, the CA server 321 references the RA management database to determine an HSM for signature execution.
  • a module HSM 3 is selected as the signature execution module in accordance with the RA management database entries shown in subfigure (a) of FIG. 21.
  • the CA server 321 outputs a signature generation instruction to the signature module (HSM 3 ) 333 .
  • the instruction as shown in subfigure (b) of FIG. 23, contains a signature generation instruction command, message data for a certificate to be generated, and data designating the key length and parameters.
  • the module (HSM 3 ) 333 performs signature execution in accordance with the signature generation instruction.
  • the module executes its signature based on the ECDSA.
  • the module (HSM 3 ) 333 transmits a signed public key certificate to the CA server 321 .
  • the CA server 321 retrieves a verification key from the verification key database to check whether the signature on the received public key certificate is valid.
  • the CA server 321 sends the signed public key certificate to the requesting registration authority (RA 2 ) 312 .
  • the registration authority (RA 2 ) 312 forwards the signed public key certificate received to the requesting end entity (EE) 300 .
  • FIG. 24 shows yet another example in which the end entity (EE) 300 outputs a public key certificate issuance request to the registration authority (RA 2 ) 312 , soliciting simultaneous execution of a plurality of signatures.
  • Numerals (1) through (14) in FIG. 24 denote steps to be taken by the parties involved. These steps are described below in ascending order.
  • the end entity (EE) 300 transmits to the registration authority (RA 2 ) 312 data including user data necessary for issuing a public key certificate in the form of a public key certificate issuance request.
  • the registration authority (RA 2 ) 312 verifies that what is received is a legitimate certificate issuance request from the end entity (EE) 300 , registers the requesting user, and carries out other related steps.
  • the registration authority 312 then transmits the certificate issuance request to the CA server 321 , along with a certificate issuance request command, necessary message data including certificate storage data, a registration authority identifier (ID); and data specifying a plurality of signature algorithms, key lengths and parameters, as shown in subfigure (a) of FIG. 24.
  • the CA server 321 Upon receipt of the certificate issuance request, the CA server 321 references the RA management database to determine HSMs for signature execution.
  • modules HSM 2 and HSM 3 are selected as the signature execution modules in accordance with the RA management database entries shown in subfigure (a) of FIG. 21.
  • the CA server 321 outputs a signature generation instruction first to the signature module (HSM 2 ) 332 .
  • the instruction as shown in subfigure (b) of FIG. 24, contains a signature generation instruction command, message data for a certificate to be generated, and data designating a key length.
  • the module (HSM 2 ) 332 performs signature execution in accordance with the signature generation instruction.
  • the module executes its signature based on the ECDSA.
  • the module (HSM 2 ) 332 transmits a signed public key certificate to the CA server 321 .
  • the CA server 321 retrieves a verification key from the verification key database to check whether the signature on the received public key certificate is valid.
  • the CA server 321 then outputs the signature generation instruction to the signature module (HSM 3 ) 333 .
  • the instruction as shown in subfigure (c) of FIG. 24, contains a signature generation instruction command, message data for a certificate to be generated, and data designating the key length and parameters.
  • the module (HSM 3 ) 333 performs signature execution in accordance with the signature generation instruction. In this case, the module executes its signature based on the ECDSA.
  • the module (HSM 3 ) 333 After the signature execution, the module (HSM 3 ) 333 transmits a signed public key certificate to the CA server 321 .
  • the CA server 321 retrieves verification keys from the verification key database to check whether the signatures on the received public key certificate are valid.
  • the CA server 321 sends the signed public key certificate to the requesting registration authority (RA 2 ) 312 .
  • the registration authority (RA 2 ) 312 forwards the signed public key certificate received to the requesting end entity (EE) 300 .
  • FIG. 25 is a block diagram outlining the setup of this example. As shown in FIG. 25, the setup includes a certificate authority (CA) 401 and a registration authority (RA) 402 each having a signature module structure management table.
  • CA certificate authority
  • RA registration authority
  • the signature module structure management table associates signature algorithm identifiers (1 through n) with HSMs executing their respectively assigned signature algorithms.
  • This table is generated by the certificate authority (CA) 401 randomly associating the signature algorithm identifiers with the HSMs involved. The table is updated periodically or as needed.
  • the generated table is delivered to each registration authority (RA) 402 .
  • the registration authority (RA) 402 When requested to issue a public key certificate by an end entity, the registration authority (RA) 402 generates a certificate issuance request furnished with a signature algorithm identifier (any one of 1 through n) and sends the request to the certificate authority (CA) 401 .
  • the certificate authority (CA) 401 searches the signature module structure management table for an HSM based on the signature algorithm identifier contained in the certificate issuance request received. When the corresponding HSM is selected, the certificate authority (CA) 401 outputs a signature request to the HSM in question.
  • a leaked signature module structure management table does not result in any essential signature algorithm leaking out. This makes it possible effectively to prevent illegal signature generation by a third party. It is preferred that the signature module structure management table be made tamper-resistant by having it signed by the certificate authority.
  • RA registration authority
  • the process of ECC signature generation may be divided into such steps as hash value generation, random number generation, generation of a coordinate value V, etc., as described earlier with reference to FIG. 6. These steps are carried out individually by independent modules.
  • the result of processing by one module is forwarded to the next downstream module for another process.
  • the data transferred from one module to another are given an intermediate signature by each transmitting module; each receiving module adds another intermediate signature to the collection of the transferred data and intermediate signatures furnished so far.
  • the last-signed result is received by the CA server 501 from the module 60 n.
  • Signature generation thus involves the series of steps being carried out in a predetermined order by all modules involved.
  • HSM signature modules
  • the module HSM 1 ( 601 ) may execute an RSA signature
  • the module HSM 2 ( 602 ) may execute an ECDSA signature “a”
  • the module HSMx ( 60 x ) may carry out an ECDSA signature “x” using a different parameter.
  • the result of the execution of these multiple signatures is transmitted to the CA server 501 .
  • each transmitting module also executes an intermediate signature onto the message
  • each receiving module adds another intermediate signature to the collection of the transferred message data and intermediate signatures furnished so far.
  • the CA server 501 in this setup is required individually to manage verification keys regarding the different modules.
  • signatures are generated by a plurality of signature modules under control of the certificate authority (CA), the modules performing their respectively assigned signature generation processes while transferring a public key certificate made of signature-supplemented message data from one module to another in a predetermined order. Because signature generation based on any single signature module is impossible, the generation of an illegal signature by a third party taking advantage of data leaks from any module is made effectively unfeasible.
  • CA certificate authority
  • CA certificate authority
  • RA registration authority
  • CA certificate authority
  • the single certificate authority can issue public key certificates each bearing a signature of a different algorithm.
  • a certificate authority which has a plurality of signature modules each executing a different signature algorithm such as RSA or ECDSA and which allows some of the signature modules selectively to execute a plurality of signatures as requested by any registration authority (RA) under control of the certificate authority.
  • the certificate authority in this setup permits generation of a single public key certificate carrying a plurality of signatures based on different algorithms.
  • public key certificate issuing system public key certificate issuing method, digital certification apparatus, and program storage medium, it is possible to provide a plurality of signature modules each executing part of steps representing various signature algorithms such as RSA and ECDSA, the modules being suitably coordinated to execute an integral signature process made up of the steps. This arrangement also forestalls illegal signature generation by a third party utilizing a leak of data from an individual signature module.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
US10/041,964 2001-01-10 2002-01-09 Public key certificate issuing system, Public key certificate issuing method, digital certification apparatus, and program storage medium Abandoned US20020108042A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/659,289 US8214637B2 (en) 2001-01-10 2010-03-03 Public key certificate issuing system, public key certificate issuing method, digital certification apparatus, and program storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JPP2001-002220 2001-01-10
JP2001002220A JP2002207426A (ja) 2001-01-10 2001-01-10 公開鍵証明書発行システム、公開鍵証明書発行方法、および電子認証装置、並びにプログラム記憶媒体

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/659,289 Continuation US8214637B2 (en) 2001-01-10 2010-03-03 Public key certificate issuing system, public key certificate issuing method, digital certification apparatus, and program storage medium

Publications (1)

Publication Number Publication Date
US20020108042A1 true US20020108042A1 (en) 2002-08-08

Family

ID=18870765

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/041,964 Abandoned US20020108042A1 (en) 2001-01-10 2002-01-09 Public key certificate issuing system, Public key certificate issuing method, digital certification apparatus, and program storage medium
US12/659,289 Expired - Fee Related US8214637B2 (en) 2001-01-10 2010-03-03 Public key certificate issuing system, public key certificate issuing method, digital certification apparatus, and program storage medium

Family Applications After (1)

Application Number Title Priority Date Filing Date
US12/659,289 Expired - Fee Related US8214637B2 (en) 2001-01-10 2010-03-03 Public key certificate issuing system, public key certificate issuing method, digital certification apparatus, and program storage medium

Country Status (2)

Country Link
US (2) US20020108042A1 (ja)
JP (1) JP2002207426A (ja)

Cited By (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030065921A1 (en) * 2001-09-28 2003-04-03 Chang Kae-Por F. Authority-neutral certification for multiple-authority PKI environments
US20040073785A1 (en) * 2002-10-09 2004-04-15 Tuija Hurtta Controlling delivery of certificates in a mobile communication system
US20040117314A1 (en) * 2002-12-16 2004-06-17 Francotyp-Postalia Ag &Co., Kg Method and arrangement for variably generating cryptographic securities in a host device
US20040156506A1 (en) * 2003-02-10 2004-08-12 Mauricio Sanchez Selecting cached RSA keys in response to RSA key requests
WO2005043807A1 (en) * 2003-10-28 2005-05-12 Certicom Corp. Method and apparatus for verifiable generation of public keys
US20050138386A1 (en) * 2003-12-22 2005-06-23 Le Saint Eric F. Trusted and unsupervised digital certificate generation using a security token
US20050257058A1 (en) * 2003-04-01 2005-11-17 Junji Yoshida Communication apparatus and authentication apparatus
US20050289349A1 (en) * 2002-09-17 2005-12-29 Siemens Aktiengesellschaft Method for generating and/or validating electronic signatures
WO2006021665A1 (fr) * 2004-08-19 2006-03-02 France Telecom Procede d'attribution de certificat d'authentification et infrastructure d'attribution de certificat
US20060075246A1 (en) * 2004-10-05 2006-04-06 Canon Kabushiki Kaisha Signature-generation method, signature-verification method, public-key distribution method, and information-processing apparatus
US20070121934A1 (en) * 2003-12-26 2007-05-31 Yuichi Futa Prime calculation device,method,and key issuing system
US20080060055A1 (en) * 2006-08-29 2008-03-06 Netli, Inc. System and method for client-side authenticaton for secure internet communications
WO2008058377A1 (en) * 2006-11-13 2008-05-22 Certicom Corp. Compressed ecdsa signatures
WO2009009871A1 (en) 2007-07-17 2009-01-22 Certicom Corp. Method of providing text representation of a cryptographic value
US20090196418A1 (en) * 2008-02-04 2009-08-06 Freescale Semiconductor, Inc. Encryption Apparatus with Diverse Key Retention Schemes
US7599489B1 (en) * 2004-02-09 2009-10-06 Sun Microsystems Inc. Accelerating cryptographic hash computations
US20090300349A1 (en) * 2008-05-30 2009-12-03 Yoko Hashimoto Validation server, validation method, and program
US20100241852A1 (en) * 2009-03-20 2010-09-23 Rotem Sela Methods for Producing Products with Certificates and Keys
US20110145569A1 (en) * 2009-12-16 2011-06-16 Verisign, Inc. Method and system for provisioning multiple digital certificates
US20110145567A1 (en) * 2009-12-16 2011-06-16 Verisign, Inc. Method and system to combine multiple digital certificates using the subject alternative name extension
US20110154027A1 (en) * 2009-12-23 2011-06-23 Verisign, Inc. Method and system for co-termination of digital certificates
US20110161662A1 (en) * 2009-12-30 2011-06-30 Hong Fu Jin Precision Industry (Shenzhen) Co., Ltd System and method for updating digital certificate automatically
US20150095650A1 (en) * 2013-09-27 2015-04-02 Daniel Nemiroff Public key infrastructure for system-on-chip
US9055059B1 (en) 2009-12-16 2015-06-09 Symantec Corporation Combining multiple digital certificates
US20170257220A1 (en) * 2014-11-19 2017-09-07 Huawei Technologies Co., Ltd. Directional-traffic statistics method, device, and system
US20170324545A1 (en) * 2016-05-04 2017-11-09 International Business Machines Corporation Revocable pki signatures
WO2018027300A1 (en) 2016-08-08 2018-02-15 ISARA Corporation Using a digital certificate with multiple cryptosystems
US20180302400A1 (en) * 2017-04-18 2018-10-18 Servicenow, Inc. Authenticating access to an instance
WO2019079761A1 (en) * 2017-10-20 2019-04-25 Alibaba Group Holding Limited METHOD AND DEVICE FOR APPLYING A DIGITAL CERTIFICATE
US10305871B2 (en) * 2015-12-09 2019-05-28 Cloudflare, Inc. Dynamically serving digital certificates based on secure session properties
CN109992953A (zh) * 2019-02-18 2019-07-09 深圳壹账通智能科技有限公司 区块链上的数字证书签发、验证方法、设备、系统及介质
CN110011799A (zh) * 2019-04-02 2019-07-12 河南管软信息技术有限公司 移动办公中的通信安全方法
CN112352238A (zh) * 2018-06-28 2021-02-09 币即特株式会社 多重签名安全帐户控制系统
CN113228560A (zh) * 2018-10-23 2021-08-06 西门子股份公司 用于发行的发行设备和方法以及用于请求数字证书的请求设备和方法
CN113841360A (zh) * 2019-05-14 2021-12-24 大众汽车股份公司 蝴蝶密钥扩展方案的实现
US20220247731A1 (en) * 2019-03-25 2022-08-04 Micron Technology, Inc. Secure communication between an intermediary device and a network
US11443293B2 (en) * 2013-12-10 2022-09-13 China Unionpay Co., Ltd. Secure network accessing method for POS terminal, and system thereof
CN115442052A (zh) * 2022-08-30 2022-12-06 云海链控股股份有限公司 一种协同签名方法、系统、设备及计算机可读存储介质
TWI810957B (zh) * 2022-06-01 2023-08-01 倍穎資訊股份有限公司 一種遠端節點控制管理平台
US20230246819A1 (en) * 2022-02-01 2023-08-03 Juniper Networks, Inc. Public key infrastructure based session authentication
EP4440033A1 (en) 2023-03-31 2024-10-02 Sick Ag Authenticating data based on certificates

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7502945B2 (en) * 2002-06-28 2009-03-10 Microsoft Corporation Using a flexible rights template to obtain a signed rights label (SRL) for digital content in a rights management system
US7370212B2 (en) 2003-02-25 2008-05-06 Microsoft Corporation Issuing a publisher use license off-line in a digital rights management (DRM) system
FR2867001B1 (fr) * 2004-02-27 2006-06-16 Gemplus Card Int Procede de production d'un certificat numerique, certificat numerique associe, et procede d'utilisation d'un tel certificat numerique
JP2005303779A (ja) * 2004-04-14 2005-10-27 Nippon Telegr & Teleph Corp <Ntt> 証明書発行サービス方法、証明書発行サービス装置及び証明書発行サービスプログラム
JP2006108886A (ja) * 2004-10-01 2006-04-20 Sony Corp 情報処理装置および方法、記録媒体、並びにプログラム
US7487358B2 (en) * 2004-11-29 2009-02-03 Signacert, Inc. Method to control access between network endpoints based on trust scores calculated from information system component analysis
US8438645B2 (en) 2005-04-27 2013-05-07 Microsoft Corporation Secure clock with grace periods
US20060265758A1 (en) 2005-05-20 2006-11-23 Microsoft Corporation Extensible media rights
JP5053756B2 (ja) * 2007-08-09 2012-10-17 株式会社日立製作所 証明書検証サーバ、証明書検証方法、および証明書検証プログラム
US8468583B2 (en) * 2010-02-23 2013-06-18 Symantec Corporation Streamlined process for enrollment of multiple digital certificates
JP2011193416A (ja) * 2010-03-17 2011-09-29 Hitachi Ltd 証明書の有効性確認方法、検証サーバ、プログラム及び記憶媒体
JP5581863B2 (ja) * 2010-07-12 2014-09-03 株式会社リコー 画像形成装置、認証システム。画像形成装置の制御方法及び制御プログラム
US8756411B2 (en) * 2010-12-06 2014-06-17 Siemens Aktiengesellschaft Application layer security proxy for automation and control system networks
EA201200133A1 (ru) * 2012-02-16 2013-08-30 Андрей Юрьевич ЩЕРБАКОВ Способ выработки и хранения цифровых сертификатов и способ тиражирования программного обеспечения (варианты)
US9948695B2 (en) * 2012-03-16 2018-04-17 Alcatel Lucent Enabling delivery of protected content using unprotected delivery services
JP5346111B2 (ja) * 2012-07-24 2013-11-20 株式会社日立製作所 検証サーバ、プログラム及び検証方法
JP2017130845A (ja) * 2016-01-21 2017-07-27 株式会社オートネットワーク技術研究所 認証システム、認証要求装置、車載電子機器、コンピュータプログラム及び認証処理方法
US11323274B1 (en) * 2018-04-03 2022-05-03 Amazon Technologies, Inc. Certificate authority
US11888997B1 (en) * 2018-04-03 2024-01-30 Amazon Technologies, Inc. Certificate manager
US11563590B1 (en) 2018-04-03 2023-01-24 Amazon Technologies, Inc. Certificate generation method
US10909250B2 (en) * 2018-05-02 2021-02-02 Amazon Technologies, Inc. Key management and hardware security integration
KR20210065109A (ko) 2018-10-02 2021-06-03 캐피탈 원 서비시즈, 엘엘씨 비접촉식 카드의 암호화 인증을 위한 시스템 및 방법
CN111368339B (zh) * 2019-11-06 2020-12-01 胡金钱 电子签章载入方法和装置
TWI730549B (zh) * 2019-12-18 2021-06-11 臺灣網路認證股份有限公司 於憑證申請過程中確認金鑰對產生演算法之系統及方法
CN111565107B (zh) * 2020-07-14 2020-11-27 腾讯科技（深圳）有限公司 基于云服务平台的密钥处理方法、装置和计算机设备
JP7283614B1 (ja) 2022-05-18 2023-05-30 凸版印刷株式会社 認証局管理システム、認証局管理方法、およびプログラム

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5659616A (en) * 1994-07-19 1997-08-19 Certco, Llc Method for securely using digital signatures in a commercial cryptographic system
US6035402A (en) * 1996-12-20 2000-03-07 Gte Cybertrust Solutions Incorporated Virtual certificate authority
US6202157B1 (en) * 1997-12-08 2001-03-13 Entrust Technologies Limited Computer network security system and method having unilateral enforceable security policy provision
US6490680B1 (en) * 1997-12-04 2002-12-03 Tecsec Incorporated Access control and authorization system
US6675296B1 (en) * 1999-06-28 2004-01-06 Entrust Technologies Limited Information certificate format converter apparatus and method

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5958051A (en) * 1996-11-27 1999-09-28 Sun Microsystems, Inc. Implementing digital signatures for data streams and data archives
JP3874127B2 (ja) * 1997-04-10 2007-01-31 日本電信電話株式会社 認証システムにおける登録鍵重複防止装置
JPH10327147A (ja) * 1997-05-21 1998-12-08 Hitachi Ltd 電子認証公証方法およびシステム
US7404077B1 (en) * 1999-01-29 2008-07-22 International Business Machines Corporation Extension of X.509 certificates to simultaneously support multiple cryptographic algorithms
US7610614B1 (en) * 1999-02-17 2009-10-27 Certco, Inc. Cryptographic control and maintenance of organizational structure and functions
JP2002207427A (ja) * 2001-01-10 2002-07-26 Sony Corp 公開鍵証明書発行システム、公開鍵証明書発行方法、および情報処理装置、情報記録媒体、並びにプログラム記憶媒体

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5659616A (en) * 1994-07-19 1997-08-19 Certco, Llc Method for securely using digital signatures in a commercial cryptographic system
US6035402A (en) * 1996-12-20 2000-03-07 Gte Cybertrust Solutions Incorporated Virtual certificate authority
US6490680B1 (en) * 1997-12-04 2002-12-03 Tecsec Incorporated Access control and authorization system
US6202157B1 (en) * 1997-12-08 2001-03-13 Entrust Technologies Limited Computer network security system and method having unilateral enforceable security policy provision
US6675296B1 (en) * 1999-06-28 2004-01-06 Entrust Technologies Limited Information certificate format converter apparatus and method

Cited By (93)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8019990B2 (en) 2001-09-28 2011-09-13 Zoralco Fund Limited Liability Company Authority-neutral certification for multiple-authority PKI environments
US7328344B2 (en) * 2001-09-28 2008-02-05 Imagitas, Inc. Authority-neutral certification for multiple-authority PKI environments
US20030065921A1 (en) * 2001-09-28 2003-04-03 Chang Kae-Por F. Authority-neutral certification for multiple-authority PKI environments
US8621206B2 (en) 2001-09-28 2013-12-31 Zoralco Fund Limited Liability Company Authority-neutral certification for multiple-authority PKI environments
US20050289349A1 (en) * 2002-09-17 2005-12-29 Siemens Aktiengesellschaft Method for generating and/or validating electronic signatures
US20040073785A1 (en) * 2002-10-09 2004-04-15 Tuija Hurtta Controlling delivery of certificates in a mobile communication system
US7526642B2 (en) * 2002-10-09 2009-04-28 Nokia Corporation Controlling delivery of certificates in a mobile communication system
US7610247B2 (en) 2002-12-16 2009-10-27 Francotyp-Postalia Ag & Co. Kg Method and arrangement for variably generating cryptographic securities in a host device
DE10260406B4 (de) * 2002-12-16 2007-03-08 Francotyp-Postalia Gmbh Verfahren und Anordnung zur unterschiedlichen Erzeugung kryptographischer Sicherungen von Mitteilungen in einem Hostgerät
EP1432170A3 (de) * 2002-12-16 2005-05-18 Francotyp-Postalia AG &amp; Co. KG Verfahren und Anordnung zur unterschiedlichen Erzeugung kryptographischer Sicherungen von Mitteilungen in einem Hostgerät
EP1432170A2 (de) * 2002-12-16 2004-06-23 Francotyp-Postalia AG &amp; Co. KG Verfahren und Anordnung zur unterschiedlichen Erzeugung kryptographischer Sicherungen von Mitteilungen in einem Hostgerät
US20040117314A1 (en) * 2002-12-16 2004-06-17 Francotyp-Postalia Ag &Co., Kg Method and arrangement for variably generating cryptographic securities in a host device
US20040156506A1 (en) * 2003-02-10 2004-08-12 Mauricio Sanchez Selecting cached RSA keys in response to RSA key requests
US8290153B2 (en) 2003-02-10 2012-10-16 Hewlett-Packard Development Company, L.P. Managing a plurality of cached keys
US20090154695A1 (en) * 2003-02-10 2009-06-18 Mauricio Sanchez Managing a plurality of cached keys
US7483537B2 (en) * 2003-02-10 2009-01-27 Mauricio Sanchez Selecting cached RSA keys in response to RSA key requests
US20050257058A1 (en) * 2003-04-01 2005-11-17 Junji Yoshida Communication apparatus and authentication apparatus
US7721101B2 (en) * 2003-04-01 2010-05-18 Panasonic Corporation Communication apparatus and authentication apparatus
CN102868528A (zh) * 2003-10-28 2013-01-09 塞尔蒂卡姆公司 一种公开密钥的可验证生成的方法和设备
US8713321B2 (en) 2003-10-28 2014-04-29 Certicom Corp. Method and apparatus for verifiable generation of public keys
US9967239B2 (en) 2003-10-28 2018-05-08 Certicom Corp. Method and apparatus for verifiable generation of public keys
US9240884B2 (en) 2003-10-28 2016-01-19 Certicom Corp. Method and apparatus for verifiable generation of public keys
WO2005043807A1 (en) * 2003-10-28 2005-05-12 Certicom Corp. Method and apparatus for verifiable generation of public keys
US20050135606A1 (en) * 2003-10-28 2005-06-23 Brown Daniel R. Method and apparatus for verifiable generation of public keys
US9160530B2 (en) 2003-10-28 2015-10-13 Certicom Corp. Method and apparatus for verifiable generation of public keys
US20160294809A1 (en) * 2003-12-22 2016-10-06 Assa Abloy Ab Trusted and unsupervised digital certificate generation using a security token
US20050138386A1 (en) * 2003-12-22 2005-06-23 Le Saint Eric F. Trusted and unsupervised digital certificate generation using a security token
US10454675B2 (en) * 2003-12-22 2019-10-22 Assa Abloy Ab Trusted and unsupervised digital certificate generation using a security token
US9331990B2 (en) * 2003-12-22 2016-05-03 Assa Abloy Ab Trusted and unsupervised digital certificate generation using a security token
US9602497B2 (en) * 2003-12-22 2017-03-21 Assa Abloy Ab Trusted and unsupervised digital certificate generation using a security token
US7634084B2 (en) * 2003-12-26 2009-12-15 Panasonic Corporation Prime calculation device, method, and key issuing system
US20070121934A1 (en) * 2003-12-26 2007-05-31 Yuichi Futa Prime calculation device,method,and key issuing system
US7599489B1 (en) * 2004-02-09 2009-10-06 Sun Microsystems Inc. Accelerating cryptographic hash computations
WO2006021665A1 (fr) * 2004-08-19 2006-03-02 France Telecom Procede d'attribution de certificat d'authentification et infrastructure d'attribution de certificat
US20070283426A1 (en) * 2004-08-19 2007-12-06 France Telecom Method for Assigning an Authentication Certificate and Infrastructure for Assigning Said Certificate
US7685429B2 (en) * 2004-10-05 2010-03-23 Canon Kabushiki Kaisha Signature-generation method, signature-verification method, public-key distribution method, and information-processing apparatus
US20060075246A1 (en) * 2004-10-05 2006-04-06 Canon Kabushiki Kaisha Signature-generation method, signature-verification method, public-key distribution method, and information-processing apparatus
US20120204025A1 (en) * 2006-08-29 2012-08-09 Akamai Technologies, Inc. System and method for client-side authentication for secure internet communications
US20080060055A1 (en) * 2006-08-29 2008-03-06 Netli, Inc. System and method for client-side authenticaton for secure internet communications
US8181227B2 (en) * 2006-08-29 2012-05-15 Akamai Technologies, Inc. System and method for client-side authenticaton for secure internet communications
US8560834B2 (en) * 2006-08-29 2013-10-15 Akamai Technologies, Inc. System and method for client-side authentication for secure internet communications
US8631240B2 (en) 2006-11-13 2014-01-14 Certicom Corp. Compressed ECDSA signatures
WO2008058377A1 (en) * 2006-11-13 2008-05-22 Certicom Corp. Compressed ecdsa signatures
US20100023775A1 (en) * 2006-11-13 2010-01-28 Vanstone Scott A Compressed ecdsa signatures
EP2174445A4 (en) * 2007-07-17 2011-10-19 Certicom Corp METHOD FOR PROVIDING A TEXTUAL REPRESENTATION OF A CRYPTOGRAPHIC VALUE
EP2174445A1 (en) * 2007-07-17 2010-04-14 Certicom Corp. Method of providing text representation of a cryptographic value
US8964971B2 (en) 2007-07-17 2015-02-24 Certicom Corp. Method of providing text representation of a cryptographic value
WO2009009871A1 (en) 2007-07-17 2009-01-22 Certicom Corp. Method of providing text representation of a cryptographic value
EP2174445B1 (en) * 2007-07-17 2016-09-07 Certicom Corp. Method of providing text representation of a cryptographic value
US20090022309A1 (en) * 2007-07-17 2009-01-22 Vanstone Scott A Method of providing text representation of a cryptographic value
US20090196418A1 (en) * 2008-02-04 2009-08-06 Freescale Semiconductor, Inc. Encryption Apparatus with Diverse Key Retention Schemes
US8175276B2 (en) * 2008-02-04 2012-05-08 Freescale Semiconductor, Inc. Encryption apparatus with diverse key retention schemes
US8819417B2 (en) * 2008-05-30 2014-08-26 Hitachi, Ltd. Validation server, validation method, and program
US20090300349A1 (en) * 2008-05-30 2009-12-03 Yoko Hashimoto Validation server, validation method, and program
US20120159158A1 (en) * 2008-05-30 2012-06-21 Hitachi, Ltd. Validation server, validation method, and program
US20100241852A1 (en) * 2009-03-20 2010-09-23 Rotem Sela Methods for Producing Products with Certificates and Keys
US8364954B2 (en) 2009-12-16 2013-01-29 Symantec Corporation Method and system for provisioning multiple digital certificates
US11251974B2 (en) 2009-12-16 2022-02-15 Digicert, Inc. Provisioning multiple digital certificates
US9055059B1 (en) 2009-12-16 2015-06-09 Symantec Corporation Combining multiple digital certificates
US20110145569A1 (en) * 2009-12-16 2011-06-16 Verisign, Inc. Method and system for provisioning multiple digital certificates
US20110145567A1 (en) * 2009-12-16 2011-06-16 Verisign, Inc. Method and system to combine multiple digital certificates using the subject alternative name extension
US8375204B2 (en) 2009-12-16 2013-02-12 Symantec Corporation Method and system to combine multiple digital certificates using the subject alternative name extension
US9100191B2 (en) 2009-12-16 2015-08-04 Symantec Corporation Combining multiple digital certificates
US20110154027A1 (en) * 2009-12-23 2011-06-23 Verisign, Inc. Method and system for co-termination of digital certificates
US9680819B2 (en) 2009-12-23 2017-06-13 Symantec Corporation Method and system for co-termination of digital certificates
US20110161662A1 (en) * 2009-12-30 2011-06-30 Hong Fu Jin Precision Industry (Shenzhen) Co., Ltd System and method for updating digital certificate automatically
US20150095650A1 (en) * 2013-09-27 2015-04-02 Daniel Nemiroff Public key infrastructure for system-on-chip
US9319224B2 (en) * 2013-09-27 2016-04-19 Intel Corporation Public key infrastructure for system-on-chip
US11443293B2 (en) * 2013-12-10 2022-09-13 China Unionpay Co., Ltd. Secure network accessing method for POS terminal, and system thereof
US20170257220A1 (en) * 2014-11-19 2017-09-07 Huawei Technologies Co., Ltd. Directional-traffic statistics method, device, and system
US10680829B2 (en) * 2014-11-19 2020-06-09 Huawei Technologies Co., Ltd. Directional-traffic statistics method, device, and system
US10893031B2 (en) * 2015-12-09 2021-01-12 Cloudflare, Inc. Dynamically serving digital certificates based on secure session properties
US10305871B2 (en) * 2015-12-09 2019-05-28 Cloudflare, Inc. Dynamically serving digital certificates based on secure session properties
US20170324545A1 (en) * 2016-05-04 2017-11-09 International Business Machines Corporation Revocable pki signatures
US10447467B2 (en) * 2016-05-04 2019-10-15 International Business Machines Corporation Revocable PKI signatures
WO2018027300A1 (en) 2016-08-08 2018-02-15 ISARA Corporation Using a digital certificate with multiple cryptosystems
US10812475B2 (en) * 2017-04-18 2020-10-20 Servicenow, Inc. Authenticating access to an instance
US20180302400A1 (en) * 2017-04-18 2018-10-18 Servicenow, Inc. Authenticating access to an instance
US11106775B2 (en) 2017-10-20 2021-08-31 Advanced New Technologies Co., Ltd. Digital certificate application
WO2019079761A1 (en) * 2017-10-20 2019-04-25 Alibaba Group Holding Limited METHOD AND DEVICE FOR APPLYING A DIGITAL CERTIFICATE
TWI696931B (zh) * 2017-10-20 2020-06-21 香港商阿里巴巴集團服務有限公司 數位證書申請方法和裝置
US11106776B2 (en) 2017-10-20 2021-08-31 Advanced New Technologies Co., Ltd. Digital certificate application
CN112352238A (zh) * 2018-06-28 2021-02-09 币即特株式会社 多重签名安全帐户控制系统
CN113228560A (zh) * 2018-10-23 2021-08-06 西门子股份公司 用于发行的发行设备和方法以及用于请求数字证书的请求设备和方法
CN109992953A (zh) * 2019-02-18 2019-07-09 深圳壹账通智能科技有限公司 区块链上的数字证书签发、验证方法、设备、系统及介质
US20220247731A1 (en) * 2019-03-25 2022-08-04 Micron Technology, Inc. Secure communication between an intermediary device and a network
US12120100B2 (en) * 2019-03-25 2024-10-15 Micron Technology, Inc. Secure communication between an intermediary device and a network
CN110011799A (zh) * 2019-04-02 2019-07-12 河南管软信息技术有限公司 移动办公中的通信安全方法
CN113841360A (zh) * 2019-05-14 2021-12-24 大众汽车股份公司 蝴蝶密钥扩展方案的实现
US20230246819A1 (en) * 2022-02-01 2023-08-03 Juniper Networks, Inc. Public key infrastructure based session authentication
TWI810957B (zh) * 2022-06-01 2023-08-01 倍穎資訊股份有限公司 一種遠端節點控制管理平台
CN115442052A (zh) * 2022-08-30 2022-12-06 云海链控股股份有限公司 一种协同签名方法、系统、设备及计算机可读存储介质
EP4440033A1 (en) 2023-03-31 2024-10-02 Sick Ag Authenticating data based on certificates

Also Published As

Publication number Publication date
US8214637B2 (en) 2012-07-03
US20100228970A1 (en) 2010-09-09
JP2002207426A (ja) 2002-07-26

Similar Documents

Publication Publication Date Title
US8214637B2 (en) Public key certificate issuing system, public key certificate issuing method, digital certification apparatus, and program storage medium
US7152158B2 (en) Public key certificate issuing system, public key certificate issuing method, information processing apparatus, information recording medium, and program storage medium
JP4796971B2 (ja) Ｏｃｓｐ及び分散型ｏｃｓｐのための効率的に署名可能なリアルタイム・クレデンシャル
US9154306B2 (en) Privacy-preserving flexible anonymous-pseudonymous access
US6192130B1 (en) Information security subscriber trust authority transfer system with private key history transfer
CA2408589C (en) Url-based certificate in a pki
JP5130318B2 (ja) 証明書に基づく暗号化および公開鍵構造基盤
US20100229241A1 (en) Method of accessing service, device and system thereof
CN109711184B (zh) 一种基于属性加密的区块链数据访问控制方法及装置
US20040165728A1 (en) Limiting service provision to group members
US20060129847A1 (en) Methods and systems for providing a secure data distribution via public networks
US20070242830A1 (en) Anonymous Certificates with Anonymous Certificate Show
US20010034834A1 (en) Public-key-encryption data-communication system and data-communication-system forming method
US20020010861A1 (en) Access control system, access control method, device, access control server, access-control-server registration server, data processing apparatus, and program storage medium
CN109146479B (zh) 基于区块链的数据加密方法
CN108696360A (zh) 一种基于cpk密钥的ca证书发放方法及系统
CN111614680B (zh) 一种基于cp-abe的可追溯云存储访问控制方法和系统
EP2179534A1 (en) Method and system for generating implicit certificates and applications to identity-based encryption (ibe)
Win et al. Privacy enabled digital rights management without trusted third party assumption
CN115834067A (zh) 一种边云协同场景中密文数据共享方法
CN117896180B (zh) 一种以属性基加密技术为基础的多系统组网方法及其智能设备、存储介质
CN107360252A (zh) 一种异构云域授权的数据安全访问方法
CN109146684B (zh) 去中心化交易验证方法
CN115001673A (zh) 基于统一多域标识的密钥处理方法、装置及系统
Fan et al. Date attachable offline electronic cash scheme

Legal Events

Date Code Title Description
AS Assignment

Owner name: SONY CORPORATION, JAPAN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:OKA, MAKOTO;ISHIBASHI, YOSHIHITO;MATSUYAMA, SHINAKO;AND OTHERS;REEL/FRAME:012786/0401;SIGNING DATES FROM 20020305 TO 20020306

STCB Information on status: application discontinuation

Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION