读取EF.PLMNsel触发UICC安全状态不满足异常的排查求助

安全上下文未正确关联 #

即使CHV1已验证，当前操作的安全上下文可能没绑定到CHV1对应的权限域。UICC卡的安全验证后，部分卡要求显式确认会话有效性，或者验证后需要保持当前安全域的激活状态。另外，若之前CHV1验证失败过，必须先调用resetRetryCounter重置重试计数器，再重新验证，否则残留的失败状态会导致权限检查不通过。

文件权限配置与实际不符 #

别完全依赖GSM 11.11的规范描述，部分运营商定制卡会修改DF.PLMNsel的权限配置——比如把读取/更新权限设为ADM而非CHV1。建议先读取目标文件的FCP（文件控制参数）确认实际权限：选中文件后调用getFileControlInformation(FCP_TLV_TAG, buffer, (short)0, (short)buffer.length)，解析其中的权限字段，看是否真的是CHV1权限。

API调用的细节疏漏 #

• 检查readBinary的参数：偏移量和长度必须在文件的实际范围内，部分卡会在权限检查前先校验参数合法性，但如果权限不满足，依然会直接抛出SECURITY_STATUS_NOT_SATISFIED。
• 确认文件选中状态：选中DF.PLMNsel后，后续操作中有没有不小心切换到其他文件？比如APDU处理逻辑中可能误执行了其他文件的选中命令，导致实际操作的不是目标文件。

CHV1禁用后的生效问题 #

如果CHV1已禁用，理论上应允许所有CHV1权限的操作，但部分卡的实现要求禁用CHV1后重新选中目标文件，权限配置才会生效。另外要确认禁用CHV1的操作是否成功——禁用CHV1需要ADM权限，若执行时没有足够权限，禁用操作实际未生效，自然还是会触发权限异常。

代码层面的常见错误 #

假设你的核心代码逻辑如下，重点检查这几个点：

// 选中DF.PLMNsel路径示例
byte[] plmnSelPath = {(byte)0x3F, (byte)0x00, (byte)0x7F, (byte)0x20, (byte)0x7F, (byte)0x21};
JCSystem.getFileInfo(plmnSelPath, (short)0, (short)plmnSelPath.length, buffer, (short)0);

// CHV1验证示例
byte[] chv1Pin = {(byte)0x31, (byte)0x32, (byte)0x33, (byte)0x34};
try {
    JCSystem.verify((byte)0x01, chv1Pin, (short)0, (short)chv1Pin.length);
} catch (UICCException e) {
    // 处理验证失败
}

// 读取二进制操作
try {
    JCSystem.readBinary((short)0, buffer, (short)0, (short)16);
} catch (UICCException e) {
    // 触发SECURITY_STATUS_NOT_SATISFIED异常
}

• 确认JCSystem.verify的第一个参数：CHV1的引用值是否正确，多数卡用(byte)0x01，但少数定制卡可能用其他值，需核对卡的规范。
• 尝试将验证和读取操作包裹在事务中：部分卡要求安全操作与文件操作在同一原子事务内，用JCSystem.beginTransaction()和JCSystem.commitTransaction()包裹整个流程再测试。

内容的提问来源于stack exchange，提问作者Typhaon