WO2004057547A1 - Method and system for transmission of data - Google Patents

Method and system for transmission of data Download PDF

Info

Publication number
WO2004057547A1
WO2004057547A1 PCT/SE2003/001980 SE0301980W WO2004057547A1 WO 2004057547 A1 WO2004057547 A1 WO 2004057547A1 SE 0301980 W SE0301980 W SE 0301980W WO 2004057547 A1 WO2004057547 A1 WO 2004057547A1
Authority
WO
WIPO (PCT)
Prior art keywords
signature
smart card
receiver
card
procedure
Prior art date
Application number
PCT/SE2003/001980
Other languages
French (fr)
Inventor
Jonas Eriksson
Rolf KÅWE
Original Assignee
Telia Ab (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telia Ab (Publ) filed Critical Telia Ab (Publ)
Priority to AU2003288840A priority Critical patent/AU2003288840A1/en
Priority to EP03781215A priority patent/EP1579396A1/en
Publication of WO2004057547A1 publication Critical patent/WO2004057547A1/en
Priority to NO20051700A priority patent/NO336856B1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/126Applying verification of the received information the source of the received data
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409Device specific authentication in transaction processing
    • G06Q20/4097Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08Access security
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10Integrity

Definitions

  • the present invention relates to a system and a method to, at a wireless telecommunication and data communication network, make earnings possible for a card issuer in a system which is based on open, standardized interfaces.
  • the card issuer which is the mobile telephone operator, has full control over the signing process and all communication is executed via the operator's OTA-platform.
  • the operator has all possibilities to charge participants (that is, service providers, for instance banks) which want to use the signature function.
  • the operator has for the same reason possibility to charge a CA (Certificate Authority) which wants to issue certificate based on keys on the smart card.
  • CA Certificate Authority
  • the interfaces are standardized by WAP (Wireless Application Protocol) forum and is often considered to be the solution which will be the most successful.
  • WAP Wireless Application Protocol
  • the interfaces are standardized, and the operator is transparent in communication sense to the participants which want to use the signing function.
  • the card issuer to-day has no technical possibility to charge participants which are using the signing function.
  • CA CA to issue certificate based on keys on the smart card, without the card issuer's knowledge, and therefore neither earnings related to this are secured by the card issuer.
  • To-day's system to secure card issuer earnings at digital signatures is based on that the communication between the smart card in the mobile telephone and the service provider/CA is executed via some form of operator gateway, where billing data is generated (frequently based on so called SAT-technology (SIM Application Toolkit) + OTA platform) .
  • SAT-technology SIM Application Toolkit + OTA platform
  • CA card issuer
  • CA card issuer
  • US " 2002/0032860 shows a system in which an encrypted digital signature is transmitted from a customer, via a tradesman, to a financial institution.
  • the financial institution decrypts the signature and transmits the decrypted signature (+ account information) to the tradesman .
  • WO 99/00775 shows a system for payment.
  • a terminal is a "smart card”.
  • an "acquirer” there 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, for instance, be a bank.
  • a PIN-code is encrypted and is transmitted via an "acquirer” to the card issuer.
  • the "acquirer” can not decrypt the PIN-code.
  • WO 01/45056 shows a system to perform card transactions.
  • the buyer's computer creates an encrypting number, which at least to some extent/part agrees with the card number.
  • the encrypted number is given to a tradesman who forwards it to the card issuer, the computer of which can decrypt, the number.
  • Identification of the buyer is made via a separate link from the buyer to the card issuer.
  • WO 00/79724 shows a WIM-card containing the card manufacturer's private key. By this, certificate is signed. Verification of the signature is made by the card issuer.
  • US 2002/00056079 shows a method to load an application on a "smart card".
  • the one which provides the application (the service provider) cannot decrypt "card attribute data", but has to transmit these (and ID for the application) further to the card issuer.
  • the card issuer decrypts "card attribute data” and identifies the card.
  • the card issuer decides if the loading of the application shall be allowed or not, and informs about this to the service provider.
  • WO 01/22374 shows a method and system for secure payment. The idea of the method is that the card issuer is responsible for "authentication" of the card owner/holder and "authorization" of the card purchase. At a purchase an inquiry/request about payment is transmitted from the tradesman to the card holder.
  • the card holder opens a link to the card issuer, (authenticated by the card issuer) , and transmits information about the purchase and the tradesman via the link to the card issuer.
  • the card issuer answers/ responds by transmitting payment information to the tradesman via the cardholder's computer.
  • the tradesman's computer confirms the purchase.
  • the card issuer confirms the payment when the card holder has been authenticated. All data which are transmitted are decrypted.
  • the cardholder's computer can be a mobile telephone.
  • the card issuer has control over the information flow to the card holder during the transfer of the payments.
  • the present invention relates to a system and a method to create digital signatures by means of a mobile telephone, which system is based on keys in so called smart cards in a mobile telephone and PKI .
  • Today's system for securing card issuer earnings at digital signatures is based on that the communication between the smart card in the mobile telephone and the service provider is executed via some form of operator interface where the debiting data is generated.
  • the invention results in that a standardized system with open solutions instead can be used, that is, in the whole interaction between the service provider and the user.
  • a distinctive feature of the invention is that when a digital signature has been created on a smart card in a mobile unit, the digital signature is encrypted (not the signed amount of data) with/by a key which belongs to the card issuer before the signature leaves the smart card.
  • the encrypted signature is transmitted/transferred to the receiver in the same way as if it had not been encrypted by /with the card issuer's key.
  • the receiver transmits the signature to the card issuer, which is the only one that can decrypt the signature.
  • the card issuer decrypts the signature, debits the signature receiver and transmits the decrypted signature to the signature receiver. Only after that, the signature receiver can evaluate/check the decrypted signature.
  • One advantage with/of the invention is that verification of the digital signature is made in a standardized system with open solutions, that is, in the whole interaction between service provider/CA and user.
  • Another advantage with/of the invention is that the digital signature is encrypted after it has been created, so that only the card issuer can decrypt it.
  • FIG. 1 shows a survey of a mobile system which verifies signatures on smart cards
  • Figure 2 shows verification system/systems of how a digital signature can be verified
  • Figure 3 shows a signal diagram of how the signature can be verified
  • Figure 4 shows a flow chart of how the signature is verified.
  • the invention aims at securing the card issuer's earnings for systems which are based on WIM or other future systems with open interfaces.
  • FIG. 1 shows a survey of a system 100 for mobile communication, the mobile system, which can verify signatures on smart cards .
  • the mobile system 100 consists of a smart card SK 102 which contains/includes a function A. to create a digital signature DS on an amount of data, and a function B which encrypts the digital signature by/with a card issuer's key KN and gets an encrypted digital signature.
  • a mobile communication network 106 via which communication between mobile terminal/smart card and a signature receiver SM 112 is executed.
  • the mobile communication network includes typically base stations, transmission, exchanges and databases.
  • the mobile communication network also can be a short distance communication network (based on, for instance, Blue Tooth) .
  • a gateway or proxy 108 which connects the mobile communication network with an Internet 110.
  • Internet data communication network
  • Such a data communication network also can be used for communication between the signature receiver and a card issuer server 118.
  • Certificate Authority 114 certificate-issuer
  • Service Provider 116 service- provider
  • Figure 2 shows a verification system 200 of how a signature can be verified
  • Figure 3 shows a signal diagram 300 over how the signature can be verified.
  • the signal diagram shows examples of which type of signal management that is applied between the different units in the verification system.
  • a smart card module SKM 202 to create digital signatures (WIM)
  • WIM digital signatures
  • ME 106 some type of mobile communication network ME 106, for instance GSM + possible WAP-gateway
  • the signature receiver SM 112 the signature receiver SM 112
  • card issuer KU 210 which provides the card issuer server 118.
  • Step 1 The signature receiver SM 112 transmits 302 a signing enquiry/request to the mobile terminal ME 104.
  • Step 2 The mobile terminal ME 104 attends to the signing enquiry/request. After that, the mobile terminal ME request 304 that a smart card module SKM 202 shall create a digital signature.
  • Step 3 The smart card module SKM 202 makes use of the function A, which creates a digital signature DS and the function B, which encrypts the digital signature and then will have an encrypted digital signature KDS . After that, the encrypted digital signature is transmitted 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 6 The card issuer KU 210 decrypts the encrypted digital signature KDS and gets a decrypted digital signature DDS, debits the signature receiver for this, and transmits 312 the decrypted signature to the signature receiver 112.
  • FIG 4 a flow chart 400 over how the signature is verified is shown, consequently a more detailed procedure than has earlier been described.
  • the service provider 116 which also is the signature receiver SM 112, transmits 402 a signing enquiry/request to the user' s mobile terminal ME 104, which, for instance, includes/contains the data which shall 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 (most often a PIN-code) which is required to unlock the signing key SN .
  • the mobile terminal requests 410 that the smart card module SKM 202 shall create a digital signature DS for the content, by one of the private keys PN for signing on the card.
  • the function A creates 412 a digital signature DS for the content in the smart card module SKM 202.
  • the function B encrypts 414 the digital signature DS by the card issuer's key KN . After that, the encrypted digital signature KDS is transmitted 416 to the mobile terminal ME 104.
  • the mobile terminal ME 104 formats/creates 418 an answer to the signature inquiry/request and encloses 420 the encrypted digital signature KDS to the signature receiver SM 112. Information about which party the card issuer is, is also enclosed.
  • the signature receiver SM 112 transmits 422 the encrypted digital signature KDS to the card issuer KU 210.
  • the card issuer KU 210 decrypts 424 the encrypted digital signature, debits 426 the signature receiver SM 112 for this, and transmits 428 the decrypted digital signature DDS to the signature receiver SM 112.
  • the invention is not limited to use with any/some specific protocols or frameworks, but since it is in the first phase is expected to be used together with WIM and WPKI according to WAP forum, here follows a (somewhat simplified of the steps 1-5) description of what this case can look like:
  • the service provider transmits a signing inquiry/ request to the user's mobile terminal by means of the function "signText".
  • a description of "signText” is to be found in "WMLScript Crypto Library” WAP-161- WMLScriptCrypto-20010620-a, WAP forum.
  • the mobile terminal starts a dialog towards the user, and the user decides to sign the content and enters information (most often a PIN-code) which is required to unlock the signing key.
  • the mobile terminal request that WIM shall create a digital signature for the content by transmitting the command "Compute Digital Signature" to
  • 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 that, the encrypted signature is transmitted to the mobile terminal in the command answer to "Compute Digital Signature" .
  • the mobile terminal formats/creates a result of
  • signalText where the encrypted signature is enclosed as the object "Signature”.
  • a certificate or a certificate-ULR is also added, where the certificate includes additional information about which party the card issuer is.
  • the result of "signText” is transmitted from the mobile terminal to the signature receiver.
  • the signature receiver transmits the encrypted signature to the card issuer.
  • the card issuer decrypts the signature, debits the signature receiver for this, and transmits the decrypted signature to the signature receiver.
  • Step 5 Note that it is only the signature, not the signed content, that is encrypted in Step 3, and which 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 if the signed content is of confidential nature .
  • the signature receiver must get to know that the signature is encrypted, and where to turn to get it decrypted. The best way probably is to let the information exist explicitly or implicitly in the user- or device certificate (sometimes a URL is transmitted instead which point at the certificate) which, according to Step 4, is transmitted to the service provider, even if there are other possibilities.
  • WAP WAP
  • signtext the encrypted signature is transmitted transparently as a non-encrypted signature.
  • the adjustments are made in WIM (however not in the interface towards the mobile terminal) and in origin server/PKI-portal (however not in the interface towards WAP GW) .
  • the method can be used both with symmetric and asymmetric card issuer encryption of the digital signature.
  • the secret key which has been placed on the smart card to encrypt the signatures is only known by/to the card issuer.
  • the signature is encrypted by a public key, the corresponding private key of which only is known by the card issuer.
  • a service provider/signature receiver buys "permanent" access to the card issuer key of certain cards, and is allowed to use it under an agreement. In that case the communication with the card issuer in Step 5 and 6 is not needed for each signature.
  • the method also can be used where digital signatures created on a smart card are used in any step to create a secure data transport, for instance WTLS (Wireless Transport Layer Security) or SSL (Secure Sockets Layer) .
  • WTLS Wireless Transport Layer Security
  • SSL Secure Sockets Layer
  • SWIM SIM with WIM
  • SWIM does not hold the public key
  • RSA-keys a device certificate
  • the operator's idea partly is based on the principle that the party who wants to issue a certificate based on keys on SWIM shall pay a fee to the operator for this .
  • One method for this is that the operator creates a database with device certificates and charges the one who requests a device certificate as basis to create a user certificate. In principle anybody can issue a user certificate if the above invention is not used.
  • two signatures of/by users inquire/request (in that way the public key can be calculated, device certificate is not necessary) .
  • the invention prevents this, by only parties having agreements with the operator being allowed to have signatures decrypted.
  • SWIM SIM with WIM
  • public public in this context means that the user will have full access to his/her certificate and it is invention, the operator can get possibility to create earnings at each signature which is made by means of the SWIM.

Abstract

A verification system (200) and a method to, at a wireless telecommunication and data communication network (100), make earnings possible for a card issuer (118). The verification system is based on open, standardized interfaces. When a digital signature has been created on a smart card (102) in a mobile unit (104), the digital signature is encrypted with/by a key which belongs to the card issuer before the signature leaves the smart card. The encrypted signature is transmitted/transferred 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 after that transmits the signature to the card issuer. The card issuer decrypts the signature, debits the signature receiver and transmits the decrypted signature to the signature receiver. After that, the signature receiver can check the digital signature.

Description

METHOD AND SYSTEM FOR TRANSMISSION OF DATA
Technical field
The present invention relates to a system and a method to, at a wireless telecommunication and data communication network, make earnings possible for a card issuer in a system which is based on open, standardized interfaces.
Prior art Since some time back there are systems to create digital signatures by means of a mobile telephone, based on keys on so called smart cards in the mobile telephone and PKI (Public Key Infrastructure) . There are two main approaches to realize these methods, on the one hand a solution which is based on SIM application tool combined with an OTA-platform (OTA = Over The Air) and on the other a solution based on WIM (Wireless Application Module) .
In the first solution the card issuer, which is the mobile telephone operator, has full control over the signing process and all communication is executed via the operator's OTA-platform. By that, the operator has all possibilities to charge participants (that is, service providers, for instance banks) which want to use the signature function. The operator has for the same reason possibility to charge a CA (Certificate Authority) which wants to issue certificate based on keys on the smart card. The disadvantage with/of this solution is that it is not standardized.
In the latter solution the interfaces are standardized by WAP (Wireless Application Protocol) forum and is often considered to be the solution which will be the most successful. Here the interfaces are standardized, and the operator is transparent in communication sense to the participants which want to use the signing function. Of that follows that the card issuer to-day has no technical possibility to charge participants which are using the signing function. There also are possibilities for a CA to issue certificate based on keys on the smart card, without the card issuer's knowledge, and therefore neither earnings related to this are secured by the card issuer.
To-day's system to secure card issuer earnings at digital signatures is based on that the communication between the smart card in the mobile telephone and the service provider/CA is executed via some form of operator gateway, where billing data is generated (frequently based on so called SAT-technology (SIM Application Toolkit) + OTA platform) .
The solution which exists today to try to secure earnings for CA is to charge for revocation information. Such a solution is based on that CA = card issuer and does not function from a business point of view for systems where CA and card issuer are different parties. When some party is interested in validating/verifying a signature, this party turns to CA to get revocation information, not to the card issuer, so the card issuer has difficulties to get any earnings for the signatures which are created with/ by his card. It is true that CA frequently have based their certificates on the card issuer's device certificate (which usually informs about which party has made/issued the card, created key etc) , but these are never revoked in the practice, so the card issuer hardly can base its business on revocation information for device certificate.
US" 2002/0032860 shows a system in which an encrypted digital signature is transmitted from a customer, via a tradesman, to a financial institution. The financial institution decrypts the signature and transmits the decrypted signature (+ account information) to the tradesman .
WO 99/00775 shows a system for payment. In a terminal is a "smart card". Between the terminal and an "acquirer" there 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, for instance, be a bank. One way is that a PIN-code is encrypted and is transmitted via an "acquirer" to the card issuer. The "acquirer" can not decrypt the PIN-code.
WO 01/45056 shows a system to perform card transactions. The buyer's computer creates an encrypting number, which at least to some extent/part agrees with the card number. The encrypted number is given to a tradesman who forwards it to the card issuer, the computer of which can decrypt, the number. Identification of the buyer is made via a separate link from the buyer to the card issuer.
WO 00/79724 shows a WIM-card containing the card manufacturer's private key. By this, certificate is signed. Verification of the signature is made by the card issuer.
US 2002/00056079 shows a method to load an application on a "smart card". The one which provides the application (the service provider) cannot decrypt "card attribute data", but has to transmit these (and ID for the application) further to the card issuer. The card issuer decrypts "card attribute data" and identifies the card. The card issuer then decides if the loading of the application shall be allowed or not, and informs about this to the service provider. WO 01/22374 shows a method and system for secure payment. The idea of the method is that the card issuer is responsible for "authentication" of the card owner/holder and "authorization" of the card purchase. At a purchase an inquiry/request about payment is transmitted from the tradesman to the card holder. The card holder opens a link to the card issuer, (authenticated by the card issuer) , and transmits information about the purchase and the tradesman via the link to the card issuer. The card issuer answers/ responds by transmitting payment information to the tradesman via the cardholder's computer. The tradesman's computer confirms the purchase. The card issuer confirms the payment when the card holder has been authenticated. All data which are transmitted are decrypted. The cardholder's computer can be a mobile telephone. The card issuer has control over the information flow to the card holder during the transfer of the payments.
SUMMARY OF THE INVENTION The present invention relates to a system and a method to create digital signatures by means of a mobile telephone, which system is based on keys in so called smart cards in a mobile telephone and PKI .
Today's system for securing card issuer earnings at digital signatures is based on that the communication between the smart card in the mobile telephone and the service provider is executed via some form of operator interface where the debiting data is generated. The invention results in that a standardized system with open solutions instead can be used, that is, in the whole interaction between the service provider and the user.
A distinctive feature of the invention is that when a digital signature has been created on a smart card in a mobile unit, the digital signature is encrypted (not the signed amount of data) with/by a key which belongs to the card issuer before the signature leaves the smart card. The encrypted signature is transmitted/transferred to the receiver in the same way as if it had not been encrypted by /with the card issuer's key. The receiver transmits the signature to the card issuer, which is the only one that can decrypt the signature. The card issuer decrypts the signature, debits the signature receiver and transmits the decrypted signature to the signature receiver. Only after that, the signature receiver can evaluate/check the decrypted signature.
One advantage with/of the invention is that verification of the digital signature is made in a standardized system with open solutions, that is, in the whole interaction between service provider/CA and user.
Another advantage with/of the invention is that the digital signature is encrypted after it has been created, so that only the card issuer can decrypt it.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention now will be described in details in the following with reference to enclosed drawings, in which Figure 1 shows a survey of a mobile system which verifies signatures on smart cards,
Figure 2 shows verification system/systems of how a digital signature can be verified,
Figure 3 shows a signal diagram of how the signature can be verified,
Figure 4 shows a flow chart of how the signature is verified. DESCRIPTION OF PREFERRED EMBODIMENTS
The invention aims at securing the card issuer's earnings for systems which are based on WIM or other future systems with open interfaces.
Figure 1 shows a survey of a system 100 for mobile communication, the mobile system, which can verify signatures on smart cards . The mobile system 100 consists of a smart card SK 102 which contains/includes a function A. to create a digital signature DS on an amount of data, and a function B which encrypts the digital signature by/with a card issuer's key KN and gets an encrypted digital signature. A mobile terminal ME 104 with a card reader where the smart card is placed. A mobile communication network 106 via which communication between mobile terminal/smart card and a signature receiver SM 112 is executed. The mobile communication network includes typically base stations, transmission, exchanges and databases. The mobile communication network also can be a short distance communication network (based on, for instance, Blue Tooth) . A gateway or proxy 108 which connects the mobile communication network with an Internet 110. Internet (data communication network) is used for the communication between mobile terminal/smart card and the signature receiver. Such a data communication network also can be used for communication between the signature receiver and a card issuer server 118. There are two main types of signature receivers: Certificate Authority 114 (certificate-issuer) or a Service Provider 116 (service- provider) . At/with these there are different servers and databases/catalogs. From the signature receiver, the encrypted digital signatures" are "transmitted to the card issuer server. The card issuer server decrypts the digital signatures and after that returns the decrypted digital signatures to the signature receiver. Figure 2 shows a verification system 200 of how a signature can be verified, and Figure 3 shows a signal diagram 300 over how the signature can be verified. The signal diagram shows examples of which type of signal management that is applied between the different units in the verification system. In the verification system is included a smart card module SKM 202 to create digital signatures (WIM), a mobile terminal 104, some type of mobile communication network ME 106, for instance 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 executed between the different units:
Step 1: The signature receiver SM 112 transmits 302 a signing enquiry/request to the mobile terminal ME 104.
Step 2: The mobile terminal ME 104 attends to the signing enquiry/request. After that, the mobile terminal ME request 304 that a smart card module SKM 202 shall create a digital signature.
Step 3: The smart card module SKM 202 makes use of the function A, which creates a digital signature DS and the function B, which encrypts the digital signature and then will have an encrypted digital signature KDS . After that, the encrypted digital signature is transmitted 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/further transmits 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 gets a decrypted digital signature DDS, debits the signature receiver for this, and transmits 312 the decrypted signature to the signature receiver 112.
In Figure 4 a flow chart 400 over how the signature is verified is shown, consequently a more detailed procedure than has earlier been described. The service provider 116, which also is the signature receiver SM 112, transmits 402 a signing enquiry/request to the user' s mobile terminal ME 104, which, for instance, includes/contains the data which shall 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 (most often a PIN-code) which is required to unlock the signing key SN . The mobile terminal requests 410 that the smart card module SKM 202 shall create a digital signature DS for the content, by one of the private keys PN for signing on the card.
The function A creates 412 a digital signature DS for the content in the smart card module SKM 202. The function B encrypts 414 the digital signature DS by the card issuer's key KN . After that, the encrypted digital signature KDS is transmitted 416 to the mobile terminal ME 104.
The mobile terminal ME 104 formats/creates 418 an answer to the signature inquiry/request and encloses 420 the encrypted digital signature KDS to the signature receiver SM 112. Information about which party the card issuer is, is also enclosed.
The signature receiver SM 112 transmits 422 the encrypted digital signature KDS to the card issuer KU 210.
The card issuer KU 210 decrypts 424 the encrypted digital signature, debits 426 the signature receiver SM 112 for this, and transmits 428 the decrypted digital signature DDS to the signature receiver SM 112.
The invention is not limited to use with any/some specific protocols or frameworks, but since it is in the first phase is expected to be used together with WIM and WPKI according to WAP forum, here follows a (somewhat simplified of the steps 1-5) description of what this case can look like:
The service provider transmits a signing inquiry/ request to the user's mobile terminal by means of the function "signText". A description of "signText" is to be found in "WMLScript Crypto Library" WAP-161- WMLScriptCrypto-20010620-a, WAP forum.
The mobile terminal starts a dialog towards the user, and the user decides to sign the content and enters information (most often a PIN-code) which is required to unlock the signing key. The mobile terminal request that WIM shall create a digital signature for the content by transmitting the command "Compute Digital Signature" to
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 that, the encrypted signature is transmitted to the mobile terminal in the command answer to "Compute Digital Signature" .
The mobile terminal formats/creates a result of
"signText", where the encrypted signature is enclosed as the object "Signature". A certificate or a certificate-ULR is also added, where the certificate includes additional information about which party the card issuer is. The result of "signText" is transmitted from the mobile terminal to the signature receiver. The signature receiver transmits the encrypted signature to the card issuer.
The card issuer decrypts the signature, debits the signature receiver for this, and transmits the decrypted signature to the signature receiver.
Note that it is only the signature, not the signed content, that is encrypted in Step 3, and which 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 if the signed content is of confidential nature .
The signature receiver must get to know that the signature is encrypted, and where to turn to get it decrypted. The best way probably is to let the information exist explicitly or implicitly in the user- or device certificate (sometimes a URL is transmitted instead which point at the certificate) which, according to Step 4, is transmitted to the service provider, even if there are other possibilities.
One important quality of the invention is that it probably can be used for WAP (WIM, signtext) without changes in the mobile terminal or WAP GW, the encrypted signature is transmitted transparently as a non-encrypted signature. The adjustments are made in WIM (however not in the interface towards the mobile terminal) and in origin server/PKI-portal (however not in the interface towards WAP GW) .
The method can be used both 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 only known by/to the card issuer. In the asymmetric case, the signature is encrypted by a public key, the corresponding private key of which only is known by the card issuer.
Note that a card issuer key per card should be used, and not a card issuer key for several cards. This in order to minimize the damage if the key becomes known.
One possible variant of the method is that a service provider/signature receiver buys "permanent" access to the card issuer key of certain cards, and is allowed to use it under an agreement. In that case the communication with the card issuer in Step 5 and 6 is not needed for each signature.
The method also can be used where digital signatures created on a smart card are used in any step to create a secure data transport, for instance WTLS (Wireless Transport Layer Security) or SSL (Secure Sockets Layer) .
This might, in the WTLS-case, imply that the answer to Sign H (handshake-msg) would be encrypted with/by the card issuer' s key, whereupon it is transmitted to the server in "Certificate verify", whereupon the server has to transmit the content in "Certificate verify" to the card issuer to get the signature decrypted. The method also would be possible to use in corresponding non-mobile connections to secure card issuer earnings .
Example 1
There is operator which issues SIM with WIM (SWIM) which also points at a device certificate (SWIM does not hold the public key) with RSA-keys. The operator's idea partly is based on the principle that the party who wants to issue a certificate based on keys on SWIM shall pay a fee to the operator for this . One method for this is that the operator creates a database with device certificates and charges the one who requests a device certificate as basis to create a user certificate. In principle anybody can issue a user certificate if the above invention is not used. By the suggested method, two signatures of/by users inquire/request (in that way the public key can be calculated, device certificate is not necessary) . The invention prevents this, by only parties having agreements with the operator being allowed to have signatures decrypted. The operator then can charge a small sum for each signature that has been made, which as such is a business possibility. This in its turn makes possible that the operator might 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 to an official CPS etc) , without it, for that reason, being uninteresting for/to 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 it as the holder of SWIM (public in this context means that the user will have full access to his/her certificate and it is invention, the operator can get possibility to create earnings at each signature which is made by means of the SWIM.

Claims

PATENT CLAIMS
1. Verification system (200) to verify signatures on a smart card (102, 202) , which verification system includes 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 issuer server (118) , c h a r a c t e r i z e d in that the smart card/mobile terminal is in connection with the signature receiver via at least one mobile communication network (106) which in its turn is in connection with the card issuer server, that it in the smart card first is created (412) a signature, next step the signature is encrypted (414), after that the encrypted signature is transmitted (306, 416, 308, 420, 310, 422) to the card issuer server via the mobile terminal and the signature receiver, that in the card issuer server the signature is decrypted (424), after that the decrypted signature is returned (312, 428) to the signature receiver, and that in the signature receiver the decrypted signature is evaluated/checked.
2. Verification system to verify signatures on a smart card as claimed in patent claim 1, c h a r a c t e r i z e d in that the mobile communication network includes base stations, transmission, exchanges and databases.
3. Verification system to verify signatures on a smart card as claimed in patent claim 1, c h a r a c t e r i z e d in that the mobile communication network is a short distance communication network.
4. Verification system to verify signatures on a smart card as claimed in any of the patent claims 1-3, c h a r a c t e r i z e d in that between the mobile communication network and the signature receiver is a gateway (108) and a data communication network (110) which are connected with each other.
5. Verification system to verify signatures on a smart card as claimed in patent claim 4, c h a r a c t e r i z e d in that the data communication network is used for communication between the mobile terminal/the smart card and the signature receiver.
6. Verification system to verify signatures on a smart card as claimed in any of the previous/above given patent claims, c h a r a c t e r i z e d in that the signature receiver is certificate issuer (114) .
7. Verification system to verify signatures on a smart card as claimed in any of the patent claims 1-5, c h a r a c t e r i z e d in that the signature receiver is a service provider (116) .
8. Procedure (200, 300, 400) to verify signatures on a smart card consisting of a verification system (100) which includes 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 issuer server (118) , c h a r a c t e r i z e d in that the smart card/the mobile terminal is in connection with the signature receiver via at least one mobile communication network (106) which in its turn is in connection with the card issuer server, that the procedure includes to create (412) a signature, to encrypt (414) the signature in the smart card, to transmit (306, 416, 308, 420, 310, 422) the encrypted signature to the card issuer server via the mobile terminal and the signature receiver, to decrypt (424) the signature, to return (312, 428) the decrypted signature to the signature receiver that these steps of procedure are executed in the card issuer server, to evaluate/check the decrypted signature in the signature receiver.
9. Procedure to verify signatures on a smart card as claimed in patent claim 8, c h a r a c t e r i z e d in that before creating a signature the procedure includes a first step; to transmit (302, 402) a signing/signature inquiry/request from the signature receiver to the mobile terminal .
10. Procedure to verify signatures on a smart card as claimed in patent claim 8, c h a r a c t e r i z e d in that before the step to create a signature, in the mobile terminal, the procedure includes a second step; to attend to the signing inquiry/request, to request (304, 404) that the smart card shall create a digital signature.
11. Procedure to verify signatures on a smart card as claimed in patent claim 8, c h a r a c t e r i z e d in that the step to create a signature, the procedure includes a third step; to use a function A to create (412) a digital signature, to in the step to encrypt the signature use a function B to encrypt (414) the digital signature, and to after that transmit (306, 416) the encrypted digital signature to the mobile terminal.
12. Procedure to verify signatures on a smart card as claimed in patent claim 8, c h a r a c t e r i z e d in that after the step to encrypt the signature, the procedure includes a fourth step ; to transmit (308, 420) the encrypted digital signature from the mobile terminal to the signature receiver.
13. Procedure to verify signatures on a smart card as claimed in patent claim 8, c h a r a c t e r i z e d in that, after the step to encrypt the signature, the procedure includes a fifth step ; to transmit (310, 422) the encrypted digital signature from the signature receiver to card issuer server.
14. Procedure to verify signatures on a smart card as claimed in patent claim 8, c h a r a c t e r i z e d in that, in the step to decrypt the encrypted signature, the procedure includes a sixth step; to decrypt (424) the encrypted digital signature, to debit (426) the signature receiver for this, and to transmit (312, 428) the decrypted digital signature to the signature receiver.
15. Procedure to verify signatures on a smart card as claimed in patent claim 10, c h a r a c t e r i z e d in that the second step of procedure includes to start (404) a dialog with a user, that the user decides (406) to sign the content and enters (408) a PIN-code to unlock the signing key SN, to request (310, 410) that the smart card shall create the digital signature by one of the private keys for signing on the card.
16. Procedure to verify signatures on a smart card as claimed in patent claim 11, c h a r a c t e r i z e d in that in the function B the digital signature is encrypted (414) by/with the card issuer's key.
17. Procedure to verify signatures on a smart card as claimed in patent claim 12, c h a r a c t e r i z e d in that the fourth step of procedure includes that the mobile terminal formats/creates (418) an answer to the signature inquiry/request and encloses (308, 420) the encrypted digital signature and information about which party the card issuer is.
18. Computer program including program steps for execution of the steps in a procedure according to any of the patent claims 8-17.
19. Computer with readable medium including instructions for execution of the steps in procedure according to any of the patent claims 8-17.
PCT/SE2003/001980 2002-12-23 2003-12-17 Method and system for transmission of data WO2004057547A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
AU2003288840A AU2003288840A1 (en) 2002-12-23 2003-12-17 Method and system for transmission of data
EP03781215A EP1579396A1 (en) 2002-12-23 2003-12-17 Method and system for transmission of data
NO20051700A NO336856B1 (en) 2002-12-23 2005-04-06 Data transfer method and system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SE0203877-6 2002-12-23
SE0203877A SE524514C2 (en) 2002-12-23 2002-12-23 Method and system for transmitting data

Publications (1)

Publication Number Publication Date
WO2004057547A1 true WO2004057547A1 (en) 2004-07-08

Family

ID=20290023

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2003/001980 WO2004057547A1 (en) 2002-12-23 2003-12-17 Method and system for transmission of data

Country Status (5)

Country Link
EP (1) EP1579396A1 (en)
AU (1) AU2003288840A1 (en)
NO (1) NO336856B1 (en)
SE (1) SE524514C2 (en)
WO (1) WO2004057547A1 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102011122874A1 (en) 2011-09-27 2013-03-28 Vodafone Holding Gmbh Method for initializing and/or activating account of user using mobile terminal such as mobile telephone, involves generating user identifier in side of provider and transferring user identifier from provider to main terminal
DE102011115154B3 (en) * 2011-09-27 2013-03-28 Vodafone Holding Gmbh Method for initializing and / or activating at least one user account
US9225680B2 (en) 2011-05-24 2015-12-29 Vodafone Gmbh Method and device for providing an identity identifier of an electronic terminal device
CN105205666A (en) * 2014-06-17 2015-12-30 中国银联股份有限公司 Bluetooth-based face to face payment method and system

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998052151A1 (en) * 1997-05-15 1998-11-19 Access Security Sweden Ab Electronic transaction
US5903882A (en) * 1996-12-13 1999-05-11 Certco, Llc Reliance server for electronic transaction system
US6223291B1 (en) * 1999-03-26 2001-04-24 Motorola, Inc. Secure wireless electronic-commerce system with digital product certificates and digital license certificates
US20020077993A1 (en) * 2000-12-18 2002-06-20 Nokia Corporation Method and system for conducting wireless payments
GB2375872A (en) * 2001-05-22 2002-11-27 Vodafone Group Services Ltd Electronic transaction systems and methods

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5903882A (en) * 1996-12-13 1999-05-11 Certco, Llc Reliance server for electronic transaction system
WO1998052151A1 (en) * 1997-05-15 1998-11-19 Access Security Sweden Ab Electronic transaction
US6223291B1 (en) * 1999-03-26 2001-04-24 Motorola, Inc. Secure wireless electronic-commerce system with digital product certificates and digital license certificates
US20020077993A1 (en) * 2000-12-18 2002-06-20 Nokia Corporation Method and system for conducting wireless payments
GB2375872A (en) * 2001-05-22 2002-11-27 Vodafone Group Services Ltd Electronic transaction systems and methods

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9225680B2 (en) 2011-05-24 2015-12-29 Vodafone Gmbh Method and device for providing an identity identifier of an electronic terminal device
DE102011122874A1 (en) 2011-09-27 2013-03-28 Vodafone Holding Gmbh Method for initializing and/or activating account of user using mobile terminal such as mobile telephone, involves generating user identifier in side of provider and transferring user identifier from provider to main terminal
DE102011115154B3 (en) * 2011-09-27 2013-03-28 Vodafone Holding Gmbh Method for initializing and / or activating at least one user account
EP2575385A1 (en) 2011-09-27 2013-04-03 Vodafone Holding GmbH Method for initializing and/or activation of at least one user account, for carrying out a transaction, and terminal
DE102011122874B4 (en) 2011-09-27 2021-10-14 Vodafone Gmbh Method for carrying out a transaction, as well as terminal device
CN105205666A (en) * 2014-06-17 2015-12-30 中国银联股份有限公司 Bluetooth-based face to face payment method and system

Also Published As

Publication number Publication date
SE0203877L (en) 2004-06-24
NO20051700D0 (en) 2005-04-06
SE524514C2 (en) 2004-08-17
EP1579396A1 (en) 2005-09-28
AU2003288840A1 (en) 2004-07-14
NO20051700L (en) 2005-07-20
NO336856B1 (en) 2015-11-16
SE0203877D0 (en) 2002-12-23

Similar Documents

Publication Publication Date Title
US8145899B2 (en) Creation of user digital certificate for portable consumer payment device
US7925878B2 (en) System and method for creating a trusted network capable of facilitating secure open network transactions using batch credentials
US7979353B2 (en) Electronic transaction method using an electronic coupon
EP1669955B1 (en) System and method of bootstrapping a temporary public-key infrastructure from a cellular telecommunication authentication and billing infrastructure
US20030069792A1 (en) System and method for effecting secure online payment using a client payment card
US20100010932A1 (en) Secure wireless deposit system and method
EP2369545A1 (en) System and method of secure authentication and billing for goods and services using a cellular telecommunication and an authorization infrastructure
US20020098830A1 (en) Method for verifying in a mobile device the authenticity of electronic certificates issued by a certification authority and corresponding identification module
US20090182676A1 (en) Remote Electronic Payment System
US20070118749A1 (en) Method for providing services in a data transmission network and associated components
US20100049655A1 (en) Method and system for securely executing a charge transaction
WO2008052592A1 (en) High security use of bank cards and system therefore
EP1176844A2 (en) Telecommunication systems and methods
NO336856B1 (en) Data transfer method and system
KR100349888B1 (en) PKI system for and method of using micro explorer on mobile terminals
KR20020010160A (en) System & Method for Wireless Electronic Commerce Payment service
WO2002091144A1 (en) Method of secure transactions by means of two public networks
KR20040055843A (en) System and Method for Payment by Using Authorized Authentication Information
KR100458526B1 (en) System and Method for the wire·wireless complex electronic payment
KR100837301B1 (en) System and method for providing cash advance service in mobile station payment portal service
KR20020083195A (en) System and Method for the electronic billing process and authentication using the synchronized wire-wireless complex system
KR20080003303A (en) System for payment by using authorized authentication information
KR100836883B1 (en) Method and Apparatus for Transit Pass Card using Mobile Communication
Pisko Enhancing Security of Terminal Payment with Mobile Electronic Signatures
KR20020078994A (en) Apparatus and method for paying the price using wireless communication terminal

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REEP Request for entry into the european phase

Ref document number: 2003781215

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2003781215

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2003781215

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Ref document number: JP