CN114731283A - 在设备到设备捆绑包或配置文件传送期间的相互设备到设备认证方法和设备 - Google Patents

在设备到设备捆绑包或配置文件传送期间的相互设备到设备认证方法和设备 Download PDF

Info

Publication number
CN114731283A
CN114731283A CN202080079139.3A CN202080079139A CN114731283A CN 114731283 A CN114731283 A CN 114731283A CN 202080079139 A CN202080079139 A CN 202080079139A CN 114731283 A CN114731283 A CN 114731283A
Authority
CN
China
Prior art keywords
bundle
information
spbl
ssp
authentication information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202080079139.3A
Other languages
English (en)
Inventor
林泰亨
具宗会
尹江镇
李德基
李慧远
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020200023247A external-priority patent/KR20210034460A/ko
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of CN114731283A publication Critical patent/CN114731283A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104—Grouping of entities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G06F21/445—Program or device authentication by mutual authentication, e.g. between devices or programs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/303—Terminal profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/40—Security arrangements using identity modules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/71—Hardware identity

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Power Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本公开公开了一种用于在两个智能安全介质之间进行相互认证的方法和装置，以用于在安全介质之间进行捆绑包传送。根据本公开的实施例，用于为第二设备提供捆绑包的第一设备包括：收发器；以及至少一个处理器，其中至少一个处理器被配置为获得关于要发送到第二设备的捆绑包的信息，控制收发器将捆绑包的标识信息发送到第二设备，控制收发器从第二设备接收与第二设备的第二智能安全平台(SSP)的捆绑包传送相关的认证信息，基于与第二SSP的捆绑包传送相关的认证信息来确定第二SSP的第二次级平台捆绑包加载器(SPBL)是否是能够接收捆绑包的Spbl，并且基于确定的结果来控制收发器将捆绑包发送到第二设备。

Description

在设备到设备捆绑包或配置文件传送期间的相互设备到设备 认证方法和设备
技术领域
本公开涉及一种用于设备到设备相互认证的方法和装置，更具体地，涉及一种用于在设备之间传送捆绑包(bundle)或配置文件(profile)的设备到设备相互认证的方法和装置。
背景技术
为了满足自4G通信系统商业化以来对无线数据业务不断增长的需求，已经努力开发高级的第五代(5G)系统或预5G通信系统。为此，5G或预5G通信系统也被称为超第四代(4G)网络通信系统或后长期演进(LTE)系统。正在考虑使用超高频(毫米波(mmWave))频带(例如，60千兆赫兹(GHz)频带)的5G通信系统的实施方式，以获得更高的数据传送速率。为了减少无线电波的传播损耗并增加无线电波在超高频带中的传输范围，正在讨论波束成形、大规模多输入多输出(MIMO)、全维MIMO(FD-MIMO)、阵列天线、模拟波束成形和大规模天线技术。为了改善系统网络，在5G通信系统中也正在开发用于高级小小区、云无线电接入网络(RAN)、超密集网络、设备到设备(D2D)通信、无线回程、移动网络、合作通信、协调多点(CoMP)、接收端干扰消除等的技术。此外，在5G系统中，正在开发高级编码调制(ACM)(例如，混合FSK和QAM调制(FQAM)、滑动窗口叠加编码(SWSC))以及高级接入技术(例如，滤波器组多载波(FBMC)、非正交多址(NOMA)、稀疏码多址(SCMA))。
与此同时，互联网正在从人类生成和消费信息的面向人类的连接网络演变为分布式实体或事物在没有人类干预的情况下发送、接收和处理信息的物联网(IoT)网络。万物互联(IoE)技术也已出现，其中，例如，通过与云服务器的连接的大数据处理技术与IoT技术相结合。为了实施IoT，需要各种技术，诸如感测技术、有线/无线通信和网络基础设施、服务接口技术和安全技术，甚至目前正在研究用于事物之间连接的传感器网络、机器对机器(M2M)通信、机器类型通信(MTC)的技术。在IoT环境中，可以提供智能互联网技术(IT)服务，其通过收集和分析从连接的事物生成的数据来为人类生活创造新的价值。通过现有信息技术(IT)和各种工业应用之间的融合和结合，IoT可以应用于各种领域，诸如智能家居、智能建筑、智能城市、智能汽车或联网汽车、智能电网、医疗保健、智能家电和高级医疗服务。
在这方面，正在进行将5G通信系统应用于IoT网络的各种尝试。例如，关于传感器网络、M2M、MTC等的技术通过诸如波束形成、MIMO和阵列天线方案等的5G通信技术来实施。甚至云无线电接入网络(云RAN)作为前述大数据处理技术的应用也可以是5G和IoT技术融合的示例。
随着前述移动通信系统的发展，可以提供各种服务，并且需要一种用于有效提供服务的方法。例如，两个设备之间的捆绑包(bundle)或配置文件(profile)(或配置文件包)传送需要用于两个设备之间的相互认证的方法。
发明内容
实施例的描述
问题的解决方案
本公开的实施例可以提供一种用于实现两个安全模块(或电子设备)之间的相互认证的装置和方法，以用于两个电子设备中包括的安全模块之间的捆绑包传送或两个电子设备之间的配置文件传送。
公开的有益效果
根据本公开的各种实施例，两个设备可以相互认证，并且在认证完成之后，安装在一个设备中的捆绑包或配置文件可以以可靠且有效的方法传送到另一设备并安装在另一设备中。
附图说明
图1是根据本公开的实施例的智能安全平台(SSP)的概念图。
图2是根据本公开的实施例的SSP的内部配置的概念图。
图3示出了根据本公开的实施例的设备中用于该设备将捆绑包下载并安装到SSP中的组件的示例。
图4示出了根据本公开的实施例的用于两个设备之间的捆绑包传送的两个设备的交互方法的示例。
图5示出了根据本公开的一些实施例的“可验证次级平台捆绑包加载器(verifiable secondary platform bundle loader，SPBL)列表(verifiable_SPBL_list)”的配置。
图6A示出了根据本公开的一些实施例的“可信SPBL列表(trusted_SPBL_list)”的配置。
图6B示出了根据本公开的一些实施例的“可信SPBL列表(trusted_SPBL_list)”的另一配置。
图7是根据本公开的实施例的用于将捆绑包从一个设备传送到另一设备的程序的概念图。
图8示出了在图7中提出的程序中的用于准备捆绑包传送的详细程序。
图9示出了在图7中提出的程序中的用于传送和安装捆绑包的程序的细节。
图10示出了根据本公开的一些实施例的用于生成证书信息的程序的示例，该证书信息可以应本地捆绑包助理(local bundle assistant，LBA)的请求由设备的SSP提供。
图11示出了根据本公开的一些实施例的程序的示例，在该程序中，设备的SSP在从另一设备接收到可以支持的证书信息时识别接收到的信息并且基于该信息生成用于认证其自身的认证信息。
图12示出了根据本公开的一些实施例的其中设备获得“可信SPBL列表(trusted_SPBL_list)”的程序的示例。
图13是示出根据本公开的一些实施例的设备的配置的图。
图14是示出根据本公开的一些实施例的服务器的配置的图。
图15示出了根据本公开的实施例的用于两个设备之间的配置文件传送的两个设备的交互方法的示例。
图16示出了根据本公开的一些实施例的“可信证书颁发者(certificate issuer，CI)列表(trusted_CI_list)”的配置。
图17示出了根据本公开的一些实施例的其中一个设备向另一设备传送配置文件的程序。
图18示出了根据本公开的一些实施例的第一设备的操作。
图19示出了根据本公开的一些实施例的第二设备的操作。
图20是示出根据本公开的一些实施例的设备的配置的图。
图21是示出根据本公开的一些实施例的服务器的配置的图。
图22是根据本公开的一些实施例的其中一个设备向另一设备传送配置文件的程序的概念图。
图23示出了根据本公开的一些实施例的图22中提出的程序中的配置文件传送准备程序的细节。
图24示出了根据本公开的一些实施例的图22中提出的程序中的两个设备之间的相互认证程序的细节。
图25示出了根据本公开的一些实施例的图22中提出的程序中的一个设备向另一设备传送配置文件并且所传送的配置文件被安装的详细程序。
具体实施方式
最佳模式
根据本公开的实施例，一种在无线通信系统中由第一设备向第二设备提供配置文件的方法，包括：在安装在第一设备中的配置文件当中确定要发送到第二设备的配置文件；基于用于与第二设备的通信的连接从第二设备接收第二设备的嵌入式通用集成电路卡(eUICC)信息；基于eUICC信息生成第一设备的认证信息；将第一设备的认证信息发送到第二设备；从第二设备接收第二设备的认证信息作为对第一设备的认证信息的响应；验证第二设备的认证信息；以及基于验证的结果将针对配置文件的配置文件包(package)发送到第二设备。
根据本公开的实施例，一种在无线通信系统中由第二设备从第一设备接收配置文件的方法，包括：基于用于与第一设备的通信的连接将第二设备的eUICC信息发送到第一设备；从第一设备接收第一设备的认证信息作为对eUICC信息的响应；验证第一设备的认证信息；基于验证的结果生成第二设备的认证信息；将第二设备的认证信息发送到第一设备；以及从第一设备接收配置文件包作为对第二设备的认证信息的响应。
根据本公开的实施例，一种由第一设备向第二设备提供捆绑包的方法，包括：获得关于要发送到第二设备的捆绑包的信息；将捆绑包的标识信息发送到第二设备；从第二设备接收与第二设备的第二智能安全平台(SSP)的捆绑包传送相关的认证信息；基于与第二SSP的捆绑包传送相关的认证信息来确定第二SSP的第二次级平台捆绑包加载器(SPBL)是否是能够接收捆绑包的Spbl；以及基于确定的结果将捆绑包发送到第二设备。
在本公开的实施例中，捆绑包的标识信息可以包括捆绑包的捆绑包家族身份(家族ID，Fid)或捆绑包家族管理器标识符(家族保管器对象ID，Oid)中的至少一个。
在本公开的实施例中，与第二SSP的捆绑包传送相关的认证信息可以包括基于捆绑包的标识信息而确定的接收SPBL认证信息，确定第二SSP的第二SPBL是否是能够接收捆绑包的Spbl可以包括：基于捆绑包的标识信息，确定接收SPBL认证信息是否被包括在第一设备的关于可验证SPBL的信息或关于可信SPBL的信息的至少一个中，并且关于可验证SPBL的信息可以预先存储在第一设备中，并且关于可信SPBL的信息可以从服务器接收。
根据本公开的实施例，关于可信SPBL的信息可以包括与捆绑包的标识信息对应的捆绑包传送策略信息，捆绑包传送策略信息可以包括以下中的至少一个：1)接收SPBL认证信息被包括在关于可验证SPBL的信息中的状况，2)接收SPBL认证信息被包括在关于可信SPBL的信息中的状况，3)接收SPBL认证信息被包括在关于可验证SPBL的信息和关于可信SPBL的信息两者中的状况，以及4)接收SPBL认证信息被包括在关于可验证SPBL的信息和关于可信SPBL的信息之一中的状况，并且确定第二SSP的第二SPBL是否是能够接收捆绑包的Spbl可以包括基于捆绑包传送策略信息确定第二SPBL是否是能够接收捆绑包的Spbl。
在本公开的实施例中，与第二设备的第二SSP的捆绑包传送相关的认证信息可以包括基于捆绑包的标识信息而确定的发送SPBL认证信息，并且该方法还可以包括基于发送SPBL认证信息确定第一设备的第一SSP的第一SPBL是否是能够将捆绑包发送到第二设备的Spbl。
根据本公开的实施例，该方法还可以包括：基于发送SPBL认证信息生成第一设备的认证信息；将第一设备的认证信息发送到第二设备；从第二设备接收第二设备的认证信息；验证第二设备的认证信息的有效性；以及基于验证的结果将捆绑包发送到第二设备。
根据本公开的实施例，该方法还可以包括：将对关于可信SPBL的信息的请求发送到服务器；以及从服务器接收关于可信SPBL的信息，并且对关于可信SPBL的信息的请求可以包括捆绑包的标识信息。
根据本公开的实施例，一种由第二设备从第一设备接收捆绑包的方法包括：从第一设备接收捆绑包的标识信息；基于接收到的捆绑包的标识信息生成与第二设备的第二智能安全平台(SSP)的捆绑包传送相关的认证信息；将与第二SSP的捆绑包传送相关的认证信息发送到第一设备；以及基于第一设备对与第二SSP的捆绑包传送相关的认证信息的验证的结果从第一设备接收捆绑包。
在本公开的实施例中，生成与第二SSP的捆绑包传送相关的认证信息可以包括从预先存储的关于第二设备的可验证次级平台捆绑包加载器(SPBL)的信息中提取与捆绑包的标识信息对应的信息；以及基于提取的信息生成针对捆绑包的接收SPBL认证信息和发送SPBL认证信息。
在本公开的实施例中，生成与第二SSP的捆绑包传送相关的认证信息可以包括基于识别出针对捆绑包的捆绑包家族标识(家族ID)和捆绑包家族管理器标识符(家族保管器对象ID)不包括在接收到的捆绑包的标识信息中，生成包括预先存储的第二设备的可验证SPBL的信息。
根据本公开的实施例，一种用于为第二设备提供捆绑包的第一设备包括：收发器；以及至少一个处理器，其中至少一个处理器被配置为获得关于要发送到第二设备的捆绑包的信息，控制收发器将捆绑包的标识信息发送到第二设备，控制收发器从第二设备接收与第二设备的第二智能安全平台(SSP)的捆绑包传送相关的认证信息，基于与第二SSP的捆绑包传送相关的认证信息来确定第二SSP的第二次级平台捆绑包加载器(SPBL)是否是能够接收捆绑包的Spbl，并且基于确定的结果控制收发器将捆绑包发送到第二设备。
在本公开的实施例中，一种用于从第一设备接收捆绑包的第二设备包括：收发器；以及至少一个处理器，被配置为：控制收发器从第一设备接收捆绑包的标识信息，基于接收到的捆绑包的标识信息生成与第二设备的第二智能安全平台(SSP)的捆绑包传送相关的认证信息，控制收发器将与第二SSP的捆绑包传送相关的认证信息发送到第一设备，以及基于第一设备对与第二SSP的捆绑包传送相关的认证信息的验证的结果来控制收发器从第一设备接收捆绑包。
公开的模式
现在将参考附图详细描述本公开的实施例。
在下面的描述中省略了本领域公知的或者与本公开不直接相关的技术内容。通过省略可能另外模糊本公开的主题的内容，主题将被更清楚地理解。
出于相同原因，附图中的一些部分被夸大、省略或示意性地示出。相应元件的大小可能不完全反映它们的实际大小。在所有附图中，相同的数字指代相同的元件。
参考本公开的以下实施例，将更清楚地理解本公开的优点和特征以及获得它们的方法，这些实施例将随后连同附图一起详细描述。然而，本公开的实施例可以以许多不同的形式体现，并且不应被解释为限于本文阐述的实施例；相反，提供本公开的这些实施例使得本公开将是彻底和完整的，并且将本公开的实施例的范围完全传达给本领域普通技术人员。在整个说明书中，相同的数字指代相同的元件。
可以理解，处理流程图中的相应框和框的组合将由计算机程序指令来执行。计算机程序指令可以被加载在通用计算机、专用计算机或其他可编程数据处理设备的处理器上，并且因此当由计算机或其他可编程数据处理设备的处理器执行时，它们生成用于执行流程图的(多个)框中描述的功能的装置。计算机程序指令也可以被存储在面向计算机或其他可编程数据处理设备的计算机可用或计算机可读的存储器中，因此可以制造包含用于执行流程图的(多个)框中描述的功能的指令装置的产品。计算机程序指令也可以被加载在计算机或可编程数据处理设备上，因此可以使指令生成由计算机或其他可编程数据处理设备执行的过程，以提供用于执行流程图的(多个)框中描述的功能的步骤。
此外，每个框可以表示包括一个或多个可执行指令的模块、片段或代码的一部分，以执行特定的(多个)逻辑功能。注意，在一些替代实施例中，框中描述的功能可以不按次序出现。例如，取决于所涉及的功能，两个连续的框可以基本上同时执行或者以相反的次序执行。
此外，本文使用的术语“单元”或“模块”是指软件或硬件组件，诸如起某种作用的现场可编程门阵列(FPGA)或专用集成电路(ASIC)。然而，模块不限于软件或硬件。模块可以被配置为存储在可寻址存储介质中，或者执行一个或多个处理器。例如，模块可以包括组件，诸如软件组件、面向对象的软件组件、类组件和任务组件、过程、功能、属性、程序、子例程、程序代码段、驱动程序、固件、微代码、电路、数据、数据库、数据结构、表格、数组和变量。由组件和模块提供的功能可以被组合成更少数量的组件和模块，或者被进一步划分成更多数量的组件和模块。此外，组件和模块可以被实施为执行设备或安全多媒体卡中的一个或多个中央处理单元(CPU)。
在整个说明书中，术语之前的诸如第一、第二等的修饰语可以用于在描述实施例时将术语彼此区分开来。诸如第一、第二等的修饰语之后的术语可以指示不同的对象。替代地，诸如第一、第二等的修饰语之后的术语可以指示相同的对象。也就是说，诸如第一、第二等的修饰语可以用于从不同的角度指示相同的对象。例如，诸如第一、第二等的修饰语可以用于从功能或操作的角度对相同的对象进行分类。例如，第一用户和第二用户可以指示相同的用户。
在整个公开中，将通过集中于作为安全介质(security media)的示例的智能安全平台(SSP)来描述每个实施例，但是公开的范围不限于SSP。例如，对于本领域普通技术人员来说显而易见的是，下面将要描述的各种实施例可以基本上等同或类似地应用于执行与SSP基本上相同或类似功能的其他安全介质。
本文使用的特定术语可以被提供来帮助理解本公开，并且可以被修改到不偏离本公开的技术范围的程度。
安全元件(secure element，SE)是指由单个芯片组成的安全模块，该单个芯片存储安全信息(例如，移动通信网络接入密钥、诸如身份(ID)卡/护照的用户标识信息、信用卡信息、加密密钥等)，并且可以配备有控制模块(例如，诸如通用订户身份模块(universalsubscriber identity module，USIM)的网络接入控制模块、加密模块、密钥生成模块等)且可以操作该控制模块以使用所存储的安全信息。SE可以用于各种电子设备(例如，智能电话、平板电脑、可穿戴设备、汽车、IoT设备等)，并且可以使用安全信息和控制模块来提供安全服务(例如，移动通信网络接入、支付、用户认证等)。
SE可以被分类为通用集成电路卡(universal integrated circuit card，UICC)、嵌入式安全元件(embedded secure element，eSE)和智能安全平台(smart secureplatform，SSP)，SSP是UICC和eSE的集成形式，并且可以被细分为可移动型、嵌入型和集成到特定设备或片上系统(system on chip，SOC)中的集成型，这取决于连接到电子设备或安装在电子设备上的形式。
UICC是插入移动通信终端时所使用的智能卡，并且也称为UICC卡。UICC可以包括接入控制模块，以接入移动通信运营商的网络。接入控制模块的示例可以包括USIM、订户身份模块(subscriber identity module，SIM)、IP多媒体服务身份模块(IP multimediaservice identity module，ISIM)等。包括USIM的UICC通常被称为USIM卡。同样，包括SIM的UICC也称为SIM卡。与此同时，可以在制造阶段在UICC卡中配备SIM模块，或者可以将在用户期望的时间使用的移动通信服务的SIM模块下载到UICC卡上。此外，可以下载多个SIM模块并将其安装在UICC卡中，并且可以选择和使用SIM模块中的至少一个。UICC卡可以不嵌入也可以嵌入在设备中。嵌入在设备中以供使用的UICC被称为嵌入式UICC(embedded UICC，eUICC)，并且具体地，嵌入在通信处理器、应用处理器或具有集成有通信处理器和应用处理器的单处理器结构的SoC中的UICC被称为集成UICC(integrated UICC，iUICC)。eUICC和iUICC通常可以被嵌入在设备中以供使用，并且可以指包括使至少一个SIM模块能够被远程下载到UICC卡并使下载的SIM模块之一能够被选择的功能的UICC卡。在本公开中，包括使至少一个SIM模块能够被远程下载并使SIM模块能够被选择的功能的UICC卡通常被称为eUICC或iUICC。具体地，那些包括使SIM模块能够被远程下载并被选择的功能的UICC卡(无论是否嵌入在设备中)通常被称为eUICC或iUICC。
在本公开中，术语UICC和SIM可以可互换地使用，并且术语eUICC和eSIM也可以可互换地使用。
“eUICC标识符(eUICC ID)”可以是嵌入在UE中的eUICC的唯一标识符，并且可以被称为EID。此外，在eUICC预先配备有供应配置文件的情况下，eUICC标识符(eUICC ID)可以是对应的供应配置文件的标识符(供应配置文件的配置文件ID)。在本公开的实施例中，当设备和eUICC芯片没有分离时，eUICC ID可以是设备ID。此外，eUICC ID可以指eUICC芯片的特定安全域。
嵌入式安全元件(embedded secure element，eSE)是指嵌入电子设备时所使用的嵌入型SE。eSE通常可以应设备制造商的用以包括操作系统和框架的请求仅为该制造商而制造。小应用形式的服务控制模块可以被远程下载并被安装在eSE中，并且所安装的服务控制模块可以用于各种安全服务，诸如电子钱包、票务、电子护照、数字钥匙等。在本公开中，处于附接到电子设备的单个芯片的形式的SE(其使服务控制模块能够被远程下载并被安装)通常被称为eSE。
智能安全平台(smart secure platform，SSP)是指能够支持集成UICC的功能和eSE的功能的单个芯片。SSP可以被分类为可移动SSP(removable SSP，rSSP)、嵌入式SSP(embedded SSP，eSSP)和嵌入SoC中的集成SSP(integrated SSP，iSSP)。SSP可以包括一个主平台(primary platform，PP)和在PP上操作的至少一个次级平台捆绑包(secondaryplatform bundle，SPB)。PP可以包括硬件平台或低级操作系统(low level operatingsystem，LLOS)中的至少一个，并且次级平台捆绑包可以包括高级操作系统(high-leveloperating system，HLOS)和在HLOS上驱动的应用中的至少一个。次级平台捆绑包也可以被称为SPB或捆绑包。捆绑包可以通过主平台接口(primary platform interface，PPI)访问资源，诸如PP的中央处理单元(CPU)或存储器，并且因此在PP上被驱动。捆绑包可以配备有通信应用，诸如SIM、USIM、ISIM等，并且还配备有各种应用，诸如电子钱包、票务、电子护照、数字钥匙等。在本公开中，SSP也可以被称为智能安全介质。
取决于被远程下载和安装的捆绑包，SSP可以用于前述UICC或eSE的目的，并且多个捆绑包可以被安装在单个SSP中，并且同时进行操作以用于UICC和eSE两者。换句话说，当包括配置文件的捆绑包被操作时，该捆绑包可以用于使UICC接入移动通信运营商的网络。对于UICC捆绑包，至少一个配置文件(诸如eUICC或iUICC)可以被远程下载到捆绑包中，并且配置文件中的至少一个可以被选择。此外，当在SSP上操作包括配备有用于提供例如电子钱包、票务、电子护照或数字钥匙服务的应用的服务控制模块的捆绑包时，SSP可以用于eSE。多个服务控制模块可以以集成方式或分离地进行安装和操作。
SSP可以通过使用空中下载(over the air，OTA)技术从外部捆绑包管理服务器(即，次级平台捆绑包管理器(SPB)管理器)下载并安装捆绑包，或者从另一设备接收并安装捆绑包。在本公开中，下载并安装捆绑包的方法可以等同地应用于可以可移动地插入设备的可移动SSP(rSSP)、可以安装在设备中的嵌入式SSP(eSSP)以及可以集成在安装在设备中的SoC中的集成SSP(iSSP)。
SSP标识符(SSP ID)可以是嵌入在设备中的SSP的唯一标识符，并且可以被称为sspID。此外，当设备和SSP芯片没有如本公开的实施例中那样分离时，SSP ID可以是设备ID。SSP ID也可以被称为SSP中的特定捆绑包ID(SPB ID)。具体地，SSP ID可以被称为管理器捆绑包或管理SSP中另一捆绑包的安装、激活、停用和删除的加载器(即，SPB加载器(SPBloader，SPBL))的捆绑包标识符。SSP ID也可以被称为SSP中的主平台标识符。SSP还可以具有多个SSP标识符，这些SSP标识符可以具有从单个唯一SSP标识符得到的值。
可以通过使用SSP的PP上的PP的资源来驱动SPB，并且例如，UICC捆绑包可以指存储在现有UICC中的应用、文件系统、认证值等以及操作它们的操作系统(例如，HLOS)的软件类型包。在本公开中，SPB可以被称为捆绑包。
在本公开中，捆绑包的状态可以如下：
[启用]
在本公开中，设备或外部服务器启用捆绑包的操作可以指将对应的SPB的状态改变为启用状态以配置UE接收由捆绑包提供的服务(例如，通过移动运营商的通信服务、信用卡支付服务、用户认证服务等)的操作。处于启用状态的捆绑包可以被表示为启用的捆绑包。启用的捆绑包可以以加密状态存储在SSP的内部或外部存储空间中。
[活动]
根据捆绑包的外部输入(例如，用户输入、推送、设备中的应用的请求、来自移动运营商的认证请求、PP管理消息等)或捆绑包中的操作(例如，定时器、轮询)，本文公开的启用的捆绑包可以被改变成活动状态。处于活动状态的捆绑包可以指处于从SSP的内部或外部存储空间加载到SSP中的驱动存储器上、通过使用SSP中的安全控制设备(例如，安全CPU)来处理安全信息并且向设备提供安全服务的状态的捆绑包。
[禁用]
在本公开中，设备或外部服务器禁用捆绑包的操作可以指将捆绑包的状态改变为禁用状态以配置设备不接收由捆绑包提供的服务的操作。禁用状态的SPB可以被表示为禁用的捆绑包。禁用的捆绑包可以以加密状态存储在SSP的内部或外部存储空间中。
[删除]
在本公开中，设备或外部服务器删除捆绑包的操作可以指将捆绑包的状态改变为删除状态或者删除包括捆绑包以及与捆绑包相关联的数据以配置设备或外部服务器不再驱动、激活捆绑包或停用捆绑包的操作。处于删除状态的捆绑包可以被表示为删除的捆绑包。
术语“捆绑包映像(bundle image)”或“映像(image)”可以与捆绑包或特定捆绑包的数据对象可互换地使用，并且也可以被称为捆绑包标签、长度和值(tag,length,andvalue，TLV)或捆绑包映像TLV。在用加密参数加密捆绑包映像的情况下，捆绑包映像可以被称为受保护捆绑包映像(protected bundle image，PBI)或受保护捆绑包映像TLV(PBITLV)。当捆绑包映像用只可以由特定SSP解码的加密参数加密时，它可以被称为绑定捆绑包映像(bound bundle image，BBI)或绑定捆绑包映像TLV(BBI TLV)。捆绑包映像TLV可以是表示以TLV格式构成捆绑包的信息的数据集。
捆绑包分类符(classifier)可以指与捆绑包标识符(SPB ID)、捆绑包家族标识符(SPB家族ID)、捆绑包家族管理器标识符(SPB家族保管器对象ID)、捆绑包匹配ID或事件ID相匹配的因子。捆绑包标识符(SPB ID)可以指示每个捆绑包的唯一标识符。捆绑包家族标识符可以指示用于识别捆绑包的类型的标识符(例如，用于接入移动通信公司的网络的电信捆绑包)。在本公开中，捆绑包家族标识符可以被称为家族ID、Fid或FID。捆绑包家族管理器标识符可以指用于识别管理捆绑包家族标识符的实体(例如，移动运营商、设备制造商、特定团体等)的标识符。在本公开中，捆绑包家族管理器标识符可以被称为OID或Oid。捆绑包分类符可以用作在捆绑包管理服务器或设备中索引捆绑包的值。
术语“捆绑包元数据”是指用于指示或描述捆绑包的信息集。捆绑包元数据可以包括捆绑包分类符。捆绑包元数据还可以包括关于捆绑包的属性、特性或设置的信息。捆绑包元数据可以被表达为元数据。
配置文件可以指存储在UICC中的数据对象，诸如应用、文件系统、认证密钥值等。
在本公开中，配置文件包可以指要安装在UICC中的以软件的形式打包的配置文件的内容。配置文件包可以被称为配置文件包TLV。当配置文件包用加密参数加密时，它可以被称为受保护配置文件包(protected profile package，PPP)或受保护配置文件包TLV(PPP TLV)。当配置文件包用只可以由特定eUICC解码的加密参数加密时，它可以被称为绑定配置文件包(bound profile package，BPP)或绑定配置文件包TLV(BPP TLV)。配置文件包TLV可以是表示以TLV格式构成配置文件的信息的数据集。
在本公开中，配置文件映像(profile image)可以指安装在UICC中的配置文件包的二进制数据。配置文件映像可以被称为配置文件TLV或配置文件映像TLV。当配置文件映像用加密参数加密时，它可以被称为受保护配置文件映像(protected profile image，PPI)或受保护配置文件映像TLV(PPI TLV)。当配置文件映像用只可以由特定eUICC解码的加密参数加密时，它可以被称为绑定配置文件映像(bound profile image，BPI)或绑定配置文件映像TLV(BPI TLV)。配置文件映像TLV可以是表示以TLV格式构成配置文件的信息的数据集。
在本公开中，配置文件的状态可以如下：
[启用]
在本公开中，设备启用配置文件的操作可以指将配置文件的状态改变为启用状态以配置设备通过提供配置文件的移动运营商接收通信服务的操作。处于启用状态的配置文件可以被表示为启用的配置文件。
[禁用]
在本公开中，设备禁用配置文件的操作可以指将配置文件的状态改变为禁用状态以配置设备不通过提供配置文件的移动运营商接收通信服务的操作。处于禁用状态的配置文件可以被表示为禁用的配置文件。
[删除]
在本公开中，设备删除配置文件的操作可以指将配置文件的状态改变为删除状态以配置设备不再激活配置文件或停用配置文件的操作。处于删除状态的配置文件可以被表示为删除的配置文件。
在本公开中，设备启用、禁用或删除配置文件的操作也可以指如下的操作：用预期的启用状态、预期的禁用状态或预期的删除状态来标记每个配置文件，而不是立即将配置文件改变为启用状态、禁用状态或删除状态，并且在设备或设备的UICC执行特定操作(例如，执行刷新命令或重置命令)之后将每个配置文件改变为启用状态、禁用状态或删除状态。用预期的启用状态、预期的禁用状态或预期的删除状态来标记某个配置文件的操作并不总是被限制为用一个预期状态来标记一个配置文件，而是可以包括用相同的预期状态或不同的预期状态来标记一个或多个配置文件、用一个或多个预期状态来标记一个配置文件、或者用相同的预期状态或一个或多个不同的预期状态来标记一个或多个配置文件。
此外，当设备用一个或多个预期状态来标记任何配置文件时，两个预期状态标记可以被组合成一个。例如，当用预期的禁用状态和预期的删除状态来标记任意配置文件时，可以用预期的禁用和删除状态来标记该配置文件。
设备用预期状态标记一个或多个配置文件的操作可以顺序或同时执行。设备用预期状态标记一个或多个配置文件并随后改变配置文件的实际状态的操作可以顺序或同时执行。
配置文件分类符可以指与配置文件ID、集成电路卡ID(integrated circuit cardID，ICCID)、匹配ID、事件ID、激活码、激活码令牌、命令码、命令码令牌、有符号命令码、无符号命令码、IDS-P或配置文件域(profile domain，PD)相匹配的因子。配置文件ID可以指示每个配置文件的唯一标识符。配置文件分类符还可以包括能够索引配置文件的配置文件提供服务器(SM-DP+)的地址。配置文件分类符还可以包括配置文件提供服务器(SM-DP+)的签名。
捆绑包管理服务器可以包括应服务提供商或另一捆绑包管理服务器的请求来生成捆绑包、加密所生成的捆绑包、创建用于远程捆绑包管理的指令或加密用于远程捆绑包管理的指令的功能。提供该功能的捆绑包管理服务器可以被表示为次级平台捆绑包管理器(secondary platform bundle manager，SPBM)、远程捆绑包管理器(remote bundlemanager，RBM)、映像传送服务器(image delivery server，IDS)、订阅管理器数据准备(subscription manager data preparation，SM-DP)、SM-DP加强(SM-DP plus，SM-DP+)、管理SM-DP+的管理器捆绑包服务器、捆绑包加密服务器、捆绑包生成服务器、捆绑包提供者(bundle provisioner，BP)、捆绑包提供商或捆绑包供应凭证持有者(bundleprovisioning credentials holder，BPC持有者)中的至少一个。
在本公开中，捆绑包管理服务器可以用于管理SSP的密钥和认证设置以下载、安装或更新捆绑包，并且远程管理捆绑包的状态。提供该功能的捆绑包管理服务器可以被表示为SPBM、RBM、IDS、订阅管理器安全路由(subscription manager secure routing，SM-SR)、SM-SR加强(SM-SR plus，SM-SR+)、eUICC配置文件管理器的卡外实体、配置文件管理凭证持有者(profile management credentials holder，PMC持有者)或eUICC管理器(eUICCmanager，EM)中的至少一个。
在本公开中，开放中继服务器可以从一个或多个捆绑包管理服务器或另一开放中继服务器接收注册事件请求(或事件注册请求)。此外，可以组合使用一个或多个开放中继服务器，在这种情况下，第一开放中继服务器不仅可以从捆绑包管理服务器而且可以从第二开放中继服务器接收注册事件请求。在本公开中，开放中继服务器的功能可以被集成到捆绑包管理服务器中。在本公开中，开放中继服务器可以被表示为SPB管理器、RBM、次级平台捆绑包发现服务器(secondary platform bundle discovery sever，SPBDS)、捆绑包发现服务器(bundle discovery sever，BDS)、订阅管理器发现服务(subscription managerdiscovery service，SM-DS)、发现服务(discovery service，DS)、根SM-DS或替代SM-DS中的至少一个。
在本公开中，捆绑包管理服务器可以指执行生成、加密和传送捆绑包或捆绑包管理指令的功能以及管理SSP和所安装的捆绑包的设置的功能的服务器。此外，捆绑包管理服务器可以指可以进一步执行开放中继服务器功能的服务器。相应地，在本公开的以下各种实施例中，捆绑包管理服务器和开放中继服务器的操作可以由一个捆绑包管理服务器来执行。此外，每个功能可以被划分到多个分离的捆绑包管理服务器上并由多个分离的捆绑包管理服务器执行。在本公开的说明书中，捆绑包管理服务器或开放中继服务器可以被表示为捆绑包服务器。捆绑包服务器可以是与捆绑包管理服务器和开放中继服务器之一相对应，并且包括捆绑包管理服务器和开放中继服务器的所有功能和配置的设备。
远程SIM供应服务器(remote SIM provisioning server，RSP服务器)可以与指示配置文件提供服务器和/或配置文件管理服务器和/或开放中继服务器的名称一起使用，这将在后面描述。RSP服务器可以被表示为订阅管理器XX(subscription manager XX，SM-XX)。
在本公开中，配置文件提供服务器可以包括生成配置文件、加密所生成的配置文件、生成配置文件远程管理指令或加密所生成的配置文件远程管理指令的功能。配置文件提供服务器可以被表示为订阅管理器数据准备(SM-DP)、订阅管理器数据准备加强(SM-DP+)、配置文件域的卡外实体、配置文件加密服务器、配置文件生成服务器、配置文件提供者(PP)、配置文件提供商或配置文件供应凭证持有者(PPC持有者)。
在本公开中，配置文件管理服务器可以包括管理配置文件的功能。配置文件管理服务器可以被表示为订阅管理器安全路由(SM-SR)、订阅管理器安全路由加强(SM-SR+)、eUICC配置文件管理器的卡外实体或配置文件管理凭证持有者(PMC持有者)、eUICC管理器(EM)、配置文件管理器(PP)等。
在本公开中，配置文件提供服务器可以指添加了配置文件管理服务器的功能的服务器。相应地，在本公开的各种实施例中，配置文件提供服务器的操作可以由配置文件管理服务器来执行。类似地，配置文件管理服务器或SM-SR的操作可以由配置文件提供服务器来执行。
在本公开中，开放中继服务器可以被表示为订阅管理器发现服务(SM-DS)、发现服务(DS)、根SM-DS或替代SM-DS。开放中继服务器可以从一个或多个配置文件提供服务器或另一开放中继服务器接收注册事件请求(或事件注册请求)。此外，可以组合使用一个或多个开放中继服务器，在这种情况下，第一开放中继服务器不仅可以从配置文件提供服务器而且可以从第二开放中继服务器接收注册事件请求。
服务提供商可以指通过向捆绑包管理服务器发布要求来请求生成捆绑包并通过捆绑包向设备提供服务的业务实体。例如，服务提供商可以指通过配备有通信应用的捆绑包来提供通信网络接入服务的移动运营商，并且移动运营商的业务支持系统(businesssupporting system，BSS)、运营支持系统(operational supporting system，OSS)、销售点(point of sale，POS)终端和其他IT系统可以被统称为服务提供商。此外，在本公开中，服务提供商可能不仅指特定的业务实体，还指一个或多个业务实体的团体、协会或联合体，或者代表该团体或协会的代表。此外，本公开中的服务提供商可以被命名为运营商(OP或Op.)、捆绑包所有者(bundle owner，BO)、映像所有者(image owner，IO)等，并且每个服务提供商可以被配置或分配有名称和/或对象标识符(object identifier，OID)中的至少一个。当服务提供商是指一个或多个业务实体的团体或协会或代表时，任何团体或协会的名称或OID可以由属于该团体或协会的所有业务实体或该代表的伙伴业务实体所共享。
移动运营商可以指示为设备提供通信服务的业务实体，并且可以共同指示移动运营商的所有业务支持系统(BSS)、运营支持系统(OSS)、销售点(POS)终端和其他IT系统。此外，在本公开中，移动运营商可能不仅指提供通信服务的特定业务实体，还指一个或多个业务实体的团体、协会或联合体，或者代表该团体或协会的代表。此外，在本公开中，移动运营商可以被命名为运营商(OP或Op.)、移动网络运营商(mobile network operator，MNO)、移动虚拟网络运营商(mobile virtual network operator，MVNO)、服务提供商或SP、配置文件所有者(profile owner，PO)等，并且每个移动运营商可以被配置或分配有移动运营商的名称和/或对象标识符(OID)中的至少一个。当移动运营商是指一个或多个业务实体的团体或协会或代表时，任何团体或协会的名称或OID可以由属于该团体或协会的所有业务实体或该代表的伙伴业务实体所共享。
术语“订户”可以用于指示拥有设备所有权的服务提供商或者拥有设备所有权的末端用户(end user)。通常，服务提供商拥有所有权的设备可以被称为M2M设备，并且末端用户拥有所有权的设备可以被称为消费者设备。至于M2M设备，可能存在不拥有该设备的所有权但从服务提供商处接管或租赁该设备的末端用户，在这种情况下，订户可以与服务提供商不同，也可以与服务提供商相同。
订户意图通常可以用于指示订户本地或远程地管理捆绑包的意图。对于本地管理，订户意图可以指末端用户意图，并且对于远程管理，订户意图可以指服务提供商意图。
术语“末端用户同意”可以指示末端用户是否同意执行本地或远程管理。
本文使用的术语“设备”或“终端”也可以被称为移动站(mobile station，MS)、用户设备(user equipment，UE)、用户终端(user terminal，UT)、无线终端、接入终端(accessterminal，AT)、订户单元、订户站(subscriber station，SS)、无线设备、无线通信设备、无线发送/接收单元(wireless transmit/receive unit，WTRU)、移动节点、移动设备或其他名称。在各种实施例中，设备可以包括蜂窝电话、具有无线通信功能的智能电话、具有无线通信功能的个人数字助理(personal digital assistant，PDA)、无线调制解调器、具有无线通信功能的便携式计算机、具有无线通信功能的诸如相机的捕获设备、具有无线通信功能的游戏设备、具有无线通信功能的用于音乐存储和播放的家用电器、能够进行无线互联网接入和浏览的互联网家用电器、或者具有组合功能的便携式单元或终端。此外，设备可以包括机器对机器(machine to machine，M2M)设备或机器类型通信(machine typecommunication，MTC)终端/设备，但不限于此。在本公开中，终端也可以被称为电子设备。
在本公开中，能够下载和安装捆绑包的SSP可以被嵌入在电子设备中。当SSP没有被嵌入在电子设备中时，与电子设备物理分离的SSP可以被插入并连接到电子设备。例如，SSP可以以卡的形式插入电子设备。电子设备可以包括可包括能够下载和安装捆绑包的SSP的设备。SSP可以被嵌入在设备中，或与设备分离，在这种情况下，SSP可以被插入并连接到设备。
在本公开中，能够下载和安装配置文件的UICC可以被嵌入在电子设备中。当UICC没有被嵌入在电子设备中时，与电子设备物理分离的UICC可以被插入并连接到电子设备。例如，UICC可以以卡的形式插入电子设备。电子设备可以包括可包括能够下载和安装配置文件的UICC的设备。SSP可以被嵌入在设备中，或与设备分离，在这种情况下，SSP可以被插入并连接到设备。能够下载和安装配置文件的UICC可以被称为例如eUICC。
术语“本地捆绑包助理(local bundle assistant，LBA)”可以指安装在设备或电子设备中用于控制SSP的软件或应用。软件或应用可以指本地捆绑包管理器(local bundlemanager，LBM)。
加载器(例如，SPBL)可以被称为用于管理SSP上的另一捆绑包的安装、激活、停用和删除的管理器捆绑包。设备或远程服务器的LBA可以通过加载器来安装、激活、停用或删除特定捆绑包。在本公开中，加载器的操作甚至可以被描述为包括加载器的SSP的操作。
术语“本地配置文件助理(local profile assistant，LPA)”可以指安装在设备或电子设备中用于控制设备或电子设备中的UICC或eUICC的软件或应用。
术语“事件”可以用于以下目的：
[与捆绑包联合使用的情况]
事件是对于捆绑包下载、远程捆绑包管理、或者捆绑包或SSP的其他管理/处理指令的统称。事件可以被命名为远程捆绑包供应操作或RBP操作，或者事件记录，并且每个事件可以被识别为包括对应的事件标识符(事件ID或eventID)、匹配标识符(匹配ID或matchingID)、存储该事件的捆绑包管理服务器或开放中继服务器的地址(FQDN、IP地址或URL)、或每个服务器的标识符中的至少一个的数据。捆绑包下载可以与捆绑包安装可互换地使用。术语“事件类型”可以用作指示特定事件是否是捆绑包下载、远程捆绑包管理(例如，删除、激活、停用、替换、更新等)、或管理/处理其他捆绑包或SSP的命令的术语。此外，事件类型可以被命名为操作类型或OperationType、操作类或OperationClass、事件请求类型、事件类、事件请求类等。
本地捆绑包管理可以被命名为捆绑包本地管理、本地管理、本地管理命令、本地命令、LBM包、捆绑包本地管理包、本地管理包、本地管理命令包、本地命令包等。LBM可以用于安装任何捆绑包，通过安装在设备中的软件改变特定捆绑包的状态(启用、禁用或删除状态)，或者更新特定捆绑包的内容(例如，捆绑包昵称、捆绑包元数据等)。LBM可以包括一个或多个本地管理命令，并且每个本地管理命令的目标捆绑包可以相同或不同。
远程捆绑包管理(remote bundle management，RBM)可以被命名为捆绑包远程管理、远程管理、远程管理命令、远程命令、RBM包、捆绑包远程管理包、远程管理包、远程管理命令包、远程命令包等。RBM可以用于安装任何捆绑包，改变特定捆绑包的状态(启用、禁用或删除状态)，或者更新特定捆绑包的内容(例如，捆绑包昵称、捆绑包元数据等)。RBM可以包括一个或多个远程管理命令，并且每个远程管理命令的目标捆绑包可以相同或不同。
目标捆绑包可以指要服从本地管理命令或远程管理命令的捆绑包。
捆绑包规则可以用作用于要由设备检查以对目标捆绑包执行本地管理或远程管理的信息的术语。此外，捆绑包规则可以与术语捆绑包策略、规则、策略等可互换地使用。
[与配置文件联合使用的情况]
事件是对于配置文件下载、远程配置文件管理、或者配置文件或eUICC的其他管理/处理指令的统称。事件可以被命名为远程SIM供应操作或RSP操作，或者事件记录，并且每个事件可以被称为包括对应的事件标识符(事件ID或eventID)、匹配标识符(匹配ID或matchingID)、地址(FQDN、IP地址或URL)、签名、以及存储该事件的配置文件提供服务器(SM-DP+)或开放中继服务器(SM-DS)的数字认证证书中的至少一个的数据。
与事件相对应的数据可以被称为命令码。使用命令码的全部或部分程序可以被称为命令码处理程序、命令码程序或本地配置文件助理应用编程接口(LPA API)。配置文件下载可以与配置文件安装可互换地使用。
此外，事件类型可以用作指示特定事件是否是配置文件下载、远程配置文件管理(例如，删除、激活、停用、替换、更新等)、或管理/处理其他配置文件或eUICC的命令的术语，并且可以被命名为操作类型或OperationType、操作类或OperationClass、事件请求类型、事件类、事件请求类等。任意事件标识符(EventID或MatchingID)可以被分配一个信道，在该信道中设备获得事件标识符(EventID或MatchingID)或使用目的。
本地配置文件管理(local profile management，LPM)可以被命名为配置文件本地管理、本地管理、本地管理命令、本地命令、LPM包、配置文件本地管理包、本地管理包、本地管理命令包、或本地命令包。LPM可以用于通过安装在设备上的软件来改变特定配置文件的状态(启用、禁用或删除状态)，或者更新特定配置文件的内容(例如，配置文件昵称、配置文件元数据等)。LPM可以包括一个或多个本地管理命令，并且每个本地管理命令的目标配置文件可以相同或不同。
远程配置文件管理(remote profile management，RPM)可以被命名为配置文件远程管理、远程管理、远程管理命令、远程命令、RPM包、配置文件远程管理包、远程管理包、远程管理命令包、或远程命令包。RPM可以用于改变特定配置文件的状态(启用、禁用或删除状态)，或者更新特定配置文件的内容(例如，配置文件昵称、配置文件元数据等)。RPM可以包括一个或多个远程管理命令，并且每个远程管理命令的目标配置文件可以相同或不同。
证书或数字证书可以指用于基于由公钥(public key，PK)和私钥(secret key，SK)组成的非对称密钥进行相互认证的数字证书。每个证书可以包括一个或多个PK、与每个PK对应的PK标识符(PK identifier，PKID)、颁发证书的证书颁发者(certificate issuer，CI)的标识符以及数字签名。证书颁发者可以被命名为证明颁发者、证书机构(certificateauthority，CA)、证明机构等。在本公开中，PK和PKID可以用于指代特定PK或包括特定PK的证书、特定PK的一部分或包括PK的证书的一部分、特定PK的运算结果(例如，散列)值或包括PK的证书的运算结果(例如，散列)值、特定PK的一部分的运算结果(例如，散列)值或包括PK的证书的一部分的运算结果(例如，散列)值、存储数据的存储空间等。
当由证书颁发者颁发的证书(第一证书)被用于颁发其他证书(第二证书)或者第二证书被用于连续颁发第三证书或更高证书时，证书链或证书层级可以表示证书之间的相关性。在这种情况下，用于颁发第一证书的CI证书可以被命名为根证书、最高证书、根CI、根CI证书、根CA、根CA证书等。
在本公开的描述中，当确定相关功能或配置的详细描述可能不必要地模糊本公开的主题时，将省略该详细描述。
现在将描述用于在设备之间传送和安装捆绑包的方法和装置的各种实施例。
图1是根据本公开的实施例的SSP 120的概念图。
参考图1，根据本公开的实施例的终端(以下称为设备)110可以包括SSP 120。例如，SSP 120可以被嵌入在设备110的SoC 130中。SoC 130可以是通信处理器、应用处理器或其中集成有两个处理器的处理器。在另一示例中，SSP 120可以是分离形式的可移动型122而没有被集成到SoC，或者是预先嵌入在设备110中的嵌入型124。
在各种实施例中，设备中所包括的SSP 120可以包括一个或多个电信捆绑包、一个或多个支付捆绑包或者一个或多个电子ID捆绑包中的至少一个。例如，如图1所示，在SSP120中包括多个电信捆绑包140和150的情况下，设备110可以通过基于设置同时或时分地操作多个电信捆绑包140和150来使用移动通信网络。此外，在SSP 120中包括支付捆绑包170和电子ID捆绑包180的情况下，设备110可以通过使用支付捆绑包170来使用经由设备app的在线支付或者经由外部信用卡销售点(PoS)设备的离线支付，并且通过使用电子ID捆绑包180来认证设备的所有者的身份。
图2是根据本公开的实施例的SSP 210的内部配置的概念图。
参考图2，在本公开的实施例中，SSP 210可以包括主平台(primary platform，PP)220和在PP 220上进行操作的至少一个次级平台捆绑包(secondary platform bundle，SPB)230和240。
在各种实施例中，主平台220可以包括硬件(未示出)和至少一个低级操作系统(low-level operating system，LLOS)222。
在各种实施例中，次级平台捆绑包230可以包括高级操作系统(high-leveloperating system，HLOS)232和在HLOS 232上进行操作的至少一个应用234。
在各种实施例中，每个次级平台捆绑包230或240可以通过使用主平台接口(primary platform interface，PPI)250来访问主平台220的资源(诸如CPU、存储器等)，并且可以相应地在SSP 210上进行操作。
图3示出了根据本公开的实施例的设备中用于该设备将捆绑包下载并安装到SSP上的组件的示例。
参考图3，根据本公开的实施例的设备310可以包括SSP 330和/或用于控制SSP330的LBA 312。例如，设备310可以是其中安装有SSP 330和用于控制SSP 330的LBA 312的设备。例如，SSP 330可以被嵌入在设备310中或者可从设备310移除。
在各种实施例中，SSP 330可以包括如下中的至少一个：主平台331、次级平台捆绑包加载器(secondary platform bundle loader，SPBL)333以及一个或多个次级平台捆绑包335、337或339。
在各种实施例中，次级平台捆绑包335、337或339可以在发布之后被远程下载和安装，而不是在发布设备时被安装在SSP 330中。
在各种实施例中，如图3的示例中，每个捆绑包可以具有不同的捆绑包家族标识符和/或捆绑包家族管理器标识符341、342、343。捆绑包家族标识符和/或捆绑包家族管理器标识符341、342、343可以用作下载和安装捆绑包所需的信息。具体地，SSP 330或SPBL 333可以基于捆绑包家族标识符和/或捆绑包家族管理器标识符341、342、343来允许或拒绝特定捆绑包的下载和安装。
图4示出了根据本公开的实施例的用于两个设备之间的捆绑包传送的两个设备的操作方法的示例。
参考图4，根据本公开的实施例，设备可以包括至少一个LBA和至少一个SSP。例如，第一设备400可以包括第一LBA 410和第一SSP 420，并且第二设备450可以包括第二LBA460和第二SSP 470。
在各种实施例中，用户可以向设备发送命令或者从设备接收要提供给用户的信息。例如，如在操作4010和4060中，第一用户440/第二用户490可以向第一设备400/第二设备450的第一LBA 410/第二LBA 460发送命令，或者从第一LBA 410/第二LBA 460接收要提供给用户的信息。第一用户440和第二用户490可以指不同的用户或相同的用户。
在各种实施例中，用户向设备发送命令或从设备接收要提供给用户的信息的操作(以下称为第一操作)可以包括用户选择要发送的捆绑包的过程。第一操作还可以包括用户识别要由用户接收的捆绑包的信息的过程。第一操作还可以包括用户确认是否发送要发送的捆绑包的过程。第一操作还可以包括确认是否发送用户想要接收的捆绑包的操作。选择和确认操作是分离的操作，它们可以不全部被操作，或者可以分离地选择和执行其中的一个或多个操作。
此外，如在操作4020和4070中，第一LBA 410/第二LBA 460可以向第一SSP 420/第二SSP 470发送命令，或者与第一SSP 420/第二SSP 470交换数据。
在实施例中，在第一LBA 410/第二LBA 460向第一SSP 420/第二SSP470发送命令或者与第一SSP 420/第二SSP 470交换数据的操作(以下称为第二操作)中，每个LBA可以将在第一操作中接收的用户的命令转发给SSP。每个LBA可以接收来自SSP的传输的结果，作为转发给SSP的命令的成果。
在另一示例中，在第二操作中，每个LBA可以将从另一设备或外部服务器接收的命令或数据转发给SSP。每个LBA可以接收来自SSP的传输的结果，作为转发给SSP的命令或数据的成果。
在各种实施例中，在第二操作中，每个LBA可以基于用户的命令或从其他设备或外部服务器接收的命令或数据来定义新的命令和数据，并且可以向SSP发送新的命令和数据。每个LBA可以接收来自SSP的传输的结果，作为转发的新的命令或数据的成果。
在各种实施例中，在第二操作中，第一LBA 410/第二LBA 460和第一SSP 420/第二SSP 470可以通过彼此交换数据来安装捆绑包。
在各种实施例中，在操作4050(以下称为第三操作)中，第一LBA 410/第二LBA 460可以彼此连接，以向彼此发送命令或彼此交换数据。在第三操作中，操作4050的连接可以在第一设备400和第二设备450之间直接进行，或者尽管未示出，也可以用第一LBA 410和第二LBA 460之间的外部实体(例如，外部服务器)间接进行。将参考以下附图描述第一LBA 410和第二LBA 460之间进行连接的方法的细节。
在各种实施例中，在操作4030和4080中，第一SSP 420/第二SSP 470可以生成、处理或验证第一SSP 420/第二SSP 470中所需的数据。
在各种实施例中，在第一SSP 420/第二SSP 470生成、处理或验证第一SSP 420/第二SSP 470中所需的数据的操作(以下称为第四操作)中，每个SSP可以检查捆绑包传送设置。此外，在第四操作中，每个SSP可以生成并使用捆绑包传送码。此外，捆绑包传送设置相关操作和捆绑包传送码相关操作是分离的功能，并且可以这两个功能不全部被执行，这两个功能中只有一个可以被执行，或者这两个功能可以都被执行。即使在这两个功能都被执行的情况下，这两个功能也可以完全分离地执行。
在各种实施例中，在第四操作中，每个SSP可以生成其自己的SSP信息或者验证从另一设备接收的SSP信息。此外，在第四操作中，每个SSP可以生成验证其自身的认证数据，并且验证来自其他设备的认证数据。
在各种实施例中，在第四操作中，每个SSP可以生成或安装捆绑包。
图5示出了根据本公开的一些实施例的“可验证次级平台捆绑包加载器(verifiable secondary platform bundle loader，SPBL)列表(verifiable_SPBL_list)”的配置。
可验证SPBL列表可以由每个SPBL的SSP制造商、由设备制造商、或者由SSP制造商和设备制造商之间的合作来提供。一个SPBL可以使用可验证SPBL列表来执行与另一SPBL的相互认证。
SPBL作为通过使用可验证SPBL列表来执行验证的实体，将被称为SPBL A。参考图5，要由另一SPBL用来验证SPBL A的证书信息(图5的Spbl列中)和要由SPBL A用来验证另一SPBL的证书信息(图5的trustedSpbl列中)可以被包括在可验证SPBL列表中。
在本公开的实施例中，要由另一SPBL用来验证SPBL A的证书信息和要由SPBL A用来验证另一SPBL的证书信息可以：
a)配置有分配给它的捆绑包家族标识符和捆绑包家族管理器标识符(图5的510和530中)，
b)配置有分配给它的捆绑包家族标识符，并且没有分配给它的捆绑包家族管理器标识符(图5的550中)，或者
c)配置为没有分配给它的捆绑包家族标识符和捆绑包家族管理器标识符(图5的570中)。
要由另一SPBL用来验证SPBL A的证书信息可以包括要由另一SPBL用来验证颁发给SPBL A的证书、颁发给SPBL A的证书链以及由SPBL A生成的签名的有效性的证书信息。要由SPBL A用来验证另一SPBL的证书信息可以包括要用来验证由另一SPBL颁发给SPBL A的证书、证书链以及签名的有效性的证书信息。
图6A和图6B示出了根据本公开的一些实施例的“可信SPBL列表(trusted_SPBL_list)”的两种可能配置。
可信SPBL列表可以由每个SPBL的服务提供商、由捆绑包管理服务器、或者由服务提供商和捆绑包管理服务器之间的合作来提供。一个SPBL可以使用所提供的可信SPBL列表来确定另一SPBL是否可信。
图6A示出了根据本公开的一些实施例的“可信SPBL列表(trusted_SPBL_list)”的可能配置。
参考图6A，可信SPBL列表可以包括用于识别特定捆绑包的信息。例如，可信SPBL列表可以包括6010中的捆绑包标识符(spbID)。
可信SPBL列表还可以包括6030中的捆绑包家族标识符(SPB家族ID)和/或6050中的与由6010中的spbID识别的捆绑包相关联的捆绑包家族管理器标识符(SPB家族保管器对象ID)。
可信SPBL列表还可以包括6070中的接收SPBL信息列表，该接收SPBL信息列表被服务提供商和/或捆绑包管理服务器信任以允许发送SPBL向接收SPBL发送由6010中的spbID识别的捆绑包。6070中的可信接收SPBL信息列表可以是：
a)用于识别被服务提供商和/或捆绑包管理服务器信任的Spbl以允许向其发送捆绑包的信息，或者
b)用于认证被服务提供商和/或捆绑包管理服务器信任的Spbl以允许向其发送捆绑包的证书信息。
可信SPBL列表还可以包括6090中的与由6010中的spbID识别的捆绑包相关联的策略。6090中的可能策略的几个示例如下：在设备或Spbl意图将由6010中的spbID识别的捆绑包发送到另一设备或SPBL的情况下，6090中用于确定接收捆绑包的Spbl是否可信的策略可以包括：
a)当接收捆绑包的SPBL被包括在如以上参考图5所述的发送捆绑包的Spbl的可验证SPBL列表中时信任接收捆绑包的SPBL的策略，
b)当接收捆绑包的SPBL包括在可信SPBL列表中时信任接收捆绑包的SPBL的策略，
c)当接收捆绑包的SPBL被包括在可验证SPBL列表和可信SPBL列表两者中时信任接收捆绑包的SPBL的策略，或者
d)当接收捆绑包的SPBL被包括在可验证SPBL列表和可信SPBL列表之一中时信任接收捆绑包的SPBL的策略。
图6B示出了根据本公开的一些实施例的“可信SPBL列表(trusted_SPBL_list)”的另一配置。
参考图6B，可信SPBL列表可以包括被服务提供商和/或捆绑包管理服务器信任以允许发送SPBL向其发送捆绑包的接收SPBL信息列表(在trustedSpbl列中)。图6B的可信接收SPBL信息列表可以对应于图6A的可信接收SPBL信息列表6070，因此将不再重复详细描述。然而，与图6A的6070中的可信接收SPBL信息列表不同，可信接收SPBL信息列表(图6B的trustedSpbl列中)不仅可以应用于特定捆绑包(例如，由图6A的6010中的spbID识别的捆绑包)，还可以应用于任何捆绑包。例如，可以使用图6B的可信接收SPBL信息列表，而不管所发送或接收的捆绑包标识符(SPB ID)如何。然而，如稍后将描述的，图6B的可信接收SPBL信息列表可以在被映射到捆绑包家族标识符(Fid)和/或捆绑包家族管理器标识符(Oid)的同时被使用，或者可以在不考虑(即，不被映射到)捆绑包家族标识符(Fid)和捆绑包家族管理器标识符(Oid)的情况下被使用。
可信SPBL列表还可以包括在确定是否信任接收捆绑包的接收SPBL时要使用的策略(图6B的策略列)。图6B的策略的详细描述可以对应于图6A的6090中的策略，因此将不再重复详细描述。
可信接收SPBL信息列表和策略可以：
a)配置有分配给它的捆绑包家族标识符和捆绑包家族管理器标识符(图6B的6510和6530中)，
b)配置有分配给它的捆绑包家族标识符，并且没有分配给它的捆绑包家族管理器标识符(图6B的6550中)，或者
c)被配置为没有分配给它的捆绑包家族标识符和捆绑包家族管理器标识符(图6B的6570中)。
图7是根据本公开的实施例的用于将捆绑包从一个设备传送到另一设备的程序的概念图。
参考图7，根据各种实施例，设备可以包括至少一个LBA和至少一个SSP。例如，第一设备700可以包括第一LBA 720和第一SSP 710，并且第二设备750可以包括第二LBA 770和第二SSP 760。例如，第一设备700是配备有第一SSP 710并安装有用于控制第一SSP 710的第一LBA 720的设备，并且第二设备750是配备有第二SSP 760并安装有用于控制第二SSP760的第二LBA 770的设备。
在操作7000中，第一设备700的第一SSP 710和第一LBA 720以及第二设备750的第二LBA 770可以执行捆绑包传送所需的准备程序(捆绑包传送准备程序)。捆绑包传送准备程序的详细描述参考图8的描述，这将在后面描述。
在操作7005中，可以执行将捆绑包从第一设备700传送到第二设备750并安装在第二设备750中的程序(捆绑包传送和安装程序)。捆绑包传送和安装准备程序的详细描述参考图9的描述，这将在后面描述。
图8示出了在图7提出的程序中的用于准备捆绑包传送的详细程序。具体地，图8示出了根据本公开的实施例的一个设备向另一设备传送捆绑包所需的准备程序。在说明书中，图8的程序可以被称为捆绑包传送准备程序。
参考图8，根据各种实施例，设备可以包括至少一个LBA和至少一个SSP。例如，第一设备800可以包括第一LBA 820和第一SSP 810，并且第二设备850可以包括第二LBA 8700和第二SSP 860。例如，第一设备800是配备有第一SSP 810并安装有用于控制第一SSP 810的第一LBA 820的设备，并且第二设备850是配备有第二SSP 860并安装有用于控制第二SSP860的第二LBA 870的设备。
在各种实施例中，第一设备800可以具有预先安装的捆绑包，并且还具有与预先安装的捆绑包相关联的元数据。
在各种实施例中，第一设备800可以具有与预先安装的捆绑包相关的捆绑包标识符(SPB ID)、捆绑包家族标识符(SPB家族ID)或捆绑包家族管理器标识符(SPB家族保管器对象ID)中的至少一个。
在各种实施例中，第一设备800可以具有与预先安装的捆绑包相关的捆绑包传送设置。
捆绑包传送设置可以是关于捆绑包是否可在设备之间传送的信息，该信息可以由作为捆绑包的第一提供商的服务提供商、捆绑包管理服务器或者服务提供商和捆绑包管理服务器之间的合作来生成。捆绑包传送设置可以由服务提供商、捆绑包管理服务器或者服务提供商和捆绑包管理服务器之间的合作来更新。可替代地，服务提供商或捆绑包管理服务器当中的至少一个实体可以与该设备合作以更新捆绑包传送设置。何时和/或如何更新可以由服务提供商、捆绑包管理服务器、设备制造商等的策略来确定。
捆绑包传送设置可以可选地包括用于指示是否允许在设备之间传送捆绑包的指示符(或指示)。捆绑包传送设置还可以包括指定当允许在设备之间传送捆绑包时允许传送的所处状况是什么的可选指示符。例如，关于设备之间的哪个连接用于捆绑包传送的信息可以被包括在捆绑包传送设置中。在这种情况下，可能的连接可以是直接的设备到设备连接(例如，诸如NFC、蓝牙、UWB、WiFi直连、LTE设备到设备(D2D)或5G D2D的无线连接，或者通过电缆的有线连接)，或者与位于第一LBA 820和第二LBA 870之间的远程服务器(例如，中继服务器)的长距离连接。
此外，用于在设备之间传送捆绑包的相互认证方法的设置可以被包括在捆绑包传送设置中。例如，为了使将要发送捆绑包的设备认证接收捆绑包的设备，关于是否需要使用从服务提供商和/或捆绑包管理服务器接收的信息(例如，如图6A或图6B所示的可信SPBL列表(trusted_SPBL_list))的附加认证的信息也可以被包括在捆绑包传送设置中。当建立了对附加认证的需求时，服务提供商和/或捆绑包管理服务器可以将与可信设备和/或SSP相关的认证信息提供给将要发送捆绑包的设备，将要发送捆绑包的该设备又可以在通过使用关于接收捆绑包的设备是否被服务提供商和/或捆绑包管理服务器信任的信息来认证接收捆绑包的设备之后发送捆绑包。
在操作8000中，第一LBA 820可以获得要在设备之间传送的捆绑包的信息。可替代地，要在设备之间传送的捆绑包的信息可以被发送到第一LBA820。例如，第一LBA 820可以通过经由第一设备800提供的用户界面(UI)接收用户选择捆绑包的用户输入来获得捆绑包的信息，通过来自远程服务器的推送输入来接收要传送的捆绑包的信息，或者通过访问远程服务器来取得要传送的捆绑包的信息。
此外，在操作8000中，第一LBA 820可以基于捆绑包传送设置来确定是否允许捆绑包在设备之间传送。
此外，在操作8000中，第一LBA 820可以生成捆绑包传送信息。捆绑包传送信息可以包括要传送的捆绑包的捆绑包分类符，诸如捆绑包标识符(SPB ID)、捆绑包家族标识符(SPB家族ID)或捆绑包家族管理器标识符(SPB家族保管器对象ID)。捆绑包传送信息还可以包括指示捆绑包的属性的其他信息(例如，捆绑包的元数据或元数据的一部分)。捆绑包传送信息还可以包括与要传送的捆绑包相关联的捆绑包管理服务器的地址(例如，SPBM地址)。捆绑包传送信息可以包括在操作8025中进行的两个设备之间的连接所需的信息。例如，可以包括两个设备之间的wi-fi连接所需的信息(例如，第一设备800的SSID和/或BSSID、要用于两个设备之间的连接的认证的预先共享的密钥、第一设备800的IP地址、或者要用于两个设备之间的通信的端口号)。
在操作8005中，与在操作8000中选择(或获得)的捆绑包相关的信息可以从第一LBA 820发送到第一SSP 810。例如，与所选择的捆绑包相关的信息可以在选择SPB命令中从第一LBA 820发送到第一SSP 810。从第一LBA 820发送到第一SSP 810的与捆绑包相关的信息可以包括用于识别在操作8000中选择的捆绑包的信息。
在操作8010中，第一SSP 810可以确定是否允许在设备之间传送所请求传送的捆绑包。可以通过基于在操作8005中接收的信息识别所请求传送的捆绑包并检查与识别出的捆绑包相关联的捆绑包传送设置来执行确定是否允许设备之间的传送的过程。
此外，在操作8010中，第一SSP 810可以配置捆绑包传送码。捆绑包传送码是用于指示在设备之间的捆绑包传送程序中传送的捆绑包并且具有用于识别传送的捆绑包的值的代码。第一SSP 810可以绑定捆绑包传送码和要传送的捆绑包的信息。
在操作8015中，对操作8005的响应可以从第一SSP 810发送到第一LBA 820。例如，对操作8005的选择SPB命令的响应可以在操作8015的选择SPB响应中从第一SPB 810发送到第一LBA 820。该响应可以包括如操作8010中所述的捆绑包传送码。
在本公开的实施例中，可以省略前述的操作8005至8015。
在操作8020中，设备之间的捆绑包传送所需的信息可以从第一设备800的第一LBA820发送到第二设备850的第二LBA 870。在这种情况下，从第一LBA 820发送到第二LBA 870的信息可以包括捆绑包传送信息。可替代地，从第一LBA 820发送到第二LBA 870的信息可以包括捆绑包传送码。此外，从第一LBA 820发送到第二LBA 870的信息还可以包括捆绑包家族标识符(SPB家族ID)和/或捆绑包家族管理器标识符(SPB家族保管器对象ID)。此外，从第一LBA 820发送到第二LBA 870的信息还可以包括要在第一LBA 820和第二LBA 870之间建立的连接所需的信息。此外，从第一LBA 820发送到第二LBA 870的信息还可以包括通知将要执行设备之间的捆绑包传送的信息。
在操作8020中从第一LBA 820发送到第二LBA 870的信息可以用各种方法来发送。例如，第一LBA 820可以通过第一设备800的UI向第一设备800的第一用户提供要发送到第二LBA 870的信息。第一用户可以将接收到的信息提供给第二设备850的第二用户。第二用户可以通过第二设备850的UI将接收到的信息输入到第二LBA 870。可替代地，第一LBA 820可以使要发送到第二LBA 870的信息以图像(例如，QR码)的形式显示在第一设备800的屏幕上，并且第二用户可以使用第二设备850来扫描显示在第一设备800的屏幕上的图像，从而将信息发送到第二LBA 870。然而，信息如何从第一LBA 820发送到第二LBA 870不限于此，并且可以被不同地确定。第一用户和第二用户可以指不同的用户或相同的用户。
在操作8025中，可以建立或设置第一LBA 820和第二LBA 870之间的连接。第一LBA820和第二LBA 870可以基于在操作8020中发送到第二LBA 870的信息来建立连接。第一LBA820和第二LBA 870之间的连接可以是直接的设备到设备连接(例如，诸如NFC、蓝牙、UWB、WiFi直连、LTE设备到设备(D2D)或5G D2D的无线连接，或者通过电缆的有线连接)，或者与位于第一LBA 820和第二LBA 870之间的远程服务器(例如，中继服务器)的长距离连接。
操作8025可以作为最终步骤来执行。然而，操作8025是独立于其他操作(即，操作8000、8005、8010和8025)的操作，并且操作8025的执行次序不限于图8所示，并且与其他操作的执行顺序无关。例如，操作8025可以在操作8015和操作8020之间执行，在这种情况下，在操作8020中从第一LBA 820发送到第二LBA 870的信息可以通过在操作8025中建立的连接来发送。
图9示出了在如图7所述的程序中传送和安装捆绑包的程序的细节。具体地，图9示出了根据本公开的实施例的一个设备向另一设备传送捆绑包并且将该捆绑包安装在该另一设备中的程序。在本公开中，图9的程序可以被称为捆绑包传送和安装程序。
参考图9，根据各种实施例，设备可以包括至少一个LBA和至少一个SSP。例如，第一设备900可以包括第一LBA 920和第一SSP 910，并且第二设备950可以包括第二LBA 970和第二SSP 960。例如，第一设备900是配备有第一SSP 910并安装有用于控制第一SSP 910的第一LBA 920的设备，并且第二设备950是配备有第二SSP 960并安装有用于控制第二SSP960的第二LBA 970的设备。
在操作9000中，第二LBA 970可以从第二SSP 960请求SSP信息(SspInfo)。当从第二SSP 960请求SSP信息(SspInfo)时，第二LBA 970可以通知第二SSP 960将要在设备之间执行捆绑包传送。此外，例如，请求的消息可以包括D2D指示符。第二LBA 970可以通过在请求消息中包括D2D指示符或将D2D指示符的值设置为1来通知第二SSP 960将要在设备之间执行捆绑包传送。第二LBA 970可以向第二SSP 960提供关于要在设备之间传送的捆绑包的信息。该信息可以包括捆绑包家族标识符(SPB家族ID)或捆绑包家族管理器标识符(SPB家族保管器对象ID)中的至少一个。
此外，操作9000可以刚好在上面结合图8描述的整个程序之后自动执行，或者可以在接收到外部输入之后执行。在这种情况下，外部输入可以是第二设备的第二用户用来通过由第二设备950提供的UI直接选择要接收的捆绑包的用户输入，或者是从远程服务器输入到第二LBA 970的推送输入。此外，第二LBA 970可以访问远程服务器并且读出关于要接收的捆绑包的信息。
在操作9005中，第二SSP 960可以生成其SSP信息。SSP信息可以包括关于要提供用于捆绑包传送的第二SSP 960的信息。
在这种情况下，SSP信息可以包括用于第二SSP 960在接收捆绑包之前经历的证书协商过程的信息(证书协商信息)。证书协商信息可以包括要由第二SSP 960用来验证另一SSP的证书信息(SenderSpblVerification)和要由另一SSP用来验证第二SSP 960的证书信息(ReceiverSpblVerification)。证书协商信息还可以包括第二SSP 960所支持的密钥协定算法(key agreement algorithm)列表和加密算法列表。第二SSP 960可以生成证书协商信息。
当在操作9000中向第二SSP 960提供了捆绑包家族标识符(SPB家族ID)和/或捆绑包家族管理器标识符(SPB家族保管器对象ID)时，有时证书协商信息可以基于捆绑包家族标识符或捆绑包家族管理器标识符的值来选择，并且SSP信息还可以包括捆绑包家族标识符和捆绑包家族管理器标识符连同证书协商信息。稍后将参考图10详细描述用于基于捆绑包家族标识符或捆绑包家族管理器标识符的值来配置证书协商信息的程序(具体地，用于配置SenderSpblVerification和ReceiverSpblVerification的程序)。
SSP信息还可以包括SSP版本信息，SSP版本信息包括由第二SSP 960中包括的主平台和加载器所支持的多条标准版本信息中的至少一条。
在操作9010中，第二SSP 960可以通过第二LBA 970和第一LBA 920将在操作9005中生成的SSP信息发送到第一SSP 910。
在操作9000至9010中，第二LBA 970可以从第二SSP 960请求SSP信息(SspInfo)，并且第二SSP 960可以生成其SSP信息，然后通过第二LBA 970和第一LBA 920将SSP信息发送到第一SSP 910。然而，在一些实施例中，第二LBA 970可以自己生成SSP信息，然后通过第一LBA 920将SSP信息发送到第一SSP 910。
在操作9015中，第一SSP 910可以检查接收到的SSP信息，并且基于该信息，生成用于认证第一SSP 910的第一设备认证信息(Device1.Auth)。用于生成第一设备认证信息(Device1.Auth)的详细程序如下：
1)检查程序
第一SSP 910可以检查证书信息以基于接收到的“SenderSpblVerification”来验证第一SSP 910，并且选择用于密钥协定的至少一个证书(ssp1.Cert.KA)。可替代地，第一SSP 910可以通过使用接收到的由第二SSP 960支持的密钥协定算法列表来生成要用于密钥协定的非对称加密的公钥“ssp1.ePK.KA”和私钥“ssp1.eSK.KA”的密钥对，并且选择该密钥对的公钥(ssp1.ePK.KA)。此外，第一SSP 910可以基于接收到的“SenderSpblVerification”来检查证书信息以验证第一SSP 910，并且还可以选择用于签名的至少一个证书(ssp1.Cert.DS)。稍后将参考图11详细描述其中第一SSP 910基于“SenderSpblVerification”选择第一SSP 910的证书信息的程序。
第一SSP 910可以基于接收到的“ReceiverSpblVerification”来选择要验证的第二SSP 960的至少一个证书信息，然后用“CiPkIdToBeUsed”来配置与所选择的证书信息对应的信息。稍后将参考图11详细描述其中第一SSP 910基于“ReceiverSpblVerification”选择第二SSP 960的证书信息的程序。
此外，第一SSP 910可以基于接收到的由第二SSP 960支持的加密算法列表来选择要在未来使用的至少一个加密算法，并且用“CryptoToBeUsed”来配置与所选择的加密算法对应的信息。此外，第一SSP 910可以检查接收到的由第二SSP 960中包括的主平台和加载器所支持的标准版本信息列表，以确定在该列表中是否也存在由第一SSP 910所支持的标准版本。
2)用于生成第一设备认证信息的程序
第一设备认证信息(Device1.Auth)可以包括前述的“ssp1.Cert.KA”、“ssp1.ePK.KA”、“CiPkIdToBeUsed”或“CryptoToBeUsed”中的至少一个。第一设备认证信息(Device1.Auth)还可以包括“ssp1.Cert.DS”。第一设备认证信息(Device1.Auth)可以包括与将来要传送的捆绑包相关联的捆绑包家族标识符(SPB家族ID)或捆绑包家族管理器标识符(SPB家族保管器对象ID)中的至少一个。
在这种情况下，第一设备认证信息(Device1.Auth)的部分或全部可以是要通过使用ssp1.Cert.DS进行验证以确保信息完整性的数字签名，并且数字签名数据可以作为第一设备认证信息的一部分被添加。
在操作9020中，第一SSP 910可以通过第一LBA 920将在操作9015中生成的第一设备认证信息(Device1.Auth)发送到第二LBA 970。
在操作9025中，第二LBA 970可以将第一设备认证信息(Device1.Auth)发送到第二SSP 960。第二LBA 970还可以将捆绑包传送码发送到第二SSP 960。第二LBA 970还可以将要接收的捆绑包的捆绑包标识符(SPB ID)发送到第二SSP 960。
在操作9030中，第二SSP 960可以验证接收到的第一设备认证信息(Device1.Auth)。当接收到“ssp1.Cert.KA”时，第二SSP 960可以检查“ssp1.Cert.KA”的签名以确定“ssp1.Cert.KA”的有效性。此外，当接收到“ssp1.ePK.KA”和对应的数字签名时，第二SSP 960可以首先检查ssp1.Cert.DS的有效性，然后基于ssp1.Cert.DS检查数字签名，从而确定接收到的公钥ssp1.ePK.KA的完整性。此外，第二SSP 960可以基于接收到的“CiPkIdToBeUsed”来选择用于签名的证书中的至少一个(ssp2.Cert.DS)来验证第二SSP960。
此外，在操作9030中，第二SSP 960可以生成要用于密钥协定的非对称加密的公钥“ssp2.ePK.KA”和私钥“ssp2.eSK.KA”的密钥对，并且选择密钥对的公钥(ssp2.ePK.KA)。此外，第二SSP 960可以选择ssp1.Cert.KA或ssp1.ePK.KA中包括的用于密钥协定的公钥之一，并且基于所选择的值和ssp2.eSK.KA来生成要用于对将来与第一设备900的通信进行加密的会话密钥ShKey01。ShKey01可能需要是用于接收到的“CryptoToBeUsed”中包括的加密算法的会话密钥。
此外，在操作9030中，第二SSP 960可以生成用于认证第二SSP 960的第二设备认证信息(Device2.Auth)。在这种情况下，第二设备认证信息(Device2.Auth)可以包括“ssp2.Cert.DS”。此外，第二设备认证信息(Device2.Auth)可以包括“ssp2.ePK.KA”。第二设备认证信息(Device2.Auth)还可以包括指示由第二SSP 960创建的当前会话的事务ID。第二设备认证信息(Device2.Auth)还可以包括捆绑包传送码。第二设备认证信息(Device2.Auth)还可以包括期望接收的捆绑包的捆绑包标识符。此外，第二设备认证信息(Device2.Auth)还可以包括第二SSP 960的SSP标识符。此外，第二设备认证信息(Device2.Auth)可以包括与将来要传送的捆绑包相关联的捆绑包家族标识符(SPB家族ID)或捆绑包家族管理器标识符(SPB家族保管器对象ID)中的至少一个。
在这种情况下，第二设备认证信息(Device2.Auth)的部分或全部可以是要基于ssp2.Cert.DS进行验证以确保信息完整性的数字签名，并且数字签名数据可以作为第二设备认证信息的一部分被添加。此外，第二设备认证信息(Device2.Auth)的部分或全部可以用先前生成的会话密钥ShKey01加密。
在操作9035中，第二SSP 960可以通过第二LBA 970和第一LBA 920将在操作9030中生成的第二设备认证信息(Device2.Auth)发送到第一SSP910。在这种情况下，还可以传送捆绑包传送码。
在操作9040中，第一SSP 910可以验证接收到的第二设备认证信息(Device2.Auth)。第一SSP 910可以通过验证接收到ssp2.Cert.DS的签名来验证ssp2.Cert.DS的有效性。此外，第一SSP 910可以检查接收到的捆绑包家族标识符(SPB家族ID)和/或捆绑包家族管理器标识符(SPB家族保管器对象ID)是否是与要由第一SSP 910传送的捆绑包相关联地正确配置的值。特别地，第一SSP 910可以通过检查与接收到的捆绑包标识符相关联的捆绑包传送设置来确定该捆绑包是否是要传送到第二设备的可用捆绑包。此外，第一SSP 910可以基于接收到的捆绑标识符和接收到的第二设备的信息来检查捆绑包是否可以在第二设备中(例如，在第二设备的SSP中)被正常安装和操作。此外，第一SSP910可以存储接收到的事务ID和/或第二SSP 960的SSP ID。此外，第一SSP 910可以将接收到的事务ID或第二SSP 960的SSP ID与当前正在进行的会话或要传送的捆绑包进行绑定。
在验证第二设备认证信息(Device2.Auth)的过程中，当第二设备认证信息(Device2.Auth)包括加密的数据时，第一SSP 910可以基于ssp1.eSK.KA或与第一SSP 910的ssp1.Cert.KA中包括的用于密钥协定的公钥对应的私钥以及接收到的ssp2.ePK.KA来创建会话密钥Shkey01，用创建的会话密钥ShKey01来解码加密的数据，并且执行验证过程。此外，在验证第二设备认证信息(Device2.Auth)的过程中，当第二设备认证信息(Device2.Auth)包括数字签名时，第一SSP 910可以基于“ssp2.Cert.DS”来验证接收到的数字签名的有效性。
此外，在操作9040中，第一SSP 910可以生成要用于密钥协定的非对称加密的公钥“ssp1.bundle.ePK.KA”和私钥“ssp1.bundle.eSK.KA”的密钥对。密钥对“ssp1.bundle.ePK.KA和ssp1.bundle.eSK.KA”可以被配置为具有与在操作9015中生成的“ssp1.ePK.KA和ssp1.eSK.KA”相同的值。可替代地，密钥对“ssp1.bundle.ePK.KA和ssp1.bundle.eSK.KA”可以被配置为具有与“ssp1.Cert.KA中包括的公钥和对应的私钥”相同的值。此外，第一SSP710可以基于ssp1.bundle.eSK.KA和ssp2.ePK.KA创建会话密钥ShKey02。当对于ssp1.bundle.eSK.KA重复使用与ssp1.eSK.KA或ssp1.Cert.KA中包括的公钥对应的私钥时，会话密钥ShKey02的值也可以用之前创建的ShKey01的值来配置。
此外，在操作9040中，第一SSP 910可以配置要传送到第二设备950的捆绑包和/或与该捆绑包相关联的元数据。在这种情况下，第一SSP 910可以基于接收到的捆绑包传送码来识别要由第一SSP 910传送的捆绑包。所配置的捆绑包可以包括“ssp1.Cert.DS”。所配置的捆绑包还可以包括“ssp1.bundle.ePK.KA”。所配置的捆绑包还可以包括用于识别对应的会话的事务ID。此外，所配置的捆绑包还可以包括与要传送的捆绑包相关联的捆绑包标识符(SPB ID)、捆绑包家族标识符(SPB家族ID)或捆绑包家族管理器标识符(SPB家族保管器对象ID)中的至少一个。在各种实施例中，在操作9040中配置的捆绑包(或与该捆绑包相关联的元数据)可以包括捆绑包传送设置。
在各种实施例中，基于ssp1.Cert.DS生成的数字签名数据可以被添加到在操作9040中配置的捆绑包。换句话说，为捆绑包的一些或全部成分生成的数字签名数据可以作为捆绑包的一部分被添加。此外，可以用ShKey02来加密所配置的捆绑包的部分或全部。
在操作9045中，第一SSP 910可以通过第一LBA 920将在操作9040中生成(配置)的捆绑包发送到第二LBA 970。在这种情况下，还可以发送与捆绑包相关联的元数据。此外，还可以发送与捆绑包相关联的捆绑包传送设置。例如，捆绑包传送设置可以以分离的格式(例如，在消息中)进行发送，而不被包括在捆绑包或元数据中。此外，还可以发送可信SPBL列表(trusted_SPBL_list)。
在操作9050中，第二LBA 970和第二SSP 960可以合作以将捆绑包安装在第二设备950中。当发送了元数据时，第二LBA 970或第二SSP 960可以验证元数据中包括的内容。当发送了捆绑包传送设置时，第二LBA 970可以将捆绑包传送设置信息转发给第二SSP 960。当发送了事务ID时，第二LBA 970或第二SSP 960可以检查接收到的事务ID是否与在当前会话中使用的事务ID完全相同。当发送了捆绑包标识符(SPB ID)、捆绑包家族标识符(SPB家族ID)或捆绑包家族管理器标识符(SPB家族保管器对象ID)中的至少一个时，第二LBA 970或第二SSP 960可以确定接收到的标识符信息是否与当前要接收的捆绑包的标识符信息完全相同。当发送了ssp1.Cert.DS时，第二SSP 960可以通过验证ssp1.Cert.DS的有效性来认证第一SSP 910。当接收到的数据包括加密的数据时，第二SSP 960可以基于接收到的ssp1.bundle.ePK.KA和第二SSP 960的ssp2.eSK.KA来创建会话密钥ShKey02，并且用会话密钥解码和验证加密的数据。当数字签名被包括在接收到的数据中时，第二SSP 960可以验证ssp1.Cert.DS，然后基于ssp1.Cert.DS来验证数字签名的有效性。第二LBA 970和第二SSP 960可以基于检查、认证和验证的结果将捆绑包安装在第二设备950中。
图10示出了根据本公开的一些实施例的用于应第二LBA的请求来生成可以由第二设备的第二SSP支持的证书信息的程序的示例。图10可以对应于图9的操作9005的详细程序的实施例。
在图10中，第二设备的第二SSP可以具有关于如图5所示的可验证SPBL列表的信息。
参考图10，在操作10001中，第二SSP可以从第二LBA接收对证书信息的请求。在操作1003中，第二SSP可以确定从第二LBA发送的对证书信息的请求是否包括与特定捆绑包相关的捆绑包家族标识符和捆绑包家族管理器标识符。
当对证书信息的请求包括捆绑包家族标识符和捆绑包家族管理器标识符两者时，第二SSP进行到操作1010，以确定第二SSP是否支持捆绑包家族标识符和捆绑包家族管理器标识符。换句话说，第二SSP可以确定在关于可验证SPBL列表的信息中是否存在为捆绑包家族标识符和捆绑包家族管理器标识符设置的证书信息。例如，参考图5，当从第二LBA输入诸如(FID1，Oid1)的捆绑包家族标识符和捆绑包家族管理器标识符，并且在关于第二SSP所拥有的可验证SPBL列表的信息中存在与(FID1，Oid1)对应的行时，第二SSP可以确定第二SSP支持捆绑包家族标识符和捆绑包家族管理器标识符(FID1，Oid1)。可替代地，当从第二LBA输入诸如(FID21，Oid6)的捆绑包家族标识符和捆绑包家族管理器标识符，并且在关于第二SSP所拥有的可验证SPBL列表的信息中不存在与(FID2，Oid6)对应的行时，第二SSP可以确定第二SSP不支持捆绑包家族标识符和捆绑包家族管理器标识符(FID2，Oid6)，尤其是不支持捆绑包家族管理器标识符(Oid6)。
当在操作10101中在关于第二SSP所拥有的可验证SPBL列表的信息中存在为捆绑包家族标识符和捆绑包家族管理器标识符设置的证书信息时，在操作10102中，第二SSP可以生成包括为捆绑包家族标识符和捆绑包家族管理器标识符设置的证书信息的SSP信息。具体地，第二SSP可以：
a)在与捆绑包家族标识符(家族ID)和捆绑包家族管理器标识符(Oid)对应的行中选择Spbl信息列表，并且基于Spbl信息列表中包括的证书信息来配置ReceiverSpblVerification。
b)在与捆绑包家族标识符(家族ID)和捆绑包家族管理器标识符(Oid)对应的行中选择可信Spbl信息列表，并且基于可信Spbl信息列表中包括的证书信息来配置SenderSpblVerification。
当在操作10101中在关于第二SSP所拥有的可验证SPBL列表的信息中不存在为证书信息请求中包括的捆绑包家族标识符和捆绑包家族管理器标识符的组合设置的证书信息时，在操作10103中，第二SSP可以确定在关于SSP所拥有的可验证SPBL列表的信息中是否存在包括捆绑包家族标识符的证书信息。例如，参考图5，当从第二LBA输入诸如(FID2，Oid6)的捆绑包家族标识符和捆绑包家族管理器标识符时，第二SSP可以确定第二SSP不支持捆绑包家族标识符和捆绑包家族管理器标识符(FID2，Oid6)的组合(确定它特别不支持捆绑包家族管理器标识符Oid6)，并且前进到操作10103。
当在操作10103中在关于第二SSP所拥有的可验证SPBL列表的信息中存在为捆绑包家族标识符设置的证书信息时，在操作10104中，第二SSP可以生成包括为捆绑包家族标识符设置的证书信息的SSP信息。例如，第二SSP可以确定第二SSP仅支持捆绑包家族标识符FID2，并且选择针对(FID2，*)设置的值。具体地，第二SSP可以：
a)在与(捆绑包家族标识符(家族ID)，*)对应的行中选择Spbl信息列表，并且基于Spbl信息列表中包括的证书信息来配置ReceiverSpblVerification。
b)在与(捆绑包家族标识符(家族ID)，*)对应的行中选择可信Spbl信息列表，并且基于可信Spbl信息列表中包括的证书信息来配置SenderSpblVerification。
当在操作10103中，在关于第二SSP所拥有的可验证SPBL列表的信息中不存在为证书信息请求中包括的捆绑包家族标识符设置证书信息时，在操作10105中，第二SSP可以生成包括未分配捆绑包家族标识符和捆绑包家族管理器标识符的证书信息的SSP信息。例如，参考图5，当从第二LBA输入诸如(FID3，OID1)的捆绑包家族标识符和捆绑包家族管理器标识符时，第二SSP可以确定第二SSP甚至不支持捆绑包家族标识符FID3，并且从关于第二SSP所拥有的可验证SPBL列表的信息当中选择针对家族ID和Oid的组合的(*，*)设置的值。第二SSP然后可以使用所选择的值来生成SSP信息。具体地，第二SSP可以：
a)在与(*，*)对应的行中选择Spbl信息列表，并且基于Spbl信息列表中包括的证书信息来配置ReceiverSpblVerification。
b)在与(*，*)对应的行中选择可信Spbl信息列表，并且基于可信Spbl信息列表中包括的证书信息来配置SenderSpblVerification。
当在操作10003中在证书信息请求中不存在捆绑包家族管理器标识符时，在操作10005中，第二SSP可以确定捆绑包家族标识符是否被包括在从第二LBA发送的证书信息请求中。例如，参考图5，当只有FID从第二LBA输入时，第二SSP可以进行到操作10005，因为不存在Oid。
当在操作10005中特定的捆绑包家族标识符被包括在证书信息请求中时，在操作10201中，第二SSP可以确定包括捆绑包家族标识符的证书设置是否存在于关于第二SSP所拥有的可验证SPBL列表的信息中。例如，参考图5，当仅FID2被包括在证书信息请求中时，第二SSP可以确定具有FID2的SSP设置信息(例如图5的530或550)是否存在于关于第二SSP所拥有的可验证SPBL列表的信息中。包括捆绑包家族标识符的证书设置可以指分配了捆绑包家族标识符和捆绑包家族管理器标识符的证书信息，或者分配了捆绑包家族标识符但未分配捆绑包家族管理器标识符的证书信息。
当在关于第二SSP所拥有的可验证SPBL列表的信息中存在包括捆绑包家族标识符的证书设置时，在操作10202中，第二SSP可以通过使用包括捆绑包家族标识符的证书信息来生成SSP信息。具体地，第二SSP可以：
a)在包括捆绑包家族标识符(家族ID)的一行(或多行)中选择Spbl信息列表，并且基于Spbl信息列表中包括的证书信息来配置ReceiverSpblVerification。
a)在包括捆绑包家族标识符(家族ID)的一行(或多行)中选择可信Spbl信息列表，并且基于Spbl信息列表中包括的证书信息来配置SenderSpblVerification。
当在操作10201中不存在包括捆绑包家族标识符的证书设置时，在操作10203中，第二SSP可以生成SSP信息，以包括在关于第二SSP所拥有的可验证SPBL列表的信息中的未分配捆绑包家族标识符和捆绑包家族管理器标识符的证书信息。更具体地，第二SSP可以：
a)在与(*，*)对应的行中选择Spbl信息列表，并且基于Spbl信息列表中包括的证书信息来配置ReceiverSpblVerification。
b)在与(*，*)对应的行中选择可信Spbl信息列表，并且基于可信Spbl信息列表中包括的证书信息来配置SenderSpblVerification。
当在证书信息请求中不能存在捆绑包家族标识符时，例如，当在操作10005中捆绑包家族标识符和捆绑包家族管理器标识符都不被包括在证书信息请求中时，在操作10007中，第二SSP可以生成SSP信息以包括为第二SSP设置的整个证书信息。例如，第二SSP可以生成SSP信息以包括关于如图5所示的可验证SPBL列表的所有信息。
图11示出了根据本公开的一些实施例的程序的示例，在该程序中，第一设备的第一SSP在从第二设备接收到可以支持的证书信息时检查接收到的信息并基于该信息生成用于认证其自身的认证信息。图11可以对应于图9的操作9015的详细程序的实施例。
在图11中，第一设备的第一SSP可以具有关于如图5所述的可验证SPBL列表的信息。此外，第一设备的第一SSP还可以具有如上结合图6A描述的可信SPBL列表信息，或者如上结合图6B描述的可信SPBL列表信息。上面结合图6A或图6B描述的可信SPBL列表信息可能在图9的操作9015之前已经存在于第一设备中，或者可以根据需要在图9的操作9015中获得。稍后将参考图12详细描述其中第一设备获得关于如以上结合图6A或图6B所述的可信SPBL列表的信息的程序。
参考图11，在操作11001中，第一设备的第一SSP从第二设备接收可以支持的证书信息(sspInfo)。
在操作11003中，第一设备的第一SSP可以基于接收到的证书信息的“ReceiverSpblVerification”执行验证过程。验证过程的细节如下：
在操作11100中，第一SSP从接收到的证书信息中提取ReceiverSpblVerification。随后，在操作11105中，第一SSP可以执行以下程序：
1.生成被次级平台捆绑包加载器(SPBL)信任的发送SPBL列表和接收SPBL列表。
第一SSP基于其自身在图8的操作8020中发送的捆绑包家族标识符和/或捆绑包家族管理器标识符信息以及其自身所拥有的如图5所述的可验证SPBL列表信息来选择(多个)Spbl信息列表和(多个)可信Spbl信息列表。第一SSP基于捆绑包家族标识符和/或捆绑包家族管理器标识符信息以及如图5所述的可验证SPBL列表信息来选择(多个)Spbl信息列表和(多个)可信Spbl信息列表的过程可以参考图10，因为该过程对应于关于图10中的第二设备的过程所描述的过程。基于可验证SPBL列表选择的Spbl信息列表被称为发送SPBL列表，并且所选择的可信Spbl信息列表被称为被SPBL信任的接收SPBL列表。
2.生成被次级平台捆绑包管理器(SPBM)信任的接收SPBL列表和/或所选择的策略。
当第一SSP具有如图6B所述的可信SPBL列表信息时，第一SSP基于已经由第一SSP发送的捆绑包家族标识符和/或捆绑包家族管理器标识符以及关于第一SSP所拥有的如图6B所述的可信SPBL列表的信息来选择(多个)可信Spbl信息列表和/或策略。具体地，第一SSP可以根据以下方法中的至少一个来选择(多个)可信Spbl信息列表和/或策略：
a)当第一SSP发送捆绑包家族标识符和/或捆绑包家族管理器标识符时，在包括图6B中对应的家族ID和Oid的行中选择(多个)可信Spbl信息列表和/或策略。
b)当第一SSP仅发送捆绑包家族标识符时，在包括图6B中的家族ID和针对Oid的*的行中选择(多个)可信Spbl信息列表和/或策略。
c)当第一SSP没有发送捆绑包家族标识符和捆绑包家族管理器标识符中的任何一个时，在包括图6B中的家族ID和针对Oid的*的行中选择(多个)可信Spbl信息列表和/或策略。
可替代地，第一SSP可以通过类似于如图10所述的程序而不是程序a)至c)来选择(多个)可信信息列表和/或策略。例如，第一SSP可以以与基于图10中的捆绑包家族标识符和/或捆绑包家族管理器标识符信息以及图5所示的可验证SPBL列表来选择行的相同方法，基于捆绑包家族标识符和/或捆绑包家族管理器标识符信息以及如图6B所述的可信SPBL列表来选择行，然后在所选择的行中选择(多个)可信Spbl信息列表和/或策略。
基于如图6B所述的可信SPBL列表选择的可信Spbl信息列表被称为被SPBM信任的接收SPBL列表，并且这些策略被称为所选择的策略。
当第一SSP具有与要由第一SSP传送的捆绑包(例如，其可以由SPB ID识别)对应的如图6A所述的可信SPBL列表时，第一SSP可以将如图6A所述的可信SPBL列表中包括的可信Spbl信息列表设置为被SPBM信任的接收SPBL列表，并且将如图6A所述的可信SPBL列表中包括的策略设置为所选择的策略。
3.生成可信接收SPBL列表。
第一SSP基于前述的被SPBL信任的接收SPBL列表和/或被SPBM信任的接收SPBL列表和/或所选择的策略来配置可信接收SPBL列表。由第一SSP配置的可信接收SPBL列表的几个可能示例如下：可信接收SPBL列表可以是：
a)与被SPBL信任的接收SPBL列表完全相同，
b)与被SPBM信任的接收SPBL列表完全相同，
c)被SPBL信任的接收SPBL列表和被SPBM信任的接收SPBL列表的交集，或者
d)被SPBL信任的接收SPBL列表和被SPBM信任的接收SPBL列表的并集。
a)至d)中的哪一个将被用作被第一SSP信任的接收SPBL列表可以取决于以下状况来选择，诸如i)第一SSP是否具有关于如图6A或图6B所述的可信SPBL列表的信息，ii)设备和/或SSP制造商的策略是什么，iii)较早提取的所选择的策略是什么，等等。
4.选择CiPkIdToBeUsed。
第一SSP检查在所提取的ReceiverSpblVerification和较早生成的可信接收SPBL列表之间是否存在交集，当存在交集时选择两个列表的公共证书信息，并且使用所选择的信息来配置“CiPkIdToBeUsed”。
在操作11005中，第一设备的第一SSP可以对接收到的除“ReceiverSpblVerification”之外的证书信息执行另一验证过程。特别地，其中，基于“SenderSpblVerification”的验证程序如下。第一SSP检查在接收到的SenderSpblVerification和如上所述发送SPBL列表之间是否存在交集，当存在交集时选择两个列表的公共证书信息，并且选择用于密钥协定的证书和/或与所选择的证书信息对应的签名。由第一SSP基于SspInfo执行的另一验证过程的详细描述可以对应于图9的操作9015中描述的内容。
此外，11005中包括的验证过程和11003的验证过程是分离的验证过程，并且每个操作的验证过程与执行其他操作的顺序无关。
在操作11007中，第一设备的第一SSP生成用于认证自身的认证信息(Device.Auth，即Device1.Auth)。操作11007的细节可以对应于图9的操作9015中描述的内容，因此将省略其详细描述。
图12示出了根据本公开的一些实施例的其中设备1250获得“可信SPBL列表(trusted_SPBL_list)”的程序的示例。“可信SPBL列表(trusted_SPBL_list)”可以由服务提供商、捆绑包管理服务器或者服务提供商和捆绑包管理服务器的合作提供给设备1250。
参考图12，根据各种实施例，设备1250可以包括至少一个LBA和至少一个SSP。例如，设备1250可以包括LBA 1270和SSP 1260。例如，设备1250可以是安装有SSP 1260并且安装有用于控制SSP 1260的LBA 1270的设备。
在各种实施例中，服务器1200可以是由服务提供商操作的服务器、捆绑包管理服务器、由服务提供商和捆绑包管理服务器的合作操作的服务器、或者与服务提供商和/或捆绑包管理服务器联合操作的任意服务器。尽管使用了术语“SPBM”(其是指示服务器1200的服务器的可能示例之一)，但是服务器的类型不限于如上所述的SPBM。
在操作12000中，可以在SPBM 1200和LBA 1270之间建立传输层安全性(transportlayer security，TLS)连接。
在操作12005中，LBA 1270可以从SPBM 1200请求可信SPBL列表(trusted_SPBL_list)。诸如捆绑包标识符(sbpID)、捆绑包家族标识符(FID)、捆绑包家族管理器标识符(OID)等的信息也可以在请求中从LBA 1270发送到SPBM 1200。
在操作12010中，SPBM 1200可以生成可信SPBL列表(trusted_SPBL_list)。可信SPBL列表(trusted_SPBL_list)可以具有预先存储在SPBM 1200中的值，或者应操作12005中的请求而新生成的值。此外，可信SPBL列表(trusted_SPBL_list)可以具有如图6A或图6B所述格式的值。所生成的可信SPBL列表(trusted_SPBL_list)还可以包括由SPBM 1200签名的信息，以确保信息的完整性。
在操作12015中，在操作12010中生成的可信SPBL列表(trusted_SPBL_list)可以从SPBM 1200发送到LBA 1270。
在操作12020中，在操作12010中生成的可信SPBL列表(trusted_SPBL_list)可以从LBA 1270发送到SSP 1260。
在操作12025中，SSP 1260可以验证接收到的可信SPBL列表(trusted_SPBL_list)。验证过程可包括验证在操作12010中生成的签名的有效性。此外，SSP 1260可以存储接收到的可信SPBL列表(trusted_SPBL_list)。
在操作12030中，SSP 1260可以将关于接收到的可信SPBL列表(trusted_SPBL_list)的结果发送到LBA 1270。例如，SSP 1260可以向LBA 1270发送验证和/或接收的成功或失败。
图13是示出根据本公开的实施例的设备的配置的图。
如图13所示，设备可以包括收发器1310和至少一个处理器1320。设备还可以包括SSP 1330。例如，SSP 1330可以被插入设备或者嵌入在设备中。至少一个处理器1320可以被称为控制器。然而，设备的配置不限于图13，并且可以包括比图13所示更多或更少的组件。在一些实施例中，收发器1310、至少一个处理器1320和存储器(未示出)可以在单个芯片中实施。此外，在SSP 1330被嵌入的情况下，它可以以包括SSP 1330的单个芯片的形式来实施。
在各种实施例中，根据本公开的各种实施例，收发器1310可以向另一设备或外部服务器的收发器发送信号、信息、数据等，以及从另一设备或外部服务器的收发器接收信号、信息、数据等。收发器1310可以包括用于对要发送的信号的频率进行上变频并放大该信号的RF发送器，以及用于低噪放大接收到的信号并对接收到的信号的频率进行下变频的RF接收器。这仅仅是收发器1310的实施例，并且收发器1310的元件不限于RF发送器和RF接收器。此外，收发器1310可以在无线信道上接收信号并将该信号输出到至少一个处理器1320，或者在无线信道上发送从至少一个处理器1320输出的信号。
在各种实施例中，收发器1310可以向另一设备或外部服务器的收发器发送或从另一设备或外部服务器的收发器接收关于另一设备中包括的SSP的信息、用于认证另一设备的认证信息、用于认证其自身的认证信息、捆绑包传送码、捆绑包传送设置、捆绑包、对可信SPBL列表(trusted_SPBL_list)的请求信息、可信SPBL列表(trusted_SPBL_list)等。
与此同时，至少一个处理器1320是用于总体上控制设备的元件。如上所述，在本公开的各种实施例中，至少一个处理器1320可以控制设备的总体操作。
SSP 1330可以包括用于安装和控制捆绑包的处理器或控制器，或者可以具有安装在其中的应用。
在各种实施例中，SSP 1330中的至少一个处理器或控制器可以通过检查捆绑包传送设置来确定是否传送特定捆绑包。
在各种实施例中，SSP中的至少一个处理器或控制器可以生成捆绑包传送码，以控制特定捆绑包的传送过程。
在各种实施例中，SSP中的至少一个处理器或控制器可以生成其SSP信息，并且检查和验证从外部接收的另一SSP的SSP信息。
在各种实施例中，SSP中的至少一个处理器或控制器可以生成用于验证其自身的认证信息，并且验证从外部接收的另一SSP的认证信息。
在各种实施例中，SSP 1330可以生成捆绑包，并且与一个或多个处理器1320合作以安装捆绑包。此外，SSP 1330可以管理捆绑包。
在各种实施例中，SSP 1330可以验证和/或存储可信SPBL列表(trusted_SPBL_list)。
在各种实施例中，SSP 1330可以在处理器1320的控制下进行操作。可替代地，SSP1330可以包括用于安装和控制捆绑包的处理器或控制器，或者可以具有安装在其中的应用。应用的部分或全部可以被安装在SSP 1330或存储器(未示出)中。
设备还可以包括存储器(未示出)，并且存储用于设备的操作的基本程序、应用程序、类似设置信息的数据等。此外，存储器可以包括闪存型、硬盘型、多媒体卡微型或卡型的存储器(例如，SD或XD存储器)、磁存储器、磁盘、光盘、随机存取存储器(RAM)、静态RAM(SRAM)、只读存储器(ROM)、可编程ROM(PROM)或电可擦除可编程ROM(EEPROM)中的至少一种存储介质。此外，处理器1320可以使用存储在存储器中的各种程序、内容、数据等来执行各种操作。
图14是示出了根据本公开的实施例的服务器的配置的图。服务器可以被理解为具有与图12所述的服务器相同的概念。如上在图12中描述的，服务器可以是由服务提供商操作的服务器、捆绑包管理服务器、由服务提供商和捆绑包管理服务器的合作操作的服务器、或者与服务提供商和/或捆绑包管理服务器联合操作的任意服务器。尽管使用了术语“捆绑包管理服务器”(其是指示服务器的服务器的可能示例之一)，但是服务器的类型不限于如上所述的捆绑包管理服务器。
在一些实施例中，捆绑包管理服务器可以包括收发器1410和至少一个处理器1420。然而，捆绑包管理服务器的配置不限于图14，并且可以包括比图14所示更多或更少的组件。在一些实施例中，收发器1410、至少一个处理器1420和存储器(未示出)可以在单个芯片中实施。
根据本公开的各种实施例，在各种实施例中，收发器1410可以向设备发送信号、信息、数据等，以及从设备接收信号、信息、数据等。例如，收发器1410可以从设备接收捆绑包标识符、特定捆绑包家族标识符或捆绑包家族管理器标识符，或者向设备发送可信SPBL列表(trusted_SPBL_list)。
收发器1410可以包括用于对要发送的信号的频率进行上变频并放大该信号的RF发送器和用于低噪放大接收到的信号并对接收到的信号的频率进行下变频的RF接收器。这仅仅是收发器1410的实施例，并且收发器1410的元件不限于RF发送器和RF接收器。此外，收发器1410可以在无线信道上接收信号并将该信号输出到至少一个处理器1420，或者在无线信道上发送从至少一个处理器1420输出的信号。
与此同时，至少一个处理器1420是用于总体上控制捆绑包管理服务器的元件。如上所述，在本公开的各种实施例中，处理器1420可以控制捆绑包管理服务器的总体操作。至少一个处理器1420可以被称为控制器。
在一些实施例中，至少一个处理器1420可以配置可信SPBL列表(trusted_SPBL_list)。
捆绑包管理服务器还可以包括存储器(未示出)，并且存储用于捆绑包管理服务器的操作的基本程序、应用程序、类似设置信息的数据等。此外，存储器可以包括闪存型、硬盘型、多媒体卡微型或卡型的存储器(例如，SD或XD存储器)、磁存储器、磁盘、光盘、RAM、SRAM、ROM、PROM或EEPROM中的至少一种存储介质。此外，处理器1420可以使用存储在存储器中的各种程序、内容、数据等来执行各种操作。
图15示出了根据本公开的实施例的用于两个设备之间的配置文件传送的两个设备的交互方法的示例。
如图15所示，第一设备1500和第二设备1520可以分别配备有第一eSIM 1503和第二eSIM 1523，并且配置文件(未示出)可以被安装在第一eSIM 1503和第二eSIM 1523中的每一个中。此外，第一LPA 1501和第二LPA 1521可以被分别安装在第一设备1500和第二设备1520中。第一eSIM 1503和第二eSIM 1523可以分别由第一LPA 1501和第二LPA 1521控制。第一用户1505和第二用户1525可以分别通过第一LPA 150和第二LPA 1521控制安装在每个设备的eSIM(第一eSIM 1503和第二eSIM 1523)中的配置文件。第一用户1505和第二用户1525可以是相同的。此外，第一LPA 1501和第二LPA 1521可以彼此连接以进行通信。LPA之间的可用连接方法将参考附图的描述，这将在后面描述。
移动运营商1560可以连接到第一RSP服务器1540和第二RSP服务器1580，第一设备1500的第一LPA 1501可以连接到第一RSP服务器1540，并且第二设备1520的第二LPA 1521可以连接到第二RSP服务器1580。第一RSP服务器1540和第二RSP服务器1580可以是相同的或不同的。当一个或多个运营商服务器被包括在配置中时，每个运营商服务器可以连接到每个RSP服务器，并且至少一个运营商服务器可以连接到相同的RSP服务器。此外，为了方便起见，第一RSP服务器1540和第二RSP服务器1580在图15中被示为被配置为分离的服务器。然而，取决于实施方式和实施例，一个或多个配置文件提供服务器(SM-DP+)可以被包括在服务器的配置中，并且帮助在特定配置文件提供服务器和设备之间建立连接的一个或多个开放中继服务器(SM-DS)也可以被包括在服务器的配置中。在下面的附图中，服务器的各种配置也可以被简单地表示为单个RSP服务器。
图16示出了根据本公开的一些实施例的“可信CI列表(trusted_CI_list)”的配置。
存储在设备中的可信CI列表1600可以是被设备制造商和/或eUICC制造商信任的eUICC列表。可替代地，存储在设备中的可信CI列表1600可以是可以用于验证被设备制造商和/或eUICC制造商信任的eUICC的信息列表。具体地，存储在设备中的可信CI列表1600中包括的设备的可信CI信息可以是
a)可以识别被设备制造商和/或eUICC制造商信任的eUICC的信息，以及
b)可以验证被设备制造商和/或eUICC制造商信任的eUICC的证书信息。例如，该信息可以是要验证其可信度的eUICC的证书链中的最高根证书的公钥信息。可替代地，该信息可以是要验证其可信度的eUICC的证书链中最高根证书的公钥ID(PKID)信息。
存储在设备中的可信CI列表1600可以是由设备制造商和/或eUICC制造商生成和/或提供的信息。
存储在设备中的可信CI列表1600可以在执行配置文件传送之前被存储在设备中。存储在设备中的可信CI列表1600可以在执行配置文件传送所需的时间点从设备制造商和/或eUICC制造商获得。
从服务器提供的可信CI列表1650可以指被移动运营商和/或RSP服务器信任的eUICC的列表。可替代地，从服务器提供的可信CI列表1650可以是可用于验证被移动运营商和/或RSP服务器信任的eUICC的信息列表。具体地，从服务器提供的可信CI列表1650中包括的服务器的可信CI信息可以是
a)可以识别被移动运营商和/或RSP服务器信任的eUICC的信息，以及
b)可以验证被移动运营商和/或RSP服务器信任的eUICC的证书信息。例如，该信息可以是要验证其可信度的eUICC的证书链中的最高根证书的公钥信息。可替代地，该信息可以是要验证其可信度的eUICC的证书链中的最高根证书的公钥ID(PKID)信息。
从服务器提供的可信CI列表1650可以是由移动运营商和/或RSP服务器生成和/或提供的信息。
从服务器提供的可信CI列表1650可以在执行配置文件传送之前被存储在设备中。从服务器提供的可信CI列表1650可以在执行配置文件传送所需的时间点从移动运营商和/或RSP服务器获得。
图17示出了根据本公开的实施例的一个设备向另一设备发送配置文件的程序。
尽管未在图17中示出，但是第一设备1700和第二设备1750可以各自包括如图15所示的eUICC和LPA。虽然未在图17中示出，但是第一设备1700可以具有配置文件传送设置。在各种实施例中，配置文件传送设置可以是关于设备之间的配置文件传送是否可能的策略，其可以由移动运营商或RSP服务器生成，或者甚至由移动运营商和RSP服务器的前述合作生成。在各种实施例中，设备中的配置文件传送设置可以由移动运营商或RSP服务器来更新，或者甚至由移动运营商和RSP服务器的前述合作来更新。可替代地，移动运营商或RSP服务器中的至少一个实体可以与该设备合作来更新配置文件传送设置。何时和/或如何更新配置文件传送设置可以由移动运营商、RSP服务器、设备制造商等的策略来确定。
配置文件传送设置可以包括用于指示是否允许在设备之间传送配置文件的指示符(或指示)。配置文件传送设置还可以包括用于指定当允许传送时在设备之间传送配置文件的所处状况是什么的可选指示符。例如，为了使将要发送配置文件的设备认证接收配置文件的设备，是否基于从移动运营商和/或RSP服务器接收的信息(例如，从服务器提供的如图16所示的可信CI列表)来执行认证也可以被包括在配置文件传送设置中。具体地，移动运营商和/或RSP服务器可以提供与被它们自己信任和/或验证的设备和/或eUICC相关的认证信息，并且将要发送配置文件的设备可以基于所提供的认证信息来认证接收配置文件的设备和/或eUICC是否被移动运营商和/或RSP服务器信任。
此外，配置文件传送设置还可以包括至少一条签名信息，该签名信息是基于(或通过使用)指示是否允许在设备之间传送配置文件的信息和/或关于当允许在设备之间传送配置文件时允许传送所处状况是什么的信息而生成的。至少一条签名信息可以是由例如RSP服务器、移动运营商、设备制造商、eUICC或eUICC制造商中的至少一个实体生成的信息。此外，至少一条签名信息还可以包括关于例如RSP服务器、移动运营商、设备制造商、eUICC或eUICC制造商中的至少一个(即，一些或全部)的认证信息。此外，配置文件传送设置还可以包括如上所述还包括的至少一条认证信息中的至少一个(即，一些或全部)的RSP服务器的签名信息。
参考图17，在操作17000中，可以选择(或确定)要发送的配置文件。该选择或确定可以通过其中用户通过由第一设备1700提供的UI亲自选择配置文件的程序来执行，配置文件可以通过来自远程服务器的推送输入被输入到第一设备1700，或者第一设备1700可以通过访问远程服务器来读出对应的信息。当第一设备1700为用户提供UI时，可以提供安装在设备中的所有配置文件的列表，或者可以通过UI提供当前可用于传送的配置文件的列表。当提供不可用于传送的配置文件的列表时，可以在UI中进一步呈现指示列表中所示配置文件的传送可用性的附加信息。此外，除了前述配置文件列表之外，配置文件的信息或配置文件的传送策略的信息可以可选地另外通过UI提供。
在操作17000中，第一设备1700可以通过检查配置文件传送设置来确定(或识别)配置文件是否可传送。基于确定或识别被选择(或确定)为要传送的配置文件是否可传送的结果，可以执行用于将所选择(或确定)的配置文件发送到第二设备1750的程序。例如，第一设备1700可以基于确定或识别配置文件是否可传送的结果来执行操作17005。此外，为了使第一设备1700在检查配置文件传送设置之后认证第二设备1750，第一设备1700可以基于从移动运营商和/或RSP服务器接收的信息(例如，从服务器提供的如图16所示的可信CI列表)来确定是否执行认证。
在操作17005中，可以建立第一设备1700和第二设备1750之间的连接。例如，第一设备1700和第二设备1750之间的连接可以是无线通信连接。第一设备1700和第二设备1750之间的连接可以是直接的设备到设备连接(例如，NFC、蓝牙、UWB、WiFi直连、LTE设备到设备(D2D)或5G D2D)，或者与位于第一设备1700和第二设备1750之间的远程服务器(例如，中继服务器)的长距离连接。
在操作17010中，第二设备1750可以发送其eUICC信息(eUICC2.Info1)。eUICC2.Info1可以包括由第二设备的eUICC生成的任意字符串(eUICC2.Challenge)。eUICC2.Info1可以包括第二设备的eUICC所支持的版本的信息。eUICC2.Info1可以包括可用于验证第二设备的eUICC的认证信息。eUICC2.Info1可以包括可用于验证另一设备的eUICC的认证信息。
在操作17015中，第一设备1700可以检查接收到的eUICC2.Info1。第一设备1700可以使用接收到的eUICC2.Info1以确定在第二设备所支持的eUICC版本当中是否存在第一设备1700所支持的版本。第一设备1700可以使用接收到的eUICC2.Info1选择用于验证第一设备1700的证书eUICC1.Cert。第一设备1700可以使用接收到的eUICC2.Info1来选择要由第二设备1750使用的证书信息。
在这种情况下，其中第一设备1700使用接收到的eUICC2.Info1选择要由第二设备1750使用的证书信息的详细程序如下：
第一设备1700可以具有存储在设备中的如图16所述的可信CI列表。此外，第一设备1700可以具有从服务器提供的如图16所示的可信CI列表。第一设备1700可以使用存储在设备中的可信CI列表和从服务器提供的可信CI列表来推导出可信CI列表。可信CI列表可以是
a)与存储在设备中的可信CI列表完全相同，
b)与从设备提供的可信CI列表完全相同，
c)存储在设备中的可信CI列表和从服务器提供的可信CI列表的交集，或者
d)存储在设备中的可信CI列表和从服务器提供的可信CI列表的并集。
将使用a)至d)中的哪一个可以由RSP服务器、移动运营商、设备制造商和eUICC制造商当中的至少一个实体的策略来确定。此外，当配置文件传送设置指示需要基于从移动运营商和/或RSP服务器接收的信息来执行认证时，可能需要使用如b)至d)中从服务器提供的可信CI列表。
第一设备1700可以确定在推导出的可信CI列表和eUICC2.Info1中包括的要用于验证第二设备的eUICC的证书信息之间是否存在交集。第一设备1700可以选择存在于推导出的可信CI列表和eUICC2.Info1中包括的要用于验证第二设备的eUICC的证书信息的交集中的部分或全部信息，并且将所选择的信息设置为要由第二设备1750使用的证书信息。
在操作17015中，第一设备1700可以生成第一设备认证信息(Device1.Auth)。第一设备认证信息(Device1.Auth)可以包括eUICC2.Info1的部分或全部。例如，第一设备认证信息(Device1.Auth)可以包括由第一设备1700接收的eUICC2.Challenge。第一设备认证信息(Device1.Auth)可以包括由第一设备的eUICC生成的任意字符串(eUICC1.Challenge)。
第一设备认证信息(Device1.Auth)可以包括要由第二设备1750使用的认证信息。第一设备认证信息(Device1.Auth)可以包括与用于验证第一设备1700自身的证书eUICC1.Cert相关的认证链信息。
前述第一设备认证信息(Device1.Auth)的部分或全部可以通过使用第一设备的证书eUICC1.Cert进行电子签名，并且电子签名的数据可以作为第一设备认证信息(Device1.Auth)的一部分被包括在内。
在操作17020中，第一设备1700可以将第一设备认证信息(Device1.Auth)发送到第二设备1750。
在操作17025中，第二设备1750可以验证接收到的第一设备认证信息(Device1.Auth)。第二设备1750可以检查第一设备认证信息(Device1.Auth)中包括的eUICC1.Cert的有效性，并且可以基于eUICC1.Cert来进一步检查第一设备认证信息(Device1.Auth)中包括的签名的有效性。第二设备1750可以检查第一设备认证信息(Device1.Auth)中包括的eUICC2.Challenge的值是否与在操作17010中由第二设备1750发送的eUICC2.Challenge的值相同。例如，当eUICC1.Cert有效时，第一设备认证信息Device1.Auth中包括的签名是有效的，并且eUICC2.Challenge的值是相同的，验证可以成功。
基于验证的结果(例如，验证成功)，第二设备1750可以生成第二设备认证信息(Device2.Auth)。第二设备认证信息(Device2.Auth)可以包括Device1.Auth的部分或全部。例如，第二设备认证信息(Device2.Auth)可以包括由第二设备1750接收的eUICC1.Challenge。第二设备认证信息(Device2.Auth)可以包括信息eUICC2.Info2，eUICC2.Info2是用于安装在第二设备中的eUICC的资格检查的信息。eUICC2.Info2可以是用于确定稍后将从第一设备1700接收的配置文件是否可以在第二设备1750的eUICC中正常安装和操作的信息。例如，eUICC2.Info2可以包括配备在第二设备1750中的eUICC的硬件和/或软件信息。
第二设备认证信息(Device2.Auth)可以包括与用于验证第二设备1750自身的证书eUICC2.Cert相关的认证链信息。
前述第二设备认证信息(Device2.Auth)的部分或全部可以通过使用第二设备的证书eUICC2.Cert进行电子签名，并且电子签名的数据可以作为第二设备认证信息(Device2.Auth)的一部分被包括在内。
在操作17030中，第二设备1750可以将第二设备认证信息(Device2.Auth)发送到第一设备1700。
在操作17035中，第一设备1700可以验证接收到的第二设备认证信息(Device2.Auth)。第一设备1700可以检查第二设备认证信息(Device2.Auth)中包括的eUICC2.Cert的有效性，并且可以基于eUICC2.Cert来检查第二设备认证信息(Device2.Auth)中包括的签名的有效性。第一设备1700可以检查第二设备认证信息Device2.Auth中包括的eUICC1.Challenge的值是否与在操作17020中由第一设备1700自身发送的eUICC1.Challenge的值相同。例如，当eUICC2.Cert有效时，第二设备认证信息Device2.Auth中包括的签名是有效的，并且eUICC1.Challenge的值是相同的，验证可以成功。
基于验证的结果(例如，当验证成功时)，第一设备1700可以通过检查第二设备认证信息Device2.Auth中包括的用于eUICC的资格检查的信息eUICC2.Info2，确定要由第一设备1700自身发送的配置文件是否可以在第二设备1750的eUICC中正常安装和操作。
基于操作17035中的确定的结果，在操作17040中，第一设备1700可以将配置文件包发送到第二设备1750。第二设备1750可以安装接收到的配置文件包。
图18示出了根据本公开的一些实施例的第一设备的操作。
参考图18，在操作1810中，根据本公开的实施例的第一设备可以在安装在第一设备中的配置文件当中确定要发送到第二设备的配置文件。
在操作1820中，第一设备可以基于用于与第二设备的通信的连接从第二设备接收第二设备的第二eUICC信息。
在操作1830中，第一设备可以基于第二eUICC信息生成第一设备的认证信息。
在操作1840中，第一设备的认证信息可以被发送到第二设备。
在操作1850中，第一设备可以从第二设备接收第二设备的认证信息，作为对第一设备的认证信息的响应。
在操作1860中，第一设备可以验证第二设备的认证信息。
在操作1870中，第一设备可以基于验证的结果将针对配置文件的配置文件包发送到第二设备。
图19示出了根据本公开的一些实施例的第二设备的操作。
参考图19，在操作1910中，根据本公开的实施例的第二设备可以基于用于与第一设备的通信的连接将第二设备的eUICC信息发送到第一设备。
在操作1920中，第二设备可以从第一设备接收第一设备的认证信息，作为对eUICC信息的响应。
在操作1930中，第二设备可以验证第一设备的认证信息。
在操作1940中，第二设备可以基于验证的结果生成第二设备的认证信息。
在操作1950中，第二设备可以将第二设备的认证信息发送到第一设备。
在操作1960中，第二设备可以从第一设备接收配置文件包，作为对第二设备的认证信息的响应。
图20是示出根据本公开的一些实施例的设备的配置的图。
参考图20，设备可以包括收发器2010、处理器2020和eUICC 2030。在本公开中，前述设备可以对应于将参考图20描述的设备。例如，结合图15至图19提及的第一设备和第二设备可以各自包括如图20所示的设备的组件。
然而，设备的配置不限于图20，并且可以包括比图20所示更多或更少的组件。在一些实施例中，收发器2010、处理器2020和eUICC 2030可以在单个芯片中实施。此外，设备可以另外包括存储器，并且处理器2020可以配置有至少一个处理器。
在各种实施例中，根据本公开的各种实施例，收发器2010可以向另一设备或外部服务器的收发器发送信号、信息、数据等，以及从另一设备或外部服务器的收发器接收信号、信息、数据等。收发器2010可以包括用于对要发送的信号的频率进行上变频并放大该信号的RF发送器和用于低噪放大接收到的信号并对接收到的信号的频率进行下变频的RF接收器。这仅仅是收发器2010的实施例，并且收发器2010的元件不限于RF发送器和RF接收器。此外，收发器2010可以在无线信道上接收信号并将该信号输出到处理器2020，并且在无线信道上发送从处理器2020输出的信号。
与此同时，处理器2020是用于总体上控制设备的元件。如上所述，在本公开的各种实施例中，处理器2020可以控制设备的总体操作。
设备还可以包括存储器(未示出)，并且存储用于设备的操作的基本程序、应用程序、类似设置信息的数据等。此外，存储器可以包括闪存型、硬盘型、多媒体卡微型或卡型的存储器(例如，SD或XD存储器)、磁存储器、磁盘、光盘、RAM、SRAM、ROM、PROM或EEPROM中的至少一种存储介质。此外，处理器2020可以使用存储在存储器中的各种程序、内容、数据等来执行各种操作。
图21是示出根据本公开的一些实施例的服务器的配置的图。
参考图21，服务器可以包括收发器2110和处理器2120。在本公开中，前述服务器可以对应于将参考图21描述的服务器。例如，结合图15至图19提及的服务器(例如，运营商服务器、RSP服务器、SM-DP+、SM-DS等)可以各自包括如图21所示的服务器的组件。
然而，服务器的配置不限于图21，并且可以包括比图21所示更多或更少的组件。在一些实施例中，收发器2110和处理器2020可以在单个芯片中实施。此外，服务器可以另外包括存储器，并且处理器2120可以配置有至少一个处理器。
在各种实施例中，根据本公开的各种实施例，收发器2110可以向设备发送信号、信息、数据等，以及从设备接收信号、信息、数据等。收发器2110可以包括用于对要发送的信号的频率进行上变频并放大该信号的RF发送器，以及用于低噪放大接收到的信号并对接收到的信号的频率进行下变频的RF接收器。这仅仅是收发器2110的实施例，并且收发器2110的元件不限于RF发送器和RF接收器。此外，收发器2110可以在无线信道上接收信号并将该信号输出到处理器2120，并且在无线信道上发送从处理器2120输出的信号。
与此同时，至少一个处理器2120是用于总体上控制服务器的元件。如上所述，在本公开的各种实施例中，处理器2120可以控制服务器的总体操作。至少一个处理器2120可以被称为控制器。
服务器还可以包括存储器(未示出)，并且存储用于服务器的操作的基本程序、应用程序、类似设置信息的数据等。此外，存储器可以包括闪存型、硬盘型、多媒体卡微型或卡型的存储器(例如，SD或XD存储器)、磁存储器、磁盘、光盘、RAM、SRAM、ROM、PROM或EEPROM中的至少一种存储介质。此外，处理器2120可以使用存储在存储器中的各种程序、内容、数据等来执行各种操作。
图22是根据本公开的一些实施例的一个设备向另一设备传送配置文件的程序的概念图。
根据各种实施例，设备可以包括至少一个LPA和至少一个eSIM。例如，参考图22，第一设备2210可以包括第一LPA 2230和第一eSIM 2220，并且第二设备2260可以包括第二LPA2280和第二eSIM 2270。
在操作22000中，第一设备2210的第一LPA 2230和第二设备2260的第二LPA 2270可以执行配置文件传送所需的准备程序(配置文件传送准备程序)。详细程序参考图23的描述，这将在后面描述。
在操作22005中，可以执行第一设备2210和第二设备2260之间的相互认证程序。详细程序参考图24的描述，这将在后面描述。
在操作22010中，可以执行将配置文件从第一设备2210传送到第二设备2260并安装在第二设备中的程序。详细程序参考图25的描述，这将在后面描述。
图23示出了根据本公开的一些实施例的图22中提出的程序中的配置文件传送准备程序的细节。
参考图23，设备可以包括至少一个LPA和至少一个eSIM。例如，第一设备2310可以包括第一LPA 2330和第一eSIM 2320，并且第二设备2360可以包括第二LPA 2380和第二eSIM 2370。
在各种实施例中，第一设备2310可以具有预先安装的配置文件，还有与预先安装的配置文件相关联的元数据。在各种实施例中，第一设备可以具有与预先安装的配置文件相关的配置文件分类符。
在各种实施例中，第一设备2310还可以具有与预先安装的配置文件相关的配置文件传送设置。
配置文件传送设置可以包括用于指示是否允许在设备之间传送配置文件的指示符(或指示)。
此外，用于在设备之间传送配置文件的相互认证方法的设置(例如，指示该设置的设置值)可以被包括在配置文件传送设置中。例如，为了使将要发送配置文件的设备认证接收配置文件的设备，是否基于从移动运营商和/或RSP服务器接收的信息(例如，从服务器提供的如图16所示可信CI列表)执行认证也可以被包括在配置文件传送设置中。当建立了对附加认证的需求时，移动运营商和/或RSP服务器可以向将要发送配置文件的设备提供与可信设备和/或eSIM相关的认证信息，该将要发送配置文件的设备又可以在基于关于接收配置文件的设备是否被移动运营商和/或RSP服务器信任的信息认证接收配置文件的设备之后发送配置文件。
前述配置文件传送设置中包括的各种因子或设置值可以由RSP服务器、移动运营商、设备制造商、eUICC或eUICC制造商当中的至少一个实体进行电子签名。电子签名值可以作为配置文件传送设置的一部分或者与配置文件传送设置一起存储在第一设备2310中。
在操作23000中，第一LPA 2330可以获得要传送的配置文件的信息。可替代地，要传送的配置文件的信息可以被发送到第一LPA 2330。例如，第一LPA 2330可以通过经由第一设备2310提供的UI接收用户选择配置文件的用户输入来获得要传送的配置文件的信息，通过来自远程服务器的推送输入来接收要传送的配置文件的信息，或者通过访问远程服务器来读出要传送的配置文件的信息。
在操作23005中，第一LPA 2330可以基于配置文件传送设置来确定配置文件是否可在设备之间传送。
在操作23010中，第一LPA 2230可以生成配置文件传送码。配置文件传送码可以包括要传送的配置文件的配置文件分类符。此外，配置文件传送码可以包括与要传送的配置文件相关的RSP服务器的地址。配置文件传送码还可以包括指示配置文件的属性的其他信息(例如，配置文件的元数据或元数据的一部分)。配置文件传送码可以包括在操作23020中进行的两个设备之间的连接所需的信息。例如，两个设备之间的wi-fi连接所需的信息(例如，第二设备2360的SSID和/或BSSID、要用于对两个设备之间的连接的认证的预先共享的密钥、第二设备2360的IP地址、或者要用于两个设备之间的通信的端口号)可以被包括在配置文件传送码中。
在操作23015中，在操作23010中生成的配置文件传送码可以从第一LPA 2330发送到第二LPA 2380。可以用各种方法发送配置文件传送码。
例如，第一LPA 2330可以通过第一设备的UI向第一设备的第一用户提供要发送到第二LPA 2380的信息。第一用户可以将接收到的信息提供给第二设备的第二用户。第二用户可以通过第二设备的UI将接收的信息输入到第二LPA。
可替代地，第一LPA 2330可以使要发送到第二LPA 2380的信息以图像(例如，QR码)的形式显示在第一设备的屏幕上，并且第二用户可以使用第二设备来扫描显示在第一设备的屏幕上的图像，从而将该信息发送到第二LPA 2380。
可替代地，第一LPA 2330可以在第一LPA 2330和第二LPA 2380之间建立连接，并且通过使用建立的连接发送要发送的信息。在第一LPA 2330和第二LPA 2380之间建立的连接可以是直接的设备到设备连接(例如，诸如NFC、蓝牙、UWB、WiFi直连、LTE设备到设备(D2D)或5G D2D的无线连接，或者通过电缆的有线连接)，或者与位于第一LPA 2330和第二LPA 2380之间的远程服务器(例如，中继服务器)的长距离连接。
在操作23020中，可以建立或设置第一LPA 2330和第二LPA 2380之间的连接。当在操作23015中发送连接所需的信息时，第一LPA 2330和第二LPA 2380可以基于该信息建立连接。第一LPA 2330和第二LPA 2380之间的连接可以是直接的设备到设备连接(例如，诸如NFC、蓝牙、UWB、WiFi直连、LTE设备到设备(D2D)或5G D2D的无线连接，或者通过电缆的有线连接)，或者与位于第一LPA 2330和第二LPA 2380之间的远程服务器(例如，中继服务器)的长距离连接。
图24示出了根据本公开的一些实施例的图22中提出的程序中的第一设备2410和第二设备2460之间的相互认证程序的细节。
参考图24，设备可以包括至少一个LPA和至少一个eSIM。例如，第一设备2410可以包括第一LPA 2430和第一eSIM 2420，并且第二设备2460可以包括第二LPA 2480和第二eSIM 2470。
在操作24000中，第二LPA 2480可以从第二eSIM 2470请求euicc2.Info1。
在操作24005中，第二eSIM 2470可以生成euicc2.Info。euicc2.Info可以包括以下各条信息中的至少一条：
-可用于第一eSIM验证第二eSIM的证书信息
-可用于第二eSIM验证第一eSIM的证书信息
-第二设备所支持的版本信息
此外，第二eSIM 2470可以向第二LPA 2480提供euicc2.Info。
在操作24010中，第二LPA 2480可以从第二eSIM 2470请求euicc2.Challenge。
在操作24015中，第二eSIM 2470可以生成euicc2.Challenge。euicc2.Challenge可以是由第二eSIM 2470生成的任何随机数。第二eSIM 2470可以向第二LPA 2480提供euicc2.Challenge。
在操作24020中，第二LPA 2480可以通过第一LPA 2430向第一eSIM 2420提供euicc2.Info1。此外，第二LPA 2480可以通过第一LPA 2730向第一eSIM 2420提供euicc2.Challenge。在这种情况下，第一LPA 2730还可以向第一eSIM 2420提供要发送的配置文件的配置文件分类符。
在操作24025中，可以执行以下程序。
第一eSIM 2420可以基于euicc2.Info1中包括的要由第二eSIM用来验证第一eSIM的证书信息，选择要由其自身使用的证书euicc1.Certificate。
第一eSIM 2420可以基于euicc2.Info1中包括的要由第一eSIM用来验证第二eSIM的证书信息，选择要由第二eSIM 2470使用的证书。在这种情况下，所选择的证书信息或者可以指示所选择的证书的信息可以被称为euiccCiPKIdToBeUsed。
其中第一eSIM 2420基于要由第一eSIM用来验证第二eSIM的证书信息来生成或选择euiccCiPKIdToBeUsed的程序可以对应于以下程序之一：
a)第一eSIM检查要用于验证第二eSIM的证书信息和存储在设备中的如图16所示的可信CI列表之间是否存在交集，然后当存在交集时，将交集的至少一个元素设置为euiccCiPKIdToBeUsed
b)第一eSIM检查要用于验证第二eSIM的证书信息和从服务器提供的如图16所示的可信CI列表之间是否存在交集，然后当存在交集时，将交集的至少一个元素设置为euiccCiPKIdToBeUsed
c)第一eSIM检查要用于验证第二eSIM的证书信息、存储在设备中的如图16所示的可信CI列表和从服务器提供的如图16所示的可信CI列表之间是否存在交集，然后当存在交集时，将交集的至少一个元素设置为euiccCiPKIdToBeUsed。
换句话说，第一eSIM 2420可以检查要用于验证第二eSIM的证书信息、存储在设备中的可信CI列表和从服务器提供的可信CI列表之间是否存在交集，然后当存在交集时，可以将交集的至少一个元素设置为euiccCiPKIdToBeUsed。
关于将使用上述指定方法中的哪一种的设置可以被包括在配置文件传送设置中。
在使用从服务器提供的可信CI列表的情况下，第一eSIM 2420可以基于接收到的配置文件分类符来确定哪个服务器被用于提供可信CI列表。此外，在使用存储在设备中的可信CI列表的情况下，第一eSIM 2420可以基于接收到的配置文件分类符来确定哪个设备被用于获得存储在其中的可信CI列表。换句话说，在设备中可以存在存储在设备中的可信CI列表和从服务器提供的可信CI列表中的一个或多个，并且在其中，可以选择和使用与当前要传送的配置文件相关联的(多个)列表。
第一eSIM 2420可以检查与接收到的配置文件分类符相关联的配置文件的配置文件传送设置。第一eSIM 2420可以检查配置文件是否可以通过设备到设备传送来发送。
第一eSIM 2420可以检查euicc2.Info1中包括的第二设备2460所支持的版本信息，以确定在其中是否存在自己支持的版本。
第一eSIM 2420可以生成用于指示与第二eSIM 2470的未来通信的会话ID(事务ID)。
第一eSIM 2420可以生成euicc1.Challenge。euicc1.Challenge可以是由第一eSIM 2420生成的任何随机数。
第一eSIM 2420可以对以下值的全部和/或部分进行电子签名：电子签名可以基于euicc1.Certificate来执行。
-事务ID
-euicc1.Challenge
-euicc2.Challenge
第一eSIM 2420可以通过第一LPA 2340向第二LPA 2480发送以下数据的全部和/或部分。
-事务ID和/或euicc1.Challenge和/或euicc2.Challenge及其电子签名值
-euiccCiPKIdToBeUsed
-euicc1.Certificate
上面提供的数据可以被称为Device1.Auth1。
在操作24030中，第二LPA 2480可以向第二eSIM 2470发送以下数据的全部和/或部分。
-Device1.Auth1
-要由第一设备2410发送到第二设备2460的配置文件的配置文件分类符
在操作24035中，可以执行以下程序。
第二eSIM 2470可以验证euicc1.Certificate的有效性。
第二eSIM 2470可以验证Device1.Auth1中包括的电子签名值。
第二eSIM 2470可以检查Device1.Auth中包括的euicc2.Challenge是否与在操作24020中由第二eSIM 2470发送euicc2.Challenge具有相同的值。
第二eSIM 2470可以基于euiccCiPKIdToBeUsed来选择要由自身使用的证书euicc2.Certificate。
第二eSIM 2470可以对以下值的全部和/或部分进行电子签名：电子签名可以基于euicc2.Certificate来执行。
-事务ID
-euicc1.Challenge
-euicc2.Info2。euicc2.Info2可以是要用于关于由第一设备发送到第二设备的配置文件是否可以在第二设备2460中安装和操作的资格检查(eligibility check)的信息。例如，eUICC2.Info2可以包括第二eSIM 2470的硬件和/或软件信息。
-要由第一设备2410发送到第二设备2460的配置文件的配置文件分类符
第二eSIM 2470可以通过第二LPA 2480和第一LPA 2340向第一eSIM 2420发送以下数据的全部和/或部分。
-事务ID和/或euicc1.Challenge和/或euicc2.Info2和/或要由第一设备发送到第二设备的配置文件的配置文件分类符以及它们的电子签名值
-Euicc2.Certificate
以上数据可以被称为Device2.Auth1。
图25示出了根据本公开的一些实施例的图22中提出的程序中的其中配置文件从第一设备2510发送到第二设备2560然后被安装在第二设备中的详细程序。
参考图25，设备可以包括至少一个LPA和至少一个eSIM。例如，第一设备2510可以包括第一LPA 2530和第一eSIM 2520，并且第二设备2560可以包括第二LPA 2580和第二eSIM 2570。
在操作25000中，可以执行以下程序。
第一eSIM 2520可以验证euicc2.Certificate的有效性。
第一eSIM 2520可以验证Device2.Auth1中包括的电子签名值。
第一eSIM 2520可以检查Device2.Auth中包括的euicc1.Challenge是否与在操作25025中由第一eSIM 2520发送的euicc1.Challenge具有相同的值。
第一eSIM 2520可以识别Device2.Auth1中包括的配置文件分类符，以指定要由第一eSIM 2520发送的配置文件。可替代地，第一eSIM 2520可以检查Device2.Auth1中包括的配置文件分类符是否与在图24的24020中接收的配置文件分类符相匹配。
第一eSIM 2520可以检查与接收到的配置文件分类符相关联的配置文件的配置文件传送设置。第一eSIM 2520可以检查配置文件是否可以通过设备到设备传送来发送。
第一eSIM 2520可以执行关于配置文件是否可以在第二设备2560(例如，第二eSIM2570)中正常安装和操作的资格检查。在这种情况下，对于资格检查来说，可以使用配置文件分类符和euicc2.Info2。
第一eSIM 2520可以对以下值进行电子签名：电子签名可以基于euicc1.Certificate来执行。
-事务ID
第一eSIM 2520可以通过第一LPA 2530和第二LPA 2580向第二eSIM 2570发送事务ID和/或电子签名。在这种情况下，所发送的值可以被称为Device1.Auth2。
在操作25005中，可以执行以下程序。
第二eSIM 2570可以验证Device1.Auth2中包括的电子签名值。
第二eSIM 2570可以创建它的创建要用于与第一eSIM 2520的加密通信的会话密钥所需的加密密钥对(例如，公钥otPK.EUICC2.KA和对应的私钥otSK.EUICC2.KA)。
第二eSIM 2570可以对以下值的全部和/或部分进行电子签名：电子签名可以基于euicc2.Certificate来执行。
-事务ID
-otPK.EUICC2.KA
第二eSIM 2570可以通过第二LPA 2580和第一LPA 2530向第一eSIM 2520发送事务ID和/或otPK.EUICC2.KA及其电子签名值。在这种情况下，所发送的值可以被称为Device2.Auth2。
在操作25010中，可以执行以下程序。
第一eSIM 2520可以验证Device2.Auth2中包括的电子签名值。
第一eSIM 2520可以创建它的创建要用于与第二eSIM 2570的加密通信的会话密钥所需的加密密钥对(例如，公钥otPK.EUICC1.KA和对应的私钥otSK.EUICC1.KA)。
第一eSIM 2520可以用由第一eSIM 2520自身生成的otSK.EUICC1.KA和接收到的otPK.EUICC2.KA创建用于与第二设备的加密通信的会话密钥。
第一eSIM 2520可以准备要发送到第二设备2560的配置文件(配置文件映像和/或配置文件包)。在这种情况下，准备的配置文件映像或配置文件包可以被称为绑定配置文件包或绑定配置文件映像。此外，绑定配置文件包和绑定配置文件映像可以被统称为绑定配置文件。
在该准备过程中，要发送的配置文件映像和/或配置文件包的全部和/或部分可以用先前创建的会话密钥来加密。此外，要发送的配置文件映像和/或配置文件包的全部和/或部分可以通过使用euicc1.Certificate进行电子签名，并且电子签名值可以作为绑定配置文件的一部分被包括在内。此外，otPK.EUICC1.KA可以作为绑定配置文件的一部分被包括在内。
第一eSIM 2520可以通过第一LPA 2530向第二LPA 2580发送绑定配置文件。在这种情况下，也可以发送与配置文件相关联的元数据。元数据可以作为绑定文件的一部分被包括在内，或者可以作为与绑定配置文件分离的数据进行发送。
第一eSIM 2520可以删除配置文件。
在操作25015中，可以执行以下程序。
第二设备2560可以检查所发送的元数据。
第二设备2560可以接收用户关于安装接收到的绑定配置文件的协定。
第二设备2560可以在第二eSIM 2570中安装接收到的绑定配置文件。该程序可以通过第二LPA 2580和第二eSIM 2570之间的合作来执行。当在该程序中在绑定配置文件中存在加密的数据时，第二eSIM 2570可以用otSK.EUICC2.KA和otPK.EUICC1.KA来创建会话密钥，然后用会话密钥来解码数据。此外，当电子签名值被包括在绑定配置文件中时，第二eSIM 2570可以基于euicc1.Certificate来验证电子签名值的有效性。
根据本公开的一些实施例，上面参考图22至图25描述的设备和服务器可以分别是图20的设备和图21的服务器。换句话说，可以通过使用图20的设备和图21的服务器来实践图22至图25中描述的至少一些实施例。
在本公开的实施例中，组件以单数或复数形式表示。然而，应当理解，为了便于解释，根据所呈现的情况适当地选择单数或复数表示，并且本公开不限于组件的单数或复数形式。此外，以复数形式表达的组件也可能意味着单数形式，反之亦然。
因此，已经描述了本公开的几个实施例，但是将理解的是，在不脱离本公开的范围的情况下，可以进行各种修改。因此，对于本领域普通技术人员来说将显而易见的是，本公开不限于所描述的实施例，而是不仅涵盖所附权利要求，还包括其等同物。
应当理解，本公开的各种实施例和相关联的术语并不旨在将前述技术限制于此，而是涵盖各种改变、等同物和/或替代物。在所有附图中，相同的附图标记指代相同的元件。如本文所使用的，单数形式“一”、“一个”和“该”旨在也包括复数形式，除非上下文清楚地另外指示。如本文所使用的，术语“A或B”、“A和/或B中的至少一个”、“A、B或C”或“A、B和/或C中的至少一个”包括一个或多个相关联的列出项目的任何和所有组合。类似“第一”、“第二”等的术语可以用于指示各种组件，但是这些组件不应受这些术语的约束。这些术语仅用于区分一个元件、组件、区域、层或部分与另一元件、组件、区域、层或部分。当说到组件(例如，第一组件)可操作地或通信地与另一组件(例如，第二组件)耦合或连接时，应当理解，第一组件可以与第二组件直接连接或耦合，或者可以通过另一新的组件(例如，第三组件)与第二组件间接连接或耦合。
在说明书中，术语“模块”、“设备”、“构件”或“框”可以指以硬件、软件或固件实施的单元，并且可以与例如逻辑、逻辑框、部件或电路可互换地使用。模块可以是执行一个或多个功能的整体部件，或者是该部件的最小单元或一部分。例如，模块可以用专用集成电路(ASIC)来配置。
本公开的各种实施例可以在包括存储在机器(例如，计算机)可读存储介质(例如，内部或外部存储器)中的指令的软件(例如，程序)中实施。装置可以是能够调用存储在存储介质中的指令并根据所调用的指令进行操作的设备，并且可以包括根据各种实施例的设备。当指令由处理器(例如，图14的处理器1420)执行时，与指令相对应的功能可以由处理器直接执行，或者由处理器控制下的其他组件执行。指令可以包括由编译器或解释器生成或执行的代码。
机器可读存储介质可以以非暂时性存储介质的形式提供。术语“非暂时性”仅意味着存储介质是有形的，而不包括信号，但无助于区分半永久地或临时地存储在存储介质中的任何数据。
根据本公开的各种实施例的前述方法可以在计算机程序产品中提供。计算机程序产品可以是可以在卖方和买方之间交易的商业产品。计算机程序产品可以以存储介质(例如，光盘只读存储器(CD-ROM))的形式分发，通过应用商店(例如，play storeTM)分发，或者在线分发。在在线分发的情况下，计算机程序产品的至少一部分可以至少临时地存储或任意地创建在制造商的服务器、应用商店的服务器或中继服务器的存储介质中。可以以单数或复数提供本公开的各种实施例中的每个组件(例如，模块或程序)，并且可以从本公开的各种实施例中省略前述子组件中的一些，或者可以向本公开的各种实施例添加其他子组件。可替代地或附加地，一些组件(例如，模块或程序)可以被集成在一个实体中，但是可以执行在集成之前由相应组件执行的相同或类似的功能。根据本公开的各种实施例，由模块、程序或其他组件执行的过程可以顺序地、并行地、重复地或启发式地执行，或者这些过程中的一个或多个可以以不同的次序执行或省略，或者可以进一步执行一个或多个附加过程。

Claims (15)

1.一种由第一设备向第二设备提供捆绑包的方法，所述方法包括：
获得关于要发送到第二设备的捆绑包的信息；
将所述捆绑包的标识信息发送到第二设备；
从第二设备接收与第二设备的第二智能安全平台(SSP)的捆绑包传送相关的认证信息；
基于与第二SSP的捆绑包传送相关的认证信息来确定第二SSP的第二次级平台捆绑包加载器(SPBL)是否是能够接收所述捆绑包的Spbl；以及
基于所述确定的结果将所述捆绑包发送到第二设备。
2.根据权利要求1所述的方法，其中，所述捆绑包的标识信息包括所述捆绑包的捆绑包家族身份(家族ID，Fid)或捆绑包家族管理器标识符(家族保管器对象ID，Oid)中的至少一个。
3.根据权利要求1所述的方法，其中，与第二SSP的捆绑包传送相关的认证信息包括基于所述捆绑包的标识信息而确定的接收SPBL认证信息，
其中，确定第二SSP的第二SPBL是否是能够接收捆绑包的SPBL还包括基于所述捆绑包的标识信息来确定所述接收SPBL认证信息是否被包括在第一设备的关于可验证SPBL的信息和关于可信SPBL的信息中的至少一个中，
其中，关于可验证SPBL的信息被预先存储在第一设备中，并且
其中，关于可信SPBL的信息是从服务器接收的。
4.根据权利要求3所述的方法，其中，关于可信SPBL的信息包括与所述捆绑包的标识信息对应的捆绑包传送策略信息，
其中，所述捆绑包传送策略信息包括以下中的至少一个：1)所述接收SPBL认证信息被包括在关于可验证SPBL的信息中的状况，2)所述接收SPBL认证信息被包括在关于可信SPBL的信息中的状况，3)所述接收SPBL认证信息被包括在关于可验证SPBL的信息和关于可信SPBL的信息两者中的状况，以及4)所述接收SPBL认证信息被包括在关于可验证SPBL的信息和关于可信SPBL的信息之一中的状况，以及
其中，确定第二SSP的第二SPBL是否是能够接收所述捆绑包的SPBL还包括基于所述捆绑包传送策略信息来确定第二SPBL是否是能够接收所述捆绑包的Spbl。
5.根据权利要求1所述的方法，其中，与第二设备的第二SSP的捆绑包传送相关的认证信息包括基于所述捆绑包的标识信息而确定的发送SPBL认证信息，以及
所述方法还包括基于所述发送SPBL认证信息来确定第一设备的第一SSP的第一SPBL是否是能够向第二设备发送捆绑包的Spbl。
6.根据权利要求5所述的方法，还包括：
基于所述发送SPBL认证信息生成第一设备的认证信息；
将第一设备的认证信息发送到第二设备；
从第二设备接收第二设备的认证信息；
验证第二设备的认证信息的有效性；以及
基于验证的结果将所述捆绑包发送到第二设备。
7.根据权利要求3所述的方法，还包括：
将对关于可信SPBL的信息的请求发送到所述服务器；以及
从所述服务器接收关于可信SPBL的信息，
其中，对关于可信SPBL的信息的请求包括所述捆绑包的标识信息。
8.一种由第二设备从第一设备接收捆绑包的方法，所述方法包括：
从第一设备接收所述捆绑包的标识信息；
基于接收到的所述捆绑包的标识信息来生成与第二设备的第二智能安全平台(SSP)的捆绑包传送相关的认证信息；
将与第二SSP的捆绑包传送相关的认证信息发送到第一设备；以及
基于由第一设备对与第二SSP的捆绑包传送相关的认证信息的验证的结果从第一设备接收所述捆绑包。
9.根据权利要求8所述的方法，其中，与第二SSP的捆绑包传送相关的认证信息的生成包括：
从预先存储的关于第二设备的可验证次级平台捆绑包加载器(SPBL)的信息中提取与所述捆绑包的标识信息对应的信息；以及
基于提取的信息生成针对所述捆绑包的接收SPBL认证信息和发送SPBL认证信息。
10.根据权利要求9所述的方法，其中，与第二SSP的捆绑包传送相关的认证信息的生成包括基于识别出针对所述捆绑包的捆绑包家族标识(家族ID)和捆绑包家族管理器标识符(家族保管器对象ID)不被包括在接收到的所述捆绑包的标识信息中，生成包括预先存储的第二设备的可验证SPBL的信息。
11.一种用于为第二设备提供捆绑包的第一设备，所述第一设备包括：
收发器；以及
至少一个处理器，
其中，所述至少一个处理器被配置为：
获得关于要发送到第二设备的捆绑包的信息，
控制所述收发器将所述捆绑包的标识信息发送到第二设备，
控制所述收发器从第二设备接收与第二设备的第二智能安全平台(SSP)的捆绑包传送相关的认证信息，
基于与第二SSP的捆绑包传送相关的认证信息来确定第二SSP的第二次级平台捆绑包加载器(SPBL)是否是能够接收捆绑包的Spbl，以及
基于确定的结果来控制所述收发器将所述捆绑包发送到第二设备。
12.根据权利要求11所述的第一设备，其中，所述捆绑包的标识信息包括针对所述捆绑包的捆绑包家族身份(家族ID，Fid)和捆绑包家族管理器标识符(家族保管器对象ID，Oid)中的至少一个。
13.一种用于从第一设备接收捆绑包的第二设备，所述第二设备包括：
收发器；以及
至少一个处理器，
其中，所述至少一个处理器被配置为：
控制所述收发器从第一设备接收捆绑包的标识信息，
基于接收到的所述捆绑包的标识信息，生成与第二设备的第二智能安全平台(SSP)的捆绑包传送相关的认证信息，
控制所述收发器将与第二SSP的捆绑包传送相关的认证信息发送到第一设备，以及
基于由第一设备对与第二SSP的捆绑包传送相关的认证信息的验证的结果来控制所述收发器从第一设备接收所述捆绑包。
14.一种在无线通信系统中由第一设备向第二设备提供配置文件的方法，所述方法包括：
在安装在第一设备中的配置文件当中确定要发送到第二设备的配置文件；
基于用于与第二设备的通信的连接从第二设备接收第二设备的嵌入式通用集成电路卡(eUICC)信息；
基于所述eUICC信息生成第一设备的认证信息；
将第一设备的认证信息发送到第二设备；
从第二设备接收第二设备的认证信息作为对第一设备的认证信息的响应；
验证第二设备的认证信息；以及
基于验证的结果将针对所述配置文件的配置文件包发送到第二设备。
15.一种在无线通信系统中由第二设备从第一设备接收配置文件的方法，所述方法包括：
基于用于与第一设备的通信的连接将第二设备的嵌入式通用集成电路卡(eUICC)信息发送到第一设备；
从第一设备接收第一设备的认证信息作为对所述eUICC信息的响应；
验证第一设备的认证信息；
基于验证的结果生成第二设备的认证信息；
将第二设备的认证信息发送到第一设备；以及
从第一设备接收配置文件包作为对第二设备的认证信息的响应。
CN202080079139.3A 2019-09-20 2020-09-18 在设备到设备捆绑包或配置文件传送期间的相互设备到设备认证方法和设备 Pending CN114731283A (zh)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
KR10-2019-0116363 2019-09-20
KR20190116363 2019-09-20
KR10-2020-0023247 2020-02-25
KR1020200023247A KR20210034460A (ko) 2019-09-20 2020-02-25 기기 간 번들 또는 프로파일 이동 시 기기 간 상호 인증 방법 및 장치
KR10-2020-0086975 2020-07-14
KR1020200086975A KR20210034475A (ko) 2019-09-20 2020-07-14 기기 간 번들 또는 프로파일 이동 시 기기 간 상호 인증 방법 및 장치
PCT/KR2020/012651 WO2021054780A1 (ko) 2019-09-20 2020-09-18 기기 간 번들 또는 프로파일 이동 시 기기 간 상호 인증 방법 및 장치

Publications (1)

Publication Number Publication Date
CN114731283A true CN114731283A (zh) 2022-07-08

Family

ID=74883495

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202080079139.3A Pending CN114731283A (zh) 2019-09-20 2020-09-18 在设备到设备捆绑包或配置文件传送期间的相互设备到设备认证方法和设备

Country Status (4)

Country Link
US (1) US20220377081A1 (zh)
EP (1) EP4027602A4 (zh)
CN (1) CN114731283A (zh)
WO (1) WO2021054780A1 (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103080946A (zh) * 2010-09-16 2013-05-01 国际商业机器公司 用于安全地管理文件的方法、安全设备、系统和计算机程序产品
CN105359486A (zh) * 2013-05-03 2016-02-24 思杰系统有限公司 使用代理安全访问资源
US20160241537A1 (en) * 2015-02-17 2016-08-18 Samsung Electronics Co., Ltd. Method for transferring profile and electronic device supporting the same
CN109756447A (zh) * 2017-11-01 2019-05-14 华为技术有限公司 一种安全认证方法及相关设备
WO2019099294A1 (en) * 2017-11-14 2019-05-23 Merck Sharp & Dohme Corp. Novel substituted biaryl compounds as indoleamine 2,3-dioxygenase (ido) inhibitors
US20190166488A1 (en) * 2017-11-30 2019-05-30 Samsung Electronics Co., Ltd. Method and electronic device for providing communication service

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7131123B2 (en) * 2001-04-30 2006-10-31 Opsware Inc. Automated provisioning of computing networks using a network database model
US7516452B1 (en) * 2005-03-31 2009-04-07 Emc Corporation Method and system for managing installation of software on a computer system platform
US8560708B2 (en) * 2010-06-29 2013-10-15 Alcatel Lucent Method and apparatus for allocating bundles of sessions in a network element
US8990561B2 (en) * 2011-09-09 2015-03-24 Microsoft Technology Licensing, Llc Pervasive package identifiers
US9448780B1 (en) * 2011-12-13 2016-09-20 Zynga Inc. Package manager verifier
KR102558361B1 (ko) * 2015-04-13 2023-07-21 삼성전자주식회사 통신 시스템에서 프로파일을 관리하는 기법
KR20170098110A (ko) * 2016-02-19 2017-08-29 삼성전자주식회사 임베디드 심 운용 지원 방법 및 이를 지원하는 전자 장치
KR102458790B1 (ko) * 2017-09-07 2022-10-25 삼성전자 주식회사 무선 통신 시스템에서 디바이스들의 프로파일 이동을 지원하는 방법 및 장치
US10187784B1 (en) * 2018-06-11 2019-01-22 Verizon Patent And Licensing Inc. Systems and methods for transferring SIM profiles between eUICC devices
US11275572B2 (en) * 2020-01-30 2022-03-15 Slack Technologies, Llc Systems and methods for providing a packaged plurality of application data within a group-based communication system
US11340881B2 (en) * 2020-04-02 2022-05-24 Vmware, Inc. Validation of desired software state image for hardware incompatibilities

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103080946A (zh) * 2010-09-16 2013-05-01 国际商业机器公司 用于安全地管理文件的方法、安全设备、系统和计算机程序产品
CN105359486A (zh) * 2013-05-03 2016-02-24 思杰系统有限公司 使用代理安全访问资源
US20160241537A1 (en) * 2015-02-17 2016-08-18 Samsung Electronics Co., Ltd. Method for transferring profile and electronic device supporting the same
CN109756447A (zh) * 2017-11-01 2019-05-14 华为技术有限公司 一种安全认证方法及相关设备
WO2019099294A1 (en) * 2017-11-14 2019-05-23 Merck Sharp & Dohme Corp. Novel substituted biaryl compounds as indoleamine 2,3-dioxygenase (ido) inhibitors
US20190166488A1 (en) * 2017-11-30 2019-05-30 Samsung Electronics Co., Ltd. Method and electronic device for providing communication service

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ETSI: "Anonymous: "Smart Cards; Smart Secure Platform (SSP)", pages 11 - 12, Retrieved from the Internet <URL:《URL:https://www.etsi.org/deliver/etsi_ts/》> *

Also Published As

Publication number Publication date
US20220377081A1 (en) 2022-11-24
WO2021054780A1 (ko) 2021-03-25
EP4027602A1 (en) 2022-07-13
EP4027602A4 (en) 2023-01-04

Similar Documents

Publication Publication Date Title
US11989543B2 (en) Method for interoperating between bundle download process and eSIM profile download process by SSP terminal
US11206534B2 (en) Method and apparatus for managing bundles of smart secure platform
KR102657876B1 (ko) Ssp 단말과 서버가 디지털 인증서를 협의하는 방법 및 장치
CN113785532B (zh) 用于管理和验证证书的方法和装置
US11963261B2 (en) Method and apparatus for recovering profile in case of device change failure
US20240015508A1 (en) Method and device for remote management and verification of remote management authority
US20220377081A1 (en) Mutual device-to-device authentication method and device during device-to-device bundle or profile transfer
EP4017047A1 (en) Method and device for setting state of bundle after transfer of bundle between apparatuses
US11950320B2 (en) Apparatus and methods for linkage of or profile transfer between devices
US20220278985A1 (en) Method and device for transferring bundle between devices
KR102180481B1 (ko) 번들 정보를 제공하는 방법 및 장치
US11997488B2 (en) Method and apparatus for managing and verifying certificate
US20230136288A1 (en) Method and device for online moving of bundles or profiles between devices
US20220095095A1 (en) Method and apparatus for moving profiles with different versions during device change
KR20210034460A (ko) 기기 간 번들 또는 프로파일 이동 시 기기 간 상호 인증 방법 및 장치
KR20210116169A (ko) 기기 간 번들 또는 프로파일 온라인 이동 방법 및 장치
KR20210034522A (ko) 기기 간 번들 이동 후 번들의 상태를 설정하는 방법 및 장치
KR20210020770A (ko) 기기 간 번들 이동 방법 및 장치
KR20210020725A (ko) 기기 간 번들 이동 방법 및 장치

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination