UICC 之 USIM 详解全系列——UICC安全相关内容

UICC安全相关内容

我们在运营商办理SIM卡时，在SIM上会显示一个PIN1和PIN2的数字一般是4位数也有8位数，这个就是UICC安全密钥，在使用PIN1或者PIN2的时候我们有3次输入错误的机会，如果输错超过3次，SIM会自动锁定，需要使用UPIN解锁，这个UPIN我们也是不知道的，需要到开卡运营商进行解锁。

PIN：Personal Identification Number
UPIN：UNBLOCK PIN

当然还有一个安全密钥是管理员密钥，这个我们是看不到的，管理员密钥可以修改PIN1和PIN2的值，如果管理员密钥输错10次，则SIM卡会启动自动销毁功能，之后SIM卡就报废了。

UICC目前支持的安全功能

UICC有支持single verification capable 也有支持 multi-verification capable。

从安全上下文的角度看，对于single verification capable的UICC，PIN1是一个全局性的Key不属于某个Application，而是分配给UICC中的所有ADF/DFs和files。PIN2是Application特有的，用于Application的二级鉴权。

从安全上下文的角度看，对于multi-verification capable的UICC可以支持多个PIN1的鉴权，这个PIN1的鉴权key是按照Application分配的，可能还有一些Application需要PIN2的二级鉴权。

UICC安全架构一览

我们在使用某些命令（例如，更新UICC中的某个文件）与UICC交互时，需要满足特定的安全要求才可以访问，如果不满足或者UICC也无法确定是否满足安全条件，则命令将执行失败UICC将返回错误码’6982’ (Security status not satisfied)。

安全架构包含以下几部分（概念比较抽象，看下面实例解释）：

• 安全属性：一个访问规则集合
• 访问规则：由一个访问mode和一个或多个安全条件组成
• 访问mode（AM）：指示安全条件将应用到那些操作当中
• 安全条件（SC）：对一些具体的操作，所定义的具体安全要求（例如，不同文件的读取操作可能有不同的安全要求）

安全属性

安全属性会包含在ADF/DF/EF的FCP中，使用tag=‘8B’ or ‘8C’ or 'AB’来表示，如下图：

访问 mode（AM）

access mode取决于文件，不同的文件值不同，可以参考ISO/IEC 7816-4。

安全条件（SC）

指示对于某个文件进行操作之前，需要满足哪些安全流程，如下图：

访问规则

访问规则其实就是各种 安全条件（SC）与访问 mode（AM）的一个组合，这个组合可以按照压缩格式或者扩展格式编码，详情查看TS102221以及ISO/IEC 7816-4。

可以有以下两种组合：

• 一个或多个 “访问 mode” 与一个 “安全条件” 组合，只要一个SC满足条件就可以执行command（OR 的关系）
• 一个或多个 “访问 mode” 与一个 “安全条件” 组合，需要多个SC满足条件才能执行command（AND 的关系）

访问规则共享：
UICC定义EF_ARR文件，这个文件以扩展格式的编码方式记录了一些安全属性，这些属性可以在不同的文件之间共享，EF_ARR的文件结构如下图：

DO：Data Object

从EF_ARR获取一个文件的访问规则有两种方式：

• File ID + record number
• File ID + 安全环境ID + record number

通过这种方式可以实现同一文件在不同安全环境下有不同的访问规则

当我们通过File ID来引用访问规则时，如果在当前目录下没有找到匹配这个File ID的访问规则，将按照下面的方式进行递归查找：

• 如果当前选择的文件是EF类型，并且在当前DF的EF_ARR中没有找到这个EF文件的访问规则，则查询当前DF的父亲DF，这个过程一直持续，直到查询到ADF或者MF中才截止
• 如果当前选择的文件是DF类型，并且在当前DF的父亲DF的EF_ARR中没有找到这个EF文件的访问规则，则继续向上查找，直到查询到ADF或者MF中才截止
• 如果当前选择的文件是ADF或者MF类型，则只会在MF下的EF_ARR中查找这个文件的访问规则

Tag '8B’结构如下图：

NOTE：在相同的DF下可能有多个EF(ARR)，这些EF(ARR)通过它们各自的file-ids来区分

安全环境（SE）

安全环境这个概念存在意义就是给UICC中的某些Application提供一个安全的command交互环境，保证command的完整性。在multi-application UICC中安全环境相当于一个容器，保护每一个激活的Application；single application UICC中安全环境对整个UICC都有效。

安全环境与逻辑信道的关系

安全环境在Application激活时建立并且一直有效，直到在这个逻辑信道下有新的Application启动或者PIN状态的DO被改变。

如果从一个non-basic的逻辑信道上激活另一个逻辑信道，则这个被激活的逻辑信道将继承这个non-basic的逻辑信道上的安全环境。

如果一条command改变了SE的设置，则①发送这条command的逻辑信道的SE会被改变；②其它逻辑信道的SE是从这个逻辑信道（发送这条command的逻辑信道）继承过来的，则其它逻辑信道的SE也会被影响。

反之，如果当前逻辑信道的SE是从其它逻辑信道的SE继承而来，则①原始逻辑信道的SE和②当前逻辑信道的SE以及③其它逻辑信道的SE(从原始逻辑信道的SE继承而来) 都会发生改变。
如下图描述：

PIN

PIN可以分为 Universal PIN、Application PIN、Local PIN

• Universal PIN
  用在multi-application environment中，实现多个Application共享一个PIN，它并不属于任何Application。single verification capable UICC中不会使用这种PIN。

• Application PIN
  一个Application PIN对应一个application Security Environment，在这个application Security Environment中的ADF/DFs都可以被Application PIN访问

• Local PIN
  存在于某个ADF/DF中的PIN，可以通过文件的FCP获取

PIN与逻辑信道

对于Universal PIN、application PINs 和 ocal PIN的 PIN状态（SELECT命令返回，包含在FCP的PS template DO中，使用Tag 'C6’标记，指明PINs enabled/disabled等状态信息），它们与逻辑信道都是独立的，也就是说我在一个逻辑信道上PIN验证成功，则在其它逻辑信道上也完成了同样的PIN验证并且成功了，不需要再在其它逻辑信道上再进行一次PIN验证。

也可以这样想，PIN的操作是逻辑信道透明的，与具体在哪个逻辑信道上进行PIN操作无关

PIN与key reference的关系

这里主要介绍一张图，这张图用于PIN相关命令的组装，例如我们使用VERIFY PIN命令进行PIN的验证，需要指明是对什么PIN的验证（PIN1，PIN2 还是其他的PIN），这时需要查看下面这张图：

解释：
对于single verification capable UICC (from the security context point of view)

• 使用key reference ‘01’ 做为 PIN
• 使用 key reference ‘81’ 做为 PIN2

multi-verification capable UICC

• key references ‘01’ 到 ‘08’ 做为 PIN
• 如果存在PIN2，则key references ‘81’ 到 ‘88’ 做为 PIN2
• key reference ‘11’ 做为 universal PIN

---

返回系列目录