WO2010048829A1 - 密钥分发方法和系统 - Google Patents

密钥分发方法和系统 Download PDF

Info

Publication number
WO2010048829A1
WO2010048829A1 PCT/CN2009/073222 CN2009073222W WO2010048829A1 WO 2010048829 A1 WO2010048829 A1 WO 2010048829A1 CN 2009073222 W CN2009073222 W CN 2009073222W WO 2010048829 A1 WO2010048829 A1 WO 2010048829A1
Authority
WO
WIPO (PCT)
Prior art keywords
application provider
security domain
management platform
public key
certificate
Prior art date
Application number
PCT/CN2009/073222
Other languages
English (en)
French (fr)
Inventor
马景旺
贾倩
余万涛
Original Assignee
中兴通讯股份有限公司
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 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Priority to KR1020117010518A priority Critical patent/KR101188529B1/ko
Priority to EP09823021.2A priority patent/EP2341659B1/en
Priority to US13/126,174 priority patent/US8532301B2/en
Priority to JP2011533518A priority patent/JP5508428B2/ja
Publication of WO2010048829A1 publication Critical patent/WO2010048829A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy

Definitions

  • NFC Near Field Communication
  • Radio Frequency Identification Radio Frequency Identification
  • a mobile communication terminal such as a mobile phone can simulate a contactless IC card for related applications of electronic payment; in addition, implementing the solution on a mobile communication terminal requires adding an NFC analog front end chip and an NFC antenna to the terminal. And use a smart card that supports electronic payment.
  • IC cards especially non-contact IC cards
  • mobile phones After more than 20 years of rapid development, mobile phones have been basically applied. It has gained popularity and brought great convenience to people's work and life. Therefore, combining mobile phones with non-contact IC card technology and applying mobile phones to the field of electronic payment will further expand the use of mobile phones, bring convenience to people's lives, and have broad application prospects.
  • the electronic payment system of the mobile terminal includes: distribution of the smart card, and electronic Download, install, and personalize payment applications, and use related technologies and management strategies to secure electronic payments.
  • a security domain is a representation of an off-card entity (including card issuers and application providers) on a smart card that contains encryption keys to support secure channel protocol operation and card content management, if the electronic payment system supports the Global platform Card Specification V2
  • Secure Channel Protocol supports Secure Channel Protocol '02, (based on symmetric key); if the electronic payment system supports the Global platform Card Specification V2.2 specification, the secure channel protocol supports Secure Channel Protocol '10, (based on asymmetric secrets) key).
  • Security i or responsible for its own key management, which ensures that applications and data from different application providers can coexist on the same card.
  • the keys and certificates on the security domain need to include: A public key (also known as a public key) and a private key (also known as a private key), a certificate for a secure domain, and a trusted public key for authenticating an out-of-card entity certificate.
  • a public key also known as a public key
  • a private key also known as a private key
  • a certificate for a secure domain and a trusted public key for authenticating an out-of-card entity certificate.
  • the application provider's security domain on the smart card is the slave security domain. Before downloading and installing the application provider's electronic payment application to the smart card, the application provider's smart card primary security domain must be created on the smart card first. From the security domain, then set the key from the security domain.
  • the secure domain key is confidential and requires reliable and secure methods and techniques to import the relevant keys and certificates into the secure domain to enable secure distribution of keys from the secure domain, where the creation of the secure domain requires the card
  • the publisher management platform indicates the creation of the primary security domain on the smart card, and after the security domain is created, the initial key from the security domain needs to be set up and distributed by the card issuer management platform.
  • One method adopted from security domain creation and key distribution is: smart card and card issuer management platform establish communication, application provider management platform establishes communication with card issuer management platform; card issuer management platform indicates smart card master security
  • the domain is established from the security domain, and the public and private key pairs from the security domain are generated by the slave security domain on the card and sent to the card issuer management platform, and then the card issuer management platform sends the key generated from the security domain to the application.
  • the provider management platform, the application provider management platform issues the certificate from the security domain according to the public key of the security domain, and then imports the security domain certificate and the trusted certificate from the security domain through the card issuer management platform. , thus completing the distribution of keys from the secure domain.
  • a main object of the present invention is to provide a key distribution method and system to avoid a secret domain key.
  • the card issuer management platform obtains the problem that the key is not secure.
  • a key distribution method is provided.
  • the key distribution method includes: the application provider management platform notifying the application provider corresponding to the application provider management platform that the smart card is configured to generate the public key and the private domain from the security domain.
  • the public-private key pair of the key the application provider management platform receives the public key encryption of the pre-obtained application provider from the security domain by the application provider through the card issuer management platform, and the CASD signature processing set on the smart card Public key; the application provider management platform verifies the signature and decrypts using the application provider's private key to obtain the public key; the application provider management platform passes the application provider's certificate from the security domain and the trusted certificate for external authentication
  • the public key of the user is sent to the application provider from the security domain through the card issuer management platform after being encrypted by the application provider from the public domain of the security domain and after the encrypted data is processed by the application provider's private key.
  • a key distribution system comprises: a card issuer management platform, comprising: a creation module for creating an application provider slave security domain on the smart card; and an information sending module for using the application provider from the security domain
  • the basic information is sent to the application provider management platform, where the basic information includes the identification information of the application provider from the security domain, the configuration information of the application provider from the security domain, and the application provider management platform, which includes: a notification module, configured
  • the application provider configured on the smart card corresponding to the application provider management platform generates a public-private key pair including a public key and a private key from the security domain; and the first receiving module is configured to receive the security domain from the application provider.
  • a public key wherein the public key is encrypted by a public key of the application provider obtained in advance, and processed by a CASD signature set on the smart card; the first obtaining module is configured to verify the signature and use the private key of the application provider Decrypting to obtain a public key; a first sending module, used to pass the application provider from the security domain Key encryption, and application provider that signs the encrypted data via the application provider's private key, from the security domain's certificate and the trusted public key for external authentication, to the application provider from the secure domain; smart card
  • the mobile terminal includes an application provider from the security domain, where the application provider further includes: a second obtaining module, configured to obtain an application provider's public key; and a second sending module, configured to be provided by the application
  • the public key encryption of the quotient and the public key processed by the CASD signature are sent to the application provider management platform; the second receiving module is configured to receive the certificate of the secure domain and the external authentication by the application provider that is encrypted and signed.
  • a decryption module configured to verify the signature of the data received by the receiving module by using the public key of the application provider, and verify If the certificate is passed, the application provider decrypts the private key of the security domain to obtain the certificate of the application provider from the security i or the trusted public key for external authentication.
  • the application provider encrypts the generated secure domain key generated on the card from the security domain by using the public key of the pre-obtained application provider, and sends it to the application provider management platform, and the application provider management platform Encrypting and transmitting to the slave domain from the security certificate of the security domain and the public key of the trusted domain from the security domain's public key by the pre-obtained application provider;
  • the card issuer management platform is responsible for application provider management The data transfer between the platform and the application provider from the security domain, but the card issuer management platform cannot obtain the private key of the application provider and the application provider from the security domain, and therefore cannot decrypt the data to obtain the key from the security domain.
  • FIG. 1 is a block diagram showing the structure of a mobile terminal electronic payment system according to an embodiment of the present invention
  • FIG. 2 is a block diagram of a key distribution system according to an embodiment of the system of the present invention.
  • a flowchart of a key distribution method of an embodiment of the inventive method FIG. 4 is a flow chart of a selection processing scheme of a key distribution method according to an embodiment of the method of the present invention.
  • an application provider encrypts and transmits a slave security domain key generated on a card from a security domain using a public key of a previously obtained application provider to the application provider management platform;
  • the application provider management platform pre-acquires the public key of the application provider from the security domain, and uses the public key to encrypt and send the application provider's certificate from the security domain and the trusted public key for external authentication to the From the security domain, the card issuer management platform cannot obtain the private key of the application domain and the application provider from the security domain, and cannot decrypt the data, so the key from the security domain cannot be obtained;
  • the CASD on the smart card is only responsible for the verification of the certificate and the signature of the data.
  • a mobile terminal electronic payment system is mainly composed of a card issuer management platform 1, an application provider management platform 2, and a mobile terminal 3 including a smart card, which may exist in the system.
  • Application provider management platform is mainly composed of a card issuer management platform 1, an application provider management platform 2, and a mobile terminal 3 including a smart card, which may exist in the system.
  • the card issuer management platform 1 includes a card management system 10, an application management system 11, a key management system 12, a certificate management system 13, and an application provider management system 14, wherein the certificate management system 13 is based on near field communication technology.
  • the mobile terminal electronic payment system supports the use of an asymmetric key, the certificate management system 13 and the card issuer CA (Certificate Center) system connection; the application supply and management function; the application provider management system 14 can manage the application provider's relevant Information, specifying the service authority of the application provider, etc.
  • the card issuer management platform 1 owned by the card issuer uses the certificate management system 13 only in the case of supporting an asymmetric key.
  • the card issuer management platform 1 is responsible for managing the resources and lifecycle, keys, and certificates of the card, and is responsible for creating the slave security domain of the application provider.
  • the application provider management platform 2 includes an application management system 20, a key management system 21, and a certificate management system 22, wherein the certificate management system 22 is used when the mobile payment system supports an asymmetric key, and the certificate management system 22 and the application provide The quotient CA system is connected and the certificate management system 22 is only used in the case of supporting asymmetric keys.
  • the application provider can provide various service applications through the application provider management platform 2, and manage the security domain corresponding to the card, control the application key, certificate, data, etc. of the security domain, and provide the application. Secure download function.
  • the application provider can be an operator, a bank, a bus company, a retailer, and the like.
  • the application provider can have a business terminal management system and a service terminal, and can provide monthly services to the user through the service terminal.
  • the mobile terminal 3 is provided with a smart card (not shown) supporting electronic payment, and in order to realize the security management of the smart card and the downloading and installation functions of the payment application, the smart card needs to be issued and the card is issued.
  • the merchant management platform 1 and the application provider management platform 2 establish communication.
  • the communication between the smart card and the management platform can be achieved in two ways: (1) The smart card establishes communication through the mobile terminal using the mobile communication network and the management platform, generally using over-the-air downloading (Over The Air, called OTA) technology enables communication between smart cards and management platforms. (2) Realize the connection between the smart card and the management platform through the business terminal of the management platform.
  • the service terminal is configured with a contactless card reader or a card reader that directly reads the smart card, and the service terminal can establish communication with the management platform, thereby realizing communication between the smart card and the management platform.
  • the user can download, install, and use the electronic payment application, and the user operates the mobile terminal and the smart card by interacting with the card issuer management platform or the application provider management platform, and downloading in the secure domain and Install new applications, using the various business applications provided by the card publisher management platform or the application provider management platform.
  • the mobile terminal electronic payment system based on the near field communication technology supports a multi-electronic payment application, and multiple electronic payment applications can be installed on the smart card.
  • the smart card adopts the Global Platform Card Specification V2.1.1 V2.2 specification, and the smart card is divided into several independent security i or to ensure isolation and independence between multiple applications, each application provider Manage their own security domains as well as applications, application data, and more.
  • the smart card that supports the Global Platform specification mentioned here refers to an IC chip or smart card conforming to the Global Platform Card Specification V2.1. 2.2 specification, which can be physically SIM/USIM card, pluggable smart memory card or integrated. IC chip on the mobile terminal.
  • a security domain is a representation of the card's external entities (including card issuers and application providers) on the card, which contain encryption keys to support secure channel protocol operation and card content management. The security domain is responsible for its own key management, which ensures that applications and data from different application providers can coexist on the same card.
  • the keys and certificates on the security domain need to include: the public key (also called public key) and the private key (also called private key) of the security domain.
  • the security domain of the application provider on the smart card is the secondary security domain.
  • the slave security domain of the application provider needs to be created on the smart card through the smart card master security domain owned by the card issuer, and then the key from the security domain is set.
  • the secure domain key is confidential and requires reliable and secure methods and techniques to pass the key And import the certificate into the secure domain to achieve secure distribution from the secure domain key.
  • an embodiment of the present invention provides a key distribution system.
  • 2 is a structural block diagram of a key distribution system according to an embodiment of the system of the present invention.
  • the key distribution system according to the present embodiment includes: a card issuer management platform 200, and an application provider management platform 210. And smart card 220.
  • the card issuer management platform 200 further comprising: a creating module, configured to create an application provider slave security domain on the smart card; and an information sending module, configured to send the application provider from the basic information of the security domain to the application provider management platform
  • the basic information includes the identification information of the application provider from the security domain, and the configuration information of the application provider from the security domain.
  • the application provider management platform 210 is connected to the card issuer management platform 200, and further includes: a notification module, configured to notify the application provider corresponding to the application provider management platform that the smart card is configured to generate the public key from the security domain and a public-private key pair of the private key; a first receiving module, configured to receive a public key from the application provider from the security domain, where the public key is encrypted by the public key of the application provider obtained in advance, and is set a CASD signature processing on the smart card; a first obtaining module, configured to verify the signature and decrypt using the private key of the application provider to obtain a public key; and a first sending module, configured to: pass the public key of the security domain through the application provider Encryption, and application provider from the security domain by the application provider's private key to sign the encrypted data
  • the public key of the externally authenticated trusted root is sent to the application provider from the security domain; the smart card 220 is connected to the card issuer management platform 200, and the smart card 220 is located at the mobile terminal, including
  • the smart card 220 further includes: a CASD for verifying the certificate of the application provider and the signature public key.
  • the smart card can conform to the Global Platform Card Specification 2.2 specification, and the smart card security domain adopts an asymmetric key system, and the keys that need to be imported from the security domain are created: from the security i or the public key and private The key, the security from the security domain ⁇ certificate and the external authentication used by the One Public Key for Trust Point for External Authentication (PK.TP_EX.AUT).
  • PK.TP_EX.AUT One Public Key for Trust Point for External Authentication
  • the security domain certificate is generated by the application provider management platform from the security domain public key, the root of the trust used by the external authentication
  • the public key is provided by the CA that issued the application provider certificate and can be obtained from the application provider management platform, which is used to authenticate the application provider certificate from the security domain.
  • the public and private keys of the security domain can be generated by the RSA algorithm.
  • the length of the public and private keys is 1024 bits.
  • the application provider management platform uses the pre-acquired application provider to encrypt and send the certificate from the security domain and the trusted public key to the secure domain from the security domain's public key; the card issuer
  • the management platform is responsible for data transmission between the application provider management platform and the application provider from the security domain, the card issuer management platform cannot obtain the private key of the application provider and the application provider from the security domain, and thus cannot decrypt the data.
  • Obtain the key from the security domain realize the isolation of the card issuer management platform, and effectively ensure the application provider from the security domain key The security of the distribution.
  • FIG. 3 is a flowchart of a key distribution method according to an embodiment of the present invention.
  • the method includes the following steps S302 to S308: Step S302, the application provider management platform notifies the application provider to manage The application provider corresponding to the platform corresponding to the smart card generates a public-private key pair including a public key and a private key from the security domain; Step S304, the application provider management platform receives the security from the application provider through the card issuer management platform.
  • the public key encryption of the pre-obtained application provider of the domain, and the public key processed by the trusted domain that is, the CASD signature processed by the trusted third party set on the smart card;
  • Step S306 the application provider management platform verifies the signature and uses the application
  • the private key of the provider is decrypted to obtain a public key;
  • step S308 the application provider management platform passes the certificate of the application provider from the security domain and the public key of the trusted certificate for external authentication, and the security is passed through the application provider.
  • the domain's public key is encrypted, and the encrypted data is signed by the application provider's private key.
  • the station sends to the application provider from the security domain, completing the distribution of the key from the secure domain.
  • the card issuer management platform and the CASD cannot obtain the private key of the security provider or the application provider from the secure i, the card issuer management platform and the CASD cannot decrypt the key data, and thus cannot obtain security from The key data of the domain realizes the isolation of the card issuer management platform, and effectively guarantees the secure distribution of the security domain key. Details of each of the above processes are further described below.
  • Step S302 in order to achieve the confidentiality requirement, a trusted third party needs to be introduced on the smart card, and the third party has a Controlling Authority from the security domain (CASD) on the smart card, and the trusted third party uses the CASD to apply
  • the provider provides services from a secure domain.
  • Controlling Authority is either from security i or in compliance with the requirements of the Global Platform Card Specification V2.2.
  • CASD can Provides an independent service interface for the application provider from the security domain, including certificate verification, signature, data decryption, and more.
  • the trusted third party is a certificate authority (CA) that issues a certificate to each application provider, and the CA has a separate CASD on the smart card.
  • CA certificate authority
  • the keys and certificates in the CASD include: the public and private keys of CASD, the certificate of CASD, the public key of the CA trusted certificate used to verify the application provider certificate, and the public and private keys of the CASD of the CA on the smart card.
  • the CA generates, the certificate of the CASD is generated by the CA according to the public key of the CASD, and the public key of the CA trusted root is provided by the CA.
  • the CASD can be created and initialized in a secure manner when the smart card is issued.
  • the CA writes the public key of the CASD security i or the public key, the certificate and the CA trusted certificate in the CASD security domain.
  • the private key of the CASD is It can only be updated on the smart card and cannot be read.
  • the card issuer management platform and the application provider management platform cannot obtain the CASD private key.
  • the card issuer management platform is first required to notify the smart card master security domain to create a slave security domain. After being created from the security domain, the card issuer management platform sends the basic information of the security domain to the application provider management platform. The application provider management platform then obtains the CASD certificate, verifies the authenticity of the CASD certificate and obtains the CASD public key from the certificate. The application provider management platform can use the public key to encrypt the data sent to the application provider from the security domain. After receiving the encrypted data from the security domain, the application provider decrypts the data by calling the service interface provided by CASD.
  • CASD uses CASD.
  • the private key decrypts the data and returns the decrypted data to the application provider from the security domain.
  • the application provider management platform sends its own certificate to the application provider from the security domain through the card issuer management platform.
  • the application provider verifies the application provider's certificate from the security domain by calling the certificate verification interface provided by CASD.
  • the CASD verifies the application provider's certificate using the CA's trusted public key, and if the verification passes, returns the application provider's identification information (ID) and the application provider's public key to the application provider's secondary security domain.
  • the application provider management platform notifies the application provider to generate a public-private key pair including a public key (public key) and a private key (private key) on the smart card from the secure domain.
  • the application provider generates the public key and the private key from the security domain by calling the interface that generates the key on the smart card, encrypts the generated key with the application provider's public key, and then signs the encrypted data through the CASD security domain, and then Send to the application provider management platform.
  • Step S304 and step S306 After the application provider management platform receives the key data from the application provider from the security domain, the signature is verified and the data is decrypted using the private key of the application provider, thereby obtaining the application provider from the security.
  • the public key of the domain is
  • the application provider management platform issues the certificate of the application provider from the security domain from the public key of the security domain according to the obtained application provider, and uses the application provider to provide the application from the public key of the security domain.
  • the cipher encrypts the certificate of the security domain and the public key of the trusted root, signs the encrypted data with the private key of the application provider, and then sends the message to the application provider from the security domain.
  • the application provider uses the application provider's public key to verify the signature and uses the application provider to decrypt the data from the secure private key to obtain the secure domain certificate and the trusted public key.
  • the security domain performs the security domain certificate and the trusted root public key according to the message indication, thereby completing the distribution of the application provider from the security domain key.
  • the isolation of the card issuer management platform is realized, and the secure distribution of the security key by the application provider is effectively ensured.
  • the application provider can create the secure domain and the key distribution process through the OTA.
  • the application provider management platform and the card issuer management platform establish a connection with the smart card through the OTA mode, and transmit related commands through the OTA. And data.
  • the creation of the security domain by the application provider and the process of distributing the key can also be completed by the service terminal of the card issuer.
  • the smart card establishes a connection through the card publisher's business terminal and the card issuer management platform and the application provider management platform, and the service terminal transmits data such as commands and responses between the smart card and the management platform.
  • FIG. 4 is a flowchart of a preferred processing scheme of the key distribution method according to the embodiment of the present invention. As shown in FIG. 4, the processing specifically includes the following steps S402 to S428: Step S402, Card Issuer Management
  • the platform creates an application provider from a secure domain.
  • the process of creating an application provider from the security domain may include: (1)
  • the card issuer management platform sends a SELECT (selection) message to the smart card, and selects the primary security domain of the smart card.
  • the card issuer management platform and the smart card master security domain establish an SCP 10 secure channel according to the requirements of the Global Platform Card Specification V2.2 Appendix F Secure Channel Protocol '10, and complete the authentication of both parties and the negotiation of the session key.
  • the card issuer management system sends an application provider to the primary security domain to create a message from the security domain.
  • the primary security domain creates an application provider from the security domain as indicated in the instructions.
  • the application provider management platform has the same ID (APSD ID) as the application provider management platform.
  • the card issuer management platform sends the created application provider from the basic information of the security domain to the application provider management platform, and the basic information includes the ID of the application provider from the security domain. (APSD ID) and configuration information from the application provider from the security domain.
  • the application provider management platform needs to save the information of the application provider from the security domain in the database of the application provider management platform.
  • the application provider management platform obtains the certificate of the smart card CASD from the smart card.
  • the application provider can send a GET DATA message to the smart card to obtain a certificate for the CASD.
  • Step S406 the application provider management platform verifies the certificate of the CASD and obtains the public key of the CASD.
  • the application provider management platform can verify the authenticity of the CASD certificate using the CA's trusted root public key and obtain the CASD public key from the CASD certificate.
  • Step S408, the application provider management platform uses the STORE DATA (data storage) message by its own certificate and sends it to the application provider from the security domain through the card issuer management platform. In order to achieve security when sending a certificate, the application provider management platform can use the CASD public key to force the application provider's certificate to be dense.
  • Step S410 the application provider requests the CASD to verify the certificate of the application provider from the security domain.
  • Step S412 the CASD returns the verification result, the ID of the application provider, and the public key of the application provider from the security domain to the application provider.
  • Step S414 after determining the authenticity of the application provider certificate, sending a STORE DATA response from the security domain to the application provider management platform.
  • Step S416 the application provider management platform notifies the application provider to generate a public and private key from the security domain.
  • Step S418, the application provider generates the public key and the private key from the security domain by calling the interface for generating the key on the card, and the generated public key is encrypted by the application provider's public key, and then the encrypted data is signed by the CASD. .
  • Step S420 the application provider sends the encrypted application provider from the security domain to the application provider management platform from the public key of the security domain.
  • Step S422 the application provider management platform verifies the signature and decrypts the data by using the application provider's private key to obtain the public key of the application provider from the security domain.
  • Step S424 The certificate management system in the application provider management platform sends the public key and the application provider from the security domain certificate application information to the application provider CA. After the CA issues the slave security domain certificate, the certificate is returned to the certificate management system.
  • Step S426 the application provider management platform sends the application provider from the security domain's certificate and the public key of the trusted root for external authentication to the slave security domain through a PUT KEY command.
  • the application provider can encrypt the certificate of the security domain and the public key of the trusted root from the security key of the application domain using the public key of the security domain, and then use the private key of the application provider to encrypt the data. Sign it.
  • Step S428 after receiving the PUT KEY command from the security domain, the application provider verifies the data signature and decrypts the data by using its own private key, obtains the certificate of the application provider from the security domain and the public key of the trusted certificate, and then applies the application. The provider sets the certificate and public key from the security domain. After the setup is complete, the application provider sends a PUT KEY response message from the security domain to the application provider management platform.
  • the application provider performs the secure domain key generated on the card from the security domain by using the public key of the application provider obtained in advance. Encrypted and sent to the application provider management platform, the application provider management platform encrypts and sends to the application provider from the security domain's certificate and the trusted root's public key from the security domain's public key using the pre-obtained application provider.
  • the card issuer management platform is responsible for the data transfer between the application provider management platform and the application provider from the security domain, but the card issuer management platform cannot obtain the private key of the application provider and the application provider from the security domain. Therefore, the data cannot be decrypted to obtain the key from the security domain, and the isolation of the card issuer management platform is realized, thereby effectively ensuring the security of the application provider from the security domain key distribution.
  • the above modules or steps of the present invention can be implemented by a general-purpose computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices.
  • the invention is not limited to any specific combination of hardware and software.
  • the above is only the preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the scope of the present invention are intended to be included within the scope of the present invention.

Description

密钥分发方法和系统
技术领域 本发明涉及通信领域， 并且特别地， 涉及一种密钥分发方法和系统。 背景技术 在相关技术中 ,近场通信技术（ Near Field Communication,筒称为 NFC ) 是工作于 13.56MHz的一种近距离无线通信技术， 该技术由射频识别 （Radio Frequency Identification , 筒称为 RFID )技术及互连技术融合演变而来。 手机 等移动通信终端在集成 NFC技术后， 可以模拟非接触式 IC卡， 用于电子支 付的相关应用； 此外， 在移动通信终端上实现该方案需要在终端上增加 NFC 模拟前端芯片和 NFC天线， 并使用支持电子支付的智能卡。
IC卡， 特别是非接触式 IC卡， 经过十多年的发展， 已经被广泛应用于 公交、 门禁、 小额电子支付等领域； 与此同时， 手机经历 20 多年的迅速发 展后， 其应用已经基本得到普及， 并且给人们的工作及生活带来了 艮大的便 利。 因此， 将手机和非接触式 IC卡技术结合， 将手机应用于电子支付领域， 会进一步扩大手机的使用范围， 给人们的生活带来便捷， 存在着广阔的应用 前景。 在相关技术中， 为实现基于 NFC技术的移动电子支付， 需要建立移动 终端电子支付系统， 并通过该系统实现对移动终端电子支付的管理， 其中， 移动终端电子支付系统包括： 智能卡的发行、 电子支付应用的下载、 安装和 个人化、 以及采用相关技术和管理策略实现电子支付的安全等。 安全域是卡外实体 （包括卡发行商和应用提供商） 在智能卡上的代表， 它们包含用于支持安全通道协议运作以及卡内容管理的加密密钥， 如果电子 支付系统支持 Global platform Card Specification V2.1.1规范， 安全通道协议 支持 Secure Channel Protocol '02， （基于对称密钥）； 如果电子支付系统支持 Global platform Card Specification V2.2 规范， 安全通道协议支持 Secure Channel Protocol ' 10， （基于非对称密钥）。 安全 i或负责其自身的密钥管理， 这保证了来自不同应用提供者的应用和数据可以共存于同一个卡上。 安全域 的密钥采用非对称密钥体制时， 安全域上的密钥和证书需要包括： 安全域的 公钥（也可称为公密钥）和私钥（也可称为私密钥）、 安全域的证书、 用于认 证卡外实体证书的可信任才艮公钥。 应用提供商在智能卡上的安全域为从安全域，在将应用提供商的电子支 付应用下载并安装到智能卡之前 , 需要在智能卡上先通过卡发行商拥有的智 能卡主安全域创建应用提供商的从安全域， 然后设置从安全域的密钥。 安全域密钥是机密数据 ,需要采取可靠及安全的方法和技术将有关密钥 和证书导入到从安全域， 以实现从安全域密钥的安全分发， 其中， 从安全域 的创建需要由卡发行商管理平台指示智能卡上的主安全域创建 , 而且从安全 域创建完成后 , 从安全域的初始密钥需要由卡发行商管理平台负责设置和分 发。 从安全域创建和密钥分发时， 采用的一种方法是： 智能卡和卡发行商管 理平台建立通信， 应用提供商管理平台与卡发行商管理平台建立通信； 卡发 行商管理平台指示智能卡主安全域建立从安全域， 从安全域的公、 私密钥对 由从安全域在卡上生成并发送给卡发行商管理平台， 然后卡发行商管理平台 将从安全域生成的密钥发送给应用提供商管理平台， 应用提供商管理平台才艮 据从安全域的公钥签发从安全域的证书 , 再通过卡发行商管理平台将从安全 域证书和可信任才艮公钥导入到从安全域， 从而完成从安全域密钥的分发。 但在这种情况下，卡发行商管理平台负责数据的传送时有可能获得发送 的安全域密钥数据， 可能使用获得的密钥对从安全域执行操作， 这样会对应 用提供商电子支付应用的安全造成威胁。 因此， 急需一种解决从安全域密钥的分发不安全的问题的技术方案。 发明内容 考虑到相关技术中从安全域密钥的分发不安全的问题而做出本发明 ,为 此， 本发明的主要目的在于提供一种密钥分发方法和系统， 以避免从安全域 密钥被卡发行商管理平台获取导致密钥不安全的问题。 根据本发明的有一个方面， 提供了一种密钥分发方法。 根据本发明的密钥分发方法包括：应用提供商管理平台通知应用提供商 管理平台对应的设置于智能卡上的应用提供商从安全域生成包括公密钥和私 密钥的公私密钥对； 应用提供商管理平台通过卡发行商管理平台接收来自应 用提供商从安全域的经过预先获得的应用提供商的公钥加密、 以及经过设置 于智能卡上的 CASD签名处理的公密钥； 应用提供商管理平台验证签名并使 用应用提供商的私钥进行解密得到公密钥； 应用提供商管理平台将应用提供 商从安全域的证书和用于外部认证的可信任才艮的公钥， 在经过应用提供商从 安全域的公密钥加密、 以及经过应用提供商的私钥对加密后的数据签名处理 后通过卡发行商管理平台发送至应用提供商从安全域， 完成对从安全域密钥 的分发。 才艮据本发明的另一方面， 还提供了一种密钥分发系统。 才艮据本发明的密钥分发系统包括： 卡发行商管理平台， 其包括： 创建模块， 用于在智能卡上创建应用提供商从安全域； 信息发送模块， 用于将应用提供商从安全域的基本信息发送至应用提供商管理平台， 其中， 基本信息包括应用提供商从安全域的标识信息、 应用提供商从安全域的配置 信息； 应用提供商管理平台， 其包括： 通知模块， 用于通知应用提供商管理平 台对应的设置于智能卡上的应用提供商从安全域生成包括公密钥和私密钥的 公私密钥对； 第一接收模块， 用于接收来自应用提供商从安全域的公密钥， 其中， 公密钥经过预先获得的应用提供商的公钥加密、 以及经过设置于智能 卡上的 CASD签名处理； 第一获取模块， 用于验证签名并使用应用提供商的 私钥进行解密得到公密钥； 第一发送模块， 用于将经过应用提供商从安全域 的公密钥加密、 以及经过应用提供商的私钥对加密后的数据签名的应用提供 商从安全域的证书和用于外部认证的可信任才艮的公钥 , 发送至应用提供商从 安全域； 智能卡， 位于移动终端， 包括应用提供商从安全域， 其中， 应用提供商 从安全域进一步包括： 第二获取模块， 用于获取应用提供商的公钥； 第二发 送模块， 用于将经过应用提供商的公钥加密、 以及经过 CASD签名处理的公 密钥发送至应用提供商管理平台； 第二接收模块， 用于接收经过加密以及签 名处理的应用提供商从安全域的证书和用于外部认证的可信任根的公钥； 解 密模块， 用于将接收模块接收的数据利用应用提供商的公钥验证签名， 并验 证通过的情况下利用应用提供商从安全域的私钥进行解密， 以获得应用提供 商从安全 i或的证书和用于外部认证的可信任才艮公钥。 通过本发明的上述技术方案 ,应用提供商从安全域利用预先获得的应用 提供商的公钥对卡上生成的从安全域密钥进行加密并发送给应用提供商管理 平台， 应用提供商管理平台利用预先获得的应用提供商从安全域的公钥对应 用提供商从安全域的证书和可信任根的公钥加密并发送至所述从安全域； 卡 发行商管理平台虽然负责应用提供商管理平台和应用提供商从安全域之间的 数据传输 , 但卡发行商管理平台无法获得应用提供商和应用提供商从安全域 的私钥 , 因此不能对数据解密进而获得从安全域的密钥 , 实现了对卡发行商 管理平台的隔离， 有效地保证了应用提供商从安全域密钥分发的安全性。 附图说明 此处所说明的附图用来提供对本发明的进一步理解 ,构成本申请的一部 分， 本发明的示意性实施例及其说明用于解释本发明， 并不构成对本发明的 不当限定。 在附图中： 图 1是才艮据本发明系统实施例的移动终端电子支付系统的结构框图； 图 2是才艮据本发明系统实施例的密钥分发系统的框图； 图 3是根据本发明方法实施例的密钥分发方法的流程图； 图 4 是才艮据本发明方法实施例的密钥分发方法的 ύ选处理方案的流程 图。 具体实施方式 功能相克述 本发明的主要思想是：应用提供商从安全域使用预先获得的应用提供商 的公钥对卡上生成的从安全域密钥进行加密并发送给应用提供商管理平台； 应用提供商管理平台预先获得应用提供商从安全域的公钥 , 并利用该公钥对 应用提供商从安全域的证书和用于外部认证的可信任才艮的公钥加密并发送至 所述从安全域， 使得卡发行商管理平台由于无法获得应用提供商和应用提供 商从安全域的私钥， 而不能对数据进行解密， 因此不能获得从安全域的密钥； 而智能卡上的 CASD只负责证书的验证和数据的签名 , 其不掌握应用提供商 和应用提供商从安全域的私钥， 无法对数据进行解密， 从而也不能获得从安 全域的密钥。 因此在应用提供商从安全域的密钥分发过程中实现了对卡发行 商管理平台的隔离， 有效地保证了应用提供商从安全域密钥分发的安全性。 以下结合附图对本发明的优选实施例进行说明， 应当理解， 此处所描述 的优选实施例仅用于说明和解释本发明， 并不用于限定本发明。 系统实施例 如图 1所示，根据本发明实施例的移动终端电子支付系统主要由卡发行 商管理平台 1、 应用提供商管理平台 2和包含有智能卡的移动终端 3组成， 该系统中可以存在多个应用提供商管理平台。 其中， 卡发行商管理平台 1包括卡管理系统 10、 应用管理系统 11、 密 钥管理系统 12、 证书管理系统 13、 应用提供商管理系统 14, 其中， 证书管 理系统 13 在基于近场通信技术的移动终端电子支付系统支持非对称密钥的 情况下使用， 证书管理系统 13和卡发行商 CA (证书中心） 系统连接； 应用 供和管理功能； 应用提供商管理系统 14 可管理应用提供商的有关信息， 规 定应用提供商的业务权限等。 此外，卡发行商拥有的卡发行商管理平台 1仅在支持非对称密钥情况下 使用证书管理系统 13。 卡发行商管理平台 1负责对卡的资源和生命周期、 密 钥、 证书进行管理， 并负责创建应用提供商的从安全域。 应用提供商管理平台 2包括应用管理系统 20、 密钥管理系统 21、 证书 管理系统 22, 其中， 证书管理系统 22在移动支付系统支持非对称密钥的情 况下使用， 证书管理系统 22和应用提供商 CA系统连接， 并且仅在支持非对 称密钥情况下使用证书管理系统 22。 并且， 应用提供商可以通过应用提供商 管理平台 2提供各种业务应用， 并对卡上与其对应的安全域进行管理， 对其 安全域的应用密钥、 证书、 数据等进行控制， 提供应用的安全下载功能。 应 用提供商可以是运营商、 银行、 公交公司、 零售商户等。 另外， 应用提供商 可拥有业务终端管理系统和业务终端，并且可通过业务终端向用户提供月 务。 移动终端 3中具备支持电子支付的智能卡 （未示出）， 并且， 为了实现 智能卡的安全性管理和支付应用的下载、 安装等功能， 智能卡需要和卡发行 商管理平台 1以及应用提供商管理平台 2建立通信。 实现智能卡和管理平台（上述卡发行商管理平台 1和应用提供商管理平 台 2 ) 的通信可以通过两个途径： （1 ) 智能卡通过移动终端使用移动通信网 络和管理平台建立通信， 一般采用空中下载 （ Over The Air, 筒称为 OTA ) 技术实现智能卡和管理平台的通信。 （2 ) 通过管理平台的业务终端实现智能 卡和管理平台的连接。 业务终端配置有非接触读卡器或者直接读取智能卡的 读卡器， 并且业务终端可以和管理平台建立通信， 从而实现智能卡和管理平 台的通信。 在上述的移动支付系统中， 用户能够进行电子支付应用的下载、安装和 使用， 用户通过与卡发行商管理平台或应用提供商管理平台交互， 对移动终 端和智能卡进行操作， 在安全域内下载及安装新的应用， 使用卡发行商管理 平台或应用提供商管理平台提供的各种业务应用。 基于近场通信技术的移动终端电子支付系统支持多电子支付应用 ,在智 能卡上可以安装多个电子支付应用。 为了实现支付应用的安全， 智能卡采用 Global Platform Card Specification V2.1.1 V2.2规范， 智能卡被分隔为若干个 独立的安全 i或， 以保证多个应用之间的隔离以及独立性， 各个应用提供商管 理各自的安全域以及应用、 应用数据等。 这里提到的支持 Global Platform规 范的智能卡指的是符合 Global Platform Card Specification V2.1. 2.2规范的 IC芯片或智能卡 , 从物理形式上可以为 SIM/USIM卡、 可插拔的智能存储卡 或者集成在移动终端上的 IC芯片。 安全域是卡外实体（包括卡发行商和应用提供商）在卡上的代表， 它们 包含用于支持安全通道协议运作以及卡内容管理的加密密钥。 安全域负责其 自身的密钥管理， 这保证了来自不同应用提供者的应用和数据可以共存于同 一个卡上。 安全域的密钥采用非对称密钥体制时， 安全域上的密钥和证书需 要包括： 安全域的公钥（也可称为公密钥）和私钥 （也可称为私密钥）、 安全 域的证书、 用于认证卡外实体证书的可信任才艮的公钥。 应用提供商在智能卡上的安全域为从安全域。在将应用提供商的电子支 付应用下载并安装到智能卡之前 , 需要在智能卡上先通过卡发行商拥有的智 能卡主安全域创建应用提供商的从安全域 , 然后设置从安全域的密钥。 安全域密钥是机密数据，需要采取可靠及安全的方法和技术将有关密钥 和证书导入到从安全域， 以实现从安全域密钥的安全分发。 从安全域需要由 卡发行商管理平台指示智能卡上的主安全域创建，而且从安全域创建完成后 , 从安全域的初始密钥需要由卡发行商管理平台负责设置和分发。 基于上述电子支付系统， 本发明实施例提供了一种密钥分发系统。 图 2是才艮据本发明系统实施例的密钥分发系统的结构框图，如图 2所示 , 根据本实施例的密钥分发系统包括： 卡发行商管理平台 200、 应用提供商管 理平台 210和智能卡 220。 卡发行商管理平台 200, 其进一步包括： 创建模块 , 用于在智能卡上创建应用提供商从安全域； 信息发送模块 ,用于将应用提供商从安全域的基本信息发送至应用提供 商管理平台， 其中， 基本信息包括应用提供商从安全域的标识信息、 应用提 供商从安全域的配置信息； 在本发明实施例中， 在智能卡中下载应用提供商的电子支付应用以前， 应用提供商管理平台需要先检查智能卡中是否存在应用提供商的从安全域。 如果不存在对应的从安全域， 应用提供商管理平台需要请求卡发行商管理平 台在智能卡上创建该应用提供商的从安全域。 应用提供商管理平台 210, 连接至卡发行商管理平台 200, 其进一步包 括： 通知模块，用于通知应用提供商管理平台对应的设置于智能卡上的应用 提供商从安全域生成包括公密钥和私密钥的公私密钥对； 第一接收模块， 用于接收来自应用提供商从安全域的公密钥， 其中， 公 密钥经过预先获得的应用提供商的公钥加密、 以及经过设置于智能卡上的 CASD签名处理； 第一获取模块 ,用于验证签名并使用应用提供商的私钥进行解密得到公 密钥； 第一发送模块， 用于将经过应用提供商从安全域的公密钥加密、 以及经 过应用提供商的私钥对加密后的数据签名的应用提供商从安全域的证书和用 于外部认证的可信任根的公钥， 发送至应用提供商从安全域; 智能卡 220 , 连接至卡发行商管理平台 200 , 该智能卡 220位于移动终 端， 包括应用提供商从安全域， 其中， 应用提供商从安全域进一步包括： 第二获 莫块 , 用于获取应用提供商的公钥； 第二发送模块， 用于将经过应用提供商的公钥加密、 以及经过 CASD 签名处理的公密钥发送至应用提供商管理平台； 第二接收模块 ,用于接收经过加密以及签名处理的应用提供商从安全域 的证书和用于外部认证的可信任才艮的公钥； 解密模块 , 用于将接收模块接收的数据利用应用提供商的公钥验证签 名， 并验证通过的情况下利用应用提供商从安全域的私钥进行解密。 并且， 智能卡 220还包括： CASD, 其用于验证应用提供商的证书以及 签名公密钥。 优选地， 在实际应用当中， 智能卡可以符合 Global Platform Card Specification 2.2规范， 智能卡安全域采用非对称密钥体制， 创建的从安全域 中需要导入的密钥包括： 从安全 i或的公钥和私钥、 从安全域 ^证书和外部认证 使用的信任才艮公 4月 ( One Public Key for Trust Point for External Authentication , PK.TP_EX.AUT )。从安全 i或的公钥和私钥由应用提供商的从安全 i或在卡上生 成， 从安全域证书由应用提供商管理平台才艮据从安全域公钥生成， 外部认证 使用的信任根公钥是由签发应用提供商证书的 CA提供的 , 可以从应用提供 商管理平台获得， 该公钥用于从安全域对应用提供商证书的认证。 从安全域 的公钥和私钥可以采用 RSA算法生成， 公钥和私钥的长度选择为 1024bits。 通过以上描述可以看出， 在本发明的密钥分发系统中， 应用提供商从安 全域利用预先获得的应用提供商的公钥对卡上生成的从安全域密钥进行加密 并发送给应用提供商管理平台， 应用提供商管理平台利用预先获得的应用提 供商从安全域的公钥对应用提供商从安全域的证书和可信任才艮的公钥加密并 发送至从安全域； 卡发行商管理平台虽然负责应用提供商管理平台和应用提 供商从安全域之间的数据传输， 但卡发行商管理平台无法获得应用提供商和 应用提供商从安全域的私钥 ,因此不能对数据解密进而获得从安全域的密钥 , 实现了对卡发行商管理平台的隔离， 有效地保证了应用提供商从安全域密钥 分发的安全性。 方法实施例 在本实施例中， 提供了一种密钥分发方法， 应用于包括应用提供商的应 用提供商管理平台、 卡发行商管理平台和移动终端的通信系统。 图 3是才艮据本发明实施例的密钥分发方法的流程图 , 如图 3所示， 该方 法包括以下步骤 S302至步骤 S308的处理： 步骤 S302, 应用提供商管理平台通知应用提供商管理平台对应的设置 于智能卡上的应用提供商从安全域生成包括公密钥和私密钥的公私密钥对； 步骤 S304, 应用提供商管理平台通过卡发行商管理平台接收来自应用 提供商从安全域的经过预先获得的应用提供商的公钥加密、 以及经过设置于 智能卡上的可信任第三方从安全域即 CASD签名处理的公密钥； 步骤 S306, 应用提供商管理平台验证签名并使用应用提供商的私钥进 行解密得到公密钥； 步骤 S308 , 应用提供商管理平台将应用提供商从安全域的证书和用于 外部认证的可信任才艮的公钥， 在经过应用提供商从安全域的公密钥加密、 以 及经过应用提供商的私钥对加密后的数据签名处理后通过卡发行商管理平台 发送至应用提供商从安全域， 完成对从安全域密钥的分发。 根据上述实施例， 卡发行商管理平台和 CASD 因为无法获得应用提供 商和应用提供商从安全 i或的私钥 , 卡发行商管理平台和 CASD无法对密钥数 据进行解密， 因而无法获得从安全域的密钥数据， 实现了对卡发行商管理平 台的隔离， 有效地保证了从安全域密钥的安全分发。 下面进一步描述上述各处理的细节。
(一） 步骤 S302 根据本发明， 为了实现机密性的需要， 智能卡上需要引入可信任的第三 方 , 第三方在智能卡上拥有 Controlling Authority从安全域（ CASD )，可信任 的第三方通过 CASD向应用提供商从安全域提供服务。 Controlling Authority 从安全 i或符合 Global Platform Card Specification V2.2中的要求。 CASD可以 为应用提供商从安全域提供独立的服务接口， 包括证书验证、 签名、 数据解 密等。 优选地 ,可信任的第三方为给各应用提供商签发证书的证书中心（ CA ) , CA在智能卡上拥有一个独立的 CASD。 CASD中的密钥和证书包括： CASD 的公钥和私钥、 CASD的证书、 用于验证应用提供商证书的 CA可信任才艮的 公钥， CA在智能卡上的 CASD的公、 私钥由 CA生成， CASD的证书由 CA 根据 CASD的公钥签发生成， CA可信任根的公钥由 CA提供。 CASD可以 在智能卡发行时采用安全的方式进行创建和初始化， 由 CA在 CASD安全域 中写入 CASD安全 i或的公私钥、 证书和 CA可信任才艮的公钥， 其中， CASD 的私钥在在智能卡上只能被更新， 不能被读取， 因此， 卡发行商管理平台和 应用提供商管理平台无法获得 CASD的私钥。 根据本发明 ,首先需要卡发行商管理平台通知智能卡主安全域创建从安 全域。 在从安全域创建后 , 卡发行商管理平台将安全域的基本信息发送给应 用提供商管理平台。 然后， 应用提供商管理平台获得 CASD的证书， 验证 CASD的证书的 真实性并从证书中获得 CASD的公钥。 应用提供商管理平台可以使用该公钥 将发送给应用提供商从安全域的数据进行加密， 应用提供商从安全域接收到 加密数据后通过调用 CASD 提供的服务接口对数据进行解密， CASD 使用 CASD的私钥对数据进行解密， 并将解密后的数据返回给应用提供商从安全 域。 并且，应用提供商管理平台将自己的证书通过卡发行商管理平台发送给 应用提供商从安全域。 应用提供商从安全域调用 CASD提供的证书验证接口 验证应用提供商的证书。 CASD使用 CA可信任才艮的公钥验证应用提供商的 证书， 如果验证通过， 则将应用提供商的标识信息 （ID ) 和应用提供商的公 钥返回给应用提供商从安全域。 应用提供商管理平台通知应用提供商从安全域在智能卡上生成包括公 密钥 （公钥） 和私密钥 （私钥） 的公私密钥对。 应用提供商从安全域通过调 用智能卡上生成密钥的接口产生公钥和私钥， 将生成的密钥采用应用提供商 的公钥加密， 再通过 CASD安全域对加密后的数据进行签名， 然后发送给应 用提供商管理平台。 (二） 步骤 S304和步骤 S306 应用提供商管理平台接收到来自应用提供商从安全域的密钥数据后 ,验 证签名并使用应用提供商的私钥对数据进行解密， 从而获得应用提供商从安 全域的公钥。
(三） 步骤 S308 基于上述处理 ,应用提供商管理平台根据得到的应用提供商从安全域的 公钥签发应用提供商从安全域的证书， 并使用应用提供商从安全域的公钥对 应用提供商从安全域的证书和可信任根的公钥进行加密、 使用应用提供商的 私钥对加密后的数据进行签名 , 然后通过报文发送给应用提供商从安全域。 应用提供商从安全域接收到数据后 ,使用应用提供商的公钥验证签名并使 用应用提供商从安全的私钥对数据进行解密 , 从而获得安全域证书和可信任才艮 公钥， 应用提供商从安全域按照报文指示进行安全域证书和可信任根公钥的设 置， 从而完成应用提供商从安全域密钥的分发。 通过上述描述可以得出，卡发行商管理平台在传输应用提供商管理平台 和从安全域的通信数据时， 因为不掌握应用提供商和从安全域的私钥， 因此 不能对数据解密， 无法获得从安全域的密钥； 而对于智能卡上的 CASD, 由 于其只负责证书的验证和数据的签名 ,不掌握应用提供商和从安全域的私钥 , 无法对数据进行解密， 因此也不能获得从安全域的密钥。 通过上述实施例， 实现了对卡发行商管理平台的隔离， 有效地保证了应用提供商从安全域密钥 的安全分发。 在上述过程中， 应用提供商从安全域的创建、 密钥的分发过程可以通过 OTA的方式实现， 应用提供商管理平台、 卡发行商管理平台通过 OTA方式 和智能卡建立连接 , 通过 OTA传输相关命令和数据。 并且， 应用提供商从安全域的创建、 密钥的分发过程也可以通过卡发行 商的业务终端完成。 智能卡通过卡发行商的业务终端和卡发行商管理平台及 应用提供商管理平台建立连接，业务终端传输智能卡和管理平台之间的命令、 响应等数据。 应用提供商发送给智能卡的命令由卡发行商管理平台发送给智 能卡， 并从卡发行商管理平台获得智能卡发送的响应。 下面将结合具体应用实例描述根据本实施例的密钥分发处理。 图 4是才艮据本发明实施例的密钥分发方法的优选处理方案的流程图，如 图 4所示， 该处理过程具体包括以下步骤 S402至步骤 S428的处理： 步骤 S402, 卡发行商管理平台创建应用提供商从安全域。 创建应用提 供商从安全域的过程可以包括： ( 1 ) 卡发行商管理平台向智能卡发送 SELECT (选择）报文， 选择智 能卡的主安全域。
( 2 ) 卡发行商管理平台和智能卡主安全域按照 Global Platform Card Specification V2.2 附录 F Secure Channel Protocol ' 10， 的要求建立 SCP 10 安全信道 , 完成双方的认证及对话密钥的协商。 ( 3 ) 卡发行商管理系统向主安全域发送应用提供商从安全域创建报文
INSTALL[for Install]。 主安全域按照 4艮文指示创建应用提供商从安全域， 应 用提供商管理平台从安全域的 ID ( APSD ID )可以和应用提供商管理平台的 ID相同。
( 4 ) 应用提供商从安全域创建完成后 , 卡发行商管理平台将创建的应 用提供商从安全域的基本信息发送给应用提供商管理平台， 该基本信息包括 应用提供商从安全域的 ID ( APSD ID ) 和应用提供商从安全域的配置信息。 应用提供商管理平台收到应用提供商从安全域的基本信息后 , 需要在应用提 供商管理平台的数据库中保存应用提供商从安全域的信息。 步骤 S404, 应用提供商管理平台从智能卡获得智能卡 CASD的证书。 应用提供商可以向智能卡发送 GET DATA (数据获取）报文以获得 CASD的 证书。 步骤 S406, 应用提供商管理平台验证 CASD的证书并获得 CASD的公 钥。 应用提供商管理平台可以使用 CA的可信任根公钥验证 CASD证书的真 实性， 并从 CASD的证书中获得 CASD的公钥。 步骤 S408 , 应用提供商管理平台将自己的证书使用 STORE DATA (数 据存储）报文并通过卡发行商管理平台发送给应用提供商从安全域。 为了实 现发送证书时的安全， 应用提供商管理平台可以使用 CASD的公钥对应用提 供商的证书进行力 P密。 步骤 S410, 应用提供商从安全域请求 CASD验证应用提供商的证书。 步骤 S412, CASD 向应用提供商从安全域返回验证结果、 应用提供商 的 ID和应用提供商的公钥。 步骤 S414, 确定应用提供商证书的真实性后， 从安全域发送 STORE DATA响应给应用提供商管理平台。 步骤 S416, 应用提供商管理平台通知应用提供商从安全域生成公、 私 钥。 步骤 S418 , 应用提供商从安全域通过调用卡上生成密钥的接口产生公 钥和私钥， 夺生成的公钥采用应用提供商的公钥加密， 然后再通过 CASD对 加密后的数据进行签名。 步骤 S420, 应用提供商从安全域将加密后的应用提供商从安全域的公 钥发送给应用提供商管理平台。 步骤 S422, 应用提供商管理平台验证签名并使用应用提供商的私钥解 密数据 , 获得应用提供商从安全域的公钥。 步骤 S424, 应用提供商管理平台中的证书管理系统将公钥和应用提供 商从安全域的证书申请信息发送给应用提供商 CA, CA 签发从安全域证书 后， 将证书返回给证书管理系统。 步骤 S426, 应用提供商管理平台通过 PUT KEY (密钥设置）命令将应 用提供商从安全域的证书和用于外部认证的可信任根的公钥发送给从安全 域。 在 PUT KEY 4艮文中， 可以使用应用提供商从安全域的公钥对应用提供 商从安全域的证书和可信任根的公钥进行加密， 然后使用应用提供商的私钥 对加密后的数据进行签名。 步骤 S428 , 应用提供商从安全域收到 PUT KEY命令后， 验证数据签名 并使用自己的私钥对数据进行解密， 获得应用提供商从安全域的证书和可信 任才艮的公钥 , 然后应用提供商从安全域进行证书和公钥的设置。设置完成后 , 应用提供商从安全域发送 PUT KEY响应消息给应用提供商管理平台。 并且， 在上述的步骤完成后， 从安全域和应用提供商管理平台之间可以 继续进行电子支付应用的下载和安装等过程。 综上所述， 借助于本发明的技术方案， 在本发明的密钥分发系统中， 应 用提供商从安全域利用预先获得的应用提供商的公钥对卡上生成的从安全域 密钥进行加密并发送给应用提供商管理平台， 应用提供商管理平台利用预先 获得的应用提供商从安全域的公钥对应用提供商从安全域的证书和可信任根 的公钥加密并发送至所述从安全域； 卡发行商管理平台虽然负责应用提供商 管理平台和应用提供商从安全域之间的数据传输， 但卡发行商管理平台无法 获得应用提供商和应用提供商从安全域的私钥 , 因此不能对数据解密进而获 得从安全域的密钥 , 实现了对卡发行商管理平台的隔离， 有效地保证了应用 提供商从安全域密钥分发的安全性。 显然， 本领域的技术人员应该明白， 上述的本发明的各模块或各步骤可 以用通用的计算装置来实现， 它们可以集中在单个的计算装置上， 或者分布 在多个计算装置所组成的网络上， 可选地， 它们可以用计算装置可执行的程 序代码来实现， 从而， 可以将它们存储在存储装置中由计算装置来执行， 或 者将它们分别制作成各个集成电路模块， 或者将它们中的多个模块或步骤制 作成单个集成电路模块来实现。 这样， 本发明不限制于任何特定的硬件和软 件结合。 以上所述仅为本发明的优选实施例而已， 并不用于限制本发明， 对于本 领域的技术人员来说， 本发明可以有各种更改和变化。 凡在本发明的^^申和 原则之内， 所作的任何修改、 等同替换、 改进等， 均应包含在本发明的保护 范围之内。

Claims

权 利 要 求 书
1. 一种密钥分发方法， 其特征在于， 包括：
应用提供商管理平台通知所述应用提供商管理平台对应的设置于 智能卡上的应用提供商从安全域生成包括公密钥和私密钥的公私密钥 对；
所述应用提供商管理平台通过卡发行商管理平台接收来自所述应 用提供商从安全域的经过预先获得的应用提供商的公钥加密、 以及经过 设置于智能卡上的可信任第三方从安全域即 CASD签名处理的所述公密 钥；
所述应用提供商管理平台验证签名并使用所述应用提供商的私钥 进行解密得到所述公密钥；
所述应用提供商管理平台将所述应用提供商从安全域的证书和用 于外部认证的可信任才艮的公钥 , 在经过所述应用提供商从安全域的公密 钥力。密、 以及经过所述应用提供商的私钥对力。密后的数据签名处理后通 过所述卡发行商管理平台发送至所述应用提供商从安全域， 完成对所述 从安全域密钥的分发。
2. 根据权利要求 1所述的方法， 其特征在于， 在所述应用提供商管理平台 通知所述应用提供商从安全域生成所述公私密钥对的处理之前 , 所述方 法还包括：
所述应用提供商管理平台 夺所述应用提供商的证书发送至所述应 用提供商从安全域， 以使所述应用提供商从安全域验证所述应用提供商 的证书；
在所述应用提供商的证书被验证通过的情况下，执行所述应用提供 商管理平台通知所述应用提供商从安全域生成所述公私密钥对的处理。
3. 根据权利要求 2所述的方法， 其特征在于， 所述应用提供商管理平台将 所述应用提供商的证书发送至所述应用提供商从安全域的处理具体包 括：
所述应用提供商管理平台获得所述 CASD的公钥； 所述应用提供商管理平台将所述应用提供商的证书利用所述 CASD 的公钥加密， 并将加密的所述应用提供商的证书通过卡发行商管 理平台发送至所述应用提供商从安全域。
4. 根据权利要求 3所述的方法， 其特征在于， 所述应用提供商管理平台获 得所述 CASD的公钥的处理具体包括：
所述应用提供商管理平台通过所述智能卡获得所述 CASD的证书； 所述应用提供商管理平台验证所述 CASD 的证书， 并获得所述 CASD的公钥。
5. 根据权利要求 2至 4中任一项所述的方法， 其特征在于， 在所述应用提 供商的证书被所述应用提供商从安全域验证通过后 , 所述方法还包括： 所述应用提供商从安全域通过所述应用提供商的证书获得所述应 用提供商的公钥。
6. 根据权利要求 5所述的方法， 其特征在于， 所述应用提供商管理平台将 所述应用提供商从安全域的证书和用于外部认证的所述可信任才艮的公钥 发送至所述应用提供商从安全域之后， 所述方法进一步包括：
所述应用提供商从安全域接收经过加密以及签名处理的所述应用 提供商从安全域的证书和用于外部认证的可信任根的公钥；
所述应用提供商从安全域利用所述应用提供商的公钥验证签名 ,在 验证通过的情况下， 利用所述应用提供商从安全域的私钥进行解密， 获 得所述应用提供商从安全域的证书和用于外部认证的所述可信任根公 钥。
7. 才艮据权利要求 6所述的方法， 其特征在于， 所述应用提供商管理平台向 应用提供商证书中心申请所述应用提供商从安全域的证书。
8. 根据权利要求 1所述的方法， 其特征在于， 在应用提供商管理平台获得 所述 CASD的公钥之前， 所述方法进一步包括：
卡发行商管理平台在所述智能卡上创建所述应用提供商从安全域， 并将所述应用提供商从安全域的基本信息发送至所述应用提供商管理平 台， 其中， 所述基本信息包括所述应用提供商从安全域的标识信息、 所 述应用提供商从安全域的配置信息。
9. 一种密钥分发系统， 其特征在于， 包括：
卡发行商管理平台， 其进一步包括：
创建模块 , 用于在智能卡上创建应用提供商从安全域； 信息发送模块 , 用于将所述应用提供商从安全域的基本信息 发送至应用提供商管理平台， 其中， 所述基本信息包括所述应用 提供商从安全域的标识信息以及配置信息；
应用提供商管理平台， 其进一步包括：
通知模块， 用于通知所述应用提供商从安全域生成包括公密 钥和私密钥的公私密钥对；
第一接收模块 , 用于接收来自所述应用提供商从安全域的所 述公密钥， 其中， 所述公密钥经过预先获得的应用提供商的公钥 加密、 以及经过设置于智能卡上的 CASD签名处理； 第一获取模块 , 用于验证签名并使用所述应用提供商的私钥 进行解密得到所述公密钥；
第一发送模块， 用于将经过所述公密钥加密、 以及经过所述 应用提供商的私钥对加密后的数据签名的所述应用提供商从安全 域的证书和用于外部认证的可信任才艮的公钥 , 发送至所述应用提 供商从安全域；
所述智能卡，位于移动终端， 包括所述应用提供商从安全域，其中， 所述应用提供商从安全域进一步包括：
第二获取模块， 用于获取所述应用提供商的公钥；
第二发送模块， 用于将经过所述应用提供商的公钥加密、 以 及经过 CASD签名处理的所述公密钥发送至所述应用提供商管理 平台；
第二接收模块 , 用于接收经过加密以及签名处理的所述应用 提供商从安全域的证书和用于外部认证的可信任根的公钥；
解密模块， 用于将所述接收模块接收的数据利用所述应用提 供商的公钥验证签名 , 并验证通过的情况下利用所述应用提供商 从安全域的私钥进行解密， 以获得所述应用提供商从安全域的证 书和用于外部认证的所述可信任才艮公钥。
0. 根据权利要求 9所述的系统， 其特征在于， 所述智能卡还包括：
CASD, 用于验证所述应用提供商的证书以及签名所述公密钥。
PCT/CN2009/073222 2008-10-28 2009-08-12 密钥分发方法和系统 WO2010048829A1 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
KR1020117010518A KR101188529B1 (ko) 2008-10-28 2009-08-12 키 분배 방법 및 시스템
EP09823021.2A EP2341659B1 (en) 2008-10-28 2009-08-12 Key distribution method and system
US13/126,174 US8532301B2 (en) 2008-10-28 2009-08-12 Key distribution method and system
JP2011533518A JP5508428B2 (ja) 2008-10-28 2009-08-12 鍵の配布方法及びシステム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200810168359.4 2008-10-28
CN200810168359A CN101729493B (zh) 2008-10-28 2008-10-28 密钥分发方法和系统

Publications (1)

Publication Number Publication Date
WO2010048829A1 true WO2010048829A1 (zh) 2010-05-06

Family

ID=42128227

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/073222 WO2010048829A1 (zh) 2008-10-28 2009-08-12 密钥分发方法和系统

Country Status (6)

Country Link
US (1) US8532301B2 (zh)
EP (1) EP2341659B1 (zh)
JP (1) JP5508428B2 (zh)
KR (1) KR101188529B1 (zh)
CN (1) CN101729493B (zh)
WO (1) WO2010048829A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014530578A (ja) * 2011-10-14 2014-11-17 オランジュ 第１のエンティティから第２のエンティティにセキュリティモジュールの制御を移行する方法
CN105991532A (zh) * 2014-11-07 2016-10-05 天地融科技股份有限公司 数据交互方法
CN105991531A (zh) * 2014-11-07 2016-10-05 天地融科技股份有限公司 数据交互系统

Families Citing this family (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8117453B2 (en) * 2005-11-23 2012-02-14 Proton World International N.V. Customization of an electronic circuit
DE102010030590A1 (de) * 2010-06-28 2011-12-29 Bundesdruckerei Gmbh Verfahren zur Erzeugung eines Zertifikats
EP2453377A1 (en) * 2010-11-15 2012-05-16 Gemalto SA Method of loading data into a portable secure token
CN102123028A (zh) * 2011-02-28 2011-07-13 成都四方信息技术有限公司 一种随机密钥生成工作方法
CN103368735B (zh) * 2012-04-06 2018-05-04 中兴通讯股份有限公司 应用接入智能卡的认证方法、装置和系统
US9141783B2 (en) 2012-06-26 2015-09-22 Ologn Technologies Ag Systems, methods and apparatuses for the application-specific identification of devices
EP2852910B1 (en) * 2012-09-18 2018-09-05 Google LLC Systems, methods, and computer program products for interfacing multiple service provider trusted service managers and secure elements
DE102012021105A1 (de) * 2012-10-26 2014-04-30 Giesecke & Devrient Gmbh Verfahren zum Einrichten eines Containers in einem mobilen Endgerät
US8898769B2 (en) 2012-11-16 2014-11-25 At&T Intellectual Property I, Lp Methods for provisioning universal integrated circuit cards
US8959331B2 (en) 2012-11-19 2015-02-17 At&T Intellectual Property I, Lp Systems for provisioning universal integrated circuit cards
US9124582B2 (en) * 2013-02-20 2015-09-01 Fmr Llc Mobile security fob
CN103490894B (zh) * 2013-09-09 2016-08-10 飞天诚信科技股份有限公司 一种确定智能密钥设备生命周期的实现方法及装置
US9036820B2 (en) 2013-09-11 2015-05-19 At&T Intellectual Property I, Lp System and methods for UICC-based secure communication
US9124573B2 (en) 2013-10-04 2015-09-01 At&T Intellectual Property I, Lp Apparatus and method for managing use of secure tokens
US9208300B2 (en) 2013-10-23 2015-12-08 At&T Intellectual Property I, Lp Apparatus and method for secure authentication of a communication device
US9240994B2 (en) 2013-10-28 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for securely managing the accessibility to content and applications
US9313660B2 (en) 2013-11-01 2016-04-12 At&T Intellectual Property I, Lp Apparatus and method for secure provisioning of a communication device
US9240989B2 (en) 2013-11-01 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for secure over the air programming of a communication device
US9413759B2 (en) 2013-11-27 2016-08-09 At&T Intellectual Property I, Lp Apparatus and method for secure delivery of data from a communication device
US9602500B2 (en) 2013-12-20 2017-03-21 Intel Corporation Secure import and export of keying material
US9713006B2 (en) * 2014-05-01 2017-07-18 At&T Intellectual Property I, Lp Apparatus and method for managing security domains for a universal integrated circuit card
US10929843B2 (en) 2014-05-06 2021-02-23 Apple Inc. Storage of credential service provider data in a security domain of a secure element
GB2531848B (en) * 2014-10-31 2017-12-13 Hewlett Packard Entpr Dev Lp Management of cryptographic keys
US10205598B2 (en) 2015-05-03 2019-02-12 Ronald Francis Sulpizio, JR. Temporal key generation and PKI gateway
CN106899552B (zh) * 2015-12-21 2020-03-20 中国电信股份有限公司 认证方法，认证终端以及系统
CN105790938B (zh) * 2016-05-23 2019-02-19 中国银联股份有限公司 基于可信执行环境的安全单元密钥生成系统及方法
GB2550905A (en) 2016-05-27 2017-12-06 Airbus Operations Ltd Secure communications
CN108011715B (zh) * 2016-10-31 2021-03-23 华为技术有限公司 一种密钥的分发方法、相关设备和系统
CN106789074B (zh) * 2016-12-27 2020-08-25 广州智慧城市发展研究院 一种Java卡的应用身份验证方法及验证系统
CN107070667B (zh) * 2017-06-07 2020-08-04 国民认证科技（北京）有限公司 身份认证方法
CN111008094B (zh) * 2018-10-08 2023-05-05 阿里巴巴集团控股有限公司 一种数据恢复方法、设备和系统
CN109347630A (zh) * 2018-10-16 2019-02-15 航天信息股份有限公司 一种税控设备密钥分发方法及系统
CN111815816B (zh) * 2020-06-22 2022-07-05 合肥智辉空间科技有限责任公司 一种电子锁安全系统及其密钥分发方法
JP7136237B2 (ja) * 2021-01-06 2022-09-13 大日本印刷株式会社 情報処理装置及びプログラム
CN113098933B (zh) * 2021-03-23 2022-12-20 中国联合网络通信集团有限公司 一种远程安装认证应用的方法、eUICC及SM-SR

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6611913B1 (en) * 1999-03-29 2003-08-26 Verizon Laboratories Inc. Escrowed key distribution for over-the-air service provisioning in wireless communication networks
CN1841996A (zh) * 2005-03-29 2006-10-04 三星电子株式会社 保护通信内容传输的设备和方法
CN1996832A (zh) * 2006-12-01 2007-07-11 上海复旦微电子股份有限公司 用于近场通讯手机的对称密钥初始化方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1004992A3 (en) * 1997-03-24 2001-12-05 Visa International Service Association A system and method for a multi-application smart card which can facilitate a post-issuance download of an application onto the smart card
JP4536330B2 (ja) * 2003-03-06 2010-09-01 ソニー株式会社 データ処理装置、および、その方法
WO2005057507A2 (en) * 2003-12-02 2005-06-23 Koolspan, Inc Remote secure authorization
KR100471007B1 (ko) * 2004-08-27 2005-03-14 케이비 테크놀러지 (주) 시큐리티 도메인의 독립성을 보장하기 위한 스마트 카드와그 방법
US20080005567A1 (en) * 2006-01-24 2008-01-03 Stepnexus, Inc. Method and system for personalizing smart cards using asymmetric key cryptography
CN1819513A (zh) * 2006-03-23 2006-08-16 北京易恒信认证科技有限公司 Cpk id证书及其生成方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6611913B1 (en) * 1999-03-29 2003-08-26 Verizon Laboratories Inc. Escrowed key distribution for over-the-air service provisioning in wireless communication networks
CN1841996A (zh) * 2005-03-29 2006-10-04 三星电子株式会社 保护通信内容传输的设备和方法
CN1996832A (zh) * 2006-12-01 2007-07-11 上海复旦微电子股份有限公司 用于近场通讯手机的对称密钥初始化方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
WU SINAN ET AL.: "Analysis of Near Field Communication Technology", JOURNAL OF UNIVERSITY OF ELECTRONIC SCIENCE AND TECHNOLOGY OF CHINA, vol. 36, no. 6, December 2007 (2007-12-01), pages 1296 - 1299, XP008146844 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014530578A (ja) * 2011-10-14 2014-11-17 オランジュ 第１のエンティティから第２のエンティティにセキュリティモジュールの制御を移行する方法
CN105991532A (zh) * 2014-11-07 2016-10-05 天地融科技股份有限公司 数据交互方法
CN105991531A (zh) * 2014-11-07 2016-10-05 天地融科技股份有限公司 数据交互系统

Also Published As

Publication number Publication date
EP2341659A1 (en) 2011-07-06
KR101188529B1 (ko) 2012-10-08
CN101729493B (zh) 2012-09-05
JP2012507220A (ja) 2012-03-22
CN101729493A (zh) 2010-06-09
JP5508428B2 (ja) 2014-05-28
EP2341659A4 (en) 2013-04-24
KR20110083658A (ko) 2011-07-20
EP2341659B1 (en) 2014-12-24
US8532301B2 (en) 2013-09-10
US20110211699A1 (en) 2011-09-01

Similar Documents

Publication Publication Date Title
KR101188529B1 (ko) 키 분배 방법 및 시스템
CN101729244B (zh) 密钥分发方法和系统
CN107358441B (zh) 支付验证的方法、系统及移动设备和安全认证设备
CN103067914B (zh) 存在于wtru上的移动置信平台(mtp)
CN101131756B (zh) 移动支付设备电子现金充值安全认证系统、装置及方法
KR101510784B1 (ko) 보안화된 ｎｆｃ 칩셋을 개인화하는 방법
US9137221B2 (en) Method of exchanging data such as cryptographic keys between a data processing system and an electronic entity such as a microcircuit card
US8781131B2 (en) Key distribution method and system
WO2010045807A1 (zh) 密钥分发方法和系统
WO2010051715A1 (zh) 智能卡从安全域初始密钥分发方法、系统及移动终端
US20160226837A1 (en) Server for authenticating smart chip and method thereof
CN101729246B (zh) 密钥分发方法和系统
KR100757685B1 (ko) Ｐｋｉ 기반 스마트 카드용 명령어 전송 서버 인증 방법 및시스템
KR102149313B1 (ko) 유심기반 전자서명 처리 방법
KR102076313B1 (ko) 무선단말의 유심기반 전자서명 처리 방법
WO2010045825A1 (zh) 密钥分发方法和系统
CN114762290B (zh) 对数字密钥进行管理的方法和电子装置
CN103532714A (zh) 一种从数据提供方传输数据到智能卡的方法和系统
KR102149315B1 (ko) 금융사의 유심기반 전자서명 처리 방법
KR102104094B1 (ko) 인증장치, 및 단말 간의 인증을 위한 프로그램 및 그 프로그램이 기록된 컴퓨터 판독 가능 기록매체
KR20210071815A (ko) 전자 디바이스 및 전자 디바이스가 디지털 키들을 관리하는 방법
KR20150014595A (ko) 시간 검증을 이용한 엔에프씨카드 인증 방법
KR20150023150A (ko) 통신사의 유심기반 전자서명 처리 방법
KR20150023144A (ko) 유심을 이용한 전자서명 처리 방법
JP2004334783A (ja) 電子価値流通システムおよび電子価値流通方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09823021

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13126174

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2011533518

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2009823021

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 20117010518

Country of ref document: KR

Kind code of ref document: A