CN114731505A - 用于在装置之间的包传输后设置包的状态的方法和设备 - Google Patents
用于在装置之间的包传输后设置包的状态的方法和设备 Download PDFInfo
- Publication number
- CN114731505A CN114731505A CN202080080987.6A CN202080080987A CN114731505A CN 114731505 A CN114731505 A CN 114731505A CN 202080080987 A CN202080080987 A CN 202080080987A CN 114731505 A CN114731505 A CN 114731505A
- Authority
- CN
- China
- Prior art keywords
- ssp
- terminal
- packet
- information
- lba
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 473
- 230000005540 biological transmission Effects 0.000 title description 127
- 238000012795 verification Methods 0.000 claims description 110
- 230000007704 transition Effects 0.000 claims description 77
- 230000008859 change Effects 0.000 claims description 25
- 238000004891 communication Methods 0.000 abstract description 38
- 238000005516 engineering process Methods 0.000 abstract description 14
- 238000012005 ligant binding assay Methods 0.000 description 400
- 230000008569 process Effects 0.000 description 381
- 238000007726 management method Methods 0.000 description 82
- 230000004044 response Effects 0.000 description 78
- 238000010586 diagram Methods 0.000 description 73
- 101150038317 SSP1 gene Proteins 0.000 description 52
- 101100125020 Schizosaccharomyces pombe (strain 972 / ATCC 24843) pss1 gene Proteins 0.000 description 52
- 101100018019 Schizosaccharomyces pombe (strain 972 / ATCC 24843) ssc1 gene Proteins 0.000 description 52
- 238000007670 refining Methods 0.000 description 39
- 101100257820 Neurospora crassa (strain ATCC 24698 / 74-OR23-1A / CBS 708.71 / DSM 1257 / FGSC 987) ssp-1 gene Proteins 0.000 description 37
- 101100256651 Homo sapiens SENP6 gene Proteins 0.000 description 34
- 102100023713 Sentrin-specific protease 6 Human genes 0.000 description 34
- 230000006870 function Effects 0.000 description 32
- 238000012546 transfer Methods 0.000 description 29
- 101100532584 Clostridium perfringens (strain 13 / Type A) sspC1 gene Proteins 0.000 description 27
- 238000010200 validation analysis Methods 0.000 description 26
- 238000011084 recovery Methods 0.000 description 22
- 101100095550 Homo sapiens SENP7 gene Proteins 0.000 description 21
- 101150098865 SSP2 gene Proteins 0.000 description 21
- 102100031406 Sentrin-specific protease 7 Human genes 0.000 description 21
- 238000009434 installation Methods 0.000 description 18
- 238000003860 storage Methods 0.000 description 14
- CPLXHLVBOLITMK-UHFFFAOYSA-N Magnesium oxide Chemical compound [Mg]=O CPLXHLVBOLITMK-UHFFFAOYSA-N 0.000 description 13
- 238000002360 preparation method Methods 0.000 description 11
- 238000012545 processing Methods 0.000 description 9
- 238000004590 computer program Methods 0.000 description 8
- 238000010295 mobile communication Methods 0.000 description 8
- 238000013507 mapping Methods 0.000 description 6
- 230000014509 gene expression Effects 0.000 description 5
- 238000004519 manufacturing process Methods 0.000 description 5
- 238000012217 deletion Methods 0.000 description 4
- 230000037430 deletion Effects 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 3
- 230000003068 static effect Effects 0.000 description 3
- 238000009826 distribution Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000009849 deactivation Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000011900 installation process Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
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
-
- 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
- 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/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
-
- 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/3247—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 digital signatures
-
- 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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
- H04L9/3265—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
-
- 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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
- H04L9/3268—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
-
- 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/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
- H04W8/20—Transfer of user or subscriber data
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
- H04W8/20—Transfer of user or subscriber data
- H04W8/205—Transfer to or from user equipment or user record carrier
Abstract
本公开涉及用于融合支持超过第四代(4G)系统的更高数据速率的第五代(5G)通信系统与物联网(IoT)技术的通信方法和系统。本公开可以应用于基于5G通信技术和IoT相关技术的智能服务，诸如智能家居、智能建筑、智能城市、智能汽车、联网汽车、医疗保健、数字教育、智能零售、安全和安保服务。本公开描述了用于在包已经在智能安全介质之间发送之后设置包的状态的方法和设备。
Description
技术领域
本公开涉及智能安全介质，更具体地，涉及用于在智能安全介质之间进行包(bundle)传输之后配置包的状态的方法和设备。
本公开涉及智能安全介质，更具体地，涉及用于在智能安全介质之间进行包传输之后在服务器中注册包传输结果的方法和设备。
背景技术
为了满足自4G通信系统部署以来增加的对无线数据流量的需求，已经努力开发改进的5G或预5G(pre-5G)通信系统。因此，5G或预5G通信系统也被指代为“超4G网络”或“后LTE系统”。5G通信系统被认为是在较高频率(毫米波)频带(例如，60GHz频带)中实现的，以便实现更高的数据速率。为了减少无线电波的传播损耗并增加传输距离，在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)与各种工业应用之间的融合和组合，IoT可以应用于各种领域，包括智能家庭、智能建筑、智能城市、智能汽车或互联汽车、智能电网、医疗保健、智能家电和高级医疗服务。
相应地，已经进行了各种尝试以将5G通信系统应用于IoT网络。诸如传感器网络、机器类型通信(MTC)和机器对机器(M2M)通信等技术可以通过波束成形、MIMO和阵列天线来实施。云无线接入网(RAN)作为上述大数据处理技术的应用也可以看作是5G技术与IoT技术的融合的一个示例。
发明内容
技术问题
所公开的实施例提供了一种用于当在两个电子设备中包括的安全模块之间移动包(bundle)时，在执行包传输之后配置包状态的设备和方法。
此外，所公开的实施例提供了一种用于当在两个电子设备中包括的安全模块之间移动包时，在执行包传输之后在服务器中注册包传输结果的设备和方法。
技术方案
根据本公开的实施例，一种操作第一终端的方法包括：向第二终端发送包；从第二终端接收生成的包括第二终端的包状态信息的第一证明；验证所接收的第一证明；在验证第一证明之后，生成包括第一终端的包状态信息的第二证明；以及向第二终端发送第二证明。
在一些示例中，第一终端的包状态信息可以包括第一终端的包状态被配置为删除(DELETE)、转换中(IN TRANSITION)和暂停(SUSPENSION)中的至少一个。
在一些示例中，该方法还可以包括：从第二终端接收所生成的第三证明，该第三证明包括当第一终端的包状态被配置为转换中时关于第二终端的包状态改变的信息；验证所接收的第三证明；以及在验证第三证明之后删除第一终端的包。
在一些示例中，包括关于第一证明和第二证明的验证结果的信息的第四证明可由第二终端生成，第四证明可被发送到服务器，并且第四证明可由服务器验证。
在一些示例中，包括与服务器的认证结果的第五证明可以由服务器生成；第五证明可以被发送到第二终端，并且第五证明可以由第二终端来验证。
根据本公开的另一实施例，一种操作第二终端的方法包括从第一终端接收包；安装包；生成包括第二终端的包状态信息的第一证明；向第一终端发送第一证明；从第一终端接收生成的包括第一终端的包状态信息的第二证明；验证所接收的第二证明；以及在验证第二证明之后，改变第二终端的包状态配置信息。
根据本公开的另一实施例，第一终端包括被配置成发送和接收至少一个信号的收发器；以及耦合到收发器的控制器，其中控制器被配置成向第二终端发送包，从第二终端接收生成的包括第二终端的包状态信息的第一证明；验证所接收的第一证明；在验证第一证明之后，生成包括第一终端的包状态信息的第二证明，并且向第二终端发送第二证明。
根据本公开的另一实施例，第二终端包括被配置成发送和接收至少一个信号的收发器；以及耦合到收发器的控制器，其中控制器被配置成从第一终端接收包，安装包，生成包括第二终端的包状态信息的第一证明，向第一终端发送第一证明，从第一终端接收生成的包括第一终端的包状态信息的第二证明，验证所接收的第二证明，以及在验证第二证明之后改变第二终端的包状态配置信息。
有益效果
根据本公开的各种实施例，安装在一个设备中的包可以以安全和有效的方式被传输和安装到另一个设备，并且在传输和安装完成之后，可以配置包状态。
此外，根据本公开的各种实施例，安装在一个设备中的包可以以安全和有效的方式被传输和安装到另一个设备，并且在传输和安装完成之后，包的传输结果可以被注册在服务器中。
附图说明
图1是示出根据本公开实施例的SSP的概念图。
图2是示出根据本公开实施例的SSP的内部结构的概念图。
图3是示出根据本公开实施例的终端中用于终端下载和安装包到SSP的组件的示例的图。
图4是示出根据本公开的实施例的两个终端相互操作以便在两个终端之间发送包的方法的示例的图。
图5是示出根据本公开的一些实施例的“证明”的配置的图。
图6是概念性地图示了根据本公开的实施例的用于从一个终端向另一个终端发送包的过程的图。
图7是示出图6中呈现的过程当中用于准备包传输的过程的详细过程的图。
图8是示出在图6中呈现的过程当中发送包的过程的详细过程的图。
图9是示出图6中呈现的过程当中包的传输完成的过程的详细过程的图。
图10是示出图6中呈现的过程当中完成包的传输的过程的另一详细过程的图。
图11是示出图6中呈现的过程当中完成包的传输的过程的另一详细过程的图。
图12是示出图6所示的过程当中完成包的传输的过程的另一个详细过程的图。
图13是示出用于使已经暂停使用的包再次可用的过程的示例的图。
图14是示出用于使已经暂停使用的包再次可用的另一过程的示例的图。
图15是示出用于使已经暂停使用的包再次可用的另一过程的示例的图。
图16是示出根据本公开的一些实施例的终端的配置的图。
图17是示出图6中呈现的过程当中完成包的传输的过程的另一详细过程的图。
图18是示出根据本公开的一些实施例的“证明”的配置的图。
图19是概念性地示出了根据本公开的实施例的用于从一个终端向另一个终端发送包的过程的图。
图20是示出图19中呈现的过程当中用于准备包传输的过程的详细过程的图。
图21是示出在图19中呈现的过程当中发送包的过程的详细过程的图。
图22是示出在图19所示的过程当中完成包的传输的过程的详细过程的图。
图23是图示在图22中呈现的过程之后在服务器中注册包传输结果的过程的图。
图24是示出图19中示出的过程当中完成包的传输的过程的另一详细过程的图。
图25是图示在图24中呈现的过程之后在服务器中注册包传输结果的过程的图。
图26是示出图19中示出的过程当中完成包的传输的过程的另一详细过程的图。
图27是图示在图26中呈现的过程之后在服务器中注册包传输结果的过程的图。
图28是示出根据本公开的一些实施例的终端的配置的图。
图29是示出根据本公开的一些实施例的服务器的配置的图。
图30是示出在图19中呈现的过程当中完成包的传输的过程和用于在服务器中注册包传输结果的过程的另一详细过程的图。
具体实施方式
在下文中，将参考附图详细描述本公开的实施例。
在描述实施例时，将省略对本公开所属技术领域中公知的并且与本公开不直接相关的技术内容的描述。这是为了更清楚地传达本公开的主旨，而不会因为省略了不必要的描述而模糊本公开的主旨。
出于同样的原因，一些组件在附图中被夸大、省略或示意性地示出。此外，每个组件的尺寸并不完全反映实际尺寸。在每幅图中，相同的附图标记表示相同或相应的组件。
参考下面结合附图详细描述的实施例，本公开的优点和特征以及实现它们的方法将变得显而易见。然而，本公开不限于下面公开的实施例，而是可以以各种不同的形式实现，并且只有这些实施例使得本公开完整，并且提供这些实施例是为了向本公开所属领域的普通技术人员充分告知本公开的范围，并且本公开仅由权利要求的范围限定。在整个说明书中，相同的附图标记指代相同的组件。
在这种情况下，将会理解，消息流程图的每个块和消息流程图的组合可以由计算机程序指令来执行。因为这些计算机程序指令可以安装在通用计算机、专用计算机或其他可编程数据处理设备的处理器中，所以由计算机或其他可编程数据处理设备的处理器执行的指令生成执行(多个)消息流程图块中描述的功能的装置。因为这些计算机程序指令可以存储在计算机可用或计算机可读存储器中，其可以指导计算机或其他可编程数据处理设备以特定方式实现功能，所以存储在计算机可用或计算机可读存储器中的指令可以生成包含用于执行(多个)消息流程图块中描述的功能的指令装置的产品。因为计算机程序指令可以安装在计算机或其他可编程数据处理设备上，所以在计算机或其他可编程数据处理设备上执行一系列操作步骤，以生成计算机执行的过程；因此，用于执行计算机或其他可编程数据处理设备的指令可以提供用于执行(多个)消息流程图块中描述的功能的步骤。
此外，每个块可以表示包括用于执行指定(多个)逻辑功能的一个或多个可执行指令的模块、片段或代码的一部分。此外，应该注意的是，在一些替代实施方式中，块中所述的功能可以不按顺序出现。例如，一个接一个示出的两个块实际上可以基本上同时执行，或者这些块有时可以根据相应的功能以相反的顺序执行。
在这种情况下，在该实施例中使用的术语“-单元”意味着软件或硬件组件，例如FPGA或ASIC，并且“-单元”执行某些角色。然而，“-单元”不限于软件或件。“-单元”可以被配置成驻留在可寻址存储介质中，或者可以被配置成复制一个或多个处理器。因此，作为示例，“单元”包括诸如软件组件、面向对象的软件组件、类组件和任务组件之类的组件、进程、功能、属性、过程、子例程、程序代码段、驱动程序、固件、微码、电路、数据、数据库、数据结构、表格、数组和变量。在组件和“-单元”中提供的功能可以被组合到更小数量的组件和“-单元”中，或者可以被进一步分成附加的组件和“-单元”。此外，可以实现组件和“-单元”来复制设备或安全多媒体卡中的一个或多个CPU。
此外，在本公开中，通过将SSP作为安全介质的示例来描述每个实施例，但是本公开的范围不限于SSP的范围。例如，对于本领域技术人员来说，很明显，下面将要描述的各种实施例可以与执行与SSP基本相同或相似功能的其他安全介质基本相同或相似地应用。
提供以下描述中使用的特定术语以帮助理解本公开，并且在不脱离本公开的技术精神的情况下，这些特定术语的使用可以改变为其他形式。
“安全元件(SE)”是指被配置为单个芯片的安全模块，该安全模块可以存储安全信息(例如，移动通信网络接入密钥、诸如ID/护照的用户识别信息、信用卡信息、加密密钥等)，并且可以使用所存储的安全信息来安装和操作控制模块(例如，诸如USIM的网络接入控制模块、加密模块、密钥生成模块等)。SE可用于各种电子设备(例如，智能电话、平板PC、可穿戴设备、汽车、IoT设备等)，并通过安全信息和控制模块提供安全服务(例如，移动通信网络接入、支付、用户认证等)。
SE可分为通用集成电路卡(UICC)、嵌入式安全元件(eSE)和智能安全平台(SSP),智能安全平台是UICC和eSE的集成形式，并可细分为可移除式、嵌入式和集成式，它们根据电子设备中的连接或安装类型集成到特定元件或片上系统(SoC)中。
“通用集成电路卡(UICC)”是在移动通信终端中插入和使用的智能卡，并且可以被指代为UICC卡。UICC可以包括用于接入移动通信服务提供商的网络的接入控制模块。接入控制模块的示例可以包括通用用户识别模块(USIM)、用户识别模块(SIM)和IP多媒体服务识别模块(ISIM)。包括USIM在内的UICC通常被指代为USIM卡。类似地，包括SIM模块的UICC通常被指代为SIM卡。可以在生产UICC时加载SIM模块，或者可以将用户想要在期望的时间使用的移动通信服务的SIM模块下载到UICC卡中。可以通过下载和安装多个SIM模块并选择其中的至少一个SIM模块来使用UICC卡。这种UICC卡可以固定在也可以不固定在终端上。固定在终端上并在终端中使用的UICC被指代为嵌入式UICC(eUICC)，特别地，内置在终端的通信处理器、应用处理器或片上系统(SoC)中的UICC可以被指代为集成UICC(iUICC),其包括其中集成了两个处理器的单个处理器结构。通常，eUICC和iUICC可以指固定到终端并使用的UICC卡，并且可以通过远程下载SIM模块来选择。在本公开中，可以远程下载和选择SIM模块的UICC卡统称为eUICC或iUICC。也就是说，在可以通过远程下载SIM模块来选择的UICC卡中，固定或不固定到终端的UICC卡被共同用作eUICC或iUICC。此外，下载的SIM模块信息被共同用作术语eUICC简档、iUICC简档，或者更简单地，术语简档。
在本公开中，术语UICC可以与SIM互换使用，术语eUICC可以与eSIM互换使用。此外，在本公开中，USIM简档可以具有与简档相同的含义，或者可以意味着包括在简档内的USIM应用中的信息以软件的形式封装。
“嵌入式安全元件(eSE)”是指固定到电子设备上使用的固定SE。eSE通常是应终端制造商的要求专门为终端制造商生产的，并且可以被生产为包括操作系统和框架。eSE远程下载并安装小应用程序类型的服务控制模块，并可用于各种安全服务，诸如电子钱包、票务、电子护照和数字密钥。在本公开中，附接到能够远程下载和安装服务控制模块的电子设备的单芯片类型SE被统称为eSE。
“智能安全平台(SSP)”能够在单个芯片中集成UICC和eSE功能，并且可以区分为可移除SSP(rSSP)、嵌入式SSP(eSSP)和嵌入SoC中的集成SSP(iSSP)。SSP可以包括一个主平台(PP)和至少一个在PP上操作的次级平台包(SPB)，并且主平台可以包括硬件平台或低级操作系统(LLOS)中的至少一个，次级平台包可以包括高级操作系统(HLOS)或在HLOS上运行的应用中的至少一个。次级平台包也称为SPB或包。包可以通过PP提供的主平台接口(PPI)访问诸如PP的中央处理器和存储器的资源，从而在PP上运行。在包中，可以加载诸如用户识别模块(SIM)、通用SIM(USIM)和IP多媒体SIM(ISIM)的通信应用，并且可以加载诸如电子钱包、票务、电子护照、数字密钥等的各种应用。在本公开中，SSP可以被指代为智能安全介质。
根据要下载和安装的包，SSP可用于上述UICC或eSE目的，并且多个包可安装在单个SSP中并同时操作，以混合UICC和eSE的使用。也就是说，当包括简档的包操作时，SSP可以用作用于接入移动通信服务提供商的网络的UICC。可以通过从远端下载和选择至少一个简档(诸如eUICC或iUICC)到包中来操作相应的UICC包。此外，当包括服务控制模块(该服务控制模块加载有能够提供诸如电子钱包、票务、电子护照或数字密钥的服务的应用程序)的包在SSP上操作时，SSP可以用于eSE的目的。多个服务控制模块可以集成、安装和操作在一个包中，或者可以作为独立的包安装和操作。
可以通过使用空中下载(OTA)技术从次级平台包管理器(SPB管理器)下载包来安装SSP，或者可以从另一个终端接收要安装的包。在本公开中，安装下载或接收的包的方法可同样应用于可插入终端和从终端移除的可移除SSP(rSSP)、可安装在终端中的固定SSP(eSSP)以及包括在安装在终端中的SoC中的集成SSP(iSSP)。
“SSP标识符(SSP ID)”是嵌入在终端中的SSP的对象标识符，可以被指代为sspID。此外，当终端和SSP芯片没有分离时，如在本公开的实施例中，SSP ID可以是终端ID。此外，SSP ID可以指SSP中的特定包标识符(SPB ID)。更详细地说，SSP ID可以指管理包或次级平台包加载器(SPBL)的包标识符，该次级平台包加载器在SSP中安装其他包，并管理其他包的激活、去激活和删除。此外，SSP ID可以指SSP中的主平台标识符。SSP可以具有多个SSP标识符，并且多个SSP标识符可以是从单个唯一的SSP标识符导出的值。
“次级平台包(SPB)”是使用SSP的主平台(PP)上的PP的资源来驱动的，例如，UICC包可能意味着存储在现有UICC中的应用程序、文件系统、认证密钥值等，以及它们在其中操作的操作系统(HLOS)被打包成软件形式。在本公开中，SPB可以被指代为包。
在本公开中，终端的“状态”可以如下。
[启用]
在本公开中，由终端或外部服务器启用包的操作可以意味着通过将相应的SPB的状态改变为启用进行配置使得终端接收由包提供的服务(例如，通信服务、信用卡支付服务、用户认证服务等)的操作。处于启用状态的包可以被表示为“启用包”。处于启用状态的包可以以加密状态存储在SSP内部或外部的存储空间中。
[活动]
根据包外部输入(例如，用户输入、推送、终端中的应用请求、来自通信运营商的认证请求、PP管理消息等)或包内部的操作(例如，定时器、轮询)，可以将本公开中启用的包改变为活动。活动包可以表示该包从SSP内部或外部的存储空间加载到SSP内部的活动存储器中，使用SSP内部的安全CPU处理安全信息，并向终端提供安全服务。
[禁用]
在本公开中，终端或外部服务器禁用包的操作可以指通过将包状态改变为禁用来进行配置使得终端可能不能接收由包提供的服务的操作。被禁用的SPB可以被表示为“禁用包”。禁用包可以以加密状态存储在SSP内部或外部的存储空间中。
[删除]
在本公开中，终端或外部服务器删除包的操作可以意味着将包状态改变为删除或通过删除包括包的包的相关数据进行配置使得终端或外部服务器不再可以驱动、启用或禁用包的操作。处于删除状态的包可以被表示为“删除包”。
“包图像(或图像)”可以与包互换使用，或者可以用作表示特定包的数据对象的术语，并且可以被指代为包TLV或包图像TLV。当包图像被使用加密参数加密时，它可以被指代为受保护包图像(PBI)或受保护包图像TLV(PBI TLV)。当包图像被使用只能由特定SSP解密的加密参数加密时，它可以被指代为绑定包图像(BBI)或绑定包图像TLV(BBI TLV)。包图像TLV可以是以TLV(标签、长度、值)格式表示构成包的信息的数据集。
“包定界符”可以被指代为包标识符(SPB ID)、包族标识符(SPB族ID)、包族管理器标识符(SPB族保管者对象ID)、包匹配ID、事件标识符(事件ID)的匹配因子。包标识符(SPBID)可以指示每个包的对象标识符。包族标识符可以指示用于对包的类型进行分类的标识符(例如，用于接入移动通信公司网络的电信包)。在本公开中，包族标识符可以被指代为族ID、Fid或FID。包族管理器标识符可以指示标识管理包族标识符的主体(例如，通信服务提供商、终端制造商、特定组织等)的标识符。在本公开中，包族管理器标识符可以被指代为OID或Oid。包定界符可以用作能够在包管理服务器或终端中索引包的值。
“包元数据”是表示可以引用或描述包的一组信息的术语。包元数据可以包括上述包定界符。此外，包元数据还可以包括关于包的属性、特征或配置的信息。包元数据可以被表示为“元数据”。
“包管理服务器”可以包括根据来自服务提供商或其他包管理服务器的请求生成包、加密所生成的包、生成包远程管理指令或加密所生成的包远程管理指令的功能。提供上述功能的包管理服务器可以被表示为次级平台包管理器(SPBM)、远程包管理器(RBM)、图像递送服务器(IDS)、订阅管理器数据准备(SM-DP)、订阅管理器数据准备增强(SM-DP+)、管理器包服务器、管理订阅管理器数据准备增强(管理SM-DP+)、包加密服务器、包生成服务器、包供应商(BP)、包提供商或包供应凭证持有者(BPC持有者)中的至少一个。
在本公开中，包管理服务器可以执行从SSP下载、安装或更新包，以及管理用于包状态的远程管理的密钥和证书的配置的功能。提供上述功能的包管理服务器可以表示为次级平台包管理器(SPBM)、远程包管理器(RBM)、图像递送服务器(IDS)、订阅管理器安全路由(SM-SR)、订阅管理器安全路由增强(SM-SR+)、eUICC简档管理器或简档管理凭证持有者(PMC持有者)的卡外实体或eUICC管理器(EM)中的至少一个。
在本公开中，开放中继服务器可以从一个或多个包管理服务器或开放中继服务器接收事件注册请求(注册事件请求)。此外，可以复杂地使用一个或多个开放中继服务器，并且在这种情况下，第一开放中继服务器不仅可以从包管理服务器而且可以从第二开放中继服务器接收事件注册请求。在本公开中，开放中继服务器的功能可以被集成到包管理服务器中。提供上述功能的开放式中继服务器可以表示为次级平台包管理器(SPBM)、远程包管理器(RBM)、次级平台包发现服务器(SPBDS)、包发现服务器(BDS)、订阅管理器发现服务(SM-DS)、发现服务(DS)、根SM-DS或替代SM-DS中的至少一个。
在本公开中，包管理服务器可以共同指代生成、加密和传输包或包远程管理指令的功能与管理SSP和已安装包的配置的功能的组合。此外，包管理服务器可以共同指代开放中继服务器的组合功能。因此，在本公开的各种实施例中，包管理服务器和开放中继服务器的操作可以在一个包管理服务器中执行。此外，每个功能可以由彼此分离的多个包管理服务器划分和执行。此外，在本公开的说明书中，包管理服务器或开放中继服务器可以被表示为包服务器。包服务器可以是包管理服务器和开放中继服务器之一，或者可以是包括包管理服务器和开放中继服务器两者的设备。
“服务提供商”可以表示向包管理服务器发出请求包生成的要求并通过包向终端提供服务的商业实体。例如，服务提供商可以代表通过其中加载了通信应用的包来提供通信网络接入服务的移动运营商，并且可以共同指代通信运营商的业务支持系统(BSS)、运营支持系统(OSS)、销售点终端(POS)和其他IT系统中的所有。此外，在本公开中，服务提供商不限于仅表示一个特定的商业实体，而是可以用作指代一个或多个商业实体的团体或协会(或联合体)或代表该团体或协会的代表的术语。此外，在本公开中，服务提供商可以被指代为运营商(OP或Op.)、包所有者(BO)、图像所有者(IO)等，并且每个服务提供商可以接收名称和/或唯一标识符(OID)中的至少一个的配置或分配。当服务提供商指一个或多个商业的团体、协会或代表时，任何团体、协会或代表的名称或对象标识符可以是由附属于该团体或协会的所有商业实体或与该代表合作的所有商业实体共享的名称或对象标识符。
“用户”可以用作指拥有终端所有权的服务提供商或拥有终端所有权的终端用户的术语。一般而言，前者可被指代为M2M设备，而后者可被指代为消费者设备。在M2M设备的情况下，尽管它不拥有该设备的所有权，但是可能存在从服务提供商转让或租赁并使用该设备的终端用户，并且在这种情况下，该用户可能与服务提供商不同或相同。
“用户意图”可用作用户本地或远程管理包的意图的通用术语。此外，在本地管理的情况下，用户意图指的是终端用户意图，而在远程管理的情况下，用户意图可以用作指服务提供商意图的术语。
“终端用户同意”可以用作表示用户同意执行本地管理还是远程管理的术语。
“终端”可以用作移动站(MS)、用户设备(UE)、用户终端(UT)、无线终端、接入终端(AT)、终端、用户单元、用户站(SS)、无线设备、无线通信设备、无线发送/接收单元(WTRU)、移动节点、移动装置或其他术语。终端的各种实施例可以包括蜂窝电话、具有无线通信功能的智能电话、具有无线通信功能的个人数字助理(PDA)、无线调制解调器、具有无线通信功能的便携式计算机、具有无线通信功能的诸如数码相机的拍摄设备、具有无线通信功能的游戏设备、具有无线通信功能的音乐存储和回放设备、能够无线访问和浏览互联网的互联网家用设备、以及结合了这些功能的组合的便携式单元或终端。此外，终端可以包括机器对机器(M2M)设备和机器类型通信(MTC)终端/设备，但不限于此。在本公开中，终端可以被指代为电子设备。
在本公开中，可以通过下载包来安装的SSP可以嵌入在电子设备中。当SSP没有嵌入在电子设备中时，与电子设备物理分离的SSP可以插入到电子设备中并连接到电子设备。例如，SSP可以以卡的形式插入到电子设备中。电子设备可以包括终端，并且在这种情况下，终端可以是包括能够通过下载包来安装的SSP的终端。SSP可以嵌入在终端中，并且当终端和SSP分离时，SSP可以插入到终端中，并且可以插入到终端中以连接到终端。
“本地包助手(LBA)”可以指安装在终端或电子设备中以便控制SSP的软件或应用。该软件或应用可以被指代为本地包管理器(LBM)。
“次级平台包加载器(SPBL)”可以指在SSP中安装其他包并管理其启用、禁用和删除的管理包。终端或远程服务器的LBA可以通过加载器安装、启用、禁用或删除特定的包。在本公开中，加载器的操作可以被描述为包括加载器的SSP的操作。
“事件”可以是用于包下载、远程包管理或其他包或SSP的管理/处理指令的通用术语。事件可以被指代为远程包供应操作(RBP操作或RBP操作)或事件记录，并且每个事件可以被指代为包括对应事件标识符(事件ID，EventID)或匹配标识符(匹配ID，MatchingID)、存储该事件的包管理服务器或开放中继服务器的地址(FQDN、IP地址或URL)或每个服务器标识符中的至少一个的数据。包下载可以与包安装互换使用。此外，事件类型可以用作指示特定事件是包下载、远程包管理(例如，删除、启用、禁用、替换、更新等)还是其他包或SSP管理/处理指令的术语，并且可以被指代为操作类型(OperationType)、操作类(OperationClass)、事件请求类型、事件类、事件请求类等。
“本地包管理(LBM)”可以被指代为包本地管理、本地管理、本地管理命令、本地命令、本地包管理程序包(LBM程序包)、包本地管理程序包、本地管理程序包、本地管理命令程序包或本地命令程序包。LBM可以用于通过安装在终端中的软件安装任何包，改变特定包的状态(启用、禁用、删除)，或者更新特定包的内容(例如，包昵称或包元数据等)。LBM可以包括一个或多个本地管理命令，并且在这种情况下，针对每个本地管理命令的包对于每个本地管理命令可以是相同的或不同的。
“远程包管理(RBM)”可以被指代为包远程管理、远程管理、远程管理命令、远程命令、远程包管理程序包(RBM程序包)、包远程管理程序包、远程管理程序包、远程管理命令程序包或远程命令程序包。RBM可用于安装任何包，改变特定包的状态(启用、禁用、删除)，或更新特定包的内容(例如，包昵称或包元数据)。RBM可以包括一个或多个远程管理命令，并且针对每个远程管理命令的包对于每个远程管理命令可以是相同的或不同的。
“目标包”可以用作指代要作为本地管理命令或远程管理命令的目标的包的术语。
“包规则”可以被用作指代当对目标包执行本地管理或远程管理时终端应该识别的信息的术语。此外，包规则可以与诸如包策略、规则和策略等术语互换使用。
“证书”或数字证书可以表示用于基于由一对公钥(PK)和私钥(SK)组成的非对称密钥进行相互认证的数字证书。每个证书可以包括一个或多个公钥(PK)、对应于每个公钥的公钥标识符(PKID)、发布对应证书的证书发布者(CI)的标识符(证书发布者ID)和数字签名。此外，证书发布者可以被指代为认证发布者、证书机构(CA)、认证机构等。在本公开中，公钥(PK)和公钥标识符(PKID)可以互换使用，具有相同的含义，其指的是特定公钥或包括公钥的证书、特定公钥的一部分、包括公钥的证书的一部分、特定公钥的操作结果(例如，散列值)、包括对应公钥的证书的操作结果(例如，散列)、或特定公钥的一部分的操作结果(例如，散列)值、包括对应公钥的证书的一部分的操作结果(例如，散列)值、或存储数据的存储空间。
当由“证书发布者”发布的证书(初级证书)被用于发布其他证书(次级证书)时，或者当次级证书被用于联合发布第三级或更高级证书时，“证书链”或证书层级可以指示对应证书之间的相关性。在这种情况下，用于发布初始证书的CI证书可以被指代为证书根、顶级证书、根CI、根CI证书、根CA或根CA证书。
在描述本公开时，当确定相关已知功能或配置的详细描述可能不必要地模糊本公开的主题时，将省略其详细描述。
在下文中，将描述用于在终端之间移动和安装包的方法和设备的各种实施例。
图1是示出根据本公开实施例的SSP的概念图。
根据各种实施例，如图1的示例中，终端110可以包括SSP 120。例如，SSP 120可以嵌入在终端110的SoC 130中。在这种情况下，SoC 130可以是通信处理器、应用处理器或者集成了这两种处理器的处理器。又例如，SSP 120可以是以不集成到SoC中的独立芯片形式的可移除类型122，或者可以是预嵌入在终端110中的嵌入式类型124。
根据各种实施例，包括在终端中的SSP 120可以包括一个或多个电信包、一个或多个支付包或者一个或多个电子ID包中的至少一个。例如，如图1所示，当多个电信包140和150包括在SSP 120中时，通过根据配置使多个电信包140和150能够同时或以时分方式操作，终端110可以使用移动通信网络。此外，当支付包170和电子ID包180被包括在SSP 120中时，终端110可以使用支付包170通过终端app(应用)使用在线支付或者通过外部信用卡销售点(PoS)设备使用离线支付，并且使用电子ID包180验证终端所有者的身份。
图2是示出根据本公开实施例的智能安全平台(SSP)的内部结构的概念图。
根据各种实施例，如在图2的示例中，SSP 210可以包括一个主平台(PP)220和至少一个在其上操作的次级平台包(SPB)230和240。
根据各种实施例，主平台220可以包括硬件(未公开)和至少一个低级操作系统(LLOS)222。
根据各种实施例，次级平台包230可以包括高级操作系统(HLOS)232和在其上操作的至少一个应用234。
根据各种实施例，次级平台包230和240中的每一个可以使用主平台接口(PPI)250来访问诸如主平台220的中央处理器和存储器的资源，从而在SSP 210中被驱动。
图3是示出了根据本公开实施例的用于使终端能够将包下载到SSP并在SSP中安装包的终端内部组件的示例的图。
根据各种实施例，如图3的示例，终端310可以包括SSP 330和/或用于控制SSP 330的LBA 312。例如，终端310可以是其中安装了SSP 330并且其中安装了用于控制SSP 330的LBA 312的终端。例如，SSP 330可以嵌入在终端310中，或者是可以从终端310移除的。
根据各种实施例，SSP 330可以包括主平台331、次级平台包加载器(SPBL)333或一个或多个次级平台包335、337或339中的至少一个。
根据各种实施例，次级平台包335、337或339可以不在终端发布时安装在SSP 330内部，而是可以在发布后远程下载和安装。
根据各种实施例，如图3的示例中，每个包可以具有不同的包族标识符和/或包族管理器标识符341、342或343。这些包族标识符和包族管理器标识符可以用作下载和安装包所需的信息。也就是说，SSP 330或SPBL 333可以根据包族标识符和包族管理器标识符来允许或拒绝特定包的下载和安装。
图4是示出根据本公开的实施例的两个终端相互操作以便在两个终端之间发送包的方法的示例的图。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图4的示例中，第一终端400可以包括LBA 410和SSP 420，第二终端450可以包括LBA 460和SSP 470。
根据各种实施例，用户可以向终端发送命令，或者可以从终端接收用户应该接收的信息。例如，如在操作4010和4060中，第一用户440和第二用户490可以向第一终端400和第二终端450的LBA 410和460发送命令，或者可以从LBA 410和460接收用户应该接收的信息。
根据各种实施例，上述操作可以包括用户选择要发送的包的过程。此外，上述操作还可以包括识别用户要发送的包的信息的过程。此外，上述操作还可以包括批准是否发送要由用户发送的包的操作。此外，上述操作还可以包括批准是否发送要由用户接收的包的操作。
此外，根据各种实施例，上述操作可以包括用户选择包以便重新使用暂停的包的过程。此外，上述操作还可以包括识别关于用户已经接收到恢复使用的请求的包的信息的过程。此外，上述操作还可以包括批准用户再次使用包的操作。此外，上述操作还可以包括用户批准恢复使用已经接收到使用恢复请求的包的操作。
上述选择和批准的操作可以不都作为独立的操作来操作，并且可以彼此独立地选择和操作一个或多个操作。
此外，在操作4020和4070中，LBA 410和460可以向SSP 420和470发出命令，或者可以向SSP 420和470发送数据和从SSP 420和470接收数据。
根据一个示例，在上述操作中，LBA可以接收用户的命令并将该命令传输给SSP。在上述操作中，当LBA接收到用户的命令并将该命令传输到SSP时，作为结果，LBA可以接收到由SSP传输的结果。
根据另一个示例，在上述操作中，LBA可以将从另一个终端或外部服务器接收的命令或数据传输到SSP。在上述操作中，当LBA将从另一个终端或外部服务器接收的命令或数据传输到SSP时，作为结果，LBA可以接收由SSP传输的结果。
根据各种实施例，在上述操作中，LBA可基于用户的命令或从另一终端或外部服务器接收的命令或数据来定义新的命令和数据，并将其传输到SSP。在上述操作中，当LBA基于用户的命令或从另一个终端或外部服务器接收的命令或数据定义新的命令和数据并将其传输到SSP时，作为结果，LBA可以接收由SSP传输的结果。
根据各种实施例，在上述操作中，LBA和SSP可相互发送和接收数据，并安装包。
根据各种实施例，在操作4050中，两个LBA 410和460可以彼此连接，以向对方给出命令，或者向对方发送数据和从对方接收数据。在这种情况下，操作4050中的连接可以是终端之间的直接设备到设备连接，尽管未示出，但是它可以是设备之间的间接连接，其中外部实体(例如，外部服务器)连接在两个LBA 410和460之间。
两个LBA之间的上述连接方法的更详细描述参考以下附图。
根据各种实施例，在操作4030和4080中，SSP 420和470可以生成、处理或验证SSP内的必要数据。
根据各种实施例，在上述操作中，SSP可以识别包传输配置。此外，在上述操作中，SSP可以生成并利用包传输码。上述包传输配置相关操作和包传输码相关操作是独立的功能，并且可以不执行这两个功能，可以执行这两个功能中的任一个，或者可以执行这两个功能二者。即使当两种功能都被执行时，这两种功能也可以作为完全独立的功能来执行。
根据各种实施例，在上述操作中，SSP可以生成其SSP信息，或者验证从对方终端和/或服务器接收的SSP信息。此外，在上述操作中，SSP可以生成能够验证其自身的认证数据，或者可以验证从对方终端接收的认证数据。
根据各种实施例，在上述操作中，SSP可以生成将参考图5描述的“证明”，并验证接收到的“证明”。SSP可以生成/验证的各种“证明”的示例参考后面将要描述的图10到15和22到27。
根据各种实施例，在上述操作中，SSP可以配置包的状态。可由SSP配置的各种包的状态和配置条件参考稍后将描述的图10至15和22至27。
根据各种实施例，在上述操作中，SSP可以生成包。
图5是示出根据本公开的一些实施例的“证明”的配置的图。
根据各种实施例，证明可以可选地包括“包定界符”(510)。例如，证明可以可选地包括包标识符(SPB ID)，其是包定界符之一，如图5所示。
根据各种实施例，该证明可以可选地进一步包括另一证明(530)。包括在证明中的另一证明的各种示例参考稍后将描述的图10-15的描述。
根据各种实施例，证明可以可选地进一步包括“SSP标识符(SSP ID)”(540)。
根据各种实施例，证明可以可选地进一步包括关于由SSP执行的操作的信息(550)。由SSP执行的操作的各种示例参考稍后将描述的图10至15的描述。
根据各种实施例，如果必要，证明可以可选地进一步包括除了上述信息530、540和550之外的数据(520)。可以包括在证明中的其他数据的各种示例参考稍后将描述的图10-15的描述。
根据各种实施例，证明可以包括上述信息的数字签名数据(560)。签名数据可以是由SSP的签名证书生成的电子签名。
图6是概念性地图示了根据本公开的实施例的用于从一个终端向另一个终端发送包的过程的图。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图6的示例中，第一终端600可以包括第一LBA 620和第一SSP 610，第二终端650可以包括第二LBA 670和第二SSP 660。例如，第一终端600可以是其中安装了第一SSP 610并且其中安装了用于控制第一SSP 610的第一LBA 620的终端，第二终端650可以是其中安装了第二SSP 660并且其中安装了用于控制第二SSP 660的第二LBA 670的终端。
参考图6，在步骤6000中，第一终端600的第一SSP 610和第一LBA 620以及第二终端650的第二LBA 670可以执行包传输所需的准备过程(包传输准备过程)。该过程的更详细描述参考稍后将描述的图7的详细描述。
参考图6，在步骤6005中，可以执行从第一终端600向第二终端650发送包的过程(包传输过程)。该过程的更详细描述参考稍后将描述的图8的详细描述。
参考图6，在步骤6010，第一终端600和第二终端660可以执行发送的包的安装过程和配置包的状态的过程(包传输完成过程)。该过程的详细描述参考稍后将描述的图9至图12的详细描述。
图7是示出图6中呈现的过程当中用于准备包传输的过程的详细过程的图。更具体地，图7是示例性地示出根据本公开的实施例的一个终端经历向另一个终端发送包所需的准备过程的过程的图。在本说明书中，图7的过程可以被指代为包传输准备过程。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图7的示例中，第一终端700可以包括第一LBA 720和第一SSP 710，第二终端750可以包括第二LBA 770和第二SSP 760。例如，第一终端700可以是其中安装了第一SSP 710并且其中安装了用于控制第一SSP 710的第一LBA 720的终端，第二终端750可以是其中安装了第二SSP 760并且其中安装了用于控制第二SSP 760的第二LBA 770的终端。
根据各种实施例，第一终端700可以具有预安装的包，并且还具有与包相关联的元数据。
根据各种实施例，第一终端700可以与对应的包相关联，以具有包标识符(SPBID)、包族标识符(SPB族ID)或包族管理器标识符(SPB族保管者对象ID)中的至少一个。
根据各种实施例，第一终端700可以具有与对应的包相关联的“包传输配置”。包传输配置可任选地包含与包是否可在设备之间发送相关的信息。此外，包传输配置可以可选地进一步包括关于包是否可以在多个终端中重复使用的信息。例如，当包“被禁止在多个终端中同时重复使用”时，即，当“包在任何一个时间应该仅在一个终端中使用”时，包传输配置可以包括关于此的信息。
参考图7，在步骤7000中，关于要在设备之间发送的包的信息可以被传输到第一LBA 720。例如，如图7所示，传输过程可以通过其中用户通过由第一终端700提供的UI直接选择包的过程来进行，或者可以通过推送输入从远程服务器输入到第一LBA 720，或者第一LBA 720可以访问远程服务器以读取对应的信息。
参考图7，在步骤7005，与通过步骤7000选择的包相关的信息可以从第一LBA 720传输到第一SSP 710。例如，如图7所示，与所选包相关的信息可以通过选择SPB命令从第一LBA 720传输到第一SSP 710。在这种情况下，从第一LBA 720传输到第一SSP 710的信息可以包括用于识别在步骤7000中选择的包的信息。
参考图7，在步骤7010中，第一SSP 710可以识别被请求发送的包是否可以在设备之间发送。该过程可以通过基于在步骤7005中接收的信息识别其中请求传输的包并识别与该包相关联的“包传输配置”来执行。在这个过程中，当“包传输配置”包括“关于包是否可以在多个终端中重复使用的信息”时，第一SSP 710可以识别这个事实。
此外，在步骤7010中，第一SSP 710可以选择性地配置“包传输码”。“包传输码”是用于在设备之间发送包的过程中指代包的代码，并且应该是能够识别包的值。第一SSP 710可绑定上述“包传输码”和将被发送的包的信息。
参考图7，在步骤7015中，对步骤7005的响应结果可以从第一SSP 710发送到第一LBA 720。例如，如图7所示，对选择SPB命令的响应可以通过选择SPB响应从第一SPB 710传输到第一LBA 720。响应值可以包括步骤7010中描述的“包传输码”。
参考图7，在步骤7020，设备之间的包传输所需的信息可以从第一终端700的第一LBA 720传输到第二终端750的第二LBA 770。在这种情况下，从第一LBA 720传输到第二LBA770的信息可以包括“包传输码”。此外，从第一LBA 820传输到第二LBA 870的信息可以可选地进一步包括在未来步骤7025中要在第一LBA 720和第二LBA 770之间建立的连接所需的信息。此外，从第一LBA 720传输到第二LBA 770的信息可以可选地进一步包括指示设备之间的包传输将被执行的信息。
通过上述步骤7020从第一LBA 720传输到第二LBA 770的信息可以以各种方式传输。例如，第一LBA 720可以通过第一终端700的UI向用户提供将被传输到第二LBA 770的信息，并且用户可以使用第二终端750的UI将接收的信息输入到第二LBA 770。替代地，第一LBA720可以使得要传输到第二LBA 770的信息具有图像(例如，QR码)的形式，以在第一终端700的屏幕上显示图像，并且用户可以使用第二终端750扫描图像，以将信息传输到第二LBA770。然而，将信息从第一LBA 720传输到第二LBA 770的方法不限于上述方法。
参考图7，在步骤7025中，可以在第一LBA 720和第二LBA 770之间建立(或配置)连接。当在步骤7020发送连接所需的信息时，第一LBA 720和第二LBA 770可使用该信息建立连接。第一LBA 820和第二LBA 870之间的连接可以是直接的设备到设备连接(例如，NFC、蓝牙、UWB、WiFi-直连、LTE设备到设备(D2D)、5G D2D)或者可以是远程连接，其中远程服务器(例如，中继服务器)位于第一LBA 720和第二LBA 770之间。
参考图7，尽管步骤7025被示为最后一步，但是该步骤独立于上述其他步骤，即步骤7000、7005、7010、7015和7020，并且可以不考虑其他步骤的顺序而执行。例如，步骤7025可以在步骤7015和7020之间执行，在这种情况下，在步骤7020中从第一LBA 720发送到第二LBA 770的信息可以通过在步骤7025中建立的连接来发送。
图8是示出图6中呈现的过程当中发送包的过程的详细过程的图。更具体地，图8是示例性示出根据本公开实施例的一个终端向另一个终端发送包的过程的图。在本公开中，图8的过程可以被指代为包传输过程。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图8的示例中，第一终端800可以包括第一LBA 820和第一SSP 810，第二终端850可以包括第二LBA 870和第二SSP 860。例如，第一终端800可以是其中安装了第一SSP 810并且其中安装了用于控制第一SSP 810的第一LBA 820的终端，第二终端850可以是其中安装了第二SSP 860并且其中安装了用于控制第二SSP 860的第二LBA 870的终端。
参考图8，在步骤8000中，第二LBA 870可以向第二SSP 860请求“SSP信息(SspInfo)”。当第二LBA 870在步骤8000中向第二SSP 860请求“SspInfo”时，第二LBA 870可以通知第二SSP 860将执行设备之间的包移动。
此外，步骤8000可以在图8所示的过程之后立即自动执行，或者可以在接收到外部输入之后执行。在这种情况下，“外部输入”可以通过其中用户通过由第二终端850提供的UI直接选择要接收的包的过程来进行，或者可以通过推送输入从远程服务器输入到第二LBA870，或者第二LBA 870可以访问远程服务器以读取对应的信息。
参考图8，在步骤8005中，第二SSP 860可以生成其“SspInfo”。“SspInfo”可以包括关于将被提供用于包传输的第二SSP的信息。在这种情况下，“SspInfo”可包括用于证书协商过程(第二SSP 860在接收包之前应该经历)的信息(证书协商信息)。“证书协商信息”可包括第二SSP 860可用于验证另一SSP的证书信息(SenderSpblVerification)和另一SSP可用于验证自身的证书信息(ReceiverSpblVerification)。此外，“证书协商信息”可以可选地进一步包括第二SSP 860支持的密钥协商算法列表，并且可选地进一步包括第二SSP 860支持的加密算法列表。此外，“SspInfo”可以可选地进一步包括SSP版本信息，该SSP版本信息包括第二SSP 960中包括的加载器和主平台所支持的标准规范的版本信息中的至少一个。
参考图8，在步骤8010中，第二SSP 860可以通过第二LBA 870和第一LBA 820将在步骤8005中生成的“SspInfo”传输到第一SSP 810。
根据上述步骤8000至8010，第二LBA 870可以向第二SSP 860请求“SspInfo”，第二SSP 860可以生成其“SspInfo”，然后通过第二LBA 870和第一LBA 820将“SspInfo”传输给第一SSP 810。然而，根据该实施例，将“SspInfo”从第二终端850传输到第一终端800的过程可以如下。例如，在第二LBA 870自己生成“SspInfo”之后，第二LBA可以通过第一LBA 820将“SspInfo”传输给第一SSP 810。
参考图8，在步骤8015中，第一SSP 810可以识别所接收的“SspInfo”并生成“第一终端认证信息(Device1.Auth)”，其能够基于该信息认证自身。该过程的更详细的过程如下。
第一SSP 810可使用接收到的“SenderSpblVerification”来识别能够验证其自身的证书信息，并选择至少一个密钥协商证书(ssp1.Cert.KA)。替代地，第一SSP 810可使用接收到的“第二SSP 860支持的密钥协商算法列表”生成公钥“ssp1.ePK.KA”和私钥“ssp1.eSK.KA”作为将要用于密钥协商的非对称加密密钥对，然后在密钥对中选择公钥(ssp1.ePK.KA)。此外，第一SSP 810可使用接收的“SenderSpblVerification”识别能够验证其自身的证书信息，并进一步选择至少一个签名证书(ssp1.Cert.DS)。
此外，第一SSP 810可选择第二SSP 860的至少一个证书信息来使用接收的“ReceiverSpblVerification”执行验证，然后将对应的信息配置为“CiPkIdToBeUsed”。
此外，第一SSP 810可以使用接收到的“第二SSP 860支持的加密算法列表”来选择至少一个将来要使用的加密算法，然后将对应的信息配置为“CryptoToBeUsed”。
此外，第一SSP 810可以识别所接收的“第二SSP 860中包括的加载器和主平台所支持的标准规范的版本信息”的列表，并且识别在该列表中是否存在其自身所支持的标准规范的版本。
“第一终端认证信息(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验证以确保信息的完整性的数字签名，并且可以添加数字签名数据作为“第一终端认证信息”的部分。
参考图8，在步骤8020中，第一SSP 810可以经由第一LBA 820将在步骤8015中生成的“第一终端认证信息(Device1.Auth)”传输到第二LBA 870。
参考图8，在步骤8025中，第二LBA 870可以将“第一终端认证信息(Device1.Auth)”传输到第二SSP 860。此外，第二LBA 870还可以向第二SSP 860传输“包传输码”。
参考图8，在步骤8030中，第二SSP 860可以验证接收到的“第一终端认证信息(Device1.Auth)”。当第二SSP 860接收到“ssp1.Cert.KA”时，第二SSP 860可以识别对应证书的签名，以识别证书的有效性。此外，当第二SSP 860接收到“ssp1.ePK.KA”及其数字签名时，第二SSP 860可以首先检查ssp1.Cert.DS的有效性，然后使用该证书识别数字签名，从而识别接收的公钥ssp1.ePK.KA的完整性。此外，第二SSP 860可以识别接收的“CiPkIdToBeUsed”并选择能够验证自身的至少一个签名证书(ssp2.Cert.DS)。
此外，尽管图中未示出，但是在步骤8030中，第二SSP 960可生成公钥“ssp2.ePK.KA”和私钥“ssp2.eSK.KA”作为将要用于密钥协商的非对称加密的密钥对，然后在密钥对中选择公钥(ssp2.ePK.KA)。此外，第二SSP860可以选择ssp1.ePK.KA或包括在ssp1.Cert.KA中的用于密钥协商的公钥中的一个，然后生成会话密钥ShKey01，该会话密钥ShKey01将在将来使用该值和ssp2.eSK.KA与第一终端通信的同时用于加密。ShKey01应该是用于包括在接收到的“CryptoToBeUsed”中的加密算法的会话密钥。
此外，在步骤8030中，第二SSP 860可以生成能够认证自身的“第二终端认证信息(Device2.Auth)”。在这种情况下，“第二终端认证信息(Device2.Auth)”可以包括“ssp2.Cert.DS”。此外，“第二终端认证信息(Device2.Auth)”可能还包括“ssp2.ePK.KA”。此外，“第二终端认证信息(Device2.Auth)”可进一步包括指示由第二SSP 860生成的当前会话的事务ID。此外，“第二终端认证信息(Device2.Auth)”还可以包括“包传输码”。此外，“第二终端认证信息(Device2.Auth)”可以进一步包括第二SSP 960的SSP标识符。此外，“第二终端认证信息(Device2.Auth)”可以可选地进一步包括与将来要传输的包相关联的包族标识符(SPB族ID)或包族管理器标识符(SPB族保管者对象ID)中的至少一个。
在这种情况下，上述“第二终端认证信息(Device2.Auth)”的部分或全部可以是能够使用ssp2.Cert.DS验证以确保信息的完整性的数字签名，并且可以添加数字签名数据作为“第二终端认证信息”的部分。此外，“第二终端认证信息(Device2.Auth)”的部分或全部可以使用先前生成的会话密钥ShKey01来加密。
参考图8，在步骤8035中，第二SSP 860可以经由第二LBA 870和第一LBA 820将在步骤8030生成的“第二终端认证信息(Device2.Auth)”发送到第一SSP 810。在这种情况下，可以可选地进一步发送“包传输码”。
参考图8，在步骤8040，第一SSP 810可以验证接收到的“第二终端认证信息(Device2.Auth)”。第一SSP 810可以验证接收到的“ssp2.Cert.DS”的签名来验证对应证书的有效性。此外，第一SSP 810可以检查接收到的包族标识符(SPB族ID)和/或包族管理器标识符(SPB族保管者对象ID)是否是与自身要发送的包相关联的正确配置的值。此外，第一SSP 810可以存储接收到的事务ID和/或第二SSP 860的SSP标识符。此外，第一SSP 810可以将接收的事务ID或第二SSP 960的SSP标识符与当前正在进行的会话或要发送的包绑定。
在该过程中，当加密数据被包括在“第二终端认证信息(Device2.Auth)”中时，第一SSP 810可使用ssp1.eSK.KA或与在其ssp1.Cert.KA中包括的用于密钥协商的公钥对应的私钥和接收的ssp2.ePK.KA来生成会话密钥ShKey01，使用会话密钥解密加密的数据，然后执行验证过程。此外，在该过程中，当数字签名被包括在“第二终端认证信息(Device2.Auth)”中时。第一SSP 810可以使用“ssp2.Cert.DS”来验证接收到的数字签名的有效性。
此外，在步骤8040中，尽管在图8中未示出，但是第一SSP 810可以生成公钥“ssp1.bundle.ePK.KA”和私钥“ssp1.bundle.eSK.KA”作为将要用于密钥协商的非对称加密的密钥对。在这种情况下，密钥对“ssp1.bundle.ePK.KA和ssp1.bundle.eSK.KA”可以被配置为与先前生成的“ssp1.ePK.KA和ssp1.eSK.KA”相同的值。替代地，密钥对“ssp1.bundle.ePK.KA和ssp1.bundle.eSK.KA”可以被配置为与“先前使用的ssp1.Cert.KA中包括的公钥和对应的私钥”的值相同的值。此外，第一SSP 810可使用ssp1.bundle.eSK.KA和ssp2.ePK.KA生成会话密钥ShKey02。当“与包括在ssp1.Cert.Ka中的公钥相对应的私钥”或用于ssp1.bundle.eSK.KA的ssp1.eSK.KA被重复使用，会话密钥ShKey02的值还可以配置成先前生成的ShKey01的值
此外，在步骤8040中，第一SSP 810可以配置要发送到第二终端850的包和/或与该包相关联的元数据。在这种情况下，第一SSP 810可以使用接收到的“包传输码”来识别将由其自身发送的包。此外，要配置的包可以包括“ssp1.Cert.DS”。此外，要配置的包还可以包括“ssp1.bundle.ePK.KA”。此外，要配置的包还可以包括用于识别对应会话的事务ID。此外，要配置的包可以可选地进一步包括与要传输的包相关联的包标识符(SPB ID)、包族标识符(SPB族ID)或包族管理器标识符(SPB族保管者对象ID)中的至少一个。根据各种实施例，在步骤8040中配置的包(或与包相关联的元数据)中可以包括“包传输配置”。
根据各种实施例，可以在步骤8040中将使用ssp1.Cert.DS生成的数字签名数据添加到要配置的包中。也就是说，为上面指定的包的一些或所有组件生成的数字签名数据可以作为包的一部分被添加。此外，要配置的包中的一些或全部可以使用ShKey02加密。
参考图8，在步骤8045中，第一SSP 810可以经由第一LBA 820将在步骤8040中生成(配置)的包传输到第二LBA 870。在这种情况下，可以选择性地进一步发送与发送的包相关联的元数据。此外，可以进一步发送与所发送的包相关联的“包传输配置”。例如，“包传输配置”可以以单独的格式(例如，消息)发送，而不包括在包或元数据中。
图9是示出图6中呈现的过程当中完成包的传输的过程的详细过程的图。更具体地，图9示出了图示根据本公开的实施例的在终端中安装包的过程和在发送包之后配置包状态的过程的图的一个可能示例。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图9的示例中，第一终端900可以包括第一LBA 920和第一SSP 910，第二终端950可以包括第二LBA 970和第二SSP 960。例如，第一终端900可以是其中安装了第一SSP 910并且其中安装了用于控制第一SSP 910的第一LBA 920的终端，第二终端950可以是其中安装了第二SSP 960并且其中安装了用于控制第二SSP 960的第二LBA 970的终端。
1.安装包
参考图9，在步骤9000中，第二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可验证证书的有效性以认证第一SSP 910。当接收的数据包括加密的数据时，第二SSP 960可使用接收的ssp1.bundle.ePK.KA及其ssp2.eSK.KA生成会话密钥ShKey02，使用会话密钥解密加密的数据，然后执行验证。当接收的数据包括数字签名时，第二SSP 960可以验证ssp1.Cer.DS然后使用该证书验证数字签名的有效性。
2.识别包是否可以重复使用
此外，尽管图中未示出，但是第二LBA 970和/或第二SSP 960可以选择性地确定该包是否可以在多个终端中重复使用。一些可能的确定方法如下。作为一个可能的示例，当包传输配置包括关于包是否可以在多个终端中重复使用的信息时，第二LBA 970和/或第二SSP 960可以识别该信息以做出确定。作为另一个可能的示例，第二LBA 970和/或第二SSP960可以使用接收到的包族标识符(SPB族ID)和/或包族管理器标识符(SPB族保管者对象ID)来识别包是否可以在多个终端中重复使用。该过程是步骤9000的一部分，并且可以不考虑步骤9000中执行的过程的顺序来执行，或者可以在步骤9000之后执行。
3.配置包状态
如果包可以在多个终端中重复使用，则额外配置包状态的过程可能不是必要的。替代地，即使当第二LBA 970和/或第二SSP 960确定/不确定包是否可被重复使用时，根据第二LBA 970和/或第二SSP 960的实现，额外配置包状态的过程可能不是必要的。
图10是示出图6中呈现的过程当中完成包的传输的过程的另一详细过程的图。更具体地，图10是示出根据本公开的实施例的在终端中安装包的过程和在发送包之后配置包状态的过程的图的另一示例。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图10的示例中，第一终端1000可以包括第一LBA 1020和第一SSP 1010，第二终端1050可以包括第二LBA1070和第二SSP 1060。例如，第一终端1000可以是其中安装了第一SSP 1010并且其中安装了用于控制第一SSP 1010的第一LBA 1020的终端，第二终端1050可以是其中安装了第二SSP 1060并且其中安装了用于控制第二SSP 1060的第二LBA 1070的终端。
1.安装包
参考图10，在步骤10000中，第二LBA 1070和第二SSP 1060可以彼此协作以在第二终端1050中安装包。其详细描述参考图9的“包安装”过程。
2.识别包是否可以重复使用
此外，尽管图中未示出，但是第二LBA 1070和/或第二SSP 1060可以选择性地确定该包是否可以在多个终端中重复使用。其详细描述参考图9的“识别包是否可以重复使用”的过程。
3.配置包状态
如果包不能在多个终端中重复使用，则包状态被额外配置如下。替代地，即使当第二LBA 1070和/或第二SSP 1060确定/不确定包是否可以被重复使用时，也可以根据第二LBA 1070和/或第二SSP 1060的实现来执行额外配置包状态的过程，如下所述。
参考图10，在步骤10005中，第二SSP 1060可以将包状态配置为“转换中”。“转换中”意味着包已经被成功安装但还不可用的状态(此外，仅通过诸如“来自另一个终端的请求(例如，通过发送“finalizationResponse(终结响应)或recoveryRequest(恢复请求)”做出的请求)和/或“来自外部服务器的请求(尽管在本公开中没有描述)”的额外操作而可以被改变为可用状态(禁用、启用、活动状态)的状态)。
参考图10，在步骤10010中，第二LBA 1070可以向第二SSP 1060请求“证明”。
参考图10，在步骤10015中，第二SSP 1060可以生成“证明”。在图10中，该证明可以被称为finalizationRequest(终结请求)。证明的结构可以遵循图5中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-finalizationRequest可以在510中包括包的“包定界符”。
-finalizationRequest可以在540中包括第二SSP的“SSP标识符”。
-finalizationRequest可以在550中包括指示第二SSP已经将包状态配置为“转换中”状态的信息。
-finalizationRequest可以可选地在520中包括其中第二SSP将包状态改变为“转换中”状态的时间或者其中生成证明的时间。
-finalizationRequest可以在560中包括第二SSP的签名信息。签名可以是通过用第二SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图10，在步骤10020中，第二SSP 1060可以向第一SSP 1010传输finalizationRequest。例如，第二SSP 1060可以通过以下过程将finalizationRequest传输到第一SSP 1010。也就是说，响应于步骤10010，第二SSP 1060可以将finalizationRequest传输到第二LBA 1070，并且第二LBA可以通过第一LBA 1020将finalizationRequest传输到第一SSP。
参考图10，在步骤10025中，第一SSP 1010可以验证接收到的finalizationRequest。验证过程可以包括检查包含在finalizationRequest中的第二SSP的签名的有效性的步骤。此外，验证过程还可包括检查包括在finalizationRequest中的“包定界符”是否与对应包的包定界符匹配的过程。此外，验证过程还可以包括检查包含在finalizationRequest中的“SSP标识符”是否是第二SSP的有效标识符的过程。此外，验证过程还可以包括识别包括在finalizationRequest中的指令信息是否是将包状态改变为“转换中”状态的指令信息的过程。
此外，在步骤10025中，第一SSP 1010可以在验证完成之后删除该包。
此外，在步骤10025中，第一SSP 1010可以生成“证明”。在图10中，该证明可以被称为finalizationResponse。证明的结构可以遵循图5中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-finalizationResponse可以在510中包括包的“包定界符”。
-finalizationResponse可以在540中包括第一SSP的“SSP标识符”。
-finalizationResponse可以在550中包括指示第一SSP已经删除了包的信息。
-finalizationResponse可以可选地在520中包括其中第一SSP删除包的时间或者其中生成证明的时间。
-finalizationResponse可以在560中包括第一SSP的签名信息。签名可以是通过用第一SSP的签名证书对上述信息进行数字签名而获得的签名信息。
此外，可能的证明配置的另一个示例如下。
-finalizationResponse可以在530中包括接收到的finalizationRequest。在这种情况下，根据需要，可以省略所接收的finalizationRequest的一些信息。例如，在某些情况下，包括在finalizationRequest中的第二SSP的签名信息可以被省略。此外，例如，在某些情况下可以省略包括在finalizationRequest中的时间信息。
-finalizationResponse可以在540中包括第一SSP的“SSP标识符”。
-finalizationResponse可以在550中包括指示第一SSP已经删除了包的信息。
-finalizationResponse可以可选地在520中包括其中第一SSP删除包的时间或者其中生成证明的时间。
-finalizationResponse可以在560中包括第一SSP的签名信息。签名可以是通过用第一SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图10，在步骤10030中，第一SSP 1010可以向第二SSP 1060传输finalizationResponse。例如，第一SSP 1010可以经由第一LBA 1020和第二LBA 1070向第二SSP 1060传输finalizationResponse。
参考图10，在步骤10035中，第二SSP 1060可以验证接收到的finalizationResponse。验证过程可以包括检查包含在finalizationResponse中的第一SSP的签名的有效性的步骤。此外，验证过程可以可选地进一步包括检查包括在finalizationResponse中的“包定界符”是否匹配对应包的包定界符的过程。此外，验证过程可以可选地进一步包括检查包括在finalizationResponse中的finalizationRequest是否匹配其自身已经发送的信息的过程。此外，验证过程还可以包括识别包含在finalizationResponse中的“SSP标识符”的过程。此外，验证过程还可以包括识别包括在finalizationResponse中的指令信息是否是删除包的指令信息的过程。
此外，在步骤10035中，在验证完成之后，第二SSP 1060可以将包状态改变为可用状态之一(禁用、启用和活动之一)。例如，如图所示，第二SSP 1060可以将包状态转换为禁用状态。
参考图10，在步骤10040中，第二SSP 1060可以将在步骤10035中执行的操作的结果(例如，成功还是失败)发送到第二LBA 1070。
图11是示出图6中呈现的过程当中完成包的传输的过程的另一详细过程的图。更具体地，图11是图示根据本公开实施例的在终端中安装包的过程和在发送包之后配置包状态的过程的图的另一示例。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图11的示例中，第一终端1100可以包括第一LBA 1120和第一SSP 1110，第二终端1150可以包括第二LBA1170和第二SSP 1160。例如，第一终端1100可以是其中安装了第一SSP 1110并且其中安装了用于控制第一SSP 1110的第一LBA 1120的终端，第二终端1150可以是其中安装了第二SSP 1160并且其中安装了用于控制第二SSP 1160的第二LBA 1170的终端。
1.安装包
参考图11，在步骤11000中，第二LBA 1170和第二SSP 1160可以彼此协作以在第二终端1150中安装包。其详细描述参考图9的“包安装”过程。
2.识别包是否可以重复使用
此外，尽管图中未示出，但是第二LBA 1170和/或第二SSP 1160可以选择性地确定该包是否可以在多个终端中重复使用。其详细描述参考图9的“识别该包是否可以重复使用”的过程。
3.配置包状态
如果包不能在多个终端中重复使用，则包状态被额外配置如下。可选地，即使当第二LBA 1170和/或第二SSP 1160确定/不确定包是否可以被重复使用时，也可以根据第二LBA 1170和/或第二SSP 1160的实现来执行额外配置包状态的过程，如下所述。
参考图11，在步骤11005中，第二SSP 1160可以将包状态配置为“转换中”。对“转换中”状态的描述参考对步骤10005的描述。
参考图11，在步骤11010，第二LBA 1170可以向第二SSP 1160请求“证明”。
参考图11，在步骤11015中，第二SSP 1160可以生成“证明”。在图11中，该证明可以被称为finalizationRequest。证明的结构可以遵循图5中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-finalizationRequest可以在510中包括包的“包定界符”。
-finalizationRequest可以在540中包括第二SSP的“SSP标识符”。
-finalizationRequest可以在550中包括指示第二SSP已经将包状态配置为“转换中”状态的信息。
-finalizationRequest可以可选地在520中包括其中第二SSP将包状态改变为“转换中”状态的时间或者其中生成证明的时间。
-finalizationRequest可以在560中包括第二SSP的签名信息。签名可以是通过用第二SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图11，在步骤11020中，第二SSP 1160可以向第一SSP 1110传输finalizationRequest。例如，第二SSP 1160可以通过以下过程将finalizationRequest传输到第一SSP 1110。也就是说，响应于步骤11010，第二SSP 1160可以将finalizationRequest传输到第二LBA 1170，并且第二LBA可以通过第一LBA 1120将finalizationRequest传输到第一SSP。
参考图11，在步骤11025中，第一SSP 1110可以验证接收到的finalizationRequest。验证过程可以包括检查包含在finalizationRequest中的第二SSP的签名的有效性的步骤。此外，验证过程还可包括检查包括在finalizationRequest中的“包定界符”是否与对应包的包定界符匹配的过程。此外，验证过程还可以包括检查包含在finalizationRequest中的“SSP标识符”是否是第二SSP的有效标识符的过程。此外，验证过程还可以包括识别包括在finalizationRequest中的指令信息是否是将包状态改变为“转换中”状态的指令信息的过程。
此外，在步骤11025中，在验证完成之后，第一SSP 1110可以将包状态配置为“转换中”状态。
此外，在步骤11025中，第一SSP 1110可以生成“证明”。在图11中，该证明可以被称为finalizationResponse。证明的结构可以遵循图5中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-finalizationResponse可以在510中包括包的“包定界符”。
-finalizationResponse可以在540中包括第一SSP的“SSP标识符”。
-finalizationResponse可以在550中包括指示第一SSP已经将包状态改变为“转换中”状态的信息。
-finalizationResponse可以可选地在520中包括其中第一SSP改变包状态的时间或者其中生成证明的时间。
-finalizationResponse可以在560中包括第一SSP的签名信息。签名可以是通过用第一SSP的签名证书对上述信息进行数字签名而获得的签名信息。
此外，可能的证明配置的另一个示例如下。
-finalizationResponse可以在530中包括接收到的finalizationRequest。在这种情况下，根据需要，可以省略所接收的finalizationRequest的一些信息。例如，在某些情况下，包括在finalizationRequest中的第二SSP的签名信息可以被省略。此外，例如，在某些情况下可以省略包括在finalizationRequest中的时间信息。
-finalizationResponse可以在540中包括第一SSP的“SSP标识符”。
-finalizationResponse可以在550中包括指示第一SSP已经将包状态改变为“转换中”状态的信息。
-finalizationResponse可以可选地在520中包括其中第一SSP改变包状态的时间或者其中生成证明的时间。
-finalizationResponse可以在560中包括第一SSP的签名信息。签名可以是通过用第一SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图11，在步骤11030中，第一SSP 1110可以向第二SSP 1160传输finalizationResponse。例如，第一SSP 1110可以经由第一LBA 1120和第二LBA 1170向第二SSP 1160传输finalizationResponse。
参考图11，在步骤11035中，第二SSP 1160可以验证接收到的finalizationResponse。验证过程可以包括检查包含在finalizationResponse中的第一SSP的签名的有效性的步骤。此外，验证过程可以可选地进一步包括检查包括在finalizationResponse中的“包定界符”是否匹配对应包的包定界符的过程。此外，验证过程可以可选地进一步包括检查包括在finalizationResponse中的finalizationRequest是否与由第二SSP 1160发送的信息相匹配的过程。此外，验证过程还可以包括识别包含在finalizationResponse中的“SSP标识符”的过程。此外，验证过程可以进一步包括识别包括在finalizationResponse中的指令信息是否正确的过程。
此外，在步骤11035中，在验证完成之后，第二SSP 1160可以将包状态改变为可用状态之一(禁用、启用和活动之一)。例如，如图所示，第二SSP 1160可以将包状态转换为禁用状态。
此外，在步骤11035中，第二SSP 1160可以生成“证明”。在图10中，证明可以被称为spblAttestation。证明的结构可以遵循图5中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-spblAttestation可以在510中包括包的“包定界符”。
-spblAttestation可以在540中包括第二SSP的“SSP标识符”。
-spblAttestation可以在550中包括指示第二SSP已经将包状态改变为可用状态的信息。
-spblAttestation可以可选地在520中包括其中第二SSP改变包状态的时间或者其中生成证明的时间。
-spblAttestation可以在560中包括第二SSP的签名信息。签名可以是通过用第二SSP的签名证书对上述信息进行数字签名而获得的签名信息。
此外，可能的证明配置的另一个示例如下。
-spblAttestation可以在530中包括接收到的finalizationResponse。在这种情况下，根据需要，可以省略所接收的finalizationResponse的一些信息。例如，在某些情况下，finalizationResponse中包含的签名信息的部分可能会被省略。此外，例如，在某些情况下可以省略finalizationResponse中包括的时间信息的部分。
-spblAttestation可以在540中包括第二SSP的“SSP标识符”。
-spblAttestation可以在550中包括指示第二SSP已经将包状态改变为可用状态的信息。
-spblAttestation可以可选地在520中包括其中第二SSP改变包状态的时间或者其中生成证明的时间。
-spblAttestation可以在560中包括第二SSP的签名信息。签名可以是通过用第二SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图11，在步骤11040中，第二SSP 1160可以将spblAttestation传输给第一SSP1110。例如，第二SSP 1160可以经由第二LBA 1170和第一LBA 1120将spblAttestation传输到第一SSP。
参考图11，在步骤11045中，第一SSP 1110可以验证接收到的spblAttestation。验证过程可以包括检查包含在spblAttestation中的第二SSP的签名的有效性的步骤。此外，验证过程还可以包括检查spblAttestation中包括的“包定界符”是否与对应包的包定界符相匹配的过程。此外，验证过程可以可选地进一步包括检查spblAttestation中包括的finalizationResponse是否与第一SSP 1110已经发送的信息相匹配的过程。此外，验证过程还可以包括检查spblAttestation中包含的“SSP标识符”是否是第二SSP的有效标识符的步骤。此外，验证过程还可以包括识别spblAttestation中包括的指令信息是否是将包状态改变为可用状态的指令信息的过程。
此外，在步骤11045中，第一SSP 1110可以在验证完成之后删除包。
图12是示出图6中呈现的过程当中完成包的传输的过程的另一详细过程的图。更具体地，图12是图示根据本公开实施例的在终端中安装包的过程和在发送包之后配置包状态的过程的图的另一示例。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图12的示例中，第一终端1200可以包括第一LBA 1220和第一SSP 1210，第二终端1250可以包括第二LBA1270和第二SSP 1260。例如，第一终端1200可以是其中安装了第一SSP 1210并且其中安装了用于控制第一SSP 1210的第一LBA 1220的终端，第二终端1250可以是其中安装了第二SSP 1260并且其中安装了用于控制第二SSP 1260的第二LBA 1270的终端。
1.安装包
参考图12，在步骤12000中，第二LBA 1270和第二SSP 1260可以彼此协作以在第二终端1250中安装包。其详细描述参考图9的“包安装”过程。
2.识别包是否可以重复使用
此外，尽管图中未示出，但是第二LBA 1270和/或第二SSP 1260可以选择性地确定该包是否可以在多个终端中重复使用。其详细描述参考图9的“识别包是否可以重复使用”的过程。
3.配置包状态
如果包不能在多个终端中重复使用，则包状态被额外配置如下。替代地，即使当第二LBA 1270和/或第二SSP 1260确定/不确定包是否可以被重复使用时，也可以根据第二LBA 1270和/或第二SSP 1260的实现来执行额外配置包状态的过程，如下所述。
参考图12，在步骤12005中，第二SSP 1260可以将包状态配置为“转换中”。对“转换中”状态的描述参考对步骤10005的描述。
参考图12，在步骤12010中，第二LBA 1270可以向第二SSP 1260请求“证明”。
参考图12，在步骤12015中，第二SSP 1260可以生成“证明”。在图12中，该证明可以被称为finalizationRequest。证明的结构可以遵循图5中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-finalizationRequest可以在510中包括包的“包定界符”。
-finalizationRequest可以在540中包括第二SSP的“SSP标识符”。
-finalizationRequest可以在550中包括指示第二SSP已经将包状态配置为“转换中”状态的信息。
-finalizationRequest可以可选地在520中包括其中第二SSP将包状态改变为“转换中”状态的时间或者其中生成证明的时间。
-finalizationRequest可以在560中包括第二SSP的签名信息。签名可以是通过用第二SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图12，在步骤12020中，第二SSP 1260可以向第一SSP 1210传输finalizationRequest。例如，第二SSP 1260可以通过以下过程将finalizationRequest传输到第一SSP 1210。也就是说，响应于步骤12010，第二SSP 1260可以将finalizationRequest传输到第二LBA 1270，并且第二LBA可以通过第一LBA 1220将finalizationRequest传输到第一SSP。
参考图12，在步骤12025中，第一SSP 1210可以验证接收到的finalizationRequest。验证过程可以包括检查包含在finalizationRequest中的第二SSP的签名的有效性的步骤。此外，验证过程还可包括检查包含在finalizationRequest中的“包定界符”是否与对应包的包定界符相匹配的过程。此外，验证过程还可以包括检查包含在finalizationRequest中的“SSP标识符”是否是第二SSP的有效标识符的过程。此外，验证过程还可以包括识别包括在finalizationRequest中的指令信息是否是将包状态改变为“转换中”状态的指令信息的过程。
此外，在步骤12025中，在验证完成之后，第一SSP 1210可以将包状态配置为“暂停”状态。“暂停”意味着包不可用的状态(此外，仅通过“来自另一个终端的请求(例如，通过发送recoveryRequest做出的请求)”和/或“来自外部服务器的请求(尽管在本公开中没有描述)”而可以被改变为可用状态(禁用、启用、活动状态)的状态)。此外，尽管图中未示出，但是上述“暂停”状态可以用“转换中”状态来代替。
此外，在步骤12025中，第一SSP 1210可以生成“证明”。在图12中，该证明可以被称为finalizationResponse。证明的结构可以遵循图5中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-finalizationResponse可以在510中包括包的“包定界符”。
-finalizationResponse可以在540中包括第一SSP的“SSP标识符”。
-finalizationResponse可以在550中包括指示第一SSP已经将包状态改变为“暂停”(或转换中)状态的信息。
-finalizationResponse可以可选地在520中包括其中第一SSP改变包状态的时间或者其中生成证明的时间。
-finalizationResponse可以在560中包括第一SSP的签名信息。签名可以是通过用第一SSP的签名证书对上述信息进行数字签名而获得的签名信息。
此外，可能的证明配置的另一个示例如下。
-finalizationResponse可以在530中包括接收到的finalizationRequest。在这种情况下，根据需要，可以省略所接收的finalizationRequest的一些信息。例如，在某些情况下，包括在finalizationRequest中的第二SSP的签名信息可以被省略。此外，例如，在某些情况下可以省略包括在finalizationRequest中的时间信息。
-finalizationResponse可以在540中包括第一SSP的“SSP标识符”。
-finalizationResponse可以在550中包括指示第一SSP已经将包状态改变为“暂停”(或转换中)状态的信息。
-finalizationResponse可以可选地在520中包括其中第一SSP改变包状态的时间或者其中生成证明的时间。
-finalizationResponse可以在560中包括第一SSP的签名信息。签名可以是通过用第一SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图12，在步骤12030中，第一SSP 1210可以向第二SSP 1260传输finalizationResponse。例如，第一SSP 1210可以经由第一LBA 1220和第二LBA 1270向第二SSP 1260传输finalizationResponse。
参考图12，在步骤12035中，第二SSP 1260可以验证接收到的finalizationResponse。验证过程可以包括检查包含在finalizationResponse中的第一SSP的签名的有效性的步骤。此外，验证过程可以可选地进一步包括检查包含在finalizationResponse中的“包定界符”是否与对应包的包定界符相匹配的过程。此外，验证过程可以可选地进一步包括检查包含在finalizationResponse中的finalizationRequest是否与第二SSP 1260已经发送的信息相匹配的过程。此外，验证过程还可以包括识别包含在finalizationResponse中的“SSP标识符”的过程。此外，验证过程可以进一步包括识别包括在finalizationResponse中的指令信息是否正确的过程。
此外，在步骤12035中，在验证完成之后，第二SSP 1260可以将包状态改变为可用状态之一(禁用、启用和活动之一)。例如，如图所示，第二SSP1260可以将包状态转换为禁用状态。
参考图12，在步骤12040中，第二SSP 1260可以将在步骤12035中执行的操作的结果(例如，成功还是失败)发送到第二LBA 1270。
图13是示出用于使已经暂停使用的包再次可用的过程的示例的图。更具体地，图13是示出用于将处于“转换中”状态或“暂停”状态的包再次配置为可用状态的过程的图的示例。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图13的示例中，第一终端1300可以包括第一LBA 1320和第一SSP 1310，第二终端1350可以包括第二LBA1370和第二SSP 1360。例如，第一终端1300可以是其中安装了第一SSP 1310并且其中安装了用于控制第一SSP 1310的第一LBA 1320的终端，第二终端1350可以是其中安装了第二SSP 1360并且其中安装了用于控制第二SSP 1360的第二LBA 1370的终端。
在执行图13中公开的过程之前，包状态被配置为“转换中”状态或“暂停”状态的情况的可能示例如下。例如，在图11中公开的包的传输完成的步骤中，当执行了步骤11025但是没有执行步骤11045时，第一终端1300中的包状态将被配置为“转换中”状态。作为另一个示例，当在图12中公开的包的传输完成的步骤中执行步骤12025时，第一终端1300中的包状态将被配置为“转换中”状态或“暂停”状态。
参考图13，在步骤13000，关于请求恢复使用的包的信息可以被传输到第二LBA1370。传输过程可以通过用户通过由第二终端1350提供的UI直接选择包的过程来进行，或者可以通过推送输入从远程服务器输入到第二LBA 1370，或者第二LBA 1370可以访问远程服务器以读取对应的信息。
参考图13，在步骤13005中，关于在步骤13000中选择的包的信息可以从第二LBA1370传输到第二SSP 1360。在这种情况下，从第二LBA 1370传输到第二SSP 1360的信息可以包括用于识别在步骤13000中选择的包的信息。
参考图13，在步骤13010中，第二SSP 1360可以删除对应的包。此外，第二SSP 1360可以生成“证明”。在图13中，该证明可以被称为recoveryRequest。证明的结构可以遵循图5中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-recoveryRequest可以在510中包括包的“包定界符”。
-recoveryRequest可以在540中包括第二SSP的“SSP标识符”。
-recoveryRequest可以在550中包括指示第二SSP已经删除了包的信息。
-recoveryRequest可以可选地在520中包括其中第二SSP删除包的时间或者其中生成证明的时间。
-recoveryRequest可以在560中包括第二SSP的签名信息。签名可以是通过用第二SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图13，在步骤13015中，第二SSP 1360可以向第一SSP 1310传输recoveryRequest。例如，第二SSP 1360可以通过以下过程将recoveryRequest传输给第一SSP 1310。也就是说，响应于步骤13005，第二SSP 1360可以将recoveryRequest传输到第二LBA 1370，并且第二LBA 1370可以经由第一LBA 1320将recoveryRequest传输到第一SSP1310。
参考图13，在步骤13020中，第一SSP 1310可以验证接收到的recoveryRequest。验证过程可以包括检查包含在recoveryRequest中的第二SSP 1360的签名的有效性的步骤。此外，验证过程可进一步包括识别包含在recoveryRequest中的“包定界符”的过程。此外，验证过程还可以包括检查包含在recoveryRequest中的“SSP标识符”的过程。此外，验证过程可以进一步包括识别recoveryRequest中包括的指令信息是否是删除包的指令信息的过程。
此外，在步骤13020中，在验证完成之后，第一SSP 1310可以将包状态改变为可用状态之一(禁用、启用和活动之一)。例如，如图所示，第一SSP 1310可以将包状态转换为禁用状态。
参考图13，在步骤13025中，第一SSP 1310可以将在步骤13020中执行的操作的结果(例如，成功还是失败)发送到第一LBA 1320。
图14是示出用于使已经暂停使用的包再次可用的另一过程的示例的图。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图14的示例中，第一终端1400可以包括第一LBA 1420和第一SSP 1410，第二终端1450可以包括第二LBA1470和第二SSP 1460。例如，第一终端1400可以是其中安装了第一SSP 1410并且其中安装了用于控制第一SSP 1410的第一LBA 1420的终端，第二终端1450可以是其中安装了第二SSP 1460并且其中安装了用于控制第二SSP 1460的第二LBA 1470的终端。
在执行图14中公开的过程之前，包状态被配置为“转换中”状态或“暂停”状态的情况的可能示例如下。例如，在图11中公开的包的传输完成的步骤中，当执行了步骤11025但是没有执行步骤11045时，第一终端1400中的包的状态将被配置为“转换中”状态。作为另一个示例，在图12中公开的包的传输完成的步骤中，当执行步骤12025时，第一终端1400中的包的状态将被配置为“转换中”状态或“暂停”状态。
参考图14，在步骤14000，关于请求恢复使用的包的信息可以被传输到第二LBA1470。传输过程可以通过用户通过由第二终端1450提供的UI直接选择包的过程来进行，或者可以通过推送输入从远程服务器输入到第二LBA 1470，或者第二LBA 1470可以访问远程服务器以读取对应的信息。
参考图14，在步骤14005中，关于在步骤14000中选择的包的信息可以从第二LBA1470传输到第二SSP 1460。在这种情况下，从第二LBA 1470传输到第二SSP 1460的信息可以包括用于识别在步骤14000中选择的包的信息。
参考图14，在步骤14010中，第二SSP 1460可以将包状态配置为“转换中”状态。此外，第二SSP 1460可以生成与包状态改变相关的“证明”。在图14中，该证明可以被称为recoveryRequest。证明的结构可以遵循图5中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-recoveryRequest可以在510中包括包的“包定界符”。
-recoveryRequest可以在540中包括第二SSP的“SSP标识符”。
-recoveryRequest可以在550中包括指示第二SSP已经将包状态配置为“转换中”状态的信息。
-recoveryRequest可以可选地在520中包括其中第二SSP改变包状态的时间或者其中生成证明的时间。
-recoveryRequest可以在560中包括第二SSP的签名信息。签名可以是通过用第二SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图14，在步骤14015中，第二SSP 1460可以向第一SSP 1410传输recoveryRequest。例如，第二SSP 1460可以通过以下过程将recoveryRequest传输给第一SSP 1410。也就是说，响应于步骤14005，第二SSP 1460可以将recoveryRequest传输到第二LBA 1470，并且第二LBA 1470可以经由第一LBA 1420将recoveryRequest传输到第一SSP1410。
参考图14，在步骤14020中，第一SSP 1410可以验证接收到的recoveryRequest。验证过程可以包括检查包含在recoveryRequest中的第二SSP 1460的签名的有效性的步骤。此外，验证过程可进一步包括识别包含在recoveryRequest中的“包定界符”的过程。此外，验证过程还可以包括识别包含在recoveryRequest中的“SSP标识符”的过程。此外，验证过程还可以包括识别包括在recoveryRequest中的指令信息是否是将包状态改变为“转换中”状态的指令信息的过程。
此外，在步骤14020中，在验证完成之后，第一SSP 1410可以将包状态改变为可用状态之一(禁用、启用和活动之一)。例如，如图所示，第一SSP 1410可以将包状态转换为禁用状态。
此外，在步骤14020中，第一SSP 1410可以生成“证明”。在图14中，该证明可以被称为recoveryResponse(恢复响应)。证明的结构可以遵循图5中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-recoveryResponse可以在510中包括对应包的“包定界符”。
-recoveryResponse可以在540中包括第一SSP的“SSP标识符”。
-recoveryResponse可以在550中包括指示第一SSP已经将包状态改变为可用状态的信息。
-recoveryResponse可以可选地在520中包括其中第一SSP改变包状态的时间或者其中生成证明的时间。
-recoveryResponse可以在560中包括第一SSP的签名信息。签名可以是通过用第一SSP的签名证书对上述信息进行数字签名而获得的签名信息。
此外，可能的证明配置的另一个示例如下。
-recoveryResponse可以在530中包括接收到的recoveryRequest。在这种情况下，根据需要，可以省略接收到的recoveryRequest的一些信息。例如，包括在recoveryRequest中的第二SSP的签名信息在一些情况下可以被省略。此外，例如，在一些情况下可以省略recoveryRequest中包括的时间信息。
-recoveryResponse可以在540中包括第一SSP的“SSP标识符”。
-recoveryResponse可以在550中包括指示第一SSP已经将包状态改变为可用状态的信息。
-recoveryResponse可以可选地在520中包括其中第一SSP改变包状态的时间或者其中生成证明的时间。
-recoveryResponse可以在560中包括第一SSP的签名信息。签名可以是通过用第一SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图14，在步骤14025中，第一SSP 1410可以向第二SSP 1460传输recoveryResponse。例如，第一SSP 1410可以经由第一LBA 1420和第二LBA 1470向第二SSP1460传输recoveryResponse。
参考图14，在步骤14030中，第二SSP 1460可以验证接收到的recoveryResponse。验证过程可以包括检查包含在recoveryResponse中的第一SSP 1460的签名的有效性的步骤。此外，验证过程可以可选地进一步包括检查包含在recoveryResponse中的“包定界符”是否与对应包的包定界符相匹配的过程。此外，验证过程可以可选地进一步包括检查包含在recoveryResponse中的recoveryRequest是否与第二SSP 1460已经发送的信息相匹配的过程。此外，验证过程还可以包括识别包含在recoveryResponse中的“SSP标识符”的过程。此外，验证过程可以进一步包括识别包括在recoveryResponse中的指令信息是否是正确的指令信息的过程。
此外，在步骤14030中，第二SSP 1460可以在验证完成之后删除包。
参考图14，在步骤14035中，第二SSP 1460可以将在步骤14030中执行的操作的结果(例如，成功还是失败)发送到第二LBA 1470。
图15是示出用于使已经暂停使用的包再次可用的另一过程的示例的图。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图15的示例中，第一终端1500可以包括第一LBA 1520和第一SSP 1510，第二终端1550可以包括第二LBA1570和第二SSP 1560。例如，第一终端1500可以是其中安装了第一SSP 1510并且其中安装了用于控制第一SSP 1510的第一LBA 1520的终端，第二终端1550可以是其中安装了第二SSP 1560并且其中安装了用于控制第二SSP 1560的第二LBA 1570的终端。
在执行图15中公开的过程之前，包状态被配置为“转换中”状态或“暂停”状态的情况的可能示例如下。例如，在图11中公开的包的传输完成的步骤中，当执行了步骤11025但是没有执行步骤11045时，第一终端1500中的包的状态将被配置为“转换中”状态。作为另一个示例，在图12中公开的包的传输完成的步骤中，当执行步骤12025时，第一终端1500中的包的状态将被配置为“转换中”状态或“暂停”状态。
参考图15，在步骤15000中，关于请求恢复使用的包的信息可以被传输到第二LBA。传输过程可以通过用户通过由第二终端1550提供的UI直接选择包的过程来进行，或者可以通过推送输入从远程服务器输入到第二LBA 1570，或者第二LBA 1570可以访问远程服务器以读取对应的信息。
参考图15，在步骤15005中，关于在步骤15000中选择的包的信息可以从第二LBA1570传输到第二SSP 1560。在这种情况下，从第二LBA 1570传输到第二SSP 1560的信息可以包括用于识别在步骤15000中选择的包的信息。
参考图15，在步骤15010中，第二SSP 1560可以将包状态改变为“暂停”。在这种情况下，尽管图中未示出，但是上述“暂停”状态可以用“转换中”状态来代替。
此外，第二SSP 1560可以生成“证明”。在图15中，该证明可以被称为recoveryRequest。证明的结构可以遵循图5中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-recoveryRequest可以在510中包括包的“包定界符”。
-recoveryRequest可以在540中包括第二SSP的“SSP标识符”。
-recoveryRequest可以在550中包括指示第二SSP已经将包状态改变为“暂停”或“转换中”的信息。
-recoveryRequest可以可选地在520中包括其中第二SSP改变包状态的时间或者其中生成证明的时间。
-recoveryRequest可以在560中包括第二SSP的签名信息。签名可以是通过用第二SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图15，在步骤15015中，第二SSP 1560可以向第一SSP 1510传输recoveryRequest。例如，第二SSP 1560可以通过以下过程将recoveryRequest传输给第一SSP 1510。也就是说，响应于步骤15005，第二SSP 1560可以将recoveryRequest传输到第二LBA 1570，并且第二LBA 1570可以经由第一LBA 1520将recoveryRequest传输到第一SSP1510。
参考图15，在步骤15020中，第一SSP 1510可以验证接收到的recoveryRequest。验证过程可以包括检查包含在recoveryRequest中的第二SSP 1560的签名的有效性的步骤。此外，验证过程可进一步包括识别包含在recoveryRequest中的“包定界符”的过程。此外，验证过程还可以包括识别包含在recoveryRequest中的“SSP标识符”的过程。此外，验证过程可以进一步包括识别包括在recoveryRequest中的指令信息是否是正确改变包状态的指令信息的过程。
此外，在步骤15020中，在验证完成之后，第一SSP 1510可以将包状态改变为可用状态之一(禁用、启用和活动之一)。例如，如图所示，第一SSP 1510可以将包状态改变为禁用状态。
参考图15，在步骤15025中，第一SSP 1510可以将在步骤15020中执行的操作的结果(例如，成功还是失败)发送到第一LBA 1520。
图16是示出根据本公开实施例的终端的配置的图。
如图16所示，终端可以包括收发器1610和至少一个处理器1620。此外，终端还可以包括SSP 1630。例如，SSP 1630可以插入到终端中或者可以嵌入到终端中。该至少一个处理器1620可以被称为“控制器”。然而，终端的配置不限于图16所示的配置，并且可以包括比图16所示的组件更多或更少的组件。根据一些实施例，收发器1610、至少一个处理器1620和存储器(未示出)可以以单个芯片的形式实现。此外，当SSP 1630嵌入在终端中时，收发器1610、至少一个处理器1620和存储器(未示出)可以以包括SSP 1630的单个芯片的形式实现。
根据各种实施例，收发器1610可以根据本公开的各种实施例向另一终端或外部服务器的收发器发送信号、信息、数据等，以及从另一终端或外部服务器的收发器接收信号、信息、数据等。收发器1610可以包括用于上变频和放大要发送的信号的频率的RF发送器，以及用于低噪声放大接收的信号并下变频其频率的RF接收器。然而，这仅仅是收发器1610的实施例，并且收发器1610的组件不限于RF发送器和RF接收器。此外，收发器1610可以通过无线信道接收信号，将信号输出到至少一个处理器1620，并且通过无线信道发送从至少一个处理器1620输出的信号。
根据各种实施例，收发器1610可以从另一个终端或外部服务器的收发器发送或接收包括在另一个终端中的SSP的信息、能够认证另一个终端的认证信息、能够认证其自身的认证信息、包传输码、包传输配置、包以及图10至图15中描述的各种证明。
至少一个处理器1620是用于总体控制终端的组件。如上所述，根据本公开的各种实施例，至少一个处理器1620可以控制终端的整体操作。
SSP 1630可以包括用于安装和控制包的处理器或控制器，或者可以在其中安装应用。
根据各种实施例，SSP 1630中的至少一个处理器或控制器可以识别包传输配置，以确定是否发送特定包。此外，至少一个处理器或控制器可以识别包传输配置，以识别包是否可以在多个终端中重复使用。
此外，根据各种实施例，SSP中的至少一个处理器或控制器可以生成包传输码，以控制特定包的传输过程。
此外，根据各种实施例，SSP中的至少一个处理器或控制器可以生成其SSP信息，并识别和验证从外部接收的另一个SSP的SSP信息。
此外，根据各种实施例，SSP中的至少一个处理器或控制器可以生成能够验证其自身的认证信息，并验证从外部接收的另一个SSP的认证信息。
此外，根据各种实施例，SSP 1330可以单独或与一个或多个处理器1620合作地生成包，以及安装该包。此外，SSP 1630可以管理该包。
此外，根据各种实施例，SSP 1630可以生成参考图10至图15描述的各种类型的证明，并验证接收到的证明。
此外，根据各种实施例，SSP 1630可以基于接收到的证明的内容来改变包的状态，如参考图10至图15所描述的。
此外，根据各种实施例，SSP 1630可以在处理器1620的控制下操作。替代地，SSP1630可以包括用于安装和控制包的处理器或控制器，或者可以在其中安装应用。应用中的一些或全部可以安装在SSP 1630或存储器(未示出)中。
终端还可以包括存储器(未示出)，并且存储器(未示出)可以存储诸如基本程序、应用程序和用于终端操作的配置信息的数据。此外，存储器可以包括闪存类型、硬盘类型、多媒体微型卡类型、卡类型存储器(例如，SD或XD存储器)、磁存储器、磁盘、光盘、随机存取存储器(RAM)、静态随机存取存储器(SRAM)、只读存储器(ROM)、可编程只读存储器(PROM)或电可擦除可编程只读存储器(EEPROM)中的至少一种存储介质。此外，处理器1620可以使用存储在存储器中的各种程序、内容、数据等来执行各种操作。
图17是示出图6中呈现的过程当中完成包的传输的过程的另一详细过程的图。更具体地，图17是图示根据本公开实施例的在终端中安装包的过程和在发送包之后配置包状态的过程的图的另一示例。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图17的示例中，第一终端1700可以包括第一LBA 1720和第一SSP 1710，第二终端1750可以包括第二LBA1770和第二SSP 1760。例如，第一终端1700可以是其中安装了第一SSP 1710并且其中安装了用于控制第一SSP 1710的第一LBA 1720的终端，第二终端1750可以是其中安装了第二SSP 1760并且其中安装了用于控制第二SSP 1760的第二LBA 1770的终端。
1.安装包
参考图17，在步骤17000中，第二LBA 1770和第二SSP 1760可以彼此协作以在第二终端1750中安装包。其详细描述参考图9的“包安装”过程。
2.识别包是否可以重复使用
此外，尽管图中未示出，但是第二LBA 1770和/或第二SSP 1760可以选择性地确定包是否可以在多个终端中重复使用。其详细描述参考图9的“识别包是否可以重复使用”的过程。
3.配置包状态
如果包不能在多个终端中重复使用，则包状态被额外配置如下。替代地，即使当第二LBA 1770和/或第二SSP 1760确定/不确定包是否可以被重复使用时，也可以根据第二LBA 1770和/或第二SSP 1760的实现来执行额外配置包状态的过程，如下所述。
参考图17，在步骤17005中，第二SSP 1760可以将包状态配置为“转换中”。“转换中”是指包已经成功安装但不可用的状态(此外，仅通过诸如“来自另一个终端的请求(例如，通过发送‘finalizationResponse或recoveryRequest’做出的请求)”和/或“来自外部服务器的请求”的额外操作而可以被改变为可用状态(禁用、启用、活动状态)的状态)。
参考图17，在步骤17010，第二LBA 1770可以向第二SSP 1760请求“证明”。
参考图17，在步骤17015中，第二SSP 1760可以生成“证明”。在图17中，该证明可以被称为finalizationRequest。证明的结构可以遵循图5中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-finalizationRequest可以在510中包括包的“包定界符”。
-finalizationRequest可以在540中包括第二SSP的“SSP标识符”。
-finalizationRequest可以在550中包括指示第二SSP已经将包状态配置为“转换中”状态的信息。
-finalizationRequest可以可选地在520中包括其中第二SSP将包状态改变为“转换中”状态的时间或者其中生成证明的时间。替代地，finalizationRequest可以可选地进一步包括关于稍后用于数字签名的证书的信息。
-finalizationRequest可以在560中包括第二SSP的签名信息。签名可以是通过用第二SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图17，在步骤17020中，第二SSP 1760可以向第一SSP 1710传输finalizationRequest。例如，第二SSP 1760可以通过以下过程将finalizationRequest传输到第一SSP 1710。也就是说，响应于步骤17010，第二SSP 1760可以将finalizationRequest传输到第二LBA 1770，并且第二LBA可以通过第一LBA 1720将finalizationRequest传输到第一SSP。
参考图17，在步骤17025中，第一SSP 1710可以验证接收到的finalizationRequest。验证过程可以包括检查包含在finalizationRequest中的第二SSP的签名的有效性的步骤。此外，验证过程还可包括检查包含在finalizationRequest中的“包定界符”是否与对应包的包定界符相匹配的过程。此外，验证过程还可以包括检查包含在finalizationRequest中的“SSP标识符”是否是第二SSP的有效标识符的过程。此外，验证过程还可以包括识别包括在finalizationRequest中的指令信息是否是将包状态改变为“转换中”状态的指令信息的过程。
此外，在步骤17025中，第一SSP 1710可以删除包。
此外，在步骤17025中，第一SSP 1710可以生成“证明”。在图17中，该证明可以被称为finalizationResponse。证明的结构可以遵循图5中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-finalizationResponse可以在510中包括包的“包定界符”。
-finalizationResponse可以在540中包括第一SSP的“SSP标识符”。
-finalizationResponse可以在550中包括指示第一SSP已经删除了包的信息。
-finalizationResponse可以可选地在520中包括其中第一SSP删除包的时间或者其中生成证明的时间。替代地，finalizationResponse可以可选地进一步包括关于稍后用于数字签名的证书的信息。
-finalizationResponse可以在560中包括第一SSP的签名信息。签名可以是通过用第一SSP的签名证书对上述信息进行数字签名而获得的签名信息。
此外，可能的证明配置的另一个示例如下。
-finalizationResponse可以在530中包括finalizationRequest的部分和/或全部数据。
-finalizationResponse可以在540中包括第一SSP的“SSP标识符”。
-finalizationResponse可以在550中包括指示第一SSP已经删除了包的信息。
-finalizationResponse可以可选地在520中包括其中第一SSP删除包的时间或者其中生成证明的时间。替代地，finalizationResponse可以可选地进一步包括关于稍后用于数字签名的证书的信息。
-finalizationResponse可以在560中包括第一SSP的签名信息。签名可以是通过用第一SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图17，在步骤17030中，第一SSP 1710可以向第二SSP 1760传输finalizationResponse。例如，第一SSP 1710可以经由第一LBA 1720和第二LBA 1770向第二SSP 1760传输finalizationResponse。
参考图17，在步骤17035中，第二SSP 1760可以验证接收到的finalizationResponse。验证过程可以包括检查包含在finalizationResponse中的第一SSP的签名的有效性的步骤。此外，验证过程可以可选地进一步包括检查包含在finalizationResponse中的“包定界符”是否与对应包的包定界符相匹配的过程。此外，验证过程可以可选地进一步包括检查包含在finalizationResponse中的finalizationRequest的一些和/或全部信息是否与第二SSP 1760已经发送的信息相匹配的过程。此外，验证过程还可以包括识别包含在finalizationResponse中的“SSP标识符”的过程。此外，验证过程还可以包括识别包括在finalizationResponse中的指令信息是否是删除包的指令信息的过程。
此外，在步骤17035中，第二SSP 1760可以将包状态改变为可用状态之一(禁用、启用和活动之一)。例如，如图所示，第二SSP 1760可以将包状态转换为禁用状态。
此外，在步骤17035中，第二SSP 1760可以生成“证明”。在图17中，证明可以被称为spblAttestation。证明的结构可以遵循图5中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-spblAttestation可以在510中包括包的“包定界符”。
-spblAttestation可以在540中包括第二SSP的“SSP标识符”。
-spblAttestation可以在550中包括指示第二SSP已经将包状态改变为可用状态的信息。
-spblAttestation可以可选地在520中包括其中第二SSP改变包状态的时间或者其中生成证明的时间。替代地，spblAttestation可以可选地进一步包括关于稍后用于数字签名的证书的信息。
-spblAttestation可以在560中包括第二SSP的签名信息。签名可以是通过用第二SSP的签名证书对上述信息进行数字签名而获得的签名信息。
此外，可能的证明配置的另一个示例如下。
-spblAttestation可以在530中包括“finalizationRequest和/或finalizationResponse”的部分和/或全部数据。
-spblAttestation可以在540中包括第二SSP的“SSP标识符”。
-spblAttestation可以540中包括指示第二SSP已经将包状态改变为可用状态的信息。
-spblAttestation可以可选地在520中包括其中第二SSP改变包状态的时间或者其中生成证明的时间。替代地，spblAttestation可以可选地进一步包括关于稍后用于数字签名的证书的信息。
-spblAttestation可以在560中包括第二SSP的签名信息。签名可以是通过用第二SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图17，在步骤17040中，第二SSP 1760可以将spblAttestation传输到第一SSP1710。例如，第二SSP 1760可以经由第二LBA 1770和第一LBA 1720向第一SSP 1710传输spblAttestation。
参考图17，在步骤17045中，第一SSP 1710可以验证接收到的spblAttestation。验证过程可以包括检查包含在spblAttestation中的第二SSP的签名的有效性的步骤。此外，验证过程还可以包括检查spblAttestation中包含的“包定界符”是否与对应包的包定界符相匹配的过程。此外，验证过程可以可选地进一步包括检查spblAttestation中包括的finalizationRequest和/或finalizationResponse的一些和/或全部信息是否与第一SSP1710发送的信息相匹配的过程。此外，验证过程还可以包括检查spblAttestation中包含的“SSP标识符”是否是第二SSP的有效标识符的过程。此外，验证过程还可以包括识别spblAttestation中包括的指令信息是否是将包状态改变为可用状态的指令信息的过程。
此外，在步骤17045中，第一SSP 1710可以删除finalizationResponse。
根据需要，可以省略步骤17035和/或步骤17040和/或步骤17045中生成spblAttestation的步骤。
当证明传输在步骤17020、步骤17030和/或步骤17040中失败时，对应的证明可以被重传到对方设备。
在这种情况下，可以尝试与预配置的最大重传数量一样多的重传。替代地，可以进行重复尝试，直到识别出对应的证明已经被发送到另一个终端。替代地，根据终端的实现方式，可以重复重传证明，直到对应的证明被删除。例如，第一终端可以重复尝试重传finalizationResponse，直到在步骤17045中删除finalizationResponse为止。
当尝试重传时，如果两个设备之间的连接断开，则这两个设备可以建立新的连接，然后发送和接收对应的证明。在这种情况下，两个终端可以使用在过去的通信期间发送和接收的记录来选择和/或验证新建立的连接的目标，确定与新建立的连接目标发送和接收什么数据，并验证从另一个终端接收的数据的有效性和/或内容。
在这种情况下，重传可以由终端内部的操作自动发起，可以由来自外部服务器的请求发起，或者可以由用户输入发起。
图18是示出根据本公开的一些实施例的“证明”的配置的图。
根据各种实施例，证明可以可选地包括“证明信息(attestation Info)”(1810)。包括在证明信息中的数据的各种示例参考稍后将描述的图22至27的描述。
根据各种实施例，证明可以可选地进一步包括“发布证明的主体的发布者ID”(1830)。发布证明的主体的各种示例参考稍后描述的图22至27的描述。
根据各种实施例，证明可以可选地进一步包括“关于由证明发布者执行的操作的命令”(1850)。由证明发布者执行的操作的各种示例参考稍后将描述的图22至27的描述。
根据各种实施例，证明可以可选地进一步包括除了上述信息之外的其他数据(1870)。可以包括在证明中的其他数据的各种示例参考稍后将描述的图22至27的描述。
根据各种实施例，证明可以包括上述信息的数字签名数据(1890)。签名数据可以是由证书生成的电子签名，该证书用于证明发布者的签名。
图19是概念性地图示了根据本公开的实施例的用于从一个终端向另一个终端发送包的过程的图。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图19的示例中，第一终端1900可以包括第一LBA 1920和第一SSP 1910，第二终端1950可以包括第二LBA1970和第二SSP 1960。例如，第一终端1900可以是其中安装了第一SSP 1910并且其中安装了用于控制第一SSP 1910的第一LBA 1920的终端，第二终端1950可以是其中安装了第二SSP 1960并且其中安装了用于控制第二SSP 1960的第二LBA 1970的终端。
参考图19，在步骤19000中，第一终端1900的第一SSP 1910和第一LBA 1920以及第二终端1950的第二LBA 1970可以执行包传输所需的准备过程(包传输准备过程)。该过程的更详细描述参考稍后将描述的图20的详细描述。
参考图19，可以在步骤19005中执行用于将包从第一终端1900发送到第二终端1950的过程(包传输过程)。该过程的更详细描述参考稍后将描述的图21的详细描述。
参考图19，在步骤19010中，第一终端1900和第二终端1960可以执行用于安装发送的包的过程和用于配置包状态的过程(包传输完成过程)。该过程的详细描述参考稍后将描述的图22、24和26的详细描述。
图20是示出图19中呈现的过程当中用于准备包传输的过程的详细过程的图。更具体地，图20是示例性地示出根据本公开的实施例的一个终端经历向另一个终端发送包所需的准备过程的过程的图。在本说明书中，图20的过程可以被称为包传输准备过程。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图20的示例中，第一终端2000可以包括第一LBA 2020和第一SSP 2010，第二终端2050可以包括第二LBA2070和第二SSP 2060。例如，第一终端2000可以是其中安装了第一SSP 2010并且其中安装了用于控制第一SSP 2010的第一LBA 2020的终端，第二终端2050可以是其中安装了第二SSP 2060并且其中安装了用于控制第二SSP 2060的第二LBA 2070的终端。
根据各种实施例，第一终端2000可以具有预安装的包，并且还具有与包相关联的元数据。
根据各种实施例，第一终端2000可以具有与对应的包相关联的包标识符(SPBID)、包族标识符(SPB族ID)或包族管理器标识符(SPB族保管者对象ID)中的至少一个。
根据各种实施例，第一终端2000可以具有与对应的包相关联的“包传输配置”。包传输配置可以可选地包括与包是否可在装置之间发送相关的信息。
此外，包传输配置可以可选地进一步包括用于在服务器中注册设备之间的包的传输结果的过程的“注册配置”。可能的“注册配置”的各种示例如下。
-是否需要通知：关于是否向服务器通知设备之间的包传输结果的配置
-是否需要预先通知：在将包从一个设备发送到新设备之后，在新设备中使用包之前，关于是否应该将传输历史通知给服务器或者在将传输历史通知给服务器之前是否可以在新设备中使用传输历史的配置
-通知内容是否需要加密：关于通知过程中发送的数据是否需要加密以便只有接收通知的服务器和做出通知的SSP可以查看内容的配置。
“注册配置”可以由服务提供商配置，由包管理服务器配置，或者由服务提供商和包管理服务器之间的协作来配置。此外，包传输配置可以作为数据被包括在包内，被包括在包的元数据中，或者可以作为独立数据存在。此外，包传输配置可以包括服务提供商和/或包管理服务器的电子签名。
参考图20，在步骤20000中，关于将在装置之间发送的包的信息可以被传输到第一LBA 2020。例如，如图20所示，传输过程可以通过用户通过由第一终端2000提供的UI直接选择包的过程来执行，或者可以通过推送输入从远程服务器输入到第一LBA 2020，或者第一LBA 2020可以访问远程服务器以读取对应的信息。
参考图20，在步骤20005中，与通过步骤20000选择的包相关的信息可以从第一LBA2020传输到第一SSP 2010。例如，如图20所示，与所选包相关的信息可以通过选择SPB命令从第一LBA 2020传输到第一SSP 2010。在这种情况下，从第一LBA 2020传输到第一SSP2010的信息可以包括用于识别在步骤20000中选择的包的信息。
参考图20，在步骤20010中，第一SSP 2010可以识别是否可以在设备之间发送请求传输的包。该过程可以通过基于在步骤20005中接收的信息识别请求传输的包，并识别与该包相关联的“包传输配置”来执行。
此外，在步骤20010中，第一SSP 2010可以可选地配置“包传输码”。“包传输码”是用于在设备之间发送包的过程中引用包的代码，并且应该是能够识别包的值。第一SSP2010可以将上述“包传输码”和将被发送的包的信息绑定。
参考图20，在步骤20015中，对步骤20005的响应结果可以从第一SSP 2010发送到第一LBA 2020。例如，如图20所示，对选择SPB命令的响应可以通过选择SPB响应从第一SPB2010传输到第一LBA 2020。响应值可以包括步骤20010中描述的“包传输码”。
参考图20，在步骤20020中，设备之间的包传输所需的信息可以从第一终端2000的第一LBA 2020传输到第二终端2050的第二LBA 2070。在这种情况下，从第一LBA 2020传输到第二LBA 2070的信息可以包括“包传输码”。此外，从第一LBA 2020传输到第二LBA 2070的信息可以可选地进一步包括在未来步骤20025中将在第一LBA 720和第二LBA 2070之间建立的连接所需的信息。
通过上述步骤20020从第一LBA 2020传输到第二LBA 2070的信息可以以各种方式传输。例如，第一LBA可以通过第一终端2000的UI向用户提供要传输到第二LBA的信息，并且用户可以使用第二终端2050的UI将接收的信息输入到第二LBA。替代地，第一LBA可以使得要传输到第二LBA的信息具有图像(例如，QR码)的形式，以在第一终端的屏幕上显示图像，并且用户可以使用第二终端2050扫描图像，以将信息传输到第二LBA 2070。然而，将信息从第一LBA 2020传输到第二LBA 2070的方法不限于上述方法。
参考图20，在步骤20025中，可以在第一LBA 2020和第二LBA 2070之间建立(或配置)连接。当在步骤20020中已经发送了连接所需的信息时，第一LBA 2020和第二LBA 2070可以使用该信息建立连接。第一LBA 2020和第二LBA 2070之间的连接可以是直接的设备到设备连接(例如，NFC、蓝牙、UWB、WiFi-直连、LTE设备到设备(D2D)、5G D2D)或者可以是远程连接，其中远程服务器(例如，中继服务器)位于第一LBA 2020和第二LBA 2070之间。
参考图20，尽管步骤20025被示为最后一步，但是该步骤独立于上述其他步骤，即步骤20000、20005、20010、20015和20020，并且可以不考虑其他步骤的顺序而执行。例如，步骤20025可以在步骤20015和20020之间执行，在这种情况下，在步骤20020中从第一LBA2020发送到第二LBA 2070的信息可以通过在步骤20025中建立的连接来发送。
图21是示出图19中呈现的过程当中发送包的过程的详细过程的图。更具体地，图21是示例性示出根据本公开实施例的一个终端向另一个终端发送包的过程的图。在本公开中，图21的过程可以被称为包传输过程。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图21的示例中，第一终端2100可以包括第一LBA 2120和第一SSP 2110，第二终端2150可以包括第二LBA2170和第二SSP 2160。例如，第一终端2100可以是其中安装了第一SSP 2110并且其中安装了用于控制第一SSP 2110的第一LBA 2120的终端，第二终端2150可以是其中安装了第二SSP 2160并且其中安装了用于控制第二SSP 2160的第二LBA 2170的终端。
参考图21，在步骤21000中，第二LBA 2170可以向第二SSP 2160请求“SspInfo”。当第二LBA 2170在步骤21000中向第二SSP 2160请求“SspInfo”时，第二LBA 2170可以通知第二SSP 2160将执行设备之间的包传输。
此外，步骤21000可以在参考图21描述的过程之后立即自动执行，或者可以在接收到外部输入之后执行。在这种情况下，“外部输入”可以通过用户通过由第二终端2150提供的UI直接选择要接收的包的过程来执行，或者可以通过推送输入从远程服务器输入到第二LBA 2170，或者第二LBA 2170可以访问远程服务器以读取对应的信息。
参考图21，在步骤21005中，第二SSP 2160可以生成其“SspInfo”。“SspInfo”可以包括关于将被提供用于包传输的第二SSP的信息。在这种情况下，“SspInfo”可以包括第二SSP 2160在接收包之前应该经历的证书协商过程的信息(证书协商信息)。“证书协商信息”可包括第二SSP 2160可用于验证另一SSP的证书信息(SenderSpblVerification)和另一SSP可用于验证自身的证书信息(ReceiverSpblVerification)。此外，“证书协商信息”可以可选地进一步包括第二SSP 2160支持的密钥协商算法列表，并且可选地进一步包括第二SSP 2160支持的加密算法列表。此外，“SspInfo”可以可选地进一步包括SSP版本信息，该SSP版本信息包括第二SSP 2160中包括的主平台和加载器所支持的标准规范的版本信息中的至少一个。
参考图21，在步骤21010中，第二SSP 2160可以经由第二LBA 2170和第一LBA 2120将在步骤21005中生成的“SspInfo”传输到第一SSP 2110。
根据上述步骤21000和21010，第二LBA 2170可以向第二SSP 2160请求“SspInfo”,并且第二SSP 2160可以生成其“SspInfo”,然后经由第二LBA 2170和第一LBA 2120将“SspInfo”传输到第一SSP 2110。然而，根据实施例，将“SspInfo”从第二终端2150传输到第一终端2100的过程可以如下。例如，在第二LBA 2170自己生成“SspInfo”之后，第二LBA2170可以经由第一LBA 2120将“SspInfo”传输给第一SSP 2110。
参考图21，在步骤21015中，第一SSP 2110可以识别所接收的“SspInfo”并生成能够基于该信息认证自身的“第一终端认证信息(Device1.Auth)”。该过程的更详细的过程如下。
第一SSP 2110可使用接收的“SenderSpblVerification”识别能够验证其自身的证书信息，并选择至少一个密钥协商证书(ssp1.Cert.KA)。替代地，第一SSP 2110可以使用接收到的“第二SSP 2160支持的密钥协商算法列表”生成公钥“ssp1.ePK.KA”和私钥“ssp1.eSK.KA”作为将要用于密钥协商的非对称加密的密钥对，然后在密钥对中选择公钥(ssp1.ePK.KA)。此外，第一SSP 2110可使用接收的“SenderSpblVerification”识别能够验证其自身的证书信息，并进一步选择至少一个签名证书(ssp1.Cert.DS)。
此外，第一SSP 2110可选择第二SSP 2160的至少一个证书信息来使用接收的“ReceiverSpblVerification”执行验证，并将对应的信息配置为“CiPkIdToBeUsed”。
此外，第一SSP 2110可以使用接收到的“第二SSP 2160支持的加密算法列表”来选择至少一个将来要使用的加密算法，然后将对应的信息配置为“CryptoToBeUsed”。
此外，第一SSP 2110可以识别接收到的“由包括在第二SSP 2160中的主平台和加载器支持的标准规范的版本信息”的列表，并且识别当中是否存在由它自己支持的标准规范的版本。
“第一终端认证信息(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验证以确保信息的完整性的数字签名，并且数字签名数据可以作为“第一终端认证信息”的部分被添加。
参考图21，在步骤21020中，第一SSP 2110可以将在步骤21015生成的“第一终端认证信息(Device1.Auth)”经由第一LBA 2120传输到第二LBA 2170。
参考图21，在步骤21025中，第二LBA 2170可以将“第一终端认证信息(Device1.Auth)”传输到第二SSP 2160。此外，第二LBA 2170还可以向第二SSP 2160传输“包传输码”。
参考图21，在步骤21030中，第二SSP 2160可以验证接收的“第一终端认证信息(Device1.Auth)”。当第二SSP 2160接收到“ssp1.Cert.KA”时，第二SSP 2160可以识别对应证书的签名，以识别该证书的有效性。此外，当第二SSP 2160接收到“ssp1.ePK.KA”及其数字签名时，第二SSP 2160可以首先检查ssp1.Cert.DS的有效性，然后使用该证书来识别数字签名，以识别所接收的公钥ssp1.ePK.KA的完整性。此外，第二SSP 2160可以识别所接收的“CiPkIdToBeUsed”并选择能够验证自身的至少一个签名证书(ssp2.Cert.DS)。
此外，尽管图中未示出，但是在步骤21030中，第二SSP 2160可以生成公钥“ssp2.ePK.KA”和私钥“ssp2.eSK.KA”作为将要用于密钥协商的非对称加密的密钥对，然后在密钥对中选择公钥(ssp2.ePK.KA)。此外，第二SSP 2160可以选择ssp1.ePK.KA和包括在ssp1.Cert.KA中的用于密钥协商的公钥中的一个，然后使用该值和ssp2.eSK.KA生成将在将来与第一终端通信期间用于加密的会话密钥ShKey01。
此外，在步骤21030中，第二SSP 2160可以生成能够认证自身的“第二终端认证信息(Device2.Auth)”。在这种情况下，“第二终端认证信息(Device2.Auth)”可以包括“ssp2.Cert.DS”。此外，“第二终端认证信息(Device2.Auth)”可能还包括“ssp2.ePK.KA”。此外，“第二终端认证信息(Device2.Auth)”可以进一步包括指示由第二SSP 2160生成的当前会话的事务ID。此外，“第二终端认证信息(Device2.Auth)”还可以包括“包传输码”。此外，“第二终端认证信息(Device2.Auth)”可以进一步包括第二SSP 2160的SSP标识符。此外，”第二终端认证信息(Device2.Auth)”可以可选地进一步包括与将来要传输的包相关联的包族标识符(SPB族ID)或包族管理器标识符(SPB族保管者对象ID)中的至少一个。
在这种情况下，上述“第二终端认证信息(Device2.Auth)”的一部分或全部可以是能够使用ssp2.Cert.DS验证以确保信息的完整性的数字签名，并且数字签名数据可以作为“第二终端认证信息”的部分被添加。此外，“第二终端认证信息(Device2.Auth)”的部分或全部可以使用先前生成的会话密钥ShKey01来加密。
参考图21，在步骤21035中，第二SSP 2160可以经由第二LBA 2170和第一LBA 2120将在步骤21030中生成的“第二终端认证信息(Device2.Auth)”传输到第一SSP 2110。在这种情况下，可以可选地进一步发送“包传输码”。
参考图21，在步骤21040，第一SSP 2110可以验证接收的“第二终端认证信息(Device2.Auth)”。第一SSP 2110可以验证接收到的“ssp2.Cert.DS”的签名以验证对应证书的有效性。此外，第一SSP 2110可以检查所接收的包族标识符(SPB族ID)和/或包族管理器标识符(SPB族保管者对象ID)是否是与将由其自身发送的包相关联的正确配置的值。此外，第一SSP 2110可以存储接收的事务ID和/或第二SSP 2160的SSP标识符。此外，第一SSP2110可以将接收到的事务ID或第二SSP 2160的SSP标识符与当前正在进行的会话或要发送的包绑定。
在该过程中，当加密数据被包括在“第二终端认证信息(Device2.Auth)”中时，第一SSP 2110可使用ssp1.eSK.KA或与包括在其ssp1.Cert.KA中的用于密钥协商的公钥相对应的私钥以及接收的ssp2.ePK.KA来生成会话密钥ShKey01，使用会话密钥解密加密的数据，然后执行验证过程。此外，在该过程中，当数字签名包括在“第二终端认证信息(Device2.Auth)”中时，第一SSP 2110可以使用“ssp2.Cert.DS”来验证接收到的数字签名的有效性。
此外，在步骤21040中，尽管在图21中未示出，但是第一SSP 2110可以生成公钥“ssp1.bundle.ePK.KA”和私钥“ssp1.bundle.eSK.KA”作为将要用于密钥协商的非对称加密的密钥对。在这种情况下，密钥对“ssp1.bundle.ePK.KA和ssp1.bundle.eSK.KA”可以被配置为与先前生成的“ssp1.ePK.KA和ssp1.eSK.KA”相同的值。替代地，密钥对“ssp1.bundle.ePK.KA和ssp1.bundle.eSK.KA”可以被配置为与先前使用的“包括在ssp1.Cert.KA中的公钥和对应的私钥”相同的值。此外，第一SSP 2110可使用ssp1.bundle.eSK.KA和ssp2.ePK.KA生成会话密钥ShKey02。当“与包括在ssp1.eSK.KA中的公钥相对应的私钥或ssp1.Cert.Ka”被重用于ssp1.bundle.eSK.KA时，会话密钥ShKey02的值也可以被配置为先前生成的ShKey01的值。
此外，在步骤21040中，第一SSP 2110可以配置要发送到第二终端2150的包和/或与该包相关联的元数据。在这种情况下，第一SSP 2110可以使用接收到的“包传输码”来识别将由其自身发送的包。此外，要配置的包可以包括“ssp1.Cert.DS”。此外，要配置的包还可以包括“ssp1.bundle.ePK.KA”。此外，要配置的包还可以包括用于识别对应会话的事务ID。此外，要配置的包可以可选地进一步包括与要发送的包相关联的包标识符(SPB ID)、包族标识符(SPB族ID)或包族管理器标识符(SPB族保管者对象ID)中的至少一个。根据各种实施例，在步骤21040中配置的包(或与包相关联的元数据)中可以包括“包传输配置”。
根据各种实施例，使用ssp1.Cert.DS生成的数字签名数据可以被添加到要在步骤21040中配置的包。也就是说，为上面指定的包的组件中的一些或全部生成的数字签名数据可以作为包的部分被添加。此外，要配置的包的一些或全部可以使用ShKey02加密。
参考图21，在步骤21045中，第一SSP 2110可以经由第一LBA 2120将在步骤21040中生成(配置)的包传输到第二LBA 2170。在这种情况下，可以可选地地进一步发送与发送的包相关联的元数据。此外，可以进一步发送与发送的包相关联的“包传输配置”。例如，“包传输配置”可以以单独的格式(例如，消息)发送，而不包括在包或元数据中。
图22是示出图19所示的过程当中完成包的传输的过程的详细过程的图。
图22示出了当设备之间的包的传输历史是如下情况时被应用的过程
-不需要预先通知
-需要或不需要加密通知内容
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图22的示例中，第一终端2200可以包括第一LBA 2220和第一SSP 2210，第二终端2250可以包括第二LBA2270和第二SSP 2260。例如，第一终端2200可以是其中安装了第一SSP 2210并且其中安装了用于控制第一SSP 2210的第一LBA 2220的终端，第二终端2250可以是其中安装了第二SSP 2260并且其中安装了用于控制第二SSP 2260的第二LBA 2270的终端。
参考图22，在步骤22000中可以执行以下过程。
1.安装包
参考图22，在步骤22000中，第二LBA 2270和第二SSP 2260可以彼此协作以在第二终端2250中安装包。在该过程中，可以一起执行以下步骤。当发送元数据时，第二LBA 2270或第二SSP 2260可验证包括在元数据中的内容。当发送“包传输配置”时，第二LBA 2270可以将信息传输到第二SSP 2260。当发送事务ID时，第二LBA 2270或第二SSP 2260可以检查事务ID是否与当前会话中使用的事务ID相同。当发送包标识符(SPB ID)、包族标识符(SPB族ID)或包族管理器标识符(SPB族保管者对象ID)中的至少一个时，第二LBA 2270或第二SSP 2260可以识别该信息是否与当前要接收的包的信息相匹配。当ssp1.Cert.DS被发送时，第二SSP 2260可以验证证书的有效性以认证第一SSP 2210。当接收的数据包括加密的数据时，第二SSP 2260可使用接收的ssp1.bundle.ePK.KA及其ssp2.eSK.KA生成会话密钥ShKey02，并使用会话密钥解密加密的数据，然后执行验证。当接收的数据包括数字签名时，第二SSP 2260可以验证ssp1.Cer.DS并且然后使用证书验证数字签名的有效性。
2.识别“注册配置”
此外，尽管图中未示出，第二LBA 2270和/或第二SSP 2260可以识别是否“需要通知”、是否“需要预先通知”、和/或是否需要使用包的“注册配置”来加密通知内容。该过程是步骤22000的一部分，并且可以独立于在步骤22000中执行的其他过程的顺序来执行。替代地，在步骤22000之后，在步骤22035完成之前，可以在需要确定的时刻执行该过程。稍后将在附图中描述的过程可以是当以下情况时要被应用的过程：作为识别“注册配置”的结果，设备之间的包的传输历史不需要被预先通知。
参考图22，在步骤22005中，第二SSP 2260可以将包状态配置为“转换中”。“转换中”意味着包已经被成功安装但是还不可用的状态(此外，仅通过“将在本图中稍后描述的额外操作”和/或诸如“来自外部服务器的请求(尽管在本公开中没有描述)”的额外操作而可以被改变为可用状态(禁用、启用、活动状态)的状态)。
参考图22，在步骤22010中，第二LBA 2270可以向第二SSP 2260请求“证明”。
参考图22，在步骤22015中，第二SSP 2260可以生成“证明”。在图22中，该证明可以被称为finalizationRequest。证明的结构可以遵循图18中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-finalizationRequest可以在图18的1810中包括对应包的“包定界符”。
-finalizationRequest可以在图18的1830中包括第二SSP的“SSP标识符”。
-finalizationRequest可以在图18的1850中包括指示第二SSP将包状态配置为“转换中”状态的信息。
-finalizationRequest可以可选地在图18的1870中包括其中第二SSP将包状态改变为“转换中”状态的时间或者其中生成证明的时间。替代地，finalizationRequest可以包括关于用于签名的证书(用于稍后描述的电子签名)的信息，以及关于与其相关的证书链的信息。
-finalizationRequest可以在图18的1890中包括第二SSP的签名信息。签名可以是通过用第二SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图22，在步骤22020中，第二SSP 2260可以向第一SSP 2210传输finalizationRequest。例如，第二SSP 2260可以通过以下过程将finalizationRequest传输到第一SSP 2210。也就是说，响应于步骤22010，第二SSP 2260可以将finalizationRequest传输到第二LBA 2270，并且第二LBA 2270可以经由第一LBA 2220将finalizationRequest传输到第一SSP 2210。
参考图22，在步骤22025中，第一SSP 2210可以验证所接收的finalizationRequest。验证过程可以包括检查包含在finalizationRequest中的第二SSP的签名的有效性的步骤。此外，验证过程还可包括检查包含在finalizationRequest中的“包定界符”是否与对应包的包定界符相匹配的过程。此外，验证过程还可以包括检查包含在finalizationRequest中的“SSP标识符”是否是第二SSP的有效标识符的过程。此外，验证过程还可以包括识别包含在finalizationRequest中的指令信息是否是将包状态改变为“转换中”状态的指令信息的过程。
此外，在步骤22025中，第一SSP 2210可以在验证完成之后删除包。
此外，在步骤22025中，第一SSP 2210可以生成“证明”。在图22中，该证明可以被称为finalizationResponse。证明的结构可以遵循图18中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-finalizationResponse可以在图18的1810中包括对应包的“包定界符”。替代地，finalizationResponse可以包括在先前步骤中接收的finalizationRequest的部分和/或全部数据。
-finalizationResponse可以在图18的1830中包括第一SSP的“SSP标识符”。
-finalizationResponse可以在图18的1850中包括指示第一SSP已经删除了包的信息。
-finalizationResponse可以可选地在图18的1870中包括其中第一SSP删除包的时间或者中生成证明的时间。替代地，finalizationResponse可以包括关于用于签名的证书(用于稍后描述的电子签名)的信息，以及关于与其相关的证书链的信息。
-finalizationResponse可以在图18的1890中包括第一SSP的签名信息。签名可以是通过用第一SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图22，在步骤22030中，第一SSP 2210可以向第二SSP 2260传输finalizationResponse。例如，第一SSP 2210可以经由第一LBA 2220和第二LBA 2270向第二SSP 2260传输finalizationResponse。
参考图22，在步骤22035中，第二SSP 2260可以验证接收到的finalizationResponse。验证过程可以包括检查包含在finalizationResponse中的第一SSP的签名的有效性的步骤。此外，验证过程可以可选地进一步包括检查包含在finalizationResponse中的“包定界符”是否与对应包的包定界符相匹配过程。此外，验证过程可以包括检查包含在finalizationResponse中的finalizationRequest的部分或全部数据是否与第二SSP 2260发送的信息相匹配的过程。此外，验证过程还可以包括识别包含在finalizationResponse中的“SSP标识符”的过程。此外，验证过程还可以包括识别包含在finalizationResponse中的指令信息是否是删除包的指令信息的过程。
此外，在步骤22035中，在验证完成之后，第二SSP 2260可以将包状态改变为可用状态之一(禁用、启用和活动之一)。例如，如图所示，第二SSP 2260可以将包状态转换为禁用状态。
此外，在步骤22035中，第二SSP 2260可以生成“证明”。在图22中，证明可以被称为spblAttestation。证明的结构可以遵循图18中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-spblAttestation可以在图18的1810中包括对应包的“包定界符”。替代地，spblAttestation可以包括finalizationRequest和/或finalizationResponse的部分和/或全部数据。
-spblAttestation可以在图18的1830中包括第二SSP的“SSP标识符”。
-spblAttestation可以在图18的1850中包括指示第二SSP已经将包状态改变为可用状态之一的信息。
-spblAttestation可以可选地在图18的1870中包括其中第二SSP将包状态改变为可用状态之一的时间，或者其中生成证明的时间。替代地，spblAttestation可以包括关于用于签名的证书(用于稍后描述的电子签名)的信息，以及关于与其相关的证书链的信息。
-spblAttestation可以在图18的1890中包括第二SSP的签名信息。签名可以是通过用第二SSP的签名证书对上述信息进行数字签名而获得的签名信息。
此外，在步骤22035中，第二SSP 2260可以生成其“选择的SSP信息(sspInforSelected)”。“选择的SSP信息”可以包括关于要提供的第二SSP的信息，以便向服务器通知设备之间的包传输的结果。
在这种情况下，“选择的SSP信息”可以包括用于证书协商过程的信息(证书协商信息)。“证书协商信息”可以可选地包括诸如以下的信息
-第二SSP 2260可以用于验证服务器的证书信息(spbmVerification)
-服务器可以用于验证第一SSP 2210的证书信息(SenderSpblVerification)
-服务器可以用于验证第二SSP 2260的证书信息(ReceiverSpblVerification)
此外，“证书协商信息”可以可选地进一步包括第二SSP 2260支持的密钥协商算法列表，并且可选地进一步包括第二SSP 2260支持的加密算法列表。
此外，“选择的SSP信息”可以可选地进一步包括SSP版本信息，该SSP版本信息包括由第二SSP 2260中包括的主平台和加载器所支持的标准规范的版本信息中的至少一个。
参考图22，在步骤22040中，第二SSP 2260可以将在步骤22035中执行的操作的结果(例如，成功还是失败)发送到第二LBA 2270。此外，在步骤22035中生成的“选择的SSP信息”可以一起发送。
可以省略步骤22035中生成“选择的SSP信息”的过程和步骤22040中传输“选择的SSP信息”的过程。
图23是图示在图22中呈现的过程之后在服务器中注册包传输结果的过程的图。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图23的示例中，第二终端2350可以包括第二LBA 2370和第二SSP 2360。例如，第二终端2350可以是其中安装了第二SSP 2360并且其中安装了用于控制第二SSP 2360的第二LBA 2370的终端。
此外，根据各种实施例，服务器2300可以是由服务提供商操作的服务器、包管理服务器、由服务提供商和包管理服务器之间的协作操作的服务器、或者与服务提供商和/或包管理服务器相关联地操作的任何服务器。在附图的描述中，尽管作为服务器的可能示例之一的术语SPBM有时用于指代服务器2300，但是如上所述，服务器的类型不限于SPBM。
参考图23，在步骤23000中，可以在SPBM 2300和LBA 2370之间建立传输层安全性(TLS)连接。尽管参考附图描述了在步骤23005至23015之前执行步骤23000，但是在执行步骤23020之前，可以独立于步骤23005至23015执行步骤23000。例如，步骤23000可以在步骤23015和23020之间执行。
参考图23，在步骤23005中，第二LBA 2370可以向第二SSP 2360请求“选择的SSP信息(SspInfoSelected)”。在这种情况下，步骤23005可以自动执行，或者可以在接收到外部输入之后执行。在这种情况下，可以通过由第二终端2350提供的UI从用户给出“外部输入”，或者可以通过推送输入从远程服务器向第二终端2350给出“外部输入”。
参考图23，在步骤23010中，第二SSP 2360可以生成其“选择的SSP信息”。对“选择的SSP信息”的描述参考参考图22描述的描述。
参考图23，在步骤23015中，第二SSP 2360可以将在步骤23010中生成的“选择的SSP信息”发送到第二LBA 2370。
可以不选择性地执行步骤23005至23015。
参考图23，在步骤23020中，第二LBA 2370可以向服务器2300发送“选择的SSP信息”。当第二LBA 2370已经通过图22的步骤22035到22040接收到“选择的SSP信息”或者通过图23的步骤23005到23015接收到“选择的SSP信息”时，第二LBA 2370可以将接收到的“选择的SSP信息”发送到服务器2300。当第二LBA 2370尚未接收到“选择的SSP信息”时，第二LBA2370可以生成“选择的SSP信息”并将该SSP信息发送到服务器2300。
参考图23，在步骤23025中，服务器2300可以识别接收到的“选择的SSP信息”并基于该信息生成能够认证自身“服务器认证信息(SPBM.Auth)”。该过程的更详细的步骤如下。
服务器2300可使用接收到的“spbmVerification”来识别能够验证自身的证书信息，并选择至少一个密钥协商证书(spbm.Cert.KA)。替代地，服务器2300可以使用接收到的“第二SSP 2360支持的密钥协商算法列表”生成公钥“spbm.ePK.KA”和私钥“spbm.eSK.KA”作为将要用于密钥协商的非对称加密的密钥对，然后在密钥对中选择公钥(spbm.ePK.KA)。此外，服务器2300可使用接收的“spbmVerification”来识别能够由自己验证的证书信息，并进一步选择至少一个签名证书(spbm.Cert.DS)。
此外，服务器2300可使用接收的“SenderSpblVerification”来识别执行验证的第一SSP 2210的证书信息是否可由其自身验证。该过程可以不被选择性地执行。
此外，服务器2300可使用接收的“ReceiverSpblVerification”来识别执行验证的第二SSP 2360的证书信息是否可由其自身验证。替代地，服务器2300可以使用“ReceiverSpblVerification”选择第二SSP 2360的能够被其自身验证的至少一个证书信息，然后将对应的信息配置为“CiPkIdToBeUsed”。
此外，服务器2300可使用接收到的“第二SSP 2360支持的加密算法列表”选择要在未来使用的至少一个加密算法，并将对应的信息配置为“CryptoToBeUsed”。
此外，服务器2300可以识别所接收的“由第二SSP 2360中包括的主平台和加载器所支持的标准规范的版本信息”的列表，并且识别当中是否存在其自身所支持的标准规范的版本。
“服务器认证信息(SPBM.Auth)”可以包括上述“spbm.Cert.KA”、“spbm.ePK.KA”、“CiPkIdToBeUsed”或“CryptoToBeUsed”中的至少一个。此外，“服务器认证信息(SPBM.Auth)”可以可选地进一步包括上述“spbm.Cert.DS”。
在这种情况下，上述“服务器认证信息(SPBM.Auth)”的部分或全部可以被数字签名，从而可以使用spbm.Cert.DS来验证它以确保信息的完整性，数字签名数据可作为“服务器认证信息”的部分被添加。
参考图23，在步骤23030中，服务器2300可以经由第二LBA 2370将在步骤23025中生成的“服务器认证信息(SPBM.Auth)”传输到第二SSP 2360。
参考图23，在步骤23035中，第二SSP 2360可以验证接收的“服务器认证信息(SPBM.Auth)”。当第二SSP 2360接收到“spbm.Cert.KA”时，第二SSP 2360可以识别对应证书的签名，以识别证书的有效性。此外，当第二SSP 2360接收到“spbm.Cert.DS”时，第二SSP2360可以识别对应证书的签名，以识别证书的有效性。此外，当第二SSP 2360接收到“spbm.ePK.KA”及其数字签名时，第二SSP 2360可以使用spbm.Cert.DS来识别数字签名以识别接收的公钥spbm.ePK.KA的完整性。此外，当接收到“CiPkIdToBeUsed”时，第二SSP2360可以识别“CiPkIdToBeUsed”以选择能够验证自身的至少一个签名证书(ssp2.Cert.DS)。
此外，尽管图中未示出，但是在步骤23035中，第二SSP 2360可以生成公钥“ssp2.ePK.KA”和私钥“ssp2.eSK.KA”作为将要用于密钥协商的非对称加密的密钥对，然后在密钥对中选择公钥(ssp2.ePK.KA)。此外，第二SSP 2360可选择spbm.ePK.KA或spbm.Cert.KA中包括的用于密钥协商的公钥中的一个，然后使用该值和ssp2.eSK.KA生成将要用于将来与服务器通信期间的加密的会话密钥ShKey03。ShKey03应该是包括在接收的“CryptoToBeUsed”中的加密算法的会话密钥。
此外，在步骤23035中，第二SSP 2360可以生成能够认证自身的“终端认证信息(Device.Auth)”。在这种情况下，“终端认证信息(Device.Auth)”可以包括“ssp2.Cert.DS”。此外，“终端认证信息(Device.Auth)”可以可选地进一步包括“ssp1.Cert.DS”。此外，“终端认证信息(Device.Auth)”还可以包括与“ssp2.Cert.DS”和/或“ssp1.Cert.DS”相关联的证书链信息。此外，“终端认证信息(Device.Auth)”可以包括spblAttestation的部分和/或全部。此外，“终端认证信息(Device.Auth)”可以包括finalizationRequest的部分和/或全部。此外，“终端认证信息(Device.Auth)”可以包括finalizationResponse的部分和/或全部的。此外，“终端认证信息(Device.Auth)”可以进一步包括“ssp2.ePK.KA”。
在这种情况下，上述“终端认证信息(Device.Auth)”的一些和全部可以被数字签名，从而可以使用ssp2.Cert.DS来验证它以确保信息的完整性，并且可以添加数字签名数据作为“终端认证信息”的部分。此外，“终端认证信息(Device.Auth)”的部分或全部可以使用先前生成的会话密钥ShKey03来加密。
参考图23，在步骤23040中，第二SSP 2360可以经由第二LBA 2370将在步骤23035中生成的“终端认证信息(Device.Auth)”传输到服务器2300。
参考图23，在步骤23045，服务器2300可以验证接收的“终端认证信息(Device.Auth)”。验证过程的具体步骤如下。服务器2300可以验证接收到的“ssp1.Cert.DS”和/或“ssp2.Cert.DS”的签名以验证对应证书的有效性。此外，服务器2300可以验证接收到的spblAttestation、finalizationRequest和/或finalizationResponse的签名。此外，服务器2300可以验证接收到的spblAttestation、finalizationRequest和/或finalizationResponse的内容。此外，服务器2300可基于验证的内容更新在设备之间发送的包的细节。例如，服务器2300可以将包和第一SSP 2210之间已经存在的映射关系更新为包和第二SSP 2360之间的映射关系。
在此过程中，当加密数据包括在“终端认证信息(Device.Auth)”中时，服务器2300可以使用spbm.eSK.KA或与包括在接收到的ssp2.ePK.KA中的用于密钥协商的公钥相对应的私钥以及其spbm.Cert.KA来生成会话密钥ShKey03，使用会话密钥解密加密的数据，然后执行验证过程。
参考图23，在步骤23050中，服务器2300可以将在步骤23045中执行的操作的结果(例如，成功还是失败)发送到第二LBA 2370。
图24是示出图19中呈现的过程当中完成包的传输的过程的另一详细过程的图。
图24示出了当设备之间的包的传输历史是如下情况时被应用的过程
-不需要预先通知，并且
-通知内容不需要加密。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图24的示例中，第一终端2400可以包括第一LBA 2420和第一SSP 2410，第二终端2450可以包括第二LBA2470和第二SSP 2460。例如，第一终端2400可以是其中安装了第一SSP 2410并且其中安装了用于控制第一SSP 2410的第一LBA 2420的终端，第二终端2450可以是其中安装了第二SSP 2460并且其中安装了用于控制第二SSP 2460的第二LBA 2470的终端。
参考图24，在步骤24000中可以执行以下过程。
1.安装包
参考图24，在步骤24000中，第二LBA 2470和第二SSP 2460可以彼此协作以在第二终端2450中安装包。在该过程中，可以一起执行以下步骤。当发送元数据时，第二LBA 2470或第二SSP 2460可验证包括在元数据中的内容。当发送“包传输配置”时，第二LBA 2470可以将信息传输到第二SSP 2460。当发送事务ID时，第二LBA 2470或第二SSP 2460可以检查事务ID是否与当前会话中使用的事务ID相同。当发送包标识符(SPB ID)、包族标识符(SPB族ID)或包族管理器标识符(SPB族保管者对象ID)中的至少一个时，第二LBA 2470或第二SSP 2460可以识别该信息是否与当前要接收的包的信息相匹配。当ssp1.Cert.DS被发送时，第二SSP 2460可以验证证书的有效性以认证第一SSP 2410。当接收的数据包括加密的数据时，第二SSP 2460可使用接收的ssp1.bundle.ePK.KA及其ssp2.eSK.KA生成会话密钥ShKey02，使用会话密钥解密加密的数据，然后执行验证。当接收的数据包括数字签名时，第二SSP 2460可以验证ssp1.Cer.DS，然后使用证书验证数字签名的有效性。
2.识别“注册配置”
此外，尽管图中未示出，第二LBA 2470和/或第二SSP 2460可以识别是否“需要通知”、是否“需要预先通知”、和/或是否需要使用包的“注册配置”来加密通知内容。该过程是步骤24000的一部分，并且可以独立于在步骤24000中执行的其他过程的顺序来执行。替代地，在步骤24000之后，在步骤24035完成之前，可以在需要确定的时刻执行该过程。稍后将在附图中描述的过程可以是当以下情况时要被应用的过程：作为识别“注册配置”的结果，设备之间的包的传输历史不需要被预先通知并且通知内容不需要加密。
参考图24，在步骤24005中，第二SSP 2460可以将包状态配置为“转换中”。“转换中”意味着包已经被成功安装但是还不可用的状态(此外，仅通过“将在本图中稍后描述的额外操作”和/或诸如“来自外部服务器的请求(尽管在本公开中没有描述)”的额外操作而可以被改变为可用状态(禁用、启用、活动状态)的状态)。
参考图24，在步骤24010，第二LBA 2470可以向第二SSP 2460请求“证明”。
参考图24，在步骤24015中，第二SSP 2460可以生成“证明”。在图24中，该证明可以被称为finalizationRequest。证明的结构可以遵循图18中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-finalizationRequest可以在图18的1810中包括对应包的“包定界符”。
-finalizationRequest可以在图18的1830中包括第二SSP的“SSP标识符”。
-finalizationRequest可以在图18的1850中包括指示第二SSP将包状态配置为“转换中”状态的信息。
-finalizationRequest可以可选地在图18的1870中包括其中第二SSP将包状态改变为“转换中”状态的时间或者其中生成证明的时间。替代地，finalizationRequest可以包括关于用于签名的证书(用于稍后描述的电子签名)的信息，以及关于与其相关的证书链的信息。
-finalizationRequest可以在图18的1890中包括第二SSP的签名信息。签名可以是通过用第二SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图2，在步骤24020中，第二SSP 2460可以向第一SSP 2410传输finalizationRequest。例如，第二SSP 2460可以通过以下过程将finalizationRequest传输到第一SSP 2410。也就是说，响应于步骤24010，第二SSP 2460可以将finalizationRequest传输到第二LBA 2470，并且第二LBA 2470可以经由第一LBA 2420将finalizationRequest传输到第一SSP 2410。
参考图24，在步骤24025中，第一SSP 2410可以验证接收到的finalizationRequest。验证过程可以包括检查包含在finalizationRequest中的第二SSP的签名的有效性的步骤。此外，验证过程还可以包括检查包含在finalizationRequest中的“包定界符”是否与对应包的包定界符相匹配的过程。此外，验证过程还可以包括检查包含在finalizationRequest中的“SSP标识符”是否是第二SSP的有效标识符的过程。此外，验证过程还可以包括识别包括在finalizationRequest中的指令信息是否是将包状态改变为“转换中”状态的指令信息的过程。
此外，在步骤24025中，第一SSP 2410可以在验证完成之后删除包。
此外，在步骤24025中，第一SSP 2410可以生成“证明”。在图24中，该证明可以被称为finalizationResponse。证明的结构可以遵循图18中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-finalizationResponse可以在图18的1810中包括对应包的“包定界符”。替代地，finalizationResponse可以包括在先前步骤中接收的finalizationRequest的部分和/或全部数据。
-finalizationResponse可以在图18的1830中包括第一SSP的“SSP标识符”。
-finalizationResponse可以在图18的1850包括指示第一SSP已经删除了包的信息。
-finalizationResponse可以可选地在图18的1870中包括其中第一SSP删除包的时间或者其中生成证明的时间。替代地，finalizationResponse可以包括关于用于签名的证书(用于稍后描述的电子签名)的信息，以及关于与其相关的证书链的信息。
-finalizationResponse可以在图18的1890中包括第一SSP的签名信息。签名可以是通过用第一SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图24，在步骤24030中，第一SSP 2410可以向第二SSP 2460传输finalizationResponse。例如，第一SSP 2410可以经由第一LBA 2420和第二LBA 2470向第二SSP 2460传输finalizationResponse。
参考图24，在步骤24035中，第二SSP 2460可以验证接收到的finalizationResponse。验证过程可以包括检查包含在finalizationResponse中的第一SSP的签名的有效性的步骤。此外，验证过程可以可选地进一步包括检查包含在finalizationResponse中的“包定界符”是否与对应包的包定界符相匹配的过程。此外，验证过程可以包括检查包含在finalizationResponse中的finalizationRequest的部分或全部数据是否与自身已经发送的信息相匹配的过程。此外，验证过程还可以包括识别包含在finalizationResponse中的“SSP标识符”的过程。此外，验证过程还可以包括识别包括在finalizationResponse中的指令信息是否是删除包的指令信息的过程。
此外，在步骤24035中，在验证完成之后，第二SSP 2460可以将包状态改变为可用状态之一(禁用、启用和活动之一)。例如，如图所示，第二SSP 2460可以将包状态转换为禁用状态。
此外，在步骤24035中，第二SSP 2460可以生成“证明”。在图24中，证明可以被称为spblAttestation。证明的结构可以遵循图18中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-spblAttestation可以在图18的1810中包括对应包的“包定界符”。替代地，spblAttestation可以包括finalizationRequest和/或finalizationResponse的部分和/或全部数据。
-spblAttestation可以在图18的1830中包括第二SSP的“SSP标识符”。
-spblAttestation可以在图18的1850中包括指示第二SSP已经将包状态改变为可用状态之一的信息。
-spblAttestation可以可选地在图18的1870中包括其中第二SSP将包状态改变为可用状态之一的时间或者其中生成证明的时间。替代地，spblAttestation可以包括关于用于签名的证书(用于稍后描述的电子签名)的信息，以及关于与其相关的证书链的信息。
-spblAttestation可以在图18的1890中包括第二SSP的签名信息。签名可以是通过用第二SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图24，在步骤24040中，第二SSP 2460可以发送在步骤24035中生成的spblAttestation。
图25是图示在图24中呈现的过程之后在服务器中注册包传输结果的过程的图。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图25的示例中，第二终端2550可以包括第二LBA 2570和第二SSP 2560。例如，第二终端2550可以是其中安装了第二SSP 2560并且其中安装了用于控制第二SSP 2560的第二LBA 2570的终端。
此外，根据各种实施例，服务器2500可以是由服务提供商操作的服务器、包管理服务器、由服务提供商和包管理服务器之间的协作操作的服务器、或者与服务提供商和/或包管理服务器相关联地操作的任何服务器。在附图的描述中，尽管作为服务器的可能示例之一的术语SPBM有时用于指代服务器2500，但是如上所述，服务器的类型不限于SPBM。
参考图25，在步骤25000中，可以在SPBM 2500和LBA 2570之间建立传输层安全性(TLS)连接。
参考图25，在步骤25005中，第二LBA 2570可以向服务器2500发送spblAttestation、finalizationRequest和/或finalizationResponse的部分和/或全部。在这种情况下，第二LBA 2570可以进一步将“选择的SSP信息”发送到服务器2500。“选择的SSP信息”的描述参考图22的描述。此外，第二LBA 2570可以选择性地进一步将“ssp2.Cert.DS”发送到服务器2500。此外，第二LBA2570可以选择性地进一步将“ssp1.Cert.DS”发送到服务器2500。此外，第二LBA 2570还可以将与“ssp2.Cert.DS”和/或“ssp1.Cert.DS”相关联的证书链信息包括到服务器2500。上述信息可以由第二LBA 2570自身配置和发送，尽管图中未示出，但是在向第二SSP 2560请求对应的信息之后，第二LBA2570可以发送接收到的信息，或者尽管图中未示出，第二LBA 2570可以向第二SSP 2560请求对应的信息的部分，然后组合并发送接收到的信息及其信息。
参考图25，在步骤25010中，服务器2500可以验证在步骤25005中接收的信息。验证过程的具体过程如下。服务器2500可以验证接收到的“ssp1.Cert.DS”和/或“ssp2.Cert.DS”的签名以验证对应证书的有效性。此外，服务器2500可以验证接收到的spblAttestation、finalizationRequest和/或finalizationResponse的签名。此外，服务器2700可以验证接收到的spblAttestation、finalizationRequest和/或finalizationResponse的内容。此外，服务器2500可基于验证的内容更新在装置之间发送的包的细节。例如，服务器2500可以将包和第一SSP 2410之间已经存在的映射关系更新为包和第二SSP 2560之间的映射关系。
参考图25，在步骤25015中，服务器2500可以将在步骤25010中执行的验证操作的结果发送到第二LBA 2570。例如，服务器2500可以向第二LBA 2570发送验证是成功还是失败。
图26是示出图19中示出的过程当中完成包的传输的过程的另一详细过程的图。
图26示出了当设备之间的包的传输历史是以下情况时被应用的过程
-需要预先通知，并且
-需要或不需要加密通知内容
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图26的示例中，第一终端2600可以包括第一LBA 2620和第一SSP 2610，第二终端2650可以包括第二LBA2670和第二SSP 2660。例如，第一终端2600可以是其中安装了第一SSP 2610并且其中安装了用于控制第一SSP 2610的第一LBA 2620的终端，第二终端2650可以是其中安装了第二SSP 2660并且其中安装了用于控制第二SSP 2660的第二LBA 2670的终端。
参考图26，在步骤26000中，可以执行以下过程。
1.安装包
参考图26，在步骤26000中，第二LBA 2670和第二SSP 2660可以彼此协作以在第二终端2650中安装包。在该过程中，可以一起执行以下步骤。当发送元数据时，第二LBA 2670或第二SSP 2660可验证包括在元数据中的内容。当发送“包传输配置”时，第二LBA 2670可以将信息传输到第二SSP 2660。当发送事务ID时，第二LBA 2670或第二SSP 2660可以检查事务ID是否与当前会话中使用的事务ID相同。当发送包标识符(SPB ID)、包族标识符(SPB族ID)或包族管理器标识符(SPB族保管者对象ID)中的至少一个时，第二LBA 2670或第二SSP 2660可以识别该信息是否与当前要接收的包的信息相匹配。当ssp1.Cert.DS被发送时，第二SSP 2660可以验证证书的有效性以认证第一SSP 2610。当接收的数据包括加密的数据时，第二SSP 2660可使用接收的ssp1.bundle.ePK.KA及其ssp2.eSK.KA生成会话密钥ShKey02，并使用会话密钥解密和验证加密的数据。当接收的数据包括数字签名时，第二SSP2660可以验证ssp1.Cer.DS，然后使用证书验证数字签名的有效性。
2.识别是否需要预先注册
此外，尽管图中未示出，第二LBA 2670和/或第二SSP 2660可以识别是否需要“通知”、是否需要“预先通知”、和/或是否需要使用包的“注册配置”来加密通知内容。该过程是步骤26000的一部分，并且可以独立于在步骤26000中执行的其他过程的顺序来执行。替代地，在步骤26000之后，在步骤26035完成之前，可以在需要确定的时刻执行该过程。稍后将在附图中描述的过程可以是当以下情况时要被应用的过程：作为识别“注册配置”的结果，设备之间的包的传输历史不需要被预先通知。
参考图26，在步骤26005中，第二SSP 2660可以将包状态配置为“转换中”。“转换中”意味着包已经被成功安装但是还不可用的状态(此外，仅通过“将在本图中稍后描述的额外操作”和将参考图27描述的额外操作和/或诸如“来自外部服务器的请求(尽管在本公开中没有描述)”的额外操作而可以被改变为可用状态(禁用、启用、活动状态)的状态)。
参考图26，在步骤26010，第二LBA 2670可以向第二SSP 2660请求“证明”。
参考图26，在步骤26015中，第二SSP 2660可以生成“证明”。在图26中，该证明可以被称为finalizationRequest。证明的结构可以遵循图18中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-finalizationRequest可以在图18的1810中包括对应包的“包定界符”。
-finalizationRequest可以在图18的1830中包括第二SSP的“SSP标识符”。
-finalizationRequest可以在图18的1850中包括指示第二SSP将包状态配置为“转换中”状态的信息。
-finalizationRequest可以可选地在图18的1870中包括其中第二SSP将包状态改变为“转换中”状态的时间或者其中生成证明的时间。替代地，finalizationRequest可以包括关于用于签名的证书(用于稍后描述的电子签名)的信息，以及关于与其相关的证书链的信息。
-finalizationRequest可以在图18的1890中包括第二SSP的签名信息。签名可以是通过用第二SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图26，在步骤26020中，第二SSP 2660可以向第一SSP 2610传输finalizationRequest。例如，第二SSP 2660可以通过以下过程将finalizationRequest传输到第一SSP 2610。也就是说，响应于步骤26010，第二SSP 2660可以将finalizationRequest传输到第二LBA 2670，并且第二LBA可以通过第一LBA 2620将finalizationRequest传输到第一SSP。
参考图26，在步骤26025中，第一SSP 2610可以验证接收到的finalizationRequest。验证过程可以包括检查包含在finalizationRequest中的第二SSP的签名的有效性的步骤。此外，验证过程还可以包括检查包含在finalizationRequest中的“包定界符”是否与对应包的包定界符相匹配的过程。此外，验证过程还可以包括检查包含在finalizationRequest中的“SSP标识符”是否是第二SSP的有效标识符的过程。此外，验证过程还可以包括识别包含在finalizationRequest中的指令信息是否是将包状态改变为“转换中”状态的指令信息的过程。
此外，在步骤26025中，第一SSP 2610可以在验证完成之后删除包。
此外，在步骤26025中，第一SSP 2610可以生成“证明”。在图26中，该证明可以被称为finalizationResponse。证明的结构可以遵循图18中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-finalizationResponse可以在图18的1810中包括对应包的“包定界符”。替代地，finalizationResponse可以包括在先前步骤中接收的finalizationRequest的部分和/或全部数据。
-finalizationResponse可以在图18的1830中包括第一SSP的“SSP标识符”。
-finalizationResponse可以在图18的1850中包括指示第一SSP已经删除了包的信息。
-finalizationResponse可以可选地在图18的1870中包括其中第一SSP删除包的时间或者其中生成证明的时间。替代地，finalizationResponse可以包括关于用于签名的证书(用于稍后描述的电子签名)的信息，以及关于与其相关的证书链的信息。
-finalizationResponse可以在图18的1890中包括第一SSP的签名信息。签名可以是通过用第一SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图26，在步骤26030中，第一SSP 2610可以将finalizationResponse传输给第二SSP 2660。例如，第一SSP 2610可以经由第一LBA 2620和第二LBA 2670将finalizationResponse传输给第二SSP 2660。
参考图26，在步骤26035中，第二SSP 2660可以验证接收到的finalizationResponse。验证过程可以包括检查包含在finalizationResponse中的第一SSP的签名的有效性的步骤。此外，验证过程可以可选地进一步包括检查包含在finalizationResponse中的“包定界符”是否与对应包的包定界符相匹配的过程。此外，验证过程可以包括检查包含在finalizationResponse中的finalizationRequest的部分或全部数据是否与其自身已经发送的信息相匹配的过程。此外，验证过程还可以包括识别包含在finalizationResponse中的“SSP标识符”的过程。此外，验证过程还可以包括识别包含在finalizationResponse中的指令信息是否是删除包的指令信息的过程。
此外，在步骤26035中，第二SSP 2660可以生成其“选择的SSP信息(sspInforSelected)”。“选择的SSP信息”可以包括关于要提供的第二SSP的信息，以便通知服务器设备之间的包传输的结果。
在这种情况下，“选择的SSP信息”可以包括用于证书协商过程的信息(证书协商信息)。“证书协商信息”可以可选地包括以下信息
-第二SSP 2660可以用于验证服务器的证书信息(spbmVerification)
-服务器可以用于验证第一SSP 2610的证书信息(SenderSpblVerification)
-服务器可用于验证第二SSP 2660的证书信息(ReceiverSpblVerification)
此外，“证书协商信息”可以可选地进一步包括第二SSP 2660支持的密钥协商算法列表，并且可选地进一步包括第二SSP 2660支持的加密算法列表。
此外，“选择的SSP信息”可以可选地进一步包括SSP版本信息，该SSP版本信息包括由第二SSP 2660中包括的主平台和加载器支持的标准规范的版本信息中的至少一个。
参考图26，在步骤26040中，第二SSP 2660可以将在步骤26035中执行的操作的结果(例如，成功还是失败)发送到第二LBA 2670。此外，在步骤26035中生成的“选择的SSP信息”可以一起发送。
可以省略步骤26035中生成“选择的SSP信息”的过程和步骤26040中传输“选择的SSP信息”的过程。
图27是图示在图26中呈现的过程之后在服务器中注册包传输结果的过程的图。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图27的示例中，第二终端2750可以包括第二LBA 2770和第二SSP 2760。例如，第二终端2750可以是其中安装了第二SSP 2760并且其中安装了用于控制第二SSP 2760的第二LBA 2770的终端。
此外，根据各种实施例，服务器2700可以是由服务提供商操作的服务器、包管理服务器、由服务提供商和包管理服务器之间的协作操作的服务器、或者与服务提供商和/或包管理服务器相关联地操作的任何服务器。在附图的描述中，尽管作为服务器的可能示例之一的术语SPBM有时用于指代服务器2700，但是如上所述，服务器的类型不限于SPBM。
参考图27，在步骤27000中，可以在SPBM 2700和LBA 2770之间建立传输层安全性(TLS)连接。尽管参考附图描述了在步骤27005至27015之前执行步骤27000，但是在执行步骤27020之前，可以独立于步骤27005至27015执行步骤27000。例如，步骤27000可以在步骤27015和27020之间执行。
参考图27，在步骤27005中，第二LBA 2770可以向第二SSP 2760请求“选择的SSP信息(SspInfoSelected)”。在这种情况下，步骤27005可以自动执行，或者可以在接收到外部输入之后执行。在这种情况下，可以通过由第二终端2750提供的UI从用户给出“外部输入”，或者可以通过推送输入从远程服务器向第二终端2750给出“外部输入”。
参考图27，在步骤27010中，第二SSP 2760可以生成其“选择的SSP信息”。“选择的SSP信息”的描述参考图26的描述。
参考图27，在步骤27015中，第二SSP 2760可以将在步骤27010中生成的“选择的SSP信息”发送给第二LBA 2770。
在某些情况下，可以省略步骤27005至27015。
参考图27，在步骤27020中，第二LBA 2770可以将“选择的SSP信息”发送给服务器2700。当第二LBA 2770已经通过图26的步骤26035到26040接收到“选择的SSP信息”或者通过图27的步骤27005到27015接收到“选择的SSP信息”时，第二LBA 2770可以将接收到的“选择的SSP信息”发送到服务器2700。当第二LBA 2770尚未接收到“选择的SSP信息”时，第二LBA 2770可以生成“选择的SSP信息”并将“选择的SSP信息”发送到服务器2700。
参考图27，在步骤27025中，服务器2700可以识别接收到的“选择的SSP信息”并基于该信息生成能够认证自身的“服务器认证信息(SPBM.Auth)”。该过程的更详细的步骤如下。
服务器2700可使用接收到的“spbmVerification”来识别能够验证其自身的证书信息，并选择至少一个密钥协商证书(spbm.Cert.KA)。替代地，服务器2700可以使用接收到的“第二SSP 2760支持的密钥协商算法列表”生成公钥“spbm.ePK.KA”和私钥“spbm.eSK.KA”作为将要用于密钥协商的非对称加密的密钥对，然后在密钥对中选择公钥(spbm.ePK.KA)。此外，服务器2700可使用接收到的“spbmVerification”来识别能够验证其自身的证书信息，并进一步选择至少一个签名证书(spbm.Cert.DS)。
此外，服务器2700可使用接收的“SenderSpblVerification”来识别执行验证的第一SSP 2610的证书信息是否可由其自身验证。
此外，服务器2700可使用接收的“ReceiverSpblVerification”来识别执行验证的第二SSP 2760的证书信息是否可由其自身验证。替代地，在使用“ReceiverSpblVerification”选择第二SSP 2760的能够由其自身验证的至少一个证书信息之后，服务器2700可以将对应的信息配置为“CiPkIdToBeUsed”。
此外，服务器2700可使用接收到的“第二SSP 2760支持的加密算法列表”选择要在未来使用的至少一个加密算法，并将对应的信息配置为“CryptoToBeUsed”。
此外，服务器2700可以识别所接收的“由第二SSP 2760中包括的主平台和加载器所支持的标准规范的版本信息”的列表，并且识别其中是否存在其自身所支持的标准规范的版本。
“服务器认证信息(SPBM.Auth)”可以包括上述“spbm.Cert.KA”、“spbm.ePK.KA”、“spbm.Cert.DS”、“CiPkIdToBeUsed”或“CryptoToBeUsed”中的至少一个。
在这种情况下，上述“服务器认证信息(SPBM.Auth)”的部分或全部可以被数字签名，从而可以使用spbm.Cert.DS来验证它以确保信息的完整性，数字签名数据可作为“服务器认证信息”的部分添加。
参考图27，在步骤27030中，服务器2700可以经由第二LBA 2770将在步骤27025中生成的“服务器认证信息(SPBM.Auth)”传输到第二SSP 2760。
参考图27，在步骤27035，第二SSP 2760可以验证接收到的“服务器认证信息(SPBM.Auth)”。当第二SSP 2760接收到“spbm.Cert.KA”时，第二SSP 2760可以识别对应证书的签名以识别证书的有效性。此外，当第二SSP 2760接收到“spbm.Cert.DS”时，第二SSP2760可以识别对应证书的签名以识别证书的有效性。此外，当第二SSP 2760接收到“spbm.ePK.KA”及其数字签名时，第二SSP 2760可以使用spbm.Cert.DS来识别数字签名以识别接收到的公钥spbm.ePK.KA的完整性。此外，在接收到“CiPkIdToBeUsed”时，第二SSP2760可以识别“CiPkIdToBeUsed”以选择能够验证自身的至少一个签名证书(ssp2.Cert.DS)。
此外，尽管图中未示出，但是在步骤27035中，第二SSP 2760可以生成公钥“ssp2.ePK.KA”和私钥“ssp2.eSK.KA”作为将要用于密钥协商的非对称加密的密钥对，然后在密钥对中选择公钥(ssp2.ePK.KA)。此外，第二SSP 2760可以选择spbm.ePK.KA或包括在spbm.Cert.KA中的用于密钥协商的公钥中的一个，然后使用该值和ssp2.eSK.KA生成用于将来与服务器通信期间的加密的会话密钥ShKey03。ShKey03应该是用于包括在接收到的“CryptoToBeUsed”中的加密算法的会话密钥。
此外，在步骤27035中，第二SSP 2760可以生成能够认证自身的“终端认证信息(Device.Auth)”。在这种情况下，“终端认证信息(Device.Auth)”可以包括“ssp2.Cert.DS”。此外，“终端认证信息(Device.Auth)”可以进一步包括“ssp2.ePK.KA”。此外，“终端认证信息(Device.Auth)”可以可选地进一步包括“ssp1.Cert.DS”。此外，“终端认证信息(Device.Auth)”可以包括finalizationRequest的部分和/或全部。此外，“终端认证信息(Device.Auth)”可以包括finalizationResponse的部分和/或全部。
在这种情况下，上述“终端认证信息(Device.Auth)”的一些或全部可以被数字签名，从而可以使用ssp2.Cert.DS来验证它以确保信息的完整性，并且可以添加数字签名数据作为“终端认证信息”的部分。此外，“终端认证信息(Device.Auth)”的部分或全部可以使用先前生成的会话密钥ShKey03来加密。
参考图27，在步骤27040，第二SSP 2760可以经由第二LBA 2770将在步骤27035中生成的“终端认证信息(Device.Auth)”发送到服务器2700。
参考图27，在步骤27045，服务器2700可以验证接收的“终端认证信息(Device.Auth)”。验证过程的具体步骤如下。服务器2700可以验证接收到的“ssp1.Cert.DS”和/或“ssp2.Cert.DS”的签名以验证对应证书的有效性。此外，服务器2700可以验证所接收的finalizationRequest和/或finalizationResponse的签名。此外，服务器2700可以验证接收到的finalizationRequest和/或finalizationResponse的内容。此外，服务器2700可以基于验证的内容更新在设备之间发送的包的细节。例如，服务器2700可以将包和第一SSP 2610之间已经存在的映射关系更新为包和第二SSP 2760之间的映射关系。
在此过程中，当加密数据包括在“终端认证信息(Device.Auth)”中时，服务器2700可使用spbm.eSK.KA或与包括在接收的ssp2.ePK.KA中的用于密钥协商的公钥相对应的私钥及其spbm.Cert.KA来生成会话密钥ShKey03，使用会话密钥解密加密的数据，然后执行验证过程。
此外，在步骤27045中，服务器2700可以生成“证明”。在图27中，证明可以被称为spbmAttestation。证明的结构可以遵循图18中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-spbmAttestation可以在图18的1810中包括包的“包定界符”。替代地，spbmAttestation可以包括在先前步骤中接收的finalizationRequest和/或finalizationResponse的部分和/或全部数据。
-spbmAttestation可以在图18的1830中包括服务器的标识符(例如，服务提供商的标识符和/或包管理服务器的标识符和/或服务器的地址)。
-spbmAttestation可以在图18的1850中包括指示服务器识别了包的移动历史的信息。
-spbmAttestation可以可选地在图18的1870中包括其中服务器识别包的移动历史的时间或者其中生成证明的时间。替代地，spbmAttestation可以包括关于用于签名的证书(用于稍后描述的电子签名)的信息，以及关于与其相关的证书链的信息。
-spbmAttestation可以在图18的1890中包括服务器的签名信息。签名可以是通过用服务器的签名证书对上述信息进行数字签名而获得的签名信息。
此外，在步骤27045中，尽管在图27中未示出，但是服务器2700可以生成公钥“spbm.attestation.ePK.KA”和私钥“spbm.attestation.eSK.KA”作为将要用于密钥协商的非对称加密的密钥对。在这种情况下，密钥对“spbm.attestation.ePK.KA和spbm.attestation.eSK.KA”可以被配置为与先前生成的“spbm.ePK.KA和spbm.eSK.KA”相同的值。替代地，密钥对“spbm.attestation.ePK.KA和spbm.attestation.eSK.KA”可被配置为与先前使用的“spbm.Cert.KA中包括的公钥和对应的私钥”相同的值。此外，服务器2700可以使用spbm.attestation.eSK.KA和ssp2.ePK.KA生成会话密钥ShKey04。当“与包括在spbm.eSK.KA或spbm.Cert.Ka中的公钥相对应的私钥被重用于spbm.attstation.eSK.KA时，会话密钥ShKey04的值可以被配置为先前生成的ShKey03的值。
此外，在步骤27045中，尽管在图27中未示出，但是服务器2700可以配置“证明验证数据”。“证明验证数据”可以包括“spbm.Cert.DS”。此外，还可以包括“spbm.attestation.ePK.KA”和/或“spbm.attestation.ePK.KA”的服务器的数字签名值。
根据各种实施例，在步骤27045中生成的“证明”和“证明验证数据”中的一些和/或全部可以使用ShKey04来加密。
参考图27，在步骤27050中，服务器2700可以经由第二LBA 2770将在步骤27045中生成的“spbmAttestation”和“证明验证数据”发送到第二SSP 2760。
参考图27，在步骤27055中，第二SSP 2760可以验证所接收的“spbmAttestation”和/或“证明验证数据”。当接收的数据包括加密的数据时，第二SSP 2760可使用接收的spbm.attestation.ePK.KA及其ssp2.eSK.KA生成会话密钥ShKey04，并使用会话密钥解密然后验证加密的数据。当接收的数据包括数字签名时，第二SSP 2760可以验证spbm.Cert.DS，然后使用证书验证数字签名的有效性。
此外，在步骤27055中，在验证完成之后，第二SSP 2760可以将包状态改变为可用状态之一(禁用、启用和活动之一)。例如，如图所示，第二SSP 2760可以将包状态转换为禁用状态。
参考图27，在步骤27060中，第二SSP 2760可以将步骤27060的结果传输到第二LBA2770。例如，第二SSP 2760可以将步骤27060的验证成功或失败结果传输给第二LBA 2770。
图28是示出根据本公开实施例的终端的构造的框图。
如图28所示，终端可以包括收发器2810和至少一个处理器2820。此外，终端还可以包括SSP 2830。例如，SSP 2830可以插入到终端中或者可以嵌入到终端中。该至少一个处理器2820可以被称为“控制器”。然而，终端的配置不限于图28的配置，并且可以包括比图28所示的组件更多或更少的组件。根据一些实施例，收发器2810、至少一个处理器2820和存储器(未示出)可以以单个芯片的形式实现。此外，当SSP 2830嵌入在终端中时，收发器2810、至少一个处理器2820和存储器(未示出)可以以包括SSP 2830的单个芯片的形式实现。
根据各种实施例，收发器2810可以根据本公开的各种实施例向另一终端或外部服务器的收发器发送信号、信息、数据等，以及从另一终端或外部服务器的收发器接收信号、信息、数据等。收发器2810可以包括用于上变频和放大要发送的信号的频率的RF发送器，以及用于低噪声放大接收的信号并下变频其频率的RF接收器。然而，这仅仅是收发器2810的示例，并且收发器2810的组件不限于RF发送器和RF接收器。此外，收发器2810可以通过无线信道接收信号，将信号输出到至少一个处理器2820，并且通过无线信道发送从至少一个处理器2820输出的信号。
根据各种实施例，收发器2810可以发送或接收来自另一终端的收发器或外部服务器的包括在另一终端中的SSP信息、能够认证另一终端的认证信息、能够认证服务器的认证信息、能够认证自身的认证信息、包传输码、包传输配置、包以及参考图22至图27描述的各种证明。
至少一个处理器2820是用于总体控制终端的组件。如上所述，根据本公开的各种实施例，至少一个处理器2820可以控制终端的整体操作。
SSP 2830可以包括用于安装和控制包的处理器或控制器，或者可以在其中安装应用。
根据各种实施例，SSP 2830中的至少一个处理器或控制器可以识别包传输配置，以确定是否发送特定包。此外，通过识别包传输配置，至少一个处理器或控制器可以确定设备之间的对应包的包传输的结果是否需要在服务器中注册，或者如果需要注册，是否需要预先通知。
此外，根据各种实施例，SSP中的至少一个处理器或控制器可以生成包传输码，以控制特定包的传输过程。
此外，根据各种实施例，SSP中的至少一个处理器或控制器可以生成其SSP信息，并识别和验证从外部接收的另一个SSP的SSP信息。
此外，根据各种实施例，SSP中的至少一个处理器或控制器可以生成能够验证其自身的认证信息，并验证从外部接收的另一个SSP的认证信息。
此外，根据各种实施例，SSP 2830可以单独或与一个或多个处理器2820合作生成包，并安装该包。此外，SSP 2830可以管理包。
此外，根据各种实施例，SSP 2830可以生成参考图22至图27描述的各种类型的证明，并验证接收到的证明。
此外，根据各种实施例，SSP 2830可以基于接收到的证明的内容来改变包状态，如参考图22至图27所描述的。
此外，根据各种实施例，SSP 2830可以在处理器2820的控制下操作。替代地，SSP2830可以包括用于安装和控制包的处理器或控制器，或者可以在其中安装应用。应用中的一些或全部可以安装在SSP 2830或存储器(未示出)中。
终端还可以包括存储器(未示出)，并存储诸如基本程序、应用程序和用于终端操作的配置信息的数据。此外，存储器可以包括闪存类型、硬盘类型、多媒体微型卡类型、卡类型存储器(例如，SD或XD存储器等)、磁存储器、磁盘、光盘、随机存取存储器(RAM)、静态随机存取存储器(SRAM)、只读存储器(ROM)、可编程只读存储器(PROM)或电可擦除可编程只读存储器(EEPROM)中的至少一种存储介质。此外，处理器2820可以使用存储在存储器中的各种程序、内容、数据等来执行各种操作。
图29是图示根据本公开实施例的服务器的配置的图。在这种情况下，服务器可以是由服务提供商操作的服务器、包管理服务器、由服务提供商和包管理服务器之间的协作操作的服务器、或者与服务提供商和/或包管理服务器相关联地操作的任何服务器。在该图的描述中，作为服务器的可能示例之一的术语包管理服务器用于指代服务器，但是如上所述，服务器的类型不限于包管理服务器。
根据一些实施例，包管理服务器可以包括收发器2910和至少一个处理器2920。然而，包管理服务器的配置不限于图29的配置，并且可以包括比图29所示更多或更少的组件。根据一些实施例，收发器2910、至少一个处理器2920和存储器(未示出)可以以单个芯片的形式实现。
根据一些实施例，收发器2910可以向终端发送和从终端接收根据本公开的各种实施例的信号、信息、数据等。收发器2910可以包括用于上变频和放大要发送的信号的频率的RF发送器，以及用于低噪声放大接收的信号并下变频其频率的RF接收器。然而，这仅仅是收发器2910的实施例，并且收发器2910的组件不限于RF发送器和RF接收器。此外，收发器2910可以通过无线信道接收信号，将信号输出到至少一个处理器2920，并通过无线信道发送从至少一个处理器2920输出的信号。
至少一个处理器2920是用于总体控制包管理服务器的组件。如上所述，根据本公开的各种实施例，处理器2920可以控制包管理服务器的整体操作。该至少一个处理器2920可以被称为控制器。
包管理服务器还可以包括存储器(未示出)，并且存储诸如基本程序、应用程序和用于包管理服务器的操作的配置信息的数据。此外，存储器可以包括闪存类型、硬盘类型、多媒体微型卡类型、卡类型存储器(例如，SD或XD存储器等)、磁存储器、磁盘、光盘、随机存取存储器(RAM)、静态随机存取存储器(SRAM)、只读存储器(ROM)、可编程只读存储器(PROM)或电可擦除可编程只读存储器(EEPROM)中的至少一种存储介质。此外，处理器2920可以使用存储在存储器中的各种程序、内容、数据等来执行各种操作。
图30是图示图19中呈现的过程当中完成包传输的过程和用于在服务器中注册包传输结果的过程的另一详细过程的图。
根据各种实施例，终端可以包括至少一个LBA和至少一个SSP。例如，在图30的示例中，第一终端3000可以包括第一LBA 3020和第一SSP 3010，第二终端3050可以包括第二LBA3070和第二SSP 3060。例如，第一终端3000可以是其中安装了第一SSP 3010并且其中安装了用于控制第一SSP 3010的第一LBA 3020的终端，第二终端3050可以是其中安装了第二SSP 3060并且其中安装了用于控制第二SSP 3060的第二LBA 3070的终端。
参考图30，在步骤30000中可以执行以下过程。
1.安装包
参考图30，在步骤30000中，第二LBA 3070和第二SSP 3060可以彼此协作以在第二终端3050中安装包。在该过程中，可以一起执行以下步骤。当发送元数据时，第二LBA 3070或第二SSP 3060可以验证包括在元数据中的内容。当发送“包传输配置”时，第二LBA 3070可以将信息传输到第二SSP3060。当发送事务ID时，第二LBA 3070或第二SSP 3060可以检查事务ID是否与当前会话中使用的事务ID相同。当发送包标识符(SPB ID)、包族标识符(SPB族ID)或包族管理器标识符(SPB族保管者对象ID)中的至少一个时，第二LBA 3070或第二SSP 3060可以识别该信息是否与当前要接收的包的信息相匹配。当发送ssp1.Cert.DS时，第二SSP 3060可以验证证书的有效性，以认证第一SSP 3010。当接收的数据包括加密的数据时，第二SSP 3060可使用接收的ssp1.bundle.ePK.KA及其ssp2.eSK.KA生成会话密钥ShKey02，使用会话密钥解密加密的数据，然后执行验证。当接收的数据包括数字签名时，第二SSP 3060可以验证ssp1.Cer.DS，然后使用证书验证数字签名的有效性。
2.识别“注册配置”
此外，尽管图中未示出，第二LBA 3070和/或第二SSP 3060可以识别是否“需要通知”、是否“需要预先通知”、和/或是否需要使用包的“注册配置”来加密通知内容。该过程是步骤30000的一部分，并且可以独立于步骤30000中执行的其他过程的顺序来执行。替代地，在步骤30000之后，在30040或30050中进行通知之前，可以识别“注册配置”，并且可以在需要确定的时刻执行该过程。
参考图30，在步骤30005中，第二SSP 3060可以将包状态配置为“转换中”。“转换中”可以表示包已经成功安装但不可用的状态(此外，仅通过诸如“来自第一终端3000的请求”和/或“来自外部服务器的请求”的操作而可以改变为可用状态(禁用、启用、活动状态)的状态)。
参考图30，在步骤30010中，第二LBA 3070可以向第二SSP 3060请求“证明”。
参考图30，在步骤30015中，第二SSP 3060可以生成“证明”。在图30中，该证明可以被称为finalizationRequest。证明的结构可以遵循图18中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-finalizationRequest可以在图18的510包括对应包的“包定界符”。
-finalizationRequest可以在图18的530中包括第二SSP的“SSP标识符”。
-finalizationRequest可以在图18的1850中包括指示第二SSP将包状态配置为“转换中”状态的信息。
-finalizationRequest可以可选地在图18的1870中包括其中第二SSP将包状态配置为“转换中”状态的时间或者其中生成证明的时间。替代地，finalizationRequest可以包括关于用于签名的证书(用于稍后描述的电子签名)的信息，以及关于与其相关的证书链的信息。
-finalizationRequest可以在图18的1890中包括第二SSP的签名信息。签名可以是通过用第二SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图22，在步骤30020中，第二SSP 3060可以向第一SSP 3010传输finalizationRequest。例如，第二SSP 3060可以通过以下过程将finalizationRequest传输到第一SSP 3010。也就是说，第二SSP 3060可以响应于步骤30010将finalizationRequest传输到第二LBA 3070，并且第二LBA 3070可以经由第一LBA 3020将finalizationRequest传输到第一SSP 3010。
参考图30，在步骤30025中，第一SSP 3010可以验证接收到的finalizationRequest。验证过程可以包括检查包含在finalizationRequest中的第二SSP的签名的有效性的步骤。此外，验证过程还可以包括检查包含在finalizationRequest中的“包定界符”是否与对应包的包定界符相匹配的过程。此外，验证过程还可以包括检查包含在finalizationRequest中的“SSP标识符”是否是第二SSP的有效标识符的过程。此外，验证过程还可以包括识别包含在finalizationRequest中的指令信息是否是将包状态改变为“转换中”状态的指令信息的过程。
此外，在步骤30025中，在验证完成之后，第一SSP 3010可以将包状态配置为“转换中”。“转换中”可以表示包已经成功安装但不可用的状态(此外，仅通过诸如“来自第二终端3050的请求”和/或“来自外部服务器的请求”的额外操作而可以改变为可用状态(禁用、启用、活动状态)的状态)。
此外，在步骤30025中，第一SSP 3010可以生成“证明”。在图30中，该证明可以被称为finalizationResponse。证明的结构可以遵循图18中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-finalizationResponse可以在图18的510中包括对应包的“包定界符”。替代地，finalizationResponse可以包括在先前步骤中接收的finalizationRequest的部分和/或全部数据。
-finalizationResponse可以在图18的530中包括第一SSP的“SSP标识符”。
-finalizationResponse可以在图18的1850中包括指示第一SSP将包状态配置为“转换中”状态的信息。
-finalizationResponse可以可选地在图18的1870中包括其中第一SSP将包状态配置为“转换中”状态的时间或者其中生成证明的时间。替代地，finalizationResponse可以包括关于用于签名的证书(用于稍后描述的电子签名的)的信息，以及关于与其相关的证书链的信息。
-finalizationResponse可以在图18的1890中包括第一SSP的签名信息。签名可以是通过用第一SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图30，在步骤30030中，第一SSP 3010可以将finalizationResponse传输给第二SSP 3060。例如，第一SSP 3010可以经由第一LBA 3020和第二LBA 3070将finalizationResponse传输给第二SSP 3060。
参考图30，在步骤30035中，第二SSP 3060可以验证接收到的finalizationResponse。验证过程可以包括检查包含在finalizationResponse中的第一SSP的签名的有效性的步骤。此外，验证过程可以可选地进一步包括检查包含在finalizationResponse中的“包定界符”是否与对应包的包定界符相匹配的过程。此外，验证过程可以包括检查包含在finalizationResponse中的finalizationRequest的部分或全部数据是否与其自身已经发送的信息相匹配的过程。此外，验证过程还可以包括识别包含在finalizationResponse中的“SSP标识符”的过程。此外，验证过程还可以包括识别包含在finalizationResponse中的指令信息是否是将包状态配置为“转换中”的指令信息的过程。
参考图30，可以在步骤30040中执行预先通知过程。当在“注册配置”中配置需要预先通知时，可以应用该过程。当执行预先通知过程时，过程可以如下。
首先，第二SSP 3060可以生成sspInfoSelected并将该信息发送到第二LBA 3070。如果需要，可以省略该过程。在这种情况下，sspInfoSelected的描述参考图26的描述。此后，参考图27描述的过程当中的在步骤27055的“将包状态改变为可用状态之一(禁用、启用和活动之一)的过程”之前的过程可以被执行。
参考图30，在步骤30045中，第二SSP 3060可以将包状态改变为可用状态之一(禁用、启用和活动之一)。例如，如图所示，第二SSP 3060可以将包状态改变为禁用状态。
此外，在步骤30045中，第二SSP 3060可以生成“证明”。在图30中，证明可以被称为spblAttestation。证明的结构可以遵循图18中公开的结构。
在这种情况下，可能的证明配置的一个示例如下。
-spblAttestation可以在图18的510中包括对应包的“包定界符”。替代地，spblAttestation可以包括“finalizationRequest、finalizationResponse和/或spbmAttestation”的部分和/或全部数据。
-spblAttestation可以在图18的530中包括第二SSP的“SSP标识符”。
-spblAttestation可以在图18的1850中包括指示第二SSP已经将包状态改变为可用状态之一的信息。
-spblAttestation可以可选地在图18的1870中包括其中第二SSP将包状态改变为可用状态之一的时间或者其中生成证明的时间。替代地，spblAttestation可以包括关于用于签名的证书(用于稍后描述的电子签名)的信息，以及关于与其相关的证书链的信息。
-spblAttestation可以在图18的1890中包括第二SSP的签名信息。签名可以是通过用第二SSP的签名证书对上述信息进行数字签名而获得的签名信息。
参考图30，在步骤30050中，可以执行后通知过程。当在“注册配置”中配置为不需要预先通知时，可以应用该过程。当执行后通知过程时，过程可能如下。
a.当在“注册配置”中配置了需要加密通知内容时
首先，第二SSP 3060可以生成sspInfoSelected并将该信息发送到第二LBA 3070。如果需要，可以省略该过程。在这种情况下，sspInfoSelected的描述参考图22的描述。此后，可以执行图23中描述的过程。
b.当在“注册配置”中配置了不需要加密通知内容时
首先，第二SSP 3060可以向第二LBA 3070发送spblAttestation。此后，可以执行参考图25描述的过程。
参考图30，在步骤30055中，第二SSP 3060可以经由第二LBA 3070和第一LBA 3020向第一SSP 3010发送spblAttestation。
参考图30，在步骤30060中，第一SSP 3010可以验证接收到的spblAttestation。验证过程可以包括检查包含在spblAttestation中的第二SSP的签名的有效性的步骤。此外，验证过程还可包括检查包含在spblAttestation中的“包定界符”是否与对应包的包定界符相匹配的过程。此外，验证过程还可以包括检查包含在spblAttestation中的“SSP标识符”是否是第二SSP的有效标识符的过程。此外，验证过程还可以包括识别包含在spblAttestation中的指令信息是否是将包状态配置为可用状态之一的指令信息的过程。
此外，在步骤30060中，第一SSP 3010可以删除包。
根据需要，可以省略步骤30045和/或步骤30055和/或步骤30060中生成spblAttestation的过程。
当在步骤30040或30050中描述的通知过程没有完成时(例如，当通知被发送到服务器但是没有接收到响应时)，第二终端可以重复地向服务器重发通知。可以执行重传过程，直到根据预先配置的最大重传次数满足最大值，或者可以重复执行重传过程，直到从服务器接收到响应。
根据“注册配置”，需要预先通知，但是当由于过程30040没有正常执行而使得包在第一终端3000和第二终端3050中都不可用时，安装在第一终端3000和/或第二终端3050中的包的状态可以通过参考图29描述的服务器的请求从“转换中”改变为可用状态之一(例如，禁用状态)。
在上述本公开的具体实施例中，根据所呈现的具体实施例，本公开中包括的组件以单数或复数表示。然而，对于为了描述方便而呈现的情况，适当地选择单数或复数表达，并且本公开不限于单数或复数组件，并且即使组件以复数表示，也可以用单数来配置，或者即使组件以单数表示，也可以用复数来配置。
尽管在本公开的详细描述中已经描述了具体实施例，但是在不脱离本公开的范围的情况下，各种修改是可能的。因此，本公开的范围不应限于所描述的实施例，而应由下面描述的权利要求以及权利要求的等同物来限定。
本公开的各种实施例和其中使用的术语不旨在将本公开中描述的技术限制于特定实施例，而是应当理解为包括实施例的各种修改、等同物和/或替代物。结合附图的描述，相同的附图标记可以用于相同的组件。单数表达可以包括复数表达，除非上下文另有明确规定。在本公开中，诸如“A或B”、“A和/或B中的至少一个”、“A、B或C”或“A、B和/或C中的至少一个”等表达可以包括一起列出的项目的所有可能组合。诸如“第一”或“第二”的表达可以修饰对应的组件，而不管顺序或重要性，并且仅用于将一个组件与其他组件区分开，而不限制对应的组件。当(例如，第一)组件被称为被“连接(功能上或通信上)”或“访问”到另一个(例如，第二)组件时，该组件可以直接连接到另一个组件或者可以通过另一个组件(例如，第三组件)连接。
本公开中使用的术语“模块”包括用硬件、软件或固件配置的单元，并且可以与诸如逻辑、逻辑块、部件或电路的术语互换使用。模块可以是整体形成的部分或最小单元或执行一个或多个功能的部分。例如，模块可以被配置为专用集成电路(ASIC)。
本公开的各种实施例可以实现为包括存储在机器(例如，计算机)可读存储介质(例如，内部存储器或外部存储器)中的指令的软件(例如，程序)。该机器是能够从存储介质调用存储的指令并根据调用的指令进行操作的设备，并且可以包括根据各种实施例的终端。当处理器执行该命令时，处理器可以直接或使用处理器控制下的其他组件来执行对应于该命令的功能。该命令可以包括由编译器或解释器生成或执行的代码。
机器可读存储介质可以以非暂时性存储介质的形式提供。这里，“非暂时性”意味着存储介质不包括信号并且是有形的，并且不区分数据是半永久地还是临时地存储在存储介质中。
根据本公开中公开的各种实施例的方法可以通过被包括在计算机程序产品中来提供。计算机程序产品可以作为商品在卖方和买方之间交易。计算机程序产品可以以机器可读存储介质(例如，光盘只读存储器(CD-ROM))的形式分发，或者通过应用商店(例如，Play StoreTM)在线分发。在在线分发的情况下，计算机程序产品的至少一部分可以至少临时存储或临时生成在存储介质中，诸如制造商的服务器、应用商店的服务器或中继服务器的存储器。根据各种实施例的每个组件(例如，模块或程序)可以用单个实体或多个实体来配置，并且前述子组件的一些子组件可以被省略，或者其他子组件可以被进一步包括在各种实施例中。替代地或附加地，一些组件(例如，模块或程序)可以被集成到单个实体中，使得在集成之前由每个对应组件执行的功能可以被相同或相似地执行。根据各种实施例，由模块、程序或其他组件执行的操作可以顺序地、并行地、重复地或启发式地执行，或者至少一些操作可以以不同的顺序执行、省略，或者可以向其添加其他操作。
Claims (15)
1.一种操作第一终端的方法，所述方法包括:
向第二终端发送包；
从所述第二终端接收所生成的包括关于所述第二终端的包状态信息的第一证明；
验证所接收的第一证明；
在验证所述第一证明之后，生成包括关于所述第一终端的包状态信息的第二证明；和
向所述第二终端发送所述第二证明。
2.根据权利要求1所述的方法，其中关于所述第一终端的包状态信息包括所述第一终端的包状态被配置为删除、转换中和暂停中的至少一个，以及
其中所述方法进一步包括:
从所述第二终端接收所生成的第三证明，所述第三证明包括在所述第一终端的包状态被配置为转换中的情况下关于所述第二终端的包状态改变的信息；
验证所接收的第三证明；并且
在验证所述第三证明之后，删除所述第一终端的包。
3.根据权利要求1所述的方法，其中由所述第二终端生成第四证明，所述第四证明包括关于所述第一证明和所述第二证明的验证结果的信息，
所述第四证明被发送到服务器，并且
所述第四证明由所述服务器验证。
4.根据权利要求1所述的方法，由所述服务器生成第五证明，所述第五证明包括与服务器的认证结果；
所述第五证明被发送到所述第二终端，并且
所述第五证明由所述第二终端验证。
5.一种操作第二终端的方法，所述方法包括:
从第一终端接收包；
安装所述包；
生成包括关于所述第二终端的包状态信息的第一证明；
向所述第一终端发送所述第一证明；
从所述第一终端接收生成的第二证明，所述第二证明包括关于所述第一终端的包状态信息；
验证所接收的第二证明；并且
在验证所述第二证明之后，改变关于所述第二终端的包状态配置信息。
6.根据权利要求5所述的方法，其中改变关于所述第二终端的包状态配置信息包括将所述第二终端的包状态改变为启用、活动和禁用中的至少一个，并且
关于所述第一终端的包状态信息包括所述第一终端的包状态被配置为删除、转换中和暂停中的至少一个，以及
其中所述方法进一步包括:
生成第三证明，所述第三证明包括在所述第一终端的包状态被配置为转换中的情况下关于所述第二终端的包状态改变的信息；以及
向所述第一终端发送所述第三证明。
7.根据权利要求5所述的方法，进一步包括:
生成第四证明，所述第四证明包括关于所述第一证明和所述第二证明的验证结果的信息；以及
将所述第四证明发送到服务器。
8.根据权利要求5所述的方法，进一步包括:
从服务器接收所生成的第五证明，所述第五证明包括与所述服务器的认证结果；
验证所接收的第五证明；以及
在验证所述第五证明之后，改变关于所述第二终端的包状态配置信息。
9.第一终端，包括:
收发器，被配置为发送和接收至少一个信号；和
耦合到收发器的控制器，
其中所述控制器被配置成:
向第二终端发送包，
从所述第二终端接收所生成的第一证明，所述第一证明包括关于所述第二终端的包状态信息，
验证所接收的第一证明，
在验证所述第一证明之后，生成包括关于所述第一终端的包状态信息的第二证明，以及
向所述第二终端发送所述第二证明。
10.根据权利要求9所述的第一终端，其中，所述控制器还被配置成:
接收所生成的第三证明，所述第三证明包括在所述第一终端的包状态被配置为转换中的情况下关于来自所述第二终端的所述第二终端的包状态改变的信息，
验证所接收的第三证明，以及
在验证所述第三证明之后删除所述第一终端的包，
其中关于所述第一终端的包状态信息包括所述第一终端的包状态被配置为删除、转换中和暂停中的至少一个。
11.根据权利要求9所述的第一终端，其中，由所述第二终端生成第四证明，所述第四证明包括关于所述第一证明和所述第二证明的验证结果的信息；
所述第四证明被发送到服务器，并且
所述第四证明由所述服务器验证。
12.根据权利要求9所述的第一终端，其中由所述服务器生成第五证明，所述第五证明包括与服务器的认证结果；
所述第五证明被发送到所述第二终端，并且
所述第五证明由所述第二终端验证。
13.第二终端，包括:
收发器，被配置为发送和接收至少一个信号；和
耦合到收发器的控制器，
其中所述控制器被配置成:
从第一终端接收包，
安装所述包，
生成包括关于所述第二终端的包状态信息的第一证明，
向所述第一终端发送所述第一证明，
从所述第一终端接收所生成的第二证明，所述第二证明包括关于所述第一终端的包状态信息，
验证所接收的第二证明，以及
在验证所述第二证明之后，改变关于所述第二终端的包状态配置信息。
14.根据权利要求13所述的第二终端，其中，所述控制器还被配置为:
将所述第二终端的包状态改变为启用、活动和禁用中的至少一个，
生成第三证明，所述第三证明包括在所述第一终端的包状态被配置为转换中的情况下关于所述第二终端的包状态改变的信息，以及
向所述第一终端发送所述第三证明，以及
其中关于所述第一终端的包状态信息包括所述第一终端的包状态被配置为删除、转换中和暂停中的至少一个。
15.根据权利要求13所述的第二终端，其中，所述控制器还被配置为:
生成第四证明，所述第四证明包括关于所述第一证明和所述第二证明的验证结果的信息，以及
将所述第四证明发送到服务器。
Applications Claiming Priority (11)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR10-2019-0116222 | 2019-09-20 | ||
| KR20190116222 | 2019-09-20 | ||
| KR20190140219 | 2019-11-05 | ||
| KR10-2019-0140219 | 2019-11-05 | ||
| KR10-2019-0150329 | 2019-11-21 | ||
| KR10-2019-0150466 | 2019-11-21 | ||
| KR20190150466 | 2019-11-21 | ||
| KR20190150329 | 2019-11-21 | ||
| KR1020200120292A KR20210034522A (ko) | 2019-09-20 | 2020-09-18 | 기기 간 번들 이동 후 번들의 상태를 설정하는 방법 및 장치 |
| KR10-2020-0120292 | 2020-09-18 | ||
| PCT/KR2020/012728 WO2021054808A1 (ko) | 2019-09-20 | 2020-09-21 | 기기 간 번들 이동 후 번들의 상태를 설정하는 방법 및 장치 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114731505A true CN114731505A (zh) | 2022-07-08 |
Family
ID=74883499
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202080080987.6A Pending CN114731505A (zh) | 2019-09-20 | 2020-09-21 | 用于在装置之间的包传输后设置包的状态的方法和设备 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US20220385670A1 (zh) |
| EP (1) | EP4017047A4 (zh) |
| JP (1) | JP2022549182A (zh) |
| CN (1) | CN114731505A (zh) |
| WO (1) | WO2021054808A1 (zh) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2741466A1 (fr) * | 2012-12-10 | 2014-06-11 | Oberthur Technologies | Procédé et système de gestion d'un élément sécurisé intégré eSE |
| CN105339894A (zh) * | 2013-07-01 | 2016-02-17 | 三星电子株式会社 | 电子设备及更新和管理电子设备中应用状态信息的方法 |
| US20190075453A1 (en) * | 2017-09-07 | 2019-03-07 | Samsung Electronics Co., Ltd | Method and apparatus for supporting transfer of profile between devices in wireless communication system |
| CN110024426A (zh) * | 2017-02-13 | 2019-07-16 | 三星电子株式会社 | 通过eSIM进行访问控制的装置及方法 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2013048084A2 (ko) * | 2011-09-28 | 2013-04-04 | 주식회사 케이티 | 프로파일 관리 방법, 내장 ｕｉｃｃ 및 내장 ｕｉｃｃ 탑재 기기 |
| KR102329824B1 (ko) * | 2014-09-16 | 2021-11-23 | 삼성전자주식회사 | 네트워크 서비스를 제공하는 방법과 전자 장치 |
-
2020
- 2020-09-21 CN CN202080080987.6A patent/CN114731505A/zh active Pending
- 2020-09-21 JP JP2022517517A patent/JP2022549182A/ja active Pending
- 2020-09-21 US US17/762,047 patent/US20220385670A1/en active Pending
- 2020-09-21 EP EP20865704.9A patent/EP4017047A4/en active Pending
- 2020-09-21 WO PCT/KR2020/012728 patent/WO2021054808A1/ko unknown
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2741466A1 (fr) * | 2012-12-10 | 2014-06-11 | Oberthur Technologies | Procédé et système de gestion d'un élément sécurisé intégré eSE |
| CN105339894A (zh) * | 2013-07-01 | 2016-02-17 | 三星电子株式会社 | 电子设备及更新和管理电子设备中应用状态信息的方法 |
| CN110024426A (zh) * | 2017-02-13 | 2019-07-16 | 三星电子株式会社 | 通过eSIM进行访问控制的装置及方法 |
| US20190075453A1 (en) * | 2017-09-07 | 2019-03-07 | Samsung Electronics Co., Ltd | Method and apparatus for supporting transfer of profile between devices in wireless communication system |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2022549182A (ja) | 2022-11-24 |
| EP4017047A1 (en) | 2022-06-22 |
| EP4017047A4 (en) | 2022-10-19 |
| WO2021054808A1 (ko) | 2021-03-25 |
| US20220385670A1 (en) | 2022-12-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112956155B (zh) | Ssp设备和服务器协商数字证书的装置和方法 | |
| US11206534B2 (en) | Method and apparatus for managing bundles of smart secure platform | |
| CN113785532B (zh) | 用于管理和验证证书的方法和装置 | |
| US20200272446A1 (en) | METHOD FOR INTEROPERATING BETWEEN BUNDLE DOWNLOAD PROCESS AND eSIM PROFILE DOWNLOAD PROCESS BY SSP TERMINAL | |
| 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 | |
| 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 | |
| US20220377081A1 (en) | Mutual device-to-device authentication method and device during device-to-device bundle or profile transfer | |
| US20220278985A1 (en) | Method and device for transferring bundle between devices | |
| KR20210034522A (ko) | 기기 간 번들 이동 후 번들의 상태를 설정하는 방법 및 장치 | |
| KR20210034460A (ko) | 기기 간 번들 또는 프로파일 이동 시 기기 간 상호 인증 방법 및 장치 | |
| KR20210116169A (ko) | 기기 간 번들 또는 프로파일 온라인 이동 방법 및 장치 | |
| KR20210020770A (ko) | 기기 간 번들 이동 방법 및 장치 | |
| KR20210020725A (ko) | 기기 간 번들 이동 방법 및 장치 | |
| CN115997398A (zh) | 用于在设备改变期间移动具有不同版本的简档的方法和设备 | |
| KR20200130044A (ko) | 인증서 관리 및 검증 방법 및 장치 | |
| CN115280815A (zh) | 在设备之间在线移动捆绑包或配置文件的方法和设备 |
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 |