常 潔/Chang Jie

（中國電信股份有限公司上海研究院 上海 200122）

(China Telecom Co.,Ltd.,Shanghai Research Institute,Shanghai 200122,China)

1 引言

移動通信系統(tǒng)多使用UICC（universal integrated circuit card，通用集成電路卡）來存儲用戶的信息、鑒權密鑰、電話簿、短信數(shù)據(jù)及運營商的定制參數(shù)等信息，以便實現(xiàn)用戶身份和用戶數(shù)據(jù)的可攜帶性以及運營商間的差異化定制[1]。隨著物聯(lián)網(wǎng)技術的不斷發(fā)展，尤其是終端經(jīng)常被部署在不方便進行人工插卡或換卡的地點，為了有效地進行終端的激活、配置、碼號變更及運營商變更等操作，并且降低終端中卡被偷盜或挪用的風險，特別是適應各類應用場景和使用環(huán)境[2]，UICC的一種新形式eUICC（embedded UICC，嵌入式UICC）應運而生。eUICC具備普通插拔式UICC的全部功能，在生產過程中將UICC芯片直接焊接在物聯(lián)網(wǎng)設備上，以實現(xiàn)緊密牢固的物理連接和可靠的接口通信。

傳統(tǒng)的UICC由UICC供卡商依據(jù)MNO（mobile network operator，移動運營商）的需求（IMSI、UIMID、密鑰、認證算法及增值業(yè)務等信息）進行預配置，即UICC出廠時已經(jīng)完成數(shù)據(jù)個人化并關聯(lián)相應運營商的手機MSISDN（mobile station ISDN number，移動終端ISDN號碼），之后MNO向供卡商采購，而后由移動運營商營業(yè)廳或代售網(wǎng)點銷售給個人用戶。與此不同，eUICC是由MNO、集成商、終端商其中之一向供卡商采購，終端商將eUICC集成到其硬件設備中，集成商或行業(yè)用戶將硬件設備安裝到物聯(lián)網(wǎng)設備中，在此過程中，碼號的資源分配、激活變更及漫游繳費等方面都存在個性化的需求，尤其是在車聯(lián)網(wǎng)環(huán)境下本地化資費的需求及同一地域更換運營商的需求[3]。另外，從用戶的角度來說，如果終端用戶想要更換運營商簽約信息，就不能通過現(xiàn)有更換卡片的方式解決。面對持續(xù)增長、日益龐大的物聯(lián)網(wǎng)市場，為了能更有效地管理終端訂購，更靈活、有效地進行終端配置，GSMA（GSM association，GSM協(xié)會）、ETSI（Europeantelecommunications standards institute，歐洲電信標準協(xié)會）、3GPP（3rd generation partnership project，第3代移動通信合作伙伴計劃）和3GPP2等國際組織在eUICC的需求、技術規(guī)范、應用場景等方面開展相關研究和標準化工作。

eUICC是一種新的涉及卡的發(fā)行、管理及業(yè)務形態(tài)而建立的一系列系統(tǒng)接口及可信的運營管理系統(tǒng)架構。在此架構中，用戶簽約管理（subscription manager，SM）、終端管理、業(yè)務管理、安全管理、個人定制化管理將是其中不可或缺的功能。SM是指傳統(tǒng)運營商的OSS/BSS中使用ICCID標識卡且與OTA平臺地位一致的支撐系統(tǒng)，用于用戶及SP（service provider，業(yè)務提供商）之間的商業(yè)關系的管理（例如，遠程配置對某個運營商的訂購數(shù)據(jù)，終止對運營商服務的訂購，將服務訂購關系從一個終端設備轉移到另一個終端設備上，進行生命期管理，包括禁止嵌入式UICC上的業(yè)務功能等）。SM功能可分為2個過程實現(xiàn)：SM-DP（subscription manager datapreparation，SM數(shù)據(jù)準備）和SM-SR（subscription manager secure routing，SM安全路由）。其中，SM-DP主要負責eUICC Profile的安全生成和管理；SM-SR主要負責eUICC Profile的安全路由和傳輸，如下載、刪除、激活、去激活運營商數(shù)據(jù)、切換或準入運營商的移動網(wǎng)絡等。Profile為eUICC內部與移動網(wǎng)絡、SP或其他第三方相關的一系列文件、數(shù)據(jù)的統(tǒng)稱，包含IMSI、UIMID、ICCID、MasterKey及算法、定制的APN及QoS規(guī)則、手機支持的接入算法及優(yōu)先級、位置（MME）等信息。

通常，eUICC在出廠時會安裝一個用于接入SM-SR的PPSM-SR（SM-SR的配置Profile），用以連接到一個預置的SM-SR。SM-SR用于實現(xiàn)對OPSM-SR（SM-SR的執(zhí)行Profile）的下載等操作，該OPSM-SR是eUICC接入移動網(wǎng)絡所需要的文件。在實際應用中，eUICC中還設置有與預置 SM-SR對應的 PICSM-SR（SM-SR的Profile安裝證書），以實現(xiàn)SM-SR進行位于eUICC內部一系列OPSM-SR和（或）數(shù)據(jù)等的下載。

2 SM部署網(wǎng)絡架構

針對SM邏輯實體在實際部署環(huán)節(jié)中的架構，其網(wǎng)絡架構示意模型如圖1所示。從圖1可以看出，SM部署主要涉及的邏輯實體包括 MNO、SM-DP、SM-SR、eUICC供應商、設備供應商。SM-DP發(fā)送安全信息給它們信任的SM-SR。一個eUICC由于其預置的PPSM-SR和PICSM-SR等信息通常只可與一個 SM-SR相關，一個 SM-SR通?？梢耘c幾個SM-DP相關。SM-SR通常使用安裝在eUICC中的PICSM-SR，這些PICSM-SR被eUICC供應商們所共享。

3 現(xiàn)有需求

在本節(jié)中，將對現(xiàn)有eUICC Profile遠程配置架構的需求進行確定。

現(xiàn)有的情況是移動終端向網(wǎng)絡側提出請求，請求網(wǎng)絡側授權eUICC參數(shù)，這種方式缺少安全保護措施，使得移動終端的Profile信息在發(fā)放過程中容易被竊取，在存儲過程中都容易被復制。本文旨在解決現(xiàn)有eUICC Profile在傳輸過程中容易造成信息泄露的問題。

為了確保用戶的身份及它所持有密鑰的正確分配，公開密鑰系統(tǒng)需要一個值得信賴且獨立的第三方機構充當認證中心（certification authority，CA），以確認公鑰持有者的身份，認證中心在鑒定該人的真實身份后，頒發(fā)包含用戶公鑰的數(shù)字證書。其他用戶只要能驗證證書是否真實，并且信賴頒發(fā)證書的認證中心，就可以確認用戶的公鑰。一般而言，公鑰有兩大類用途：驗證數(shù)字簽名和加密信息。相應地，在CA系統(tǒng)中也需要配置用于數(shù)字簽名或驗證簽名的密鑰對和用于數(shù)據(jù)加密/解密的密鑰對，分別稱為簽名密鑰對和加密密鑰對。由于2種密鑰對的功能不同，管理起來也不大相同，所以在CA中為一個用戶配置2對密鑰和2張證書。

因為現(xiàn)有的Profile里包含了一些安全信息，而在配置過程中卻沒有加以保護，因此下列安全需求應該得到保障[4]。

（1）相互性

現(xiàn)有的Profile里包含了一些安全信息，而在配置過程中卻沒有加以保護，因此需要eUICC和SM-DP通過密鑰的交換對對方進行驗證。

（2）保密性

只有那些被授權的實體 Profile才能通過SM-DP發(fā)送給eUICC。

（3）完整性

eUICC和SM-DP之間所交換的數(shù)據(jù)不能被未經(jīng)授權的實體所更改。

（4）認證性

eUICC和SM-DP必須確保數(shù)據(jù)來自于已經(jīng)授權的實體。

（5）隱秘性

eUICC和SM-DP間的證書只能在Profile配置過程中所直接參與的實體間公開。

圖1 SM部署網(wǎng)絡架構示意

（6）驗證性

eUICC發(fā)送給其他實體的信息必須通過接收方進行驗證。

4 安全Profile配置架構

安全Profile配置架構包含2個過程：預配置過程和安全Profile配置過程。

4.1 預配置過程

安全 Profile配置架構包含預配置過程，在eUICC的設備生產過程中完成。通過這個過程，SM可以收集有用的信息，同時驗證eUICC的能力信息。安全Profile配置架構的預配置過程示意如圖2所示。

圖2 安全Profile配置架構的預配置過程示意

（1）預配置步驟1

eUICC供應商在生產制造 eUICC時，將PPSM-SR、PICSM-SR和eUICC所支持的加密算法、密鑰協(xié)商協(xié)議、安全通信協(xié)議、可用內存容量等信息寫入到每一個eUICC中，并在eUICC的安全模塊內部保存有一個密鑰對中的私鑰KeyPRI_A，密鑰對中的公鑰KeyPRI_B保存在eUICC認證中心。eUICC安全模塊新生成一個密鑰對中的私鑰KeyPRI_C和公鑰 KeyPRI_D，私鑰 KeyPRI_A和私鑰 KeyPRI_C均保存在eUICC安全模塊內部，不可導出。

（2）預配置步驟2

eUICC使用安全模塊內部保存的私鑰 KeyPRI_A為預配置步驟1中新生成的公鑰KeyPUB_D生成AI（authentication information，鑒別信息），然后從eUICC的安全模塊內部導出公鑰KeyPUB_D和AI，并將公鑰 KeyPUB_D和 eUICC信息合并生成 CSR（certificate signing request，證書申請文件），eUICC安全模塊使用其生成的私鑰KeyPUB_C對生成的CSR簽名，將簽名后的證書申請文件及AI發(fā)送給eUICC認證中心。

（3）預配置步驟3

eUICC認證中心使用其保存的公鑰KeyPUB_B對于公鑰KeyPUB_D和AI進行驗證，如果驗證成功，則說明公鑰KeyPUB_D是在eUICC安全模塊中生成，且CSR中的公鑰KeyPUB_D和AI沒有被替換過，eUICC認證中心可以對CSR進行簽名使它成為PMCSM-SR（SM-SR的Profile管理證書）并返回給eUICC供應商；如果對公鑰KeyPUB_D和鑒別信息AI驗證失敗，則說明證書申請文件中的公鑰 KeyPUB_D不是在eUICC安全模塊中生成，或者在傳送的過程中已經(jīng)被替換，所以eUICC認證中心不能給CSR進行簽名使它成為證書。

（4）預配置步驟4

eUICC供應商接收到PMCSM-SR后知道已經(jīng)通過eUICC認證中心的認證，將所開發(fā)的eUICC發(fā)送給設備制造商進行開發(fā)。

4.2 安全Profile配置過程

預配置過程完成后，已經(jīng)安裝好eUICC的設備可以開始配置Profile信息。安全Profile配置架構的安全配置過程示意如圖3所示。

（1）安全配置步驟1

eUICC初始接入SM-SR時使用eUICC內預置的PPSM-SR。

（2）安全配置步驟2

建立通信信道后，eUICC發(fā)送包括eUICC ID、IMEI和PICSM-SR的信息到SM-SR進行驗證，SM-SR根據(jù)上述信息確定eUICC是否為合法設備。如果SM-SR確定eUICC為合法設備，SM-SR返回確認消息接收eUICC發(fā)送的請求接入消息。

（3）安全配置步驟3

圖3 安全Profile配置架構的安全配置過程示意

eUICC根據(jù)收到的確認消息向 SM-SR發(fā)送OPSM-SR請求，所述OPSM-SR請求用于使SM-SR 獲取用于接入移動網(wǎng)絡的參數(shù)。SM-SR根據(jù)所述OPSM-SR請求向SM-DP發(fā)送OPSM-SR獲取請求，OPSM-SR獲取請求用于使SM-DP與所述移動網(wǎng)絡交互，獲取生成OPSM-SR的必要信息，SM-DP根據(jù)必要信息生成相應的 OPSM-SR，并發(fā)送采用 SM-DP安裝證書加密的OPSM-SR到SM-SR。SM-SR將加密的OPSM-SR發(fā)送到 eUICC，使得eUICC根據(jù)OPSM-SR接入相應的移動網(wǎng)絡。

（4）安全配置步驟4

eUICC的安裝方解密并驗證接收到的Profile塊。如果沒有發(fā)現(xiàn)問題，eUICC的安裝方將Profile塊配置在eUICC中，然后發(fā)送帶有MAC值的確認信息到SM-DP。這一步將不斷遞歸直至配置完成。在eUICC和SM-DP進行能力協(xié)商后，密鑰協(xié)商模塊是運行在eUICC內部用于執(zhí)行密鑰協(xié)商協(xié)議的軟件。密鑰協(xié)商模塊主要用來對需要的SM-DP證書進行協(xié)商。從安全性角度出發(fā)，除了eUICC，SM-DP證書不應該透露給任何一方，甚至是SM-SR。

5 結束語

隨著終端經(jīng)常被部署在不方便進行人工插卡或換卡的地點，嵌入式UICC將會越來越多的使用。在終端的激活、配置、碼號變更及運營商變更等各種各樣的操作方面，嵌入式UICC正以強大的技術優(yōu)勢迅速地融入物聯(lián)網(wǎng)的發(fā)展趨勢。隨著遠程文件配置可能導致的巨大安全問題，本文從現(xiàn)有的SM部署網(wǎng)絡架構出發(fā)，分析現(xiàn)有的需求，提出了安全的Profile配置架構，更好地保證了遠程文件配置的安全。

[1]姚海鵬，張智江，劉韻潔.物聯(lián)網(wǎng)嵌入式SIM卡技術初探[J].信息通信技術，2012（5）.

[2]張尼，姚海鵬.物聯(lián)網(wǎng)嵌入式智能卡遠程管理技術[J].電信工程技術與標準化，2012（6）.

[3]唐劍峰，呂志虎.增強型安全SIM卡技術方案[J].電信科學，2004（12）.

[4]PARK J，BAEK K， KANG C.SecureProfileProvisioning Architecture for Embedded UICC[A].2013 International Conference on Availability,Reliability and Security[C].2013.297-303.