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/321—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 a third party or a trusted authority
• • 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
• • 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/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/3297—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 time stamps, e.g. generation of time stamps
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
  • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
  • H04L2209/80—Wireless

Definitions

• the present invention relates to the verification of identity and especially to digital certifi- cates.
• the invention relates to a method for limiting the interpretation of the identity of an entity.
• Third Party such as e.g. a Certificate Authority
• CA certificate
• the function of the trusted third party is to verify the identity of certificate holders and to sign the certificate so that it cannot be altered without the change being discovered. After the trusted third party has signed the certificate, the owner of the certificate can present it to other people or parties to prove -his identity and to establish encrypted telecommunication connections.
• the certificate contains information relating to its owner and to the party having is- sued the certificate.
• the certificate contains e.g. the following information. Name of the owner and other possible information identifying the owner, electronic mail address and public key. A public signing key contained in the certificate can be used for the verification of signatures.
• the certificate contains e.g. the name and identification number of the party having publicized the certificate and time data defining the period of validity of the certificate.
• Digital certifi- cates are generally based on Public Key Cryptography
• PLC PLC
• PLC public key method
• the use of the public key and the use of the secret key are heavily interdependent.
• Using a public signing key it is pos- sible to verify a digital signature which has been made by utilizing a secret signing key.
• the public key can be freely publicized and distributed to any parties that may desire to have it, but the secret key has to be kept in a safe place that cannot be accessed by any other parties.
• a digital certificate links the public key with the identity verified by a trusted third party.
• the certificates are not context-dependent, but in practice different certificates are needed for different uses.
• a standard X.509 certificate contains no e-mail address data, which is needed for secure transmission of e-mail mes- sages (e.g. PGP or S/MIME) .
• certain applications may require the inclusion of specific attributes in the certificate.
• the end user's public key has been certified with several digital certificates. One of them is revoked while the other certificates remain valid. The problem is whether a service provider can use one of the valid certificates instead of the revoked one if he originally intended to use the revoked certificate.
• a further problem is that the customer software applications in all terminals, especially portable and wireless terminals, do not necessarily have sufficient resources for generating and maintaining several key pairs .
• the present system does not allow the same user to have several different roles when the same key is used in the services provided by the same service provider.
• the keys are generated to a data medium (e.g. a smart card) by another party before the data medium comes into the end user's possession.
• a data medium e.g. a smart card
• the secret signing key cannot be activated before its public counterpart has been verified with a certificate. Otherwise there is a theoretical risk that an unreliable party might use the signature before a certificate has been created and that these signatures could be later regarded as having been made by the party that acquired the certificate .
• the object of the present invention is to eliminate the drawbacks referred to above or at least to significantly alleviate them.
• a specific object of the invention is to disclose a new type of method that will make it possible to define for an entity a certificate to be used for the interpretation of the identity of the entity.
• the present invention relates especially to applications which do not have sufficient resources for maintaining and processing user certificates and the associated public keys in conjunction with digital signatures.
• the invention concerns a method for limiting the interpretation of the identity of an entity.
• one or more digital certificates are defined for the public key of the entity.
• the validity of the certificate may be limited according to the number of times the certificate is used or according to the length of time it is used. Thus, it is possible to define certificates that are valid for a very short time, e.g. a few seconds or a few hours, or certificates that can be used e.g. only once.
• 'Entity' preferably refers to a juridical person. However, this term may also be used to refer to something else than a juridical person, e.g. to a device or a computer program.
• Each certificate may represent a given identity or role defined for the entity. Two or more certificates may also represent the same identity or role.
• the entity's digital certificate or data indi- eating the digital certificate to be used is attached to a digital document generated by the entity.
• the data indicating the digital certificate to be used preferably is a hash code generated from an actual certificate .
• the digital document is signed digitally, said digital document comprising at least a digital certificate of the entity or data indicating the digital certificate to be used. This is to say that the certificate used or the data indicating the certifi- cate used is included in the digital signature. However, the digital document is not signed in the event that the certificate in the digital document is false or the data indicating the certificate in the message refers to a wrong certificate.
• the entity is verified by the aid of the certificate indicated by the digital document bearing a digital signature.
• the digital document unambiguously indicates which certificate is to be used for verifying the entity.
• To allow the entity to ascertain that the digital document contains the right certificate it can be shown to the entity before the digital signature is made.
• To the digital document signed by the entity it is possible to add a time stamp and/or certificate and/or digital signature given by a trusted third party.
• a time stamp and/or certificate and/or digital signature given by a trusted third party is added to the digital document before the document is signed by the entity.
• the entity's actions are carried out by means of a mobile station and/or a subscriber identity module connected to a mobile station.
• the invention also concerns a method for limiting the interpretation of the identity of an entity between contracting parties, in which method two or more entities establish a service relationship and decide about the structure and content of messages to be used during the service relationship.
• 'Service relationship' may refer e.g. to a service relationship that only comprises a single transaction.
• one or more digital certificates are defined for the public key of the entity. The validity of the certificate may be limited according to the number of times the certificate is used or according to its utilization time. Thus, it is possible to define certificates having a very short validity period, e.g. a few seconds or a few hours, or certificates that can be used e.g. only once.
• 'Entity' preferably refers to a juridical person, but it may also refer to something else than a juridical person, e.g. to a device or a computer program.
• certificates Preferably there are several certificates defined for the entity and the same public key. Each certificate may represent an identity or role defined for the entity. Two or more certificates may also represent the same iden- tity or role.
• the contracting parties have previously decided which digital certificate is to be used for verifying the identity of the entity. This decision may be made jointly or separately.
• the decision regarding the certificate to be used for the verification- tion is made e.g. in conjunction with the establishment of the service relationship. Thus, it will be possible to eliminate any attempts to verify the identity of the entity using a wrong certificate.
• a digital certificate or data indicating the digital certificate to be used is added to every agreement message consistent with the message structure used between the entity and the receiver of the agreement message.
• 'Receiver of the agreement message' preferably refers to another entity.
• 'Data indicating the digital certificate to be used' preferably refers to a hash code generated from the actual certificate.
• the service relationship may require that one of the entities sends to another entity an agreement message consistent with the message structure defined in the agreement .
• the message structure contains for each signing party a certificate or data indicating the digital certificate to be used. If the entity is a device, it may still desire to make sure about its own certificate or the certificates of the other parties.
• the certificate or certificates can be displayed to the entity before the digital signature is made. Thus, the entity can make sure that the right certificate is used to verify his identity. At the same time, the entity can check and accept the certificates of the other entities signing the agreement that are added to the agreement message.
• the agreement message is signed digitally before being sent to the receiver of the agreement message, which, for each contracting party signing the agreement, comprises at least a digital certificate or data indicating the digital certificate to be used. This is to say that the certificate used or the data indicating the digital certificate used is within the digital signature. However, the agreement is not signed if it contains the wrong certificate or no certificate at all.
• the entity is verified by the aid of the certificate indicated by the digitally signed agreement message. As there may be several certificates defined for the entity, the agreement message unambiguously indicates which certificate is to be used for the verification of each entity.
• a time stamp and/or certificate and/or digital signature given by a trusted third party can be added to the agreement message signed by the contracting parties.
• a time stamp and/or certificate and/or digital signature given by a trusted third party is added to the agreement message before the agreement message is sent to the contracting parties.
• the message received is rejected if it does not contain a predetermined certificate or data indicating a predetermined certificate. Further, the agreement message can be rejected if it has been signed using a differ- ent key than the key indicated by the certificate.
• a confirmation message concerning the agreement made is sent to the contracting parties.
• they en- tity's actions are carried out by means of a mobile station and/or a subscriber identity module connected to a mobile station.
• the communication between the entity and the service provider is preferably transmitted in a short message in a mobile communication net- work .
• the present invention makes it possible for a contracting party to ascertain which other parties are going to sign the agreement .
• the contracting party can also ascertain who is going to be used as a certifier of the agreement (notary) .
• the present invention enables the user to make sure that the right certificate is used for the verification of his identity, because the data indicating the certificate to be used is included in the message between the user and the receiver of the agreement message. As a decision is made beforehand as to the certificate to be used to verify the user's identity, the message sent will only be valid according to a given certificate even if alternative certificates should be available.
• the invention makes it possible to define the responsibilities and obliga- tions associated with the certificate so that they only pertain to a single CA even if the same key has been certified by more than one CA.
• the invention makes it possible to specify in advance which trusted third party is to be used to certify the agreement.
• the invention makes it possible to use a plurality of identities or roles with the same public key in the services provided by the same service provider.
• Fig. la represents a method according to the invention
• Fig. lb represents a method according to the invention.
• Fig. 2a and 2b present a preferred example of a signal flow diagram in which the method of the in- vention is used.
• Fig. la describes the operation of the method of the invention.
• the required actions are preferably carried out using a mobile station (MS) and/or a subscriber identity module (SIM) connected to the mobile station.
• MS mobile station
• SIM subscriber identity module
• the choice of the terminal to be used is in no way restricted to a mobile station; instead, the terminal may be any other device that comprises the properties required by the invention.
• one or more digital certificates are have been defined for the public key of an entity.
• 'Entity' preferably means a juridical person. However, 'entity' may be also be used to refer to something else than a juridical person, e.g. a de- vice or a computer program.
• Each digital certificate defined for the entity may represent an identity or role of the entity (e.g. company identity, personal identity) .
• Two or more certificates may also represent the same identity or role. Creating different digital certificates for the same public key obviates the necessity to create a new public key for each certificate. Some of the digital certificates created may be very short-lived as regards the validity period or the number of times they can be used (e.g. certificate us- able only once or valid for only a few seconds or hours) . Therefore, it would not be very practical to create a separate public key for each digital certificate .
• the digital certificate or data indicating the digital certificate to be used is added to each digital document generated by the entity, block 2.
• 'Data indicating the digital certificate to be used' preferably refers to a hash code generated from the actual certificate.
• Such a hash code is generated by using a special function, e.g. SHA1 (SHA, Secure Hash
• the hash code contains an unambiguous string of characters that is considerably shorter than the original input data.
• the generation of the hash code is a one-way operation, so it is not possible to make any conclusions about the original input data from the hash code .
• the digital document generated by the entity is signed digitally.
• digital signature e.g. the public key method (PKI, Public Key Infrastructure) and the RSA algorithm (RSA, Rivest, Shamir, Adleman) are used.
• the RSA algorithm may be replaced with any other algorithm that can be used in the public key method.
• the certificate can be presented to the user before the digital signature is made.
• a time stamp and/or certificate and/or digital signature given by a trusted third party can be added to the digital document before the entity signs the digital document.
• a time stamp and/or certificate and/or digital signature given by a trusted third party can also be added to the digital document after the digital document has been signed by the entity.
• the entity is verified by means of the digital certificate indicated by the digital document signed with a digital signature.
• Fig. lb describes the operation of the method of the invention.
• the entity is a person who uses an appropriate terminal.
• 'entity' may also refer to something else than a human being, e.g. a device or a computer program.
• the words 'entity' and 'user' mean the same thing.
• the actions carried out by the user are preferably accomplished using a mobile station and/or a subscriber identity module connected to a mobile sta- tion.
• User terminals are by no means restricted to a mobile station; instead, the terminal may be any other device that comprises the properties necessary for the invention.
• One or more of the entities may be a specific service provider, which preferably is a party that provides services defined in the agreement to the user.
• the service provider is e.g. a travel agency, a bank or an organ of public administration, but it may also be any other party which has the necessary resources for communicating with the user and his terminal .
• one or more digital certificates have been defined for the public key of the entity.
• Each certificate may represent a given identity or role of the user (e.g. company identity, personal identity). Two or more certificates may also represent the same identity or role.
• the necessity of creating a new public key for each certificate is now avoided.
• the use of a single public key is a considerable advantage especially in small portable terminals that do not have enough resources for maintaining and processing the user's digital certificates and the associated keys.
• some of the digital certificates created may be very short-lived in respect of their validity period or the number of times they can be used (being usable e.g. only once or having a validity period of a few seconds or a few hours) . Therefore, it would not be very prac- tical to create a separate public key for each digital certificate .
• the contracting parties have previously decided which digital certificate is to be used for the verification of the user's identity, block 6.
• the de- cision regarding the digital certificate to be used for verification is made e.g. in conjunction with the establishment of the service relationship.
• the deci- sion may be made jointly or separately. Thus, it is possible to make sure that the user's identity is always verified using the right digital certificate.
• the digital certificate or data indicating the digital certificate to be used for each contracting party is attached to each agreement message consistent with the message structure used between the user and the receiver of the agreement message, block 7.
• the receiver of the agreement message may be a spe- cific service provider.
• the data indicating the digital certificate to be used is preferably a hash code generated from the actual certificate. Such a hash code is generated using a special function, e.g. the SHA1.
• the hash code contains an unambiguous string of characters that is considerably shorter than the original input data.
• the generation of the hash code is a one-way operation, so it is not possible to make any conclusions about the original input data from the hash code.
• a time stamp and a digital signa- ture of the party giving the time stamp may be added to the signed agreement message.
• the service provider send the user an agreement message consistent with the message struc- ture defined in the agreement.
• the message structure contains for each contracting party signing the agreement a digital certificate or data indicating the digital certificate to be used.
• the digital certificate may be pre- sented to the user.
• the user can make sure that the right digital certificate is used for the verification of his identity.
• the entity can verify and accept the certificates of the other entities signing the agreement that are associated with the agreement message.
• the user signs the agreement message digitally before the message is sent to the other entity or to a specific service provider.
• the digital signature is made using e.g. the public key method and the RSA algorithm.
• the RSA algorithm may be replaced with any other algorithm that can be used in the public key method.
• a time stamp and/or certificate and/or digital signature given by a trusted third party can be added to the agreement message before the agreement message is sent to the contracting parties.
• each signer of the agreement message can see that the agreement message containing the digital certificates of the contracting parties has been certified.
• the service provider verifies the user by the aid of the digital certificate indicated by the digi- tally signed agreement message, block 9.
• the service provider can easily verify that the digital signature associated with the message corresponds to the certificate defined in the agreement. If an unreliable party sends a message in which there is a conflict be- tween the signature and the digital certificate, then the message can be automatically rejected.
• a time stamp and/or certificate and/or digital signature given by a trusted third party can be added to the agreement message signed by the contracting parties.
• the certificates of all the signing parties are added to the basic agreement before the signatures .
• data indicating the digital certificate to be used may be added to the basic agreement . Such data is e.g.
• the agreement transaction comprises three contracting parties (A, B and C) .
• One or more of the parties (A, B or C) may be a service provider who provides services or products mentioned in the agree- ment to the other parties. However, it is not strictly necessary for any one of the contracting parties to act as a specific service provider in the agreement transaction.
• party A Before signing the agreement, party A can ascertain who are the other parties whose digital signa- tures will be included in the agreement .
• party B Upon receiving the agreement signed by A, party B signs the entire document created during the previous stage, comprising the basic agreement, the certificates of the contracting parties and the signature of the previous party having signed the agreement. Thus, B accepts the signature of A.
• Party C acts in a corresponding manner, signing the agreement already signed by A and B.
• the signatures can be made at different times and in different places in a secure manner as the interpreta- tion of the identity of the signatories has been limited beforehand.
• the agreement will not be considered valid if it has been signed using a key other than the one indicated by the certificate.
• the signed agreement can be sent to a trusted third party, e.g.
• the agreement transaction comprises four contracting parties (A, B, C and D) .
• One or more of the parties may be a service provider who provides services or products mentioned in the agreement to the other parties. However, it is not strictly necessary for any one of the contracting parties to act as a specific service provider in the agreement transaction.
• party A Before signing the agreement, party A can ascertain who are the other parties whose digital signa- tures will be included in the agreement . An agreement corresponding to that sent to A is also sent to B and C. Likewise, B and C can check the certificates included in the agreement to see which other parties are going to sign an identical agreement. However, the agreement message sent to B or C is not the agreement message previously signed by A. D signs an agreement message that contains the digital signatures of both A, B and C as well as the digital certificates of all the signatories . The arrangement described above works in a star-like manner. This is to say that each contracting party has a separate identical message which is signed by each party.
• Party D is at the center of the star and receives the signed agreement messages and generates an agreement message that contains the digital certificates and digital signatures of all the contracting parties.
• the signed agreement can be sent to a trusted third party, e.g. to a notary service, which verifies the signatures of the parties and the validity of the certificates. After this, a time stamp and/or the digital signature of the trusted third party can be added to the agreement .
• D signs the agreement message just as A, B and C do. After A, B and C have sent the agree- ment messages signed by them to D, D sends all four signed messages to a trusted third party. The latter generates an agreement message containing the digital certificates and signatures of all the contracting parties and finally adds his own certificate and/or a time stamp and/or his own digital signature to the agreement message.
• the certificates of all the signing parties are added to the basic agreement before the signatures .
• data indicating the digital certificate may be added to the basic agreement. Such data is e.g. a hash code generated from the certificate.
• the agreement transaction comprises four contracting parties (A, B, C and D) .
• One or more of the parties may be a service provider who provides services or products mentioned in the agreement to the other parties. However, it is not strictly necessary for any one of the of the contracting parties to act as a specific service provider in the agreement transaction.
• party A Before signing the agreement, party A can ascertain who are the other parties whose digital signatures are to be included in the agreement.
• B, C and D have their own agreements corresponding to that sent to A.
• B and C and D can check the certifi- cates included in the agreement to see which other parties are going to sign an identical agreement.
• each contracting party has an identical message, which is signed digitally by each party.
• A, B, C and D send the signed agreement mes- sage directly to a trusted third party.
• the arrangement described above works as a star-like structure with the trusted third party at its center.
• the trusted third party receives the agreement message signed by each contracting party and verifies the sig- natures of the contracting parties and the validity of the certificates of the signatories.
• the trusted third party generates an agreement message containing the digital certificates and digital signatures of all the contracting parties and adds a time stamp and/or his own digital signature to the agreement message thus generated.
• the agreement transaction comprises three contracting parties: a payer, a bank and a payee.
• the payer has a basic agreement form that he can use to pay invoices.
• the payer fills in the identification and account data for the payer and the payee, possible bank reference or other additional data as well as the sum payable in the basic agreement form. Moreover, the payer adds his own digital certificate or alternatively data indicat- ing a digital certificate to the basic agreement form. Such data is e.g. a hash code generated from the digital certificate. The digital certificate or the data indicating a digital certificate may also be included in the basic agreement form beforehand by the bank. After all the required information has been added to the basic agreement, the payer signs the agreement message thus generated by putting his digital signature to it and sends the signed agreement message to the bank. The bank verifies the payer by the aid of the certificate indicated by the digitally signed agreement message.
• the bank may send the agreement message signed by the payer to a trusted third party, e.g. a notary service, which adds to the agreement message a time stamp and/or a digital signature of the trusted third party.
• a trusted third party e.g. a notary service
• the agreement message is sent to a trusted third party, which adds to the agreement message his own digital certificate and/or time stamp and/or digital signature.
• the trusted third party can verify the certificates in the agreement message beforehand. The procedure described above allows the parties to ascertain that the certificates of all the parties entering into agreement are valid. This procedure also lets the contracting parties know which trusted third party has verified the agreement message and the digital certificates of the parties. If one of the contracting parties does not accept the trusted third party to be used, then that party can refuse to sign the agreement and thus prevent its conclusion. After the contracting parties have signed the agreement message, the trusted third party adds a time stamp and/or a digital signature to the agreement message.
• the final agreement message carries two signatures of a trusted third party. It is not necessary to use the same trusted third party for the first and the second signatures to be added to the agreement message. Therefore, it is possible to use a first trusted third party to verify the agreement message before the addition of the signatures of the parties and a second trusted third party to verify the final agreement message containing the digital certificates and digital signatures of all the contracting parties signing the agreement .
• each contracting party can be sent a copy of the final agreement.
• each contracting party can e.g. file the agreement thus concluded or prove if necessary that he has made a given agreement .
• Figures 2a and 2b present a preferred example of a signalling flow diagram in which the method of the invention is applied.
• the example according to Fig. 2a and 2b comprises a PKI party PKI, a user and his terminal ME, a local certificate authority LRA (CA, Certificate Authority) and a service provider SP.
• the term ME in this example refers to the user, or to the user and the terminal equipment at his disposal .
• the service provider SP may be a mobile communication operator or any other party.
• 'user's terminal equipment ' means a mobile station and the subscriber identity module connected to the mobile station, but this is by no means intended to limit the application of the invention exclusively to mobile stations; instead, any other terminal may be used.
• 'PKI party PKI' refers to a party which channels and guarantees PKI services and which helps the user of services to find the desired services and warrants the reliability of many service providers SP by his own signature.
• the small arrows in Fig. 2a and 2b indicate the order of occurrence of the actions in the procedure.
• the user ME requests that a certificate be generated.
• the user's mobile station or the subscriber identity module connected to it contains a predefined public key, for which he now wants to have a new certificate generated.
• the new certificate is to be generated e.g. as a "company" certificate, whereas a previously generated certificate represents the user's "personal” certificate.
• the local certificate authority LRA receives the request sent by the user ME, block 21.
• the local certificate authority LRA checks the user data and the network identity (NID) associated with the user, block 22.
• 'Network identity' preferably means identity data com- prising encryption and/or signing keys attached to it at the time of its generation.
• the local certificate authority LRA generates a writ and encrypts it using the public key indicated by the network identity associated with the user ME, block 23.
• the user ME receives the writ and decrypts it using his own secret key, block 2 .
• the user ME further signs the writ using his own secret signing key and sends the signed writ back to the local certificate authority LRA, block 25.
• the local certifi- cate authority LRA receives the signed message and verifies the signature, block 26. If the message is successfully verified, then the local certificate authority LRA sends to the certificate authority CA a request to generate and publicize a certificate, block 27.
• the certificate authority receives the request and publicizes the user's certificate, blocks 28 and 29.
• the publicized certificate is then sent to the local certificate authority LRA, block 30.
• Fig. 2b carries the example presented in Fig. 2a further.
• the user ME sends a service request (SIR, Service Initialization Request) to the PKI party PKI.
• the service request may contain a certificate associated with the user or data indicating the certificate to be used for the verification of the user in conjunction with the desired service.
• the PKI party PKI receives the request and generates a certificate relating to the service provider SP, signs it and sends it to the user ME, blocks 32 and 33.
• the user ME receives the certificate relating to the service provider SP that was sent by the PKI party PKI and stores it in his mobile sta- tion.
• the PKI party PKI transmits the service request sent by the user further to the service provider SP, block 35.
• the service provider SP receives the service request, block 36.
• the user ME and the service pro- vider SP may have previously decided which digital certificate is to be used for the verification of the user in conjunction with each service.
• the service provider SP asks the certificate authority CA for a certificate relating to the user ME, incorporates it in the message to be sent to the user ME and sends the message it has generated to the user ME, blocks 37, 38 and 39.
• 'Message generated' denotes e.g. a kind of blank message form in which the user ME later fills in the re- quired information.
• the user ME receives the message form containing the certificate relating to the user ME. If the user thinks that the certificate contained in the message form is a false one or the message form contains no certificate at all, then the user ME will reject the message received.
• the cer- tificate can be presented to the user ME e.g. on the display of his mobile station to allow the user to make sure about the certificate.
• the user ME fills in the required information in the message form, puts his digital signature to the message generated and sends the service request to the service provider SP, block 41. All acceptable digital signatures are only made on message forms received by the user ME that already contain the certificate to be used for the verification of the user's ME identity.
• the service provider SP receives the message sent by the user ME and compares the digital signature attached to the message, the certificate contained in the message and the certificate obtained from the certificate authority CA to establish whether they are congruent, blocks 42, 43 and 44. Based on these, the service provider determines whether the service request received by the service provider SP is acceptable or not, block 45.
• the user generates, sends and receives the messages according to the above-described example preferably via a mobile station.
• the messages generated and received by the user are preferably short messages in a mobile communication network.
• the user preferably communicates with the other parties in the example via the mobile communication network.
• this is only one example of a possible terminal and telecommunication network that may be used.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Applications Claiming Priority (1)

Publications (1)

Family

ID=8555875

Family Applications (1)

Country Status (3)

Families Citing this family (1)

Citations (2)

Family Cites Families (6)

• 2000
  • 2000-06-14 EP EP00936929A patent/EP1297654A1/de not_active Withdrawn
  • 2000-06-14 AU AU2000252248A patent/AU2000252248A1/en not_active Abandoned
  • 2000-06-14 WO PCT/FI2000/000535 patent/WO2001097445A1/en active Application Filing

Patent Citations (2)

Non-Patent Citations (2)

Also Published As

Similar Documents

Legal Events