CN116724578A - 用于基于超宽带通信的安全测距的方法和设备 - Google Patents

Abstract

公开了一种用于UWB安全测距的方法。根据本公开的一个实施例的电子设备方法可以包括以下操作：向安全部件发送用于设置用于安全测距的测距数据集的请求；以及向安全部件发送用于将测距数据集传输到UWB子系统的请求。在此，测距数据集可以是通过使用通过框架设置在安全部件与UWB子系统之间的安全信道从安全部件发送到UWB子系统的。

Description

用于基于超宽带通信的安全测距的方法和设备

技术领域

本公开涉及UWB通信，并且更具体地，涉及用于基于UWB的安全测距的方法和设备。

背景技术

互联网正在从人类创建和消费信息的以人为中心的连接网络演变为在事物或其他分布式组件之间进行信息通信和处理的物联网(IoT；Internet of Things)网络。另一项新兴技术是万物互联(IoE；Internet of Everything)，它是例如通过与云服务器的连接的大数据处理技术和物联网技术的结合。实施IoT需要诸如传感技术、有线/无线通信和网络基础设施、服务接口和安全技术的技术要素。最近正在进行的物对物连接研究是关于传感器网络、机器对机器(M2M；machine-to-machine)或机器类型通信(MTC；machine-typecommunication)的技术。

在IoT环境中，可能会提供智能互联网技术(IT；Internet Technology)服务，该服务收集和分析由相互连接的事物所产生的数据，从而为人类生活创造新的价值。通过常规IT(信息技术)技术和各行业的融合或集成，IoT可以有多种应用，诸如智能家居、智能建筑、智能城市、智能汽车或联网汽车、智能电网、医疗保健或智能家电行业或最先进的医疗服务。

随着无线通信系统演进为提供各种服务，需要用于有效地提供此类服务的方法。例如，可以使用测距技术来测量使用超宽带(UWB；ultra-wide band)的电子设备之间的距离。

发明内容

技术问题

本公开提供了一种用于配置用于简单且有效的基于UWB的安全测距的安全部件和框架的方法。本公开提供了一种方法，其中配置的安全部件将用于安全测距的会话密钥安全地传输到UWB子系统。

本公开提供了一种方法，其中连同安全应用程序一起包括在TEE区域中的UWB子系统有效且安全地从安全应用程序获取安全数据。

技术方法

根据本公开的一个方面，一种由电子设备执行安全测距的方法可以包括：通过电子设备的框架，向安全部件发送用于配置用于安全测距的测距数据集的请求；以及通过框架，向安全部件发送用于将测距数据集传输到超宽带UWB子系统的请求。测距数据集是使用通过框架在安全部件与UWB子系统之间建立的安全信道从安全部件传输到UWB子系统的。

根据本公开的另一方面，一种执行安全测距的电子设备可以包括存储器和连接到存储器的处理器。处理器可以被配置为：通过电子设备的框架，向安全部件发送用于配置用于安全测距的测距数据集的请求；以及通过框架，向安全部件发送用于将测距数据集传输到超宽带UWB子系统的请求。测距数据集是使用通过框架在安全部件与UWB子系统之间建立的安全信道从安全部件传输到UWB子系统的。

根据本公开的各种实施例，由UWB设备执行安全测距的方法可以包括：从框架接收由UWB设备的UWB子系统从UWB设备的安全应用程序获取用于安全测距的测距数据集(RDS；ranging data set)的命令；基于命令由UWB子系统与安全应用程序建立安全信道；以及由UWB子系统通过建立的安全信道从安全应用程序接收RDS。UWB子系统和安全应用程序可以包括在可信执行环境(TEE；trusted execution environment)区域中，并且RDS可以包括用于保护UWB测距会话的测距会话密钥。

根据本公开的各种实施例，由UWB设备执行安全测距的方法可以包括：从框架接收用于通过UWB设备的安全应用程序将用于安全测距的测距数据集(RDS；ranging data set)传输到UWB设备的UWB子系统的命令；由安全应用程序基于命令向安全OS发送用于建立安全应用程序的安全操作系统(OS)与UWB子系统之间的安全信道的请求；以及由安全应用程序通过建立的安全信道将RDS传输到UWB子系统。UWB子系统和安全应用程序可以包括在可信执行环境(TEE；trusted execution environment)区域中，并且RDS可以包括用于保护UWB测距会话的测距会话密钥。

在一个实施例中，命令可以包括应用程序的应用程序ID或与由应用程序配置的至少一个会话之一相关联的实例ID中的至少一个。

在一个实施例中，可以为UWB子系统配置用于与TEE区域中的部件通信的第一接口和用于与TEE区域之外的部件通信的第二接口。

在一个实施例中，框架可以包括在TEE区域之外。

在一个实施例中，UWB子系统可以通过使用包括在RDS中的测距会话密钥与另一个UWB设备的UWB子系统执行安全测距。

有益效果

根据本公开的安全部件和框架的配置，可以执行简单且有效的基于UWB的安全测距。根据其中本公开的安全部件将用于安全测距的会话密钥传输到UWB子系统的方法，可以安全地传输会话密钥。

通过根据本公开的实施例的方法，与安全应用程序一起包括在TEE区域中的UWB子系统可以有效且安全地从安全应用程序获取安全数据。

附图说明

图1是示出了支持基于UWB的服务的电子设备的示例性层配置的视图；

图2a是示出了包括支持基于UWB的服务的电子设备的通信系统的示例性配置的视图；

图2b是示出了包括支持基于UWB的支付服务的电子设备的通信系统的示例性配置的视图；

图3是示出了支持基于UWB的服务的电子设备中包括的框架的示例性配置的视图；

图4示出了根据本公开的实施例的使用第一安全部件执行安全测距的通信系统的示例性操作；

图5示出了根据本公开的实施例的使用第一安全部件执行安全测距的电子设备的示例性配置和操作；

图6示出了根据本公开的实施例的使用第二安全部件执行安全测距的电子设备的示例性配置和操作；

图7a示出了根据本公开的实施例的电子设备在第一安全部件与超宽带基站(UWBS)之间建立安全信道的方法；

图7b示出了根据本公开的实施例的电子设备在第二安全部件与超宽带基站(UWBS)之间建立安全信道的方法；

图8为示出了根据本公开的实施例的通过包括第二安全部件的电子设备提供RDS的方法的流程图；

图9a示出了根据本公开的实施例的用于使用对称加密方法建立UWBS与安全部件之间的安全信道的过程；

图9b示出了根据本公开的实施例的使用非对称加密方法建立UWBS与安全部件之间的安全信道的示例性过程；

图9c示出了根据本公开的实施例的使用非对称方法建立UWBS与安全部件之间的安全信道的另一示例性过程；

图9d示出了根据本公开的实施例的UWBS通过UWBS与安全部件之间的安全信道将RDS传输到安全部件的过程；

图10a示出了根据本公开的实施例的用于包括第一安全部件的电子设备的密钥供应方法；

图10b示出了根据本公开的实施例的用于包括第二安全部件的电子设备的密钥供应方法；

图11示出了根据本公开的实施例的用于为包括第二安全部件的电子设备提供密钥的认证过程；

图12示出了根据本公开的实施例的电子设备的示例性配置；

图13是示出了根据本公开的实施例的由电子设备实现的方法的流程图；

图14是示出了根据本公开的实施例的第一电子设备的结构的视图；

图15是示出了根据本公开的实施例的第二电子设备的结构的视图；

图16示出了包括SE的UWB设备的示例性配置；

图17示出了包括SE的UWB设备的操作；

图18是示出了根据本公开的实施例的包括TEE的UWB设备的示例性配置的视图；

图19示出了根据本公开的实施例的包括TEE的UWB设备的操作；

图20示出了根据本公开的实施例的包括TEE和SE的UWB设备的操作；

图21示出了根据本公开的实施例的其中第一UWB设备执行与第二UWB设备的安全测距的方法；

图22示出了根据本公开的另一实施例的包括TEE的UWB设备的操作；

图23示出了根据本公开的另一实施例的其中第一UWB设备执行与第二UWB设备的安全测距的方法；

图24示出了根据本公开的实施例的UWB设备的配置；

图25是示出了根据本公开的实施例的UWB设备的方法的流程图；

图26是示出了根据本公开的另一实施例的UWB设备的方法的流程图；以及

图27是示出了根据本公开的实施例的电子设备的结构的视图。

具体实施方式

在下文，参考附图详细描述本公开的实施例。

在描述实施例时，省略对本领域技术人员已知并且与本发明不直接相关的技术的描述。这是为了进一步阐明本公开的主旨而不使其变得不清楚。

出于同样的原因，一些元件可能被夸大或示意性地示出。每个元件的大小并不一定反映元件的真实大小。在所有附图中，相同的参考标号始终用于表示相同的元件。

通过下面结合附图所描述的实施例，可以理解本发明的优点和特征以及用于实现这些优点和特征的方法。然而，本发明不限于本文公开的实施例，并且可以对其进行其各种改变。提供本文所公开的实施例仅用于告知本领域的普通技术人员本公开的范畴。本发明仅由所附权利要求限定。贯穿本说明书，相同的附图标记指示相同的元件。

应当理解，每个流程图中的框和流程图的组合可以由计算机程序指令执行。由于计算机程序指令可以配备在通用计算机、专用计算机或其他可编程数据处理设备的处理器中，因此通过计算机或其他可编程数据处理设备的处理器执行的指令生成用于执行结合每个流程图的框描述的功能的装置。由于计算机程序指令可以存储在可面向计算机或其他可编程数据处理设备的计算机可用或计算机可读存储器中以便以指定方式实施功能，因此存储在计算机可用或计算机可读存储器中的指令可以产生包括用于执行结合每个流程图中的框描述的功能的指令装置的产品。由于计算机程序指令可以配备在计算机或其他可编程数据处理设备中，因此生成随着在计算机或其他可编程数据处理设备上执行一系列操作步骤而由计算机执行的过程并且操作计算机或其他可编程数据处理设备的指令可以提供用于执行结合每个流程图中的框描述的功能的步骤。

此外，每个框可以表示模块、区段或代码的一部分，包括用于执行指定逻辑功能的一个或多个可执行指令。此外，还应当注意的是，在一些替换实施例中，框中提到的功能可以以不同顺序发生。例如，连续示出的两个框可以基本上同时执行或以相反顺序执行，这取决于对应的功能。

如本文所使用，术语“单元”是指软件元件或硬件元件，诸如现场可编程门阵列(FPGA；field-programmable gate array)或专用集成电路(ASIC；application specificintegrated circuit)。单元发挥特定作用。然而，“单元”不限于软件或硬件。“单元”可以配置在可以被寻址的存储介质中或者可以配置成运行一个或多个处理器。因此，作为一个示例，“单元”包括元件，诸如软件元件、面向对象的软件元件、类元件和任务元件、进程、函数、属性、过程、子例程、程序代码段、驱动程序、固件、微码、电路、数据、数据库、数据结构、表、阵列和变量。在部件和“单元”中提供的功能可以组合成更少数量的部件和“单元”，或者还可以分成附加的部件和“单元”。此外，部件和“单元”可以实现为运行设备或安全多媒体卡中的一个或多个CPU。根据本公开的实施例，“…单元”可以包括一个或多个处理器。

如本文所用，术语“终端”或“设备”也可称为移动台(MS；mobile station)、用户设备(UE；user equipment)、用户终端(UT；user terminal)、终端、无线终端、接入终端(AT；access terminal)、订户单元、订户站(SS；subscriber station)、无线设备、无线通信设备、无线发射/接收单元(WTRU；wireless transmit/receive unit)、移动节点或移动装置或者可以用其他术语来指代。终端的各种实施例可以包括蜂窝电话、具有无线通信能力的智能电话、具有无线通信能力的个人数字助理(PDA；personal digital assistant)、无线调制解调器、具有无线通信能力的便携式计算机、捕获/记录/拍摄/摄影设备，诸如具有无线通信能力的数码相机、具有无线通信能力的游戏机、具有无线通信能力的音乐存储和播放家用电器、能够无线上网和浏览互联网的互联网家用电器或者合并有这些能力的组合的便携式单元或终端。此外，终端可以包括机器到机器(M2M；machine to machine)终端和机器类型通信(MTC；machine-type communication)终端/设备，但不限于此。在本公开中，终端可以称为电子设备或仅称为设备。

在下文中，以下参考附图来描述本公开的操作原理。当确定使本公开的主题不必要地不清楚时，在描述本公开的实施例时可以跳过已知功能或配置的详细描述。本文中使用的术语在考虑本公开中的功能的情况下进行定义，并且根据用户或运营商的意图或实践可以用其他术语来替换。因此，应基于整体公开来定义术语。

在下文中，参考附图详细描述本发明的实施例。进一步地，虽然结合本发明的实施例描述了使用UWB的通信系统(例如，由FiRa联盟规定的UWB通信系统)，但是作为示例，本发明的实施例也可以应用于具有类似技术背景或特征的其他通信系统。例如，其中可以包括使用蓝牙或ZigBee的通信系统。此外，在本领域的普通技术人员确定的情况下，可以在不显著背离本发明的范围的情况下对本发明的实施例进行修改，并且这种修改可以适用于其他通信系统。

当确定使本公开的主题不清楚时，可以跳过已知领域或功能的详细描述。本文中使用的术语在考虑本公开中的功能的情况下进行定义，并且根据用户或运营商的意图或实践可以用其他术语来替换。因此，应基于整体公开来定义术语。

一般而言，无线传感器网络技术根据识别距离主要划分成无线局域网(WLAN；wireless local area network)技术和无线个人局域网(WPAN；wireless personal areanetwork)技术。在这种情况下，WLAN是基于IEEE 802.11的技术，其使得能够在大约100m的半径范围内访问骨干网络。WPAN是基于IEEE 802.15的技术，包括蓝牙、ZigBee和超宽带(UWB；ultra-wide band)。在其中实现这种无线网络技术的无线网络可以包括多个通信电子设备。

根据联邦通信委员会(FCC；Federal Communications Commission)的定义，UWB可以是指使用500MHz以上的带宽或者与20％以上的中心频率相对应的带宽的无线通信技术。UWB可以表示应用了UWB通信的频带本身。UWB可以在设备之间实现安全且准确的测距。

基于UWB的服务的操作可以包括用于启动基于UWB的服务的服务启动步骤、用于提供安全密钥的密钥供应步骤、用于发现设备的发现步骤、包括安全信道创建和参数交换的连接步骤和/或用于测量设备之间的位置/距离的UWB测距步骤。

另外，根据一个实施例，可以省略一些步骤。例如，在一个实施例中，服务启动步骤和UWB测距步骤可以是强制性步骤，而密钥供应步骤、发现步骤和连接步骤可以是可选步骤。作为另一示例，在另一个实施例中，服务启动步骤、密钥供应步骤和UWB测距步骤可以是强制性步骤，但是发现步骤和连接步骤可以是可选步骤。

此处使用的术语是为了更好地理解本公开而提供的，并且在不脱离本公开的技术精神的情况下可以对其进行改变。

“应用程序专用文件(ADF；Application dedicated file)”可以是例如可以托管应用程序或应用程序特定数据的数据结构。

“应用程序协议数据单元(APDU；Application protocol data unit)”可以是在与安全元件(SE；secure element)(例如，嵌入式SE)或应用程序数据结构通信时使用的命令和响应。

“应用程序特定数据”可以是例如小程序、专有小程序或测距设备内的等效实现。

“控制器”可以是定义和控制测距控制消息(RCM；ranging control message)的测距设备。在本公开中，测距设备可以是例如如在IEEE Std802.15.4z标准中定义的增强型测距设备(ERDEV；enhanced ranging device)。

“受控者”可以是使用从控制器接收的RCM中的测距参数的测距设备。

“动态STS”可以是其中STS是机密的并且在测距会话期间从不重复的操作模式。在这种模式下，STS可以由安全部件管理。

“小程序”可以是实现在安全部件上运行的APDU接口的小程序并且由明确定义的应用程序(小程序)ID(AID)识别。此小程序可以托管安全测距所需的数据。在一个实施例中，小程序可以是例如如在FIRA联盟公共服务和管理层(CSML；COMMON SERVICE&MANAGEMENT LAYER)规范中定义的FiRa小程序。

“测距设备”是可以使用预定义的配置文件(例如，与用于启用UWB的门锁服务的UWB和OOB相关的配置参数集)与另一个测距设备通信的测距设备或者能够支持预定义的UWB测距服务以便执行与另一个测距设备的测距会话的测距设备。在本公开中，测距设备可以称为UWB设备或UWB测距设备。在一个实施例中，测距设备可以是例如如在FIRA联盟CSML规范中定义的FiRa设备。

“测距数据集(RDS；Ranging data set)”可以是建立UWB会话所需的数据，其机密性、真实性和完整性需要得到保护。作为一个实施例，RDS可以包括UWB会话密钥。作为一个实施例，RDS可以用于安全测距。例如，RDS可以用于生成用于安全测距的STS。

“UWB启用应用程序”可以是使用框架API针对UWB会话配置OOB连接器、安全服务和/或UWB服务的应用程序。在本公开中，“UWB启用应用程序”可以缩写为应用程序。在一个实施例中，UWB启用应用程序可以是例如如在FIRA联盟CSML规范中定义的FiRa启用应用程序。

“框架”可以是例如逻辑软件部件的集合，包括OOB连接器、安全服务和/或UWB服务。在一个实施例中，框架可以是例如在FIRA联盟CSML规范中定义的FiRa框架。

“OOB连接器”可以是用于在测距设备之间建立带外(OOB；out-of-band)通信(例如，BLE通信)的软件部件。在一个实施例中，OOB连接器可以是例如如在FIRA联盟CSML规范中定义的FiRa OOB连接器。

“配置文件(Priofile)”可以是先前定义的UWB和OOB配置参数集。在一个实施例中，配置文件可以是例如如在FIRA联盟CSML规范中定义的FiRa配置文件。

“配置文件管理器(Profile manager)”可以实现测距设备上可用的配置文件。在一个实施例中，配置文件管理器可以是例如如FIRA联盟CSML规范中定义的FiRa配置文件管理器。

“智能测距设备”可以是能够托管一个或多个UWB启用应用程序并实现框架的测距设备(例如，物理访问读取器)，或者是实现由制造商提供的特定屏幕应用程序的测距设备。智能测距设备可以是能够安装多个UWB启用应用程序以支持基于UWB测距的服务从而执行与另一测距设备或智能测距设备的测距会话的测距设备。在一个实施例中，智能测距设备可以是例如如在FIRA联盟CSML规范中定义的FiRa智能设备。

“全局专用配置文件(GDF；Global Dedicated File)”可以是包括建立USB会话所需的数据的应用程序特定数据的根级。应用程序特定数据可以是例如小程序、专有小程序或测距设备内的等效实现。

“框架API”可以是由UWB启用应用程序用来与框架通信的API。

“发起者”可以是发起测距交换的测距设备。

“对象标识符(OID；Object identifier)”可以是应用程序数据结构中的ADF的标识符或者用于标识服务提供商SP的唯一ID。

“带外(OOB；Out-of-band)”可以是不使用UWB作为底层无线技术的数据通信。

“响应者”可以是在测距交换中响应发起者的测距设备。

“加扰时间戳序列(STS；Scrambled timestamp sequence)”可以是用于增加测距测量时间戳的完整性和准确性的加密序列。

“安全信道”可以是防止偷听和篡改的数据信道。

“安全部件”可以是为了例如当使用动态STS时向UWBS提供RDS而与UWBS接口连接的部件。它还可以托管UWB启用应用程序数据。

“安全元件(SE；Secure element)”可以是可以用作测距设备中的安全部件的防篡改安全硬件部件。

“安全服务”可以是用于与诸如可信执行环境(TEE；trusted executionenvironment)或安全元件的系统的安全部件接口连接的部件。

“静态STS”是其中STS在会话期间被重复并且不需要由安全部件管理的操作模式。

“SUS小程序”可以是安全部件上的小程序，其作为安全部件(诸如UWBS和SE)之间的安全信道的端点来操作。

“UWB服务”可以是提供对UWBS的访问的特定于实现的软件部件。

当控制者和受控者可以开始UWB测距时，可以认为“UWB会话”已建立。UWB会话可以是从控制者和受控者通过UWB开始通信到通信停止的时间段。UWB会话可以包括测距、数据传输或测距和数据传输两者。

“UWB会话ID”可以是用于标识UWB会话的ID(例如，整数)。

“UWB会话密钥”可以是用于保护UWB会话的密钥。在本公开中，UWB会话密钥可以是UWB测距会话密钥(URSK；UWB ranging session key)，并且可以表示为会话密钥。

“UWB子系统(UWBS)”可以是实现UWB PHY和MAC规范的硬件部件。UWBS可以具有通往其中已实现有UCI逻辑接口层的FiRa框架的接口，以及用于搜索RDS的安全部件的接口。在一个实施例中，UWB PHY和MAC规范可以是例如FiRa联盟PHY和MAC规范。

当确定使本发明的主题不必要地不清楚时，可以在描述本公开时跳过对相关已知功能或特征的详细描述。

在下文中，参考附图描述本公开的各种实施例。

图1是示出了支持基于UWB的服务的电子设备的示例性层配置的视图。

图1的电子设备(UWB设备)100可以是例如智能测距设备或测距设备。作为一个实施例，智能测距设备或测距设备可以是IEEE 802.15.4z中定义的增强型测距设备(ERDEV；enhanced ranging device)或由FiRa联盟定义的FiRa设备。在图1中，电子设备可以称为UWB设备。

在图1的实施例中，UWB设备100可以通过UWB会话与其他UWB设备交互。

参考图1，电子设备100可以包括UWB启用应用程序层(UWB启用应用程序)110、公共服务和管理层(框架)120、和/或包括UWB MAC层和UWB物理层的UWB子系统(UWBS)130。根据实施例，一些实体可以不包括在电子设备中，或者可以进一步包括附加的实体(例如，安全层)。

电子设备100可以实现作为UWB启用应用程序110与框架120之间的接口的第一接口(接口(IF)#1)，并且第一接口允许电子设备100上的UWB启用应用程序110以预定方式使用电子设备100的UWB能力。在一个实施例中，第一接口例如可以是框架API，但不限于此。

电子设备100可以实现作为框架110与UWBS 130之间的接口的第二接口(接口(IF)#2)。在一个实施例中，第二接口可以是例如UWB命令接口(UCI；UWB CommandInterface)，但不限于此。

UWB启用应用程序层110可以是使用第一接口(例如，框架API)以构成例如用于UWB会话的OOB连接器、安全服务和UWB服务的应用程序(例如，FiRa启用应用程序)的层。

UWB启用应用程序110可以触发UWBS 130通过第一接口建立UWB会话。UWB启用应用程序110可以使用先前定义的配置文件(配置文件)之一。例如，UWB启用应用程序110可以使用FiRa中定义的配置文件之一或自定义配置文件。UWB启用应用程序110可以使用第一接口来处理相关事件，诸如服务发现、测距通知和/或错误状况。

公共服务和管理层(框架)120可以定义实现例如UWB安全测距所必需的公共部件和过程。

框架120可以提供对配置文件、单独的UWB配置和/或通知的访问。框架120可以支持UWB测距和交易执行的功能、向应用程序和UWBS 130提供接口的功能、或者估计设备100的位置的功能中的至少一个。框架120可以是软件部件集合。如上所述，UWB启用应用程序110可以通过第一接口与框架120接口连接，并且框架120可以通过第二接口与UWBS 130接口连接。

另外，在本公开中，UWB启用应用程序110和/或框架120可以由应用程序处理器(AP)(或处理器)实现。因此，在本公开中，UWB启用应用程序110和/或框架120的操作可以被理解为由AP(或处理器)执行。

UWB MAC层和UWB物理层可以统称为UWB子系统(UWBS)130。UWBS 130可以基于参考例如IEEE 802.15.4z规范的FiRa PHY和MAC规范。

UWBS 130可以是包括UWB MAC层和UWB物理层的硬件部件。UWBS 130可以执行UWB会话管理并且可以与另一个UWB设备的UWBS通信。UWBS 130可以通过第二接口与框架120接口连接并且可以从安全部件获得安全数据。在一个实施例中，框架(或应用程序处理器)120可以通过UCI向UWBS 130发送命令，并且UWBS 130可以向框架120发送对该命令的响应。UWBS 130可以通过UCI向框架120传输通知。

图2a是示出了包括支持基于UWB的服务的电子设备的通信系统的示例性配置的视图。

参考图2a，通信系统200包括第一电子设备210a和第二电子设备220a。

在一个实施例中，第一UWB设备210a和第二UWB设备220a可以是例如图1的UWB设备或包括图1的UWB设备的电子设备。例如，第一电子设备(第一UWB设备)210a例如可以是智能测距设备或测距设备，并且第二电子设备(第二UWB设备)220a例如可以是测距设备或测距设备。作为一个实施例，智能测距设备或测距设备可以是IEEE 802.15.4z中定义的增强型测距设备(ERDEV)或由FiRa联盟定义的FiRa设备。在图2a中，第一电子设备可以称为第一UWB设备，而第二电子设备可以称为第二UWB设备。

第一电子设备210a可以托管例如一个或多个UWB启用应用程序，这些应用程序可以由用户(例如，移动电话)安装。它可以基于框架API。第二电子设备220a不提供框架API，并且例如可以使用专有接口来实现仅由制造商提供的特定UWB启用应用程序。与所示的不同，根据一个实施例，第一UWB设备和第二UWB设备都可以是使用框架API的测距设备，或者第一UWB设备和第二UWB设备都可以是使用专有接口的测距设备。

第一电子设备210a和第二电子设备220a可以各自包括UWB启用应用程序层(UWB启用应用程序)211a和221a、框架212a和222a、OOB部件(OOB子系统)213a和223a、安全部件214a和224a和/或UWBS 215a和225a。根据一个实施例，可以省略一些部件，并且可以进一步包括附加部件。

第一电子设备210a和第二电子设备220a可以通过OOB连接器213a和223a生成OOB连接(信道)并且通过UWBS 215a和225a生成UWB连接(信道)并且彼此通信。

框架212a和222a可以用于提供对配置文件、单独的UWB设置和/或通知的访问。框架212a和222a可以是软件部件集合，并且可以包括例如配置文件管理器、OOB连接器、安全服务和/或UWB服务。

OOB部件213a和223a可以是包括用于OOB通信(例如，BLE通信)的MAC层和/或物理层的硬件部件。OOB部件213a和223a可以与其他设备的OOB部件通信。在一个实施例中，第一UWB设备210a和第二UWB设备220a可以使用OOB部件213a和223a创建OOB连接(信道)并且通过OOB信道交换用于建立UWB会话的参数。在本公开中，OOB部件213a和223a可以称为OOB子系统。

安全部件214a和224a可以是与框架和/或UWBS接口连接以提供RDS的硬件部件。作为一个实施例，安全部件214a和224a可以是SE(例如，eSE)、TEE(或TEE内的可信应用程序(TA；trusted application))或保险箱(SB；strongbox)。

UWBS 215a和225a可以是包括UWB MAC层和UWB物理层的硬件部件。UWBS 215a和225a可以执行UWB会话管理并且可以与另一个UWB设备的UWBS通信。在一个实施例中，第一UWB设备210a和第二UWB设备220a可以使用交换的参数经由通过UWBS 215a和225a建立的UWB会话来执行服务数据的事务和UWB测距。

在本公开中，UWB启用应用程序层和/或框架可以由应用程序处理器(AP；application processor)(或处理器)来实现。因此，在本公开中，可以理解，UWB启用应用程序层和/或框架的操作是由AP(或处理器)执行的。

图2b是示出了包括支持基于UWB的支付服务的电子设备的通信系统的示例性配置的视图。

图2b的实施例可以是图2a的实施例的示例。

参考图2b，提供基于UWB的支付服务的通信系统200b可以包括第一电子设备(第一UWB设备)210b和第二电子设备(第二UWB设备)220b。在图2b中，第一电子设备可以称为第一UWB设备，而第二电子设备可以称为第二UWB设备。

第一电子设备210b可以是用于基于UWB的支付服务的用户的电子设备(例如，用户的移动设备)。第一电子设备210b可以包括至少一个UWB启用钱包应用程序(UWB启用应用程序)211b-1和211b-2、UWB启用钱包框架(框架)212b、OOB部件213b、至少一个安全部件214b-1和214b-2和/或UWBS 215b。每个部件的描述可以参考图2a的描述。

另外，在图2b的实施例中，为了描述的方便，描述了UWB启用应用程序对应于UWB启用钱包应用程序，并且框架对应于UWB启用钱包框架，但实施例不限于此，并且可以实现用于提供各种类型的其他服务的各种UWB启用应用程序和框架。在图2b中，UWB启用钱包应用程序可以称为UWB启用应用程序，并且UWB启用钱包框架可以称为框架。

UWB启用应用程序211b-1和211b-2可以支持以下特征中的至少一个。

-在SE(例如eSE)中托管基于UWB支付的小程序或者在TEE中托管基于UWB支付的可信支付(可信支付应用程序)

-如果由框架请求，提供关于用于估计第一电子设备的位置的锚点的布置信息和UWB块结构(例如，测距块结构)

-与第二电子设备和后端服务器通信以便实现支付小程序或可信支付应用程序(TPA)的个性化

框架212b可以支持以下特征中的至少一个。

-估计第一电子设备的位置

-实现UCI命令

-提供UWB启用应用程序用来访问UWBS和OOB部件的API集合

OOB部件213b可以支持以下特征。

-实现OOB连接操作(例如，BLE连接操作)

可信支付应用程序211b-2可以包括在TEE中并且可以支持以下特征中的至少一个。

-支持TEE客户端API

-实现可信应用程序

-实现安全信道协议以便以安全方式与第二电子设备通信

-托管用于安全信道的支付凭证和加密密钥

-托管支持基于UWB的支付服务的重要信息(例如，卡信息)

支付小程序211b-1可以包括在SE中并且可以支持以下特征中的至少一个。

-支持APDU

-实现安全信道协议以便以安全方式与第二电子设备通信

-托管用于安全信道的支付凭证和加密密钥

-托管支持基于UWB的支付服务的重要信息(例如，卡信息)

第一电子设备210b的每个部件可以通过预定义的接口IF与另一个部件通信。在下文中，对每个接口进行描述。

接口#1：第一电子设备210b的UWBS 215b与另一电子设备的UWBS(例如，第二电子设备220b的UWBS 223b)之间的接口。接口#1可以用于交换UWB消息和/或支付事务。

接口#2：第一电子设备210b的OOB部件213b与另一电子设备的OOB部件(例如，第二电子设备220b的OOB部件222b)之间的接口。接口#2可以用于交换OOB消息。

接口#3：框架212b与UWBS 215b之间的接口。接口#3可以用于交换UCI消息。例如，接口#3可以用于交换UCI消息以便在可信支付应用程序211b-2与UWBS 215b之间建立安全信道。

接口#4：UWB启用应用程序211b-2与TEE中的可信支付应用程序211b-2之间的接口。接口#4可以用于通过TEE客户端API交换TEE命令。例如，接口#4可以用于交换TEE命令以便在可信支付应用程序211b-2与UWBS 215b之间建立安全信道。

接口#A：UWB启用应用程序211b-1和211b-2与UWBS 215b之间的接口。接口#A可以是例如SUS外部API。

接口#B：UWB启用应用程序211b-2与SE(eSE)中的支付小程序214b-1之间的接口。接口#B可以用于通过OMAPI交换APDU。例如，接口#B可以用于交换APDU以便在eSE与UWBS之间建立安全信道。

接口#C：OOB部件213b与框架212b或UWB启用应用程序211b-1和211b-2之间的接口。

接口#D：UWB启用应用程序211b-1和211b-2与框架212b之间的接口。接口#D可以是由框架212b提供的框架API(API)。

第二电子设备220b可以是用于基于UWB的支付服务的运营商的电子设备(例如，零售服务点(PoS；point of service)终端)。第二电子设备220b可以包括终端应用程序221b、OOB部件222b和/或UWBS 223b。作为一个实施例，终端应用程序221b可以是UWB启用应用程序。

图3是示出了支持基于UWB的服务的电子设备中包括的框架的示例性配置的视图。

图3的框架300可以是图2a和图2b的框架的示例。图3的框架300可以是如FIRA联盟中定义的FiRa框架。

框架300可以是逻辑软件部件的集合。UWB启用应用程序可以通过由框架提供的框架API与框架300交互。

参考图3，框架300可以包括配置文件管理器310、OOB连接器320、安全服务330和/或UWB服务340。根据一个实施例，可以省略一些部件，并且可以进一步包括附加部件。

配置文件管理器310可以管理在测距设备(UWB设备)上可用的配置文件。配置文件可以是在测距设备(UWB设备)之间建立成功的UWB会话所需的参数集。例如，配置文件可以包括指示使用哪个安全信道(例如，OOB安全信道)的参数、UWB/OOB配置参数、指示是否强制使用特定安全部件的参数和/或与ADF的文件结构相关的参数。配置文件管理器310可以从UWB启用应用程序中提取UWB和OOB配置参数。

OOB连接器320可以是用于在测距设备(UWB设备)之间建立OOB连接的部件。OOB连接器320可以处理用于提供基于UWB的服务的发现阶段和连接阶段。

安全服务330可以用于与诸如安全元件(SE)或可信执行环境(TEE)的安全部件接口连接。安全部件可以是与UWBS接口连接以将UWB测距数据传输到UWBS的部件。

UWB服务340可以是提供对UWBS的访问的部件。

如上所述，诸如UWB启用钱包应用程序的UWB启用应用程序可以与框架交互以通过由框架提供的API使用UWBS和OOB。此外，UWB启用应用程序可以与存储凭证、加密密钥和其他敏感信息的至少一个安全部件相关联。例如，UWB启用应用程序可以具有eSE(或eSE中的小程序)(第一安全部件)和/或TEE(或TEE中的可信应用程序(TA))(第二安全部件)作为安全部件。

另外，TEE中的TA可以直接或间接与UWBS交互。

如果UWBS通过中间实体(例如，框架)连接到TA，则UWBS可以间接地与TA通信。这种模式可以称为旁路模式。

如果UWBS物理连接到TEE中的驱动程序TA(安全操作系统)，则UWBS可以直接与TA通信。这种模式可以称为附接模式。在附接模式下，可以理解为UWBS包括在TEE区域中。

<实施例A>

实施例A对应于与上述旁路模式相关的实施例。在下文中，参考图4至图15示例性地描述实施例A。

图4示出了根据本公开的实施例的使用第一安全部件执行安全测距的通信系统的示例性操作。

在图4的实施例中，第一安全部件可以是安全元件(例如，嵌入式SE(eSE))。SE是基于防篡改特征的安全的安全模块，并且如果各个实体之间没有建立契约关系，应用程序的安装和驱动就会受到限制。

eSE是指在电子设备中固定使用的固定SE。eSE通常是应终端制造商的要求专门为制造商制造的，并且可以制造成包括操作系统和框架。对于eSE，可以远程下载并安装小程序形式的服务控制模块，并且用于诸如电子钱包、票务、电子护照或数字钥匙等各种安全服务。

在本公开中，第一安全部件区别于第二安全部件，第二安全部件是诸如TEE(或TEE内的TA)或保险箱(Strongbox)的安全部件。

TEE可以是以S/W为中心的安全环境，其基于例如由特定芯片组(例如，基于ARM)支持的代码来创建虚拟分离环境。TEE具有防篡改特征，但与SE相比具有可用内存大、速度快且成本低等优点。此外，由于在移动制造商允许的范围内可以立即获得各种服务提供商，因此与SE相比，TEE具有实体之间的复杂性较低的优势。

例如，保险箱可以是基于Javacard操作系统的物理安全芯片。类似于TEE，保险箱也相比SE具有实体间复杂度较低的优势。

另外，第二安全部件不限于上述TEE或保险箱，并且可以是与TEE或保险箱具有相同或相似特征的安全部件。

如下所述，当使用第一安全部件并且使用第二安全部件时，在密钥供应过程、用于将用于安全测距的会话密钥传输到UWBS的过程等中存在差异。

参考图4，通信系统400包括第一电子设备410、第二电子设备420和/或服务提供商430。

在图4的实施例中，第一电子设备(第一UWB设备)410和第二电子设备(第二UWB设备)420可以是上文参考图1至图3描述的电子设备之一。例如，第一电子设备(第一UWB设备)410例如可以是智能测距设备，并且第二电子设备(第二UWB设备)420例如可以是测距设备或智能测距设备。

服务提供商430可以是提供UWB启用应用程序并起到提供用于安全测距的密钥的作用的实体。

参考图4，第一电子设备410可以包括属于非安全世界的UWB启用应用程序411、框架412和OOB部件413，并且可以包括属于安全世界的安全元件SE(第一安全部件)和UWBS414。第二电子设备420可以包括应用程序421、OOB部件422和/或UWBS 423。

UWB启用应用程序411可能需要UWB功能并且可以通过框架412访问UWBS 414。

框架412提供对不同配置文件的访问。如图3所示，框架412可以包括配置文件管理器、OOB连接器、安全服务和/或UWB服务部件。

SE(例如，eSE)可以包括小程序415和/或安全UWB服务(SUS；secure UWB service)小程序416。小程序415可以包括安全生成测距数据集(RDS)所需的至少一个应用程序专用配置文件(ADF；application dedicated file)。例如，如图所示，小程序415可以包括由每个服务提供商SP提供的每个ADF(例如，SP1的ADF(ADF(SP1))和SP2的ADF(ADF(SP2)))。ADF可以例如在密钥供应步骤中由服务提供商提供。此外，小程序415可以通过SUS小程序416将RDS发送到UWBS 414。在一个实施例中，RDS可以包括用于特定UWB会话的会话ID和/或UWB会话密钥。

OOB部件413可以连接到框架412的OOB连接器，并且可以建立测距设备(UWB设备)之间的OOB连接(例如，蓝牙低功耗(BLE；Bluetooth low energy)连接)。例如，第一电子设备410与第二电子设备420之间的OOB连接可以通过第一电子设备410的OOB部件413和第二电子设备420的OOB部件422建立。

UWBS 414管理UWB硬件。UWBS 414可以与另一测距设备的UWBS(例如，第二电子设备420的UWBS 423)执行UWB会话。UWBS 414可以由框架412管理并且可以从SE接收安全测距所需的RDS。

参考图4，在操作1(发现操作)中，第一电子设备410和第二电子设备420可以通过OOB部件413和422执行服务发现过程。服务发现过程可以包括安全信道(SC；securechannel)协商操作。

在操作2(安全信道配置操作)中，第一电子设备410和第二电子设备420可以通过框架配置设备之间的安全信道(例如，SC#1和SC#2)以便在电子设备(例如，FiRa设备)之间安全地共享数据。安全信道可以通过OOB通道(连接)打开。

在操作3(RDS生成/传输操作)中，可以在小程序415与SUS小程序416之间交换UWB会话密钥URSK。例如，可以通过与SUS小程序416的通信将小程序415的UWB测距会话密钥(URSK；UWB ranging session key)发送到SUS小程序416。此外，会话ID可以通过SUS小程序416被发送到UWBS 414。为此，可以首先建立小程序415与SUS小程序416之间的安全信道以及SUS小程序416与UWBS 414之间的安全信道。UWBS 414可以通过配置的安全信道从SUS小程序416获得对应的RDS。会话ID和UWB会话密钥可以由小程序415生成。

在操作4(安全测距操作)中，第一电子设备410和第二电子设备420可以通过UWBS414和423执行安全测距过程。UWBS可以使用获得的URSK进行安全测距。

图5示出了根据本公开的实施例的使用第一安全部件执行安全测距的电子设备的示例性配置和操作。

在图5的实施例中，电子设备(UWB设备)510可以是上文参考图1至图3描述的电子设备之一。例如，电子设备510可以是例如智能测距设备，并且第一安全部件可以是安全元件(例如，eSE)。

参考图5，电子设备510可以包括UWB启用应用程序511、框架512和第一安全部件513，并且可以与外部电子设备520通信。

在图5的实施例中，框架512可以通过APDU接口与另一测距设备和第一安全部件513通信。APDU接口基于例如ISO/IEC 7816-4。例如，电子设备510的框架512可以从外部测距设备(例如，FiRa设备)520接收用于选择由OID标识的ADF的APDU命令(选择ADF(OID))，并且可以将接收到的APDU命令发送到第一安全部件513。此外，框架512可以从第一安全部件513接收对APDU命令的响应并将接收到的响应发送到外部测距设备(例如，FiRa设备)520。该响应可以包括密码、加密消息EncMsg和/或消息认证码MAC。

另外，APDU接口可以仅由框架512调用，并且不能由应用程序511调用。因此，当使用APDU接口时，UWB启用应用程序511可以使用例如serviceInit()API仅起到向框架512提供服务配置文件的作用。换言之，UWB启用应用程序511可以不主动操作。

图6示出了根据本公开的实施例的使用第二安全部件执行安全测距的电子设备的示例性配置和操作。

在图6的实施例中，电子设备(UWB设备)610可以是上文参考图1至图3描述的电子设备之一。例如，电子设备610可以是例如智能测距设备，并且第二安全部件可以是TEE或保险箱(SB)。

参考图6，电子设备610可以包括UWB启用应用程序611、框架612和第二安全部件613，并且可以与外部电子设备620通信。

在一个实施例中，第二安全部件613可以包括例如实现安全信道1SC01的功能和/或实现密钥的功能。例如，第二安全部件613可以包括对应于应用程序(例如，Appid为abc的应用程序)的MAC私钥(例如，密钥值为123的MAC私钥)和/或对应于应用程序(例如，Appid为abc的应用程序)的ENC私钥(例如，密钥值为456的ENC私钥)。在一个实施例中，MAC私钥可以用于生成消息验证码，并且ENC私钥可以用于加密。这种安全信道密钥可以例如在密钥供应步骤中由服务提供商提供。密钥供应步骤可以在发现步骤之前执行。

在图6的实施例中，框架612可以通过框架API集而不是APDU接口与第二安全部件(TEE/SB)613通信。在一个实施例中，框架API集可以包括例如API，诸如用于注册应用程序的register()、用于配置安全消息会话的setsecureMessagingSession()和/或用于配置测距数据(或RDS)的setRangingData()。

不同于图5的使用APDU接口的实施例，这个框架API可以被应用程序611调用。因此，当使用该框架API时，框架612可负责逻辑，并且UWB启用应用程序611可以使用API实现各种服务(例如，FiRa服务)以及用于安全测距的详细参数设置，并且向框架提供与之相关的数据。因此，与图5的实施例相比，图6的实施例在服务提供商对应用程序的维护和可靠性方面是有利的。

图7a示出了根据本公开的实施例的电子设备建立第一安全部件与超宽带基站(UWBS)之间的安全信道的方法。

在图7a的实施例中，电子设备710可以是例如具有图5的配置的电子设备，并且第一安全部件可以是SE(例如，eSE)。

参考图7a，电子设备710可以包括UWB启用应用程序711、框架712、UWBS 713和第一安全部件714。

在图7a的实施例中，安全信道通过APDU接口直接配置在UWBS 713与第一安全部件714之间。如图所示，安全信道是基于对称密钥的安全信道，其中UWBS 713和第一安全部件714共享相同的共享密钥(例如，共享密钥(“sharedScret＝K”))。

图7b示出了根据本公开的实施例的电子设备建立第二安全部件与超宽带基站(UWBS)之间的安全信道的方法。

在图7b的实施例中，电子设备720可以是例如具有图6的配置的电子设备，并且第二安全部件可以是TEE和/或SB。

参考图7b，电子设备720可以包括UWB启用应用程序721、框架722、UWBS 723和第二安全部件724。第二安全部件724可以是TEE或保险箱，并且TEE可以包括TA。

在图7b的实施例中，安全信道通过功能调用(API调用)通过框架722配置在UWBS723与第二安全部件724之间。换言之，安全信道可以不直接配置在UWBS 723与安全部件724之间，而是可以经由框架722来设置。例如，可以建立TEE(或SB)724与框架722之间的安全信道(第一安全信道)，并且可以配置框架722与UWBS 723之间的安全信道(第二安全信道)，从而间接配置TEE(或SB)724与UWBS 723之间的安全信道。这将在下文参考图9a和图9b进一步描述。

在图7b的实施例中，安全信道可以是基于非对称密钥或对称密钥的安全信道。换言之，在图7b的实施例中，安全信道可以基于非对称加密算法或对称加密算法来配置。因此，不同于图7a的使用第一安全部件的实施例，在图7b的使用第二安全部件的实施例中，可以设置基于非对称密钥的安全信道。

图8为示出了根据本公开的实施例的通过包括第二安全部件的电子设备提供RDS的方法的流程图。

对于UWB安全测距，电子设备需要与外部电子设备进行端到端加密(E2EE；end-to-end encryption)通信。为此，与外部设备共享的特定会话密钥URSK应该从安全部件安全地传输到UWBS。在图8的实施例中，描述了其中会话密钥可以从安全部件安全地传输到UWBS的实施例。

在图8的实施例中，电子设备810可以是例如具有图6的配置的电子设备，并且电子设备810可以包括框架811、UWBS 812和第二安全部件813，并且可以与外部电子设备820通信。第二安全部件813可以是TEE(或TEE中的TA)和/或SB。TEE可以包括可信应用程序(TA)。另外，虽然未示出，但电子设备810与其他UWB设备一样，可以包括至少一个应用程序(UWB启用应用程序)，并且框架和UWB启用应用程序可以由至少一个处理器(例如，应用程序处理器(AP))实现。因此，在本公开中，框架和/或UWB启用应用程序的操作可以表示为处理器的操作。

在图8的实施例中，假定第二安全部件813包括对应于第一应用程序(应用程序标识符(例如，应用程序ID(例如，应用程序ID(AppID)或UUID)为abc的UWB启用应用程序)的安全信道密钥(例如，密钥值为123的密钥)、以及对应于第二应用程序(应用程序标识符(例如，应用程序ID(AppID)或UUID)为xyz的UWB启用应用程序)的安全信道密钥(例如，密钥值为789的密钥)。作为一个实施例，安全信道密钥可以包括用于加密的密钥和/或用于消息认证的密钥。然而，本公开不限于此，并且第二安全信道可以包括更多安全信道密钥或单个安全信道密钥。

在操作8010中，外部电子设备820可以向电子设备810发送安全信道请求(第一安全信道请求)。例如，外部电子设备820可以向电子设备810发送包括OID的第一安全信道请求。第一安全信道请求可以是用于请求生成外部电子设备820与电子设备810之间的安全信道的请求。换言之，第一安全信道请求可以是用于生成设备之间的安全信道的请求。发送的第一安全信道请求可以被发送到电子设备810的框架811。

在操作8020中，框架811可以识别与包括在第一安全信道请求中的OID相匹配的应用程序标识符(例如，AppID)。因此，框架811可以将OID转换成AppID。这里，AppID可以是用于识别由服务提供商提供的UWB启用应用程序的ID。在本公开中，AppID可以区别于用于识别上述小程序的小程序ID(AID)。在一个实施例中，框架811可以包括OID与AppID之间的映射表(列表)。

在操作8030中，框架811可以向电子设备810的第二安全部件813发送与第一安全信道请求相对应的第二安全信道请求。例如，框架811可以向第二安全部件813发送包括与第一安全信道请求的OID相匹配的AppID的第二安全信道请求。

在操作8040中，电子设备810可以建立电子设备810的第二安全部件813(或电子设备810)与外部电子设备820之间的安全信道。在一个实施例中，安全信道可以与由包括在第二安全信道请求中的AppID识别的UWB启用应用程序相关联，并且可以直接或间接地配置在外部电子设备820与第二安全部件813之间。

在操作8050中，电子设备810可以通过配置的安全信道执行用于与外部电子设备820的UWB会话的参数交换过程。因此，电子设备810可以与外部电子设备820协商设置参数的值。例如，电子设备810可以通过设置的安全信道协商诸如会话ID和/或URSK等参数的值。交换的参数可以存储在第二安全部件813中。在一个实施例中，该参数可以包括UWB能力参数和/或UWB配置参数。

在操作8060中，框架811可以向第二安全部件813发送用于配置测距数据RDS的命令。例如，框架811(或UWB启用应用程序)可以调用/使用针对第二安全部件813的setRangingData()API/命令。setRangingData()具有允许第二安全部件813准备(或设置/生成)RDS的功能。换言之，setRangingData()可以是用于允许第二安全部件813设置RDS的API。setRangingData()可以包括应用程序的AppID以识别哪个应用程序调用了API。

在操作8070中，第二安全部件813可以准备(或设置/生成)RDS。例如，TEE(或TEE中的TA)可以准备RDS。在一个实施例中，RDS可以包括会话ID和/或URSK。

在操作8080中，第二安全部件813可以向框架811发送与用于配置测距数据RDS的命令相对应的响应。例如，第二安全部件813可以向框架811发送与setRangingData(AppID)相对应的API返回。在一个实施例中，返回可以包括值(API返回：RDS就绪)，其指示RDS已准备好(或已配置/生成)。

在操作8090中，框架811可以将用于将RDS传输到UWBS的命令传输到第二安全部件813。例如，框架811(或UWB启用应用程序)可以调用/使用针对第二安全部件813的PushRDStoUWBS()API/命令。PushRDStoUWBS()具有允许第二安全部件813将准备好的RDS发送(或推送)到UWBS的功能。换言之，PushRDStoUWBS()可以是用于允许第二安全部件813将RDS发送给UWBS的API。PushRDStoUWBS()可以包括与准备好的RDS相对应的应用程序的AppID。

在操作8100中，电子设备810可以建立UWBS 812与第二安全部件813之间的安全信道。因此，可以在设备中建立UWBS 812与第二安全部件813之间的安全信道。例如，可以建立UWBS与TEE(或TEE中的TA)之间的安全信道。如上文参考图7b所述，UWBS 812与第二安全部件813之间的安全信道可以通过例如框架811间接设置。该安全信道建立过程的示例在下文中参考图9a和图9b进行描述。

在操作8110中，第二安全部件813可以通过建立的安全信道将加密的RDS传输到UWBS 812。例如，TEE(或TEE中的TA)可以使用通过安全信道建立过程获得的加密密钥K_ENC对RDS进行加密，并且可以将加密的RDS传输给UWBS 812。因此，可以将RDS从第二安全部件安全地传输(推送)到UWBS。

在操作8120中，框架811可以向UWBS 812发送用于开始UWB会话的测距开始命令。例如，框架811可以将用于启动UWB会话/测距的UCI命令(UCI：Ranging Start())发送到UWBS。Ranging Start()可以包括AppID。在一个实施例中，AppID可以与用于识别UWB会话的会话ID相关联。

在操作8130中，UWBS 812可以向框架811发送对应于测距开始命令的响应。在一个实施例中，响应可以包括指示测距开始命令是否被接受的状态值。例如，该响应可以包括指示测距开始命令被接受的OK值，或者指示测距开始命令未被接受的NOK值。

在操作8140中，电子设备810可以通过UWBS 812与外部电子设备820执行安全测距。在这种情况下，UWBS 812可以使用URSK执行安全测距。

如图8的实施例所示，在包括第二安全部件的电子设备中，可以通过应用程序的API调用将包括URSK的RDS从第二安全部件推送到UWBS。例如，RDS可以通过应用程序的PushRDStoUWBS(AppID)API调用从TEE(或TEE中的TA)被发送到UWBS。

另外，从外部设备的角度来看，使用由图8中公开的第二安全部件传输的会话密钥的安全测距操作可以被视为与使用由图4中公开的第一安全部件传输的会话密钥的安全测距操作相同。

<UWBS与第二安全部件(例如，TEE)之间的安全信道建立过程的第一实施例>

图9a示出了根据本公开的实施例的用于使用对称方案配置UWBS与安全部件之间的安全信道的过程。

图9a的安全信道建立过程可以是图8的操作8100的安全信道建立过程的示例。

图9a的对称方法对应于相互交换随机值并基于对应的随机值生成会话密钥的方法。在这种情况下，密码用于证明它具有用于身份验证的密钥。生成的会话密钥可以包括用于加密的会话密钥s_ENC(第一会话密钥)和/或用于消息认证的会话密钥s_MAC(第二会话密钥)。

在图9a的实施例中，电子设备可以包括框架911、UWBS 912和安全部件913。

在图9a的实施例中，安全部件913和UWBS 912可以包括用于使用对称加密算法的对称方案的预先共享的共享密钥(例如，K1和K2)。每个密钥可以通过例如将参考图10b描述的密钥供应操作存储在安全部件中。

图9a的安全信道建立过程例如可以在如操作9100中调用PushRDStoUWBS()API时启动。例如，当用于将RDS推送到UWBS的命令从框架(或UWB启用应用程序)传输到安全部件时，可以启动安全信道建立过程。然而，实施例不限于此。

参考图9a，在操作9101中，安全部件913生成随机值r并将随机值r发送到框架912。安全部件可以是TEE或保险箱。如上所述，TEE可以包括TA，并且作为TEE的安全部件的操作可以被理解为TEE中的TA的操作。

在操作9102中，框架911将接收到的随机值r发送到UWBS 912。随机值r可以称为第一随机值。

在操作9103中，UWBS 912可以执行生成随机值r'(Gen random r')的操作、生成第一会话密钥s_enc(Gen SessionKey s_enc)的操作、生成第二会话密钥s_MAC(GenSessionKey s_MAC)的操作和/或生成密码q(Gen cryptogram q)的操作。

UWBS 912可以通过随机值生成操作来生成随机值r'。随机值r'可以称为第二随机值。

UWBS 912可以通过第一会话密钥生成操作来生成用于加密的第一会话密钥s_enc。

UWBS 912可以通过第二会话密钥生成操作来生成用于消息认证的第二会话密钥s_MAC。

UWBS 912可以通过密码生成操作来生成密码q。密码q可以称为第一密码。

在操作9104中，UWBS 912可以将随机值r'和密码q发送到安全部件913。随机值r'和密码q可以通过框架911传输到安全部件913。

在操作9105中，安全部件可以执行第一会话密钥(s_enc)生成操作(GenSessionKey s_enc)、第二会话密钥(s_MAC)生成操作(Gen SessionKey s_MAC)、密码q验证操作(验证密码q)和/或密码p生成操作(Gen cryptogram p)。在一个实施例中，会话密钥可以基于安全信道密钥和随机值生成。

安全部件913可以通过第一会话密钥生成操作来生成用于加密的第一会话密钥s_enc。

安全部件913可以通过第二会话密钥生成操作来生成用于消息认证的第二会话密钥s_MAC。

安全部件913可以通过密码验证操作来验证从UWBS 912接收到的密码q。

安全部件913可以通过密码生成操作来生成密码p。密码p可以称为第二密码。

在操作9106中，安全部件913可以将密码p发送到UWBS 912。密码p可以通过框架911传输到安全部件913。

在操作9107中，UWBS 912可以执行密码p验证操作(验证密码p)。UWBS 912可以通过密码验证操作来验证从安全部件913接收到的密码p。

在操作9108中，框架911可以对UWBS 912和安全部件913执行随机质询操作。例如，如图所示，框架911可以通过随机质询操作将随机质询(随机值)发送到UWBS 912和安全部件913。

在操作9109中，框架911可以从UWBS 912和安全部件913接收对随机质询的响应。例如，如图所示，框架911可以分别从USBS 912和安全部件913接收基于用于随机质询和消息认证的第二会话密钥s_MAC生成的MAC。作为一个实施例，可以使用基于哈希的消息认证码(HMAC)算法或基于密码的消息认证码(CMAC)算法来生成MAC。

此外，框架911可以确定从UWBS 912接收到的MAC(第一MAC)是否匹配从安全部件913接收到的MAC(第二MAC)。

通过这个过程，UWBS 912可以准备好接收URSK(或RDS)，并且框架911和安全部件913可以准备好将URSK(或RDS)推送到UWBS 912。例如，当从UWBS 912接收到的MAC(第一MAC)匹配从安全部件913接收到的MAC(第二MAC)时，UWBS 912可以准备好接收URSK(或RDS)，并且框架911和安全部件913可以准备好将URSK(或RDS)传输到UWBS 912。

<UWBS与第二安全部件(例如，TEE)之间的安全信道建立过程的第二实施例>

图9b示出了根据本公开的实施例的使用非对称方法配置UWBS与安全部件之间的安全信道的过程的示例。

图9b的安全信道建立过程可以是图8的操作8100的安全信道建立过程的示例。

图9b的不对称方法的特征在于使用基于椭圆曲线(ECC；elliptic curve)的临时密钥生成共享密钥以满足完美正向序列(PFS；perfect forward sequence)。生成的共享密钥可以用于生成会话密钥。此外，非对称方法需要移动厂商预先存储的证书和私钥(静态密钥)来进行认证，并且可以在两侧根据ECC算法来配置临时密钥和静态密钥从而生成并利用共享密钥。

在图9b的实施例中，电子设备可以包括框架921、UWBS 922和安全部件923。作为一个实施例，安全部件923可以是TEE或SB。如上所述，TEE可以包括TA，并且作为TEE的安全部件的操作可以被理解为TEE中的TA的操作。

在图9b的实施例中，电子设备可以包括框架921、UWBS 922和安全部件923。例如，安全部件TA可以包括TA的私钥/公钥Priv/Pub_TA、TA的证书Cert_TA和/或UWBS的证书Cert_UWB，安全部件SB可以包括SB的私钥/公钥Priv/Pub_SB、SB的证书Cert_SB和/或UWBS的证书Cert_UWB，并且UWBS可以包括UWBS的私钥/公钥Priv/Pub_UWB、TA的证书Cert_TA和/或SB的证书Cert_SB。每个密钥可以通过例如将参考图10b描述的密钥供应操作存储在安全部件中。

参考图9b，在操作9201中，安全部件923可以执行第一临时密钥e生成操作(Genephemeral key e)。例如，TEE(或TA)可以通过第一临时密钥生成操作来生成第一临时密钥e。在一个实施例中，例如可以在如操作9200中调用PushRDStoUWBS()API之前生成临时密钥e，但不限于此。

安全部件923还可以生成针对第一临时密钥e的签名值(signed(e))。例如，TEE(或TA)还可以使用TA的私钥(Priv_TA)为第一临时密钥e生成签名值(signed(e))。在本公开中，第一临时密钥e可以称为Pub_e，并且第一临时密钥的签名值(signed(e))可以称为signed(Pub_e)。

在操作9202中，安全部件923将第一临时密钥和第一临时密钥的签名值(“e||signed(e)”)发送到框架921，并且在操作9203中，框架921将接收到的第一临时密钥和第一临时密钥的签名值(“e|signed(e)”或“Pub_e|signed(Pub_e)”)发送到UWBS。

在操作9204中，UWBS 922可以执行验证签名的临时密钥(signed e)的操作(Verify signed e)以及生成第二临时密钥(e')的操作(Gen ephemeral key e')。例如，UWBS 922可以使用TA的证书(或TA的公钥(Pub_TA))来验证第一临时密钥的签名值(signed(e))，并且可以通过生成第二临时密钥的操作来生成第二临时密钥e'。作为一个实施例，可以基于第一临时密钥e和第二临时密钥e'生成/计算共享密钥。在本公开中，第二临时密钥e'也可以称为Pub_e'。

UWBS 922还可以生成针对第二临时密钥e'的签名值(singed(e')或signed(Pub_e',Pub_e))。例如，UWBS 922还可以通过使用UWBS的私钥Priv_UWBS生成针对第二临时密钥e'的签名值。

在操作9205中，UWBS 922将第二临时密钥和第二临时密钥的签名值(“e'||signed(e')”或“Pub_e'||signed(Pub_e',pub_e)”)发送到框架921，并且在操作9206中，框架921将接收到的第二临时密钥和第二临时密钥的签名值(“e'||signed(e')”或“Pub_e'||signed(Pub_e',pub_e)”)发送到安全部件923。

在操作9207中，安全部件923可以执行通过使用第二临时密钥Pub_e'和第一临时密钥Pub_e计算共享密钥S的操作、基于共享密钥S和预共享参数(例如，1234)(第一上下文)生成用于加密的会话密钥K_ENC的操作、以及基于共享密钥S和预共享参数(例如，ABCD)(第二上下文)生成用于MAC的会话密钥K_MAC的操作。例如，TEE(或TA)可以通过使用第二临时密钥e'和第一临时密钥e生成共享密钥S，通过使用预设的密钥推导函数(KDF；keyderivation function)从第一上下文和共享密钥S生成用于加密的会话密钥K_ENC，并且通过使用预设的KDF从第二上下文和共享密钥S生成用于消息认证的会话密钥K_MAC。

在操作9208中，UWBS 922可以执行通过使用第二临时密钥Pub_e'和第一临时密钥Pub_e计算共享密钥S的操作、基于共享密钥S和预共享参数(例如，1234)(第一上下文)生成用于加密的会话密钥K_ENC的操作、以及基于共享密钥S和预共享参数(例如，ABCD)(第二上下文)生成用于MAC的会话密钥K_MAC的操作。例如，UWBS 922可以通过使用第二临时密钥Pub_e'和第一临时密钥Pub_e生成共享密钥S，通过使用预设的KDF从第一上下文和共享密钥S生成用于加密的第一会话密钥K_ENC，并且通过使用预设的KDF从第二上下文和共享密钥S生成用于消息认证的第二会话密钥K_MAC。因此，UWBS 922和安全部件923可以拥有用于相同加密的密钥K_ENC和用于消息认证的密钥K_MAC。

另外，在所示实施例中，举例说明了操作9208在操作9205之后执行，但是操作9208可以在操作9204之后的任何时间点执行。例如，操作9208可以在操作9204之后和操作9205之前执行。

在操作9209中，框架921可以对UWBS 922和安全部件923执行随机质询操作。例如，如图所示，框架921可以通过随机质询操作将随机质询(随机值)发送到UWBS 922和安全部件923。

在操作9210中，框架921可以从UWBS 922和安全部件923接收对随机质询的响应。例如，如图所示，框架921可以分别从UWBS 922和安全部件923接收基于随机质询(Random)和用于消息认证的第二会话密钥K_MAC生成的MAC。作为一个实施例，可以使用基于哈希的消息认证码(HMAC)算法或基于密码的消息认证码(CMAC)算法来生成MAC。

此外，框架921可以确定从UWBS 922接收到的MAC(第一MAC)是否匹配从安全部件923接收到的MAC(第二MAC)。

通过这个过程，UWBS 922可以准备好接收URSK(或RDS)，并且框架921和安全部件923可以准备好将URSK(或RDS)推送到UWBS 922。例如，当从UWBS 922接收到的MAC(第一MAC)匹配从安全部件923接收到的MAC(第二MAC)时，UWBS 922可以准备好接收URSK(或RDS)，并且框架921和安全部件923可以准备好将URSK(或RDS)传输到UWBS 922。

<UWBS与第二安全部件(例如，TEE)之间的安全信道建立过程的第三实施例>

图9c示出了根据本公开的实施例的使用非对称方法建立UWBS与安全部件之间的安全信道的另一示例性过程。

图9c的安全信道建立过程可以是图8的操作8100的安全信道建立过程的示例。

图9c的不对称方法的特征在于使用基于椭圆曲线(ECC)的临时密钥生成共享密钥以满足完美正向序列(PFS)。生成的共享密钥可以用于生成会话密钥。此外，非对称方法需要移动厂商预先存储的证书和私钥(静态密钥)来进行认证，并且可以在两侧根据ECC算法来配置临时密钥和静态密钥从而生成并利用共享密钥。

在图9c的实施例中，为了便于描述，假设电子设备是用于提供基于UWB的支付服务的电子设备(例如，图2b的第一电子设备)，并且安全部件是TEE(TA)，但本公开不限于此。

在图9c的实施例中，电子设备可以包括UWB启用钱包应用程序921、钱包框架932、UWBS 933和可信支付应用程序934。

在图9c的实施例中，UWBS 933和可信支付应用程序(TPA；trusted paymentapplication)934各自包括用于使用非对称加密算法的非对称方法的密钥和证书。例如，TPA 934可以包括TPA的密钥(私钥)(SK.TPA)、TPA的证书(CERT.TPA)和/或根证书(ROOT.OEM)，并且UWBS可以包括UWBS的密钥(私钥)(SK.UWBS)、UWBS的证书(CERT.UWBS)和/或根证书(ROOT.OEM)。每个密钥可以通过例如将参考图10b描述的密钥供应操作存储在安全部件中。

下表1示出了用于建立UWBS与TEE(TPA/TA)之间的安全信道的密钥和数据的示例。

[表1]

下表2示出了交换证书(例如，TPA证书(CERT.TPA)和UWBS证书(CERT.UWBS))以在UWBS与TEE(TPA/TA)之间建立安全信道的示例。

[表2]

参考图9c，在操作9301中，UWB启用钱包应用程序931可以向TPA 934发送用于从TPA获得临时密钥的命令。例如，UWB启用钱包应用程序931可以将用于从TPA获得临时密钥和/或签名的临时密钥的TEE命令(例如，TEE客户端API CMD：WALLET_GET_EPHEMERAL_KEY)传输到TPA 934。下表3示出了WALLET_GET_EPHEMERAL_KEY的TEE命令的示例。

[表3]

在操作9032中，TPA934可以生成TPA的临时密钥(ePK.TPA)并且可以将包括TPA的临时密钥(ePK)和/或TPA的证书(CERT.TPA)的响应发送到UWB启用钱包应用程序931。例如，TPA934可以生成TPA的临时密钥(ePK.TPA)并且将包括TPA的临时密钥(ePK.TPA)和TPA的证书(CERT.TPA)的TEE响应(例如，TEE客户端API返回：ePK.TPA|CERT.TPA)传输到UWB启用钱包应用程序931。在操作9033中，UWB启用钱包应用程序931可以将接收到的TPA的临时密钥(ePK.TPA)和/或TPA的证书(CERT.TPA)发送到框架932。例如，UWB启用钱包应用程序931可以调用API(例如，框架API)以将接收到的TPA的临时密钥(ePK)和TPA的证书(CERT.TPA)传输到框架932。

在操作9034中，框架932可以将接收到的TPA的临时密钥(ePK)和/或TPA的证书(CERT.TPA)传输到USBS 933。例如，框架932可以将包括接收到的TPA的临时密钥(ePK)和/或TPA的证书(CERT.TPA)的UCI命令(例如，UCI CMD：WALLET_PUT_EPHEMERAL_KEY_FROM_TEE_CMD)传输到USBS 933。WALLET_PUT_EPHEMERAL_KEY_FROM_TEE_CMD可以是用于将来自TEE(TPA/TA)的临时密钥和证书放入UWBS中的命令。

下表4示出了用于WALLET_PUT_EPHEMERAL_KEY_FROM_TEE_CMD的UCI命令的示例。

[表4]

在操作9305中，USBS 933可以生成共享密钥并且可以生成AES密钥。例如，USBS933可以生成UWBS的临时密钥(ePK.UWBS)并且可以使用UWBS的临时密钥(ePK.UWBS)和接收到的TPA的临时密钥(ePK.TPA)来生成共享密钥S。此外，USBS 933可以使用生成的共享秘密S生成用于加密的AES密钥(K_ENC)和用于消息认证的AES密钥(K_MAC)。在操作9306中，USBS933可以将所生成的UWBS的临时密钥(ePK.UWBS)和UWBS的证书(CERT.UWBS)传输到框架932。例如，USBS 933可以将包括所生成的UWBS的临时密钥(ePK.UWBS)和UWBS的证书(CERT.UWBS)的UCI响应(例如，UCI RSP：WALLET_PUT_EPEHERAL_KEY_FROM_TEE传输到框架932。WALLET_PUT_EPEHERAL_KEY_FROM_TEE_RSP可以是对WALLET_PUT_EPHEMERAL_KEY_FROM_TEE_CMD的响应。

下表5示出了WALLET_PUT_EPEHERAL_KEY_FROM_TEE_RSP的示例。

[表5]

在操作9307中，框架932可以将接收到的UWBS的临时密钥(ePK.UWBS)和/或UWBS的证书(CERT.UWBS)传输到UWB启用钱包应用程序931。例如，框架932可以向UWB启用钱包应用程序931发送包括接收到的UWBS的临时密钥(ePK.UWBS)和/或UWBS的证书(CERT.UWBS)的API响应(例如，API返回：ePK.UWBS|CERT.UWBS)。在操作9308中，UWB启用钱包应用程序931可以向TPA 934发送用于放置来自UWBS的临时密钥的命令。例如，UWB启用钱包应用程序931可以向TPA934发送用于将来自UWBS的临时密钥和/或签名的临时密钥放入TPA中的TEE命令(例如，TEE客户端API CMD：WALLET_PUT_EPHEMERAL_KEY)。

下表6示出了WALLET_PUT_EPHEMERAL_KEY的TEE命令的示例。

[表6]

/>

在操作9309中，TPA 934可以生成共享密钥并且可以生成AES密

钥。例如，TPA 934可以使用接收到的UWBS的临时密钥ePK.UWBS和TPA的临时密钥ePK.TPA来生成共享密钥S。此外，TPA 934可以使用生成的共享密钥S生成用于加密的AES密钥(K_ENC)和用于消息认证的AES密钥(K_MAC)。在操作9310中，TPA 934可以向UWB启用钱包应用程序931发送针对用于放入来自UWBS的临时密钥的命令的响应。例如，TPA 934可以传输TEE响应(例如，TEE客户端API返回：OK/NOK)，从而向UWB启用钱包应用程序931指示OK/NOK。

图9d示出了根据本公开的实施例的UWBS通过UWBS与安全部件之间的安全信道将RDS传输到安全部件的过程。

在图9d的实施例中，可以例如通过图9c的安全信道配置过程来配置UWBS与安全部件之间的安全信道。

在图9d的实施例中，为了便于描述，假设电子设备是用于提供基于UWB的支付服务的电子设备(例如，图2b的第一电子设备)，并且安全部件是TEE(TA)，但本公开不限于此。

在图9d的实施例中，电子设备可以包括UWB启用钱包应用程序941、钱包框架942、UWBS 943和可信支付应用程序944。

在操作9401中，UWB启用钱包应用程序941可以向TPA 944发送随机质询(随机值)。例如，UWB启用钱包应用程序941可以向TPA 944传输包括随机质询的TEE命令(例如，TEE客户端API CMD：WALLET_PUT_CHALLENGE)。WALLET_PUT_CHALLENGE用于从TPA获取MAC(例如CMAC)，输入包括随机值，并且输出包括随机值和共享密钥的MAC值。

下表7示出了WALLET_PUT_CHALLENGE的TEE命令的示例。

[表7]

在操作9402中，TPA 944可以将TPA的MAC(MAC.TPA)发送到UWB启用钱包应用程序941。例如，TPA 944可以基于接收到的随机质询和共享密钥来生成MAC(MAC.TPA)，并且将包括MAC(MAC.TPA)的TEE响应(例如，TEE客户端API返回：MAC.TPA)传输到UWB启用钱包应用程序941。在操作9403中，UWB启用钱包应用程序941可以将随机质询(随机值)传输到框架942。例如，UWB启用钱包应用程序941可以通过调用框架API(API)将随机质询(随机值)传输到框架942。

在操作9404中，框架942可以将接收到的随机质询发送到UWBS 943。例如，框架942可以将包括UWBS 943(包括接收到的随机质询的)的UCI命令(例如，WALLET_PUT_CHALLENGE_CMD)传输到UWBS 943。WALLET_PUT_CHALLENGE_CMD可以用于从UWBS获取UWBS的MAC(MAC.UWBS)。

下表8示出了WALLET_PUT_CHALLENGE_CMD的示例。

[表8]

在操作9405中，UWBS 943可以将UWBS的MAC(MAC.UWBS)传输到框架942。例如，UWBS943可以基于接收到的随机质询和共享密钥来生成MAC(MAC.UWBS)，并且可以将包括MAC(MAC.UWBS)的UCI响应(例如，WALLET_PUT_CHALLENGE_RSP)传输到框架942。下表9示出了WALLET_PUT_CHALLENGE_RSP的示例。

[表9]

在操作9406中，框架942可以将接收到的UWBS的MAC(MAC.UWBS)传输到UWB启用钱包应用程序941。例如，框架942可以通过API返回将UWBS的MAC(MAC.UWBS)传输到UWB启用钱包应用程序941。在操作9407中，UWB启用钱包应用程序941可以确定TPA的MAC(MAC.TPA)和UWBS的MAC(MAC.UWBS)是否相同。

在操作9408中，UWB启用钱包应用程序941可以将用于获得RDS的命令传输到TPA944。例如，当TPA的MAC(MAC.TPA)和UWBS的MAC(MAC.UWBS)相同时，UWB启用钱包应用程序941可以将用于获得RDS的TEE命令(例如，TEE客户端API命令：TEE WALLET_GET_RDS)传输到TPA 944。WALLET_GET_RDS可以用于从TPA获取加密的RDS。

下表10示出了WALLET_GET_RDS的TEE命令的示例。

[表10]

在操作9409中，TPA 944可以将加密的RDS(encrypted_blob)发送到UWB启用钱包应用程序941。例如，TPA 944可以将包括加密RDS(Encrypted_blob)和加密RDS的MAC(MAC.eRDS)的TEE响应(例如，TEE客户端API返回：Encrypted_blob|MAC.eRDS)传输到UWB启用钱包应用程序941。在操作9410中，UWB启用钱包应用程序941可以将接收到的加密RDS(Encrypted_blob)传输到框架942。例如，UWB启用钱包应用程序941可以通过调用API(框架API)将加密的RDS(Encrypted_blob)和加密的RDS的MAC(MAC.eRDS)发送到框架942。

在操作9411中，框架942可以将接收到的加密RDS(Encrypted_blob)发送到UWBS943。例如，框架942可以将包括加密RDS(Encrypted_blob)和加密的RDS的MAC(MAC.eRDS)的UCI命令(例如，WALLET_PUT_ENCRYPTED_RDS_CMD)发送到UWBS 943。WALLET_PUT_ENCRYPTED_RDS_CMD可以用于从UWBS放入UWBS的RDS。

下表11示出了WALLET_PUT_ENCRYPTED_RDS_CMD的示例。

[表11]

在操作9412中，UWBS 943可以向框架942发送响应。例如，UWBS 943可以将对应于UCI命令的UCI响应(例如，WALLET_PUT_ENCRYPTED_RDS_RSP)发送到框架942。WALLET_PUT_ENCRYPTED_RDS_RSP可以包括指示加密RDS是否被正常接收的状态OK/NOK的信息。下表12示出了WALLET_PUT_ENCRYPTED_RDS_RSP的示例。

[表12]

图10a示出了根据本公开的实施例的用于包括第一安全部件的电子设备的密钥供应方法。

图10a的电子设备可以是图5的电子设备，并且第一安全部件可以是SE(例如，eSE)。

参考图10a，在操作1中，对于服务提供商(SP)1011的密钥供应，供应机构(PA)1012可以向安全域(SD)拥有者1013发送授权请求，并且在操作2中，SD拥有者1013可以基于该请求向第一安全部件1014提供PA凭证。在操作3中，SP 1011可以向PA 1012请求ADF，并且在操作4中，PA 1012可以基于该请求向第一安全部件1014提供ADF。在操作5中，SP 1011可以对提供给第一安全部件1014的ADF执行个性化。

因此，为了服务提供商1011向第一安全部件1014提供密钥供应，各种业务合同关系中的各种实体(PA、SD拥有者等)需要彼此合作。因此，服务提供商1011难以直接将密钥提供给第一安全部件1014。换言之，服务提供商1011变得难以灵活且有效地提供密钥。

图10b示出了根据本公开的实施例的用于包括第二安全部件的电子设备的密钥供应方法。

图10b的电子设备可以是图6的电子设备，并且第二安全部件可以是TEE(TA)或SB。

在图10b的实施例中，电子设备可以包括移动平台1022(例如，Android平台)和第二安全部件1023。在一个实施例中，移动平台可以包括上述框架。

参考图10b，在操作1中，服务提供商1021可以调用用于密钥供应的API，并且在操作2中，移动平台1022可以向第二安全部件1023提供认证。在操作3中，第二安全部件1023向移动平台1022发送证书，并且在操作4中，移动平台1022向服务提供商1021发送证书。在操作5中，服务提供商1021可以将加密密钥发送给移动平台1022，并且在操作6中，移动平台1022可以将加密密钥发送给第二安全部件1023。

在使用第二安全部件的图10b的实施例中，与使用第一安全部件的图10a的实施例不同的是，服务提供商1021可以以安全方式将其自己的凭证导入受信区域，例如TEE或SB。在这种情况下，电子设备的移动平台(或框架)1022只需要提供用于供应方法的API。因此，服务提供商1021可以灵活且有效地提供密钥。

图11示出了根据本公开的实施例的用于为包括第二安全部件的电子设备提供密钥的认证过程。

在图11的实施例中，电子设备可以是图6的电子设备，并且第二安全部件可以是TEE(TA)或SB。

在图11的实施例中，认证过程可以是图10的过程的一部分。在执行密钥供应之前执行认证过程。

参考图11，在操作1101中，电子设备的UWB启用应用程序可以从服务提供商(服务器)请求现时值(nonce)，并且在操作1102中，服务提供商可以基于该请求向UWB启用应用程序提供现时值。

在操作1103中，UWB启用应用程序可以将包括现时值的认证(认证请求)发送到框架，并且在操作1104中，框架可以将认证(认证请求)发送到第二安全部件。

在操作1105中，第二安全部件可以将基于认证(认证请求)的blob(认证响应)返回给框架。在一个实施例中，blob(认证响应)可以包括现时值、测量值、设备ID、签名和/或证书。在操作1106中，框架可以将blob发送给UWB启用应用程序，并且在操作1107中，UWB启用应用程序可以将blob发送给服务提供商。

在操作1108中，服务提供商可以从blob中提取公钥，并且可以通过使用基于公钥的密钥包装方法来对凭证(例如，安全信道密钥)进行加密。

在操作1109中，服务提供商可以将包装的密钥发送到UWB启用应用程序，并且在操作1110中，UWB启用应用程序可以将包装的密钥发送到第二安全部件。在操作1111中，第二安全部件可以将包装的密钥与OID和/或AppID一起导入(import)。

通过这种过程，密钥(安全信道密钥)可以由服务提供商安全地导入到第二安全部件。

图12示出了根据本公开的实施例的电子设备的示例性配置。

在图12的实施例中，电子设备1200可以是例如智能测距设备或测距设备。

参考图12，电子设备1200包括至少一个应用程序1210、框架1220、UWBS 1230和/或安全部件1240(例如，TA和/或保险箱)。

每个应用程序1210可以由AppID识别并且可以调用/使用框架1220的框架API。在一个实施例中，应用程序1210可以是UWB启用应用程序。

框架1220可以包括OOB连接器1221和/或安全服务1222，并且可以通过框架API1223与应用程序1210接口连接。框架API 1223可以包括例如用于注册应用程序的register()API、用于设置安全消息会话的setsecureMessagingSession()API、用于设置测距数据(或RDS)的setRangingData()API和/或用于将URSK(或RDS)传输到UWBS的pushURSKtoUWBS()API。

安全部件1240可以支持密码生成函数(genCryptogram)和/或加密消息生成函数(genEncyptedMsg)，并且可以包括与具有对应于应用程序的安全信道密钥(例如，AppID(#ABC))的应用程序对应的安全信道密钥(例如，SC02Key)以及与具有AppID(#XYZ)的应用程序对应的安全信道密钥(例如，SC01Key)。例如，SB 1241可以支持密码生成功能(genCryptogram)和/或加密消息生成功能(genEncyptedMsg)，并且可以包括与具有AppID(#XYZ)的应用程序对应的安全信道密钥(例如，SC01Key)。作为另一个示例，TEE 1242可以支持密码生成功能(genCryptogram)和/或加密消息生成功能(genEncyptedMsg)，并且可以包括与具有AppID(#XYZ)的应用程序对应的安全信道密钥(例如，SC01Key)。

在一个实施例中，安全部件1240可以生成/存储会话ID和/或UWB会话密钥URSK。通过应用程序1210的pushURSKtoUWBS(API)的调用，会话ID和/或UWB会话密钥可以通过框架1220从安全部件1240传输到UWBS 1230。

图13是示出了根据本公开的实施例的由电子设备实现的方法的流程图。

在图13的实施例中，电子设备可以是智能测距设备或测距设备。图13的实施例的每个操作的详细描述可以参考上文参考图1至图12所做的描述。在图13的实施例中，电子设备的操作可以是例如电子设备的框架(或应用程序)的操作或者用于控制电子设备的框架(或应用程序)的控制器(或处理器)的操作。

电子设备可以向安全部件发送用于配置用于安全测距的测距数据集的请求(1310)。例如，电子设备可以向TEE(或TEE中的TA)发送用于设置用于安全测距的测距数据集的请求。在本公开中，测距数据集可以是UWB测距所需的数据集。在一个实施例中，测距数据集可以包括与安全测距相关联的UWB会话的会话ID信息和用于保护UWB会话的会话密钥信息中的至少一者。

电子设备可以向安全部件发送用于将测距数据集传输到UWB子系统的请求(1320)。例如，电子设备可以向TEE(或TEE中的TA)发送用于将数据集传输到UWB子系统的请求。在一个实施例中，测距数据集可以通过使用通过框架配置在安全部件与UWB子系统之间的安全信道从安全部件传输到UWB子系统。

在一个实施例中，发送用于配置测距数据集的请求可以包括调用用于请求安全部件配置测距数据集的框架API(setRangingData()API)，并且该框架API可以包括用于识别已调用框架API的应用程序的应用程序ID。

在一个实施例中，发送用于将测距数据集传输到UWB子系统的请求可以包括：调用用于请求安全部件将测距数据集传输到UWB子系统的框架API(PushRDStoUWBS()API)，并且框架API可以包括应用程序ID以用于识别已调用框架API的应用程序。

在一个实施例中，该方法还可以包括由框架向UWB子系统发送用于开始安全测距的命令。用于开始安全测距的命令可以包括用于识别与安全测距相关联的应用程序的应用程序ID。

在一个实施例中，安全部件与UWB子系统之间的安全信道可以是基于非对称密钥的安全信道。

在一个实施例中，安全部件可以是可信执行环境(TEE)或保险箱。

图14是示出了根据本公开的实施例的第一电子设备的结构的视图。

图14的第一电子设备可以是包括第二安全部件(例如TEE或SB)的电子设备(例如，智能测距设备)。

参考图14，电子设备可以包括收发器1410、控制器1420和存储单元1430。在本公开中，控制器可以被定义为电路或专用集成电路或至少一个处理器。

收发器1410可以向另一电子设备发送信号或从另一电子设备接收信号。收发器1410可以使用例如UWB通信发送和接收数据。

控制器1420可以控制根据本公开中提出的实施例的UWB带内搜索方法的整体操作。例如，控制器1420可以控制块间信号流以根据上述流程图执行操作。具体地，控制器1420可以控制例如参考图1至图13描述的用于安全测距的方法的操作。

存储单元1430可以存储经由收发器1410发送/接收的信息和通过控制器1420生成的信息中的至少一者。例如，存储单元1430可以存储用于上文参考图1至图13描述的安全测距的信息和数据。

图15是示出了根据本公开的实施例的第二电子设备的结构的视图。

图15的第二电子设备可以是与图14的第一电子设备通信的电子设备(例如，智能测距设备或测距设备)。

参考图15，第二电子设备可以包括收发器1510、控制器1520和存储单元1530。在本公开中，控制器可以被定义为电路或专用集成电路或至少一个处理器。

收发器1510可以向另一电子设备发送信号或从另一电子设备接收信号。收发器1510可以使用例如UWB通信发送和接收数据。

控制器1520可以控制根据本公开中提出的实施例的UWB带内搜索方法的整体操作。例如，控制器1520可以控制块间信号流以根据上述流程图执行操作。具体地，控制器1520可以控制例如参考图1至图13描述的用于安全测距的操作。

存储单元1530可以存储经由收发器1510发送/接收的信息和通过控制器1520生成的信息中的至少一者。例如，存储单元1530可以存储用于上文参考图1至图13描述的安全测距的信息和数据。

<实施例B>

实施例B对应于与上述附接模式相关的实施例。在下文中，参考图16至图27示例性地描述实施例A。

图16示出了包括SE的UWB设备的示例性配置。

在图16的实施例中，UWB设备1600是安全部件并且可以是包括安全元件(例如，eSE)的UWB设备(例如，FiRa智能设备或FiRa设备)。

如上所述，SE是基于防篡改特征的安全的安全模块，并且eSE是指在电子设备中固定和使用的固定SE。

参考图16，UWB设备1600可以包括至少一个应用程序(UWB启用应用程序)1610、框架1620、安全元件1630和/或UWBS 1640。UWB启用应用程序1610和框架1620的描述可以参考上文参考图1至图3所做的描述。

在一个实施例中，SE(例如，eSE)1630可以包括服务小程序(applet)和/或安全UWB服务(SUS)小程序。小程序可以包括安全地生成安全数据(例如，测距数据集(RDS))所需的至少一个应用程序专用配置文件(ADF)。例如，每个小程序可以包括由每个服务提供商SP提供的ADF。ADF可以由服务提供商在密钥供应步骤中提供。此外，小程序可以通过SUS小程序将RDS传输到UWBS。

在一个实施例中，RDS可以包括指示用于保护UWB测距会话的密钥的测距会话密钥(UWB测距会话密钥)和/或用于识别RDS(或与RDS相关联的会话)的会话ID。在这种情况下，测距会话密钥和会话ID在发起者和响应者中应相同。此外，RDS还可以包括至少一个测距参数(例如，到达角(AoA；angle of arrival)、接近距离)、客户端特定数据和/或多播响应者特定密钥。

UWBS 1640管理UWB硬件。UWBS 1640可以执行与另一测距设备的UWBS的UWB会话。UWBS 1640可以由框架1620管理并且可以从SE 1630接收安全测距所需的RDS。

在一个实施例中，UWB设备1600的部件可以通过先前定义的接口相互通信。例如，应用程序1610和框架1620可以通过预定义的应用程序编程接口(API)进行通信。框架1620和SE(eSE)1630可以通过预定义的对象管理应用程序编程接口(OMPI)进行通信。框架1620和UWBS 1640可以通过预定义的UCI进行通信。UWBS 1640和SE 1630可以通过预定义的SUSAPI进行通信。然而，上述接口仅仅是用于部件彼此进行通信的接口的示例，并且根据一个实施例，部件可以使用不同类型的接口彼此进行通信。

图17示出了包括SE的UWB设备的操作。

根据图17的实施例的UWB设备1700可以是图16的UWB设备。如图所示，UWB设备1700可以包括至少一个应用程序(UWB启用应用程序)1710、框架1720、安全元件(例如，eSE)1730和/或UWBS 1740。UWB设备1700可以与另一个UWB设备1750通信。在一个实施例中，UWB设备1700可以作为从另一个UWB设备1750接收用于UWB测距的控制消息(信息)的受控者来操作。

参考图17，在过程1(操作1)中，UWB设备1700可以执行用于与另一个UWB设备1750交换UWB会话参数的过程。在一个实施例中，UWB设备1700可以使用利用OOB部件(例如，BLE部件)配置的安全信道来交换UWB会话参数。在一个实施例中，UWB会话参数可以包括指示用于保护UWB测距会话的密钥的测距会话密钥(UWB测距会话密钥)和/或用于识别RDS(或与RDS相关联的会话)的会话ID。在一个实施例中，UWB会话参数可以由UWB设备1700和/或另一个UWB设备1750的小程序生成。通过过程1交换的UWB会话参数可以存储在eSE 1730中。

在过程2(操作2)中，框架1720可以从eSE 1730请求UWB参数，并且eSE 1730可以响应于该请求将UWB参数传输(返回)到框架1720。在一个实施例中，框架1720和eSE 1730可以使用预定义的OMAPI来进行UWB参数交换。在一个实施例中，UWB参数可以包括存储在eSE1730中的一些或所有UWB会话参数。例如，UWB参数可以包括UWB会话参数中的会话ID。UWB参数还可以包括存储在eSE 1730中的UWB设备的一些或全部信息(例如，受控者信息)参数。

在过程3(操作3)中，框架1720和UWBS 1740可以执行用于设置UWB参数的过程。在一个实施例中，框架1720可以将会话ID传输到UWBS 1740。框架1720和UWBS 1740可以使用预定义的UCI来进行UWB参数设置。

在过程4(操作4)中，UWBS 1740可以执行用于从eSE 1730获得安全参数的操作。例如，UWBS 1740可以查找UWB会话来搜索安全参数。在一个实施例中，UWBS 1740可以通过使用通过框架1720发送的会话ID从eSE 1730获得RDS。在这种情况下，UWBS 1740可以使用在UWBS 1740与eSE 1730之间设置的安全信道来获得RDS。在一个实施例中，UWBS 1740可以使用预定义的SUS API(例如，SUS外部API)来获得安全参数。

另外，在图17的实施例中，框架1720需要UWB会话参数(例如会话ID)来调用UWBS1740以用于例如安全测距。因此，如在过程2(操作2)中，安全地存储在eSE 1730中的UWB会话参数应该被解码并传输到框架1720。在这种情况下，可能会暴露诸如会话ID等安全参数，从而导致安全问题。此外，在图17的实施例中，应为所有参数设置访问规则(例如，从远程/本地读/写)，这可能会对访问控制造成负担。此外，在图17的实施例中，由于eSE 1730的计算性能和内存限制，多个应用程序的处理受到限制。下文参考附图描述用于解决这些问题的实施例。

图18是示出了根据本公开的实施例的包括TEE的UWB设备的示例性配置的视图。

参考图18，UWB设备1800包括至少一个应用程序(UWB启用应用程序)1810、框架1820和/或TEE 1830。UWB设备1800还可以包括OOB部件。在本公开中，除了新的定义/描述之外，图18的框架1820、UWBS 1833、UWB启用应用程序1810和OOB部件可以基本上遵循以上参考图1至图3描述的框架、UWBS、UWB启用应用程序和OOB部件的定义/描述。

参考图18，TEE 1830可以包括至少一个可信应用程序(TA)1831、安全OS(可信OS)1832和/或UWBS 1833。在图6的实施例中，如图所示，UWBS 1833可以包括在TEE区域中。换言之，UWBS 1833可以直接连接到TEE 1830的安全OS 1832。因此，UWBS 1833可以具有比位于TEE区域之外的UWBS更高的可靠性和安全级别。

TEE 1830是执行代码的环境，并且可以具有高信任度。在TEE 1830中，信任可能意味着与通用软件环境相比，它对存储在TEE区域(空间)中的项目的有效性、隔离性和访问控制具有更高级别的信任度。因此，在TEE区域中执行的TA 1831和安全OS 1832可以具有更高的信任度。在一个实施例中，TEE 1830(或TA1831)可以通过预定义接口(例如，TEE客户端API)与另一个部件通信。例如，TEE 1830(或TA 1831)可以通过预定义接口(例如，TEE客户端API)与应用程序1810通信。

TA 1831是TEE 1830的应用程序并且被称为TA以便区别于富操作系统执行环境(REE；Rich Operating System Execution Environment)中的应用程序的不确定特征。在本公开中，TA 1831(或TA的ADF)可以用于生成/存储/传输RDS并且可以用作框架1820(或与框架通信的UWBS 1833)的联系点。在本公开中，TA 1831可以由为TA定义的ID(例如，UUID)来识别。在本公开中，TA 1831也可以表示为FiRa TA。如上所述，RDS可以包括指示用于保护UWB测距会话的密钥的测距会话密钥(UWB测距会话密钥)和/或用于识别RDS(或与RDS相关联的会话)的会话ID。在这种情况下，测距会话密钥和会话ID在发起者和响应者中应相同。此外，RDS还可以包括至少一个测距参数(例如，到达角(AoA)、接近距离)、客户端特定数据和/或多播响应者特定密钥。

安全OS 1832是由TEE 1830托管的OS，并且可以是与由设备的其余部分(REE)托管的富OS(例如，Android)区分开的可信OS。TA 1831和安全OS 1832可以通过预定义的TEE核心API进行通信。通常，TA 1831可以通过使用TEE核心API的安全OS 1832将命令下载到外部设备(外围设备)来操作。在本公开中，安全OS 1832可以称为驱动程序TA。

另外，如在图16和图17的实施例中，当UWB设备的安全部件是eSE时，UWBS与eSE之间的通信是通过其中UWBS向eSE发送命令的方法进行的。另一方面，如在图18所示的实施例中，在TEE的情况下，通常，TA通过经由安全OS向外部设备发送命令的方法来与外部设备通信。因此，当UWBS被识别为仅一个外部设备并且TA和UWBS通过上述一般接口连接方法通信时，分开实现用于eSE的UWBS芯片组和用于TEE的UWBS芯片组可能是有负担的。因此，需要考虑一种用于在TA与UWBS之间进行接口连接的新方法。

在下文中，将参考每个附图示例性地描述TEE中包括的TA和UWBS相互通信的实施例。在以下实施例中，描述了UWBS与TA通信以获取TA中存储的RDS，但本公开不限于此，并且对于本领域技术人员而言显而易见的是，以下描述可以相同或类似地应用于其中UWBS获得存储在TA中的其他类型的安全数据/参数的实施例。

实施例1：其中UWBS从TA拉取RDS的实施例(例如，其中UWBS作为发起用于传输(获取)RDS的过程的发起者操作，并且TA作为响应于此的响应者操作的实施例)

在下文中，参考图19至图21示例性地描述实施例1。

图19示出了根据本公开的实施例的包括TEE的UWB设备的操作。

图19的UWB设备可以是例如图18的UWB设备。

参考图19，UWB设备1900可以包括TEE 1910和框架1920。在一个实施例中，TEE1910可以包括TA 1911、安全OS 1912和/或UWBS 1913。在图19的实施例中，包括在TEE区域中的UWBS 1913可以作为发起RDS获取过程的主体来操作，而不是从TA(或安全OS)1911的角度简单地起到作为一个外部设备(外围设备)的作用。例如，UWBS 1913可以作为传输用于安全测距的RDS获取(请求)命令的发起者来操作。在这种情况下，TA 1911可以作为响应于从UWBS 1913传输的RDS获取命令来传输RDS的响应者来操作。因此，在图19的实施例中，TA1911不以使用TEE核心API将RDS直接推送到UWBS 1913的方式来操作。

在图19的实施例中，UWBS 1913可以向TA 1911请求用于安全测距的RDS，并且TA1911可以响应于该请求将RDS传输到UWBS 1913。在这种情况下，无论安全部件的类型如何，从UWBS 1913的角度而言，UWBS都可以被实现为对安全部件执行一致的操作(作用)。换言之，无论安全部件是TEE还是SE，针对安全部件获取RDS的UWBS操作(作用)可以以相同的方式来配置。因此，可以在不考虑安全部件的情况下设计UWBS芯片组，从而有助于UWBS芯片组的设计。

此外，在图19的实施例中，如上所述，TA 1911可以不使用先前定义的TEE核心API来执行推送RDS的过程。因此，有必要为UWBS 1913与TA 1911之间的整个路径建立安全信道，包括UWBS 1913与安全OS 1912之间的路径。

此外，在图19的实施例中，可以分别为TEE和REE单独定义用于UWBS 1913的硬件接口(例如，串行外围接口(SPI)、内部集成电路(I2C)等)。在这种情况下，根据需要的安全级别，特定过程(处理)可以被灵活配置为使用用于TEE的接口或用于REE的接口。例如，用于安全测距的RDS相关处理可以被配置为通过用于TEE的接口来执行，并且例如用于一般测距的处理可以被设置为通过用于REE的接口来执行。

此外，在图19的实施例中，代替向UWBS 1913发送包括会话ID的命令，框架1920可以向TA 1911和/或UWBS 1913发送包括应用程序ID和/或应用程序的实例ID(随机ID)的命令。

在此，应用程序ID可以是用于识别应用程序的ID，并且实例ID可以是用于识别与由应用程序ID识别的应用程序相关联的会话实例的ID(例如，为每个会话分配的随机值)。例如，当为一个应用程序(应用程序实例)设置了多个会话(会话实例)时，可以通过应用程序ID和实例ID来识别对应应用程序的每个会话。作为另一个示例，当为一个应用程序仅设置一个会话时，可以通过实例ID(或应用程序ID)来识别对应的应应用程序的会话。如上所述，当使用应用程序ID和/或实例ID而不是会话ID来识别会话时，可以解决由会话ID(安全参数)被暴露给框架1920以获取RDS而引起的安全问题。在本公开中，实例ID可以称为会话实例ID。

在下文参考图21来描述图19的实施例的示例性操作。

图20示出了根据本公开的实施例的包括TEE和SE的UWB设备的操作。

参考图20，UWB设备2000可以包括TEE 2010、SE(例如，eSE)2020和框架2030。在一个实施例中，TEE 2010可以包括TA 2011、安全OS 2012和/或UWBS 2013。

图20的实施例对应于其中将TEE 2010和SE 2020一起用作安全部件的混合方法的实施例。因此，有必要为每个安全部件有效地配置UWBS 2013的操作。换言之，有必要以增加兼容性的方式来实现它。

图20的实施例的TEE 2010的配置和操作可以遵循图19的实施例的TEE 1910的配置和操作。例如，UWBS 2013可以包括在TEE区域中，并且可以分别针对TEE和REE单独定义UWBS 2013的硬件接口(例如，SPI、I2C等)。此外，UWBS 2013可以向TA 2011请求用于安全测距的RDS，并且TA 2011可以响应于该请求将RDS传输到UWBS 2013。此外，代替向UWBS 2013发送包括会话ID的命令，框架2030可以向TA 2011和/或UWBS 2013发送包括应用程序ID和/或应用程序的实例ID(随机ID)的命令以获得RDS。

在图20的实施例中，因为UWB设备2000中包括两种类型的安全部件，所以UWB设备2000可以在两种操作模式下操作。例如，UWB设备2000可以在TEE模式或SE模式下操作。在此，TEE模式可以是其中框架2030和UWBS 2013与TEE 2011一起操作的模式(即，使用TEE2011作为安全部件的模式)，并且SE模式可以是其中框架2030和UWBS 2013与SE 2020一起操作的模式(即，使用SE 2020作为安全部件的模式)。在一个实施例中，在TEE模式下，UWBS2013可以从TEE 2010(例如，TEE的TA 2011)获取安全数据(例如，RDS)，并且在SE模式下，UWBS 2013可以从SE 2020(例如，eSE的SUS小程序)获取安全数据(例如，RDS)。

在TEE模式下，如上文参考图19所述，UWBS 2013可以向TA 2011发送用于获得RDS的请求(命令)，并且TA 2011可以响应于该请求向UWBS 2013发送RDS。类似地，在SE模式下，UWBS 2013可以向eSE 2020的SUS小程序发送用于获取RDS的请求(命令)，并且eSE 2020的SUS小程序可以响应于该请求将RDS发送到UWBS 2013。如上所述，在两种模式下，UWBS 2013可以作为发起RDS获取过程的发起者来操作。换言之，不管安全部件的类型如何，UWBS 2013都可以执行相同的作用和操作以获得RDS。例如，UWBS 2013可以将用于获得RDS的相同命令传输到安全部件TEE(TA)或SE。因此，具有UWBS芯片设计容易的优点。

另外，针对UWBS 2013的框架2030的命令可以根据操作模式而不同。例如，在TEE模式下，框架2030可以将包括应用程序ID和/或实例ID的命令传输到UWBS 2013和/或TA2011，并且在SE模式下，框架2013可以将包括会话ID的命令传输到UWBS 2013。

因此，在其中TEE 2010和SE 2020一起使用的混合方法的情况下，具有高兼容性的实施例1(其中UWBS从安全部件TA拉取RDS的实施例)具有芯片设计方面的优势。因此，在混合情况下，实施例1的方法可能比稍后描述的实施例2的方法更有优势。

图21示出了根据本公开的实施例的其中第一UWB设备执行与第二UWB设备的安全测距的方法。

在图21的实施例中，第一UWB设备2100a可以是图18的UWB设备，并且第二UWB设备2100b可以是与第一UWB设备2100a执行安全测距的设备。如图所示，第一UWB设备2100a可以包括包含UWBS 2113a、安全OS 2112a和TA 2111a的TEE 2110a、以及框架2120a。

在图21的实施例中，第一UWB设备2100a对应于根据上文参考图19描述的方案(例如，实施例1)操作的UWB设备。

参考图21，在操作2101中，第二UWB设备2100b可以向第一UWB设备2100a发送用于选择由对象ID(OID)识别的对象的SELECT命令。在一个实施例中，SELECT命令可以包括OID。在一个实施例中，应用程序可以具有包括根级GDF和至少一个ADF的数据结构。在这种情况下，对象可以是包括在应用程序中的至少一个ADF之一。在一个实施例中，ADF可以用于生成/存储/传输RDS。

在操作2102中，第一UWB设备2100a的框架2120a可以识别与由OID识别的对象相关联的应用程序(例如，包括由OID识别的ADF的应用程序)，并且可以将应用程序ID和/或应用程序的实例ID(随机ID)发送到TA 2111a。如上所述，应用程序ID可以是用于识别应用程序的ID，并且实例ID可以是用于识别与由应用程序ID识别的应用程序相关联的会话实例的ID(例如，为每个会话分配的随机值)。例如，当针对一个应用程序(应用程序实例)设置了多个会话(会话实例)时，可以通过应用程序ID和实例ID来识别对应应用程序的每个会话。作为另一个示例，当针对一个应用程序仅设置一个会话时，可以通过实例ID(或应用程序ID)来识别对应应用程序的会话。如上所述，当使用应用程序ID和/或实例ID而不是会话ID来识别会话时，可以解决由会话ID(安全参数)被暴露给框架以获取RDS而引起的安全问题。在本公开中，实例ID可以称为会话实例ID。

在操作2103中，第一UWB设备2100a和第二UWB设备2100b可以建立安全信道。可以在第一UWB设备2100a的TA 2111a与第二UWB设备2100b的安全部件(例如，TA或SUS小程序)之间建立安全信道。在一个实施例中，安全信道可以通过诸如BLE的OOB来建立。通过该安全信道，可以交换UWB参数。

在操作2104中，TA 2111a可以基于交换的UWB参数来生成/准备用于安全测距的RDS。

在操作2105中，TA 2111a可以将指示RDS准备就绪的通知传输到框架2120a。

在操作2106中，框架2120a可以向UWBS 2113a传输用于从TA 2111a获取RDS的PULL命令。在一个实施例中，框架2120a可以将PULL命令连同应用程序ID和/或实例ID一起发送。例如，框架2120a可以发送包括应用程序ID和/或实例ID的PULL命令。

在操作2107中，UWBS 2113a可以向TA 2111a发送SELECT命令，并且TA 2111a可以将与SELECT命令相对应的SELECT响应发送到UWBS 2113a。在一个实施例中，SELECT命令可以包括关于TA 2111a的识别信息(例如，UUID)。由此，可以选择用于搜索RDS的TA 2111a。

在操作2108中，UWBS 2113a可以向TA 2111a发送用于从TA 2111a获得随机质询的第一认证命令(一般认证GENERAL AUTHENTICATE(Part 1/2：GET RANDOM))，并且TA 2111a可以将对应于第一认证命令的响应发送到UWBS 2113a。此外，在操作2109中，响应于随机质询，UWBS 2113a可以将用于与TA 2111a建立安全信道的第二认证命令(一般认证GENERALAUTHENTICATE(Part 1 2/2：Mutual Authentication))连同加密质询一起发送到TA2111a，并且TA 2111a可以向UWBS 2113a发送对应于第二认证命令的响应。通过操作2108至操作2109，可以在UWBS 2113a与TA2111a之间建立安全信道。

在操作2110中，UWBS 2113a可以向TA 2111a发送用于获得RDS的GET命令(GETURSK)，并且TA 2111a可以向UWBS 2113a发送与GET命令相对应的响应。在一个实施例中，GET命令可以包括用于识别RDS的会话ID(UWB会话ID)，并且响应可以包括与会话ID相对应的RDS数据(例如，测距会话密钥)。因此，UWBS可以获得RDS数据。

在操作2111中，UWBS 2113a可以将指示UWBS 2113a正常获得RDS数据的通知传输到框架2120a。在一个实施例中，可以响应于操作2106的PULL命令来发送该通知。

在操作2112中，UWBS 2113a可以使用获得的RDS数据与第二UWB设备2100b的UWBS执行安全测距。例如，UWBS 2113a可以使用STS与第二UWB设备2100b的UWBS执行安全测距，该STS使用RDS的测距会话密钥生成。

如上所述，当UWB设备根据实施例1操作时，可以在不考虑安全部件的情况下设计UWBS，从而有助于UWBS芯片组的设计。然而，难以利用TA现有的API，并且需要建立针对包括UWBS与安全OA之间的路径的UWBS与TA之间的整个路径的安全信道。

上述每个操作举例说明了由每个部件执行的特定操作，并且操作的顺序不限于上述顺序。例如，每个操作可以以与描述的顺序不同的顺序来执行。

在下文中，参考图22至图23来示例性地描述与着眼于兼容性的实施例1不同的实施例(实施例2)。实施例2例如可以是效率导向的实施例。

实施例2：其中TA向UWBS推送RDS的实施例(例如，其中TA作为发起传递(获取)RDS的过程的发起者来操作并且UWBS作为响应于此的响应者操作的实施例)

在下文中，参考图22至图23示例性地描述实施例2。

图22示出了根据本公开的另一实施例的包括TEE的UWB设备的操作。

图22的UWB设备可以是例如图18的UWB设备。

参考图22，UWB设备2200可以包括TEE 2210和框架2220。在一个实施例中，TEE2210可以包括TA 2211、安全OS 2212和/或UWBS 2213。在图22的实施例中，对于TA 2211(或安全OS 2212)而言，包括在TEE区域中的UWBS 2213用作一个外部设备(外围设备)。因此，不同于图19的实施例，在图22的实施例中，TA 2211可以以使用TEE核心API将RDS直接推送到UWBS 2213的方式来操作。换言之，无关乎UWBS 2213的请求，TA 2211可以将RDS发送到UWBS2213。因此，它具有易于实施的优点。换言之，实施例2在TA的运行效率方面比实施例1更有优势。

此外，在图22的实施例中，由于在TA 2211与安全OA 2212之间通过预定义的TEE核心API进行安全通信，因此只需要配置安全OA 2212与UWBS 2213之间路径的安全信道，而不需要配置整个路径来进行RDS传输。

此外，在图22的实施例中，可以分别针对TEE和REE单独定义UWBS 2213的硬件接口(例如，SPI、I2C等)。在这种情况下，根据需要的安全级别，特定过程(处理)可以被灵活配置为使用用于TEE的接口或用于REE的接口。例如，用于安全测距的RDS相关处理可以被配置为通过用于TEE的接口来执行，并且例如用于一般测距的处理可以被设置为通过用于REE的接口来执行。

此外，在图22的实施例中，代替向UWBS 2213发送包括会话ID的命令，框架可以向TA 2211和/或UWBS 2213发送包括应用程序ID和/或应用程序的实例ID(随机ID)的命令。

在此，应用程序ID可以是用于识别应用程序的ID，并且实例ID可以是用于识别与由应用程序ID识别的应用程序相关联的会话实例的ID(例如，为应用程序的每个会话分配的随机值)。例如，当针对一个应用程序(应用程序实例)设置了多个会话(会话实例)时，可以通过应用程序ID和实例ID来识别对应应用程序的每个会话。作为另一个示例，当针对一个应用程序仅设置一个会话时，可以通过实例ID(或应用程序ID)来识别对应应用程序的会话。如上所述，当使用应用程序ID和/或实例ID而不是会话ID来识别会话时，可以解决由会话ID(安全参数)被暴露给框架以获取RDS而引起的安全问题。在本公开中，实例ID可以称为会话实例ID。

然而，在图22的实施例(实施例2)的情况下，当SE(eSE)与TEE 2210一起使用时，应当分开实现用于TEE 2210的UWBS 2213的操作和用于SE的UWBS 2213的操作，并且因此，与图19的实施例(实施例1)相比，在芯片设计方面并不容易。因此，实施例2在仅使用TEE作为安全部件的情况下可能更有利。

在下文参考图23来描述图22的实施例的示例性操作。

图23示出了根据本公开的另一实施例的其中第一UWB设备执行与第二UWB设备的安全测距的方法。

在图23的实施例中，第一UWB设备2300a可以是图18的UWB设备，并且第二UWB设备2300b可以是与第一UWB设备2300a执行安全测距的设备。如图所示，第一UWB设备2300a可以包括包含UWBS 2313a、安全OS 2312a和TA 2311a的TEE 2310a、以及框架2320a。

在图23的实施例中，第一UWB设备2300a对应于根据上文参考图22描述的方案(例如，实施例2)操作的UWB设备。

参考图23，在操作2301中，第二UWB设备2300b可以向第一UWB设备2300a发送用于选择由对象ID(OID)识别的对象的SELECT命令。在一个实施例中，SELECT命令可以包括OID。在一个实施例中，应用程序可以具有包括根级GDF和至少一个ADF的数据结构。在这种情况下，对象可以是至少一个ADF之一。在一个实施例中，ADF可以用于生成/存储/传输RDS。

在操作2302中，第一UWB设备2300a的框架2320a可以识别与由OID识别的对象相关联的应用程序(例如，包括由OID识别的ADF的应用程序)，并且可以将应用程序ID和/或实例ID(随机ID)发送到TA 2311a。

在此，应用程序ID可以是用于识别应用程序的ID，并且实例ID可以是用于识别与由应用程序ID识别的应用程序相关联的会话实例的ID(例如，为每个会话分配的随机值)。例如，当针对一个应用程序(应用程序实例)设置了多个会话(会话实例)时，可以通过应用程序ID和实例ID来识别对应应用程序的每个会话。作为另一个示例，当针对一个应用程序仅设置一个会话时，可以通过实例ID(或应用程序ID)来识别对应应用程序的会话。如上所述，当使用应用程序ID和/或实例ID而不是会话ID来识别会话时，可以解决由会话ID(安全参数)被暴露给框架以获取RDS而引起的安全问题。在本公开中，实例ID可以称为会话实例ID。

在操作2203中，第一UWB设备2300a和第二UWB设备2300b可以建立安全信道。可以在第一UWB设备2300a的TA 2311a与第二UWB设备2300b的安全部件(例如，TA或SUS小程序)之间建立安全信道。在一个实施例中，安全信道可以通过诸如BLE的OOB来建立。通过该安全信道，可以交换UWB参数。

在操作2304中，TA 2311a可以基于交换的UWB参数来生成用于安全测距的RDS。

在操作2305中，TA 2311a可以将指示RDS准备就绪的通知传输到框架2320a。

在操作2306中，框架2320a可以向TA 2311a发送用于将RDS发送到UWBS的PUSH命令(即，用于TA将RDS推送到UWBS的PUSH命令)。在一个实施例中，框架2320a可以将PUSH命令连同应用程序ID和实例ID一起发送。例如，框架2320a可以发送包括应用程序ID和实例ID的PUSH命令。

在操作2307中，TA 2311a可以向安全OS 2312a发送用于建立安全OS 2312a与UWBS2313a之间的安全信道的请求。由于TEE 2310a在TA 2311a与安全OS 2312a之间处于安全状态，因此有必要在安全OS 2312a与UWBS 2313a之间建立安全信道，以便将在TA 2311a中生成的RDS安全地传输到UWBS 2313a。在下文中，通过操作2308至操作2312来描述用于在安全OS 2312a与UWBS 2313a之间建立安全信道的过程。

在操作2308中，安全OS 2312a可以生成随机值p并将生成的随机值p发送到UWBS2313a。在操作2309中，UWBS 2313a可以基于随机值p生成会话密钥K(例如，用于保护消息的会话密钥)。例如，UWBS 2313a可以基于接收到的随机值p和/或由UWBS 2313a生成的随机值q来生成会话密钥K。此外，UWBS 2313a可以基于会话密钥K生成加密数据。

在操作2310中，UWBS 2313a可以将生成的密码和/或随机值q发送到安全OS2312a。在操作2311中，安全OS 2312a可以基于随机值q生成会话密钥K。例如，安全OS 2312a可以基于接收到的随机值q和/或由安全OS 2312a生成的随机值p来生成会话密钥K。另外，安全OS 2312a可以基于会话密钥K生成加密数据(密码)。

在操作2312中，安全OS 2312a可以将生成的密码发送到UWBS 2313a。因此，可以在安全OS 2312a与UWBS 2313a之间共享相同的会话密钥K，并且可以使用会话密钥K来保护后续操作。通过操作2308至操作2312，可以在UWBS 2313a与安全OS 2312a之间建立安全信道。

在操作2313中，安全OS 2312a可以向TA 2311a发送指示在UWBS 2313a与安全OS2312a之间建立了安全信道的通知OK或者指示在UWBS 2313a与安全OS 2312a之间未建立安全信道的通知NOK。在一个实施例中，可以响应于操作2307中的请求来发送该通知。

在操作2314中，当建立了UWBS 2313a与安全OS 2312a之间的安全信道时，TA2311a可以通过安全信道将RDS发送到UWBS 2313a。例如，TA 2311a可以使用会话密钥K通过安全OS 2312a将RDS发送到UWBS 2313a。例如，TA 2311a可以使用会话密钥K加密RDS并且将加密的RDS传输到UWBS 2313a。

在操作2315中，UWBS 2313a可以使用获得的RDS数据与第二UWB设备2300b的UWBS执行安全测距。例如，UWBS 2313a可以使用STS与第二UWB设备2300b的UWBS执行安全测距，该STS使用RDS的测距会话密钥生成。

上述每个操作举例说明了由每个部件执行的特定操作，并且操作的顺序不限于上述顺序。例如，每个操作可以以与描述的顺序不同的顺序来执行。

图24示出了根据本公开的实施例的UWB设备的配置。

图24的UWB设备可以是图18的UWB设备的示例。

参考图24，UWB设备2400可以包括TEE 2410、框架2420和至少一个应用程序(UWB启用应用程序)2430。至少一个应用程序2430位于TEE外部并且可以与作为TEE内部的应用程序的TA 2411区分开。TEE外的应用程序2430的安全性低于TA 2411。在本公开中，框架2420可以称为FiRa框架，应用程序2430可以称为FiRa应用程序，并且TA 2411可以称为FiRa TA。

在一个实施例中，TEE 2410可以包括至少一个TA 2411、安全OS 2412和/或UWBS2413。TA 2411和安全OS 2412可以通过TEE核心API进行通信，并且TA 2411和TEE外部的另一部件(例如，应用程序2430)可以通过TEE客户端API进行通信。

在一个实施例中，TA 2411可以包括至少一个ADF。ADF可以由OID识别。例如，如图所示，TA 2411可以包括由OID#1识别的ADF和由OID#2识别的ADF。在这种情况下，每个ADF可以包括对应的应用程序的应用程序证书(AppCert)、应用程序ID(AppID)、实例ID和/或安全信道密钥参数(SC Key Params)(例如，安全信道密钥ID)。

在一个实施例中，框架2420可以包括存储在每个ADF中的应用程序证书(AppCert)、应用程序ID(AppID)、实例ID和/或安全信道密钥参数(SC Key Params)(例如，SC Key ID)中的至少一个。因此，框架2420可以识别从外部UWB设备传输的消息并将其连接到特定的TA 2411。例如，当从外部UWB设备调用特定OID时，框架2420可以识别它并且将APPID和/或与OID相关联的应用程序的实例ID传输到TA 2411，从而允许TA 2411识别对应应用程序的会话。在这种情况下，根据预设方法，TA 2411可以响应于UWBS 2413的请求将与对应会话相关联的RDS传输到UWBS 2413，或者无关乎UWBS 2413的请求而将与对应会话相关联的RDS推送给UWBS 2413。

图25是示出了根据本公开的实施例的UWB设备的方法的流程图。

在图25的实施例中，UWB设备可以是图18的UWB设备或图24的UWB设备。图25的UWB设备的操作可以是根据参考图19至图21描述的实施例1的操作。

参考图25，UWB子系统可以从框架接收从安全应用程序TA获取用于安全测距的测距数据集RDS的命令(PULL命令)(2510)。

UWB子系统可以基于命令与安全应用程序建立安全信道(2520)。用于在UWB子系统与安全应用程序之间建立安全信道的过程可以参考图21来描述。

UWB子系统可以通过设置的安全信道从安全应用程序接收RDS(2530)。在一个实施例中，安全应用程序可以响应于UWB子系统的请求来传输RDS。RDS传输过程可以参考图9的描述。

在一个实施例中，UWB子系统和安全应用程序可以包括在TEE区域中，并且RDS可以包括用于保护UWB测距会话的测距会话密钥。

在实施例中，PULL命令可以包括应用程序的应用程序ID或与由应用程序配置的至少一个会话之一相关联的实例ID中的至少一个。

在一个实施例中，可以为UWB子系统配置用于与TEE区域中的部件通信的第一接口和用于与TEE区域之外的部件通信的第二接口。

在一个实施例中，框架可以包括在TEE区域之外。

在一个实施例中，UWB子系统可以通过使用包括在RDS中的测距会话密钥与另一个UWB设备的UWB子系统执行安全测距。

图26是示出了根据本公开的另一实施例的UWB设备的方法的流程图。

在图26的实施例中，UWB设备可以是图18的UWB设备或图24的UWB设备。图26的UWB设备的操作可以是根据参考图19至图21描述的实施例1的操作。

参考图26，安全应用程序TA可以从框架接收将用于安全测距的测距数据集RDS传输到UWB子系统的命令(2610)。

安全应用程序可以基于命令向安全OS发送用于建立安全应用程序的安全OS与UWB子系统之间的安全信道的请求(2620)。安全OS与UWB子系统之间的安全信道建立过程可以参考图23来描述。

安全应用程序可以通过设置的安全信道将RDS传输到UWB子系统(2630)。

图27是示出了根据本公开的实施例的电子设备的结构的视图。

在图27的实施例中，电子设备可以对应于图18的UWB设备，或者可以是包括图18的UWB设备的电子设备，或者包括在图18的UWB设备的一些部件中的电子设备。

参考图27，电子设备可以包括收发器2710、控制器2720和存储单元2730。在本公开中，控制器可以被定义为电路或专用集成电路或至少一个处理器。

收发器2710可以向另一实体发送信号/从另一实体接收信号。收发器2710可以发送/接收用于UWB测距的数据。

控制器2720可以控制根据实施例的电子设备的整体操作。例如，控制器2720可以控制块间信号流以根据上述流程图执行操作。具体地，控制器2720可以控制以上参考图13至图26描述的电子设备的操作。

存储单元2730可以存储经由收发器2710发送/接收的信息和通过控制器2720生成的信息中的至少一者。例如，存储单元2730可以存储参考图13至图26描述的安全测距所需的信息和数据。在本公开的上述具体实施例中，包括在本公开中的部件根据所呈现的具体实施例以单数或复数形式表示。然而，为了便于描述，单数或复数形式被选择为适合于所提出的上下文，而本公开不限于单数或复数部件。如本文所使用的，单数形式“一(a)”、“一(an)”和“该(the)”也旨在包括复数形式，除非上下文另有明确指示。

尽管上文已经描述了本发明的具体实施例，但在不脱离本发明的范围的情况下，可以对本发明作出各种改变。因此，本公开的范围不应限于上述实施例，而是应由所附权利要求以及其等效物限定。

Claims (15)

1.一种由电子设备执行安全测距的方法，所述方法包括：

向安全部件发送用于配置用于所述安全测距的测距数据集的请求；以及

向所述安全部件发送用于将所述测距数据集传输到超宽带UWB子系统的请求，

其中，所述测距数据集是使用在所述安全部件与所述UWB子系统之间建立的安全信道从所述安全部件传输到所述UWB子系统的。

2.如权利要求1所述的方法，其中，

发送用于配置所述测距数据集的请求包括：调用框架应用程序编程接口API以请求所述安全部件配置所述测距数据集，其中，所述框架API包括用于识别调用所述框架API的应用程序的应用程序ID。

3.如权利要求1所述的方法，其中，发送用于将所述测距数据集传输到UWB子系统的请求包括：调用框架API以请求所述安全部件将所述测距数据集传输到所述UWB子系统，其中，所述框架API包括用于识别调用所述框架API的应用程序的应用程序ID。

4.如权利要求1所述的方法，其中，发送用于将所述测距数据集传输到UWB子系统的请求包括：从应用程序将用于从所述安全部件获得所述测距数据集的命令传输到所述UWB子系统。

5.如权利要求1所述的方法，其中，所述测距数据集包括用于与所述安全测距相关联的UWB会话的会话ID信息和用于保护所述UWB会话的会话密钥信息中的至少一者。

6.如权利要求1所述的方法，还包括：由框架向所述UWB子系统发送用于启动所述安全测距的命令，其中，用于启动所述安全测距的命令包括用于识别与所述安全测距相关联的应用程序的应用程序ID。

7.如权利要求1所述的方法，其中，所述安全部件与所述UWB子系统之间的安全信道是基于非对称密钥的安全信道。

8.如权利要求1所述的方法，其中，所述安全部件是可信执行环境TEE或保险箱。

9.一种执行安全测距的电子设备，包括：

存储器；以及

处理器，所述处理器连接到所述存储器，所述处理器被配置为：

向安全部件发送用于配置用于所述安全测距的测距数据集的请求；以及

向所述安全部件发送用于将所述测距数据集传输到超宽带UWB子系统的请求，

其中，所述测距数据集是使用通过所述框架在所述安全部件与所述UWB子系统之间建立的安全信道从所述安全部件传输到所述UWB子系统的。

10.如权利要求9所述的电子设备，其中，发送用于配置所述测距数据集的请求包括：调用框架应用程序编程接口API以请求所述安全部件配置所述测距数据集，以及其中，所述框架API包括用于识别调用所述框架API的应用程序的应用程序ID。

11.如权利要求9所述的电子设备，其中，发送用于将所述测距数据集传输到所述UWB子系统的请求包括：调用所述框架API以请求所述安全部件将所述测距数据集传输到所述UWB子系统，其中，所述框架API包括用于识别调用所述框架API的应用程序的应用程序ID。

12.如权利要求9所述的电子设备，其中，所述测距数据集包括用于与所述安全测距相关联的UWB会话的会话ID信息和用于保护所述UWB会话的会话密钥信息中的至少一者。

13.如权利要求9所述的电子设备，其中，所述处理器还被配置为向所述UWB子系统发送用于启动所述安全测距的命令，以及

其中，用于启动所述安全测距的命令包括用于识别与所述安全测距相关联的应用程序的应用程序ID。

14.如权利要求9所述的电子设备，其中，所述安全部件与所述UWB子系统之间的所述安全信道是基于非对称密钥的安全信道。

15.如权利要求9所述的电子设备，其中，所述安全部件是可信执行环境TEE或保险箱。