标签：平衡 获取 算法 oca one 另一个 制造商 两种 事件
本文档提供了一种体系结构方法，作为所有市场中设备的远程SIM配置的建议解决方案。体系结构的主要目标是为设备的远程SIM配置提供必要的凭据以获取移动网络访问权限。该版本专注于消费类市场的设备。请注意，SGP.21 V1.0 [23]尚未弃用。
本文档的目的是定义一个通用架构框架，以实现设备中的嵌入式UICC（eUICC）的远程SIM卡配置和管理。此架构框架的采用旨在为确保运营商之间在不同部署方案中进行远程SIM配置的全球互操作性提供基础。
在运营商，SIM解决方案提供商，设备供应商，标准组织，网络基础设施供应商，服务提供商和其他行业机构内部工作的技术专家。
“必须”，“不得”，“要求”，“应该”，“不应该”，“应该”，“不应该”，“推荐”，“可能“和”可选“在RFC2119 [6]中进行了解释。 “FFS”或“进一步研究”意味着它将包含在SGP.22 V2.1中。
本节包含与嵌入式UICC的GSMA远程SIM配置系统相关的原则。基于本文档中描述的要求的解决方案必须以非歧视的方式提供。
BAS1现有标准和规范应尽可能用于eUICC和相关供应系统的规范。
BAS2 GlobalPlatform规范应作为实施eUICC的首选框架。
BAS3 eUICC的总体安全性与相关的管理流程一起，在任何情况下都应至少与当前可拆卸的UICC及其供应流程相同。
BAS4 eUICC及其远程SIM供应系统的体系结构应符合3GPP TS 21.133 [7]的要求。
BAS5体系结构应该支持操作员证书保护水平，这至少与当前的安全水平相当。这特别适用于：?密钥和认证参数的机密性; ?订户身份（例如IMSI）的完整性。
BAS6体系结构应支持所有Profile内容的安全级别，这至少与UICC当前的安全级别相同。
BAS7架构不应损害用户数据的安全性和隐私，也不会损害最终用户数据的安全和隐私。取决于地域的示例包括可用于跟踪的身份，例如ICCID，MSISDN，EID，IMSI Ki等。
BAS8监管问题被认为超出了本文的范围。但是，任何可用于识别个人身份的数据均应视为个人数据并受当地法规的约束。 EID，ICCID等。
PRO1 Profile是发行运营商的财产并受其控制。
PRO2 Profile不存在于eUICC之外。即 Profile始终位于特定的eUICC上。
PRO3个人资料应由其ICCID唯一标识。
PRO4启用 Profile与eUICC组合应能够承载UICC的所有逻辑特性。
PRO5启用 Profile后，将应用ETSI 102 221 [2]规范中所述的所有相关UICC特性或功能，但本规范中定义的例外情况除外。
PRO6除了eUICC存储器复位和eUICC测试存储器复位功能之外，只能在禁用状态下删除 Profile。
PRO7 Profile Management应受政策约束。
PRO8 Profile应该是操作 Profile， Profile或测试 Profile。
EUM1 eUICC制造商负责eUICC的初始密码配置和安全架构。
EUM2 eUICC由eUICC制造商（EUM）提供。
EUM3 eUICC制造商的产品和流程的相关部分通过了GSMA批准的认证流程。
EUM4 EUM颁发eUICC证书以允许：?eUICC认证和其他实体的认证证明; ?在SM-DP +和eUICC之间建立认证的密钥集。
EUM5 eUICC制造商负责实施驻留在eUICC中的任何LPA元素，并遵守LPA与第4.10.3节中的要求。
DM1设备制造商负责实施驻留在设备上的任何LPA元素以及LPA符合第4.10.2节的要求。
DM2设备制造商负责实施驻留在主设备上的任何应用程序，以允许本地用户界面访问配套设备。
本节描述与该架构及其运营相关的运营商和服务提供商角色的特征。其他特征存在但被认为超出范围。
OPE1操作员可通过ES2 +接口访问SM-DP +。 OPE2如果订户选择了服务提供商，该服务提供商将启动 Profile包的配置。
OPE3运营商（可能代表服务提供商）规定了 Profile特征以及类似于可移动UICC的任何特征和应用。
OPE4操作员能够使用OTA平台来管理eUICC（RAM，RFM）中已启用 Profile的内容。
CIS1证书颁发者为远程SIM资源调配实体颁发证书，并作为可信第三方来验证系统的实体。 CIS2证书颁发者通过超出本规范范围的接口与SM-DP +，SM-DS和EUM进行通信。
本节包含嵌入式UICC的Remote SIM Provisioning系统体系结构的功能描述。
本节介绍eUICC的内部高层架构。
eUICC体系结构与GSMA远程SIM规范[8]中使用的相似。
[SGP.02 GSMA Remote SIM Provisioning of Embedded UICC Technical specification]
profile基于GlobalPlatform卡片规范[9]中定义的安全框架进行配置。
[GPC_SPE_034 GlobalPlatform Card Specification with its Amendments]
嵌入式UICC控制权限安全域（ECASD）负责安全存储支持eUICC上所需安全域所需的凭证。在eUICC上只有一个ECASD。如[9]中所述，eUICC制造过程中ECASD应由EUM进行安装和个性化。 ECASD应具有以下属性：?
ISD-R负责创建新的ISD-Ps和所有ISD-Ps的生命周期管理。
ISD-P是用于托管Profile的安全容器（安全域）。 ISD-P与Profile包解释器协作用于Profile下载和安装，以解码/解释接收到的绑定Profile包。 ISD-P是SM-DP +的卡上代表。
MNO-SD是运营商的卡上代表。它包含运营商的OverThe-Air（OTA）密钥并提供安全的OTA通道。
提供profile策略规则验证和执行的eUICC操作系统（OS）服务。
电信框架是一种操作系统服务，为ISD-Ps中托管的NAA提供标准化的网络认证算法。此外，它还提供了使用必要参数配置算法的功能。
profile包解释器是一个eUICC操作系统服务，它使用目标eUICC的特定内部格式将profile包数据转换为已安装的profile。
LPA服务提供对LPA功能所需的服务和数据的以下必要访问：
EUICC1 eUICC应该是一个由硬件和软件组成的独立的防篡改组件，能够安全地托管应用程序以及机密和加密数据。
EUICC2可拆卸的eUICC采用标准ETSI规格[2]封装。
EUICC3 eUICC应该是可移动的或不可移动的。
EUICC4具有启用profile的eUICC的行为应与UICC相同。
EUICC5 eUICC应能够包含零个或多个profile。
EUICC6最多只能在任何时间点启用一个profile。
EUICC7在eUICC上，NAA USIM或ISIM中的行为应与可移动的UICC NAA USIM或ISIM相同。 注：预期不会更改现有的3GPP / 3GPP2 USIM，CSIM和ISIM规范。
EUICC8 eUICC应支持Milenage [11]/[12]和TUAK [10]算法集
EUICC9 eUICC的所有权可能随着设备的使用寿命而改变。
EUICC10如果任何Profile Management操作未成功完成，则eUICC应保持其收到请求之前的状态。
EUICC11 eUICC应包含在制造过程中安装和个性化的ECASD和ISD-R安全域。
EUICC12在eUICC生产之后，不可能删除或禁用ECASD。
EUICC13 ISD-R应负责创建新的ISD-Ps和所有ISD-Ps的生命周期管理。
EUICC14在[9]中描述的eUICC制造过程中，ISM-R应该由EUM进行安装和个性化。
EUICC15 eUICC应能够支持eUICC存储器复位。这只能由最终用户请求。
EUICC16如果eUICC支持测试profile，则eUICC应支持eUICC测试存储器复位。
EUICC17 eUICC应支持由SIMalliance [5]定义的eUICC Profile Package Interoperable格式。
EUICC18 ISD-R应该：?
EUICC19 eUICC可提供LPA功能。
EUICC20应SM-DP +的要求，ISD-R应由ISD-R创建。
EUICC21 eUICC和SM-DP +之间的通信应受到真实性，完整性和机密性的保护。
EUICC22 eUICC不应导出安装在eUICC上的profile。
EUICC23 eUICC应实施profile的隔离并防止profile在其执行环境之外运行，即profile应在沙箱中运行。
EUICC24在eUICC上安装时，应确保绑定profile包的完整性。
EUICC26profile密钥和算法参数不能从eUICC中提取。
EUICC27所有加密功能应以强大的防篡改方式实施，并能抵抗边信道攻击。
EUICC28运营商应能够以安全和保密的方式更新eUICC在其profile中的OTA密钥，重用现有的OTA平台机制。
EUICC29下载的profile包应安装在eUICC处于禁用状态。
EUICC30 eUICC应始终在SM-DP +或SM-DS每次会话开始时的首次通信中报告其eSVN。
EUICC31 EUM应在用于验证eUICC认证的eUICC中安装eUICC证书。
EUICC32 EUM应在用于验证eUICC证书的eUICC中安装EUM证书。
EUICC33 eUICC应具有向SM-DS进行认证的手段。
EUICC34 eUICC应保护自己免受未经授权的访问。
EUICC35在profile删除后，eUICC应确保完全删除与profile相关的所有数据。
EUICC36 eUICC只接受eUICC或设备中的LPA发送的profile管理操作。
EUICC37 eUICC应拒绝与相应profile的profile策略规则相冲突的任何profile管理命令。
EUICC38如果任何绑定profile包下载或安装未成功完成，则eUICC应保持其收到请求之前的状态。
EUICC39 eUICC应支持GlobalPlatform安全元件访问控制[15]。
EUICC40应该在eUICC中预先设置一个默认的SM-DP +地址。
EUICC41 eUICC应存储根SM-DS地址。
EUICC42 eUICC应能够向LPA发送删除通知，通知通知接收方该profile已被删除。
EUICC43在EUICC42中，如果连接不可用于向通知接收器发送删除通知，每当连接再次可用时，每个通知都应保留并发送。
EUICC44在eUICC存储器复位的情况下，对于每个已删除的profile也应该执行删除通知过程。
EUICC45 eUICC应支持一系列标准功能和服务，包括但不限于Java应用程序，USIM工具包功能和GlobalPlatform功能。支持的功能和服务列表（例如API包名称和版本）应在技术规范（SGP.22 [24]）中明确引用。根据附件D中定义的不同嵌入式UICC类别，可以定义/支持不同的一组功能和服务。
EUICC46 eUICC应至少支持以下USIM工具包命令：?
EUICC47 eUICC应支持至少两组椭圆曲线参数在eUICC制造过程中由EUM预装，定义见GSMA SGP.22 V2.0 [24]。
EUICC48每份通知都应有唯一标识，并由eUICC签署。
EUICC49每条通知（删除，预先删除，禁用）均应重新受到攻击保护并由eUICC签署。
EUICC50（FFS）可以通过Profile参数请求发送预删除通知，通知发送通知后，eUICC将执行删除操作。
EUICC51（FFS）在成功尝试预删除通知的情况下，eUICC应删除为其进行通知尝试的profile。如果此通知不成功，但无论如何都将删除profile，则应在通信连接再次可用时立即保留并发送通知。
EUICC52该profile应能够包含每种通知类型的零个或多个通知接收者列表。
eUICC资格检查使SM-DP +能够使用eUICC发送的信息验证eUICC是否有资格安装profile。 eUICC向SM-DP +发送的用于资格检查目的的信息在此被称为eUICC资格检查信息。 由于Device / eUICC必须支持并作为eUICC资格检查信息集的一部分交付的设备功能，可能需要某些eUICC资格检查参数。 注意：设备功能是指设备提供的设备功能或服务启用功能，它可能对profile的内容或用于下载profile的过程有直接影响，并且需要eUICC的支持。
ELG1 eUICC应指明其支持的规格版本。在eUICC资格检查期间，该参数应传送给SM-DP +。
ELG2 eUICC应在eUICC资格检查信息中包含可用内存。
ELG3 eUICC应在资格检查信息中声明它是否无法接受其他profile。
ELG4 eUICC应提供有效的当前证书给由EUM签署的SM-DP +。
ELG5 eUICC应提供EUM的标识。
ELG6 eUICC应提供当前的操作系统版本。
ELG7 UICC应提供与可能需要Profile支持的服务有关的设备使能器信息（例如NFC使能器）。
ELG8资格检查信息应由eUICC保护，以便将其发送到SM-DP +以保护其完整性和真实性。
ELG9 eUICC应指示eUICC资格检查信息中支持的应用程序运行时环境版本和库版本。
ELG10 eUICC应指明eUICC资格检查信息中支持的加密算法及其各自的密钥长度。
ELG12 eUICC应指出其当前的认证状态。在eUICC资格检查期间，该参数应传送给SM-DP +。
ELG13如果eUICC支持NFC（例如CAT3），则应表明其支持相关的NFC服务，包括其当前的认证状态。
ELG14 eUICC应指明其类别（见附件D）。在eUICC资格检查过程中，该参数应发送到SM-DP +。
注：假定EID通常以其他方式与SM-DP +共享，并可用于资格审查程序。
DEV1设备应符合ETSI TS 102 221 [2]中的终端要求，但本规范中定义的例外情况除外。
DEV2应该有一种手段让最终用户通过设备软件获取EID。这只能通过LUI来实现。
DEV3如果eUICC在设备包装内，则EID应在设备包装上以机器可读形式打印。
DEV4配套设备与SM-DP +的承载连接只能由承载可用性决定。注意：伴侣设备可以使用任何可用的连接方法连接到SM-DP +。
DEV5符合GSMA NFC手持设备要求的设备[17]应支持设备应用程序使用的开放移动API [19]与在eUICC上启用的profile中运行的对应应用程序交换数据。
DEV6在设备中实施远程SIM卡配置规范不会影响3GPP TS 22.022 [16]中定义的SIM锁定机制的潜在用途。
DEV7当设备同时支持设备中的LPA和eUICC中的LPA时，设备应具有设置哪个LPA应使用的机制（设置或配置参数）。
DEV8最终用户应能修改DEV7中定义的参数。
DEV9在eUICC中支持不带LPA的嵌入式UICC的器件，应提供LPA功能。
DEV10在eUICC中仅支持带LPA的嵌入式UICC的设备，可以提供LPA功能。
DEV11如果器件支持器件测试模式，器件应支持eUICC测试存储器复位。 eUICC测试存储器复位只能在设备处于设备测试模式时由最终用户请求。
DEVCAP1
应该有一种机制能够为SM-DP +提供设备能力。
FAC1最终用户可以在不影响eUICC状态的情况下执行任何类型的器件复位。
FAC2设备应通过安全程序触发/请求eUICC存储器复位。
FAC3设备应通过安全程序触发/请求eUICC测试存储器复位。
MEM1 UICC存储器复位应删除eUICC上除标记为永久的预先安装的profile外的所有profile。
MEM2 eUICC内存复位应删除eUICC上的所有profile，而不管其profile策略规则，但不要删除profile或预安装的测试profile。
MEM3认证确认应被验证以启动eUICC存储器复位。
MEM4除MEM3外，还可以使用其他安全手段来执行eUICC存储器复位功能。应用基于LUI的重置功能所提供的相同级别的安全性。用户意图和确认请求应适用。
MEMT1 eUICC测试存储器复位应删除eUICC上的所有发布后安装的测试profile，包括已启用的测试profile（如果有）。
MEMT2简单确认应验证以启用eUICC测试存储器复位。
MEMT3如果测试profile不受支持，则不需要eUICC测试存储器复位。
TPRO1可移动eUICC支持本节中描述的测试profile的要求是可选的。如果测试profile不受支持，则不能将测试profile下载到eUICC中。
TPRO2测试profile不能使用Operator Credentials对运营商的移动网络进行认证。 eUICC应确保即使认证信息包含在测试profile中，这些profile也不能用于连接到任何运营商的移动网络。
TPRO3测试profile应该安装在它自己的ISD-P中。
TPRO4测试profile可以预先安装在eUICC上。
TPRO5当器件处于器件测试模式时，测试profile只能显示和使用。
TPRO6除eUICC存储器复位操作外，只能在器件测试模式下下载，安装，启用，禁用或删除eUICC中的测试profile。
TPRO7测试profile与任何其他profile一样，应通过经认证的SM-DP +进行管理。
TPRO8启用测试profile将覆盖不禁用profile策略规则。
TPRO9当设备测试模式被禁用时，LPA应禁用任何启用的测试profile。
TPRO10当测试profile被禁用时，eUICC应启用以前启用的操作profile（如果有）。
TPRO11设备测试模式激活应从最终用户模糊处理。
TPRO12退出设备测试模式时，将出现最终用户通知，提示测试仪执行eUICC测试存储器复位。设备可以实现一种连接外部SIM卡的机制，以便在设备修复的情况下进行测试，而不会影响eUICC的状态。
PPRO1授权profile应基于与profile所述相同的格式结构（图2）。
PPRO2如果使用当前已启用profile建立连接不成功，那么LPA可以根据最终用户对PPRO6中定义的操作的请求启用配置profile。如果这导致操作profile被禁用，则最终用户应首先同意由启用profile提供的通信丢失。
PPRO3授权profile及其关联的profile元数据在LUI上对最终用户不可见。
PPRO4最终用户不能选择授权profile。
PPRO5通过最终用户的任何行动，包括使用eUICC存储器复位，授权profile不得被删除。
PPRO6授权profile只能用于profile下载和相关profile维护功能的预期用途。授权profile不得用作操作profile。
PPRO7 PPRO6应在RSP架构中强制执行。
META1所有profile都应具有关联的profile元数据。
META2profile元数据应存储在eUICC中。
META3无论profile的状态如何，profile元数据都可以访问。
META4profile元数据应包含一个用于服务提供商名称的字段。注意：EFSPN已经在本规范以外的不同环境中使用过，并且可能为空。
META5profile元数据应包含用于profile的ICCID的字段。
META6profile元数据应包含profile最终用户昵称的字段。
META7profile元数据应包含一个字段，用于包含由操作员/服务提供商定义的简档的简短描述。
META8昵称应由最终用户编辑。
META9profile元数据应始终提供给LUI。
META10profile元数据应包含一个可选字段，以允许显示由运营商/服务提供商为相应profile定义的图标。
META11profile元数据应能够包含与profile关联的profile策略规则的副本。
META12所有profile应在profile元数据中唯一标识为操作，配置或测试profile。
META13如果profile已启用，运营商应能够使用ES6界面访问和更新其profile的以下profile元数据：?
NFC设备和NFC eUICC应符合以下要求列表：
NFC1 NFC设备应符合GSMA TS 26 [17]。
NFC2安装运营profile后，NFC eUICC应支持SGP.03 GSMA NFC UICC要求规范[20]中规定的所有要求。
NFC3 NFC设备应按照GlobalPlatform SEAC规范[15]中的规定检索并执行访问控制规则。
NFC4 eUICC应能够生成操作profile已被删除的证据。
NFC5所有NFC应用程序和NFC使能应用程序（例如ARA-M，PPSE，CRS，CREL等）附加到操作profile应包含在为profile创建的ISD-P下，可以在MNO-SD下或在SD层次结构，带有具有授权管理权限的自引导SSD。
NFC6 NFC eUICC解决方案应能够向NFC应用服务提供商保证eUICC和运营profile的组合是值得信赖的。该解决方案应基于CASD，该CASD是SGP.03 [20]规定的操作profile和场景Push 2B和场景3的一部分。
NFC7如果NFC eUICC符合M4M，则当包含M4M应用程序的profile被禁用时，eUICC应重置与该profile关联的所有M4M虚拟卡。
NFC8在eUICC资格审查期间，适当的NFC相关认证信息应作为与SM-DP +共享的信息的一部分。
NFC9 NFC设备应至少具有嵌入式eUICC，或者具备支持与CAT3和SGP.03 [20]兼容的可拆卸eUICC的能力。
根据运营商的输入/请求，SM-DP +负责创建，生成，管理和保护生成的profile。它还负责在Bound Profile Package包内提供profile，使Bound Profile Package包可用于安全传送。此外，SM-DP +负责请求在将要安装Profile的eUICC中创建ISD-P。 SM-DP +也将成为离卡实体，负责根据请求创建的ISD-P的生命周期管理。这是通过下面列出的不同功能执行的。
SMDP1 SM-DP +应代表运营商行事。
SMDP2 SM-DP +应能够启动ISD-P创建请求，作为Bound Profile Package包传送的一部分。
SMDP3 SM-DP +应建立eUICC的端到端安全通道，以在eUICC上下载和安装Bound Profile Package包。
SMDP4 SM-DP +应链接Protected Profile Package包，以便仅在相应运营商的请求下才能绑定到特定的eUICC。
SMDP5 SM-DP +应仅在相应eUICC的请求下从链接的Protected Profile Package创建Bound Profile Package。
SMDP6 SM-DP +应能够为任何认证的eUICC创建Bound Profile Package包。
SMDP7只有目标eUICC才能解密由SM-DP +传送的Bound Profile Package包的内容。
SMDP8profile包仅在完成所有生产步骤，profile包保护和绑定后才能离开SM-DP +。
SMDP9SM-DP +与LPA之间的通信会话应在执行预期操作后由SM-DP +终止。
SMDP10 SM-DP +与profile下载和安装中涉及的eUICC之间的端对端通信应受到完整性，真实性和机密性的保护。
SMDP11存储在SM-DP +中的profile包应始终通过加密进行保护。
SMDP12在SM-DP +上，profile创建和存储基础架构内的备份以及使用的数据应使用安全删除程序（逻辑和物理）丢弃。
SMDP13 SM-DP + / eUICC通信应包含完美前向保密（PFS）。
SMDP14用于Bound Profile Package包的传输应在SM-DP +和eUICC之间实现防重放机制。
SMDP15与SM-DP +的连接应当中止，并且在未能验证连接方的真实性时，由SM-DP +触发明确的错误消息。 （不应向连接方发送消息）
SMDP16经过可配置次数的失败尝试将Bound Profile Package包下载到LPA后，传输加密过程应被更新。如果后续尝试下载Bound Profile Package包失败的次数超过可配置次数，配置事务将被终止，并且应通知运营商。
SMDP17 SM-DP +应使用互联网协议（如DNSSEC，DNSCurve等）的安全版本。
SMDP18 SM-DP +应按照SIMalliance [5]定义的eUICCprofile包互操作格式规范来准备profile包。
SMDP19 SM-DP +应能够按需创建Bound Profile Package包。
SMDP20 SM-DP +可以批量创建profile包。
SMDP21 SM-DP +应向操作员发送成功完成的下载和安装profile的确认。
SMDP22在成功安装profile后，应该有一种机制来消除任何SM-DP +和ISD-P之间的关系。这种机制应由运营商订购或由运营商自行执行。如果使用这种删除机制，则不会有负责管理已安装profile的ISD-P的离卡实体。
SMDP23 SM-DP +应由其SMDPid全局唯一标识。
SMDP24 SM-DP +证书应包含SMDPid。
SMDP25 SM-DP +应能够向运营商发送通知，通知他们特定的Bound Profile Package包下载即将开始。
SMDP26在下载eUICC Bound Profile Package包之前/之前，SM-DP +应能够向运营商发送eUICC资格检查信息报告和其他相关信息（例如激活码，ICCID等）。
SMDP27 SM-DP +应能够向SM-DS执行事件注册。
SMDP28 SM-DP +应能够从备选SM-DS请求不将事件注册传播到根SM-DS。
SMDP29当从eUICC收到相关的删除通知时，SM-DP +应能够向拥有profile的运营商发送profile删除通知。
SMDP30 SM-DP +应支持由profile所有者触发的profile包的以下状态：?
SMDP31 SM-DP +应能够在profile下载过程中选择椭圆曲线参数。
SMDP32（FFS）SM-DP +可以对SM-DS（根或备用）进行事件记录查询，以审计其拥有的事件注册。
SMDP33（FFS）SM-DP +应能够通过ES12接口查询由EID或Event-ID标识的根SM-DS或替代SM-DS上的事件记录。
SMDP34（FFS）对SM-DP +事件记录查询的响应只应在根SM-DS或备选SM-DS验证事件记录所有权的情况下进行。
SMDP35（FFS）SM-DP +事件记录查询的所有权验证应仅针对所持有的事件记录的组件使用请求者地址或提交的事件ID。
SMDP36 SM-DP +应支持GSMA SGP.22 V2.0 [24]中定义的所有椭圆曲线参数集。
SMDP37如果Profile包尚未发布供下载，则应通过特定的错误代码通知LPA。
DF1如果在呈现给LUI的AC中存在SM-DP +地址，则eUICC中的默认SM-DP +地址应该被忽略。
DF2 LPU可访问eUICC中的默认SM-DP +地址，以建立与此SM-DP +的连接。
DF3 eUICC中的默认SM-DP +地址可以留空。
DF4如果eUICC中的默认SM-DP +地址为空，则需要在AC中使用SM-DS发现过程或SM-DP +地址来建立目标SM-DP +。
DF5（FFS）不支持重定向到查询默认的SM-DP +地址。
该角色既存在于设备中，也与eUICC提供的LPA服务一起存在，并在eUICC中与eUICC提供的LPA功能一起存在。 它提供三种不同的功能，如下所述的本地用户界面（LUI），本地Profile下载（LPD）和本地发现服务（LDS）。 如果没有设备交互，eUICC本身不能提供任何这些功能，交互的具体级别将取决于设备内的功能。 在不同的设备和设备类型中实现这种可变性的方式有待进一步研究。
当设备和eUICC中有LPA时，要使用的LPA由设备设置（DEV7）指定：
?- LPA in the Device
?- LPA in the eUICC
LPA功能是由eUICC提供.
LPA功能是由设备提供.
LPA1 LPA应负责指示eUICC根据最终用户请求执行本地Profile管理功能。
LPA2在eUICC之外的任何LPA单元和eUICC之间应实施一种机制，以确保通信不会在LPA所在的任何地方受到威胁。
LPA3应在LUI和设备上相关的显示或输入应用程序之间实施安全机制。
LPA4对LUI应用程序的访问应根据当前最佳实践进行保护。这将由Device OS强制执行。
LPA5所有本地Profile管理操作都需要用户意图。
LPA6 LUI访问需要用户意图。
LPA7最终用户应能够轻松访问已安装的Profile列表。
LPA8 LPA应保护个人资料元数据免受未经授权的访问。
LPA9本地Profile管理操作’enable’应被支持。此操作应允许最终用户选择Profile。
LPA10本地Profile管理操作“禁用”应受支持。
LPA11本地Profile管理操作’删除’应该被支持。此操作应允许最终用户从eUICC中删除已禁用的Profile。最终用户应确认删除Profile后果的消息。认证确认应执行。
LPA12应支持本地Profile管理操作“查询”。此操作应允许最终用户通过其Profile元数据查看eUICC上安装的操作Profile列表和相关的相关信息。
LPA13应支持本地Profile管理操作’编辑默认的SM-DP +地址’。该操作应允许最终用户编辑默认的SMDP +地址。简单确认应执行。
LPA14应支持本地Profile管理操作’eUICC Memory Reset’。该操作应按照第4.5.2节所述执行eUICC存储器复位。最终用户应确认’eUICC存储器复位’的结果信息。认证确认应执行。
LPA15应支持本地Profile管理操作’eUICC测试存储器复位’。该操作应执行第4.5.3节中所述的eUICC测试存储器复位。简单的确认将被强制执行。
LPA16应支持本地Profile管理操作的“设置/编辑昵称”。此操作应允许最终用户添加或修改所选Profile的昵称。该操作不应修改服务提供商名称。可以提供在LUI上区分Profile的其他方法。
LPA17应支持本地Profile管理操作“添加Profile”。此操作应允许LPA下载并安装新的Profile到eUICC。 LPA至少应支持三种机制，具体取决于具有技术能力的设备类型：?从默认SM-DP +
?通过SM-DS服务发现下载Profile?使用激活代码认证确认进行Profile下载，除初始设备设置（LPA62）外应强制执行。
LPA18 LPA不能由除LPA提供商提供的应用程序之外的任何应用程序访问，仅用于启用LPA的服务和功能。
LPA19 LPA提供商应执行安全且不可被认可的认证确认。
LPA20 LPA提供商应在设备上执行安全且不可拦截的简单确认。
LPA21对LUI的访问应受到认证确认的保护。
LPA22 LPA21中的机制应由最终用户选择/取消选择。
LPA23默认情况下会提示LPA21中的机制启用，但可以由最终用户跳过。
LPA24 LPA及其主机（即设备，如果LPA位于设备中; eUICC，如果LPA位于eUICC中）应实施一种机制，通过经过身份验证的确认来保护LPA访问。这个认证确认可以通过使用设备中实现的机制来实现，例如电话锁码，指纹输入等。
LPA25最终用户应该能够定义专用的个性化用户凭证来访问LPA。
LPA26如果最终用户选择保护对LUI（LPA23）的访问权限，则操作级别的后续认证确认可以用简单确认来替换。
LPA27强制执行时，任何确认请求都应允许最终用户取消本地Profile管理操作。
LPA28可以暴露配套设备的LUI，允许来自主设备上的最终用户界面的输入。
LPA29当配套设备LUI允许来自主设备的输入时，配套设备LUI应能够限制可应用的操作。例如：?不提供eUICC存储器复位; ?仅公开’启用’和’禁用’操作。 ?Profile启用仅在配套设备上未启用Profile的情况下公开。
LPA30伴随设备的LUI应能够在建立任何接近安全链路（用于从另一设备向LUI的输入）之前向伴随设备请求最终用户发起的动作。
LPA31由终端用户发起并提供机密性和完整性的点对点接近安全链接应在配套设备和主设备之间为从主设备执行的任何输入建立。
LPA32当从主设备操作配套设备LUI时，任何必需的用户意图或确认请求只能由配套设备上的LPA执行。物理最终用户输入可以在主设备或伴随设备中完成。
LPA33伴随设备的设备制造商应实施一项安全措施，以确保任何访问LUI的应用程序的完整性和资格。
LPA34用于用户意图保护的最终用户数据（例如PIN码，指纹）应存储在安全的环境中。
LPA35 LPA应能够利用任何设备上和现有的互联网连接，例如Wi-Fi或Wi-Fi直连，以接触SM-DP +。通过这种连接，可以建立ES8 +和ES9 +。
LPA36 LPA应能够通过其他连接机制（例如有线共享，本地共享Wi-Fi连接或蓝牙）利用其他连接机制提供的任何互联网连接，以便接触SM-DP +。通过这种连接，可以建立ES8 +和ES9 +。
LPA37 LPA应能够确定是否可以通过任何方式连接到SM-DP +。
LPA38 LPA应能通知最终用户没有连接到互联网，或者没有连接到SM-DP +，以便允许最终用户启用或排除所需的连接。
LPA39如果分配了权限，LPA只能访问eUICC。
LPA40设备上只能有一个LPA。
LPA41 LPA只应执行本规范中描述的操作。
LPA42 LPA程序不得由任何外部（非LPA）程序调用。
LPA43安装多个操作Profile时，本地Profile管理操作“启用”应在启动所选Profile的“启用”操作之前首先启动任何已启用Profile的“禁用”操作。
LPA44 LPA应能读取Profile策略规则。
LPA45当安装了Profile策略规则的Profile时，在请求最终用户同意的情况下，LPA应向最终用户显示Profile策略规则的结果。此信息应以描述性和非歧视性方式制定（例如，对于“非删除”Profile策略规则：“您将要安装的Profile不能根据您与服务提供商商定的条款删除。 YES / NO）。认证确认应以LPA17中列出的例外执行。
LPA46在下载新Profile之前，LPA应检查已启用Profile（如果有）是否已启用POL RULE1的条件。如果是这种情况，应该显示一条专用信息，标识最终用户的后果。可能显示的信息示例如下：?由于当前启用的Profile无法禁用，因此无法启用新的Profile。 ?已启用Profile的Profile名称。 ?有关更多信息，最终用户应联系此Profile的Profile所有者。通过显示此消息，最终用户应能决定是继续下载还是取消操作。该对话可以与常规最终用户意图结合以确认简档下载。
LPA47主设备的最终用户界面和伴随设备的LUI之间的通信应受到保护（机密性，完整性和认证）。
LPA48如果最终用户退出LPA菜单或在一段时间内未执行操作，以避免滥用为连续的本地Profile管理操作绕过已认证的确认
LPA49确认请求，则应有机制限制LPA26的有效性只要向最终用户明确解释不同的行为，就可以一步完成。例如，在安装新的Profile时，LPA可以建议’添加Profile’和’启用’为一个单一的步骤，只有一个确认（例如“你想在你的设备上安装Profile’ProfileName’并启用它？是/否/仅安装“）
LPA50当在一个单一步骤（LPA49）中实现连续操作时，应用最高级别的确认 - 即在两个操作分别具有已验证和简单确认请求的情况下，单步骤使用已认证的确认请求。
LPA51本地Profile管理操作’启用’（LPA9），’禁用’（LPA10），’删除’（LPA11）应能够触发通知到被管理的相应Profile的通知接收器，以指示该操作已被执行。这些通知以尽力而为的方式发送，并且不会影响操作。
LPA52 LPA应通过LUI提供从最终用户到eUICC的可信链路。
LPA53最终用户应能够配置LPA，使得可以禁用从SM-DS中检索自动事件记录。
LPA54 LPA应能读取eUICC中配置的任何SM-DS和SM-DP +地址。
LPA55应该可以检查LPA完整性。如果完整性检查失败，eUICC和LPA之间的通信将不会发生。
LPA56 LPA完整性应确保在目标平台上使用最佳实践方法。见附录G.
LPA57 LPA中的轮询机制应有两种类型的触发器：那些基于事件的，以及最终用户发起的。应提供
LPA58用于轮询的基于事件的触发器。至少应包括设备加电;此外可以提供其他触发器。基于事件的触发器可以由最终用户禁用。
LPA59最终用户启动的轮询触发器应包括：?’添加Profile’操作以触发默认SM-DP +（如果已配置）和根SM-DS。 ?另外，可以提供其他手动触发器。
LPA61应该实现LPA轮询机制的错误/重试处理。建议最终用户根据需要重试或自动重试。相应的确认需要在重试案例中执行。
LPA62在初始设备设置期间，如果尚未安装操作Profile，则应按以下顺序执行：1.如果配置了默认的SM-DP +地址，则LPA应联系SM-DP +以检查是否有正在等待的Profile。 2.如果（1）中没有任何Profile正在等待，则应联系根SM-DS地址以检查等待Profile的事件。
简单确认应针对上述程序执行。
LPA63如果没有默认的SM-DP +地址，最终用户应始终能够通过LPA手动请求检索任何等待的事件记录。注：这可以通过与现有操作的组合来实现 - 例如，按“添加Profile”将联系服务器以检索事件。
LPA64在启动下载Profile并在下载Profile之前向最终用户显示时，操作员/服务提供商名称应在从SM-DP +到LPA的信令信息中给出。简单的确认将被强制执行。
LPA65 LPA应当将EID作为文本和定义的可扫描格式（例如QR码）呈现给最终用户。
LPA66（FFS）对于在组合操作中要禁用并删除的Profile提供唯一可用连接的情况，应在Profile禁用之前发送预删除通知。这种尝试的失败不应该阻止删除或连接拆解。
LPA67如果SM-DP +停止Profile下载过程，则LPA应能通知最终用户。
LPA68本地Profile管理操作的自动化应该可以访问，除非在LPA43中描述的情况。
LDS1
LDS应能读出EUICC中描述的地址。 并仅使用（se）地址连接到SM-DS
SM-DS的作用是提供允许SM-DP +在任何设备内通知SM-DP +希望进行通信的LDS用它。 SMDS与LDS通信的目的应该是通知LDS一个未决事件。所有用例的操作原理都是一样的。 SM-DP +会将目标设备的事件注册消息发送给SM-DS。在简单部署中，只有根SM-DS在eUICC上配置。根SM-DS地址是唯一的，并填写在eUICC中。目标设备中的LDS使用相同的逻辑位置轮询Root SMDS。当根SM-DS具有目标设备的事件ID时，它将使用SM-DP +地址进行响应，或者如果没有事件ID，响应将为空响应。在具有级联SM-DS的部署中，SM-DP +将向另一个SM-DS发送事件注册，该SM-DS可能未在eUICC上配置为根SM-DS。此替代SM-DS将将事件注册级联到根SM-DS。目标设备中的LDS轮询根SM-DS并将接收替代SM-DS地址。然后它将请求替代SM-DS中的事件，该SM-DS将用SM-DP +地址进行响应。
eUICC上的两个SM-DS地址配置可能存在：
?- 根SM-DS地址
?- 可选的SM-DS地址
图11显示了这两种配置。 根SM-DS在设备制造时配置并且是不变的。
在定义技术实现时应考虑以下声明：?
4.11.4 SM-DS功能
SM-DS有以下三个功能:
SMDS1 SM-DS应使LDS能够发现由SM-DP +（s）或备选SM-DS（s）注册的自己的事件记录。
SMDS2 SM-DS将无法识别事件的性质。注：事件的性质可能是’可供下载的Profile包’。
SMDS3所有有效的发现请求和事件注册均应以无歧视的方式进行处理。
SMDS4 SM-DS只接受来自?具有有效证书的任何经授权和认证的SM-DP +（s）的事件注册。 ?任何具有有效证书的授权和认证SM-DS。
SMDS5 SM-DS只接受由相应的eUICC通过LDS认证的发现请求。
SMDS6 SM-DS和SM-DP +以及连接的SM-DS应相互认证。
SMDS7 SM-DS不可见任何可能用于危害最终用户隐私的数据。
SMDS8 SM-DS应支持每个eUICC的多个并发事件注册，并应按照与SM-DS（先入先出）相同的顺序向LDS提供所有当前有效的事件记录。
SMDS9 SM-DS只能存储指定给特定EID的事件记录。
SMDS10用户特定数据和Profile相关内容不应存储在SM-DS中。
SMDS11 SM-DS不允许收集任何信息，例如运营商，EID，设备制造商，设备等。
SMDS12 SM-DS应仅返回LDS，与所服务的eUICC相关的事件记录。
SMDS13 SM-DS不会与Profile包有任何联系，例如不得存储或处理任何Profile包。
SMDS14无论查询设备的状态如何（即时间和地理位置一致），SM-DS都应提供相同的数据。
SMDS15 SM-DS不应该严重影响端到端的供应时间。
SMDS16 SM-DS将提供针对DoS攻击的防御。
SMDS17所有与SM-DS实体之间以及之间的通信都应加密。
SMDS18 SM-DP +应能够删除在SM-DS上注册的任何自己的事件记录。
SMDS19另一种SM-DS应能够删除在根SM-DS上注册的任何自己的事件记录（响应SMDS18中定义的SM-DP +删除操作）。
SMDS20如果SM-DP +有请求，SM-DS的替代方案应将事件记录传播到根SM-DS。
SMDS21如果在SM-DS上为一个eUICC注册了多个事件记录，则这些应全部作为单个响应发送。
SMDS22 SM-DP +应能够通过根SM-DS或通过SM-DP +选择的备选方法向LDS发送事件记录。如果选择了替代方案，则LDS的事件记录应来自此替代SM-DS。
SMDS23应该有一个独特的根SM-DS。注意：此要求不禁止此根SM-DS的潜在负载平衡。
SMDS24根SM-DS应由GSMA管理。
SMDS25（FFS）替代SM-DS可以对根SM-DS进行事件记录查询，以审计其拥有的事件注册。
SMDS26（FFS）对事件记录查询的SM-DS响应应仅确认事件记录的存在，并且不应包含其他信息。
SMDS27（FFS）备选SM-DS应能够通过ES15接口查询EID或Event-ID所标识的根SM-DS上事件记录的存在。
SMDS28（FFS）对SM-DS事件记录查询的响应应仅在响应者验证事件记录所有权时发生。
SMDS29（FFS）SM-DS事件记录查询的所有权验证应仅针对所持有的事件记录的组件使用请求者地址或提交的事件ID。
SMDS30（FFS）SM-DS（根或备选方案）可以直接或通过另一个SM-DS通知SM-DP +，通过发布事件记录来解答来自授权LDS的发现请求。
SMDS31（FFS）SM-DS只应通知事件记录拥有的SM-DP +或SMDS它已回复发现请求。
下图显示了使用根SM-DS和替代SM-DS（级联模式）进行部署的过程。
起始条件：
a. SM-DP +具有等待由EID识别的目标eUICC的动作。
程序：
1.SM-DP +与Profile所有者选择的替代SM-DS建立安全连接。
2.SM-DP +通知备选SM-DS有关未决动作。
3.至4.替代SM-DS注册并确认事件注册。
5.替代SM-DS建立到根SM-DS的安全连接。
6.可选SM-DS通知根SM-DS，对于给定的EID，事件记录正在等候替代SM-DS。
7.根SM-DS确认收到的信息。
4.11.7发现请求程序
下图显示了使用替代SM-DS和根SM-DS（级联模式）进行部署的过程。
程序：
1.至3.为了生成发现请求，LDS请求eUICC生成包含（至少）eUICC证书并由eUICC签名的eUICC授权。
4.到5.LDS建立到根SM-DS的安全通信。
6.根SM-DS通过检查eUICC授权来验证eUICC的真实性。
7.如果eUICC是可信的并且事件记录正在等待，它会返回：
一个。 SM-DP +的地址，正在等待一个动作。
要么
湾以下其他操作：
I。替代SM-DS的地址，可以检索事件记录。
II。 LDS建立到替代SM-DS的安全连接。
III。替代SM-DS通过检查eUICC授权来验证eUICC的真实性。
IV。如果eUICC是真实的并且已收到事件记录，则它将传回SM-DP +的地址，在该处等待一个动作。
运营商使用ES2 +接口为特定eUICC以及其他管理功能订购Profile。
这个接口超出了本规范的范围。
ESeu是最终用户和LUI之间的接口。
在主/伴随设备场景中，所使用的LUI只能位于伴侣设备或其eUICC内。
ESeu接口用于支持以下要求：
ESeu1本地Profile管理操作只能通过ESeu接口执行。
ESeu2每个本地Profile管理操作应由最终用户明确发起，并由用户意图进行验证。
ESeu3 ESeu接口应支持触发和确认Profile下载和安装操作。
运营商使用ES6接口通过OTA服务管理运营商服务。
ES9 +接口用于为SM-DP +和LPD之间的绑定Profile包提供安全传输。
ES8 +接口在SM-DP +和eUICC之间提供安全的端到端通道，用于在下载和安装期间管理ISD-P和关联的Profile。它是一个提供完美向前保密的界面。
ES12接口允许任何SM-DP +发布或删除SMDS上的事件注册。
ES11接口允许LDS检索相应eUICC的事件记录。
这个接口超出了本规范的范围。
设备中的LPA使用ES10a接口从root用户SM-DS的eUICC以及可选的默认SM-DP +获取配置的地址。
设备中的LPD使用ES10b接口，LPA服务将绑定Profile包传输到eUICC。
ES10c接口用于设备中的LUI与最终用户的本地Profile管理的LPA服务之间。
在部署级联SM-DS的情况下，ES15接口用于连接SM-DS。
该连接将通过以下方式提供：
?可用的互联网连接或在LPA所在的同一设备上提供的互联网连接
要么?通过本地中继连接从另一台设备共享的互联网连接
INT1 eUICC的所有接口都应指示eSVN。
INT2所有接口的行为应支持指定的eSVN。
INT3在从eUICC到SMDP +的支持eSVN的指示期间，应使用eUICC版本或该过程失败。 见下表。
INT4涉及远程SIM配置的所有通信实体应相互认证。 Device和eUICC在这方面被视为一个实体。
Profile策略管理功能提供了一些机制，通过这些机制，服务提供商可以加强向订户提供服务的条件或政策（运营和业务）。在某些情况下，这可能还包括强制执行订户设定的政策。Profile策略管理也可以与其他已有的策略执行技术一起使用，这些技术也需要订户同意。Profile策略管理功能的实现基于两个关键要素。第一个元素是eUICC中包含的Profile Policy Enabler。第二个元素是一组定义的Profile策略规则，这些规则是特定策略的实际执行所必需的。
POL1Profile策略规则只能在Profile中配置。
POL2每个Profile可能有与其自身相关的Profile策略规则。
POL3Profile策略规则只适用于包含它的Profile。
POL4Profile策略实施应在各个实施中保持一致。
POL5Profile策略执行应能解决任何Profile策略规则冲突.
POL6更新Profile的策略规则应限于Profile所有者。
POL7用于更新Profile策略规则的机制应为原子。
POL8Profile策略规则集将可扩展用于将来的版本。
POL9应该有一个Profile策略规则方案，以允许策略规则的可扩展性，例如如’操作命令，应用范围，资格描述
POL10Profile策略规则应当在尝试Profile状态更改时执行。
POL11使用Profile策略下载并安装Profile规则’不要禁用’只有当前没有安装其他操作Profile时才可以。
POL12 LPA和eUICC应阻止下载和安装包含与已安装Profile的Profile策略规则冲突的Profile策略规则的Profile。注意：技术规范应详尽地描述可能发生的每个冲突。 POL13如果Profile已启用，运营商应能够使用ES6接口停用其Profile的Profile策略规则。注意：在ES6接口上激活Profile策略规则是未来版本的潜在功能。
POL14在Profile与Profile策略规则一起安装之前，最终用户应该能够得到有关Profile策略规则的通知，并且如果得到通知，安装将以最终用户身份验证确认为条件。如果RAT直接允许安装，则可能不需要此提示。
POL15最终用户同意安装Profile策略规则和Profile下载的请求可以合并为单个提示，因此需要最终用户的单一确认。
POL16Profile策略规则应由eUICC中的Profile策略启动器强制执行。
POL17Profile策略启动器应仅支持本规范中定义的Profile策略规则。
POL18Profile策略启动器应能够支持本规范中定义的所有Profile策略规则。
POL19在所有情况下POLAR POL RULE3都是可执行的，但启用Profile除外。注意：POL RULE3被定义为用于尚未完全定义的特定用例，并且不适用于此版本的规范。
POL20允许安装具有Profile策略规则的Profile应符合当地法规要求。
POL RULE1应支持Profile策略规则’禁止禁止Profile’。
POL RULE2应支持Profile策略规则“不允许删除此Profile”。
POL RULE3Profile策略规则“应该在成功禁用时删除此Profile”应该被支持。注意：POL RULE3被定义为用于尚未完全定义的特定用例，并且不适用于此版本的规范。
POLPPE1规则授权表（RAT）应存储在eUICC的Profile策略启动器中。
POLPPE2Profile策略启用程序应仅在Profile安装时强制安装RAT的内容（如果有）。
POLPPE3 RAT应允许多个Profile所有者在Profile中启用Profile策略规则。
POLPPE4 RAT应能够支持特定的配置，允许任何配置文件所有者使用一组或全部配置文件策略规则。
POLPPE5 RAT只能在发行前或在初始设备设置期间安装，前提是没有安装操作配置文件。
POLPPE6 RAT不受eUICC Memory Reset功能的影响。
POLPPE7为了支持可识别的监管要求，RAT应该能够支持特定的配置，该配置可以禁止任何配置文件所有者设置特定的配置文件策略规则。
POLPPE8如果设置了POLPPE7，则此信息应为SM-DP +与eUICC共享的资格检查信息的一部分。
POLPPE9如果RAT允许安装配置文件的配置文件策略规则，安装应按照POL14中的规定进行。
POLPPE10在安装配置文件之前，RAT应能够支持设置以显示配置文件策略规则对最终用户的影响。
POLPPE11 OEM或EUM应负责提供RAT。 POLPPE12固定RAT应在eUICC中实施。注意：允许的RAT配置在附件H中有详细说明。
CERTEU1 EUM应通过GSMA SAS认证[13]。
CERTEU2 EUM应被要求声明eUICC产品符合GSMA SGP.22 V2.0 [24]。
CERTEU3 eUICC应根据GSMA（TBD）定义的保护配置文件进行认证。
CERTEU4 eUICC保护配置文件至少应包含以下要素：平台服务管理器，ISD-R，配置文件存储和配置文件隔离。
CERTEU5 eUICC保护配置文件应与SGP.05 [21]中定义的eUICC保护配置文件相同。
CERTEU6 eUICC保护配置文件的评估保证级别应至少（至少）EAL4增加AVA_VAN.5和ALC_DVS.2（EAL 4+）或同等级别。注：FASG需要对保证水平进行研究。
CERTEU7用于身份验证的eUICC公钥证书应包含EID。
CERTEU8 eUICC公钥证书应包含产品的技术参考，例如Common Criteria认证报告编号。
CERTEU9 EUM公钥证书应由GSMA CI签署。
CERTEU10 eUICC证书应由EUM使用其EUM证书进行签名。
CERTEU11 eUICC私钥不应该是可修改的。
CERTEU12如果eUICC私钥是可修改的，则应使用GlobalPlatform规范中定义的机制，使用密钥长度为128位的AES算法对应的最低安全级别。
CERTEU13 eUICC应该支持一个安全的机制来更新其EUM证书。
CERTEU14 eUICC应该支持更新其CI公钥的安全机制。
CERTEU15 eUICC应该支持更新其eUICC证书的安全机制。
CERTDEV1根据GSMA，对于本地配置文件管理实施的所有部分应该有合规流程。
CERTDP1 SM-DP +提供商应被要求声明符合GSMA SGP.22 V2.0 [24]的产品（SM-DP +）。
CERTDP2 SM-DP +应根据GSMA SAS [22]进行认证。
CERTDP3 SM-DP +元件应使用硬件安全模块（HSM）进行密码相关操作（密钥存储，派生，加密操作）。注意：这将由SAS文档“根据FIPS 140-2 3级或更高级别认证的HSM”涵盖
CERTDP4 SM-DP +应实现权限隔离（日志，审计，操作和管理）。
CERTDP5 SM-DP +应实施操作系统强化机制。
CERTDP6 SM-DP +应实现控制，用户和管理平面的分离。
CERTDP7 SM-DP +应使用多重身份验证和管理操作。用于存储配置文件的
CERTDP8 SM-DP +硬盘和备份介质将被加密。
CERTDP9用于与eUICC进行双向认证的SM-DP +证书私钥应根据CERTDP3进行保护并存储在HSM中。
CERTDP10 SM-DP +应实施速率限制机制以减轻DoS攻击。
CERTDP11 SM-DP +应记录所有证书认证失败。
CERTDP12 SM-DP +公钥证书应由GSMA CI签名。
CERTDS1 SM-DS提供商应被要求声明产品符合GSMA SGP.22 [24]。
CERTDS2 SM-DS应根据相关的GSMA SAS进行认证。
CERTDS3 SM-DS应实现特权的隔离（日志，审计，操作和管理）。
CERTDS4 SM-DS应实施操作系统强化机制。
CERTDS5 SM-DS应实施控制，用户和管理平面的分离。
CERTDS6 SM-DS应使用多因素身份验证和管理操作。
CERTDS7 SM-DS硬盘驱动器和备份介质应加密。
CERTDS8 SM-DS证书应由GSMA CI签署。
CERTLPA1对于与远程SIM供应实体通信的所有LPA元素，应该有一个认证过程。
CERTLPA2认证过程应确保本地配置文件管理操作仅由授权的LPA元素发送。
CERTLPA3认证过程应确保存在阻止受损LPA的机制。
CERTLPA4 LPD应在TLS会话期间对SM-DP +进行身份验证。
CERTLPA5 LDS应在TLS会话期间对SM-DS进行身份验证。
CERTLPA6 LPA应仅接受由GSMA CI签署的证书以进行服务器身份验证。
CERTPK1 eUICC应验证SM-DP +的公钥证书。
CERTPK2 LPD应验证SM-DP +的公钥证书。
CERTPK3 LDS应验证SM-DS的公钥证书。
CERTPK4使用无效公钥证书的SM-DS的LDS身份验证将失败（请参见CERTPK11），并且正在进行的通信应停止。
CERTPK5使用无效公钥证书的SM-DP +的LPD认证失败（参见CERTPK11CERTPK1），并且正在进行的通信应停止。
CERTPK6使用无效公钥证书的eUICC的SM-DP +认证应失败（参见CERTPK11），并且正在进行的通信应停止。
CERTPK7使用无效公钥证书的SM-DP +的eUICC认证应失败（参见CERTPK11），并且正在进行的通信应停止。
CERTPK8 GSMA CI应当撤销任何实体（SMDP +，SM-DS，EUM）的公钥证书（如果私钥被盗用）。
CERTPK9 eUICC应能够支持一组GSMA CI。
CERTPK10在下列情况下，公钥证书应被视为有效：?它具有有效签名?由GSMA CI或可信任的证书链直至GSMA CI进行签名。证书路径验证应遵循RFC 5280中定义的过程。?尚未撤销，且信任链中没有证书已被撤销?尚未到期如果这些适用的验证失败，公钥证书应被视为无效。
CERTPK11 eUICC，LPA，SM-DS和SM-DP +应知晓撤销的公钥证书。
LID1如果激活码尚未提供，则LPA应使用eUICC上填充的任何Root SM-DS或默认SM-DP +地址.
LID2在LID1的上下文中，如果同时填充了根SM-DS和默认SM-DP +地址，则LPA应先联系SM-DP +，然后再联系SM-DS以启动远程SIM配置事务.
5.1.2 LPA启动的下载过程
以下过程描述了属于由LPA启动的profile包下载和安装过程的一部分的事件.
GSMA-SGP-21-第五章学习
开始条件：
a.订户已完成所选运营商/服务提供商优惠的订购流程.
b.与此订阅相关的profile订购过程已完成（即，分配的受保护profile包存储在SM-DP +上）.
程序：
1.LPA启动profile包下载并识别profile存储并可供下载（通过例如URL，QR码，手动输入等）以及提供的其他信息（例如，令牌，SMDPId，确认码）.
2.LPA通过与SM-DP +建立TLS连接来认证SM-DP +，并验证SMDID是否已提供此类信息.3.至4.
LPA得到eUICC挑战
5.至6. LPA将eUICC质询和任何其他相关信息发送至SM-DP +.
7.至9. SM-DP +签署eUICC挑战，并生成一个DP_Challenge发送回eUICC.
10.LPA将SM-DP +和AC令牌收到的资料发送给eUICC; eUICC检查SMDPid并验证SM-DP +.
11.eUICC将包括DP_Challenge，AC令牌，EID及其证书在内的一组签名信息发送回LPA.
12.最终用户确认profile的下载，可选择显示运营商的profile名称.
13.LPA将步骤11中收到的一组信息从eUICC发送到SM-DP +.
14.SM-DP +验证签名; eUICC已通过认证.
15.至16.可选：eUICC资格检查和profile绑定功能由SM-DP +执行.
17.至22.可选
17.将向运营商通知即将下载的profile包.
18.如果操作员已收到通知，可以通过向SM-DP +指示错误代码来请求停止下载过程.
19.如果操作员向SM-DP +发送错误代码，则SM-DP +将停止下载过程并向LPA指示错误代码.
结束条件：
a.profile在禁用状态下安装在eUICC中
AC1如果使用，激活码应触发从特定SM-DP +下载绑定profile包.
AC2激活码应包含以下参数：?SM-DP +地址?激活码令牌（包括可选确认码必需标志）?SMDPid（可选）
AC3激活码令牌应能够包含一个参数，该参数指示确认码是否需要.如果需要此确认码，则LPA应要求最终用户输入确认码.SM-DP +在交付绑定profile包之前应验证确认码.注意：如何创建确认码并将其提供给最终用户超出了本规范的范围.
AC4在交付绑定profile包之前，激活代码应由SM-DP +进行验证.
AC5最终用户在LPA中的激活码输入应至少支持手动输入和QR码扫描.
AC6所有激活码程序应作为LPA的一部分原生实施.
AC7激活码程序应有条件地在初始设备设置期间自动提供给最终用户.如果已经设置了profile，则此自动设置不适用.不需要验证确认.注意：例如，这可能不适用于开放市场cellularenabled笔记本电脑.
AC8按照激活码过程，应使用profile包下载程序.
AC9激活码程序应保护用户意图的生态系统安全性，隐私和验证.
AC10激活码程序应仅用于将profile包下载到目标eUICC的唯一目的.激活码程序应防止将IMEI和EID信息发送给未经认证的SM-DP +.
AC11激活码应唯一标识运营商/服务提供商.
AC12对特定SM-DP +进行认证后，对SM-DP +的激活码请求应由LPA用EID进行扩展.
5.2.2使用激活码下载profile过程
激活码过程定义了一项通用功能，允许用户或最终用户代表用户通过请求从设备本身下载操作profile来“激活”设备.
开始条件：
a.认购人已订立认购协议.
b.激活码已经提供给最终用户和可选的确认码（旁道）.
过程：
1.最终用户通过LUI将激活码输入到LPA.
2.LPA解析激活码参数以识别SM-DP +地址，激活码令牌，LPA模式和可选的SMDPid.另外，LPA可以在激活令牌中解析需要确认码的信息.
3.如果激活码令牌中的确认码参数设置为“需要确认码”，则会提示最终用户输入由发卡运营商/服务提供商提供给他们的确认码.
4.激活码下载程序由LPA启动.LPA向eUICC请求nonceeUICC.
5.eUICC创建与支持的eUICC规范版本号（eSVN）关联的nonceeUICC.
结束条件：
a.绑定的profile包已经下载并安装在处于禁用状态的eUICC上.
b.LPA可能会提供最终用户启用的profile.
此过程执行目标profile的启用.该请求由最终用户给予LPA.
开始条件：
a.目标profile在eUICC上被禁用.
b.目标profile已由最终用户选择.
C. LPA向eUICC认证为合法执行本地profile管理.
过程：
1.最终用户在LPA上发出profile启用请求.
2.用户意图已验证.
3.LPA将目标profile的profile启用操作发送给eUICC上的ISD-R.
4.ISD-R检查在目标profile上应用的profile策略规则是否允许启用profile
5.如果与profile策略规则存在冲突，则ISD-R中止该过程并通过LPA通知最终用户.
6.目标profile已启用.
结束条件：
a.目标profile已启用.
禁用profile可以通过以下步骤来实现.该请求由LPA上的最终用户提供.
开始条件：
a.目标profile在eUICC上启用.
b.目标profile已由最终用户选择.
C. LPA向eUICC认证为合法执行本地profile管理.
过程：
1.最终用户在LPA上发出profile禁用请求.
2.用户意图已验证.
3.LPA向eUICC上的ISD-R发送profile禁用操作.
4.ISD-R检查在目标profile上应用的profile策略规则是否允许profile被禁用.
5.如果与profile策略规则有冲突，ISD-R将中止该过程并通过LPA通知最终用户.
通过以下步骤可以实现profile删除.该请求由LPA上的最终用户提供.
开始条件：
a.目标profile被禁用.
b.目标profile已由最终用户选择
c. LPA向eUICC认证为合法执行本地profile管理.
过程：
1.最终用户在LPA上发出profile删除请求.
2.用户意图已验证.
3.LPA将目标profile的profile删除操作发送给eUICC上的ISD-R.该请求包括目标profile的ISD-P AID.
4.ISD-R检查是否应用profile策略规则允许删除profile.
5.如果与profile策略规则有冲突，ISD-R将中止该过程并通过LPA通知最终用户.
6.ISD-R擦除目标profile和相关的ISD-P.
7.ISD-R通知LPA删除profile.
8.目标profile的profile元数据被删除.
9.最终用户通过LPA通知.
结束条件：
a.目标profile被删除.
添加/更新昵称将允许订户或最终用户将昵称归属到profile以便于使用.请注意，添加或更改昵称不会影响该profile的任何其他数据或其他profile元数据.
开始条件：
a.用户意图已被验证.
b.目标profile已由最终用户选择.
C. LPA向eUICC认证为合法执行本地profile管理.
过程：
1.最终用户请求更新LPA上的昵称.
2.LPA使用eUICC中最终用户选择的昵称更新目标profile的profile元数据.
结束条件：
a.profile目标profile的元数据已更新为最终用户选择的昵称.
此过程将允许最终用户查询最终用户可访问的profile的profile元数据.结果应在查询时在eUICC上显示所选profile的全部（或部分）profile元数据.作为此过程的结果，不会对eUICC上的任何数据进行更改.
开始条件：
a. LPA被认证为eUICC合法执行本地profile管理.
b.最终用户可访问的profile列表由LPA（LUI）显示.
过程：
1.最终用户选择要查询的profile.
2.LPA收到来自最终用户的查询请求.
3.LPA向eUICC请求profile元数据.
4.LPA在LUI上向最终用户显示profile元数据.
结束条件：
a.没有更改profile元数据.
此过程执行eUICC的eUICC存储器复位，包括其关联的profile元数据.该请求由最终用户给予LPA.注意：执行eUICC的eUICC测试存储器复位也将采用类似的步骤.
开始条件：
a. LPA向eUICC认证为合法执行本地profile管理.
b.eUICC Memory Reset选项由LPA（LUI）显示.
过程：
1.最终用户在LPA（LUI）上发出eUICC存储器重置请求.
2.用户意图已验证.
3.LPA（LUI）向最终用户显示’eUICC Memory Reset’的结果消息.
4.最终用户确认符合对LPA的后果.
5.LPA向eUICC发送eUICC存储器复位操作.
结束条件：a.profile已从eUICC中删除.
5.3.1.7添加具有激活码的profile
此步骤将允许订户添加单个profile.此过程不会启用下载的profile，也不会禁用已启用的profile.假定网络连接.下载可以通过输入激活码来启动.
开始条件：
a.用户意图已被验证.
b.eUICC允许下载新的profile.
C. LPA向eUICC认证为合法执行profile下载.
过程：
1.最终用户获得激活码以将profile添加到其设备.
2.LPA请求最终用户输入激活码.
3.按照第5.2.2节开始所述的激活码程序下载profile.
结束条件：
a.该profile已安装在最终用户的设备上.
b.profile元数据已从profile更新.
5.3.1.8编辑SM-DP +地址
此过程将允许最终用户编辑到eUICC的默认SM-DP +地址.
开始条件：
a.LPA中有一个默认的SM-DP +地址.
b.最终用户愿意编辑默认的SM-DP +地址
程序：
1.最终用户通过LPA编辑SM-DP +地址.
2.需要最终用户的简单确认.
3.LPA发送默认的SM-DP +地址以存储在LPA服务中.
4.LPA服务通知LPA存储默认SM-DP +地址.
5.最终用户通过LPA通知.
结束条件：
a.目标默认SM-DP +地址在LPA服务中编辑.
附件A新安全威胁，风险和创建过程要求（资料性附录）
新主设备上的新配置文件（关闭设备激活）
INI1不完整或损坏的配置文件被推送到订阅服务器。
INI2使用特权位置的恶意eUICC方为了将未经请求的配置文件推送到设备。
配置文件删除
IND1由于长期存储已交付的配置文件而导致关键材料在禁用后长期收集。
IND2丢弃的媒体支持中的敏感数据丢失（硬盘驱动器…）
IND3恶意软件启动协调或单独删除一个或多个配置文件，导致与最终用户失去连接。
IND4意外配置文件删除（例如无人照管的儿童…）导致与最终用户失去连接。
IND5非技术专业人员或恶意订户反复删除配置文件并要求重新加载，导致配置服务器的附加费用。
配置文件切换
INP1恶意配置文件切换源自内部方。
INP2人为错误导致交替轮廓切换导致连接丢失。
INP3恶意软件启动一个或多个配置文件的协调或隔离切换，导致连接丢失。
INP4恶意软件启动一个或多个配置文件的协调或隔离切换，导致重大欺诈情况。
配置文件交换
INS1争用条件导致停用所有配置文件并丧失连接。
加密相关风险
INO1丢失或盗用一个或多个Profile Management组件中的私钥，导致整个链上的机密性丧失。
INO2无法撤消已损坏的证书，导致整个证书链失去信任。
INO3地方执法要求导致强制披露关键材料。
INO4地方执法要求导致关键组件的有力妥协。
INO5恶意或意外撤销证书，导致整个供应证书链上拒绝服务。
INO6在配置文件创建，临时存储，传输或长期存储过程中使用临时对称密码或“通用”密钥材料，导致单点故障和攻击被创建。
服务质量
QoS1配置文件创建突发导致eUICC平台无法提供预期的服务级别。
QoS2交付平台上的拒绝服务导致无法提供预期的服务级别。
QoS3无法从导致暂时或永久无法提供配置文件的管理通信故障中恢复。
非人为或不可预测的EXC1
灾难性事件，如洪水，地震等，导致数据中心遭到破坏。
EXC2导致数据中心遭到破坏的地缘政治/人类事件。
EXC3更改法规导致供应交付链（操作员，OEM，SIM供应商…）的行为者部分或全部丧失信任。
用户旅程中的新配置文件
EXN1使用无人照管的主设备或伴随设备恶意配对新设备。
EXN2使用公共Wi-Fi进行互联网连接，导致在配置文件操作期间丧失机密性。
EXN3使用公共Wi-Fi进行互联网连接，导致在配置文件操作期间篡改注册信息。
EXN4社会工程导致向攻击者传播OTP材料。
EXN5配置文件配置期间出现中间人或窃听导致机密性丢失的情况。
EXN6“隐式认证”（例如，HTTP MSISDN加密）导致身份验证或配置文件材料丢失。
设备交换
EXS1
恶意用户使用争用情况导致配置文件在两台设备上被激活。
EXS2使用弱交换程序的恶意实体为了破坏认证向量。
隐私权损失
PRI1对EID或与用户有关的任何数据信息的处理，传输或披露不当，导致将后者用作“超级”用户跟踪标识符。
PRI2 eUICC管理命令导致第三方使用意外和不可预测的“远程寻呼”或“远程控制”命令来间谍或危害设备或订户本身。
其他
EXO1妥协配置文件管理角色之间的交换导致私钥严重丢失。
EXO2由于特定场景的不可预测的实现例程导致的配置文件克隆。
创建过程无法创建
CRE1配置文件应安全删除或至少清除认证向量。
CRE2参与创建配置文件的系统之间的通信应受到完整性和机密性的保护。
附录Bprofile生产程序（资料性附录）
本节描述了一个通用实施.它应该被视为一个例子而已;可能需要特定的实施来解决特定的安全问题.在eUICC中，UICC的当前功能由一个profile表示.与当前的UICC一样，profile是运营商的责任，profile制作是根据他们的请求和许可（如果不是由运营商自己制作）执行的.应用与当前UICC相同的操作员程序.
Snipaste_2018-05-12_16-06-49.png
profile生成由三个步骤组成：?
profile描述定义：SM-DP +基于操作profile描述创建并注册profile描述.
?操作员证书生成：操作员要求SM-DP +生成将在下一步中使用的操作员证书.此过程是可选的，如果操作员想要在生成受保护的profile包期间生成操作员证书，则不会使用该过程. ?
受保护的profile包生成：profile包将被创建，保护和存储.此步骤（批次类型的操作或实时过程）仅在相应操作员下单后执行. ?
合同结论和链接profile：在合同结束时，将激活码发送给最终用户，并可为该合同分配profile.注意：绑定profile包的生成是profile下载的一部分，使用第5.2.2节中的激活码过程.
profile描述定义可以包含以下序列：
Snipaste_2018-05-12_16-07-52.png
开始条件：
a.运营商与SM-DP +之间的契约关系.
步骤：
1.运营商定义其不同的profile类型（由[非标准化]profile描述ID标识），其中包含网络访问应用程序，如USIM，文件结构，数据和应用程序等.
结束条件定义多个profile描述：a.操作员可以根据profile描述ID来订购受保护的profile包.
允许操作员在SM-DP +上分配一组操作员证书，而不将它们关联到特定的ProfileDescriptionID.操作员证书生成可以包含以下序列：
Snipaste_2018-05-12_16-08-02.png
开始条件：
a.运营商已经分配了IMSI，ICCID和其他资源.
步骤：
3.运营商提供IMSI，ICCID，要创建的证书类型（例如Milenage [11]、[12]，TUAK [10]等）以及可能已分配给SM-DP +的其他资源.它要求SM-DP +安全地生成并存储一组操作员证书.
受保护的profile包生成可以包含以下序列：此过程可以应用于profile描述定义，合同结论和链接profile之间，具体取决于受保护的profile包是按需创建还是准备好提前.
Snipaste_2018-05-12_16-08-12.png
开始条件：
a.profile描述定义
过程：
1.操作员通过向SM-DP +提供profile描述ID和一些相应的操作员输入数据（证书，例如ICCID，IMSI）来生成受保护的profile包生成.操作员输入保护profile包生成所需的数据（由IMSI，ICCID，K / Ki，OTA密钥，PIN，PUK等）由操作员创建（并提供给SM-DP +）或由SM-DP +（并提供给操作员）.
结束条件：
a.订购的受保护的profile包可在SM-DP +上找到.运营商能够激活这些订阅，并且可以在绑定到EID时触发profile下载.
激活码必须提供给最终用户才能实现profile下载过程.合同结论和链接profile过程描述了将合同与激活码流程链接在一起的不同场景.
以下选项描述如下：?
具有已知EID的激活码：EID由订户在合同签订期间给予运营商.
?具有未知EID的激活码：订户在合同签订期间未向EID提供EID. EID只在profile下载过程中提供给SM-DP +，并从SM-DP +返回给运营商. ?
提供给运营商的EID激活码：订户在合同结束时不立即给出EID，但在步骤2中向运营商提供.
合同参考可以是但不一定是任何激活码参数（例如令牌），ICCID或IMSI.在任何情况下，SM-DP +都应能够在profile下载过程中分配和链接profile到相应的eUICC.
Snipaste_2018-05-12_16-15-52.png
程序：
图31中的步骤1-11：已知EID的合同结论
1.订户与运营商签订合同，并在此过程中提供EID.
2.至5.或者’在profile下载程序之前由运营商分配ICCID：运营商分配profile并将EID，IMSI和ICCID发送到SM-DP +. SM-DP +链接不同的参数并将其确认给操作员.
6.至10.或者’在profile下载程序之前通过SM-DP +进行ICCID分配’：操作员将EID，IMSI和profile描述ID发送到SM-DP +. SM-DP +将ICCID分配给相应的profile，链接不同的参数并确认分配的ICCID和与运营商的链接. 11.运营商向订户确认合同结论以及相应的信息（合同参考）.
结束条件：
a.认购人已与运营商签订合同和有效认购.
b.通知SM-DP +未来的profile下载过程请求.
Snipaste_2018-05-12_16-16-06.png
过程：
图32中的步骤1-6：没有EID的合同结论
1.订户与运营商签订合同，但不知道目标eUICC（EID）.
2.或者’运营商分配ICCID’：运营商分配profile（ICCID）
3至5.或者’通过SM-DP +分配ICCID’：运营商将profile模板（ID）发送至SM-DP +. SM-DP +分配相应的profile（ICCID）并将分配的ICCID发送给运营商.
6.运营商向订户确认合同结论以及相应信息（合同参考）.
结束条件：a.认购人已与运营商签订合同和有效认购.
Snipaste_2018-05-12_16-16-17.png
步骤：图33中的步骤1-11：向运营商提供EID的激活码
1.在不知道目标eUICC（EID）的情况下，用户与运营商签订合同.
2.或者’运营商分配ICCID’：运营商分配profile（ICCID）
3至5.或者’通过SM-DP +分配ICCID’：运营商将profile模板（ID）发送至SM-DP +. SM-DP +分配相应的profile（ICCID）并将分配的ICCID发送给运营商.
6.运营商向订户确认合同结论以及相应信息（合同参考）.
7.订户选择设备/ eUICC后，EID将与合同参考一起提供给运营商.
8.至10.运营商请求SM-DP +链接eUICC（EID）和Profile（ICCID）. SM-DP +链接EID和ICCID并向运营商确认.
11.运营商确认EID与相应的订户合同的链接.
结束条件：
a.认购人已与运营商签订合同和有效认购.
b.通知SM-DP +未来的profile下载过程请求.
标签：平衡 获取 算法 oca one 另一个 制造商 两种 事件
原文地址：https://www.cnblogs.com/LearnFromNow/p/9345405.html
