2026年eSIM机卡安全技术白皮书

第3页/共19页eSIM技术作为下一代通信终端的核心基础设施，正在从消费电子向物联网、车联网、工业互联网等更广阔的领域加速渗透。eUICC与终端设备之间的安全认证既是支撑eSIM规模化应用的关键能力，也是保障网络接入安全和用户身份真实可信的核心环节。近年来，国家高度重视新一代信息基础设施安全。围绕数字经济、物联网新型基础设施、车联网安全等方向，国家相关部门先后出台了一系列政策文件与行业指引，将“提升终端可信接入与安全管控能力”作为产业升级的重要任务之一。GSMA等国际标准化组织也持续推进eSIM相关规范的演进，为eSIM机卡安全技术提供了良好的标准与协议基础。在此背景下，全球智慧物联网联盟（GIIC）组织相关成员单位编写了《eSIM机卡安全技术白皮书》，旨在凝聚产业共识，推动eSIM机卡安全技术的标准化与规模化落地，为产业链各方提供统一的技术参考框架。本白皮书主要分为十个部分。第一部分介绍eSIM技术演进及由此带来的新型安全风险；第二部分阐述机卡安全的技术目标与设计原则；第三部分给出整体架构与状态模型；第四部分介绍方案所依据的密码学基础；第五部分详述配对与互认证的核心流程；第六部分定义命令格式与交互协议；第七部分讨论重试、锁定与会话保护等安全机制；第八部分介绍MEP多配置文件模式下的适配；第九部分分析典型异常场景与处置策略；第十部分阐述产业价值与后续演进方向。第4页/共19页组织单位：全球智慧物联网联盟（GIIC）牵头编制单位：中国联合网络通信有限公司、紫光同芯微电子有限公司、梵利特科技（北京）有限公司参与编制单位：芯昇科技有限公司、北京银联金卡科技有限公司、东信和平科技股份有限公司、北京中电华大电子设计有限责任公司、北京中广瑞波科技股份有限公司、楚天龙股份有限公司、恒宝股份有限公司第5页/共19页1行业背景与挑战 62技术目标与设计原则 63整体架构与状态模型 74密码学基础 85核心流程：配对与互认证 96命令格式与交互协议 7安全机制：重试、锁定与会话保护 8MEP多配置文件模式适配 159典型异常场景与处置 10产业价值与展望 第6页/共19页1行业背景与挑战1.1eSIM技术的产业演进eSIM是将传统可插拔SIM卡的功能嵌入到设备中的一种新型解决方案。通过eUICC（嵌入式通用集成电路卡）芯片承载，可实现配置文件（Profile）的远程下载、激活与切换，无需更换实体卡片。这一技术正在被广泛应用于智能手机、可穿戴设备、车载终端、工业物联网模组、智能电表、共享设备等场景。根据GSMA及主要市场调研机构的判断，eSIM正在从消费电子向更大规模的物联网与车联网市场加速渗透。eSIM的普及一方面提升了终端设计的灵活性和用户体验，另一方面也对产业链的安全管控能力提出了更高要求。1.2eSIM带来的新安全风险传统SIM卡是一种独立的物理实体，用户对卡片的“持有”即是网络接入身份的最直接体现。而eSIM在便利化的同时，也带来了几类新的安全风险：——eUICC被非法移植：攻击者可能将一台合法设备中的eUICC芯片取出并焊接到另一台未授权设备中，从而以原用户身份接入网络。——设备被非法更换eUICC：攻击者可能在已被合法激活的设备上更换eUICC，以绕过设备认证策略（如定制设备、补贴机等）。——批量盗用与黑灰产风险：未做配对的eUICC在二手流通环节存在被恶意提取、复用的风险，影响产业相关方和合规企业用户的资产安全。上述风险均直接威胁到“机”与“卡”之间应有的对应关系。要真正构建可信的eSIM生态，必须从协议层面建立机卡之间的强认证能力。2技术目标与设计原则2.1总体目标本方案的目标是在eUICC与设备之间建立一种基于密码学协议的双向锁定关系，使得：——一旦配对完成，设备与eUICC形成唯一对应关系，任何一方被替换均无法通过认证。——已配对的eUICC接入其他设备时，新设备无法通过互认证，eUICC拒绝提供网络认证服务。——已配对的设备接入其他eUICC时，设备识别该卡非原对应卡，拒绝完成配对或互认证流程。——配对过程在终端出厂前完成，不依赖联网或在线服务器，具备良好的离线可用性。2.2设计原则第7页/共19页方案遵循以下设计原则：——标准密码学算法优先：采用业界广泛认可的ECDH、AES等标准算法，避免私有密码学。——最小信任假设：不依赖在线的可信第三方，仅依赖出厂前的一次性配对过程。——流程对称简洁：配对与互认证流程在结构上保持高度对称，便于芯片实现与互通测试。——可配置可灰度：eSIMLock功能在生产阶段可配置开关，便于业务管理方按场景灵活启用。——通信层与安全层解耦：将Modem超时等通信问题与密码学验证失败明确区分，避免误锁定。——设备侧密钥安全存储：设备侧对协商密钥Ks的存储安全等级直接决定了整体方案的安全基线。设计上要求设备侧具备硬件级或TEE级的密钥保护能力，作为启用eSIMLock功能的前提条件之一。3整体架构与状态模型3.1通信通道方案在不改动现有终端-eUICC接口的基础上，复用SIMToolkit（STK）机制中的GETINPUT主动命令，承载配对与互认证所需的APDU数据交换。设备完成上电与初始化后，eUICC通过GETINPUT主动向设备发起请求，设备通过TerminalResponse应答，构成完整的双向交互。3.2状态定义eUICC内部维护四种核心状态：状态值状态名称说明0x00初始状态eUICC尚未与任何设备完成配对0x01配对完成已成功完成首次密钥协商与配对0x02互认证成功本次上电会话已完成双向身份认证0x03配对或互认证重试计数器耗尽，eUICC拒绝一切配对与互认证请求3.3状态矩阵与预期行为设备与eUICC的状态组合决定了系统应执行的下一步动作。预期行为如下：eUICC状态设备状态预期行为未配对未配对正常执行配对流程第8页/共19页eUICC状态设备状态预期行为未配对异常：设备可能被更换了eUICC卡，设备应拒绝配对请求未配对异常：eUICC卡可能被移植到新设备，设备应拒绝互认证请求正常执行互认证流程任意eUICC通过GETINPUT(forlocked)通知设备4密码学基础4.1非对称算法方案采用基于椭圆曲线的密钥协商算法ECKA，选用NISTP-256曲线（ECC256-bit实现方式为ECDH（椭圆曲线Diffie-Hellman）。密钥协商的形式化表达为：其中SS为协商生成的共享密钥，SK为己方私钥，PK为对方公钥，×表示NISTP-256曲线上的标量点乘运算。eUICC与设备各自生成临时密钥对（otSK/otPK），交换公钥后双方都可独立计算出同一个共享密钥SS。4.2对称算法方案采用AES-128-CCM（CounterwithCBC-MAC）作为认证加密算法（参见NISTSP800-38C），同时提供数据机密性、完整性与来源认证性。CCM由CTR模式（加密）与CBC-MAC（认证）组合而成，均为eUICC芯片的标准硬件加速能力，与GlobalPlatformSCP03的密码学栈完全一致，具备最广泛的智能卡平台兼容性。Nonce：长度为12字节（96-bit），对应CCM格式参数q=3，支持最大消息长度2²4-1字节，满足本方案需求。每次会话的Nonce必须唯一，禁止重复使用，推荐由安全随机数发生器直接生成12字节随机值。eUICC侧和设备侧分别独立生成各自的Nonce（即nonce_icc和nonce_dev）。认证标签（Tag）：长度为16字节（128-bit），取最高认证强度。CCM运算完成后，Tag附加在密文之后一并传输。接收方在解密前必须首先验证Tag，Tag验证失败时应终止当前会话且不递减重试计数器（详见第7.2节）。明文：本方案中CCM加密的明文为16字节挑战值random。附加认证数据（AAD将1字节会话方向标识作为AAD输入CCM运算（0x01表示Device→eUICC，0x02表示eUICC→Device），用于防止反射攻击。AAD不被加密，仅纳入认证标签计算。4.3共享密钥的产生第9页/共19页配对阶段，双方通过ECDH协商出共享秘密SS后，取其前16字节作为对称密钥Ks：此Ks同时用于AES-CCM运算中的加密与认证标签生成（CCM模式内部使用同一密钥完成CTR加密和CBC-MAC计算），在配对成功后由eUICC和设备分别持久化保存，作为后续每次互认证流程的唯一密钥。此处“持久化保存”指将Ks写入非易失性安全存储区域（如eUICC侧的NVM、设备侧的SE/TEE安全存储），确保掉电后数据不丢失。Ks在eUICC和设备中长期有效。设备侧应将Ks存储于安全环境中（如SE、TEE、安全芯片或硬件级密钥存储区），禁止以明文形式存储于普通文件系统或可被应用层访问的存储区域。若设备不具备上述安全存储能力，则应在产品安全评估中明确标注为已知风险，并由业务管理方根据业务场景决定是否启用eSIMLock功能。4.4共享密钥的归属与生命周期Ks的存储层级与Profile的关系是本方案在多Profile场景下的核心设计决策，明确如Ks归属于eUICC平台级（ISD-R层），而非某个具体Profile。这意味着Ks独立于Profile的启用/禁用/删除/下载操作，在eUICC的整个配对生命周期内持续有效。设计理由：配对关系的本质是设备硬件与eUICC芯片之间的物理配对，而非设备与某个Profile之间的逻辑配对。将Ks关联到Profile层会导致以下问题：Profile切换时需要重新配对或多次配对，增加流程复杂度并暴露更多攻击面；Profile被删除后配对关系失效，与“防止eUICC物理移植”的安全目标相矛盾。GETINPUT的发起上下文：虽然GETINPUT命令在协议层上是由当前EnabledProfile的STKApplet发起，但配对/互认证的逻辑实体应为eUICC平台级安全模块。建议的实现方式为：eUICC平台在每个Profile的STKApplet中注册一个统一的eSIMLock事件处理入口，确保无论哪个Profile处于启用状态，均可触发配对或互认证流程并访问平台级存储的Ks。Profile切换场景处理：当Profile切换（enable/disable）不涉及eUICC冷复位时，已完成的互认证状态应保持有效，无需重新认证。当Profile切换触发eUICC冷复位时，新启用的Profile上电后应自动触发互认证流程（非重新配对），复用平台级Ks完成认证。5核心流程：配对与互认证5.1配对流程配对流程发生在设备和eUICC均处于未配对状态时，通常在终端出厂前完成。第10页/共19页主要步骤如下：——[1]~[4]设备上电后与eUICC进行初始化会话，发送TerminalProfile命令。注：步骤[3]中的“初始化”指设备上电后对eUICC执行的标准UICC初始化过程，包括ATR、PPS、SELECT等ISO7816标准命令序列——[5]eUICC检查内部状态，若未配对则发起配对流程，否则进入相应分支。——[6]eUICC生成临时密钥对otSK.EUICC.ECKA/otPK.EUICC.ECKA，以及12字节随机Nonce（nonce_icc）和16字节挑战值random_icc。第11页/共19页——[7]eUICC通过GETINPUT(forbinding)将其公钥、nonce_icc、random_icc下发给设备。——[8]设备校验自身状态：若一致（未配对）则继续；若不一致（已配对）则返回GeneralResult=0x20，流程终止并拒绝接入网络，eUICC不递减重试计数器。——[9]设备生成自身临时密钥对，使用ECDH计算共享密钥Ks=SS[0:16]。设备同时生成自身12字节随机Nonce（nonce_dev）和16字节挑战值random_dev。——[10]设备计算(Ciphertext1,Tag1)=AES-CCM-ENC(Ks,nonce_icc,random_icc,AAD=0x01)，将Cryptogram1=Ciphertext1||Tag1拼接，通过TerminalResponse将自身公钥、Cryptogram1（32字节）、nonce_dev、random_dev发送给eUICC。——[11]~[12]eUICC独立计算Ks'，然后对收到的Cryptogram1执行AES-CCM-DEC(Ks',nonce_icc,Ciphertext1,Tag1,AAD=0x01)：.若Tag1验证失败（完整性校验不通过），表明数据可能被篡改，eUICC终止当前会话但不递减重试计数器，返回SW=6984（表示完整性校验失败）。.若Tag1验证通过但解密得到的random_icc'与本地random_icc不匹配，递减配对计数器：未达最大次数返回63CX，达最大次数则锁定返回6983。.若Tag1验证通过且random_icc匹配，将对应的重试计数器恢复至出厂预设的初始最大值，返回9000。注：状态切换时机约定：eUICC侧在步骤[11]验证Cryptogram1成功（准备返回SW=9000）时，暂不将自身状态切换为“配对完成”，而是标记为内部中间态“配对待确认”。eUICC在步骤[13]通过GETINPUT(forresult)收到设备返回的Result=0后，再将状态最终提交为“配对完成”并持久化。若下次上电时eUICC仍处于“配对待确认”状态，应自动回退至“未配对”状态，重新执行配对流程。设备侧在步骤[16]验证Cryptogram2成功后，才将自身状态从“未配对”切换为“配对完成”，并持久——[13]~[16]eUICC计算(Ciphertext2,Tag2)=AES-CCM-ENC(Ks',nonce_dev,random_dev,AAD=0x02)，将Cryptogram2=Ciphertext2||Tag2拼接，通过GETINPUT(forresult)连同验证结果状态字一并发给设备。设备收到后，首先校验Tag2：Tag2验证失败则认为数据被篡改，终止流程，不保存Ks；Tag2验证通过后再比对解密得到的random_dev'与本地random_dev是否匹配，匹配则保存Ks，允许接入网络。），），——[17]配对/互认证流程成功完成后，设备继续执行常规SIM初始化流程（读取IMSI、执行网络认证AUTHENTICATE、读取EF文件等），进入正常的网络接入阶段。5.2互认证流程第12页/共19页配对完成后，每次设备上电都应执行互认证流程，使用配对阶段保存的共享密钥Ks/Ks'进行双向验证。互认证流程与配对流程结构相似，但有以下关键差异：——不再涉及密钥协商，直接复用已存储的Ks/Ks'。——状态校验逻辑相反：双方均应处于“已配对”状态才视为状态一致。——设备发送的TerminalResponse不再携带公钥，仅携带Cryptogram1（32字节，含Ciphertext1||Tag1）、nonce_dev和random_dev。Cryptogram的计算与验证方式同配对流程，均采用AES-CCM认证加密，Tag验证失败不递减计数器。5.3设备侧解除配对设备侧自身的解除配对操作（清除本地保存的Ks并重置配对状态）不在本白皮书范围内，由设备厂商根据自身产品安全策略自行定义。业务管理方可结合设备管理平台、保修流程、二次销售流程等制定相应的解除配对授权机制。第13页/共19页6命令格式与交互协议方案定义了四类核心STK主动命令，分别用于配对、互认证、结果上报和锁定通知。每类命令均复用GETINPUT命令格式（Commanddetails=8103012304），通过Deviceidentities字段中的次级标识符（F1/F2/F3/F4）区分功能场景。6.1命令分类概览命令名称DeviceIdentities用途binding)820281F1eUICC发起配对请求，下发临时公钥与挑战值auth)820281F2eUICC发起互认证请求，下发挑战值result)820281F3eUICC将本次验证结果（含Cryptogram2与状态字）下发给设备，并通过TerminalResponse获取设备侧验证结果locked)820281F4eUICC处于锁定状态时主动通知设备6.2关键字段约定——公钥格式：otPK.EUICC.ECKA与otPK.DEVICE.ECKA均采用未压缩EC点格式，以0x04开头，256-bit曲线下公钥实际值64字节，总长65字节。——Textstring编码：0x04表示采用GSM默认字母表8-bit编码。——拒绝应答：设备检测到状态不一致时，应发送Result=0x830120（GeneralResult=0x20），eUICC据此终止会话且不递减重试计数器。——响应状态字：9000表示成功；63CX表示失败但仍可重试，X为剩余可用次数；6983表示已锁定；6984表示CCM认证标签（Tag）校验失败，疑似数据篡改，该状态不递减重试计数器。——Nonce格式：nonce_icc与nonce_dev均为12字节随机值，由安全随机数发生器生成，每次会话唯一。——Cryptogram格式：Cryptogram=Ciphertext（16字节）||Tag（16字节），总长32字节。其中Ciphertext为AES-CCM加密输出，Tag为CCM认证标签。7安全机制：重试、锁定与会话保护7.1重试计数器管理配对与互认证使用各自独立的重试计数器，在eSIM生产阶段分别配置初始值。基本规则如下：第14页/共19页——计数器取值范围为0x01~0xFE，表示允许的最大尝试次数。0xFF表示不限制尝试次数（仅在特定测试或调试场景下使用），与GlobalPlatform规范惯例保持一致。0x00为保留值。——由于响应状态字63CX仅能通过X（单个十六进制位）表达0x00~0x0F的剩余次数，当实际剩余次数大于15时，eUICC应返回63CF；当剩余次数降至15及以下时，返回真实剩余值63CX。——当任一计数器达到最大失败值时，eUICC应进入锁定状态。注：采用独立计数器的设计理由：配对与互认证虽然在状态机上是先后关系，但两个阶段的安全策略和运营需求不同。配对通常在出厂产线环境下执行，通信链路可控，可设置较低的重试次数（如3~5次）；互认证在设备的整个生命周期中每次上电都会执行，面临更多通信层干扰，适合配置较高的重试次数。此外，业务管理方通过管理渠道解锁时，可能仅需重置互认证计数器而保留配对计数器的状7.2计数器递减规则计数器仅在eUICC侧完成完整的密码学验证且确认密钥不匹配时才递减。具体而言，在配对或互认证流程的步骤[11]中，eUICC首先对收到的Cryptogram1执行AES-CCM解密，当且仅当CCM认证标签（Tag）验证通过、但解密得到的明文与本地挑战值不匹配时，才递减对应的计数器（配对流程递减配对计数器，互认证流程递减互认证计数器）。Tag验证失败、通信层异常等其他未完成完整验证的情形均不递减计数器（详见第7.3节）。7.3计数器不递减的场景以下情形虽然流程未成功完成，但不应递减计数器，以避免合法用户被误锁定：——设备返回Result=1：eUICC侧Cryptogram1已通过，Result=1可能是设备侧通信传输异常。——设备因状态不一致而拒绝（GeneralResult=0x20）：属于设备侧前置校验，eUICC尚未进行密码验证。——Modem超时导致的无效TerminalResponse：属于通信层问题，并非安全事件。——CCM认证标签（Tag）校验失败：Tag校验未通过说明密文在传输过程中被篡改或数据损坏，不能确定是密钥不匹配，属于通信完整性事件而非安全认证事件，不应递减计数器。eUICC应返回SW=6984以区分此场景。7.4单次会话保护在同一次上电会话内，每个计数器最多递减一次，避免因为通信链路异常导致计数器被快速耗尽，从而误将合法用户锁定。7.5锁定状态第15页/共19页当eUICC进入锁定状态后，每次上电应主动发送GETINPUT(forlocked)通知设备，设备据此停止一切接入尝试。锁定状态不可在设备侧自行恢复，需通过授权的管理渠道进行干预。7.6通信层重试机制由于Modem初始化速度通常远快于AP启动速度，部分Modem会在AP尚未就绪时因内部超时机制发送无效TerminalResponse。为提升兼容性，eUICC宜支持通信层重试机制：若Modem未能正确回复GETINPUT(forauth/forresult)，eUICC可重新下发该命令，建议支持3次重试。该重试属于通信层范畴，不消耗安全重试计数器。eUICC实现应能明确区分Modem超时与真正的密码验证失败。7.7模组兼容性指引本方案通过GETINPUT命令的DeviceIdentities字段扩展标识符（F1~F4）区分不同功能场景。由于该扩展超出了现有ETSITS102.223中定义的标准设备标识值范围，部分模组的STK驱动或AT命令解析层可能无法正确识别和透传这些命令，具体可能表现为：模组未向AP层上报GETINPUT命令、AT+STGI返回异常、或直接返回TerminalResponse错误码。建议模组厂商在支持本方案时，确保以下能力：——STK驱动能够识别并透传DeviceIdentities中F1~F4标识符的GETINPUT命令；——AT指令层能够正确上报并携带扩展标识符信息；——对于不支持该扩展的存量模组，应明确在产品规格中标注兼容性限制。产业链各方在方案部署初期，建议建立联合兼容性测试机制，由eUICC供应商与主流模组厂商协同完成端到端验证。8MEP多配置文件模式适配在多启用配置文件（MultipleEnabledProfiles,MEP）场景下，单张eUICC可同时启用多个Profile，本方案需在不同MEP模式下保持一致的安全语义：——MEP-A1/A2模式：配对或互认证流程应仅在Port#0以外的端口上发起，且应由第一个完成UICC初始化的LSI（非Port#0）触发。——MEP-B模式：配对或互认证流程应由第一个完成UICC初始化的LSI触发。——当配置文件在某个LSI上被启用或禁用时，终端通过ManageLsiReset重置目标端口；由于不涉及冷/热复位，目标端口不需要重新执行配对或互认证流程。——eUICC一旦锁定，应在所有活跃端口上发送GETINPUT(forlocked)，以确保设备能在任意端口感知到锁定事件。第16页/共19页在MEP模式下，Ks同样存储于eUICC平台级，所有活跃LSI/端口共享同一配对关系。各端口上的Profile独立触发互认证流程时，均使用同一Ks进行验证，认证结果在eUICC平台级统一维护。任一端口互认证成功后，其他端口无需重复认证（除非发生冷复位）。9典型异常场景与处置本章对典型异常场景进行分类讨论。9.1~9.3为物理替换类攻击场景，涵盖eUICC或设备被非法替换的各种组合及防护边界；9.4~9.6为验证失败与系统异常的恢复处理；9.7为中继攻击风险分析，讨论通过无线链路中继绕过互认证的攻击路径及防护方向。9.1eUICC卡被更换场景：设备已配对，eUICC被更换为另一张卡。根据新卡是否支持eSIMLock，处理方式不同：（a）新卡支持eSIMLock但未配对：eUICC发起GETINPUT(forbinding)，但设备内部已有Ks。设备据状态矩阵识别为“状态不一致”，发送GeneralResult=0x20，终止流程并拒绝接入网络。eUICC不递减重试计数器。（b）新卡不支持eSIMLock或被篡改：eUICC不发送任何GETINPUT命令。设备在完成UICC初始化后启动等待超时计时器，若在超时时间内未收到GETINPUT(forauth)命令，设备应视为异常卡，拒绝接入网络。。9.2eUICC卡被移植到新设备场景：eUICC已配对，被移植到一台新设备。根据目标设备是否支持eSIMLock，处理方式不同：（a）目标设备支持eSIMLock但未配对：eUICC发起GETINPUT(forauth)，设备内部不存在Ks，识别为状态不一致，发送GeneralResult=0x20，终止流程并拒绝接入网络。eUICC不递减重试计数器。（b）目标设备不支持eSIMLock：eUICC发送GETINPUT(forauth)，但设备的STK驱动不识别该命令，可能返回不支持的TerminalResponse或完全不响应。eUICC在通信层重试（最多3次，参见第7.6节）均未获得有效响应后，应视为互认证失败，拒绝提供网络认证服务。eUICC不递减互认证重试计数器，因为该失败属于通信层问题而非密码学验证失败。9.3设备与eUICC同时被更换场景：攻击者同时更换了设备和eUICC，且双方均未配对。此时新设备与新卡可正常完成配对流程，超出本方案的协议层防护范围。建议结合设备管理平台、IMEI白名单、远程证明等更高层手段进行管控。第17页/共19页同样地，若终端设备本身的配对逻辑被篡改或完全伪造（如不执行Cryptogram2验证即返回成功），也超出本方案的协议层防护范围。本方案假设设备侧的配对程序完整性由设备厂商通过安全启动（SecureBoot）、代码签名等机制保障。建议在实际部署中，将设备侧可信执行作为启用eSIMLock的前提条件。9.4互认证失败但未锁定场景一：eUICC返回SW=63CX，表示本次验证失败但仍可重试。失败可能源于通信异常、时序问题或密钥数据损坏。设备可在新一轮上电会话中重新发起互认证。重试流程说明：重试无需人工干预，由eUICC在下次上电后根据自身状态自动发起对应的GETINPUT命令，设备据此响应。eUICC在发起流程前应先检查对应计数器是否大于零，若已为零则直接进入锁定状态，发送GETINPUT(forlocked)。场景二：eUICC返回SW=6984，表示CCM认证标签校验失败，疑似传输数据被篡改或损坏，重试计数器不受影响。设备可立即在当前会话中重试（如通信层重试机制允许），或在新一轮上电会话中重新发起互认证。若连续多次出现6984，建议设备上报异常事件至设备管理平台，排查通信链路安全性。场景：连续失败次数达到上限，eUICC进入锁定状态。eUICC在每次上电时通过GETINPUT(forlocked)通知设备，设备停止一切尝试，需通过授权管理渠道恢复。9.6配对过程中断电的状态恢复场景：配对流程执行过程中发生意外断电，导致eUICC与设备的状态不一致。eUICC侧恢复：由于eUICC采用“配对待确认”中间态机制（详见第5.1节状态切换时机约定），在收到设备确认前不会最终提交“配对完成”状态，因此断电后重新上电时eUICC自动回退至“未配对”状态。设备侧处理分两种情况：（a）设备侧也未完成保存（步骤[16]之前断电）：双方均为“未配对”，重新上电后正常执行配对流程，无需特殊处理。（b）设备侧已完成保存（步骤[16]之后断电的极端窗口重新上电后出现eUICC（未配对）+设备（已配对）的状态组合。根据状态矩阵，设备应拒绝eUICC的配对请求。由于设备无法区分此场景与真实的eUICC被更换场景，为保证安全语义的一致性，不应在设备侧自动清除Ks。实践建议：步骤[16]断电窗口极为短暂（仅在设备保存Ks与向eUICC返回Result之间在产线环境下发生概率极低。9.7中继攻击风险分析第18页/共19页场景：攻击者通过合规流程完成机卡配对与eSIM开户后，将eUICC从原设备中物理剥离，安装到攻击者控制的设备中，同时借助Wlan等无线链路在攻击者设备与原合法设备之间建立命令中继通道。eUICC发出的GETINPUT命令经中继通道转发至原设备，原设备使用其本地保存的Ks正确完成互认证响应，响应结果再经中继通道回传