WO2001097445A1

WO2001097445A1 - Interpretation of the identity of an entity

Info

Publication number: WO2001097445A1
Application number: PCT/FI2000/000535
Authority: WO
Inventors: Jukka Liukkonen; Vesa Torvinen
Original assignee: Smarttrust Systems Oy
Priority date: 2000-06-14
Filing date: 2000-06-14
Publication date: 2001-12-20
Also published as: EP1297654A1; AU2000252248A1

Abstract

The invention concerns a method for limiting the interpretation of the identity of an entity. According to the invention, one or more digital certificates are defined for the public key of the entity; a digital certificate of the entity or data indicating the digital certificate to be used is added to a digital document generated by the entity; the digital document is signed digitally, said digital document comprising at least the digital certificate of the entity or data indicating the digital certificate to be used; and the entity is verified by the aid of the digital certificate indicated by the digitally signed digital document.

Description

INTERPRETATION OF THE IDENTITY OF AN ENTITY

FIELD OF THE INVENTION

The present invention relates to the verification of identity and especially to digital certifi- cates. In particular, the invention relates to a method for limiting the interpretation of the identity of an entity.

BACKGROUND OF THE INVENTION In operations requiring security, e.g. various electronic business transactions, it is necessary that the parties be able to electrically verify their identity in order to use selected services. This verification of identity can be implemented e.g. by em- ploying a user identifier and an associated password or by using a special certificate. To enable the verification of identity, the user must first register himself in order to obtain a certificate as described above . 'Digital certificate' or 'electronic identity' refers to data or a file that is unambiguously used for the identification of people and various resources via a telecommunication network, such as the Internet. When electronic mail applications are used, certificates are typically transmitted as an attachment to an e-mail message. However, the digital certificate is not signed even if the e-mail message is additionally provided with a digital signature. Digital certificates also enable a secure and confidential connection between two parties. Digital certificates are issued by a trusted third party (TTP, Trusted

Third Party), such as e.g. a Certificate Authority

(CA) . 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. Typically, 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. Moreover, 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.

To create a digital certificate, the trusted third party signs it digitally. The signature makes it impossible to alter the contents of the certificate without the change being discovered. Digital certifi- cates are generally based on Public Key Cryptography

(PKC) , which is based on the use of a public key and a secret key. In the 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.

Theoretically, the certificates are not context-dependent, but in practice different certificates are needed for different uses. For example, 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) . Similarly, certain applications may require the inclusion of specific attributes in the certificate.

In existing PKI (Public Key Infrastructure) applications, the end user's digital signature and the verification of this signature often occur at different times and at different locations. The end user signs messages which do not reveal the signer's identity. The end user identity associated with the signa- ture is only interpreted after the message has been received in the data system of a service producer. The end user cannot be completely certain about which certificate is used to verify his identity even if a certificate verified with a signature has been attached to the message sent to the service producer. It is possible that the same public key has been certified with more than one certificate by more than one CA. However, there is no statutory obligation that would compel the service producer to use expressly that cer- tificate which was sent as an attachment. In addition, there are PKI applications in which it is not possible to send a digital certificate along with a message to a service producer. Thus, the message can be afterwards interpreted in several ways differing from each other. Below is a list of problematic situations currently encountered.

1. If the end user's public key has been certified with certificates issued by more than one CA, then it is impossible to know which one of them should be used to prove the end user's identity. One certificate may be used on one day and another ^' certificate on the next day. Thus, the message is not unambiguous . 2. If the end user's public key has been certified with several certificates issued by different CA's, then there is no way to know which CA should be held liable to compensate for a loss.

3. If a new certificate for public keys is created afterwards for the time at which a transaction took place, then the message can be interpreted according to this new certificate.

4. If the end user's public key has been certified with several, conflicting role- specific certificates (e.g. work, private and anonymous certificates) , then his identity may be later confused.

5. 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.

6. In principle, it is possible for anyone to assume the role of a CA and award certificates.

In short, the problem is that the end user cannot be totally confident about which certificate is used to verify his identity.

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.

There are systems in which 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. In such systems, 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 .

OBJECT OF THE INVENTION

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.

BRIEF DESCRIPTION OF THE INVENTION

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. According to the invention, 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. There are preferably several certificates defined for the same public key of the entity. 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. As there may be several certificates defined for the entity, 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.

In an embodiment of the invention, 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.

In an embodiment of the invention, 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. According to the invention, 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. 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 verifica- 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.

For each contracting party signing the agreement, 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. In an embodiment of the invention, 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. In an embodiment of the invention, 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.

In an embodiment of the invention, a confirmation message concerning the agreement made is sent to the contracting parties.

In an embodiment of the invention, 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.

LIST OF ILLUSTRATIONS

In the following, the invention will be described in detail by the aid of a few examples of its embodiments, wherein

Fig. la represents a method according to the invention,

Fig. lb represents a method according to the invention, and

Fig. 2a and 2b present a preferred example of a signal flow diagram in which the method of the in- vention is used.

DETAILED DESCRIPTION OF THE INVENTION

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. 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. According to block 1, 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

Algorithm) . 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 . According to block 3 , the digital document generated by the entity is signed digitally. For 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. In the case of a human entity, the certificate can be presented to the user before the digital signature is made. In this way it is possible to ensure that the right digital certificate is used for the verification of the user's identity. 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.

According to block 4, 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. In the example in Fig. lb, it is assumed that two or more entities have entered into a service relationship and decide about the message structure and content to be used during the service relationship. In this example, the entity is a person who uses an appropriate terminal. However, 'entity' may also refer to something else than a human being, e.g. a device or a computer program. In this example, 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 .

According to block 5, one or more digital certificates have been defined for the public key of the entity. In this example it is assumed that several digital certificates differing from each other have been defined for the user's public key. 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. As several digital certificates differing from each other are created for the same public key, 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. Further, 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. Moreover, a time stamp and a digital signa- ture of the party giving the time stamp may be added to the signed agreement message.

For the service relationship it may be required that 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. Before the digital signature is made, the digital certificate may be pre- sented to the user. Thus, the user can make sure that the right digital certificate is used for the verification of his identity. At the same time, the entity can verify and accept the certificates of the other entities signing the agreement that are associated with the agreement message.

According to block 8, 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. Thus, 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. In an embodiment according to Fig. lb, the certificates of all the signing parties are added to the basic agreement before the signatures . Alternatively, data indicating the digital certificate to be used may be added to the basic agreement . Such data is e.g. a hash code generated from the certificate. In this example, 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.

Before signing the agreement, party A can ascertain who are the other parties whose digital signa- tures will be included in the agreement . 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. In addition, 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 . In an embodiment according to Fig. lb, the certificates of all the signing parties entering into agreement are added to the basic agreement before the signatures. Alternatively, data indicating the digital certificate may be added to the basic agreement. Such data is e.g. a hash code generated from the certificate. In this example, the agreement transaction comprises four contracting parties (A, B, C and D) . One or more of the parties (A, B, C or D) 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.

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. In addition, 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 .

An alternative solution regarding the role of D could be that 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. In an embodiment according to Fig. lb, the certificates of all the signing parties are added to the basic agreement before the signatures . Alternatively, data indicating the digital certificate may be added to the basic agreement. Such data is e.g. a hash code generated from the certificate. In this example, the agreement transaction comprises four contracting parties (A, B, C and D) . One or more of the parties (A, B, C or D) 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. 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. Likewise, 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. Thus, 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. In an embodiment according to Fig. lb, 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. If this payer verification yields a positive result, then the bank will execute the actions required for the payment of the bill. 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.

In an embodiment according to Fig. lb, before the agreement message is sent to the contracting parties for signature, 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. Thus, 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 .

In the above examples according to Fig. lb, each contracting party can be sent a copy of the final agreement. Thus, 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. In this example, '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.

According to block 20, 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. According to block 31, 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. According to block 34, 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. After the service provider SP has received the service request, it 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.

According to block 40, 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. Thus, the user preferably communicates with the other parties in the example via the mobile communication network. However, this is only one example of a possible terminal and telecommunication network that may be used.

The invention is not restricted to the examples of its embodiments described above; instead, many variations are possible within the scope of the inventive idea defined in the claims.

Claims

1. Method for limiting the interpretation of the identity of an entity, characterized in that the method com- prises the steps of: defining one or more digital certificates for the public key of the entity; adding a digital certificate of the entity or data indicating the digital certificate to be used to a digital document generated by the entity; signing the digital document with a digital signature, said digital document comprising at least the digital certificate of the entity or data indicating the digital certificate to be used; and verifying the entity by the aid of the digital certificate indicated by the digitally signed digital document .

2. Method according to claim 1, charac t eri zed in that the data indicating the certifi- cate of the entity is included in the digitally signed digital document in a hashed form.

3. Method according to claim 1 or 2 , char act eri zed in that the digital document is only signed if it contains the right certificate or data indicating the right certificate.

4. Method according to any one of the preceding claims 1, 2 or 3, charact eri zed in that a time stamp and/or certificate and/or digital signature given by a trusted third party are/is added to the digital document before the entity signs the digital document .

5. Method according to any one of the preceding claims 1, 2, 3 or 4, charact eri zed in that a time stamp and/or certificate and/or digital signature given by a trusted third party are/is added to the digital document signed by the entity.

6. Method according to any one of the preceding claims 1, 2, 3, 4 or 5, characteri zed in that the certificate is presented to the entity before signature .

7. Method according to any one of the preceding claims 1, 2, 3, 4, 5 or 6, characteri zed in that the validity of the certificate is limited according to the number of times it may be used and/or according to utilization time.

8. Method according to any one of the preceding claims 1, 2, 3, 4, 5, 6 or 7, characterized in that the entity's actions are carried out by means of a mobile station and/or a subscriber identity module connected to a mobile station.

9. 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 message structure and content to be used during the service rela- tionship, characteri zed in that the method further comprises the steps of: defining one or more digital certificates for the public key of the entity; deciding which digital certificate is to be used for the verification of the identity of the entity; including in each agreement message consistent with the message structure used between the entity and the receiver of the agreement message the digital cer- tificate of each contracting party signing the agreement or data indicating the digital certificate to be used; signing the agreement message with a digital signature before it is sent to the receiver of the agree- ment message, said message comprising at least the digital certificate of each contracting party signing the agreement or data indicating the digital certificate to be used; and verifying the entity by the aid of the digital certificate indicated by the digitally signed agree- ment message.

10. Method according to claim 9, charac teri zed in that a decision about which digital certificate is to be used for the verification of the identity of the entity is made in conjunction with the establishment of the service relationship.

11. Method according to claim 9 or 10, characterized in that the data indicating the digital certificate of the entity is included in the agreement message in a hashed form.

12. Method according to any one of the preceding claims 9, 10 or 11, characteri zed in that the agreement message is only signed if it contains the right digital certificates or data indicating the right digital certificates.

13. Method according to any one of the preceding claims 9, 10, 11 or 12, characteri zed in that a time stamp and/or certificate and/or digital signature given by a trusted third party are/is added to the agreement message before the agreement message is sent to the contracting parties.

14. Method according to any one of the preceding claims 9, 10, 11, 12 or 13, characteri zed in that a time stamp and/or certificate and/or digital signature given by a trusted third party are/is added to the agreement message signed by the contracting parties.

15. Method according to any one of the preceding claims 9, 10, 11, 12, 13 or 14 charac teri zed in that the digital certificate is pre- sented to the entity before signature.

16. Method according to any one of the preceding claims 9, 10, 11, 12, 13, 14 or 15, char- acteri zed in that the validity of the digital certificate is limited according to the number of times it may be used and/or according to utilization time.

17. Method according to any one of the pre- ceding claims 9, 10, 11, 12, 13, 14, 15 or 16 c h a r - acteri zed in that 'the agreement message is rejected if it does not contain a predetermined digital certificate or data indicating a predetermined digital certificate .

18. Method according to any one of the preceding claims 9, 10, 11, 12, 13, 14, 15, 16 or 17, characteri zed in that the agreement message is rejected if the agreement message has been signed using a key other than the key indicated by the digital certificate.

19. Method according to any one of the preceding claims 9, 10, 11, 12, 13, 14, 15, 16, 17 or 18, characteri zed in that a confirmation message concerning the agreement concluded is sent to the con- tracting parties.

20. Method according to any one of the preceding claims 9, 10, 11, 12, 13, 14, 15, 16, 17, 18 or 19, characteri zed in that the entity's actions are performed by means of a mobile station and/or a subscriber identity module connected to a mobile station.

21. Method according to any one of the preceding claims 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19 or 20, characteri zed in that the communi- cation between the entities is transmitted in a short message in a mobile communication network.