【问题标题】:How to segment command script that is too big to fit into one transport APDU如何分割太大而无法放入一个传输 APDU 的命令脚本
【发布时间】:2021-03-01 21:52:42
【问题描述】:

SGP.02 - 嵌入式 UICC 技术规范的远程供应架构(特别是 v4.0 的第 255 页)说:

函数调用者提供的数据格式不应依赖于所选的OTA协议能力(例如SM-DP可以认为对数据长度没有限制)

以后

SM-SR 负责构建最终的命令脚本, 取决于 eUICC 功能和选择的协议:

  • 通过添加固定或不固定长度的命令脚本模板,

  • 如有必要,将提供的命令脚本分成几部分

  • 并在必要时添加相关的脚本链接 TLV。

据我了解,SM-DP 可以向ES3.SendData 发送任意长的data 参数,如果data 太大而无法容纳一个,则SM-SR 应该在多个SMS 中发送多个APDU。这就是segmenting的意思。

问题是我找不到定义应该如何进行分段的相关规范。这就是问题所在:分割过程在哪里定义?

我可能是错的,但它似乎与 ETSI TS 123 048 第 6.3 节中描述的串联短消息不同。

似乎 ETSI TS 102 226 中简要提到的脚本链接有些相关,因此也非常欢迎指向定义其工作方式的规范的指针(TS 102 226 讨论了脚本链接 TLV,但没有讨论如何使用它们,在至少我肯定错过了一些更广泛的背景它是如何工作的,所以任何提示都值得赞赏)。

更新:

ES8.EstablishISDPKeySet 函数需要发送 3 个 APDU。它们很大,因为它们包含钥匙。从 SGP.02-v4.0 表 150 我了解到它们是使用扩展远程命令格式从 SM-DP 发送到 SM-SR 的。据我了解,这种格式的脚本可能相当大(假设 SM-DP 可以假设对数据长度没有限制)。并且不清楚 SM-SR 应该如何segment 它或使用chaining。我只是错过了描述的规格。

【问题讨论】:

    标签: sms apdu ota sim-card globalplatform


    【解决方案1】:
    1. eUICC 的内部缓冲区有限,即它无法在内部存储 10kb 或更大的完整配置文件包。消息必须分块。如果 eUICC 仅支持例如1 kb 然后您必须在最多 3 个 APDU 命令之后拆分 APDU 命令以保持在 1kb 以下。 SGP.02 规范定义至少有 1024 个字节。功能齐全的 SM-SR 可能会在 EID 中存储一些基于 eUICC 供应商的属性,以便为某些 eUICC 添加特殊处理和补丁,以支持更大的缓冲区大小。

    2. 将每个 APDU 块(1..n APDU)编码为扩展远程命令格式(ETSI TS 102 226,第 5.2.1 节)(紧凑格式只能对最后一个 APDU 有一个响应,但如果它有效,你可以节省几个字节)

    3. 将每个扩展远程命令消息编码为 SMS-DELIVER(TS 123 048 和 simalliance 互操作性垫脚石版本 6)这包括使用 OTA 密钥(KiC、KID)的数据加密。 gsm0348 是一个很好的 Java 库。注意:对于每条消息,OTA 计数器必须递增。选择一个参考号码并为所有消息保留它。我想这是 eUICC 如何知道哪些消息属于一起的标识符。

    4. 如果使用 SMS(我建议改用 CAT-TP 或 HTTPs -> 更快更可靠)将其编码为 SMS-PP 下载消息 (TS 131 111)。如果负载超过 140 字节,您将在此处使用消息连接。

    5. 您将收到 SendShortMessage (TS 131 111, 6.4.10) 作为响应。使用 TS 123 048 和 simalliance Interoperability Stepping Stones 版本 6 再次提取用户数据。您将收到 SMS 响应消息。查看响应包以获取用户数据。

    6. 将用户数据提取为扩展远程响应 (ETSI TS 102 226)

    eUICC 将处理流式消息。串接的短消息仅用于在传输过程中属于一起的消息块。

    【讨论】:

    • 谢谢。我在答案和规格中遗漏了什么是APDU chunk。它是在哪里描述的?
    • 我已经为我的问题添加了一个澄清(我希望)。
    • 块没有在任何地方定义 AFAIK。也许在某个地方定义了一个最小的内部 eUICC 缓冲区,您可以假设它被处理。你必须提前知道。假设 1kb 应该是安全的。但就像说的短信不是最好的选择。
    • 抱歉,还不清楚。当 SM-SR 接收到长的扩展远程命令格式(比 eUICC 支持的时间长)时,它应该如何将该数据拆分成片段?您是否想说当 SM-SR 获得一个大型扩展远程命令格式脚本时,它需要通过将命令列表拆分为多个命令列表来创建几个较小的脚本?并通过 ES5 将它们作为单独的消息发送?
    • 该规范引用了很多 ETSI 和 GP 规范。这些又是指其他规格。以某种方式提到了所有内容,但是如果没有完整的图片,太多的未知数会使规范变得非常模糊。
    【解决方案2】:

    详细解释分段和脚本链接如何工作的最佳规范是 SGP.11 Remote Provisioning Architecture for Embedded UICC Test Specification

    它本身没有要求,但它具有传入ES3.SendData 的字节级示例和eUICC 接收到的消息示例。这可以很容易地推断出 SM-SR 的实际行为。

    这里是参考该规范的更详细的解释。

    命令脚本

    命令脚本是在 ES3.SendData 的数据字段中发送的命令列表。它可以是(参见 SGP.02-v4.0 表 150 中的data 字段描述):

    1. C-APDU 命令列表(在 SGP.11-v4.0 第 595 页的 EXPANDED_COMMANDS 方法中定义,并在 SGP.11-v4.0 第 407 页的步骤 2 中使用)

    2. 构成 SCP03t 脚本的 TLV 命令(在 SGP.11-v4.0 第 600 页的 SCP03T_SCRIPT 方法中定义,并在 SGP.11-v4.0 第 408 页的步骤 14 中使用)

    脚本链接

    脚本链接是在需要执行多个传输消息中发送的多个命令但在执行第一个命令并用于下一个命令(例如第一个命令是INSTALL [for personalization],第二个是STORE DATA)。此上下文是 TS 102 226 第 4 节中定义的命令会话。

    这至少在这些情况下使用(SGP.02 中的附件 K 也支持):

    1. 当后续命令基于 eUICC 的响应时

    2. 当命令脚本过大无法一次发送时

    脚本链接由 SM-SR 执行,通过将 Script Chaining TLV 添加到扩展远程格式的命令脚本来实现。请参阅 TS 102 226 中的第 5.4.1.2 节。

    可以在 SGP.11-v4.0 中找到脚本链接的示例。

    对于第一种情况,请参阅第 4.2.10.2.1.1 节中 EstablishISDRKeyset 过程的场景。对于第二种情况,请参阅第 4.2.18.2.1.1 节中 DownloadAndInstallation 过程的场景。脚本链接的字节级表示在第 601 页的SCP80_PACKET 方法中进行了描述(请参阅选项CHAINING_OPT)。

    似乎显式链接仅适用于SMSCAT_TP 传输。对于HTTPS,命令会话与Remote Application Management over HTTP – Public Release v1.1.3 第 3.6 节中定义的管理会话一致,因此无需添加显式脚本链接 TLV。 p>

    细分

    当命令脚本过大无法一次性发送时,SMSR 会生成多个命令脚本。 SMSR 从 SMDP CMD1CMD2、...、CMDN(参见 SGP.11-v4.0 的第 408 页上的步骤 14)收到的命令并形成命令脚本被拆分为多个命令脚本。第一个包含命令CMD1CMD2、...、CMDi 的一些初始部分。第二个命令脚本包含命令CMDi+1CMDi+2、...、CMDj。第三个CMDj+1,…,CMDk等等。

    如果使用SMSCAT_TP,那么对于每个命令,链式TLV 都会以适当的值添加到开头(参见SGP.11-v4.0 中的第4.2.18.2.1.1 节)。

    然后每个新的命令脚本都会在单独的消息中发送给 eUICC。

    【讨论】:

      猜你喜欢
      • 2019-12-12
      • 1970-01-01
      • 2011-09-09
      • 1970-01-01
      • 1970-01-01
      • 2011-11-16
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多