首页 > 编程知识 正文

怎么看是不是usim卡,android UI线程

时间:2023-05-06 19:56:39 阅读:106407 作者:753

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

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

文章目录UICC安全相关内容UICC当前支持的安全功能UICC安全体系结构列表安全属性访问模式(am )安全条件(SC )访问规则安全环境(SE )安全

UICC安全相关内容

在运营商办理SIM卡时,SIM上会显示PIN1和PIN2的数字。 通常是4位数和8位数。 这是UICC安全密钥。 使用PIN1或PIN2时,我们有三次输入错误的机会。 如果输入错误3次以上,SIM将自动锁定,需要用UPIN解除锁定。 这个UPIN我们不知道。 需要打开卡托架并解锁

pin:personalidentificationnumberupin:unblock pin当然还有一个安全密钥是管理员密钥。 这个我们看不见。 管理员密钥可以更改PIN1和PIN2的值。 如果管理员密钥输入错误10次,SIM卡将启动自动销毁功能,然后销毁SIM卡。

UICC当前支持的安全功能UICC包括单验证功能和多验证功能。

从安全上下文的角度来看,对于single verification capable的UICC,PIN1是全局密钥,分配给UICC中的所有ADF/DFs和文件,而不是应用的一部分PIN2是APP特有的,用于APP的二次认证。

从安全上下文的角度来看,多验证功能的UICC可以支持多个PIN1的验证。 此PIN1的验证密钥是为每个APP分配的,并且可能有些APP需要PIN2的第2级验证。

UICC安全体系结构列表使用特定命令与UICC交互时,例如更新UICC中的文件,必须满足特定的安全要求才能访问。 如果不满足或UICC也无法确定是否满足安全条件,则命令失败,UICC返回错误代码“6982”(securitystatusnotsatisfied )

安全体系结构包括以下部分:概念比较抽象,看下面实例解释

安全属性:一个访问规则集访问规则:由一个访问模式和一个或多个安全条件组成的访问模式(am )安全条件(SC )。为特定操作定义的特定安全条件不同的文件读取操作可能有不同的安全要求) )安全属性安全属性包含在ADF/DF/EF的FCP中

对模式(am )访问模式的访问因文件而异,值因文件而异,请参阅ISO/IEC 7816-4。

安全条件(SC )表示在处理文件之前必须满足的安全流程,如下图所示。

访问规则访问规则实际上是各种安全条件(SC )和访问模式(am )的组合,可以以压缩或扩展格式进行编码。 详情请参照TS102221及ISO/IEC 7816-4。

有以下两种组合。

可以将一个或多个“访问模式”和一个“安全条件”组合,以在一个SC满足条件时执行一个或多个“访问模式”和一个安全条件的组合。 command ) and关系)多个SC必须满足条件才能共享访问规则。

UICC定义了EFARR文件。 此文件以扩展格式编码记录了可以在不同文件之间共享的安全属性。 EFARR的文件结构如下图所示。

DO:Data Object可以通过两种方式从EFARR获取对文件的访问规则。

这样,文件ID record number文件id安全环境ID record number在不同的安全环境中为同一文件提供不同的访问规则

使用文件id引用访问规则时,如果在当前目录下找不到与此文件id匹配的访问规则,则会递归搜索:

如果当前选定的文件是EF类型,并且在当前DF的EFARR中找不到对此EF文件的访问规则,则则查询当前DF的父亲DF将一直持续到您与ADF或MF联系。 如果当前选定的文件是DF类型,且在当前DF的父亲DF的EFARR中中找不到对此EF文件的访问权限,则退出此过程。如果当前选定的文件是ADF或MF类型,则MF下的EFARR

节点:安全环境) SE )安全环境的概念,其中在同一DF下可能有多个ef(arr )

念存在意义就是给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’ 做为 PIN2key reference ‘11’ 做为 universal PIN

返回系列目录

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。