UICC 之 USIM 详解全系列——UICC协议层结构
文章目录
基础介绍
与计算机网络的协议层概念一样，UICC也有自己的协议层概念，只是相对简单一些。这个协议层用于Terminal与UICC之间的数据交互，如下图
针对这个协议层定义里两种协议，分别为protocol T=0和protocol T=1。它们两的区别在与protocol T=0是基于字符的协议，也就是Terminal与UICC之间的交互以字节为单位；protocol T=1是基于块的协议。我们的讲解以protocol T=0为主，不对protocol T=1做介绍，但兴趣的同学可以参考协议TS102221
1. 应用层与CAT层（Application layer）
这一层面向Terminal中的应用程序，在TS102221中已经定义好多个command-response pair（也就是暴露给应用程序员的一些命令以及命令对应的response）。在应用层我们可以直接使用这些命令完成所有需要的功能。
例如：在应用层通过这条命令 0x00A40004 04 6F07 即可选中USIM中的IMSI文件，但是这条命令的背后可能需要Terminal与UICC的多次通信才能完成这个任务。
2. 传输层（Transport layer Protocol T=0）
APDU（Application Protocol Data Unit）进入传输层首先会被mapping成TPDU（Transfer Protocol Data Unit）
我们先来看一下APDU的结构（深入讲解可参考这篇博文）：
| CLA | INS | P1 | P2 | Lc（可选） | Data（可选） | Le（可选） |
|---|
TPDU（Command header）的结构：
| CLA | INS | P1 | P2 | P3 |
|---|
通过图表大家应该能明白转换的主要工作是完成TPDU的P3 Field与APDU的Lc、Data、Le的映射。
四种命令格式
Case1：APDU中不包含Lc、Data、Le
这种情况下Terminal会将TPDU的P3置为0x00发送到UICC，UICC处理命令并返回Status words（R-TPDU），传输层会将R-TPDU原封不动的发送给应用层。
Example：
Case2：APDU中不包含Lc、Data，但是包含Le
Le Field的含义主要是Terminal告诉UICC希望获取的数据长度，例如Terminal要读取一个文件，在没有Le的情况下UICC会按照max{文件长度，255}这个长度返回给Terminal 数据，如果设置了Le则UICC按照min{Le ，文件长度}返回给Terminal。
case2中P3 Field设置成Le发送给UICC，UICC传输层返回Le个Bytes的数据以及Status words给Terminal传输层（在这个过程中UICC会使用procedure bytes ‘61xx’ 或者 '6Cxx’来控制数据的返回，也就是说Terminal的传输层首先发送一个Command header给UICC传输层，随后UICC发送一个procedure byte给terminal传输层通知terminal来取数据），Terminal传输层对R-TPDU不做任何修改传送给应用层。
针对’61xx’ 和 '6Cxx’的详细用法参照文章末尾
Examples：
Case3：APDU中不包含Le，但是包含Lc、Data
Terminal发送Command header给UICC传输层，UICC返回一个procedure byte通知Terminal发送"Lc bytes of DATA"，当UICC处理完command之后返回status words，terminal的传输层不做任何处理返回给应用层。
Example：
Case4：APDU中包含Lc、Data、Le
这种case下C-APDU到C-TPDU的映射会将Le截取掉。
- 1）Terminal发送Command header给UICC传输层
- 2）收到Command header之后，如果UICC：
- a）UICC返回procedure byte给Terminal传输层，则Terminal传输层发送"Lc bytes of DATA"给UICC传输层，或者
- b）UICC返回status words，Terminal的传输层将会终止命令的处理
- 3）如果在2b）中处理没有中断，UICC收到"Lc bytes of DATA"之后：
- a）如果command处理没有出现异常，则UICC会返回procedure bytes '61xx’给Terminal的传输层，请求Terminal发起GET RESPONSE command从UICC读取数据。
- b）如果发生异常，则UICC发送status byte给Terminal传输层
- 4）在step3中收到procedure bytes or status bytes后，如果UICC：
- a）如果UICC在step 3a）发送给Terminal ‘61xx’ procedure bytes，则Terminal发送GET RESPONSE command header给UICC并设置P3的值小于或等于’XX’，或者
- b）在step 3b）中发送给Terminal的是warning(‘62xx’ or ‘63xx’)或者是应用相关的(‘9xxx’ but not ‘9000’),则Terminal发送GET RESPONSE command并设置Le等于0x00，或者
- c）如果在stpe 3b）中返回的并不是 step 4b）中的status words，则Terminal的传输层将会终止命令的处理。
针对’61xx’ 和 '6Cxx’的详细用法参照文章末尾
Example：
procedure bytes ‘61xx’ and '6Cxx’的使用
‘61xx’ and '6Cxx’仅仅应用于上述Case2和Case4
Luicc: UICC在回复Case2或者Case4 command时，会携带这个参数，它表示我UICC实际可以给Terminal回复的字节数，如果Le大于Luicc，则只能回复Luicc个字节
‘61xx’
‘61xx’就是告诉Terminal传输层向UICC发送GET RESPONSE command，并设置GET RESPONSE的commnad header的P3 Field为’xx’。
‘6Cxx’
‘6Cxx’就是告诉Terminal传输层向UICC立即重发previous command，并设置previous command的commnad header的P3 Field为’xx’。
Case 2 commands
- 1）如果UICC收到Case 2 command header并且Le=‘00’（Luicc < 256 bytes）或者Le > Luicc，则UICC将会返回：
- a）procedure bytes '6C Luicc’给Terminal传输层，通知Terminal立即重发previous command并设置P3=Luicc，或者
- b）发送status words给Terminal，报告一条warning或者error
- 2）如果UICC收到Case 2 command header并且Le=‘00’Luicc = 256 bytes）或者Le=Luicc，则UICC将会返回：
- a）UICC发送给Terminal一条消息，这条消息的开头是INS、~INS或者’60’ procedure bytes，后面紧跟长度为Le的data，最后面是相关的status words，或者
- b）UICC发送procedure bytes ‘61xx’给Terminal传输层，Terminal发送GET RESPONSE command并设置P3为’XX’，'XX’应该小于Luicc（这种情况发生在Scard的buffer小于Luicc），或者
- c）发送status words给Terminal，报告一条warning或者error
- 3）如果UICC收到Case 2 command header并且Le < Luicc，则UICC将会返回：
- a）UICC发送给Terminal一条消息，这条消息的开头是INS、~INS或者’60’ procedure bytes，后面紧跟长度为Le的data，最后面是procedure bytes ‘61xx’，Terminal立即发送GET RESPONSE command 并设置P3=‘XX’，或者
- b）发送status words给Terminal，报告一条warning或者error
Example：
Case 4 commands
UICC收到case 4 command后会返回：
- a）procedure bytes ‘61 xx’，通知Terminal立即发送GET RESPONSE command 并设置P3=‘XX’
- b）发送status words给Terminal，报告一条warning或者error
Examples：
3. 数据链路层（Data Link Layer Protocol T=0）
这一部分设计到时序的问题，这里不做介绍，感兴趣的同学可以参考TS102221
T=0是数据链路层是一个半双工基于字符的异步传输协议，所有使用T=0的Terminal，都需要首先发送5个bytes的command header给UICC，告诉UICC将要做什么。Terminal总是作为master，UICC作为slave。
command header:总是有5个连续的比特组成，CLA, INS, P1, P2 and P3
这一层会对命令进行处理，并返回procedure byte or a status byte。通过procedure byte or a status byte，UICC与Terminal可以安全的访问I/O-line
Status Words与Procedure Bytes
Procedure byte coding
Procedure bytes用来实现UICC与Terminal之间的通信，并不会传输给应用层
| Byte | Value | Action |
|---|---|---|
| ACK | ACK等于INS | Terminal将会发送所有剩余的数据（data bytes）给UICC或者Terminal将接收来自UICC的所有剩余的数据 |
| ACK等于INS取反(~INS) | Terminal将会发送下一个字节的数据（the next data byte）或者Terminal将从UICC接收下一个数据比特 | |
| NULL | ‘60’ | 没有数据传输需要完成，Terminal需要等待a procedure byte |
| SW1 | ‘61’ | Terminal等待第二个procedure byte，然后发送GET RESPONSE command header给UICC且设置P3等于‘XX’,这个‘XX’就是第二个procedure byte的SW2 |
| ‘6C’ | Terminal等待第二个procedure byte，然后重新发送上一条command，但是设置P3字段为‘XX’，这个‘XX’就是第二个procedure byte的SW2 |
Status bytes
这个status bytes SW1 SW2用来描述command在UICC中的执行情况。成功？失败？
通常情况下命令执行成功之后会返回SW1 SW2 = ‘90 00’。
| Byte | Value | Action |
|---|---|---|
| SW1 | ‘6X’ or ‘9X’(except ‘60’, ‘61’ and ‘6C’) | Terminal等待SW2，并且将收到的Status bytes和数据（如果有的话）发送给应用层 |
4. 物理层（Physical Layer）
协议中对该层无描述，应该对应于一些实际的物理器件
这一部分比较复杂，也是UICC开发的关键，如果需要深入理解可以参考博主GitHub中的USIM_deom Project