Dual Sim Dual Volte

目前移动和联通支持情况最为简单，无论移动+移动、移动+联通、联通+联通都没有任何问题，均可支持双4G网络.

Mix2S 中　唯独电信卡相对比较特殊，理论上全网通5.0电信卡作为副卡时可支持VoLTE，但由于现在中国电信的VoLTE服务还未商用，所以目前电信卡作为副卡，暂时只能停留在CDMA 1x，也就是电信2G网络.

红米Note5双电信一样只有设置为上网卡的才能接入网络，无法自动切换，而且移动+电信、联通+电信的组合中，必须把电信卡设置为上网卡才能4G，否则是2G
(支持电信双卡双待，但是不支持电信双4G)

红米6A 对电信卡删除CSIM，　那么双4G数据网也是可以实现的

电信
B–江苏恒宝
C–广东楚天龙
D–大唐
G–江西捷德
H–北京华虹
K–上海柯私
P–天津金普斯 （同雅斯拓合并为金雅拓，现在属于泰雷兹,代码已经取消)
T–武汉天喻
W–北京握奇
X–珠海东信和平
Y–上海雅斯托 （现在为法国 泰雷兹)

联通
C 上海柯斯  （2015年后已经退出联通供应商序列）
N 江苏恒宝
L 东莞楚天龙
D 深圳欧贝特（2015年后已经退出联通供应商序列）
E 珠海东信和平
G 天津金普斯 （金雅拓，泰雷兹,代码已经取消）
S 上海雅斯拓 （金雅拓，泰雷兹）
T 大唐微电子
W 北京握奇
H 北京华虹
J 江西捷德（湖北黄石有工厂)
Y 武汉天喻
V 珠海星汉
A 东方英卡（被恒宝收购，代码已经取消）
B 法国布尔（退出联通供应商， 代码已经取消）
M 深圳明华澳汉 （退出联通供应商， 代码已经取消）
Z 航天智通（已取消）

移动

0 雅斯拓 （金雅拓，泰雷兹）
1 金普斯 （合并到金雅拓，代码取消)
2 武汉天喻
3 江西捷德
4 珠海东信和平
5 大唐微电子
6 航天九州通 (代码取消)
7 北京握奇
8 东方英卡(恒宝收购)
9 北京华虹
A 上海柯斯

SubscriptionManager　setDefaultDataSubId()

在权限检查时，

permission android:name="com.qualcomm.permission.UIM_REMOTE_CLIENT" android:protectionLevel="signatureOrSystem" 

跟

permission android:name="com.qualcomm.permission.UIM_REMOTE_CLIENT" 

是不一样

在apk安装后，权限信息会解析到　　/data/system/packages.xml　文件里

...
item name="com.qualcomm.permission.UIM_REMOTE_CLIENT" package="com.qualcomm.uimremoteclient"
...
   package name="com.redteamobile.virtual.softsim"
   perms
      item name="com.qualcomm.permission.UIM_REMOTE_CLIENT" granted="true" flags="0"
   


区别就在于

item name="com.qualcomm.permission.UIM_REMOTE_CLIENT" package="com.qualcomm.uimremoteclient" protection="18"

通过hook系统包管理服务

com/android/server/pm/PackageManagerService.java
android/content/pm/permissionInfo



updatePermissionsLPw


PMS的全局数据结构中


context.checkCallingOrSelfPermission(String permission) 跟踪这个

ContextImpl.checkCallingOrSelfPermission()
checkPermission(String permission, int pid, int uid)


ActivityManagerNative.getDefault().checkPermission(permission, pid, uid);
通过AMS去做检测的

AMS.checkPermission()

ActivityManager.checkComponentPermission(permission, uid,　owningUid, exported);
ActivityManager.checkComponentPermission


AppGlobals.getPackageManager()
            .checkUidPermission(permission, uid);





PMS.checkUidPermission()

 先调用getUserIdLPr，同PMS的Setting.mUserIds数组中根据uid 查找权限列表。找到则表示有相应的权限，接着再根据传过来的参数坐下判断，看是否有对应的

如没有找到，则去PMS的mSystemPermissions 中找。
这些信息是启动时从 /system/etc/permissions/platform.xml 中读取的

https://android.googlesource.com/platform/frameworks/base.git/+/master/services/core/java/com/android/server/pm/PackageManagerService.java

mPermissionManager.updatePermissions

BasePermission bp = (BasePermission) mPermissionManager.getPermissionTEMP(permName);

mPermissions.put(name, new PermissionData(permissionData)); 修改权限

https://sanjay-f.github.io/2016/05/18/%E6%BA%90%E7%A0%81%E6%8E%A2%E7%B4%A2%E7%B3%BB%E5%88%9736—%E5%AE%89%E5%8D%93%E7%9A%84%E5%AE%89%E5%85%A8%E6%9C%BA%E5%88%B6permission/

在Android 8.0 Oreo后， 权限不会自动赋予那些在 system/priv-app目录的应用。
所有的特权应用，都必须通过 在 /etc/permissions目录下的白名单来配置。
比如 privapp-permissions-platform.xml 里就有
privapp-permissions package=”com.android.phone”
…
permission name=”android.permission.READ_PRIVILEGED_PHONE_STATE”
…
的配置

特许权限许可名单
特权应用是位于系统映像某个分区上 priv-app 目录下的系统应用。各 Android 版本中，该分区为：

Android 8.1 及更低版本 – /system
Android 9 及更高版本 – /system, /product, /vendor
在本页面中，/etc/permissions/priv-app 解析为 partition/etc/permissions/priv-app。

过去，设备制造商几乎无法控制可对特权应用授予哪些签名|特许权限。从 Android 8.0 开始，制造商必须在 /etc/permissions 目录下的系统配置 XML 文件中明确授予特许权限。从 Android 9 开始，实现人员必须明确授予或拒绝授予所有特许权限，否则设备将无法启动。

privapp-permissions.xml 文件只有在与特权应用位于同一分区时才能授予或拒绝授予该应用权限。例如，如果 /vendor 分区上的应用请求特许权限，则只能由同样位于 /vendor 上的 privapp-permissions.xml 文件来同意或拒绝该请求。

注意：必须列入许可名单的只有核心平台（“android”软件包）所定义的权限。设备制造商定义的特许权限仍将自动授予。在 privapp-permissions.xml 文件中，请仅列出实际存在于该分区上的应用。如果应用不在该分区上，系统将忽略所列条目。

添加许可名单
应用的权限许可名单可列在位于 frameworks/base/etc/permissions 目录下的单个或多个 XML 文件中，如下所示：

/etc/permissions/privapp-permissions-OEM_NAME.xml
/etc/permissions/privapp-permissions-DEVICE_NAME.xml
对于如何组织内容，没有严格的规则。设备实现人员可以决定内容结构，只要 /system/priv-app 下的所有应用均列入许可名单即可。例如，Google 针对由 Google 开发的所有特权应用提供了一个许可名单，并建议使用以下组织方式：

对于已包含在 Android 开源项目 (AOSP) 树中的应用，请将其权限列在 /etc/permissions/privapp-permissions-platform.xml 中。
对于 Google 应用，请将其权限列在 /etc/permissions/privapp-permissions-google.xml 中。
对于其他应用，请使用以下格式的文件：/etc/permissions/privapp-permissions-DEVICE_NAME.xml。

作者：　smarticcard (微信号)

自从智能卡开始进入人们的日常生活之后，大家对于智能卡的安全性普遍看好，但是不同公司的智能卡在安全机制的实现方面也存在很多的差异。对于智能卡应用开发和智能卡COS设计人员来说，如果能够更多地了解不同公司的智能卡安全机制，无疑会对自己的开发过程有所帮助。在此将逐步介绍一些流行的智能卡操作系统中各具特色的安全机制，究竟这些安全机制孰优孰劣，其实无关紧要，只要这种安全机制能够满足系统的安全需求就足够了。

首先看看早期的CardOS，CardOS是西门子公司基于自己的44C40/80系列芯片而设计的，该系列芯片RAM大小256字节，程序空间8K/16K，数据空间4K/8K，采用西门子的8051内核。CardOS在1995年推出了1.2版本，主要的APDU命令是符合ISO7816-4的文件读写操作，采用的安全机制非常灵活，初看起来也有点复杂，但是实际原理却是比较简单的。虽然目前国内市场上几乎已经没有什么CardOS产品了，但是了解这个初期的鼻祖级的智能卡安全机制，对于了解目前市场上流行的COS安全机制应该会有些帮助。

CardOS采用半字节作为安全状态，除却0和F之外，还有1到E共计14种状态，每个状态分别对应要达到该状态需要进行的某种安全认证操作以及这些认证的不同组合方式，这些安全认证包括校验PIN或者是C/R （Challenge / Response） 认证（也就是我们现在通常所说的外部认证），而认证的组合方式包括“逻辑与”及“逻辑或”。

对于文件的操作和密钥的使用可以定义不同的安全状态，只有满足定义的安全状态后才能进行相应的文件操作，或者密钥的使用。无论是DF还是EF都有一组3字节的安全状态控制字，每半字节作为一种访问控制的状态标识，分别对应着文件的建立、删除、添加、读取、更新等操作。

这些安全状态及其需要的认证或组合全部保存在一个特殊的内部文件STCF（Security Test Control File）安全认证控制文件中，该文件是一个TLV（Tag Length Value）结构的记录文件，其中第一个字节就是1-E这14个状态中的一个作为TAG，Length根据认证方式的不同而存在差别，Value当中的第一个字节表示认证类型，从中可以看出这个认证是需要PIN认证，还是需要C/R认证，或者是某几个认证状态的“逻辑与”及“逻辑或”组合。对于PIN认证还可以指出应该使用哪个PIN文件中的哪个PIN，同样对于C/R认证也可以指出应该使用哪个密钥文件中的哪个密钥。在CardOS的系统中有一个安全状态bit mask标志，用不同的数据位来记录哪个安全状态经过认证得到了满足。在有些情况下，进行DF选择之后，当前DF的认证状态的bit mask标志将会被清空。

关于“逻辑与”和“逻辑或”其实也很简单。比如“03”的状态表示认证第3个PIN文件中的第2个PIN，“0B”的状态表示需要对第1个密钥文件的第5条密钥进行C/R认证。那么我们可以定义状态“06”表示“03”和“0B”的逻辑或组合，定义状态“07”表示“03”和“0B”的逻辑与组合。我们假设有两个文件EF01和EF02，其中EF01读写的安全状态分别为“03”和“06”，EF02读写的安全状态分别为“0B”和“07”。那么在验证了第3个PIN文件中的第2个PIN后，即可以读EF01也可以写EF01，而对于第一个密钥文件的第5条密钥经过C/R认证后，也可以写EF01。对于EF02的写操作必须同时满足以上两个认证状态，对于EF02的读则只需要C/R认证第1个密钥文件的第5条密钥即可。

除了以上的安全状态控制机制之外，CardOS还定义了所谓的线路保护LINE PROTECTION，在文件的创建过程中会定义LPROTF字段，作为线路保护属性，有两种线路保护模式分别为MAC方式和加密方式，同时还定义了线路保护的方向，即从卡到终端以及从终端到卡。而用来进行线路保护的密钥只能存储在SKF（System Key File）系统密钥文件中。

在CardOS中定义了几个默认的EF文件标识，分别为：0000 = ATR二进制文件，0001 = STCF记录文件，0002 = PIN记录文件，0003 = SKF系统密钥记录文件，0004 = RSF 随机数种子二进制文件。CardOS支持最多6层DF文件结构，可以通过文件名、文件标识、文件路径等方式进行文件的选择。

作者：　smarticcard (微信号)

DS Smart Card是飞利浦公司自己开发的一款CPU卡产品，在早期芯片厂商开发自己的COS并进行推广很普遍，现在像英飞凌（前西门子半导体）以及恩智普（前飞利浦半导体）几乎很少推广自己的COS，大多时候都是在集中精力推广自己的芯片。

飞利浦的DS系列智能卡COS结合了ISO7816和ETSI的规范（也就是SIM卡规范），在安全机制上采取了和SIM卡类似的密码验证方式，即主要通过密码比对的方式获取对文件的访问控制权限。

DS CPU卡一共定义了三种基本的访问权限，分别是发卡商权限（0到3）共享权限（0和1），持卡人权限（0和1）。这些访问权限通过密码单元中对应的访问权限区域来定义，对应的密码分别是发卡商密码和持卡人密码，而共享权限可以利用发卡商密码或者持卡人密码来获得。在正确验证密码后根据访问权限区域设定的数据位就可以获得其中的一种或几种权限。一旦获得了某种权限，那么这种权限就一直保留，直到到卡片断电，或者是对同一个密码又进行了错误的认证后才会消失。每次正确的密码认证所获得的权限是累加的关系。

在可以设定的权限中共有16种状态，其中0表示始终满足，即不需要认证，而15表示永远都不满足，即拒绝任何访问。其余的14种状态可以分别对应不同的密码或者密码组合来实现访问控制。每个密码还设计了对应的解锁密码，当连续错误验证密码超过规定的次数后，该密码将被锁定，只有通过核对解锁密码才能解开。

总体上看DS的CPU卡COS主要是依据SIM卡的规范而设计的安全机制，而其中的文件管理和操作也符合SIM卡的标准，比如对于文件的访问除了一般的读写之外，还有对文件的禁用和启用，在文件被禁用后不能更改，根据文件建立时规定的禁用可读与否来决定文件禁用后是否可读。

DS卡只支持一种EF文件类型，那就是透明二进制文件。

DS卡还有一种据称申请专利的认证技术，采用DES的算法来认证卡片上存储的数据，借以判断终端明确知道的某个地址的卡片内容对不对，这种认证方式类似于7816规定的内部认证，但是机制上又有自己的定义，所以也比较有意思。在目前广泛应用的CPU卡中几乎没有人再使用这种机制了。

这种认证机制可以核对更改后的数据是否正确、实现文件内容的密文读出、实现带有随机数的内部认证。实际上终端应该能够确切地知道卡片中某个位置存储的4个字节数据，在认证中并不是采用简单的密码比较方式，而是采用随机数和认证响应的方式进行计算和比较。

认证是依靠当前的EF文件来进行的，在认证进行之前，对于文件的读权限必须满足。通过两步来完成认证，第一步是生成临时密钥，第二步是使用第一步得到的临时密钥计算认证数据。首先终端发送8字节的随机数据给卡片，卡片把前两字节用当前文件的标识给替换掉，使用该数据通过认证密钥Kc进行DES解密运算来得到临时密钥。如果重新进行了正确的文件选择，那么原来计算得到的临时密钥就会被破坏。然后利用临时密钥对文件中某个地址的4个字节数据及其对应的两个字节的地址进行DES解密运算，出于冗余和8字节DES计算的需要，两个字节的数据被重复，即8字节的数据结构为：数据（4字节）+地址（2字节）+地址（2字节）。经过计算得到的8字节认证数据传送给终端，终端可以比对计算的结果是否正确，来确定认证是否成功。

作者：　smarticcard (微信号)

MPCOS是金普斯早期推出的一款多应用支付芯片卡操作系统，支持ISO7816以及PCOS的数据格式和命令。MPCOS具有两级目录文件结构，即MF下可以有一级DF，每个DF下最多可创建63个EF。

MPCOS的文件访问控制是由密码来实现的，该密码存储在一个特殊的密码文件EFsc中，每个DF下只有一个EFsc，每个EFsc可以存储8个密码，对应的编号分别为0-7。对于EF和DF分别对应不同的访问控制操作，比如创建文件，读写操作等。这些访问控制操作就需要通过访问控制条件来实现。对于DF和EF而言，分别有两个字节的寄存器来表示在进行创建、读写等文件操作之前需要验证的密码编号，对于某一种文件操作最多可以指明需要验证两个密码。另外这个寄存器也指出了在进行安全报文操作时，进行数据加密和MAC计算需要使用的密钥编号。由此可以看出，MPCOS的安全控制依靠的是密码比对方法，而数据传输的安全保护（MAC以及数据密文的计算）使用另外一个密钥文件EFkey中存储的密钥通过DES运算来完成。

MPCOS是在金普斯原来的PCOS基础上扩展了ISO7816的文件结构，从而形成的多应用智能卡操作系统。所以MPCOS中保留了原来PCOS在支付应用方面的特色，做到了面向PCOS的向下兼容。

金普斯在结合支付应用和ISO7816文件操作的过程中，设计了两种操作模式：支付模式和管理模式。每种模式都有一个专有命令来启动一个会话过程，而这个会话过程只有在启动了另一种模式或者是卡片复位后才能被终止。（其实这种机制和后来的EMV96，以及PBOC电子钱包的状态机模式很像）

MPCOS对于支付和文件管理分别定义了不同的安全机制，在支付应用中可以加密敏感数据、生成交易证书、设定交易计数器等；而对于文件管理操作，可以通过MAC验证来确保数据的完整性、监控追踪某些敏感命令的执行等。不过MPCOS的MAC是3个字节的，这点和目前流行的4字节MAC稍有不同，但是计算方式是类似的。

针对文件的访问控制MPCOS是在文件创建的时候定义访问控制条件的，但是在文件被创建后，当满足安全控制条件的情况下，可以通过Lock和Localize两个命名来改变文件的访问控制属性，其中Lock是用来锁定文件的，文件被锁定后，拒绝任何访问；而Localize则是把文件访问控制所需参考主控文件MF下的密码或者密钥，改成参考当前DF下的密码或者密钥。

在MPCOS的支付交易处理过程中，同样引入了终端编号以及终端交易序号这样的参数，通过这些参数的参与来计算交易验证码。

作者：　smarticcard (微信号)

PayFlex是斯伦贝谢公司（经过若干整合现在是金雅拓的一部分）在上世纪90年代推出的一款电子钱包支付COS，从功能上看可以说PayFlex是EMV96以及PBOC电子钱包规范的雏形。

PayFlex同时具备用户卡和SAM卡功能，支持电子钱包用户卡的消费、圈存等交易。

从文件结构上看，仅支持定长记录文件和循环记录文件两种格式。PIN和密钥都是存储在定长记录文件中，PIN也就是所谓的持卡人验证CHV，密钥分为验证密钥和计算密钥，CHV文件中只有一个记录来存储PIN，而密钥文件中最多可以存储16条密钥；交易记录和钱包文件是用循环记录文件来存储的。

从安全机制上看，也是采用访问控制条件加上当前安全状态的模式。但是相对比较简单，总共有5种访问控制状态：自由访问、PIN、密钥验证、PIN+密钥验证、拒绝访问。

….

每个文件在创建的时候都有2个字节AC1和AC2用来指示不同APDU命令的访问控制权限，同时也有另外2个字节KN1和KN2来指出实现需要的访问控制权限将会使用的密钥。

访问权限的获得可以通过明文的方式验证PIN或者密钥，也可以通过密文的方式来验证。这里所谓的密文方式，实际上就是我们常说的外部认证，也就是先取8字节的随机数，然后再通过密钥加密，把加密后的数据按照某种规则截取6个字节，送到卡片中去比对。

因为PayFlex本身也具有SAM卡的功能，所以也可以用PayFlex卡计算分散密钥。此外PayFlex还支持内部认证，可以让主机或者终端来验证卡片的合法性。

电子钱包的交易流程和现在常用PBOC电子钱包交易非常类似，也是通过两个步骤，经由SAM卡来完成的，交易完成之后也生成类似于MAC和TAC的证书数据，用来验证交易的完整性。

和目前PBOC电子钱包不同的是PayFlex卡的密钥长度都是8字节，而不是16字节。

当时这款产品是基于TI的一款TMS373C012，只有4K的程序ROM，128字节的RAM和1K字节的EEPROM。在这样有限的资源里，开发出如此功能的产品，的确称得上是地位领先了。其中实现了20来个APDU，包括读/写/更新记录文件、外部认证、内部认证、验证/更改/解锁PIN（或密钥）、选择文件、创建文件、消费、圈存、分散密钥、取随机数、补丁程序的下载和激活等。

后来，在96年PBOC电子钱包规范发布之后，斯伦贝谢迅速推出了一款符合PBOC规范的QianFlex产品。

作者：　smarticcard (微信号)

StarCOS是捷德公司的推出的智能卡COS，和前面说过的几种COS不同的是，国内的用户对于StartCOS可以说非常熟悉，而且因为握奇、明华、天喻等公司的安全机制都基本上是脱胎于StarCOS，所以经常会给大家造成一种错觉，好像智能卡的COS就该是这样的。其实完全不然，稍后会介绍握奇的TimeCOS，从TimeCOS V1.0中可以看出来，和StarCOS还是有很大差别的。

捷德中国为了满足国内PBOC的需求，在StarCOS的基础上推出了Star China，安全机制和StarCOS相同。

StarCOS的文件结构除了通常的二进制透明文件、线性定长记录文件、线性变长记录文件、循环记录文件之外，还多了一种名为compute的文件结构，从形式上看compute文件和循环记录文件类似，但是每条记录又有自己固定的结构定义。

StarCOS的MF和每个DF都有自己的初始安全状态，当卡片上电后首先默认选择MF，安全状态为MF的初始状态，当选择某个DF后，当前DF的安全状态就是该DF的初始状态。MF和DF的初始状态在文件建立的时候可以设定。

在整个卡片的操作过程中分别保存两个当前安全状态，一个是MF的，另一个是当前DF的。只有通过验证PIN或者外部认证、双向认证才能改变当前的安全状态。

总共有1到15种状态可以设定，用半字节来表示。

在MF下有建立EF、安装密钥、建立DF、注册DF的安全条件；在DF下有建立EF和安装密钥的安全条件；对于EF而言分别有读、写、锁定、解锁、增值、减值等操作的安全条件。

所谓的安全条件AC就是定义卡片应该处于什么样的安全状态下，才能满足相应的操作。安全条件为一个字节，具体定义为：

其中高两位b8b7定义比较模式，分别为等于、小于、大于等于、不等于；b6用来定义是否采用安全报文；b5用来表示和当前DF的安全状态比较还是和MF的安全状态比较；b4b3b2b1则表示比较时参考的安全状态。

简单地说如果卡片MF的安全状态是05，当前DF的安全状态是08，如果在当前DF下有一个EF的读AC=43、写AC=99，那么就可以对该EF进行读操作，但是不能写。

在密钥中有两个安全条件值ACV，其中第一个ACV用来指明这个密钥的使用条件、而第二个ACV的后四位数据用来指明正确认证密钥后将要转换的后续状态。同样每条密钥中还有一个用来指出更新密钥需要遵循的安全状态。

下图用来说明安全状态的转换

该图说明只有在MF下验证DES密钥之后，才能进入DF下进行PIN验证，并且将DF的安全状态改变为c。

StarCOS的安全机制是目前见到过的最灵活和最有效的安全机制，对于文件的不同操作可以非常方便地定义安全条件，即可以参考当前的DF值也可以参考MF下的值。

唯一的限制是在98年版的StarCOS S2.1中，仅支持二级文件目录，亦即在MF下只有一级DF，虽然稍显不足，但是也基本上可以满足大多数应用的需求。

http://blog.sina.com.cn/s/blog_4df8400a0100gpm6.html

TimeCOS是握奇公司推出的智能卡操作系统，也可以说是国内早期自己开发的为数不多的几款COS之一。当然随着后来国内公司对于CPU卡开发的投入，其他公司的COS产品也纷纷推出。

其实从握奇的TimeCOS来看，早期的1.0版本和目前流行的TimeCOS版本之间在安全机制方面存在很大的差别。TimeCOS1.0采用的是按位比较的状态机机制，也就是说TimeCOS1.0在内存中维护一个安全状态字节，这个字节的每个位分别对应一种安全状态，在初始情况下这个状态字节为00，只有通过外部认证或者是通过PIN的验证之后这个字节的某个位才能从0转变为1。而某个文件或者应用的安全状态一般都需要这个安全状态字节的某些位必须被置1之后才能被访问或者操作。这种模式简单易行，基本可以满足各种基本的应用需求。

但是在随后的TimeCOS版本中，握奇借鉴了StarCOS的安全机制模式，也采用前后顺序状态，以及状态数值之间的大小比较来确定安全状态是否被满足。

在握奇各种细分的COS版本中，基本上都采用了这种类StarCOS的安全机制，其中包括：PBOC产品、PKI产品、PSAM产品等。

具体的实施方法是：卡片的内存中同样会有一个安全状态字节，不过这个字节的变化不是按位改变，而是由认证密钥（或者PIN）中预设的“后续状态”来直接指定，对于卡片中存储的任何一个密钥（含PIN）都有一个所谓的“后续状态”。

这个字节被划分为前后两个半字节，分别用来指出MF和当前DF的状态。

卡片各种操作的权限的获得就是通过这个状态的转变来实现，该状态的取值范围是0到15，操作的权限用一个字节表示，分为左右两个半字节，其中左半字节和右半字节的取值均为0-15（0x0-0xF），可以表示为0xXY，如果当前DF的安全状态值V满足Y<=V<=X的条件，那么就获得了操作权限。 比如一个文件的读权限是0x52，而写权限是0x84；密钥1的后续状态是0x03，而密钥2的后续状态是0x05。那么认证密钥1之后可以文件满足读权限，但是不可写；认证密钥2后可以满足文件的写权限，但是不可读。 如果要把某个权限设定为可以自由操作，无需认证密钥，那么可以设为0xF0，这种情况下无论安全状态字节的值V是什么都满足0<=V<=15的条件。当然如果要把某个权限设定为禁止，即无论认证多少密钥都不能满足权限，那么可以设定为0x1F，在这种情况下无论S为任何值V都不能满足小于等于1并且大于等于15的条件。 特别地如果操作权限为0x0Y（即0xXY中的X=0），则表示需要比较MF下的安全状态大于Y。 如果仔细分析了StarCOS的安全机制，可以发现握奇采用的机制是在StarCOS的基础上进行的一个改进版本，因为StarCOS可以定义比较模式，也就是StarCOS可以更灵活地定义比较安全状态究竟是采用大于、小于还是等于或者不等于的模式。 国内另外一些厂商推出的COS多数借鉴握奇的TimeCOS安全机制，比如明华的所谓SmartCOS，以及复旦的FMCOS。 而航天金卡的PowerCOS则是完全照搬了StarCOS的安全机制。 国内的一些应用开发商和某些行业标准制定者，在进行系统开发和行业标准规划的过程中根本没有去认真阅读ISO7816的相关标准，仅把某家厂商的用户手册作为唯一的参考，甚至错误地认为全世界所有的COS都应该是这样的，实在让人无语！