NO336856B1 - Data transfer method and system - Google Patents

Abstract

A verification system (200) and a method for enabling the profits of a wireless telecommunications and data communications network (100) for a card issuer (118) are described. The verification system is based on open, standardized interfaces. When a digital signature has been formed on a smart card (102) in a mobile device (104), the digital signature is encrypted with / by a key belonging to the card issuer before the signature leaves the smart card. The encrypted signature is sent / transmitted to the signature receiver (112) in the same way as if it had not been encrypted by the card issuer's key. The signature receiver transfers the signature to the card issuer after this. The card issuer decrypts the signature, debits the signature recipient, and transfers the decrypted signature to the signature recipient. After this, the signature receiver can check the digital signature.

Description

The position of the technique

The present invention relates to a system and a method for enabling profit for a card issuer in a system by a wireless telecommunications and data communication network, which is based on open, standardized interfaces. More specifically, the invention relates to a verification system and method for verifying signatures on a smart card, where the verification system comprises at least one mobile terminal with at least one card reader for at least one smart card, at least one signature receiver and at least one card issuing server, where the smart card/mobile terminal is in connection with the signature receiver via at least a mobile communication network which in turn is connected to the card issuing server, where a signature is first created in the smart card, that in the next step the signature is encrypted, and that the decrypted signature is evaluated/checked in the signature receiver.

Known technique

In recent times, there are systems for creating digital signatures using mobile phones based on keys for so-called smart cards in the mobile phone and PKI (Public Key Infrastructure). There are two main ways to realize these procedures, on the one hand a solution based on SIM application tools combined with an OTA platform (OTA=Over The Air) and on the other hand a solution based on WIM (Wireless Application Module).

In the first solution, the card issuer, which is the mobile phone operator, has full control over the signing process and all communication is carried out via the operator's OTA platform. In this way, the operator has every opportunity to invoice participants (i.e. service providers, for example banks) who want to use the signature function. For the same reason, the operator has the option of invoicing a CA (Certificate Authority) who will issue a certificate based on keys on the smart card. The disadvantage of this solution is that it is not standardized.

In the latter solution, the interfaces are standardized by the WAP (Wireless Application Protocol) forum and are often considered to be the solution that will be most successful. Here, the interfaces are standardized, and the operator is transparent in terms of communication to participants who want to use the signing function. This implies that the card issuer currently has no technical possibility to invoice participants who use the signing function. There are also possibilities for a CA to issue a certificate based on keys on the smart card without the card issuer's knowledge, and therefore profits associated with this are also not protected by the card issuer.

The current system for protecting the card issuer's profits through digital signatures is based on the fact that the communication between the smart card in the mobile phone and the service provider/CA is carried out via some form of operator gateway, where billing data is generated (often based on so-called SAT technology (SIM Application Toolkit ) + OTA platform).

The solution that exists today to try to protect CA profits is to charge for cancellation information. Such a solution is based on CA = card issuer and does not work from a business point of view for systems where the CA and the card issuer are different parties. When a party is interested in validating/verifying a signature, that party turns to the CA for revocation information, and not the card issuer, so the card issuer has trouble getting any profit for the signatures being formed with/by his card. It is true that the CA has often based its certificates on the card issuer's device certificate (which usually informs which party has generated/issued the card, generated key etc), but these are never canceled in practice, so that the card issuer can hardly base its business on cancellation information for device certificates.

GB 2375872 A describes a verification system for verifying signatures on a smart card, where the verification system comprises a mobile terminal with a card reader for one smart card, a signature receiver and a server for issuing a card.

WO 98/52151 A1 describes a method for electronic transaction.

US 2002/0032860 shows a system in which an encrypted digital signature is sent from a customer via a dealer to a financial institution. The financial institution decrypts the signature and transmits the decrypted signature (+ account information) to the retailer.

WO 99/00775 shows a payment system. In a terminal is a "smart card". Between the terminal and an "acquirer" is a two-way communication channel. This two-way communication channel connects the card issuer with the "acquirer", where the "acquirer" acts as an agent for the majority of card issuers and can be, for example, a bank. One way is that the PIN code is encrypted and is transferred via an "acquirer" to the card issuer. The "acquirer" cannot decrypt the PIN code.

WO 01/45056 discloses a system for performing card transactions. The buyer's computer generates an encryption number, which at least to a certain extent/part corresponds to the card number. The encryption number is given to a handler who forwards it to the card issuer, where the associated computer can decrypt the number. The identification of the buyer is done via a separate link from the buyer to the card issuer.

WO 00/79724 discloses a WIM card comprising the card manufacturer's private key. The certificate is then signed. Verification of the signature is done by the card issuer.

US 2002/00056079 shows a method for loading an application onto a "smart card". The one providing the application (the service provider) cannot decrypt "card attribute data", but must pass this (and the ID for the application) on to the card issuer. The card issuer decrypts "card attribute data" and identifies the card. The card issuer then decides whether or not to allow the loading of the application and informs the service provider accordingly.

WO 01/22374 shows a method and system for secure payment. The idea behind the procedure is that the card issuer is responsible for "authentication" of the card owner/holder and "authentication" of the card purchase. In the case of a purchase, a request/recommendation for payment is transferred from the merchant to the cardholder. The cardholder opens a link to the card issuer, (authenticated by the card issuer), and transfers information about the purchase and the merchant via the link to the card issuer. The card issuer responds by transferring payment information to the merchant via the cardholder's computer. The merchant's computer confirms the purchase. The card issuer confirms the payment when the cardholder has been authenticated. All data transmitted is decrypted.

The cardholder's computer can be a mobile phone. The card issuer has control over the information flow to the cardholder during the transfer of payments.

BRIEF DESCRIPTION OF THE INVENTION

The present invention relates to a system and a method for creating digital signatures using a mobile phone, where the system is based on keys in so-called smart cards in a mobile phone and PKI.

Preferred embodiments of the invention are specified in the independent claims, while alternative embodiments are specified in respective non-independent claims.

Today's system for protecting card issuer profits through digital signatures is based on the communication between the smart card in the mobile phone and the service provider being carried out via some form of operator interface where debit data is generated. The invention results in a standardized system with open solutions being used instead, i.e. holistic interaction between the service provider and the user.

A characteristic feature of the invention is that when a digital signature has been formed on a smart card in a mobile device, the digital signature is encrypted (not the signed amount of data) with/by a key belonging to the card issuer before the signature leaves the smart card. The encrypted signature is sent/transmitted to the recipient in the same way as if it had not been encrypted by/with the card issuer's key. The recipient sends the signature to the card issuer, who is the only one who can decrypt the signature. The card issuer decrypts signatures, charges the signature receiver and sends the decrypted signature to the signature receiver. The signature recipient can only evaluate/check the decrypted signature after this.

An advantage of/of the invention is that verification of the digital signature is carried out in a standardized system with open solutions, i.e. comprehensive interaction between service provider/CA and user.

Another advantage of the invention is that the digital signature is encrypted after it has been formed, so that only the card issuer can decrypt it.

BRIEF DESCRIPTION OF THE FIGURES

The invention will now be described in more detail in the following with reference to the attached figures, in which

Figure 1 shows an investigation of a mobile system that verifies signatures on smart cards. Figure 2 shows the verification system/systems for how a digital signature can be verified. Figure 3 shows a signal diagram for how the signature can be verified. Figure 4 shows a flow diagram for how the signature is verified.

DESCRIPTION OF PREFERRED EMBODIMENTS

The invention is aimed at protecting the card issuer's profits for systems based on WIM, or other future systems with open interfaces.

Figure 1 shows an examination of a system 100 for mobile communication, where the mobile system can verify signatures on smart cards. The mobile system 100 comprises a smart card SK 102 which comprises/includes a function A to form a digital signature DS on a data quantity, and a function B which encrypts the digital signature by/with a card issuer's key KN and obtains an encrypted digital signature. A mobile terminal ME 104 with a card reader where the smart card is placed. A mobile communication network 106, by which communication between the mobile terminal/smart card and a signature receiver SM 112 is carried out. The mobile communication network typically comprises base stations, transmission, exchanges and databases. The mobile communication network can also be a short-range communication network (based on, for example, Blue Tooth). A gateway or proxy 108, which connects the mobile communication network with an Internet 110. The Internet (data communication network) is used for communication between the mobile terminal/smart card and the signature receiver. Such a data communication network can also be used for communication between the signature receiver and a card issuing server 118. There are also two main types of signature receivers: Authority for Certificate 116 (certificate issuer) or a Service provider 116 (service provider). At/with these there are various servers and databases/directories. From the signature receiver, the encrypted digital signatures are sent to the card issuing server. The card issuing server decrypts the digital signatures and then returns the digital signatures to the signature recipient.

Figure 2 shows a verification system 200 for how a signature can be verified, and Figure 3 shows a signal diagram of how the signature can be verified. The signal diagram shows examples of the type of signal processing used between the various units in the verification system. Included in the verification system is a smart card module SKM 202 for forming digital signatures (WIM), a mobile terminal 104, a type of mobile communication network ME 106, for example GSM + possible WAP gateway, the signature receiver SM 112 and card issuer KU 210 which provides the card issuer server 118.

The following communication can be carried out between the various units:

Step 1: The signature receiver SM 112 sends 302 a signing request to the mobile terminal ME 104.

Step 2: The mobile terminal ME 104 takes care of the signing request. After this, the mobile terminal ME 304 requests that a smart card module SKM 202 should form a digital signature.

Step 3: The smart card module SKM 202 uses function A, which forms a digital signature DS and function B, which encrypts the digital signature and will then have an encrypted digital signature KDS. After this, the encrypted digital signature is sent 306 to the mobile terminal ME 104.

Step 4: The mobile terminal ME 104 transmits 308 with the encrypted digital signature KDS to the signature receiver SM 112.

Step 5: The signature receiver SM 112 forwards 310 the encrypted digital signature KDS to a card issuer KU 210.

Step 6: The card issuer KU 210 decrypts the encrypted digital signature KDS and obtains a decrypted digital signature DDS, debits the signature receiver for this, and transmits 312 the decrypted signature to the signature receiver 112.

Figure 4 shows a flowchart 400 of how the signature is verified, as a result of which is a more detailed method than previously described.

The service provider 116, which is also the signature recipient SM 112, transmits 402 a signing request to the user's mobile terminal ME 104, which for example includes/includes the data to be signed.

The mobile terminal ME 104 starts 404 a dialog with a user. The user decides 406 to sign the content and enters 408 information (typically a PIN code) required to unlock the signing key SN. The mobile terminal requests 410 that the smart card module SKM 202 should create a digital signature DS for the content, by one of the private keys PN for signing on the card.

Function A forms 412 a digital signature DS for the contents of the smart card module SKM 202. Function B encrypts 414 the digital signature DS by the card issuer's key KN. After this, the encrypted digital signature KDS is transferred 416 to the mobile terminal ME 104.

The mobile terminal ME 104 formats/forms 418 a response to the signature request and attaches 420 the encrypted digital signature KDS to the signature receiver SM 112. Information about which party the card issuer is is also attached.

The signature receiver SM 112 transfers 422 the encrypted digital signature KDS to the card issuer KU 210.

The card issuer KU 210 decrypts 424 the encrypted signature, debits 426 the signature receiver SM 112 for this, and transfers 428 the decrypted digital signature DDS to the signature receiver SM 112.

The invention is not limited to use with a/any specific protocol(s) or frames, but since it is in the first phase expected to be used together with WIM and WPKI according to the WAP forum, here follows a (somewhat simplified of steps 1-5) description of how this case might look: The service provider transfers a signing request to the user's mobile terminal using the "signText" function. A description of "signText" can be found in "WMLScript Crypto Library" WAP-161-WMLScriptCrypto-20010620-a, WAP Forum.

The mobile terminal initiates a dialogue with the user, and the user decides to sign the content and enters information (usually a PIN code) required to unlock the signing key. The mobile terminal requests the WIM to generate a digital signature for the content by sending the "Compute Digital Signature" command to the WIM, see "Wireless Identity Module" WAP-260-WIM-20010712-a, WAP Forum.

The WIM application creates a signature for/to the content. An additional function on the smart card encrypts the signature with/by the card issuer's key. After this, the encrypted signature is transferred to the mobile terminal in the command response to "Compute Digital Signature".

The mobile terminal formats/forms a result of "signText", where the encrypted signature is attached as the "Signature" object. A certificate or certificate ULR is also added, where the certificate includes additional information about which party the card issuer is. The result of "signText" is transferred from the mobile terminal to the signature recipient. The signature receiver transfers the encrypted signature to the card issuer.

The card issuer decrypts the signature, charges the signature receiver for this, and transfers the decrypted signature to the signature receiver.

Note that only the signature, not the signed content, is encrypted in step 3, and is transmitted to the card issuer in step 5. Because the signature is based on a one-way function of the signed content, it is insensitive information from a security point of view, even whether the signed content is confidential.

The recipient of the signature must be told that the signature is encrypted, and where to go to get it decrypted. The best way is probably to let the information exist explicitly or implicitly in the user or device certificate (sometimes a URL is passed instead pointing to the certificate) which, according to step 4, is passed to the service provider, even if there are other possibilities.

An important characteristic of the invention is that it can probably be used for WAP (WIM, signtext) without changes in the mobile terminal or WAP GW, where the encrypted signature is transmitted transparently as an unencrypted signature. The adaptations are made in the WIM (however not in the interface to the mobile terminal) and in the origin server/PKI portal (however not in the interface to the WAP

GW).

The method can be used with symmetric and asymmetric card issuer encryption of the digital signature. In the symmetric case, the secret key, which has been placed on the smart card to encrypt the signatures, is known only to the card issuer. In the asymmetric case, the signature is encrypted by a public key, and a corresponding private key is only known by the card issuer.

Note that one card issuer key per card should be used, and not one card issuer key for multiple cards. This is to minimize the damage if the key becomes known.

One possible variant of the procedure is for a service provider/signature recipient to purchase "permanent" access to the card issuer key for certain cards, and is allowed to use it in an agreement. In that case, the communication with the card issuer in steps 5 and 6 is not needed for each signature.

The method can also be used where digital signatures formed on a smart card are used in any step to form secure data transport, for example WTLS (Wireless Transport Layer Security) or SSL (Secure Sockets Layer). In the WTLS case, this may imply that the response to Sign H (handshake msg) will be encrypted with/by the card issuer's key, whereby it is transmitted to the server in "Certificate verify", whereby the server must transmit the contents of "Certificate verify" to the card issuer to have the signature decrypted.

It may also be possible to apply the method in corresponding non-mobile connections to protect card issuer profits.

Example 1

It is operator that issues SIM with WIM (SWIM), which also points to a device certificate (SWIM does not hold the public key) with RSA keys. The operator's idea is partly based on the principle that the party that wants to issue a certificate based on keys on SWIM must pay a fee to the operator for this. One way of doing this is for the operator to create a database of device certificates and charge the person who requests a device certificate as a basis for creating a user certificate. In principle, anyone can issue a user certificate if the present invention is not used. In the proposed approach, two signatures are requested from users (that way the public key can be calculated and device certificate is not required). The invention prevents this by only allowing parties who have agreements with the operator to have signatures encrypted. The operator can then charge a small sum for each signature that has been created, as such is a business opportunity. This in turn enables the operator to allow external CA (Certificate Authority) to issue "public" certificates (public in this context means that the user will have full access to his/her certificate and it is associated with an official CPS etc), without it is, for that reason, uninteresting for other parties to issue certificates for the same user connected to the same SWIM.

Example 2

The operator issues SIM with WIM (SWIM) and the operator issues "public" user certificates to the holder of SWIM (public in this context means that the user will have full access to his/her certificate and it is associated with an official CPS etc). With the help of the invention, the operator can get the opportunity to create a profit with each signature that is formed with the help of the SWIM.

Claims (19)

1. Verification system (200) for verifying signatures on a smart card (102, 202), where the verification system comprises at least one mobile terminal (104) with at least one card reader for at least one smart card (102, 202), at least one signature receiver (112) and at least one card issuing server (118, where the smart card/mobile terminal is in connection with the signature receiver via at least one mobile communication network (106) which in turn is in connection with the card issuing server, that a signature is first formed (412) in the smart card, that in the next step the signature encrypted (414), and that the decrypted signature is evaluated/checked in the signature receiver, characterized in that the encrypted signature is transferred (306, 416, 308, 420, 310, 422) to the card issuing server via the mobile terminal and the signature receiver, that the signature is decrypted (424) in the card issuing server, after which the decrypted signature is returned (312, 428) to the signature recipient. 2. Verification system in accordance with claim 1, characterized in that the mobile communication network comprises base stations, transmission, exchanges and databases. 3. Verification system in accordance with claim 1, characterized in that the mobile communication network is a short-distance communication network. 4. Verification system in accordance with claims 1-3, characterized in that between the mobile communication network and the signature receiver there is a gateway (108) and a data communication network (110) which are connected to each other. 5. Verification system in accordance with claim 4, characterized in that the data communication network is used for communication between the mobile terminal/smart card and the signature receiver. 6. Verification system in accordance with one of the preceding requirements, characterized in that the signature recipient is the certificate issuer (114). 7. Verification system in accordance with claims 1-5, characterized in that the signature recipient is a service provider (116). 8. Method (200, 300, 400) for verifying signatures on a smart card comprising a verification system (100) comprising at least one mobile terminal (104) with at least one card reader for at least one smart card (102, 202), at least one signature receiver (112 ) and at least one card issuing server (118), where the smart card/mobile terminal is in connection with the signature receiver via at least one mobile communication network (106) which in turn is in connection with the card issuing server, and that the method comprises forming (412) a signature, as well as encrypting (414) the signature in the smart card and evaluating /checking the decrypted signature in the signature receiver, characterized by transmitting (306, 416, 308, 420, 310, 422) the encrypted signature to the card issuing server via the mobile terminal and the signature receiver, decrypting (424) the signature, and returning (312, 428) the decrypted the signature of the signature receiver, where these steps of the method are performed in the card issuing server. 9. Method in accordance with claim 8, characterized in that before a signature is formed, the method comprises a first step: transmitting (302, 402) a signing/signature request from the signature receiver to the mobile terminal. 10. Method in accordance with claim 8, characterized in that before the step of creating a signature in the mobile terminal, the method comprises a second step: processing the signing request, and requesting (304, 404) that the smart card should create a signature. 11. Method in accordance with claim 8, characterized in that in the step of creating a signature, the method comprises a third step: using a function A to create (412) a digital signature, using a function B in the step of encrypting the signature in order to encrypting (414) the digital signature, and after this transmitting (306, 416) the encrypted digital signature to the mobile terminal. 12. Method in accordance with claim 8, characterized in that after the step of encrypting the signature, the method comprises a fourth step: transferring (308, 420) the encrypted signature from the mobile terminal to the signature receiver. 13. Method in accordance with claim 8, characterized in that after the step of encrypting the signature, the method comprises a fifth step: transferring (310, 422) the encrypted digital signature from the signature receiver to the card issuing server. 14. Method in accordance with claim 8, characterized in that in the step of decrypting the encrypted signature, the method comprises a sixth step: decrypting (424) the encrypted digital signature, debiting (426) the signature receiver for this and transferring (312, 428) the decrypted digital signature of the signature recipient. 15. Method according to claim 10, characterized in that the second step in the method comprises starting (404) a dialogue with a user, and that the user determines (406) a PIN code to unlock the signing key SN, and to request (310, 410) that the smart card should form the digital signature at one of the private keys for signing on the card. 16. Method in accordance with claim 11, characterized in that in function B the digital signature is encrypted (414) with/by the card issuer's key. 17. Method in accordance with claim 12, characterized in that the fourth step in the method includes the mobile terminal formatting/forming (418) a response to the signature request and attaching (308, 420) the encrypted digital signature and information about which party the card issuer is. 18. Computer program, comprising program steps for performing the steps in the method according to one of claims 8-17. 19. Computer with readable memory, comprising instructions for carrying out the steps in the method according to one of claims 8-17.