專利名稱：密鑰分發(fā)方法和系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，并且特別地，涉及一種密鑰分發(fā)方法和系統(tǒng)。
背景技術(shù)：
在相關(guān)技術(shù)中，近場通信技術(shù)(Near Field Communication,簡稱為NFC)是 工作于13. 56腿z的一種近距離無線通信技術(shù)，該技術(shù)由射頻識別(Radio Frequency Identification,簡稱為RFID)技術(shù)及互連技術(shù)融合演變而來。手機等移動通信終端在集 成NFC技術(shù)后，可以模擬非接觸式IC卡，用于電子支付的相關(guān)應(yīng)用；此外，在移動通信終端 上實現(xiàn)該方案需要在終端上增加NFC模擬前端芯片和NFC天線，并使用支持電子支付的智 能卡。 IC卡特別是非接觸式IC卡經(jīng)過十多年的發(fā)展，已經(jīng)被廣泛應(yīng)用于公交、門禁、小 額電子支付等領(lǐng)域；與此同時，手機經(jīng)歷20多年的迅速發(fā)展后，其應(yīng)用已經(jīng)基本得到普及， 并且給人們的工作及生活帶來了很大的便利，隨著手機的功能越來越強大，將手機和非接 觸式IC卡技術(shù)結(jié)合，將手機應(yīng)用于電子支付領(lǐng)域，會進一步擴大手機的使用范圍，給人們 的生活帶來便捷，存在著廣闊的應(yīng)用前景。 在相關(guān)技術(shù)中，為實現(xiàn)基于NFC技術(shù)的移動電子支付，需要建立移動終端電子支 付系統(tǒng)，并通過該系統(tǒng)實現(xiàn)對移動終端電子支付的管理，其中，移動終端電子支付系統(tǒng)包 括智能卡的發(fā)行、電子支付應(yīng)用的下載、安裝和個人化、以及采用相關(guān)技術(shù)和管理策略實 現(xiàn)電子支付的安全等。 安全域是卡外實體包括卡發(fā)行商和應(yīng)用提供商在智能卡上的代表，它們包含用 于支持安全通道協(xié)議運作以及卡內(nèi)容管理的加密密鑰，如果電子支付系統(tǒng)支持Global platform Card Specification V2. 1. 1規(guī)范，安全通道協(xié)議支持Secure Channel Protocol '02'(基于對稱密鑰)；如果電子支付系統(tǒng)支持Global platform Card Specification V2. 2規(guī)范，安全通道協(xié)議支持Secure Channel Protocol '10'(基于非對 稱密鑰)。安全域負責它們自己的密鑰管理，這保證了來自不同應(yīng)用提供者的應(yīng)用和數(shù)據(jù)可 以共存于同一個卡上。安全域的密鑰采用非對稱密鑰體制時，安全域上的密鑰和證書需要 包括安全域的公鑰(也可稱為公密鑰)和私鑰(也可稱為私密鑰)、安全域的證書、用于 認證卡外實體證書的可信任根公鑰。 應(yīng)用提供商在智能卡上的安全域為從安全域，在將應(yīng)用提供商的電子支付應(yīng)用下 載并安裝到智能卡之前，需要在智能卡上先通過卡發(fā)行商擁有的智能卡主安全域創(chuàng)建應(yīng)用 提供商的從安全域，然后設(shè)置從安全域的密鑰。 安全域密鑰作為機密數(shù)據(jù)，需要采取可靠及安全的方法和技術(shù)將有關(guān)密鑰和證書 導入到從安全域，實現(xiàn)從安全域密鑰的安全分發(fā)，其中，從安全域的創(chuàng)建需要由卡發(fā)行商管 理平臺指示智能卡上的主安全域創(chuàng)建，而且從安全域創(chuàng)建完成后，從安全域的初始密鑰需 要由卡發(fā)行商管理平臺負責設(shè)置和分發(fā)。 從安全域創(chuàng)建和密鑰分發(fā)時，采用的一種方法是智能卡和卡發(fā)行商管理平臺建立通信，應(yīng)用提供商管理平臺與卡發(fā)行商管理平臺建立通信；卡發(fā)行商管理平臺指示智能
卡主安全域建立從安全域，從安全域的公、私密鑰對由從安全域在卡上生成并發(fā)送給卡發(fā)
行商管理平臺，然后卡發(fā)行商管理平臺將從安全域生成的密鑰發(fā)送給應(yīng)用提供商管理平
臺，應(yīng)用提供商管理平臺根據(jù)從安全域的公鑰簽發(fā)從安全域的證書，再通過卡發(fā)行商管理
平臺將從安全域證書和可信任根公鑰導入到從安全域，從而完成從安全域密鑰的分發(fā)。 但在這種情況下，卡發(fā)行商管理平臺負責數(shù)據(jù)的傳送時有可能獲得發(fā)送的安全域
密鑰數(shù)據(jù)，可能使用獲得的密鑰對從安全域執(zhí)行操作，這樣會對應(yīng)用提供商的電子支付應(yīng)
用安全造成威脅。 因此，急需一種解決從安全域密鑰的分發(fā)不安全的問題的技術(shù)方案。

發(fā)明內(nèi)容
考慮到相關(guān)技術(shù)中從安全域密鑰的分發(fā)不安全的問題而做出本發(fā)明，為此，本發(fā)
明的主要目的在于提供一種密鑰分發(fā)方法和系統(tǒng)，以避免從安全域密鑰被卡發(fā)行商管理平 臺獲取導致的密鑰不安全的問題。 根據(jù)本發(fā)明的有一個方面，提供了一種密鑰分發(fā)方法。 根據(jù)本發(fā)明的密鑰分發(fā)方法包括應(yīng)用提供商管理平臺通知應(yīng)用提供商管理平臺
對應(yīng)的設(shè)置于智能卡上的應(yīng)用提供商從安全域生成包括公密鑰和私密鑰的公私密鑰對；應(yīng)
用提供商管理平臺通過卡發(fā)行商管理平臺接收來自應(yīng)用提供商從安全域的經(jīng)過預先獲得
的應(yīng)用提供商的公鑰加密、以及經(jīng)過設(shè)置于智能卡上的CASD簽名處理的公密鑰；應(yīng)用提供
商管理平臺驗證簽名并使用應(yīng)用提供商的私鑰進行解密得到公密鑰；應(yīng)用提供商管理平臺
將應(yīng)用提供商從安全域的證書和用于外部認證的可信任根的公鑰，在經(jīng)過應(yīng)用提供商從安
全域的公密鑰加密、以及經(jīng)過應(yīng)用提供商的私鑰對加密后的數(shù)據(jù)簽名處理后通過卡發(fā)行商
管理平臺發(fā)送至應(yīng)用提供商從安全域，完成對從安全域密鑰的分發(fā)。 根據(jù)本發(fā)明的另一方面，還提供了一種密鑰分發(fā)系統(tǒng)。
根據(jù)本發(fā)明的密鑰分發(fā)系統(tǒng)包括 卡發(fā)行商管理平臺，其包括 創(chuàng)建模塊，用于在智能卡上創(chuàng)建應(yīng)用提供商從安全域；信息發(fā)送模塊，用于將應(yīng)用 提供商從安全域的基本信息發(fā)送至應(yīng)用提供商管理平臺，其中，基本信息包括應(yīng)用提供商 從安全域的標識信息、應(yīng)用提供商從安全域的配置信息； 應(yīng)用提供商管理平臺，其包括通知模塊，用于通知應(yīng)用提供商管理平臺對應(yīng)的設(shè)
置于智能卡上的應(yīng)用提供商從安全域生成包括公密鑰和私密鑰的公私密鑰對；第一接收模
塊，用于接收來自應(yīng)用提供商從安全域的公密鑰，其中，公密鑰經(jīng)過預先獲得的應(yīng)用提供商
的公鑰加密、以及經(jīng)過設(shè)置于智能卡上的CASD簽名處理；第一獲取模塊，用于驗證簽名并
使用應(yīng)用提供商的私鑰進行解密得到公密鑰；第一發(fā)送模塊，用于將經(jīng)過應(yīng)用提供商從安
全域的公密鑰加密、以及經(jīng)過應(yīng)用提供商的私鑰對加密后的數(shù)據(jù)簽名的應(yīng)用提供商從安全
域的證書和用于外部認證的可信任根的公鑰，發(fā)送至應(yīng)用提供商從安全域； 智能卡，位于移動終端，包括應(yīng)用提供商從安全域，其中，應(yīng)用提供商從安全域進
一步包括第二獲取模塊，用于獲取應(yīng)用提供商的公鑰；第二發(fā)送模塊，用于將經(jīng)過應(yīng)用提
供商的公鑰加密、以及經(jīng)過CASD簽名處理的公密鑰發(fā)送至應(yīng)用提供商管理平臺；第二接收
5模塊，用于接收經(jīng)過加密以及簽名處理的應(yīng)用提供商從安全域的證書和用于外部認證的可 信任根的公鑰；解密模塊，用于將接收模塊接收的數(shù)據(jù)利用應(yīng)用提供商的公鑰驗證簽名，并 驗證通過的情況下利用應(yīng)用提供商從安全域的私鑰進行解密，以獲得應(yīng)用提供商從安全域 的證書和用于外部認證的可信任根公鑰。 通過本發(fā)明的上述技術(shù)方案，應(yīng)用提供商從安全域利用預先獲得的應(yīng)用提供商的 公鑰對卡上生成的從安全域密鑰進行加密并發(fā)送給應(yīng)用提供商管理平臺，應(yīng)用提供商管理 平臺利用預先獲得的應(yīng)用提供商從安全域的公鑰對應(yīng)用提供商從安全域的證書和可信任 根的公鑰加密并發(fā)送至所述從安全域；卡發(fā)行商管理平臺雖然負責應(yīng)用提供商管理平臺和 應(yīng)用提供商從安全域之間的數(shù)據(jù)傳輸，但卡發(fā)行商管理平臺無法獲得應(yīng)用提供商和應(yīng)用提 供商從安全域的私鑰，因此不能對數(shù)據(jù)解密以獲得從安全域的密鑰，實現(xiàn)了對卡發(fā)行商管 理平臺的隔離，有效地保證了應(yīng)用提供商從安全域密鑰分發(fā)的安全性。


此處所說明的附圖用來提供對本發(fā)明的進一步理解，構(gòu)成本申請的一部分，本發(fā)
明的示意性實施例及其說明用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的不當限定。在附圖中 圖1是根據(jù)本發(fā)明系統(tǒng)實施例的移動終端電子支付系統(tǒng)的結(jié)構(gòu)框圖； 圖2是根據(jù)本發(fā)明系統(tǒng)實施例的密鑰分發(fā)系統(tǒng)的框圖； 圖3是根據(jù)本發(fā)明方法實施例的密鑰分發(fā)方法的流程圖； 圖4是根據(jù)本發(fā)明方法實施例的密鑰分發(fā)方法的優(yōu)選處理方案的流程圖。
具體實施方式

功能概述 本發(fā)明的主要思想是應(yīng)用提供商從安全域使用預先獲得的應(yīng)用提供商的公鑰對 卡上生成的從安全域密鑰進行加密并發(fā)送給應(yīng)用提供商管理平臺；應(yīng)用提供商管理平臺預 先獲得應(yīng)用提供商從安全域的公鑰，并利用該公鑰對應(yīng)用提供商從安全域的證書和用于外 部認證的可信任根的公鑰加密并發(fā)送至所述從安全域，使得卡發(fā)行商管理平臺由于無法獲 得應(yīng)用提供商和應(yīng)用提供商從安全域的私鑰，而不能對數(shù)據(jù)進行解密，因此不能獲得從安 全域的密鑰；而智能卡上的CASD只負責證書的驗證和數(shù)據(jù)的簽名，其不掌握應(yīng)用提供商和 應(yīng)用提供商從安全域的私鑰，無法對數(shù)據(jù)進行解密，從而也不能獲得從安全域的密鑰。因此 在應(yīng)用提供商從安全域的密鑰分發(fā)過程中實現(xiàn)了對卡發(fā)行商管理平臺的隔離，有效地保證 了應(yīng)用提供商從安全域密鑰分發(fā)的安全性。 以下結(jié)合附圖對本發(fā)明的優(yōu)選實施例進行說明，應(yīng)當理解，此處所描述的優(yōu)選實
施例僅用于說明和解釋本發(fā)明，并不用于限定本發(fā)明。 系統(tǒng)實施例 如圖1所示，根據(jù)本發(fā)明實施例的移動終端電子支付系統(tǒng)主要由卡發(fā)行商管理平 臺1、應(yīng)用提供商管理平臺2和包含有智能卡的移動終端3組成，該系統(tǒng)中可以存在多個應(yīng) 用提供商管理平臺。 其中，卡發(fā)行商管理平臺1包括卡管理系統(tǒng)10、應(yīng)用管理系統(tǒng)11、密鑰管理系統(tǒng) 12、證書管理系統(tǒng)13、應(yīng)用提供商管理系統(tǒng)14，其中，證書管理系統(tǒng)13在基于近場通信技
6術(shù)的移動終端電子支付系統(tǒng)支持非對稱密鑰的情況下使用，證書管理系統(tǒng)13和卡發(fā)行商 CA(證書中心)系統(tǒng)連接；應(yīng)用管理系統(tǒng)11負責卡發(fā)行商本身的電子支付應(yīng)用或者其負責 托管的應(yīng)用的提供和管理功能；應(yīng)用提供商管理系統(tǒng)14可管理應(yīng)用提供商的有關(guān)信息，規(guī) 定應(yīng)用提供商的業(yè)務(wù)權(quán)限等。 此外，卡發(fā)行商擁有的卡發(fā)行商管理平臺1僅在支持非對稱密鑰情況下使用證書 管理系統(tǒng)13?？òl(fā)行商管理平臺1負責對卡的資源和生命周期、密鑰、證書進行管理，并負 責創(chuàng)建應(yīng)用提供商的從安全域。 應(yīng)用提供商管理平臺2包括應(yīng)用管理系統(tǒng)20、密鑰管理系統(tǒng)21、證書管理系統(tǒng)22， 其中，證書管理系統(tǒng)22在移動支付系統(tǒng)支持非對稱密鑰的情況下使用，證書管理系統(tǒng)22和 應(yīng)用提供商CA系統(tǒng)連接，并且僅在支持非對稱密鑰情況下使用證書管理系統(tǒng)22。并且，應(yīng) 用提供商可以通過應(yīng)用提供商管理平臺2提供各種業(yè)務(wù)應(yīng)用，并對卡上與其對應(yīng)的安全域 進行管理，對其安全域的應(yīng)用密鑰、證書、數(shù)據(jù)等進行控制，提供應(yīng)用的安全下載功能。應(yīng)用 提供商可以是運營商、銀行、公交公司、零售商戶等。另外，應(yīng)用提供商可擁有業(yè)務(wù)終端管理 系統(tǒng)和業(yè)務(wù)終端，并且可通過業(yè)務(wù)終端向用戶提供服務(wù)。 移動終端3中具備支持電子支付的智能卡(未示出)，并且，為了實現(xiàn)智能卡的安 全性管理和支付應(yīng)用的下載、安裝等功能，智能卡需要和卡發(fā)行商管理平臺1以及應(yīng)用提 供商管理平臺2建立通信。 實現(xiàn)智能卡和管理平臺(上述卡發(fā)行商管理平臺1和應(yīng)用提供商管理平臺2)的 通信可以通過兩個途徑(l)智能卡通過移動終端使用移動通信網(wǎng)絡(luò)和管理平臺建立通 信，一般采用空中下載(OverThe Air，簡稱為OTA)技術(shù)實現(xiàn)智能卡和管理平臺的通信。(2) 通過管理平臺的業(yè)務(wù)終端實現(xiàn)智能卡和管理平臺的連接。業(yè)務(wù)終端配置有非接觸讀卡器或 者直接讀取智能卡的讀卡器，并且業(yè)務(wù)終端可以和管理平臺建立通信，從而實現(xiàn)智能卡和 管理平臺的通信。 在上述的移動支付系統(tǒng)中，用戶能夠進行電子支付應(yīng)用的下載、安裝和使用，用戶 通過與卡發(fā)行商管理平臺或應(yīng)用提供商管理平臺交互，對移動終端和智能卡進行操作，在 安全域內(nèi)下載及安裝新的應(yīng)用，使用提供的各種業(yè)務(wù)應(yīng)用。 基于近場通信技術(shù)的移動終端電子支付系統(tǒng)支持多電子支付應(yīng)用，在智能卡上可 以安裝多個電子支付應(yīng)用。為了實現(xiàn)支付應(yīng)用的安全，智能卡采用Global Platform Card Specification V2. 1. 1/V2. 2規(guī)范，智能卡被分隔為若干個獨立的安全域，以保證多個應(yīng) 用相互之間的隔離以及獨立性，各個應(yīng)用提供商管理各自的安全域以及應(yīng)用、應(yīng)用數(shù)據(jù) 等。這里提到的支持Global Platform規(guī)范的智能卡指的是符合Global Platform Card Specification V2. 1. 1/V2. 2規(guī)范的IC芯片或智能卡，從物理形式上可以為SM/USIM卡、 可插拔的智能存儲卡或者集成在移動終端上的IC芯片。 安全域是卡外實體包括卡發(fā)行商和應(yīng)用提供商在卡上的代表，它們包含用于支持 安全通道協(xié)議運作以及卡內(nèi)容管理的加密密鑰。安全域負責它們自己的密鑰管理，這保證 了來自不同應(yīng)用提供者的應(yīng)用和數(shù)據(jù)可以共存于同一個卡上。安全域的密鑰采用非對稱密 鑰體制時，安全域上的密鑰和證書需要包括安全域的公鑰(也可稱為公密鑰)和私鑰(也 可稱為私密鑰)、安全域的證書、用于認證卡外實體證書的可信任根的公鑰。
應(yīng)用提供商在智能卡上的安全域為從安全域。在將應(yīng)用提供商的電子支付應(yīng)用下載并安裝到智能卡之前，需要在智能卡上先通過卡發(fā)行商擁有的智能卡主安全域創(chuàng)建應(yīng)用 提供商的從安全域，然后設(shè)置從安全域的密鑰。 安全域密鑰作為機密數(shù)據(jù)，需要采取可靠及安全的方法和技術(shù)將有關(guān)密鑰和證書 導入到從安全域，實現(xiàn)從安全域密鑰的安全分發(fā)。從安全域的創(chuàng)建需要由卡發(fā)行商管理平 臺指示智能卡上的主安全域創(chuàng)建，而且從安全域創(chuàng)建完成后，從安全域的初始密鑰需要由 卡發(fā)行商管理平臺負責設(shè)置和分發(fā)。 基于上述電子支付系統(tǒng)，本發(fā)明提出了一種密鑰分發(fā)系統(tǒng)。 圖2是根據(jù)本發(fā)明系統(tǒng)實施例的密鑰分發(fā)系統(tǒng)的結(jié)構(gòu)框圖，如圖2所示，根據(jù)本實 施例的密鑰分發(fā)系統(tǒng)包括卡發(fā)行商管理平臺200，應(yīng)用提供商管理平臺210和智能卡220。
卡發(fā)行商管理平臺200，其進一步包括
創(chuàng)建模塊，用于在智能卡上創(chuàng)建應(yīng)用提供商從安全域； 信息發(fā)送模塊，用于將應(yīng)用提供商從安全域的基本信息發(fā)送至應(yīng)用提供商管理平 臺，其中，基本信息包括應(yīng)用提供商從安全域的標識信息、應(yīng)用提供商從安全域的配置信
息； 在本發(fā)明中，在智能卡中下載應(yīng)用提供商的電子支付應(yīng)用以前，應(yīng)用提供商管理 平臺需要先檢查智能卡中是否存在應(yīng)用提供商的從安全域。如果不存在對應(yīng)的從安全域， 應(yīng)用提供商管理平臺需要請求卡發(fā)行商管理平臺在智能卡上創(chuàng)建屬于自己的從安全域。
應(yīng)用提供商管理平臺210，連接至卡發(fā)行商管理平臺200，其進一步包括
通知模塊，用于通知應(yīng)用提供商管理平臺對應(yīng)的設(shè)置于智能卡上的應(yīng)用提供商從 安全域生成包括公密鑰和私密鑰的公私密鑰對； 第一接收模塊，用于接收來自應(yīng)用提供商從安全域的公密鑰，其中，公密鑰經(jīng)過預
先獲得的應(yīng)用提供商的公鑰加密、以及經(jīng)過設(shè)置于智能卡上的CASD簽名處理； 第一獲取模塊，用于驗證簽名并使用應(yīng)用提供商的私鑰進行解密得到公密鑰； 第一發(fā)送模塊，用于將經(jīng)過應(yīng)用提供商從安全域的公密鑰加密、以及經(jīng)過應(yīng)用提
供商的私鑰對加密后的數(shù)據(jù)簽名的應(yīng)用提供商從安全域的證書和用于外部認證的可信任
根的公鑰，發(fā)送至應(yīng)用提供商從安全域； 智能卡220，連接至卡發(fā)行商管理平臺200，該智能卡220位于移動終端，包括應(yīng)用
提供商從安全域，其中，應(yīng)用提供商從安全域進一步包括
第二獲取模塊，用于獲取應(yīng)用提供商的公鑰； 第二發(fā)送模塊，用于將經(jīng)過應(yīng)用提供商的公鑰加密、以及經(jīng)過CASD簽名處理的公 密鑰發(fā)送至應(yīng)用提供商管理平臺； 第二接收模塊，用于接收經(jīng)過加密以及簽名處理的應(yīng)用提供商從安全域的證書和 用于外部認證的可信任根的公鑰； 解密模塊，用于將接收模塊接收的數(shù)據(jù)利用應(yīng)用提供商的公鑰驗證簽名，并驗證 通過的情況下利用應(yīng)用提供商從安全域的私鑰進行解密。 并且，智能卡220還包括CASD，其用于驗證應(yīng)用提供商的證書以及簽名公密鑰。
優(yōu)選地，在實際應(yīng)用當中，智能卡可以符合Global Platform CardSpecif ication 2. 2規(guī)范，智能卡安全域采用非對稱密鑰體制，創(chuàng)建的從安全域中需要導入的密鑰包括從 安全域的公鑰和私鑰、從安全域證書和外部認證使用的信任根公鑰(One Public Key forTrust Pointfor External Authentication, PK. TP EX. AUT)。從安全域的公鑰和私鑰由應(yīng) 用提供商從安全域在卡上生成，從安全域證書由應(yīng)用提供商管理平臺根據(jù)從安全域公鑰生 成，外部認證使用的信任根公鑰是由簽發(fā)應(yīng)用提供商證書的CA提供的，可以從應(yīng)用提供商 管理平臺獲得，該公鑰用于從安全域?qū)?yīng)用提供商的證書進行認證。從安全域的公鑰和私 鑰可以采用RSA算法生成，公鑰和私鑰的長度選擇為1024bits。 通過以上描述可以看出，在本發(fā)明的密鑰分發(fā)系統(tǒng)中，應(yīng)用提供商從安全域利用 預先獲得的應(yīng)用提供商的公鑰對卡上生成的從安全域密鑰進行加密并發(fā)送給應(yīng)用提供商 管理平臺，應(yīng)用提供商管理平臺利用預先獲得的應(yīng)用提供商從安全域的公鑰對應(yīng)用提供商 從安全域的證書和可信任根的公鑰加密并發(fā)送至所述從安全域；卡發(fā)行商管理平臺雖然負 責應(yīng)用提供商管理平臺和應(yīng)用提供商從安全域之間的數(shù)據(jù)傳輸，但卡發(fā)行商管理平臺無法 獲得應(yīng)用提供商和應(yīng)用提供商從安全域的私鑰，因此不能對數(shù)據(jù)解密以獲得從安全域的密 鑰，實現(xiàn)了對卡發(fā)行商管理平臺的隔離，有效地保證了應(yīng)用提供商從安全域密鑰分發(fā)的安 全性。 方法實施例 在本實施例中，提供了一種密鑰分發(fā)方法，應(yīng)用于包括應(yīng)用提供商的應(yīng)用提供商 管理平臺、卡發(fā)行商管理平臺和移動終端的通信系統(tǒng)。 圖3是根據(jù)本發(fā)明實施例的密鑰分發(fā)方法的流程圖，如圖3所示，該方法包括以下 處理 步驟S302，應(yīng)用提供商管理平臺通知應(yīng)用提供商管理平臺對應(yīng)的設(shè)置于智能卡上 的應(yīng)用提供商從安全域生成包括公密鑰和私密鑰的公私密鑰對； 步驟S304，應(yīng)用提供商管理平臺通過卡發(fā)行商管理平臺接收來自應(yīng)用提供商從安 全域的經(jīng)過預先獲得的應(yīng)用提供商的公鑰加密、以及經(jīng)過設(shè)置于智能卡上的可信任第三方 從安全域即CASD簽名處理的公密鑰； 步驟S306，應(yīng)用提供商管理平臺驗證簽名并使用應(yīng)用提供商的私鑰進行解密得到 公密鑰； 步驟S308，應(yīng)用提供商管理平臺將應(yīng)用提供商從安全域的證書和用于外部認證的 可信任根的公鑰，在經(jīng)過應(yīng)用提供商從安全域的公密鑰加密、以及經(jīng)過應(yīng)用提供商的私鑰 對加密后的數(shù)據(jù)簽名處理后通過卡發(fā)行商管理平臺發(fā)送至應(yīng)用提供商從安全域，完成對從 安全域密鑰的分發(fā)。 根據(jù)上述實施例，卡發(fā)行商管理平臺和CASD因為無法獲得應(yīng)用提供商和應(yīng)用提 供商從安全域的私鑰，卡發(fā)行商管理平臺和CASD無法對密鑰數(shù)據(jù)進行解密，從而無法獲得 從安全域的密鑰數(shù)據(jù)，實現(xiàn)了對卡發(fā)行商管理平臺的隔離，有效地保證了從安全域密鑰的 安全分發(fā)。 下面進一步描述上述各處理的細節(jié)。
( — )步驟S302 根據(jù)本發(fā)明，為了實現(xiàn)機密性的需要，智能卡上需要引入可信任的第三方，第三方 在智能卡上擁有Controlling Authority從安全域(CASD)，可信任的第三方通過CASD向 應(yīng)用提供商從安全域提供服務(wù)。Controlling Authority從安全域符合Global Platform CardSpecification V2. 2中的要求。CASD可以為應(yīng)用提供商從安全域提供獨立的服務(wù)接口 ，提供的服務(wù)接口包括證書驗證、簽名、數(shù)據(jù)解密等。 優(yōu)選地，可信任的第三方為給各應(yīng)用提供商簽發(fā)證書的證書中心(CA)， CA在智能 卡上擁有一個獨立的CASD。 CASD中的密鑰和證書包括CASD的公鑰和私鑰、CASD的證書、 用于驗證應(yīng)用提供商證書的CA可信任根的公鑰，CA在智能卡上的CASD的公、私鑰由CA生 成，CASD的證書由CA根據(jù)CASD的公鑰簽發(fā)生成，CA可信任根的公鑰由CA提供。CASD可 以在智能卡發(fā)行時采用安全的方式進行創(chuàng)建和初始化，由CA在CASD安全域中寫入CASD安 全域的公私鑰、證書和CA可信任根的公鑰，其中，CASD的私鑰在在智能卡上只能更新，不能 被讀取，卡發(fā)行商管理平臺和應(yīng)用提供商管理平臺無法獲得CASD的私鑰。
根據(jù)本發(fā)明，首先需要卡發(fā)行商管理平臺通知智能卡主安全域創(chuàng)建從安全域。在 從安全域創(chuàng)建后，卡發(fā)行商管理平臺將安全域的基本信息發(fā)送給應(yīng)用提供商管理平臺。
然后，應(yīng)用提供商管理平臺獲得CASD的證書，驗證CASD的證書的真實性并從證書 中獲得CASD的公鑰。應(yīng)用提供商管理平臺可以使用該公鑰將發(fā)送給應(yīng)用提供商從安全域 的數(shù)據(jù)進行加密，應(yīng)用提供商從安全域接收到加密數(shù)據(jù)后通過調(diào)用CASD提供的服務(wù)接口 對數(shù)據(jù)進行解密，CASD使用CASD的私鑰對數(shù)據(jù)進行解密，并將解密后的數(shù)據(jù)返回給應(yīng)用提 供商從安全域。 并且，應(yīng)用提供商管理平臺將自己的證書通過卡發(fā)行商管理平臺發(fā)送給應(yīng)用提供 商從安全域。應(yīng)用提供商從安全域調(diào)用CASD提供的證書驗證接口驗證應(yīng)用提供商的證書。 CASD使用CA可信任根的公鑰驗證應(yīng)用提供商的證書，如果驗證通過，則將應(yīng)用提供商的標 識信息(ID)和應(yīng)用提供商的公鑰返回給應(yīng)用提供商從安全域。 應(yīng)用提供商管理平臺通知應(yīng)用提供商從安全域在智能卡上生成包括公密鑰(公 鑰)和私密鑰(私鑰)的公私密鑰對。應(yīng)用提供商從安全域通過調(diào)用智能卡上生成密鑰的 接口產(chǎn)生公鑰和私鑰，將生成的密鑰采用應(yīng)用提供商的公鑰加密，再通過CASD安全域?qū)?密后的數(shù)據(jù)進行簽名，然后發(fā)送給應(yīng)用提供商管理平臺。
( 二 )步驟S304和步驟S306 應(yīng)用提供商管理平臺接收到來自應(yīng)用提供商從安全域的密鑰數(shù)據(jù)后，驗證簽名并
使用應(yīng)用提供商的私鑰對數(shù)據(jù)進行解密，從而獲得應(yīng)用提供商從安全域的公鑰。
(三)步驟S308 基于上述處理，應(yīng)用提供商管理平臺根據(jù)得到的應(yīng)用提供商從安全域的公鑰簽發(fā) 應(yīng)用提供商從安全域的證書，并使用應(yīng)用提供商從安全域的公鑰對應(yīng)用提供商從安全域的 證書和可信任根的公鑰進行加密、使用應(yīng)用提供商的私鑰對加密后的數(shù)據(jù)進行簽名，然后 通過報文發(fā)送給應(yīng)用提供商從安全域。 應(yīng)用提供商從安全域接收到數(shù)據(jù)后，使用應(yīng)用提供商的公鑰驗證簽名并使用應(yīng)用 提供商從安全的私鑰對數(shù)據(jù)進行解密，從而獲得安全域證書和可信任根公鑰，應(yīng)用提供商 從安全域按照報文指示進行安全域證書和可信任根公鑰的設(shè)置，從而完成應(yīng)用提供商從安 全域密鑰的分發(fā)。 通過上述描述可以得出，卡發(fā)行商管理平臺在傳輸應(yīng)用提供商管理平臺和從安全 域的通信數(shù)據(jù)時，因為不掌握應(yīng)用提供商和從安全域的私鑰，因此不能對數(shù)據(jù)解密，無法獲 得從安全域的密鑰；而對于智能卡上的CASD， CASD只負責證書的驗證和數(shù)據(jù)的簽名，它也 不掌握應(yīng)用提供商和從安全域的私鑰，無法對數(shù)據(jù)進行解密，因此也不能獲得從安全域的密鑰。通過上述實施例，實現(xiàn)了對卡發(fā)行商管理平臺的隔離，有效地保證了應(yīng)用提供商從安 全域密鑰的安全分發(fā)。 在上述過程中，應(yīng)用提供商從安全域的創(chuàng)建、密鑰的分發(fā)過程可以通過OTA的方 式實現(xiàn)，應(yīng)用提供商管理平臺、卡發(fā)行商管理平臺通過OTA方式和智能卡建立連接，通過 OTA傳輸相關(guān)命令和數(shù)據(jù)。 并且，應(yīng)用提供商從安全域的創(chuàng)建、密鑰的分發(fā)過程也可以通過卡發(fā)行商的業(yè)務(wù) 終端完成。智能卡通過卡發(fā)行商的業(yè)務(wù)終端和卡發(fā)行商管理平臺及應(yīng)用提供商管理平臺建 立連接，業(yè)務(wù)終端傳輸智能卡和管理平臺之間的命令、響應(yīng)等數(shù)據(jù)。應(yīng)用提供商發(fā)送給智能 卡的命令由卡發(fā)行商管理平臺發(fā)送給智能卡，并從卡發(fā)行商管理平臺獲得智能卡發(fā)送的響 應(yīng)。 下面將結(jié)合具體應(yīng)用實例描述根據(jù)本實施例的密鑰分發(fā)處理。 圖4是根據(jù)本發(fā)明實施例的密鑰分發(fā)方法的優(yōu)選處理方案的流程圖，如圖4所示，
該處理過程具體包括以下步驟 步驟S402，卡發(fā)行商管理平臺創(chuàng)建應(yīng)用提供商從安全域。創(chuàng)建應(yīng)用提供商從安全 域的過程可以包括 (1)卡發(fā)行商管理平臺向智能卡發(fā)送SELECT(選擇)報文，選擇智能卡的主安全 域。 (2)卡發(fā)行商管理平臺和智能卡主安全域按照Global PlatformCard Specification V2. 2附錄F Secure Channel Protocol '10'的要求建立SCP 10安全信 道，完成雙方的認證及對話密鑰的協(xié)商。 (3)卡發(fā)行商管理系統(tǒng)向主安全域發(fā)送應(yīng)用提供商從安全域創(chuàng)建報文
INSTALL[for Install]。主安全域按照報文指示創(chuàng)建應(yīng)用提供商從安全域，應(yīng)用提供商管
理平臺從安全域的ID(APSD ID)可以和應(yīng)用提供商管理平臺的ID相同。 (4)應(yīng)用提供商從安全域創(chuàng)建完成后，卡發(fā)行商管理平臺將創(chuàng)建的應(yīng)用提供商從
安全域的基本信息發(fā)送給應(yīng)用提供商管理平臺，該基本信息包括應(yīng)用提供商從安全域的
ID(APSD ID)和應(yīng)用提供商從安全域的配置信息。應(yīng)用提供商管理平臺收到應(yīng)用提供商從
安全域的基本信息后，需要在應(yīng)用提供商管理平臺的數(shù)據(jù)庫中保存應(yīng)用提供商從安全域的信息。 步驟S404，應(yīng)用提供商管理平臺從智能卡獲得智能卡CASD的證書。應(yīng)用提供商可 以向智能卡發(fā)送GET DATA(數(shù)據(jù)獲取)報文獲得CASD的證書。 步驟S406，應(yīng)用提供商管理平臺驗證CASD的證書并獲得CASD的公鑰。應(yīng)用提供 商管理平臺可以使用CA的可信任根公鑰驗證CASD證書的真實性，并從CASD的證書中獲得 CASD的公鑰。 步驟S408，應(yīng)用提供商管理平臺將自己的證書使用ST0REDATA(數(shù)據(jù)存儲)報文并
通過卡發(fā)行商管理平臺發(fā)送給應(yīng)用提供商從安全域。為了實現(xiàn)發(fā)送證書時的安全，應(yīng)用提
供商管理平臺可以使用CASD的公鑰對應(yīng)用提供商的證書進行加密。 步驟S410，應(yīng)用提供商從安全域請求CASD驗證應(yīng)用提供商的證書。 步驟S412，CASD向應(yīng)用提供商從安全域返回驗證結(jié)果、應(yīng)用提供商的ID和應(yīng)用提
供商的公鑰。
步驟S414，確定應(yīng)用提供商證書的真實性后，從安全域發(fā)送STORE DATA響應(yīng)給應(yīng) 用提供商管理平臺。 步驟S416，應(yīng)用提供商管理平臺通知應(yīng)用提供商從安全域生成公、私鑰。 步驟S418，應(yīng)用提供商從安全域通過調(diào)用卡上生成密鑰的接口產(chǎn)生公鑰和私鑰，
將生成的公鑰采用應(yīng)用提供商的公鑰加密，然后再通過CASD對加密后的數(shù)據(jù)進行簽名。 步驟S420，應(yīng)用提供商從安全域?qū)⒓用芎蟮膽?yīng)用提供商從安全域的公鑰發(fā)送給應(yīng)
用提供商管理平臺。 步驟S422，應(yīng)用提供商管理平臺驗證簽名并使用應(yīng)用提供商的私鑰解密數(shù)據(jù)，獲 得應(yīng)用提供商從安全域的公鑰。 步驟S424，應(yīng)用提供商管理平臺中的證書管理系統(tǒng)將公鑰和應(yīng)用提供商從安全域 的證書申請信息發(fā)送給應(yīng)用提供商CA， CA簽發(fā)從安全域證書后，將證書返回給證書管理系 統(tǒng)。 步驟S426，應(yīng)用提供商管理平臺通過PUT KEY(密鑰設(shè)置)命令將應(yīng)用提供商從安 全域的證書和用于外部認證的可信任根的公鑰發(fā)送給從安全域。在PUT KEY報文中，可以使 用應(yīng)用提供商從安全域的公鑰對應(yīng)用提供商從安全域的證書和可信任根的公鑰進行加密， 然后使用應(yīng)用提供商的私鑰對加密后的數(shù)據(jù)進行簽名。 步驟S428，應(yīng)用提供商從安全域收到PUT KEY命令后，驗證數(shù)據(jù)簽名并使用自己 的私鑰對數(shù)據(jù)進行解密，獲得應(yīng)用提供商從安全域的證書和可信任根的公鑰，然后應(yīng)用提 供商從安全域進行證書和公鑰的設(shè)置。設(shè)置完成后，應(yīng)用提供商從安全域發(fā)送PUT KEY響 應(yīng)消息給應(yīng)用提供商管理平臺。 并且，在上述的步驟完成后，從安全域和應(yīng)用提供商管理平臺之間可以繼續(xù)進行 電子支付應(yīng)用的下載和安裝等過程。 綜上所述，借助于本發(fā)明的技術(shù)方案，在本發(fā)明的密鑰分發(fā)系統(tǒng)中，應(yīng)用提供商從 安全域利用預先獲得的應(yīng)用提供商的公鑰對卡上生成的從安全域密鑰進行加密并發(fā)送給 應(yīng)用提供商管理平臺，應(yīng)用提供商管理平臺利用預先獲得的應(yīng)用提供商從安全域的公鑰對 應(yīng)用提供商從安全域的證書和可信任根的公鑰加密并發(fā)送至所述從安全域；卡發(fā)行商管理 平臺雖然負責應(yīng)用提供商管理平臺和應(yīng)用提供商從安全域之間的數(shù)據(jù)傳輸，但卡發(fā)行商管 理平臺無法獲得應(yīng)用提供商和應(yīng)用提供商從安全域的私鑰，因此不能對數(shù)據(jù)解密以獲得從 安全域的密鑰，實現(xiàn)了對卡發(fā)行商管理平臺的隔離，有效地保證了應(yīng)用提供商從安全域密 鑰分發(fā)的安全性。 顯然，本領(lǐng)域的技術(shù)人員應(yīng)該明白，上述的本發(fā)明的各模塊或各步驟可以用通用 的計算裝置來實現(xiàn)，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成 的網(wǎng)絡(luò)上，可選地，它們可以用計算裝置可執(zhí)行的程序代碼來實現(xiàn)，從而，可以將它們存儲 在存儲裝置中由計算裝置來執(zhí)行，或者將它們分別制作成各個集成電路模塊，或者將它們 中的多個模塊或步驟制作成單個集成電路模塊來實現(xiàn)。這樣，本發(fā)明不限制于任何特定的 硬件和軟件結(jié)合。 以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領(lǐng)域的技 術(shù)人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修 改、等同替換、改進等，均應(yīng)包含在本發(fā)明的保護范圍之內(nèi)。
1權(quán)利要求
一種密鑰分發(fā)方法，其特征在于，包括應(yīng)用提供商管理平臺通知所述應(yīng)用提供商管理平臺對應(yīng)的設(shè)置于智能卡上的應(yīng)用提供商從安全域生成包括公密鑰和私密鑰的公私密鑰對；所述應(yīng)用提供商管理平臺通過卡發(fā)行商管理平臺接收來自所述應(yīng)用提供商從安全域的經(jīng)過預先獲得的應(yīng)用提供商的公鑰加密、以及經(jīng)過設(shè)置于智能卡上的可信任第三方從安全域即CASD簽名處理的所述公密鑰；所述應(yīng)用提供商管理平臺驗證簽名并使用所述應(yīng)用提供商的私鑰進行解密得到所述公密鑰；所述應(yīng)用提供商管理平臺將所述應(yīng)用提供商從安全域的證書和用于外部認證的可信任根的公鑰，在經(jīng)過所述應(yīng)用提供商從安全域的公密鑰加密、以及經(jīng)過所述應(yīng)用提供商的私鑰對加密后的數(shù)據(jù)簽名處理后通過所述卡發(fā)行商管理平臺發(fā)送至所述應(yīng)用提供商從安全域，完成對所述從安全域密鑰的分發(fā)。
2. 根據(jù)權(quán)利要求1所述的方法，其特征在于，在所述應(yīng)用提供商管理平臺通知所述應(yīng) 用提供商從安全域生成所述公私密鑰對的處理之前，所述方法還包括所述應(yīng)用提供商管理平臺將所述應(yīng)用提供商的證書發(fā)送至所述應(yīng)用提供商從安全域， 以使所述應(yīng)用提供商從安全域驗證所述應(yīng)用提供商的證書；在所述應(yīng)用提供商的證書被驗證通過的情況下，執(zhí)行所述應(yīng)用提供商管理平臺通知所 述應(yīng)用提供商從安全域生成所述公私密鑰對的處理。
3. 根據(jù)權(quán)利要求2所述的方法，其特征在于，所述應(yīng)用提供商管理平臺將所述應(yīng)用提 供商的證書發(fā)送至所述應(yīng)用提供商從安全域的處理具體包括所述應(yīng)用提供商管理平臺獲得所述CASD的公鑰；所述應(yīng)用提供商管理平臺將所述應(yīng)用提供商的證書利用所述CASD的公鑰加密，并將 加密的所述應(yīng)用提供商的證書通過卡發(fā)行商管理平臺發(fā)送至所述應(yīng)用提供商從安全域。
4. 根據(jù)權(quán)利要求3所述的方法，其特征在于，所述應(yīng)用提供商管理平臺獲得所述CASD 的公鑰的處理具體包括所述應(yīng)用提供商管理平臺通過所述智能卡獲得所述CASD的證書； 所述應(yīng)用提供商管理平臺驗證所述CASD的證書，并獲得所述CASD的公鑰。
5. 根據(jù)權(quán)利要求2至4中任一項所述的方法，其特征在于，在所述應(yīng)用提供商的證書被 所述應(yīng)用提供商從安全域驗證通過后，所述方法還包括所述應(yīng)用提供商從安全域通過所述應(yīng)用提供商的證書獲得所述應(yīng)用提供商的公鑰。
6. 根據(jù)權(quán)利要求5所述的方法，其特征在于，所述應(yīng)用提供商管理平臺將所述應(yīng)用提 供商從安全域的證書和用于外部認證的所述可信任根的公鑰發(fā)送至所述應(yīng)用提供商從安 全域之后，所述方法進一步包括所述應(yīng)用提供商從安全域接收經(jīng)過加密以及簽名處理的所述應(yīng)用提供商從安全域的 證書和用于外部認證的可信任根的公鑰；所述應(yīng)用提供商從安全域利用所述應(yīng)用提供商的公鑰驗證簽名，在驗證通過的情況 下，利用所述應(yīng)用提供商從安全域的私鑰進行解密，獲得所述應(yīng)用提供商從安全域的證書 和用于外部認證的所述可信任根公鑰。
7. 根據(jù)權(quán)利要求6所述的方法，其特征在于，所述應(yīng)用提供商管理平臺向應(yīng)用提供商證書中心申請所述應(yīng)用提供商從安全域的證書。
8. 根據(jù)權(quán)利要求1所述的方法，其特征在于，在應(yīng)用提供商管理平臺獲得所述CASD的 公鑰之前，所述方法進一步包括卡發(fā)行商管理平臺在所述智能卡上創(chuàng)建所述應(yīng)用提供商從安全域，并將所述應(yīng)用提供 商從安全域的基本信息發(fā)送至所述應(yīng)用提供商管理平臺，其中，所述基本信息包括所述應(yīng) 用提供商從安全域的標識信息、所述應(yīng)用提供商從安全域的配置信息。
9. 一種密鑰分發(fā)系統(tǒng)，其特征在于，包括 卡發(fā)行商管理平臺，其進一步包括創(chuàng)建模塊，用于在智能卡上創(chuàng)建應(yīng)用提供商從安全域；信息發(fā)送模塊，用于將所述應(yīng)用提供商從安全域的基本信息發(fā)送至應(yīng)用提供商管理平 臺，其中，所述基本信息包括所述應(yīng)用提供商從安全域的標識信息以及配置信息； 應(yīng)用提供商管理平臺，其進一步包括通知模塊，用于通知所述應(yīng)用提供商從安全域生成包括公密鑰和私密鑰的公私密鑰對；第一接收模塊，用于接收來自所述應(yīng)用提供商從安全域的所述公密鑰，其中，所述公密 鑰經(jīng)過預先獲得的應(yīng)用提供商的公鑰加密、以及經(jīng)過設(shè)置于智能卡上的CASD簽名處理； 第一獲取模塊，用于驗證簽名并使用所述應(yīng)用提供商的私鑰進行解密得到所述公密鑰；第一發(fā)送模塊，用于將經(jīng)過所述公密鑰加密、以及經(jīng)過所述應(yīng)用提供商的私鑰對加密 后的數(shù)據(jù)簽名的所述應(yīng)用提供商從安全域的證書和用于外部認證的可信任根的公鑰，發(fā)送 至所述應(yīng)用提供商從安全域。所述智能卡，位于移動終端，包括所述應(yīng)用提供商從安全域，其中，所述應(yīng)用提供商從 安全域進一步包括第二獲取模塊，用于獲取所述應(yīng)用提供商的公鑰；第二發(fā)送模塊，用于將經(jīng)過所述應(yīng)用提供商的公鑰加密、以及經(jīng)過CASD簽名處理的所 述公密鑰發(fā)送至所述應(yīng)用提供商管理平臺；第二接收模塊，用于接收經(jīng)過加密以及簽名處理的所述應(yīng)用提供商從安全域的證書和 用于外部認證的可信任根的公鑰；解密模塊，用于將所述接收模塊接收的數(shù)據(jù)利用所述應(yīng)用提供商的公鑰驗證簽名，并 驗證通過的情況下利用所述應(yīng)用提供商從安全域的私鑰進行解密，以獲得所述應(yīng)用提供商 從安全域的證書和用于外部認證的所述可信任根公鑰。
10. 根據(jù)權(quán)利要求9所述的系統(tǒng)，其特征在于，所述智能卡還包括 CASD，用于驗證所述應(yīng)用提供商的證書以及簽名所述公密鑰。
全文摘要
本發(fā)明公開了一種密鑰分發(fā)方法和系統(tǒng)，該方法包括應(yīng)用提供商管理平臺通知應(yīng)用提供商管理平臺對應(yīng)的設(shè)置于智能卡上的應(yīng)用提供商從安全域生成包括公密鑰和私密鑰的公私密鑰對；應(yīng)用提供商管理平臺通過卡發(fā)行商管理平臺接收來自應(yīng)用提供商從安全域的經(jīng)過預先獲得的應(yīng)用提供商的公鑰加密、以及經(jīng)過設(shè)置于智能卡上的CASD簽名處理的公密鑰；應(yīng)用提供商管理平臺驗證簽名并使用應(yīng)用提供商的私鑰進行解密得到公密鑰；應(yīng)用提供商管理平臺將應(yīng)用提供商從安全域的證書和用于外部認證的可信任根的公鑰，在經(jīng)過應(yīng)用提供商從安全域的公密鑰加密、以及經(jīng)過應(yīng)用提供商的私鑰對加密后的數(shù)據(jù)簽名處理后通過卡發(fā)行商管理平臺發(fā)送至應(yīng)用提供商從安全域。
文檔編號H04L9/30GK101729493SQ200810168359
公開日2010年6月9日 申請日期2008年10月28日 優(yōu)先權(quán)日2008年10月28日
發(fā)明者余萬濤, 賈倩, 馬景旺 申請人:中興通訊股份有限公司