FI114767B - A method for granting electronic identity - Google Patents

Description

\ 114767

METHOD FOR ISSUING ELECTRICAL IDENTITY BACKGROUND OF THE INVENTION

Object of the invention

The present invention relates to electronic identity techniques and methods. In particular, the present invention relates to a new and improved method and system for requesting and granting electronic identity based on previously certified electronic identity.

10

Description of the Prior Art

Identities often require electronic authentication to protect communications before using services or executing transactions. This authentication can be a username and password combination or a certificate. To meet this requirement, identities must first register, either physically or virtually, so that they can receive proof of identity.

Providing proof, such as a combination of a username and password, • authenticates.

'·' · Unfortunately, the above simple authentication is not content-specific: the identity 25 based on the username and password can be completely meaningless in all other contexts. Further, such a certificate does not indisputably distinguish between different iden-, i> t; identity.

... Digital certificates or electronic identities are electronic files that are used to uniquely identify people and resources in networks such as the Internet. Digital '<] ·' certificates makes it possible to secure the Confidential connection between the two parties. When already-35 ku traveling to another country, his passport provides 114767 2 worldwide ways to present identity and secure entry. Digital certificates provide similar identification. Certification can be granted by a trusted third party (TTP) such as a Certification Authority (CA). In the same way as the passport-office role, role of a trusted third party must confirm (validate) the certificate identity and rulers to "sign" the certificate so that it can be shown manipulations or 10 intact. Once TTP has signed the certificate, the administrator can present its certificate to other people, web sites, and network resources to prove its identity and establish an encrypted secure communications connection.

15 Typically, a certificate contains a set of information related to the certificate holder and the TTP. Who issued the certificate. This information can be as follows. The holder's name and other identifying information required to uniquely identify the holder, such as the URL to the web server using the certificate, the individual's email address, or the holder's public key. The public key can be used to encrypt sensitive information to the certificate holder; ·: · *: Name of the certifying authority issuing the certificate; a unique identifier; period of validity (or lifetime) ser. ···. for the certificate (start and end date).

, ···. When creating a certificate, this information is * - digitally written by the issuing TTP. The TTP signature on the certificate is like a trust | • 30 · · · · · · · · · · · · · · · · · · · · · · · - · · · · · · · · · · · · · · · · · · · · · · · · · · Digital certificates *: * · are usually based on public key encryption, which uses a key pair for encryption and decryption. In public key encryption, the keys function as matching pairs of "public" and "private" keys. In encryption systems, the term key refers to a numeric value used in an algorithm to change information 114767 3, making the information secret and visible only to individuals who have the corresponding key to recover the information.

The public key may be freely distributed without imposing a secret key which must be kept secret by the holder. Because these keys act as a key pair, operations (for example, encryption) with a public key can be restored (decrypted) with the corresponding secret key and vice versa. The Digi-10 Dali Certificate securely binds your identity, verified by a trusted third party (CA), to your public key.

A CA certificate is a certificate that identifies a certification authority. CA certificates 15 correspond to other digital certificates except they are self-signed. CA certificates are used to determine whether a certificate issued by a CA is trusted.

In the case of a passport, the passport control authority 20 verifies the validity and authenticity of your passport and determines whether you can enter the country. Similarly, CA certificates • .V are used to authenticate and validate a web server certificate. When the web server certificate is presented to ·: * ·: the browser uses the CA certificate specified by V '*. 25 to determine if the web server certificate is trusted.

. ···. If the server certificate is a valid encrypted • «, ···, the session proceeds. If the server certificate is not * * valid, the server certificate will be rejected and the encrypted session will be suspended.

♦ · · t · 30 In the digital environment, the current equivalence of an identity card is a certificate: a validated proof of an identifiable identity. A certificate fiction typically does nothing more than verify the attribute it is targeted for. The most common use for I »t '·' '35 certificates is to bind the public keys of an identity to its identity. These keys can be used for various purposes such as providing authentication, authentication, security clearance, data integrity, and non-repudiation.

Theoretically, certificates are not content dependent, but in practice different uses require different certificates. For example, the X.509 certificate does not contain the e-mail address information that is required for encrypted e-mail (such as PGP or S / MIME). Similarly, other applications may require their own security-specific attribute, which is included in the certificate. While this attribute increase is not problematic in itself, new certificates must be created.

US 5,982,898 describes a method of issuing a short-term certificate to a person who already has a prior certificate. The new certificate will be issued after the validity of the previous certificate has been verified. Validation is done by separating identity verification and certification 20, which allows for the long-term bond to be removed from the individual and their public and / or private key pair. This is done by the registration authority: ·: the authority which issues the passport to the person, once it has been ascertained of the person's good faith. After ** **. 25 every time a person wants to get a new certificate I ·, ···. or electronic identity, the person will contact you

> I

*, identify yourself with your passport and get the certificate. Typically, the certificate includes the person's name and public key in text format 30 and a signature. The signature is obtained by hash - «· ... * encoding a body of text from the certificate to obtain a value« and encrypting the value with a CA secret key.

* · ·. ·· *. In order to obtain a certificate or other electronic identity certificate, the subject must »prove and re-register its existence to an authority.

· ... · If the same identity needs multiple proofs for different 114767 5 I uses, it is quite inconvenient to repeat the registration procedure.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide means for using a previously certified identity to create another representation for the same identity.

This representation may be implemented as an electronic identity, certificate, or certified access to the service or server. In this way, the identity that can be defined as the recipient of the electronic identity or certificate or the certificate holder can extend its own already verified identity to other uses. A previously certified identity may be, for example, a so-called mobile identity associated with a person's mobile device, such as a mobile phone. An individual can prove his or her certificate by using the digital signature feature of the mobile 20-man.

The following is an example of steps in the identity extension process in accordance with the present invention. Note that identities and devices in the process description are listed by their role and are not necessarily separate in practical implementations.

An entity (entity; entity) must be authenticated in a situation where it does not have an entity. a more established identity. The entity or> 30 authorized representatives provide optional information that is attached to the verifiable facts available from the registration authority that knows the entity's mobile identity.

<1 ^ This information and the identification request are sent to 35 mobile identity registration authorities ** · * with routing information from the recipient of the identification and also to a terminal containing means such as 6 11477 signature keys to confirm the previously confirmed mobile message identity. Based on the type of authentication request, the registration authority adds the attributes added by the optional sender to the verified data it manages and forwards them to a particular terminal. If the identity cannot be resolved from the terminal routing information, the process is interrupted.

The entity or authorized representative 10 examines the accuracy of the authentication response information at the terminal and, if it finds the information approved, digitally signs the response, which is then sent back to the registration authority. Where the type of identification requires additional guarantees such as certification, the registration authority shall request appropriate confirmation from the providers of such services. Verified identity information is sent to the recipient address specified in the original authentication request.

Compared to the previous registration and certification schemes, the most obvious advantage is that the present invention provides the same level of confidence as the local registration office can provide without physical and other limitations. The equivalence of trust is based on the fact that the registration authority (*. · * ·, Manages or has access to similar information, * «·. Ie its private databases or the databases of other authorities such as the Finnish Population Register Center. There are also attributes like

<i 11 I

30 access to a specific email address that can be ... * secured by virtual means, even though these were not pre-stored.

. * · *. If the mobile identity and device are used, for example, instead of a terminal '·' '35 device with a smart card, the solution of the present invention is completely location dependent. The entity can verify its identity and receive the new identity at any time and wherever required and is not limited to the available hardware and software provided the recipient is able to receive the confirmation. Although solution j 5 does not allow the use of generic mobile stations (i.e.

j someone else's phone), the probability transfer terminal that f is used to authorize the authentication response is the entity's own. Thus, the entity is not required to perform sensitive operations such as a signature-10 PIN on unreliable devices.

Essentially, the invention is intended to extend entity identity based on existing mobile certificate and other verified and validated facts. -The most obvious and practical function is to use this information to issue a new certificate for various uses, such as secure email, PGP or S / MIME. The mobile conversion of the solution, however, is not necessarily as limited. Because the ability to produce validated facts from an entity is fully mobile, in certain situations, the certificate • · * .V is not a key factor. For example, if mobile. '.1 The registration authority has access to the Finnish' ·· *: Database of the Population Register Center, it can provide 25 verified home addresses, marital status or whatever, ** ·. hansa is required.

t * • ·

'·· *' PHOTO LIST

The forms, objects, and advantages of the present invention will become more apparent from the following detailed description with reference to the accompanying drawings, where: i a ♦

Fig. 1 is a flow diagram of a system according to the present invention, ···; Figure 2 is a flowchart of an embodiment of the present invention; 114767 8

Figure 3 is a second flow diagram of another embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Figure 1 shows an example of a preferred system according to the present invention. The system of Figure 1 includes a mobile station MS connected through a communication network CN to a CA server of a certification authority. In addition, system 10 includes a terminal device including, for example, a web browser. The terminal is connected to the CN / CA server of the communication network. The mobile station includes means for digitally signing the message or string. The digital signature device is certified 15 by at least one certificate, which allows the user to authenticate multiple certificates. This earlier certificate may be the mobile certificate mentioned above.

Referring to Figure 1, a preferred embodiment of the present invention is described. This application, ·, ·, is described in the * 1 i, 1 certification of the new PGP key pair.

<<·) In this solution, the following assumptions apply * I I »·. The t · 25 PGP key pack, signed by the mobile SIM card, "lives" for only a short time (a few t t · ',,, · minutes) in the system and is then discarded. If logged in, it can be used to confirm transactions in the issuance process.

>;>. j You can still log in for debugging, · 1 ·, 30. If the package is maintained to any extent (for statutory or other purposes), it will

S · I

some existing standard forms should be completed to ensure that it can be accepted and interpreted correctly in the future.

35 As described herein, the format of the PGP key package signed by the phone does not fit into any existing standard. If necessary, standard format 114767 9 could be used and signatures in this format could be required from the SIM card software. The user has control over the PC (physical security) and the corresponding PGP secret key used to perform the 5 functions described herein. The CA operates on a publicly accepted PGP key server that contains all the PGP keys that the CA has signed.

Here, we describe the steps of using the Applicant's S3 system to securely sign a PGP key with a WPKI CA (WPKI, Wireless Public Key Infrastructure) using a user's S3 SIM card to link a signature to an identity proof presented to the local WPKI registration authority. This process is carried out without breaking the anonymity of the user's SIM card network identity. As described herein, the process is stateless at the end of the CA, which reduces complexity and increases the flexibility of the protocol used by the CA.

First, software that uses PGP on a PC will display the name and PGP key fingerprint of the user being certified on the PC screen. In addition, the PC screen • · ·: *. · Prompts you to enter a four-digit number on the mobile phone screen.

·; ··: The fingerprint of the PGP key is encrypted; ** 'j 25 strong hash code on the key. PGP users are accustomed to. ··. key verification by comparing the fingerprints of the keys, this facilitates • PC phone connection verification to be reliable and untouched by an attacker for adding a blur message to 30 phones. The latter may not be necessary ... * for security reasons, as we assume physical security; to the mouth. However, the connection may not be available. * ··. safe.

t I

* The PC software communicates with the phone via '· * * 35 wireless or wired connection or other suitable connection ... and transmits a message packet (TBD) including a command to start the PGP key signing process ίο 114767. The phone generates and displays a four-digit random number along with a prompt to enter this number on the PC if the user wants to sign his PGP key with his phone key.

| 5 The phone displays a four-digit random number, which is then manually entered on the PC keyboard. This will prevent a bold (high probability) attack from a threatening device that might be communicating with your phone, trying to fool it into signing "What's My Name?" message that could be used to compromise the anonymous identity of the NID.

The user then enters a four-digit number from the phone screen into the PC as prompted in 15 ways.

On a PC, the software takes a four-digit random number entered by the user and sends it with a message to be sent to the CA, requesting the (CA) to verify the User ID in response to the 20 NIDs of the phone that signed the request. In other words, "What is my name?" 'request.

The phone compares a random number sent to "What's My Name?" request, and ·; ··· if agreed, warns that it is signing a PGP key with its key.

, ···. The PC displays a lengthy statement of legality used by the client warning that the user is signing his PGP key with the phone key and that the user is only authorized to sign '* 30 under the agreement if he / she is the owner of both. Again, if the random number matched, "What's my name?" message is signed by phone, returned. ···. PCs through serial interface and stored for transmission to CA. The PC software generates another message, *. * '35, which is to be sent to the CA, which message · ... · contains a fingerprint of the key and a request to the CA to sign the attached key if the fingerprint matches. This is "Sign this user ID and key, please." -request. "Sign this user ID and key, please." The message is then forwarded to the phone via a serial interface with 5 requests that the phone sign the packet using the SIM card secret key.

The PGP key fingerprint is displayed on the phone at this point and is verified by the user to be consistent with the PGP key fingerprint on the PC screen. After that, the user is prompted to accept the signature if the fingerprint matches another. The user's phone sends a signed "Sign this user ID and key, please." packet back through the serial interface to the PC [along with the ID of the telephone 15 signer who signed it]. This is stored on the PC for later transmission to the CA. The PC dial-up connection is then redundant and disconnected.

Note that if desired, the process outlined in the few 20 steps described above could be accomplished with only one signed message from the ·, · ·. · Lime. This message would include the fingerprint signature of the PGP key. The message could be used for two different purposes, first to query the CA,. "·. 25" What is my user ID? "And second to · ···. To share it" Sign this key and user ID, 1!. ^ thanks. ". In the first case, the PGP key's fingerprint is discarded because only the NID of the phone is needed to determine what name the CA wants.

30 The PC opens a secure connection (using ... * TLS) to the Certification Authority. The PC sends the SIM signed request to the user ID ("What is the mi · ···. Nun user ID and name?") Over the CA through a secure connection.

V '35 CA checks the phone owner's trusted · database and sends the user ID back to the PC as requested. This is a WPKI-1 1 4767 12 user ID certified by the phone owner with LRA. Sending this information to your PC is not a violation! NID anonymity because the connection is encrypted and the phone owner is the requester.

5 The PC checks to see if the restored WPKI user ID exists in the user's PGP key. If so, the process will automatically proceed to the next step. If the restored WPKI user ID is not in the PGP key, the user ID is added to the PGP key before proceeding.

If a WPKI user ID needs to be added to the PGP key, this point will branch and follow the normal PGP procedure to insert the new ID into the existing key ring. The user must provide 15 email addresses for the user ID because the user ID provided by the CA does not contain an email address.

Because the ultimate result of this process is publishing the signed key on the public key server, the user ID must be self-signed. PGP user IDs are only suitable for publication if they are signed by the key owner.

: ·: Next, the PC uses the user's PGP secret *: ··· key to sign "Sign this key, 25 thanks." request to CA (this request asks CA to al, ···. write down the owner of the phone's PGP key, »). This request was previously signed on the phone's SIM card.

This signature indicates to the CA that the requester 30 is the one who controls the PGP private key component ... * and is not transmitting any other key for certification.

»· ·. ·". PC sends PGP and phone signature »*« man "Sign this user ID and key, thank you." • ta v * 35 - Request TLS connection to CA with matching PGP key Again, this package links the phone owner's (presumably anonymous) NID 13 1 U767 to a public PGP identity, in which case the channel must be encrypted.

The CA verifies the PGP signature. The CA checks the phone key. The CA then checks its trusted 5 database to the phone that signed "Sign this key, kit." request associated ID. The provided PGP user ID (name part) must be compatible with the CA phone user name. That's because we just added the user-10 ID that the CA returned to this NID in the PGP key that was attached to the message.

If the supplied user ID for this phone is not found in the CA confidential database, the request is blocked and an error message is sent back to 15 PCs. For recovery purposes, this error message may contain the correct user ID because we are operating on an encrypted channel. The user is informed of the problem by an error message displayed on the PC. If the name portion of the user ID matches, then the CA signs the PGP key with the 20 CA keys and discards "Sign this key, thank you." request to your phone's NID. It will then add this information to the confidential database. The PGP key written by the CA al- • / .j is added to the "Searchable PGP ·; ··: Certificates" database by the CA.

25 The CA then sends the email to the CA, ···. to the e-mail address of the PGP key written to, ·· *. the user specified in the user ID that the CA * * signed. This provides a check that the email address is correct. This certificate is encrypted with the public encryption key of that user. This way ... * I can, if the email address is wrong and the key is misrepresented, it is likely that no one will ever. · · ·. opens.

The CA assumes that the user will open and reload the signed key to the CA, thereby addressing that the e-mail address was correct and the person at the end of the e-mail address will be able to use the key to decrypt the password. When the CA retrieves this key from the user, the CA removes it from the database of retrievable PGP certificates. To eliminate email delivery problems, the CA periodically repeats the previous 5 steps until the user responds or until the CA decides to release.

When the CA retrieves the key from the user, the CA publishes the received signed PGP key on its PGP key server. The PGP key is, of course, signed with a user ID verified only by the LRA.

None of the other user IDs that the user may have in their PGP key will be signed by the CA. Also note that the phone's NID is not part of the PGP key and is not published with the PGP key, 15 whereby we still strongly protect the anonymity associated with the user's NID.

Figure 2 illustrates an example of a flow chart of the present invention. First, the need for additional data is verified, step 21. The additional data may be a current and previously issued certificate or other information such as a name or email address of the user.

If additional information is required, the user provides it, step • ♦ 22. Then, an identification request is sent to register - *: ··· the notifying authority CA, step 23. According to the identity information, the existence of previous identities. ···. check, step 24. This search can be done in register ·· 1. in the private databases of the Authority or in the databases of other authorities. If any previous identity is found, a response is generated [30 and transmitted to the specified terminal, step 26.

If no previous identities are found, · /; 1; information is requested from the user.

. ··. If the user accepts the response, he or she digitally signs it and sends it back to the V.1 35 registration authority, steps 27 and 28. If additional guarantees are required, they can be requested from the appropriate authorities, steps 29 and 210. Finally, the confirmed 15 114767 identity information is sent to the specified to the recipient, step 211.

Figure 3 shows an example of a certificate according to the present invention. The certificate contains a set of information that is required for identification. Typically such information is certificate identification number, user name, user email address, RSA / DSS keys, signature or certificate fingerprint, password hash, al-10 signature, and certificate expiration date.

The foregoing description of preferred embodiments is provided to enable one skilled in the art to make or use the invention. Various modifications to these applications will be readily apparent to those skilled in the art, and the general principles set forth herein may be applied to other applications without inventing anything new. Accordingly, the present invention is not intended to be limited to the applications disclosed herein, but to the broadest scope of the principles and novel features set forth herein. 1 i I t «· M ·

Claims (26)

A method for granting an electronic identity to an entity from an identity registration authority, characterized in that the method comprises the following steps: a) a first electronic identity is granted to the entity; b) creating a request for a second electronic identity for the entity, which request includes an identification of the entity; c) the request is sent to the identity registration authority; d) in response to the request, an identification response is created; E) the identification response is sent to the entity; f) the acceptability of the identifier response is verified in the entity; g) in response to the verification, if the identification response is acceptable, the identification response is digitally signed in the first entity; h) the signed response is sent to the identity Vj: the registration authority; i) the validity of the digital signature and (In the identification response is verified in the signed reply, * ··, 25; and »·, ···, j) in response to the verification, if it digits. ! speak the signature and the identification response is valid, a second identity is granted on the basis of the first identity. i ♦ »:. * 30 A method according to claim 1, characterized in that the method comprises a second entity with which the first entity digitally signs the identification response. i t. A method according to claim 1 or 2, 1 *, characterized in that the method further comprises the following steps: examining if information of the other entity is available using the identification; and in response to the review, if information is not available, information is requested from the second entity from the first entity. Method according to claim 2 or 3, characterized in that the second entity is controlled by the first entity. 10 5. A method according to claim 3, characterized in that the information of the second entity comprises one or more of an amount containing a unique address of the second identity, the name of the holder of the second entity and the previous identity or identities. of the other entity. A method according to claim 1, characterized in that: a telecommunication channel is formed and encrypted between the first entity and the identity registration authority to ensure a secure connection between them. · V A method according to claim 1, characterized in that: *: '': the second identity granted is stored in the database of the identity registration authority. 8. A method according to claim 1, characterized in that: • the second identity granted is stored in the database of the first electronic identity grantor. ♦ · a 9. A method as claimed in claim 1, characterized in that: the first and second electronic identities are combined to form a combined electrical system. Identity; and * * a '>' 'the combined electronic identity is stored in the database. 114767 The method of claim 1, characterized in that: the second identity granted is transmitted to the entity. 5 The method according to claim 1, characterized in that: the second identity granted is sent to a third party. 12. The method of claim 1, -10 may be characterized by the fact that, prior to the step of granting the second identity, it is: reviewed if additional security is required to ensure the validity of the first identity; and 15 in response to the audit, if additional security is required, additional security is requested. 13. A method according to claim 1, characterized in that: a timestamp is added to the granted second identity; and the timestamped second identity is stored in the identity registration authority's database. • "V." 14. A method according to claim 1, characterized in that: *: **: 25 an expiry date for the second electronic identity is added to the timestamp. f · ». ···. The method of claim 1, characterized in, ···. characterized in that: • a notarization is added to the second granted identity; and * · · • · 'the notarized second identity is stored in the database of the registration authority. The method according to claim 1, characterized in that: an additional identification code is requested in order to add the signed identification response; The identification code is received at the registration authority; and the validity of the identification code is verified by the registration authority. 5 17. A method according to claim 16, characterized in that the identification code comprises one or more of an amount containing the first entity's biometric code, a predetermined string of characters, a fingerprint of the entity's public key, a random number, a certificate and a hash code of the shared secret between the first entity and the registry. 18. A method according to claim 1, characterized in that: a first hash code is created from the identity request at the registration authority; the first hash code is sent to the second entity; a second hash code is created from the identity request with the second entity; and the validity of the first hash code is verified by comparing it with the second hash code · before signing the response. : 'j The method of claim 1 or 2; Characterized in that, prior to granting, a confirmation message is sent to the address • ·, ··, as defined in the entity's additional information; · The acknowledgment response to the confirmation message * 1 is received by the registration authority; and the validity of the confirmation response is verified. ; · 1 20. A method according to claim 19, characterized in that, further before granting:, the granting of the second electronic identity is canceled if the confirmation response is not received:: within a pre-authorization fixed period of time. »1 1 4767 21. A method according to claim 1, characterized in that the request for granting a second certificate to the entity is initiated by a third party. 5 The method according to claim 1, characterized in that the request for granting a second certificate to the entity is initiated with the second entity. The method according to claim 2, characterized in that the request is digitally signed with the first entity before the request is sent. 24. A method according to claim 2, characterized in that the request is encrypted before it is transmitted. 15 25. A method according to claim 1, characterized in that, further in the process: the log of all transactions is logged during the granting process of the second electronic identity. Method according to claim 2, characterized in that the second entity is one of the following in an amount containing a mobile terminal, a mobile telephone, a personal computer, a set-top box. , an intelligent card, a secure device, a security card, a software agent, a pager, III, ··>, a terminal and a personal digital auxiliary device (PDA). I · i I I * 4> t »* - I» · »I I · • i · t t 1