OMA通道-3

4 Transport API
 

传输 API 作为开放移动 API 的一部分，为开放移动设备中可用的 SE 提供通信框架

4.1 概述

传输 API 的作用是为应用程序提供访问设备上可用的 SE 的方法。 提供的访问权限基于 ISO/IEC 7816-4 [ISO 7816-4] 定义的概念：
• APDU：与 SE 交换的消息格式，基本上是字节序列，被发送到 SE（或更准确地说是 SE 中的小程序），SE 以另一个字节序列响应。 有关此类字节序列的确切格式的详细信息，请参阅 [ISO 7816-4]。
• 基本和逻辑通道：这些通道在设备上的实体和SE 上的applet 之间提供逻辑链接。 可以随时打开多个逻辑通道，OMAPI 传输层负责任何必要的访问序列化

此 API 依赖于“连接”模式。 客户端应用程序（在连接到 SE 的设备上运行，例如电话）打开到 SE 的连接（“会话”），然后打开到 SE 中运行的小程序的逻辑或基本通道。 在此模式之上，还有许多由系统强制执行的约束。 Transport API 的一个主要优点是它使用 [ISO 7816-4] 中定义的通道管理 APDU 抽象了跨多个依赖应用程序的通信通道管理。 因此，禁止应用程序自己发送“通道管理”APDU，因为这会破坏通道提供的隔离功能。 一旦打开一个通道，它就会被分配与 SE 中的一个且仅一个小程序进行通信。 同理，终端应用不能发送SELECT by DF name APDU。

系统的限制应该在直接处理与 SE 通信的模块中实现，而不是在 API 本身中实现，以确保攻击者无法克服 APDU 过滤器。 因此，如果可能，基带应负责过滤或至少负责与基带通信的 RIL。 一旦一个逻辑信道被分配给一个移动应用程序，只有来自这个移动应用程序的 APDU 命令应该在这个逻辑信道上传输。

4.1.1 General Rules for Handling of Status Word
 

此规范基于 ISO 规范，以便与跨不同部门和应用程序（银行、运输、身份等）的任何小程序正确运行。 除了 ISO 7816 之外，OMAPI 规范没有集成任何其他规范的特定行为。 这是有意为之的，可确保与任何类型的应用程序兼容。

使用传输层 T=1
API 或底层实现应按照 ISO/IEC 7816-3 [ISO 7816-3] 中的规定处理协议 T=1，并将数据（如果可用）和接收到的状态字返回给应用程序。 API 或底层实现不应在接收到任何状态字时自动发出 GET-RESPONSE APDU。

使用传输层 T=0
除非另有说明，在发送命令 APDU 时，本规范要求对本文档中定义的所有方法进行以下状态字管理：

• 对于状态字{0x61, 0xXX}，API 或底层实现应按照[ISO 7816-3] 中的规定发出GET RESPONSE 命令。 对于 SE 向 APDU 返回超过 256 字节的总体响应数据的情况，必须应用相同的行为。 如果接收到 GET RESPONSE 命令的错误 SW，则应丢弃目前收到的所有数据并返回错误 SW。
• 对于匹配{0x6C, 0xXX} 的状态字，API 或底层实现应按照[ISO 7816-3] 中的规定重新发出输入命令。 如果重新发出的命令收到错误 SW，则应丢弃目前收到的所有数据并返回错误 SW

• 对于 {0x61, 0xXX} 和 {0x6C, 0xXX} 以外的状态字，API（或底层实现）不得在内部处理接收到的状态字（例如，不得自动发送 GET RESPONSE）。 API（或底层实现）应提供状态字和数据，

• 处理状态字警告（{0x62, 0xXX} 和{0x63, 0xXX}）的具体规则

o 对于状态字 {0x62, 0xXX} 和 {0x63, 0xXX} 的 transmit() 方法，API 或底层实现应根据 setTransmitBehaviour(Boolean expectDataWithWarningSW) 方法设置的行为处理这些状态字。

o 如果有以下任何一种情况：
• openBasicChannel(byte[] aid)
• openBasicChannel(byte[] aid, byte P2)
• openLogicalChannel(byte[] aid)
• openLogicalChannel(byte[] aid, byte P2)
• 选择下一步()

如果 SW 警告 ({0x62, 0xXX}, {0x63, 0xXX}) 作为 SELECT 命令的第一个响应收到，并且与 setTransmitBehaviour(Boolean expectDataWithWarningSW) 方法中的设置无关，也应发送 Le = 0x00 的 GET RESPONSE .

请注意，上面指定的 GET RESPONSE 处理意味着 API（或底层实现）应处理响应数据，即使它超过 256 字节。

注意：打算从 Open Mobile API 使用的 Card Applets 的开发人员应该避免实现需要使用 expectDataWithWarningSW 的警告行为，以避免设备应用程序开发人员可能对案例 4 的这种特殊情况处理的操作产生混淆