專利名稱：電路卡數(shù)據(jù)保護(hù)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及電路卡，具體而言，涉及用于保護(hù)電路卡上存儲(chǔ)的數(shù)據(jù)的布置和方法。
背景技術(shù)：
諸如蜂窩電話手機(jī)之類的手持設(shè)備以及其他形式的移動(dòng)設(shè)備(ME)隨著它們功能的不斷增多已經(jīng)成為用于存儲(chǔ)和保存大量(個(gè)人)數(shù)據(jù)的流行設(shè)備/接口。這些數(shù)據(jù)可以例如包括私人照片、視頻和SMS消息，并且用戶一般可以選擇將這些數(shù)據(jù)存儲(chǔ)在ME內(nèi)，或諸如訂戶身份模塊(SIM)卡之類的通用集成電路卡(UICC)的相關(guān)部分中，或甚至由網(wǎng)絡(luò)運(yùn)營(yíng)商提供的網(wǎng)絡(luò)側(cè)存儲(chǔ)區(qū)域中，或諸如存儲(chǔ)器卡之類的其他介質(zhì)設(shè)備上?？紤]到將被存儲(chǔ)的數(shù)據(jù)的量和可能的私人/敏感性本質(zhì)，從終端用戶(end-user) 的角度，存儲(chǔ)區(qū)域應(yīng)該提供足夠的存儲(chǔ)容量、適當(dāng)?shù)陌踩约?jí)別以及易訪問(wèn)性。雖然ME本身可以被認(rèn)為是提供了適當(dāng)?shù)陌踩猿潭?，但是這樣的安全性級(jí)別傾向于與特定ME制造商有關(guān)，并且存儲(chǔ)容量被認(rèn)為不足夠用于所有類型的用戶數(shù)據(jù)(具體講，多媒體數(shù)據(jù))。同樣，對(duì)數(shù)據(jù)的可訪問(wèn)性一般也需要特定于制造商的線纜和相關(guān)的連接軟件。雖然諸如存儲(chǔ)器卡之類的設(shè)備可以提供大存儲(chǔ)容量和易訪問(wèn)性，但不存在已有裝置可用于保護(hù)用戶數(shù)據(jù)或?yàn)橛脩魯?shù)據(jù)提供適當(dāng)保護(hù)。關(guān)于網(wǎng)絡(luò)側(cè)存儲(chǔ)區(qū)域，可以實(shí)現(xiàn)高度安全性以及足夠的存儲(chǔ)容量，但是可訪問(wèn)性當(dāng)然將取決于可能無(wú)法保證的網(wǎng)絡(luò)訪問(wèn)可用性。根據(jù)近來(lái)發(fā)展，例如來(lái)源于3GPP/ETSI Rel_7，諸如UICC之類的電路卡包括潛在吸引人的存儲(chǔ)位置，支持高密度存儲(chǔ)器的UICC是可獲得的，并且根據(jù)同一規(guī)范，建議在 UICC和ME之間提供基于USB 2. 0/USB Inter-Chip的新接口，這將極大地簡(jiǎn)化和加速與 UICC的數(shù)據(jù)交換，從而使得能夠利用簡(jiǎn)單的適配器來(lái)容易地實(shí)現(xiàn)例如到PC的數(shù)據(jù)獲取。引用列表專利文獻(xiàn)PTL 1 國(guó)際專利公開 No. W02008/139615PTL 2 美國(guó)專利公開 No. 2008/254834PTL 3 美國(guó)專利公開 No. 2008/256629PTL 4 美國(guó)專利公開 No. 2008/155830

發(fā)明內(nèi)容
技術(shù)問(wèn)題但是，雖然UICC被認(rèn)為是相對(duì)安全的，尤其是通過(guò)使用個(gè)人標(biāo)識(shí)號(hào)(PIN)代碼，但是仍舊存在限制，一旦PIN得到核實(shí)(這一般僅發(fā)生在用戶希望激活USIM/GSM應(yīng)用時(shí))，所存儲(chǔ)的用戶數(shù)據(jù)則同樣可被自由地訪問(wèn)而無(wú)需任何進(jìn)一步的安全性檢查。
就是說(shuō)，一旦攜帶ME，例如，USIM已經(jīng)通過(guò)輸入正確的PIN而被適當(dāng)?shù)摹凹せ睢保瑒t存儲(chǔ)在USIM上的所有其它數(shù)據(jù)都可以被容易地訪問(wèn)，這可能是不合適的，尤其是如果只希望當(dāng)前的終端用戶具有對(duì)ME的臨時(shí)訪問(wèn)權(quán)限。國(guó)際專利公開No. W02008/139615公開了存儲(chǔ)器卡、訪問(wèn)控制系統(tǒng)和訪問(wèn)控制方法，其允許通過(guò)根據(jù)與將要下載的內(nèi)容相關(guān)聯(lián)的信息執(zhí)行訪問(wèn)管理來(lái)取決于用戶動(dòng)態(tài)改變服務(wù)范圍和提供不同服務(wù)，并且其中的電路卡包括數(shù)據(jù)管理部分并且依賴于動(dòng)態(tài)改變服務(wù)范圍而非提供安全性機(jī)制來(lái)保護(hù)卡上的數(shù)據(jù)。此外，美國(guó)專利公開No. 2008/254834,No. 2008/2566 和 No. 2008/155830 各自公開了存儲(chǔ)器卡，這些存儲(chǔ)器卡通過(guò)提供用戶標(biāo)識(shí)符的比較來(lái)提供內(nèi)容的安全存儲(chǔ)，因此表現(xiàn)出如上所述的現(xiàn)有技術(shù)的限制。本發(fā)明致力于提供具有優(yōu)于已知的卡和方法的優(yōu)勢(shì)的電路卡，并進(jìn)而提供包括這種卡的ME以及這種卡內(nèi)的數(shù)據(jù)保護(hù)方法。具體講，本發(fā)明致力于提供具有優(yōu)于已知的卡和方法的優(yōu)勢(shì)的UICC和用于對(duì) UICC中的數(shù)據(jù)提供安全性的方法。問(wèn)題的解決方案根據(jù)本發(fā)明的一個(gè)方面，提供了一種在布置用于存儲(chǔ)多個(gè)數(shù)據(jù)元素的電路卡中進(jìn)行數(shù)據(jù)保護(hù)的方法，包括基于域保護(hù)元件和密碼保護(hù)元件之一來(lái)提供保護(hù)，所述域保護(hù)元件用于定義可以對(duì)數(shù)據(jù)元素允許的操作，所述密碼保護(hù)元件用于控制對(duì)數(shù)據(jù)元素的訪問(wèn)， 其中，所述多個(gè)數(shù)據(jù)元素中的至少一個(gè)與所述域保護(hù)元件和所述密碼保護(hù)元件兩者相關(guān)聯(lián)。本發(fā)明的優(yōu)勢(shì)在于，通過(guò)提供一個(gè)或多個(gè)域保護(hù)元件，可以容易地提高存儲(chǔ)在電路卡上的數(shù)據(jù)的安全性程度，并且這種安全性程度的提高以靈活且容易適配的方式提供。因此，這樣的電路卡有利地為終端用戶提供特別是對(duì)特定于用戶的敏感數(shù)據(jù)的適當(dāng)?shù)陌踩约?jí)別、容量以及可訪問(wèn)性。安全性級(jí)別的提高是通過(guò)組合上述“密碼”和“域”特征以使得它們能夠組合提供對(duì)數(shù)據(jù)元素(例如分區(qū)、目錄或文件)的保護(hù)來(lái)提供的?！懊艽a”特征以獨(dú)立于在密碼得到核實(shí)并且允許對(duì)數(shù)據(jù)元素的訪問(wèn)的情況下可以被允許的操作的本質(zhì)的方式提供保護(hù)，而“域” 特征定義可以對(duì)諸如前述分區(qū)、目錄或文件之類的數(shù)據(jù)元素允許的可能操作。在一個(gè)特定示例中，電路卡包括UICC。此外，通過(guò)對(duì)電路卡的一個(gè)或多個(gè)應(yīng)用使用PIN訪問(wèn)代碼，可以提供額外的安全性級(jí)別。優(yōu)選地，所述多個(gè)數(shù)據(jù)元素中的每一個(gè)與域保護(hù)元件相關(guān)聯(lián)。有利地，由域保護(hù)元件所定義的允許的操作可以包括讀和/或?qū)懺L問(wèn)操作中的一個(gè)或多個(gè)。此外，根據(jù)本發(fā)明的方法，能夠訪問(wèn)電路卡中的數(shù)據(jù)的實(shí)體被布置為與唯一的標(biāo)識(shí)符相關(guān)聯(lián)。該方法還可以包括存儲(chǔ)創(chuàng)建數(shù)據(jù)元素的實(shí)體的身份。此外，關(guān)于被布置為與體現(xiàn)本發(fā)明的電路卡一起使用的ME，本方法可以包括在ME 內(nèi)識(shí)別需要訪問(wèn)所述數(shù)據(jù)的實(shí)體的步驟。
有利地，本方法使得數(shù)據(jù)保護(hù)步驟被應(yīng)用在ME和電路卡之間的USB接口類上。有利地，數(shù)據(jù)元素可以根據(jù)標(biāo)準(zhǔn)文件格式文件系統(tǒng)被存儲(chǔ)在電路卡上。此外，數(shù)據(jù)元素的創(chuàng)建和管理可以通過(guò)創(chuàng)建和管理電路卡內(nèi)的數(shù)據(jù)元素來(lái)實(shí)現(xiàn)并且可以通過(guò)ME來(lái)提供。而且，ME-電路卡接口功能可以被定義為包括創(chuàng)建功能、讀取功能、更新功能、重命名功能、移動(dòng)功能、刪除功能和清除功能中的一種或多種。根據(jù)本發(fā)明的另一方面，提供了一種被布置用于存儲(chǔ)多個(gè)受保護(hù)的數(shù)據(jù)元素的電路卡，包括所述多個(gè)受保護(hù)的數(shù)據(jù)元素中的至少一個(gè)，它們被布置為與域保護(hù)元件和密碼保護(hù)元件兩者相關(guān)聯(lián)，所述域保護(hù)元件用于定義可以對(duì)數(shù)據(jù)元素允許的操作，所述密碼保護(hù)元件用于控制對(duì)數(shù)據(jù)元素的訪問(wèn)。優(yōu)選地，電路卡包括UICC。所述至少一個(gè)數(shù)據(jù)元素可以被布置為使得需要密碼來(lái)啟動(dòng)由域保護(hù)元件所允許的操作。優(yōu)選地，多個(gè)數(shù)據(jù)元素中的每一個(gè)與域保護(hù)元件相關(guān)聯(lián)。而且，由域保護(hù)元件所定義的前述操作包括讀/寫訪問(wèn)操作中的至少一個(gè)。有利地，電路卡可以被布置為允許通過(guò)USB接口來(lái)訪問(wèn)所述數(shù)據(jù)元素。此外，電路卡可以被布置為使得所述數(shù)據(jù)元素存儲(chǔ)在該文件系統(tǒng)上的標(biāo)準(zhǔn)文件中。本發(fā)明還提供了被布置用于接收上述電路卡的ME。有利地，ME可以被布置為通過(guò)USB接口類與電路卡通信。有利地，ME可以被布置為創(chuàng)建和/或管理所存儲(chǔ)的數(shù)據(jù)元素。優(yōu)選地，ME-電路卡接口功能由創(chuàng)建功能、讀取功能、更新功能、重命名功能、移動(dòng)功能、刪除功能和清除功能中的一種或多種來(lái)定義。本發(fā)明在下文中參考附圖僅以示例方式被描述。本發(fā)明的優(yōu)勢(shì)效果根據(jù)本發(fā)明，通過(guò)提供一個(gè)或多個(gè)域保護(hù)元件，可以容易地、并甚至以一種靈活且容易適配的方式提高存儲(chǔ)在電路卡上的數(shù)據(jù)的安全性程度。


圖1是根據(jù)本發(fā)明實(shí)施例的UICC的示意性平面圖；圖2是被配置用于與圖1的UICC—起操作的、具有蜂窩電話手機(jī)形式的移動(dòng)無(wú)線電通信設(shè)備或ME的示意性平面圖；圖3是根據(jù)本發(fā)明與在UICC內(nèi)創(chuàng)建目錄有關(guān)的信令時(shí)序圖；圖4是用于創(chuàng)建用于這樣的UICC的文件的信令時(shí)序圖；圖5示出針對(duì)使用不正確的密碼嘗試讀取受保護(hù)文件的信令時(shí)序圖；以及圖6示出針對(duì)使用正確的密碼嘗試讀取受保護(hù)文件的信令時(shí)序圖。
具體實(shí)施例方式如從以上描述所了解到的，并且根據(jù)下面對(duì)特定實(shí)施例的更具體描述，本發(fā)明有利地致力于解決在當(dāng)前電路卡上存在的限制，例如那些與簡(jiǎn)單地基于PIN代碼來(lái)提供數(shù)據(jù)保護(hù)機(jī)制有關(guān)的限制。如上所述，它們主要與應(yīng)用(例如GSM/USIM)及其相關(guān)的數(shù)據(jù)(例如IMSI或PLMN列表等等)有關(guān)，并且其中不是與任意這樣的應(yīng)用直接鏈接的數(shù)據(jù)(例如， 用戶私人文件、照片、視頻、個(gè)人消息)落在相同的安全性區(qū)段內(nèi)。本發(fā)明限定了一種數(shù)據(jù)保護(hù)機(jī)制，如果需要，該機(jī)制可被與已有的PIN保護(hù)一起使用，以便為存儲(chǔ)在電路卡上的所有類型的數(shù)據(jù)提供更高的安全性級(jí)別。而且，在電路卡內(nèi)的數(shù)據(jù)存儲(chǔ)當(dāng)前是基于初級(jí)文件(Elementary File)，這些初級(jí)文件不適應(yīng)于大量數(shù)據(jù)的存儲(chǔ)。而且，這些文件通常不能用于存儲(chǔ)某些類型的數(shù)據(jù)，例如視頻和音樂(lè)文件。因此，作為本發(fā)明的一部分，建議了一種新的數(shù)據(jù)存儲(chǔ)布置，并且發(fā)現(xiàn)這種新布置特別有利于與提高的電路卡安全性相關(guān)聯(lián)的使用。首先參考圖1，提供了可以有利地體現(xiàn)本發(fā)明的一個(gè)電路卡示例的示意圖。電路卡包括UICC 10，其包括介于存儲(chǔ)區(qū)域14和ME接口 16之間的處理功能12。如下面將描述的，接口 16可以有利地基于USP 2. 0/USP hter-Chip，其簡(jiǎn)化和加速例如UICC 10與圖2的蜂窩電話手機(jī)18可以通過(guò)簡(jiǎn)單的電適配器被連接到的PC之間的數(shù)據(jù)交換。關(guān)于圖2，提供了一種移動(dòng)無(wú)線電通信設(shè)備的示意圖，該移動(dòng)無(wú)線電通信設(shè)備可以包括任意形式的移動(dòng)設(shè)備(ME)(例如蜂窩電話手機(jī)18)，并且其中提供了圖1的UICC 10以及相關(guān)聯(lián)的標(biāo)準(zhǔn)存儲(chǔ)器22、處理器20和發(fā)送/接收功能M，如圖所示的。如上所述，并且下面將進(jìn)一步論述，在蜂窩電話手機(jī)18能夠提供的各種存儲(chǔ)選項(xiàng)之中，UICC 10可以基于域安全性元件和密碼安全性元件的組合來(lái)提供非常安全的、容易訪問(wèn)的、并且適當(dāng)大的存儲(chǔ)位置。與本發(fā)明的當(dāng)前描述和定義有關(guān)，應(yīng)該意識(shí)到，“密碼”獨(dú)立地保護(hù)對(duì)文件/目錄 /分區(qū)的訪問(wèn)，一旦密碼被檢查就將允許對(duì)這些文件/目錄/分區(qū)的操作。相反，域定義 (domain define)服務(wù)于一特定實(shí)體可以對(duì)文件/目錄/分區(qū)執(zhí)行的不同的操作。因此，在一個(gè)特定示例中，每個(gè)數(shù)據(jù)元素(例如文件、目錄或甚至分區(qū))可以與一個(gè)域相關(guān)聯(lián)，并且可能受密碼保護(hù)(在相關(guān)聯(lián)的域需要密碼的情況下)?？梢蕴峁└鞣N域， 這些域具有對(duì)它們各自的允許操作的定義，并且一般以標(biāo)準(zhǔn)化方式提供，以允許互操作性。作為示例，可能的域可以如下“私人”其中只有所有者(創(chuàng)建該文件/目錄/分區(qū)的實(shí)體)可以具有訪問(wèn)權(quán)限。 一旦密碼被成功驗(yàn)證就授予所有權(quán)限?！笆芟拮x寫”其中讀寫訪問(wèn)權(quán)限被授予任意成功通過(guò)密碼檢查的實(shí)體?！笆芟拮x”其中讀訪問(wèn)權(quán)限被授予任意成功通過(guò)密碼檢查的實(shí)體?！爸蛔x”其無(wú)需密碼而可以被任意實(shí)體讀取?！肮_”其中無(wú)需密碼讀寫訪問(wèn)權(quán)限被授予任意實(shí)體。任意實(shí)體，例如特定用戶和/或能夠訪問(wèn)UICC中的數(shù)據(jù)的其他設(shè)備/裝備，被與一稱之為“entity_id”的唯一標(biāo)識(shí)符相關(guān)聯(lián)。該標(biāo)識(shí)符優(yōu)選地由UICC基于來(lái)自ME的請(qǐng)求而分配，并且“請(qǐng)求/結(jié)果”結(jié)構(gòu)可以如下從 ME 至Ij UICC :Generate_Entity_Id_Req (entity_name)從 UICC 至Ij ME :Generate_Entity_Id_Res (result, entity_name, entity_id)
“entityjame”是能夠訪問(wèn)UICC中的數(shù)據(jù)的實(shí)體的公開可獲得的名稱。該特定圖示示例建議至少如下具有它們各自的entity_name的公開實(shí)體被定義-用戶(USER)-ME (ME)-遠(yuǎn)程服務(wù)器(REM0TE_SERVER)-ME 內(nèi)的第三方應(yīng)用(ME_THIRD_PARTY)當(dāng)然應(yīng)該意識(shí)到，該列表不是窮盡的，因此可以包括其他實(shí)體?！癳ntity_id”是由UICC分配的針對(duì)給定“entity_name”的私人標(biāo)識(shí)符。"entity_name, entity_id”對(duì)將被保存在ME的存儲(chǔ)器中，并且ME將確保這些對(duì)的機(jī)密性。有利的是，ME負(fù)責(zé)準(zhǔn)確地識(shí)別發(fā)出請(qǐng)求的實(shí)體(希望訪問(wèn)UICC中的數(shù)據(jù)的實(shí)體)，例如，如果請(qǐng)求來(lái)自ME應(yīng)用，則ME將在該文檔中所定義的接口功能中使用與ME相關(guān)聯(lián)的 entity_id。ME識(shí)別不同請(qǐng)求實(shí)體的簡(jiǎn)單方式可以通過(guò)使用由ME操作系統(tǒng)分配的它們各自的線程或進(jìn)程標(biāo)識(shí)符。UICC可以依賴于如下事實(shí)由ME通過(guò)的“entity_id”是準(zhǔn)確的，因?yàn)槟承┎僮髦苯右蕾囉谠揺ntity_id。因此，從ME向UICC提供這樣的準(zhǔn)確的“entity_id”用于提高在本建議中所限定的安全性機(jī)制。當(dāng)文件/目錄/分區(qū)被創(chuàng)建時(shí)，UICC可以針對(duì)所創(chuàng)建的元素關(guān)聯(lián)“所有者”的概念。出于這個(gè)目的，UICC簡(jiǎn)單地采用在創(chuàng)建請(qǐng)求功能中所通過(guò)的“entity_id”并將其存儲(chǔ)為所創(chuàng)建的元素的所有者entity_id。該所有權(quán)的概念可以證明很重要，因?yàn)楹芏嗖僮鞫純H僅允許文件/目錄/分區(qū)的所有者(例如，在上述“私人”域中所定義的元素只允許其所有者訪問(wèn))。各種安全性接口功能可以被采用。首先，可采用設(shè)置密碼功能，其中實(shí)體可以僅針對(duì)其自身的文件/目錄/分區(qū)使用該功能。如果Uicc在接收到請(qǐng)求時(shí)意識(shí)到所接收的 entity_id與所有者entity_id不匹配，則丟棄該請(qǐng)求，并且“請(qǐng)求/結(jié)果”結(jié)構(gòu)可以如下從 ME 至Ij UICC :Set_Password_Req (entity_id, pathname, password)從 UICC 至Ij ME :Set_Password_Res (result, entity_id, pathname)entity_id被提供，以使得有利地只有文件/目錄/分區(qū)的所有者被允許執(zhí)行請(qǐng)求。路徑名(pathname)包含包括文件/目錄/分區(qū)的名稱的路徑，并且密碼(password) 包括為該文件/目錄/分區(qū)設(shè)置的密碼。最終結(jié)果將是成功或失敗。改變密碼功能可以被實(shí)體使用，但是僅針對(duì)其自身的文件/目錄/分區(qū)。如果UICC在接收到請(qǐng)求時(shí)意識(shí)到所接收的entity_id與所有者entity_id不匹配，則丟棄該請(qǐng)求，并且“請(qǐng)求/結(jié)果”結(jié)構(gòu)可以如下從 ME 至Ij UICC :Change_Password_Req (entity_id, pathname, old_password, new_ password)從 UICC 至Ij ME :Change_Password_Res (result, entity_id, pathname)除了與上述類似的參數(shù)，還采用 old_password 禾口 new_password, old_password 包含文件/目錄/分區(qū)的當(dāng)前密碼，neW_paSSWOrd包含將被設(shè)置給文件/目錄/分區(qū)的新密碼。用于核實(shí)密碼功能的請(qǐng)求/結(jié)果結(jié)構(gòu)可以如下從 ME 至Ij UICC :Verify_Password_Req (entity_id, pathname, password)從 UICC 至Ij ME :Verify_Password_Res (result, entity_id, pathname)在一種布置中，每個(gè)實(shí)體對(duì)一個(gè)給定的受保護(hù)元素(文件或目錄或分區(qū))的密碼核實(shí)的“嘗試”次數(shù)可以被限制為三次。在三次失敗的嘗試之后，該元素不能再被作出這些嘗試的實(shí)體所訪問(wèn)，直到針對(duì)該元素的訪問(wèn)條件改變?yōu)橹?例如，該元素的所有者改變或刪除密碼)。可以如下布置一實(shí)體可以僅對(duì)其自身的文件/目錄/分區(qū)使用“設(shè)置域”功能。 如果UICC在接收到請(qǐng)求時(shí)意識(shí)到所接收的entity_id與所有者entity_id不匹配，則丟棄該請(qǐng)求，并且“請(qǐng)求/結(jié)果”結(jié)構(gòu)可以如下從 ME 至Ij UICC :Set_Domain_Req (entity_id, pathname, domain)從 UICC 至Ij ME :Set_Domain_Res (result, entity_id, pathname)還可以提供獲得域功能，其具有如下“請(qǐng)求/結(jié)果”結(jié)構(gòu)從 ME 至Ij UICC :Get_Domain_Req (entity_id, pathname)從 UICC 至Ij ME Get_Domain_Res (result, entity_id, pathname, domain)此外，可以提供訪問(wèn)條件通知功能，其具有如下相應(yīng)結(jié)構(gòu)從 UICC 到 ME :Access_Condition_Notification(entity_id, pathname， condition)與上述類似的參數(shù)被采用，另外還包括condition (條件)參數(shù)，該參數(shù)包括針對(duì)由pathname所指定的元素需要核實(shí)的條件(例如，需要密碼)。一個(gè)實(shí)體標(biāo)識(shí)符創(chuàng)建功能可以被提供，其具有如下“請(qǐng)求/結(jié)果”結(jié)構(gòu)從 ME 至Ij UICC Generate_Entity_Id_Req (entity_name)從 UICC 至丨J ME :Generate_Entity_Id_Res(result, entity_name, entity_id)對(duì)于相關(guān)參數(shù)，entity_name還是包括實(shí)體的公開名稱，并且entity_id包括由 UICC為每個(gè)entity_name分配的唯一標(biāo)識(shí)符。作為對(duì)本發(fā)明的該方面的一個(gè)示例的進(jìn)一步圖示，下面是與上述可能的域相關(guān)的本發(fā)明的實(shí)現(xiàn)方式的示例。首先，用戶拍攝一照片并將圖像文件存儲(chǔ)在“/partitionl/directoryl/imagel. jpg”中。Partitionl域被定義為“受限讀寫”?！癲irectoryl ”和“ imagel. jpg”不受密碼保護(hù)。用戶或任意其他實(shí)體希望訪問(wèn)“imagel. jpg”文件，并且唯一條件是它們需要知道 “partitionl” 的密碼。作為第二示例，用戶拍攝一照片，并將圖像文件存儲(chǔ)在“/partitionl/ directoryl/imagel. jpg” 中?！皃artitionl”和“directoryl”域被定義為“公開”(因此沒有密碼)。“imagel. jpg”受密碼保護(hù)(域“受限讀”)。用戶或任意其他實(shí)體希望讀取“imagel. jpg”文件，并且唯一條件是它們需要知道 "imagel. jpg” 的密碼。
在第三示例中，用戶拍攝一照片并將圖像文件存儲(chǔ)在“/partitionl/directoryl/ image 1. jpg” 中?！皃artitionl” 域被定義為“私人”?！癲irectoryl”和“imagel. jpg” 不受密碼保護(hù)。用戶或任意其他實(shí)體希望訪問(wèn)“imagel. jpg”文件。但是，只有用戶在成功的密碼核實(shí)之后才能夠訪問(wèn)該文件。任意其他實(shí)體即使具有正確的密碼也不能訪問(wèn)該文件(因?yàn)樗膃ntity_id與所有者的entity_id不匹配)。對(duì)于第四示例，用戶拍攝一照片并將圖像文件存儲(chǔ)在“/partitionl/directoryl/ imagel. jpg” 中。“partitionl ”、“directoryl ” 和 “ imagel. jpg” 域被定義為“只讀”。對(duì)于該示例的第一操作，用戶或任意其他實(shí)體希望讀取“imagel. jpg”文件，并且文件數(shù)據(jù)可直接訪問(wèn)，因?yàn)椴恍枰艽a來(lái)讀取文件。但是，對(duì)于第二操作，用戶或任意其他實(shí)體希望更新“imagel. jpg”文件，但是只有所有者(用戶)將能夠在成功的密碼核實(shí)之后訪問(wèn)該文件。將會(huì)意識(shí)到的，本發(fā)明可以容易地考慮到如下事實(shí)未來(lái)的UICC-ME大數(shù)據(jù)操作將主要通過(guò)USB接口實(shí)現(xiàn)。因此，圖示示例針對(duì)基于USB的ME-UICC接口上的實(shí)現(xiàn)方式并且支持EEM(以太網(wǎng)仿真模式)接口類。但是，該解決方案的原理也可在其他USB接口類上應(yīng)用，例如智能卡CCID (集成電路卡接口設(shè)備)。鑒于此，應(yīng)該意識(shí)到，USB分組具有如下格式其中EEM分組包含USB分組的有效載荷。EEM分組本身具有被定義為EEM Data (EEM數(shù)據(jù))或EEM Command (EEM命令)格式的格式。EEM Command分組被用于本地USB鏈路管理，因此不能超出USB設(shè)備驅(qū)動(dòng)器層。因此，該圖示示例所定義的所有接口功能都將被封裝在EEM Data類分組的有效載荷部分中。如上所述，本發(fā)明還包括用來(lái)允許改進(jìn)的數(shù)據(jù)存儲(chǔ)的特征，以便增強(qiáng)對(duì)大尺寸/ 多媒體數(shù)據(jù)的支持，對(duì)于大尺寸/多媒體數(shù)據(jù)，當(dāng)前基于初級(jí)文件的文件系統(tǒng)具有某些限制。本發(fā)明的這方面建議用標(biāo)準(zhǔn)文件格式文件系統(tǒng)替代大多數(shù)已有的初級(jí)文件文件系統(tǒng)。為此，特定的ME-UICC接口功能被定義，以便允許ME創(chuàng)建和管理UICC中的文件/ 目錄/分區(qū)。這種ME-UICC功能的示例如下所述。用來(lái)創(chuàng)建文件/目錄/分區(qū)的Creation(創(chuàng)建)功能可以與如下“請(qǐng)求/結(jié)果”結(jié)構(gòu)相關(guān)聯(lián)。從 ME 到 UICC :Create_Element_Req (entity_id，element_type，pathname， element—parameters)從 UICC 到 ME :Create—Element_Res (result，entity—id，pathname，additional— info)這里所采用的參數(shù)可以被定義如下。-entity_id 指示發(fā)送創(chuàng)建請(qǐng)求的實(shí)體-element_type 分區(qū)或目錄或文件-pathname 包含將被創(chuàng)建的元素的“路徑+名稱”，例如，"/partition/global_directory/directoryl/imagel. jpg，，-elementparameters :特定于給定元素類型的參數(shù)(例如，在分區(qū)情況下的大小，在文件情況下的文件類型，等等)-result 包含請(qǐng)求執(zhí)行結(jié)果(成功、失敗、帶修改的成功…)-additional_info 當(dāng)UICC發(fā)送比簡(jiǎn)單的執(zhí)行結(jié)果更多的信息時(shí)，這些附加數(shù)據(jù)項(xiàng)被包括在該參數(shù)中(例如，在Uicc所創(chuàng)建的分區(qū)的大小與所請(qǐng)求的大小不同的情況下)用來(lái)讀取分區(qū)或目錄或文件的Read (讀取)功能可以與如下“請(qǐng)求/結(jié)果”結(jié)構(gòu)相關(guān)聯(lián)。從 ME 至Ij UICC :Read_Element_Req (entity_id, pathname)從 UICC 至Ij ME :Read_Element_Res (result, entity_id, pathname, data)這里，參數(shù)可以被定義如下-entity_id 指示發(fā)送讀取請(qǐng)求的實(shí)體-pathname 包含將被讀取的元素的“路徑+名稱”-result 元素讀取結(jié)果(成功或失敗)-data 包含讀取的元素的數(shù)據(jù)(例如，位于一讀取的分區(qū)/目錄下的目錄和文件的列表或在文件的情況下其自身內(nèi)容)可以提供Update (更新)功能，但是僅針對(duì)文件定義，并且與如下“請(qǐng)求/結(jié)果”結(jié)構(gòu)相關(guān)聯(lián)。從 ME 至Ij UICC :Update_File_Req (entity_id, pathname, data_type, data)從 UICC 至Ij ME :Update_File_Res (result, entity_id, pathname)這里，參數(shù)包含-entity_id 指示發(fā)送更新請(qǐng)求的實(shí)體-pathname 包含將被更新的文件的“路徑+名稱”，例如"/partition/global_directory/directoryl/imagel. jpg，，-datatype 指示文件中的數(shù)據(jù)的類型，例如，jpg、mpeg、txt等等-data:文件的內(nèi)容-result 文件更新結(jié)果(成功或失敗)Rename (重命名)功能可以與如下“請(qǐng)求/結(jié)果”結(jié)構(gòu)相關(guān)。從 ME 至Ij UICC :Rename_Element_Req (entity_id, old_pathname, new_name)從 UICC 至Ij ME Rename_E 1 ement_Res (result, entity_id, new_pathname)并且，參數(shù)可被定義為-entity_id 指示發(fā)送重命名請(qǐng)求的實(shí)體-οIcLpathname 包含將被重命名的元素的舊“路徑+名稱”-new_name 僅包含將被重命名的元素的新名稱(沒有路徑)-result 重命名執(zhí)行結(jié)果(成功或失敗)-new_pathname 包含已經(jīng)被重命名的元素的“路徑+新名稱”
Move (移動(dòng))功能可以被體現(xiàn)為從 ME 至Ij UICC :Move_Element_Req (entity_id, old_pathname, new_pathname)從 UICC 至Ij ME :Move_Element_Res (result, entity_id, new_pathname)并且，參數(shù)定義如下-entity_id 指示發(fā)送移動(dòng)請(qǐng)求的實(shí)體
-οIcLpathname 包含將被移動(dòng)的元素的舊“路徑+名稱”-new_pathname 包含已經(jīng)被被移動(dòng)的元素的新“路徑+名稱”-result 移動(dòng)執(zhí)行結(jié)果(成功或失敗)Delete (刪除)功能可以同樣提供，并且根據(jù)如下請(qǐng)求/結(jié)果結(jié)構(gòu)。從 ME 至Ij UICC :Delete_Element_Req (entity_id, pathname)從 UICC 至Ij ME :Delete_Element_Res (result, entity_id, pathname)參數(shù)定義可以如下-entity_id 指示發(fā)送刪除請(qǐng)求的實(shí)體-pathname 包含將被刪除的元素的“路徑+名稱”-result 刪除執(zhí)行結(jié)果(成功或失敗)應(yīng)該注意，如果pathname包含某些受保護(hù)的父目錄，則對(duì)于這些目錄的訪問(wèn)條件必須在處理該請(qǐng)求之前被首先滿足。還可以提供Cleaning (清除)功能，用于在所有者已經(jīng)丟失/忘記相關(guān)聯(lián)的密碼 (并因此不能訪問(wèn)該分區(qū)/目錄/文件中的任何數(shù)據(jù))的情況下刪除分區(qū)/目錄/文件。只有分區(qū)/目錄/文件的所有者可以執(zhí)行該操作。UICC必須檢查所通過(guò)的entity_id對(duì)應(yīng)于所有者entity_id，并且相關(guān)的“請(qǐng)求/ 結(jié)果”結(jié)構(gòu)如下。從 ME 至Ij UICC :Clean_Element_Req (entity_id, pathname)從 UICC 至丨J ME :Clean_Element_Res (result, entity_id, pathname)參數(shù)定義如下-entity_id 只有所有者將能夠?qū)崿F(xiàn)該請(qǐng)求-pathname 包含將被清除(S卩，刪除)的元素的“路徑+名稱”-result 清除執(zhí)行結(jié)果(成功或失敗)此外，還可以提供例如與調(diào)整分區(qū)大小相關(guān)的功能，其“請(qǐng)求/結(jié)果”結(jié)構(gòu)如下。a)調(diào)整分區(qū)大小從 ME 至Ij UICC :Resize_Partition_Req (entity_id, name, new_size)從 UICC 至Ij ME :Resize_Partition_Res (result, entity_id, new_allocated_size)相關(guān)的參數(shù)可以定義如下-entity_id 指示發(fā)送調(diào)整大小請(qǐng)求的實(shí)體-name 分區(qū)的名稱-new_size 包含該分區(qū)的新的所需存儲(chǔ)器大小-result 調(diào)整分區(qū)大小結(jié)果(成功、失敗、帶修改的成功(例如，在所分配的大小與所請(qǐng)求的大小不同的情況下))-new_allocated_size 代表由UICC分配的分區(qū)的真實(shí)存儲(chǔ)器大小當(dāng)然應(yīng)該意識(shí)到，這些接口功能可以根據(jù)需要組合提供。現(xiàn)在參考圖3，提供了與在圖1的UICC 10的存儲(chǔ)器存儲(chǔ)區(qū)域中創(chuàng)建目錄所引起的信號(hào)序列相關(guān)的信令時(shí)序圖。該信號(hào)序列是發(fā)生在終端用戶26、ME 28 (例如蜂窩電話手機(jī))和UICC 30 (例如圖1的UICC 10)之間的信號(hào)序列。
圖3所示序列開始于來(lái)自用戶沈的要在現(xiàn)有的分區(qū)/目錄中創(chuàng)建目錄的請(qǐng)求32， 因此，適當(dāng)?shù)恼?qǐng)求操作34被發(fā)送到ME 28，并且可以包含密碼名稱、域和密碼。如果要求域是“公開的”，用戶沈則不為目錄設(shè)置密碼，因此“password”參數(shù)將為
空字串。ME 沘隨后向 UICC 30 傳遞 Create_Element_Request 36，其包括 entity_id、 element_type> pathname 禾口 element_parameters0在本示例中應(yīng)該注意，為了創(chuàng)建目錄，“element—type”被設(shè)置為“目錄”，并且 “element—parameters，，具有空值。隨后通過(guò)的信令包括密碼核實(shí)序列38，其與父目錄相關(guān)，但是如果父目錄不受密碼保護(hù)則不需要該序列。但是，如果存在若干受保護(hù)的目錄級(jí)別，則必須隨后核實(shí)每個(gè)目錄的密碼。密碼核實(shí)序列38開始于access_condition_notification信號(hào)40，其包括 parent_directory_path并且還確認(rèn)需要密碼的條件。表示需要密碼的通知42被從ME 28傳遞到ME用戶26，ME用戶沈進(jìn)而向ME 28 提供回密碼 44，ME 沘進(jìn)而向 UICC 30 傳遞 verify_password_request 信號(hào) 46。UICC 30 進(jìn)而向ME沘提供verify_password_result信號(hào)48，并且隨后在UICC 30和ME沘之間發(fā)生信令交換，該信令交換包括create_element_result信號(hào)50、set_domain_request信號(hào) 52、set_domain_resu 11 信號(hào) 54、set_password_request 信號(hào) 56 禾口 set_password_result 信號(hào)58，但是應(yīng)該意識(shí)到，這樣的設(shè)置密碼功能如果密碼值為空則不會(huì)發(fā)生。該序列以從ME 28傳遞到用戶沈的創(chuàng)建目錄結(jié)果信號(hào)60結(jié)束。作為比較，參考圖4示出本發(fā)明的本實(shí)施例的特性的更多細(xì)節(jié)，圖4圖示出與文件的創(chuàng)建相關(guān)的信號(hào)序列。再次地，與用戶26、ME 28和UICC 30相關(guān)的信令被示出。在本示例中，假設(shè)終端用戶使用ME的照相機(jī)功能拍攝一照片，并決定將照片保存在現(xiàn)有的分區(qū)/目錄中。在62，作出將照片保存在現(xiàn)有的分區(qū)/目錄中的決定，因此用戶 26向移動(dòng)設(shè)備觀提供創(chuàng)建文件請(qǐng)求64，并且創(chuàng)建文件請(qǐng)求64包括與相關(guān)數(shù)據(jù)有關(guān)的路徑名、域、密碼和數(shù)據(jù)類型。隨后，create_element_request 66被從ME沘傳遞到UICC 30，并且為了創(chuàng)建文件，element_type被設(shè)置為“文件”，element_parameters包含諸如JPG或MP3之類的文件類型和數(shù)據(jù)，即文件本身的內(nèi)容。如果在68發(fā)現(xiàn)在到達(dá)要?jiǎng)?chuàng)建文件的位置之前存在受密碼保護(hù)的目錄，則每個(gè)目錄的密碼都應(yīng)該被核實(shí)，并且可以將諸如圖3所示序列之類的核實(shí)序列38與圖4的序列一起采用。就是說(shuō)，create_element_result 70被從UICC 30傳遞到ME 28，并且作為回復(fù)， set_domain_request 信號(hào) 72 被傳遞到 UICC 30，UICC 30 進(jìn)而發(fā)起 set_domain_results 信號(hào)74。假設(shè)密碼沒有被設(shè)置為“空”，則set_password_request 76被從ME觀傳遞到UICC 30，并且作為響應(yīng)，set_password_result 78被從UICC 30傳遞到ME 28。在完成ME沘和 UICC 30之間的信令交換70-78之后，創(chuàng)建文件結(jié)果指示80被ME 28提供到終端用戶26。最后參考圖5和6，這里作為比較提供了在采用正確密碼的實(shí)例(圖5)中以及在訪問(wèn)條件沒有得到滿足的實(shí)例(圖6)中與嘗試讀取受保護(hù)文件相關(guān)的信令圖。因此，首先參考圖5，適當(dāng)?shù)膶?shí)體沈在82通過(guò)向ME 28提供讀取文件84來(lái)提供該實(shí)體希望讀取在“受限讀”域中定義的文件的指示。在讀取文件指示84中的路徑名包括到將被讀取的文件的特定路徑，例如“/partition I/directory I/picture l.jpg”。read_element_request 86 隨后被從 ME 沘發(fā)送到 UICC 30。如圖5所示，密碼核實(shí)序列88被應(yīng)用到文件本身以及在前的目錄，其可以受密碼保護(hù)，在此情況下，提供例如如圖5所示的包含信令和指示90-98的密碼核實(shí)序列。最初，access_condition_notification 信號(hào) 90 被從 UICC 30 傳遞到 ME28，然后， 需要密碼指示92被從ME 28提供到實(shí)體26，實(shí)體沈返回核實(shí)密碼嘗試94，該核實(shí)密碼嘗試 94 進(jìn)而發(fā)起從 ME 28 到 UICC 30 的 verify_password_request 96。verify_password_result 98然后被從UICC 30返回到ME 28，以便完成密碼核實(shí)序列88。在已經(jīng)核實(shí)密碼的情況下，包括所需數(shù)據(jù)的讀取元素結(jié)果100被從UICC 30傳遞到ME 28，以使得包括所需數(shù)據(jù)的讀取文件結(jié)果可以被進(jìn)而傳遞(102)到請(qǐng)求實(shí)體沈?，F(xiàn)在參考圖6，所示序列與如下過(guò)程相關(guān)在104，一實(shí)體嘗試讀取由另一不同實(shí)體定義在“私人”域中的文件，并且讀取文件指示106被提供到ME 28。read_element_request 108隨后被從ME沘傳遞到UICC 30，其中，應(yīng)該意識(shí)到， entity_id不同于文件所有者的entity_id。UICC 30意識(shí)到該文件的域包含“私人”域并因此只有文件的所有者可以訪問(wèn)它。 由于接收到的entity_id與所有者的entity_id不匹配，因此在從UICC 30傳遞到ME 28 的read_element_result 110中讀取請(qǐng)求被拒絕。讀取文件結(jié)果指示112隨后被從ME 28提供到請(qǐng)求實(shí)體沈，并且結(jié)果指示讀取失敗，從而其中的數(shù)據(jù)參數(shù)為空。當(dāng)然應(yīng)該意識(shí)到，本發(fā)明并不局限于上述實(shí)施例的細(xì)節(jié)。雖然沒有明確描述用于運(yùn)行在USB智能卡ICXD接口類上的應(yīng)用的實(shí)現(xiàn)方式(其將涉及創(chuàng)建支持與該文檔中所描述的相同特征的新APDU命令)，但是如上所述的相同原理可以被應(yīng)用到這樣的IC⑶類。而且，對(duì)于涉及支持USB大容量存儲(chǔ)接口類的UICC的情形，如果由實(shí)體(例如ME) 在這樣的UICC中保存的數(shù)據(jù)元素可無(wú)需密碼核實(shí)被訪問(wèn)，S卩，數(shù)據(jù)元素本身不需要密碼， 其父數(shù)據(jù)元素也不需要密碼，那么該數(shù)據(jù)元素在被配置為并且表現(xiàn)為類似USB大容量存儲(chǔ)設(shè)備的UICC被連接到諸如PC的設(shè)備時(shí)應(yīng)該也可以被訪問(wèn)。受密碼保護(hù)的數(shù)據(jù)元素必須在UICC被配置為USB大容量存儲(chǔ)設(shè)備并被連接到不支持密碼核實(shí)過(guò)程的設(shè)備時(shí)保持無(wú)法被訪問(wèn)。因此，更詳細(xì)地，對(duì)于被體現(xiàn)為被配置為USB大容量存儲(chǔ)設(shè)備并被連接到諸如PC 之類的遠(yuǎn)程設(shè)備的UICC，該UICC可以表現(xiàn)為簡(jiǎn)單的USB記憶棒的形式。然后，在UICC上由 ME或任意其他設(shè)備已經(jīng)保存的無(wú)需密碼的(即，在上述“公開”域中的)數(shù)據(jù)元素應(yīng)該保持可在PC上訪問(wèn)。但是，對(duì)于受密碼保護(hù)的數(shù)據(jù)元素，它們?cè)诒憩F(xiàn)為記憶棒的形式的UICC被連接到 PC時(shí)保持無(wú)法被訪問(wèn)。
例如，用戶使用ME的照相機(jī)拍攝照片并將其無(wú)密碼地保存在UICC中。當(dāng)用戶隨后將UICC通過(guò)電適配器插入PC時(shí)，UICC將表現(xiàn)得像USB記憶棒，并且照片將可以在PC上被訪問(wèn)。但是，如果用戶保存照片時(shí)設(shè)置了密碼，該照片在UICC被插入PC時(shí)則將不可見?！赐ㄟ^(guò)引用并入〉本申請(qǐng)基于2009年1月16日遞交的英國(guó)專利申請(qǐng)No. 0900664. 4并要求其優(yōu)先權(quán)權(quán)益，該在先申請(qǐng)的公開內(nèi)容通過(guò)引用被整體上結(jié)合于此。標(biāo)號(hào)列表
10UICC
12處理功能
14存儲(chǔ)區(qū)域
16接口
20處理器
22標(biāo)準(zhǔn)存儲(chǔ)器
24發(fā)送/接收功能
26用戶
28ME
30UICC
32請(qǐng)求
34適當(dāng)?shù)恼?qǐng)求操作
36Create_Element_Request (創(chuàng)建兀素請(qǐng)求)
38密碼核實(shí)序列
40access_condition_notification(訪問(wèn)條件通知)信號(hào)
46verify_password_request (核實(shí)密碼請(qǐng)求)信號(hào)
48verify_password_result (核實(shí)密碼結(jié)果)信號(hào)
50create_e 1 ement_resu 11 (創(chuàng)建元素結(jié)果)信號(hào)
52set_domain_request (設(shè)置域請(qǐng)求)信號(hào)
Mset_domain_result (設(shè)置域結(jié)果)信號(hào)
56set_password_request (設(shè)置密碼請(qǐng)求)信號(hào)
60create_directory_result (倉(cāng)ij建目錄結(jié)果)信號(hào)
64create_f i le_request (倉(cāng)鍵文件請(qǐng)求)
66create_element_request (創(chuàng)建兀素請(qǐng)求)
70create_e 1 ement_resu 11 (創(chuàng)建元素結(jié)果)
72set_domain_request (設(shè)置域請(qǐng)求)信號(hào)
74set_domain_result (設(shè)置域結(jié)果)信號(hào)
76set_password_request (設(shè)置密石馬請(qǐng)求)
78set_password_result (設(shè)置密碼結(jié)果)
80文件結(jié)果指示
82指示
84讀取文件指示
86read_element_request (讀取元素請(qǐng)求)90access_condition_notification(訪問(wèn)條件通知)信號(hào)92需要密碼指示94核實(shí)密碼嘗試96verify_password_request (核實(shí)密碼請(qǐng)求)98verify_password_result (核實(shí)密碼結(jié)果)100讀取元素結(jié)果102 傳遞106讀取文件指示108read_element_request (讀取元素請(qǐng)求)110read_element_result(讀取元素結(jié)果)112讀取文件結(jié)果指示
權(quán)利要求
1.一種在布置用于存儲(chǔ)多個(gè)數(shù)據(jù)元素的電路卡中的數(shù)據(jù)保護(hù)方法，包括基于域保護(hù)元件和密碼保護(hù)元件之一來(lái)提供保護(hù)，所述域保護(hù)元件用于定義可以對(duì)數(shù)據(jù)元素允許的操作，所述密碼保護(hù)元件用于控制對(duì)數(shù)據(jù)元素的訪問(wèn)，其中，所述多個(gè)數(shù)據(jù)元素中的至少一個(gè)數(shù)據(jù)元素與所述域保護(hù)元件和所述密碼保護(hù)元件兩者相關(guān)聯(lián)。
2.如權(quán)利要求1所述的數(shù)據(jù)保護(hù)方法，其中，對(duì)于所述至少一個(gè)數(shù)據(jù)元素，需要密碼來(lái)啟動(dòng)所允許的操作，并且所述操作由所述域保護(hù)元件定義。
3.如權(quán)利要求1或2所述的數(shù)據(jù)保護(hù)方法，還包括對(duì)所述電路卡的一個(gè)或多個(gè)應(yīng)用使用PIN代碼訪問(wèn)。
4.如權(quán)利要求1到3中的任意一個(gè)所述的數(shù)據(jù)保護(hù)方法，其中，所述多個(gè)數(shù)據(jù)元素中的每一個(gè)與所述域保護(hù)元件相關(guān)聯(lián)。
5.如權(quán)利要求1所述的數(shù)據(jù)保護(hù)方法，其中，由所述域保護(hù)元件所定義的所允許的操作包括讀和/或?qū)懺L問(wèn)操作中的一個(gè)或多個(gè)。
6.如權(quán)利要求1所述的數(shù)據(jù)保護(hù)方法，其中，能夠訪問(wèn)所述電路卡上的數(shù)據(jù)的實(shí)體被與唯一的標(biāo)識(shí)符相關(guān)聯(lián)。
7.如權(quán)利要求6所述的數(shù)據(jù)保護(hù)方法，還包括存儲(chǔ)創(chuàng)建數(shù)據(jù)元素的實(shí)體的標(biāo)識(shí)符。
8.如權(quán)利要求6或7所述的數(shù)據(jù)保護(hù)方法，其中，所述電路卡被布置用于存儲(chǔ)所述數(shù)據(jù)元素的所述實(shí)體的標(biāo)識(shí)符。
9.如權(quán)利要求6、7和8中的任意一個(gè)所述的數(shù)據(jù)保護(hù)方法，其中，在ME中標(biāo)識(shí)需要訪問(wèn)所述數(shù)據(jù)的實(shí)體。
10.如權(quán)利要求1所述的數(shù)據(jù)保護(hù)方法，其中，當(dāng)在所述ME和所述電路卡之間激活USB 接口時(shí)，所述數(shù)據(jù)保護(hù)被應(yīng)用到USB接口類。
11.如權(quán)利要求1所述的數(shù)據(jù)保護(hù)方法，包括根據(jù)標(biāo)準(zhǔn)文件格式文件系統(tǒng)在所述電路卡上存儲(chǔ)數(shù)據(jù)元素。
12.如權(quán)利要求1所述的數(shù)據(jù)保護(hù)方法，其中，在所述電路卡上的數(shù)據(jù)元素的創(chuàng)建和管理受所述ME控制。
13.如權(quán)利要求1所述的數(shù)據(jù)保護(hù)方法，其中，ME電路卡接口功能被定義為包括創(chuàng)建功能、讀取功能、更新功能、重命名功能、移動(dòng)功能、刪除功能和清除功能中的一種或多種。
14.如權(quán)利要求1到13中的任意一個(gè)所述的數(shù)據(jù)保護(hù)方法，其中，所述電路卡包括UICCo
15.一種被布置用于存儲(chǔ)多個(gè)受保護(hù)的數(shù)據(jù)元素的電路卡，包括所述多個(gè)受保護(hù)的數(shù)據(jù)元素中的至少一個(gè)，它們被布置為與域保護(hù)元件和密碼保護(hù)元件兩者相關(guān)聯(lián)，所述域保護(hù)元件用于定義可以對(duì)數(shù)據(jù)元素允許的操作，所述密碼保護(hù)元件用于控制對(duì)數(shù)據(jù)元素的訪問(wèn)。
16.如權(quán)利要求15所述的電路卡，其中，需要密碼來(lái)啟動(dòng)所述域保護(hù)元件所允許的操作。
17.如權(quán)利要求15所述的電路卡，其中，所述多個(gè)數(shù)據(jù)元素中的每一個(gè)與所述域保護(hù)元件相關(guān)聯(lián)。
18.如權(quán)利要求15到17中的任意一個(gè)所述的電路卡，其中，所述電路卡被布置為允許通過(guò)USB接口類對(duì)所述數(shù)據(jù)元素的訪問(wèn)。
19.如權(quán)利要求15到18中的任意一個(gè)所述的電路卡，還包括UICC。
20.如權(quán)利要求15到19中的任意一個(gè)所述的電路卡，其中，所述電路卡被配置為USB 大容量存儲(chǔ)設(shè)備并被布置為連接到遠(yuǎn)程設(shè)備，其中，如果所述遠(yuǎn)程設(shè)備不支持密碼核實(shí)機(jī)制，則不與所述密碼保護(hù)元件相關(guān)聯(lián)的數(shù)據(jù)元素可以在所述遠(yuǎn)程設(shè)備上被訪問(wèn)，并且與所述密碼保護(hù)元件相關(guān)聯(lián)的數(shù)據(jù)元素不可以在所述遠(yuǎn)程設(shè)備上被訪問(wèn)。
21.一種被布置用于結(jié)合如權(quán)利要求15到20中的任意一個(gè)所述的電路卡操作的移動(dòng)無(wú)線電通信設(shè)備。
22.如權(quán)利要求21所述的移動(dòng)無(wú)線電通信設(shè)備，其中，所述移動(dòng)無(wú)線電通信設(shè)備被布置為通過(guò)USB接口類與所述電路卡通信。
23.如權(quán)利要求21或22所述的移動(dòng)無(wú)線電通信設(shè)備，其中，所述移動(dòng)無(wú)線電通信設(shè)備被布置為創(chuàng)建和/或管理所述所存儲(chǔ)的數(shù)據(jù)元素。
全文摘要
本發(fā)明提供了一種方法，該方法實(shí)現(xiàn)諸如UICC之類被布置用于存儲(chǔ)多個(gè)數(shù)據(jù)元素的電路卡中的數(shù)據(jù)保護(hù)并基于域保護(hù)元件和密碼保護(hù)元件來(lái)提供保護(hù)，域保護(hù)元件用于定義可以對(duì)數(shù)據(jù)元素允許的操作，密碼保護(hù)元件用于控制對(duì)數(shù)據(jù)元素的訪問(wèn)，其中，所述多個(gè)數(shù)據(jù)元素中的至少一個(gè)與域保護(hù)元件和密碼保護(hù)元件兩者相關(guān)聯(lián)，并且本發(fā)明還提供了被布置用于安全存儲(chǔ)這樣的數(shù)據(jù)元素的電路卡和被布置用于采用這樣的電路卡的ME。
文檔編號(hào)G06K19/073GK102282566SQ20098015483
公開日2011年12月14日 申請(qǐng)日期2009年12月28日 優(yōu)先權(quán)日2009年1月16日
發(fā)明者奧利維爾·董 申請(qǐng)人:日本電氣株式會(huì)社