1 簡(jiǎn)介

本文檔中指定的 API 使移動(dòng)應(yīng)用程序能夠訪(fǎng)問(wèn)移動(dòng)設(shè)備中的不同 SE，例如 SIM 或嵌入式 SE。 本規(guī)范提供了接口定義和 UML 圖，以允許在各種移動(dòng)平臺(tái)和不同的編程語(yǔ)言中實(shí)現(xiàn)。 如果編程語(yǔ)言支持命名空間，則它應(yīng)為 org.simalliance.openmobileapi，除非在平臺(tái)綁定文檔中明確更改。 對(duì)于過(guò)程接口，使用前綴“OMAPI_”代替

編者注：GlobalPlatform 打算在本規(guī)范的未來(lái)版本中拆分本文檔，以便提供具有一組平臺(tái)/語(yǔ)言綁定的高級(jí)功能 API 描述，作為解決圍繞平臺(tái)綁定出現(xiàn)的歧義的一種方法 在過(guò)去。 特別是，計(jì)劃將現(xiàn)有的 TEE SE API 和用于訪(fǎng)問(wèn) SE 的 WebAPI 將來(lái)成為 OMAPI 的平臺(tái)綁定，并有一個(gè)新的單獨(dú)文檔描述廣泛部署的 Java/Android 綁定。 本文檔中的一些文本——尤其是在事件處理程序方面——旨在為這種拆分鋪平道路。 本文無(wú)意在未來(lái)用于證明對(duì)已部署在市場(chǎng)上的 Open Mobile API 的平臺(tái)綁定的向后不兼容更改的合理性。

2 Architecture
?

圖 2-1 提供了 Open Mobile API 架構(gòu)的概覽。
該架構(gòu)分為以下功能層：

? 當(dāng)通過(guò)傳輸API 訪(fǎng)問(wèn)時(shí)，傳輸層為應(yīng)用程序提供對(duì)SE 的一般訪(fǎng)問(wèn)。 傳輸層使用 APDU 與 SE 通信（詳見(jiàn)第 4 節(jié)）。 在傳輸層之下是插件，它們?cè)陂_(kāi)放移動(dòng) API 的核心功能和用于與安全元素通信的低級(jí)機(jī)制之間提供接口抽象。

o Open Mobile API 與特定編程語(yǔ)言或軟件平臺(tái)的具體綁定可能會(huì)提供有關(guān)插件實(shí)現(xiàn)的特定指南。
o 每個(gè) Reader 有一個(gè)插件實(shí)例。
o 某些插件可能會(huì)提供與相關(guān)安全元件的直接和無(wú)中介通信。 但是，其他插件可以通過(guò)中間子系統(tǒng)（例如調(diào)制解調(diào)器或 RIL）進(jìn)行通信。
o 插件行為的某些方面可能超出了本文檔的范圍； 例如：錯(cuò)誤處理、電源管理和恢復(fù)策略。 插件開(kāi)發(fā)人員負(fù)責(zé)確保此類(lèi)策略不會(huì)影響使用 Open Mobile API 的應(yīng)用程序。
o 插件功能和行為將在第 7 節(jié)中進(jìn)一步討論。

? 服務(wù)層為SE 上的各種功能提供更抽象的接口。 它們可能比通用傳輸 API 更容易被應(yīng)用程序開(kāi)發(fā)人員使用。 一個(gè)示例可能是使用加密 API 的 sign() 函數(shù)并讓加密 API 與 SE 交換所有 APDU 的電子郵件應(yīng)用程序（而不是直接在電子郵件應(yīng)用程序中處理所有必需的 APDU）

注意：本文檔中的服務(wù)層已棄用

? 應(yīng)用層代表使用開(kāi)放移動(dòng)API 的各種應(yīng)用程序。

圖 2-1 顯示了在移動(dòng)設(shè)備上實(shí)現(xiàn) Open Mobile API 的可能架構(gòu)。 由于給定設(shè)備上的 Open Mobile API 實(shí)現(xiàn)的各個(gè)方面依賴(lài)于 REE 和硬件，因此此體系結(jié)構(gòu)的某些方面可能看起來(lái)因 REE 而異。 API 的描述使用抽象的面向?qū)ο蟮膱?zhí)行環(huán)境，支持聚合、異常處理、并發(fā)、回調(diào)和內(nèi)部類(lèi)。 針對(duì)不支持部分或全部這些功能的環(huán)境的映射提供了一些指導(dǎo)。 在圖 2-1 中，我們展示了啟用與安全元件連接的插件可以與托管 Open Mobile API 的執(zhí)行環(huán)境以外的執(zhí)行環(huán)境進(jìn)行通信：

? 安全元件可以通過(guò)插件連接到傳輸API，該插件使用由REE 托管和控制的物理接口。 此類(lèi)接口的示例包括 I2C、SPI 或由支持 CLF 的 REE 服務(wù)托管的 APDU 門(mén)。

? 安全元件（通常支持 UICC 功能）可以通過(guò)使用物理接口的插件連接到傳輸 API，例如 ISO/IEC 7816 中定義的接口，由調(diào)制解調(diào)器托管和控制。 在圖中，無(wú)線(xiàn)電接口層為 REE 和調(diào)制解調(diào)器之間的通信提供代理。

?? 安全元件可以通過(guò)插件連接到傳輸API，該插件使用由TEE 擁有和控制的物理接口，例如I2C 或SPI。 所呈現(xiàn)的安排展示了一種允許使用 TEE 安全元件 API 規(guī)范 [TEE SE API] 的受信任應(yīng)用程序和使用服務(wù) API 或傳輸 API 的移動(dòng)應(yīng)用程序訪(fǎng)問(wèn)安全元件的方法。 請(qǐng)注意，在這種情況下，REE 應(yīng)用程序還可以通過(guò)本身使用 TEE SE API（例如使用 TEE 客戶(hù)端 API）的受信任應(yīng)用程序與安全元件間接通信。 此類(lèi)通信超出了本文檔的范圍。

來(lái)自 REE 或其他執(zhí)行環(huán)境的安全元件連接的其他安排是有效的。 安全元件以多種形式存在，包括嵌入式安全元件、smartSD、智能 microSD、UICC、eUICC 和集成安全元件。 當(dāng)我們?cè)趫D 2-1 中提及安全元件時(shí)，我們指的是任何外形規(guī)格的符合 GlobalPlatform 標(biāo)準(zhǔn)的安全元件。 Transport API 包括一個(gè)訪(fǎng)問(wèn)控制執(zhí)行器的實(shí)現(xiàn)。 結(jié)合連接的安全元素中的 ARA 小程序和/或 ARF，這使開(kāi)放移動(dòng) API 能夠使用 GlobalPlatform 安全元素訪(fǎng)問(wèn)控制規(guī)范 ([SEAC]) 來(lái)確保執(zhí)行環(huán)境托管提供的安全級(jí)別 Access Control Enforcer，只有 SE 發(fā)行者或授權(quán) SD 所有者授權(quán)的應(yīng)用程序才能與 SE 上的小程序通信。

3 API Description
?

一般而言，本規(guī)范中描述的 API 定義了一個(gè)抽象接口，該接口使支持面向?qū)ο蟾拍?#xff08;例如異常或?qū)ο蠛蛯?shí)例）的軟件平臺(tái)能夠訪(fǎng)問(wèn) SE。 接口和數(shù)據(jù)類(lèi)型不受特定軟件平臺(tái)或編程語(yǔ)言的約束。 相反，它們是通過(guò)可以相應(yīng)地映射到相應(yīng)平臺(tái)表示的邏輯類(lèi)型來(lái)定義的。 方法描述如下： <返回值類(lèi)型> <方法名稱(chēng)> ( <parameter1 type> <parameter1 name> …) 可以定義本規(guī)范針對(duì)特定軟件平臺(tái)的具體綁定，例如： ? The Open Mobile API – Android 綁定規(guī)范【Android Binding】定義了該規(guī)范在Android平臺(tái)上的具體綁定。 ? [TEE SE API] 定義了此規(guī)范在GlobalPlatform TEE 上的具體綁定。 以下類(lèi)型用于描述返回值、參數(shù)和錯(cuò)誤。 如果平臺(tái)支持，錯(cuò)誤可能會(huì)映射到異常。

3.1 Programming Language vs. ISO 7816-4 Language Conventions
?

本文檔描述了一個(gè) API，可用于實(shí)現(xiàn)涉及設(shè)備和 SE 的用例。 在本文檔中，API 定義使用類(lèi)似 Java 的語(yǔ)言約定。 與 SE 的交互使用 ISO/IEC 7816-4 [ISO 7816-4] 中的約定。 應(yīng)特別注意以下約定：

? 使用“XX”或“xx”表示一個(gè)字節(jié)，表示為一對(duì)十六進(jìn)制數(shù)字，其中每個(gè) x 可以取以下值之一：“0”..“9”表示十進(jìn)制值 0 到 9； ‘A’..‘F’代表十進(jìn)制值 10 到 15； “X”表示 0 到 15 之間的任何十進(jìn)制值。
? 為了保證到字節(jié)的明確映射，此語(yǔ)法只能用于偶數(shù)個(gè)十六進(jìn)制數(shù)字（例如，'A34' 是非法的）。
? 一對(duì)直單引號(hào)內(nèi)可以連接無(wú)限數(shù)量的字節(jié)。

3.5 Asynchronous Notifications
?

此規(guī)范定義了 API 以啟用異步通知。 這些 API 捕獲的基本行為是觀察者模式的行為：
? 一種機(jī)制，觀察者對(duì)象可以借此向某個(gè)主題對(duì)象注冊(cè)或取消注冊(cè)。
? 一種機(jī)制，通過(guò)該機(jī)制異步通知觀察者對(duì)象某些主題對(duì)象的狀態(tài)變化。
? 主體對(duì)象向觀察者對(duì)象發(fā)起通知的機(jī)制。

在本文檔中，異步通知是根據(jù)回調(diào)定義的。 雖然它們得到廣泛支持，但它們不一定是某些系統(tǒng)上首選的異步通知機(jī)制，甚至可能不受此處定義的形式的支持。 在這種情況下，本規(guī)范與特定軟件平臺(tái)或編程語(yǔ)言的具體綁定可以提供觀察者模式的等效替代實(shí)現(xiàn)。 一些例子包括：

? 單線(xiàn)程/協(xié)作多任務(wù)軟件平臺(tái)可以使用事件隊(duì)列實(shí)現(xiàn)異步通知。
? 提供輕量級(jí)異步廣播機(jī)制的平臺(tái)可能優(yōu)先使用這些機(jī)制而不是回調(diào)。
? 消息傳遞系統(tǒng)可能會(huì)通過(guò)發(fā)送包含所需內(nèi)容的消息來(lái)實(shí)現(xiàn)異步通知