ai异构通信技术,三星uicc解锁

我就职于国际知名终端制造商，负责调制解调器芯片的开发。

5G初期负责终端数据业务层、核心网相关开发，目前带动6G计算网络技术标准研究。

UICC的USIM详细信息全系列——UICC协议层结构文章目录UICC的USIM详细信息全系列——UICC协议层结构基础介绍1.APP应用层和CAT层2 .传输层transsion 使用类re bytes '61xx' and '6Cxx.数据链路层(数据链接层协议t=0) Status Words和Procedure Bytes 4.物理层)物理层

基础介绍

和计算机网络协议层的概念一样，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 .在APP应用层和CAT层(Application layer )层级，TS102221可针对Terminal中的APP应用，向APP应用编程人员提供多个命令响应在APP应用层，可以直接使用这些命令执行所有必需的功能。

例如，在APP应用层，可以使用此命令0x00A40004 04 6F07选择USIM的IMSI文件，但此命令后面可能需要Terminal和UICC的多次通信才能完成此任务。

2 .传输层(传输层协议t=0) apdu )进入应用协议数据单元(apdu )传输层时，首先通过映射来传输PDU (传输层协议t=0)

首先，我们来看看APDU的工作原理。 详细说明请参照这篇博文。

CLAINSP1P2Lc (可选数据) Le )可选) tpdu )命令头)的结构：

您可以从图表中看到，CLAINSP1P2P3转换的主要任务是完成TPDU的P3 Field和APDU的Lc、Data、Le的映射。

4种命令格式Case1：APDU中不包含Lc、Data、Le

在这种情况下，终端将TPDU的P3设置为0x00并将其发送到UICC，UICC处理命令并返回statuswords(R-TPDU )，传输层将r-tpdu直接发送到APP应用层。

Example :

Case2：APDU中不包含Lc、Data，但是包含Le

Le Field的意思主要是将Terminal想要获取的数据的长度传达给UICC。 例如，在Terminal读取文件，但是没有Le的情况下，UICC以max{文件的长度，255}的长度返回Terminal数据，在设定了Le的情况下，UICC为min{Le，文件的长度}

在case2中，P3 Field被设置为由Le发送到UICC，UICC传输层将Le个字节的数据和Status words返回给终端传输层。 (在此过程中，UICC使用procedure bytes‘61xx’或‘6 cxx’控制数据的返回。 http://ww

’61xx’和’6 cxx’的详细用法见文章末尾

Examples :

也就是说Terminal的传输层首先发送一个Command header给UICC传输层，随后UICC发送一个procedure byte给terminal传输层通知terminal来取数据

终端将命令头发送到UICC传输层，UICC将procedure byte通知发送回终端“Lc bytes of DATA”，在UICC处理命令后，状态为witus

Example :

Case3：APDU中不包含Le，但是包含Lc、Data

这种在case中从C-APDU到C-TPDU的映射将切掉Le。

1 )终端将命令头发送到UICC传输层2 )如果收到命令头，UICC: a ) UICC返回procedu

re 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之间的通信，并不会传输给应用层

ByteValueActionACKACK等于INSTerminal将会发送所有剩余的数据（data bytes）给UICC或者Terminal将接收来自UICC的所有剩余的数据ACK等于INS取反(~INS)Terminal将会发送下一个字节的数据（the next data byte）或者Terminal将从UICC接收下一个数据比特NULL‘60’没有数据传输需要完成，Terminal需要等待a procedure byteSW1‘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’。

ByteValueActionSW1‘6X’ or ‘9X’(except ‘60’, ‘61’ and ‘6C’)Terminal等待SW2，并且将收到的Status bytes和数据（如果有的话）发送给应用层 4. 物理层（Physical Layer）

协议中对该层无描述，应该对应于一些实际的物理器件

这一部分比较复杂，也是UICC开发的关键，如果需要深入理解可以参考博主GitHub中的USIM_deom Project

返回系列目录