KR20220104652A - Method and apparatus for secure ranging based on ultra wide band - Google Patents

Abstract

According to the present invention, disclosed is a method for UWB security ranging. According to an embodiment of the present invention, a method of an electronic device comprises the following steps of: transmitting a request for setting a ranging data set for security ranging to a security component; and transmitting a request for transferring the ranging data set to a UWB sub-system to the security component. Here, the ranging data set may be transferred from the security component to the UWB sub-system by using a security channel set between the security component and the UWB sub-system through a framework.

Description

Method and apparatus for UWB-based security ranging {METHOD AND APPARATUS FOR SECURE RANGING BASED ON ULTRA WIDE BAND}

The present disclosure relates to UWB communication, and more particularly, to a method and apparatus for UWB-based secure ranging.

The Internet is evolving from a human-centered connection network where humans create and consume information, to an Internet of Things (IoT) network that exchanges and processes information between distributed components such as objects. Internet of Everything (IoE) technology, which combines big data processing technology through connection with cloud servers, etc. with IoT technology, is also emerging. In order to implement the IoT, technology elements such as sensing technology, wired/wireless communication and network infrastructure, service interface technology, and security technology are required. Recently, technologies such as a sensor network, Machine to Machine (M2M), and MTC (Machine Type Communication) for connection between objects are being studied.

In the IoT environment, an intelligent IT (Internet Technology) service that collects and analyzes data generated from connected objects and creates new values in human life can be provided. The IoT is a smart home, smart building, smart city, smart car or connected car, smart grid, health care, smart home appliance, advanced medical service, etc. can be applied in the field of

As various services can be provided with the development of wireless communication systems, a method for effectively providing these services is required. For example, a ranging technique for measuring a distance between electronic devices using Ultra Wide Band (UWB) may be used.

The present disclosure provides a method of configuring a security component and a framework for simple and efficient UWB-based security ranging. The present disclosure provides a method for a configured security component to securely deliver a session key for secure ranging to a UWB subsystem.

The present disclosure provides a method for efficiently and safely obtaining security data from a security application by a UWB subsystem included in a TEE area together with a security application.

According to an aspect of the present disclosure, in a method of an electronic device for performing secure ranging, a framework of the electronic device transmits a request for setting a ranging data set for the secure ranging to a secure component. sending action; and sending, by the framework, a request to the security component to transmit the ranging data set to the UWB subsystem, wherein the ranging data set is transmitted to the security component and the UWB sub via the framework. It may be transmitted from the secure component to the UWB subsystem using a secure channel established between the systems.

According to another aspect of the present disclosure, an electronic device for performing secure ranging includes: a memory; and a control unit connected to the memory, wherein the control unit includes: the framework of the electronic device transmits a request for setting a ranging data set for the secure ranging to a security component, wherein the framework is configured to: and send a request to the secure component to transmit a ranging data set to the UWB subsystem, wherein the ranging data set is configured to use a secure channel established between the secure component and the UWB subsystem through the framework. from the security component to the UWB subsystem.

According to various embodiments of the present disclosure, in a method of a UWB device for performing secure ranging, the UWB subsystem of the UWB device receives a ranging data set (RDS) for the secure ranging from a security application of the UWB device. receiving a command to fetch from the framework; establishing, by the UWB subsystem, a secure channel with the secure application based on the command; and receiving, by the UWB subsystem, the RDS from the security application through the established secure channel, wherein the UWB subsystem and the security application are included in a Trusted Execution Environment (TEE) area, the RDS comprising: It may include a ranging session key used to secure a UWB ranging session.

According to various embodiments of the present disclosure, in the method of the UWB device for performing secure ranging, the security application of the UWB device transmits the ranging data set (RDS) for the secure ranging to the UWB subsystem of the UWB device. receiving a command to forward from the framework; sending, by the secure application, a request for establishing a secure channel between the secure OS of the secure application and the UWB subsystem to the secure OS based on the command; and transmitting, by the security application, the RDS to the UWB subsystem through the established secure channel, wherein the UWB subsystem and the security application are included in a Trusted Execution Environment (TEE) area, the RDS comprising: It may include a ranging session key used to secure a UWB ranging session.

In an embodiment, the command may include at least one of an application ID of an application or an instance ID associated with one of at least one session established by the application.

As an embodiment, a first interface for communicating with a component within the TEE area and a second interface for communicating with a component outside the TEE area may be configured for the UWB subsystem.

In an embodiment, the framework may be included in addition to the TEE area.

As an embodiment, the UWB subsystem may perform secure ranging with the UWB subsystem of another UWB device using the ranging session key included in the RDS.

According to the configuration of the security component and framework of the present disclosure, it is possible to perform simple and efficient UWB-based security ranging. According to a method in which the security component of the present disclosure delivers the session key for secure ranging to the UWB subsystem, the session key may be securely transferred.

According to the method according to the embodiment of the present disclosure, the UWB subsystem included in the TEE area together with the security application may efficiently and safely obtain security data from the security application.

1 illustrates an exemplary layer configuration of an electronic device supporting a UWB-based service.
2A illustrates an exemplary configuration of a communication system including an electronic device supporting a UWB-based service.
2B illustrates an exemplary configuration of a communication system including an electronic device supporting a UWB-based payment service.
3 shows an exemplary configuration of a framework included in an electronic device supporting a UWB-based service.
4 illustrates an exemplary operation of a communication system for performing secure ranging using a first secure component according to an exemplary embodiment of the present disclosure.
5 illustrates an exemplary configuration and operation of an electronic device that performs secure ranging using a first secure component according to an exemplary embodiment of the present disclosure.
6 illustrates an exemplary configuration and operation of an electronic device that performs secure ranging using a second secure component according to an exemplary embodiment of the present disclosure.
7A illustrates a method for an electronic device to establish a secure channel between a first secure component and UWBS according to an exemplary embodiment of the present disclosure.
7B illustrates a method for an electronic device to establish a secure channel between a second secure component and UWBS according to an exemplary embodiment of the present disclosure.
8 is a flowchart of a method for providing an RDS by an electronic device including a second security component according to an exemplary embodiment of the present disclosure.
9A illustrates a procedure for establishing a secure channel between UWBS and a security component using a symmetric encryption method (Symmetric method) according to an exemplary embodiment of the present disclosure.
9B illustrates an example of a procedure for establishing a secure channel between UWBS and a secure component using an asymmetric encryption method (Asymmetric method) according to an exemplary embodiment of the present disclosure.
9C illustrates another example of a procedure for establishing a secure channel between UWBS and a secure component using an asymmetric scheme according to an exemplary embodiment of the present disclosure.
9D illustrates a procedure for UWBS to deliver an RDS to a secure component through a secure channel between the UWBS and the secure component according to an exemplary embodiment of the present disclosure.
10A illustrates a key provisioning method for an electronic device including a first security component according to an exemplary embodiment of the present disclosure.
10B illustrates a key provisioning method for an electronic device including a second security component according to an embodiment of the present disclosure.
11 illustrates an attestation procedure for key provisioning for an electronic device including a second security component according to an embodiment of the present disclosure.
12 shows an exemplary configuration of an electronic device according to an exemplary embodiment of the present disclosure.
13 is a flowchart illustrating a method of an electronic device according to an embodiment of the present disclosure.
14 is a diagram illustrating a structure of a first electronic device according to an embodiment of the present disclosure.
15 is a diagram illustrating a structure of a second electronic device according to an embodiment of the present disclosure.
16 shows an exemplary configuration of a UWB device including an SE.
17 shows the operation of a UWB device including an SE.
18 illustrates an exemplary configuration of a UWB device including a TEE according to an embodiment of the present disclosure.
19 illustrates an operation of a UWB device including a TEE according to an embodiment of the present disclosure.
20 illustrates an operation of a UWB device including a TEE and an SE according to an embodiment of the present disclosure.
21 illustrates a method for a first UWB device to perform security ranging with a second UWB device according to an embodiment of the present disclosure.
22 illustrates an operation of a UWB device including a TEE according to another embodiment of the present disclosure.
23 illustrates a method for a first UWB device to perform security ranging with a second UWB device according to another embodiment of the present disclosure.
24 shows the configuration of a UWB device according to an embodiment of the present disclosure.
25 is a flowchart illustrating a method of a UWB device according to an embodiment of the present disclosure.
26 is a flowchart illustrating a method of a UWB device according to another embodiment of the present disclosure.
27 is a diagram illustrating a structure of an electronic device according to an embodiment of the present disclosure.

Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings.

In describing the embodiments, descriptions of technical contents that are well known in the technical field to which the present disclosure pertains and are not directly related to the present disclosure will be omitted. This is to more clearly convey the gist of the present disclosure without obscuring the gist of the present disclosure by omitting unnecessary description.

For the same reason, some components are exaggerated, omitted, or schematically illustrated in the accompanying drawings. In addition, the size of each component does not fully reflect the actual size. In each figure, the same or corresponding elements are assigned the same reference numerals.

Advantages and features of the present disclosure, and a method for achieving them will become apparent with reference to the embodiments described below in detail in conjunction with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below, but may be implemented in various different forms, and only the embodiments of the present disclosure make the present disclosure complete, and common knowledge in the technical field to which the present disclosure belongs It is provided to fully inform those who have the scope of the disclosure, and the present disclosure is only defined by the scope of the claims. Like reference numerals refer to like elements throughout.

At this time, it will be understood that each block of the flowchart diagrams and combinations of the flowchart diagrams may be performed by computer program instructions. These computer program instructions may be embodied in a processor of a general purpose computer, special purpose computer, or other programmable data processing equipment, such that the instructions performed by the processor of the computer or other programmable data processing equipment are not described in the flowchart block(s). It creates a means to perform functions. These computer program instructions may also be stored in a computer-usable or computer-readable memory that may direct a computer or other programmable data processing equipment to implement a function in a particular manner, and thus the computer-usable or computer-readable memory. It may also be possible for the instructions stored in the flowchart block(s) to produce an article of manufacture containing instruction means for performing the function described in the flowchart block(s). The computer program instructions may also be mounted on a computer or other programmable data processing equipment, such that a series of operational steps are performed on the computer or other programmable data processing equipment to create a computer-executed process to create a computer or other programmable data processing equipment. It may also be possible for instructions to perform the processing equipment to provide steps for performing the functions described in the flowchart block(s).

Additionally, each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s). It should also be noted that in some alternative implementations it is also possible for the functions recited in the blocks to occur out of order. For example, two blocks shown one after another may in fact be performed substantially simultaneously, or it may be possible that the blocks are sometimes performed in a reverse order according to a corresponding function.

In this case, the term '~ unit' used in this embodiment means software or hardware components such as FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit), and '~ unit' performs certain roles. do. However, '-part' is not limited to software or hardware. '~unit' may be configured to reside on an addressable storage medium or may be configured to refresh one or more processors. Accordingly, according to some embodiments, '~ part' refers to components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, and programs. Includes procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. The functions provided in the components and '~ units' may be combined into a smaller number of components and '~ units' or further separated into additional components and '~ units'. In addition, components and '~ units' may be implemented to play one or more CPUs in a device or secure multimedia card. Also, according to some embodiments, '~ unit' may include one or more processors.

As used herein, the term 'terminal' or 'device' refers to a mobile station (MS), user equipment (UE), user terminal (UT), wireless terminal, access terminal (AT), terminal, subscriber unit. may be referred to as a (Subscriber Unit), Subscriber Station (SS), wireless device, wireless communication device, Wireless Transmit/Receive Unit (WTRU), mobile node, mobile or other terms. . Various embodiments of the terminal include a cellular phone, a smart phone having a wireless communication function, a personal digital assistant (PDA) having a wireless communication function, a wireless modem, a portable computer having a wireless communication function, and a digital camera having a wireless communication function. devices, gaming devices with wireless communication capabilities, music storage and playback appliances with wireless communication capabilities, Internet appliances with wireless Internet access and browsing, as well as portable units or terminals incorporating combinations of such functions. have. In addition, the terminal may include a machine to machine (M2M) terminal and a machine type communication (MTC) terminal/device, but is not limited thereto. In this specification, the terminal may be referred to as an electronic device or simply a device.

Hereinafter, the operating principle of the present disclosure will be described in detail with reference to the accompanying drawings. In the following description of the present disclosure, if it is determined that a detailed description of a related well-known function or configuration may unnecessarily obscure the subject matter of the present disclosure, the detailed description thereof will be omitted. In addition, the terms described below are terms defined in consideration of functions in the present disclosure, which may vary according to intentions or customs of users and operators. Therefore, the definition should be made based on the content throughout this specification.

Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. Hereinafter, an embodiment of the present disclosure will be described using a communication system using UWB (eg, a UWB communication system defined by FiRa Consotium) as an example, but the embodiment of the present disclosure may also be applied to other communication systems having similar technical backgrounds or characteristics. can For example, a communication system using Bluetooth or ZigBee may be included in this. Accordingly, the embodiments of the present disclosure may be applied to other communication systems through some modifications within a range that does not significantly depart from the scope of the present disclosure as judged by a person having skilled technical knowledge.

In addition, in the description of the present disclosure, if it is determined that a detailed description of a related function or configuration may unnecessarily obscure the subject matter of the present disclosure, the detailed description thereof will be omitted. In addition, the terms described below are terms defined in consideration of functions in the present disclosure, which may vary according to intentions or customs of users and operators. Therefore, the definition should be made based on the content throughout this specification.

In general, wireless sensor network technology is largely divided into a wireless local area network (WLAN) technology and a wireless personal area network (WPAN) technology according to a recognition distance. In this case, the wireless LAN is a technology based on IEEE 802.11, and it is a technology that can connect to a backbone network within a radius of about 100 m. In addition, the wireless private network is a technology based on IEEE 802.15, and includes Bluetooth, ZigBee, and ultra wide band (UWB). A wireless network in which such a wireless network technology is implemented may include a plurality of electronic devices.

According to the definition of the Federal Communications Commission (FCC), UWB may refer to a wireless communication technology that uses a bandwidth of 500 MHz or more, or a bandwidth corresponding to a center frequency of 20% or more. UWB may mean a band itself to which UWB communication is applied. UWB enables secure and accurate ranging between devices.

The operation of the UWB-based service includes a service initiation step for initiating a UWB-based service, a key provisioning step for providing a key for security, and a discovery step for discovering a device. ), a connection step including secure channel creation and parameter exchange, and/or a UWB ranging step for measuring a location/distance between devices.

Meanwhile, depending on the embodiment, some steps may be omitted. For example, in some embodiments, the service initiation phase and the UWB ranging phase may be a mandetory phase, but the key provisioning phase, discovery phase, and connection phase may be optional phases. For another example, in another embodiment, the service initiation phase, the key provisioning phase, and the UWB ranging phase may be a mandetory phase, but the discovery phase and the connection phase may be optional phases.

Specific terms used in the following description are provided to help the understanding of the present disclosure, and the use of such specific terms may be changed to other forms without departing from the technical spirit of the present disclosure.

“Application Dedicated File (ADF)” may be, for example, a data structure capable of hosting an application or application specific data.

An "Application Protocol Data Unit (APDU)" may be a command and a response used when communicating with a Secure Element (SE) (eg, embedded SE) or an Application Data Structure.

"application specific data" may be, for example, an Applet, a proprietary applet, or an equivalent implementation in a Ranging Device.

"Controller" may be a Ranging Device that defines and controls Ranging Control Messages (RCM). In the present disclosure, the ranging device may be, for example, an Enhanced Ranging Device (ERDEV) defined in the IEEE Std 802.15.4z specification.

"Controlee" may be a Ranging Device using a ranging parameter in the RCM received from the Controller.

"Dynamic STS" may be an operation mode in which the STS is confidential and is never repeated during the ranging session. STS can be managed by Secure Component in this mode.

“Applet” may be an Applet that implements an APDU interface running on a Secure Component and is identified by a well-defined AID (Application (Applet) ID). This applet can host the data needed for secure ranging. In one embodiment, the Applet may be, for example, a FiRa Applet defined in the FIRA CONSORTIUM COMMON SERVICE & MANAGEMENT LAYER (CSML) specification.

"Ranging Device" is a Ranging Device that can communicate with other Ranging Devices using predefined profiles (eg, a set of UWB and OOB related configuration parameters used in UWB-enabled door lock service), or , it may be a Ranging Device capable of supporting a predefined UWB ranging service in order to perform a ranging session with another ranging device. In this disclosure, the Ranging Device may be referred to as a UWB Device or a UWB Ranging Device. In one embodiment, the Ranging Device may be, for example, a FiRa Device defined in the FIRA CONSORTIUM CSML specification.

"Ranging Data Set (RDS)" may be data required to establish a UWB session that needs to be protected (protected) of confidentiality (confidentiality), authenticity (authenticity) and integrity (integrity). As an embodiment, the RDS may include a UWB Session Key. As an embodiment, RDS may be used for secure ranging. For example, the RDS may be used to generate an STS for secure ranging.

"UWB-enabled Application" may be an application using Framework API for configuring OOB Connector, Secure Service, and/or UWB service for UWB session. In this disclosure, "UWB-enabled Application" may be abbreviated as an application. In one embodiment, the UWB-enabled Application may be, for example, a FiRa-enabled Application defined in the FIRA CONSORTIUM CSML specification.

"Framework" may be a collection of logical software components including OOB Connector, Secure Service, and/or UWB service. In one embodiment, the Framework may be, for example, the FiRa Framework defined in the FIRA CONSORTIUM CSML specification.

"OOB Connector" may be a software component for establishing out-of-band (OOB) communication (eg, BLE communication) between Ranging Devices. In one embodiment, the OOB Connector may be, for example, a FiRa OOB Connector defined in the FIRA CONSORTIUM CSML specification.

"Profile" may be a predefined set of UWB and OOB configuration parameters. In one embodiment, the Profile may be, for example, a FiRa Profile defined in the FIRA CONSORTIUM CSML specification.

"Profile Manager" can implement profiles available in Ranging Device. In one embodiment, the Profile Manager may be, for example, a FiRa Profile Manager defined in the FIRA CONSORTIUM CSML specification.

"Smart Ranging Device" may host one or more UWB-enabled Applications, and may be a Ranging Device that may implement a Framework, or a Ranging Device that implements a specific service application provided by a manufacturer (eg, a physical access reader). ). The Smart Ranging Device may be a Ranging Device capable of installing multiple UWB-enabled Applications in order to support a UWB ranging-based service to perform a ranging session with another ranging device or a Smart Ranging Device. In one embodiment, the Smart Ranging Device may be, for example, a FiRa Smart Device defined in the FIRA CONSORTIUM CSML specification.

"Global Dedicated File (GDF)" may be a root level of application specific data including data required to establish a USB session. The application specific data may be, for example, an Applet, a proprietary applet, or an equivalent implementation in a Ranging Device.

"Framework API" may be an API used by a UWB-enabled Application to communicate with the Framework.

“Initiator” may be a Ranging Device that initiates a ranging exchange.

"Object Identifier (OID)" may be an identifier of the ADF in the application data structure, or a unique ID that identifies a service provider (SP).

“Out-Of-Band (OOB)” may be data communication that does not use UWB as an underlying wireless technology.

A “Respondent” may be a Ranging Device that responds to an Initiator in a ranging exchange.

“Scrambled Timestamp Sequence (STS)” may be a ciphered sequence for increasing the integrity and accuracy of ranging measurement timestamps.

"Secure Channel" may be a data channel that prevents overhearing and tampering.

"Secure Component" may be, for example, a component that interfaces with UWBS for the purpose of providing RDS to UWBS when dynamic STS is used. It can also host UWB-enabled Application data.

"Secure Element (SE)" may be a tamper-resistant secure hardware component that can be used as a Secure Component in the Ranging Device.

"Secure Service" may be a component for interfacing with a Secure Component of a system, such as a Secure Element or a Trusted Execution Environment (TEE).

"Static STS" is an operation mode in which the STS is repeated during a session, and does not need to be managed by the Secure Component.

"SUS Applet" may be an Applet on a Secure Component that operates as an end point for a Secure Channel between UWBS and a Secure Component such as SE.

"UWB Service" may be an implementation-specific software component that provides access to UWBS.

"UWB Session" may be considered to be set when the Controller and Controlee(s) can start UWB ranging. The UWB Session may be a period from when the Controller and the Controlee start communication through UWB until the communication stops (stop). A UWB Session may include ranging, data transfer, and both.

“UWB Session ID” may be an ID (eg, integer) identifying a UWB Session.

"UWB Session Key" may be a key used to protect the UWB Session. In this disclosure, the UWB Session Key may be referred to as a UWB Ranging Session Key (URSK), or a session key.

“UWB Subsystem (UWBS)” may be a hardware component implementing the UWB PHY and MAC specifications. UWBS may have an interface to FiRa Framework in which UCI logical interface layer is implemented and an interface to Secure Component to search for RDS. In one embodiment, the UWB PHY and MAC specifications may be, for example, FiRa CONSORTIUM PHY and MAC specifications.

And, in describing the present disclosure, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the subject matter of the present disclosure, the detailed description thereof will be omitted.

Hereinafter, various embodiments of the present disclosure will be described with reference to the accompanying drawings.

1 illustrates an exemplary layer configuration of an electronic device supporting a UWB-based service.

The electronic device (UWB device) 100 of FIG. 1 may be, for example, a Smart Ranging Device or a Ranging Device. As an embodiment, the Smart Ranging Device or the Ranging Device may be an Enhanced Ranging Device (ERDEV) defined in IEEE 802.15.4z or a FiRa Device defined by the FiRa Consortium. In FIG. 1 , the electronic device may be referred to as a UWB device.

1 , the UWB device 100 may interact with other UWB devices through a UWB session.

Referring to FIG. 1 , the electronic device 100 includes a UWB-enabled Application Layer (UWB-enabled Application) 110, a Common Service & Management Layer (Framework) 120, and/or a UWB MAC Layer and a UWB Physical Layer. It may include a UWB subsystem (UWBS) 130 that includes. According to an embodiment, some entities may not be included in the electronic device, or additional entities (eg, a security layer) may be further included.

The electronic device 100 may implement a first interface (Interface (IF) #1) that is an interface between the UWB-enabled Application 110 and the Framework 120 , and the first interface is UWB-enabled on the electronic device 100 . Allows application 110 to use UWB capabilities of electronic device 100 in a predetermined manner. In one embodiment, the first interface may be, for example, Framework API, but is not limited thereto.

The electronic device 100 may implement a second interface (Interface (IF) #2 ) that is an interface between the Framework 110 and the UWBS 130 . In an embodiment, the second interface may be, for example, UWB Command Interface (UCI), but is not limited thereto.

The UWB-enabled Application Layer 110 is, for example, a layer of an application (eg, FiRa-enabled Application) that uses a first interface (eg, Framework API) to configure an OOB Connector, Secure Service, and UWB service for a UWB session. can be

The UWB-enabled Application 110 may trigger establishment of a UWB session by the UWBS 130 using the first interface. In addition, the UWB-enabled Application 110 may use one of the predefined profiles (profile). For example, the UWB-enabled Application 110 may use one of the profiles defined in FiRa or a custom profile. The UWB-enabled Application 110 may use the first interface to handle related events such as service discovery, ranging notifications, and/or error conditions.

The Common Service & Management Layer (Framework) 120 may define, for example, common components and procedures necessary to implement UWB secure ranging.

Framework 120 may provide access to Profiles, individual UWB settings and/or notifications. In addition, the Framework 120 may support at least one of a function for performing UWB ranging and transaction, a function for providing an interface to an application and UWBS 130 , or a function for estimating the location of the device 100 . The framework 120 may be a set of software components. As described above, the UWB-enabled Application 110 may interface with the framework 120 through a first interface, and the framework 120 may interface with the UWBS 130 through a second interface.

Meanwhile, in the present disclosure, the UWB-enabled Application 110 and/or the Framework 120 may be implemented by an application processor (AP) (or processor). Accordingly, in the present disclosure, the operation of the UWB-enabled Application 110 and/or the Framework 120 may be understood as being performed by an AP (or a processor).

The UWB MAC Layer and the UWB Physical Layer may be collectively referred to as a UWB subsystem (UWBS) 130 . The UWBS 130 may be based on, for example, the FiRa PHY and MAC specifications referring to the IEEE 802.15.4z specification.

The UWBS 130 may be a hardware component including a UWB MAC layer and a UWB physical layer. The UWBS 130 may perform UWB session management and communicate with UWBSs of other UWB devices. The UWBS 130 may interface with the Framework 120 through the second interface, and may obtain security data from the Secure Component. In an embodiment, the Framework (or application processor) 120 may transmit a command to the UWBS 130 through UCI, and the UWBS 130 may transmit a response to the command to the Framework 120 . can be forwarded to The UWBS 130 may deliver a notification to the Framework 120 through the UCI.

2A illustrates an exemplary configuration of a communication system including an electronic device supporting a UWB-based service.

Referring to FIG. 2A , the communication system 200 includes a first electronic device 210a and a second electronic device 220a.

As an embodiment, the first UWB device 210a and the second UWB device 220a may be, for example, the UWB device of FIG. 1 or an electronic device including the UWB device of FIG. 1 . For example, the first electronic device (the first UWB device) 210a may be, for example, a Smart Ranging Device or a Ranging Device, and the second electronic device (the second UWB device) 220a may be, for example, a Ranging Device or a Ranging Device. It can be a device. As an embodiment, the Smart Ranging Device or the Ranging Device may be an Enhanced Ranging Device (ERDEV) defined in IEEE 802.15.4z or a FiRa Device defined by the FiRa Consortium. In FIG. 2A , a first electronic device may be referred to as a first UWB device, and a second electronic device may be referred to as a second UWB device.

The first electronic device 210a may host, for example, one or more UWB-enabled Applications that may be installed by a user (eg, a mobile phone). It can be based on the Framework API. The second electronic device 220a does not provide the Framework API, but may use a proprietary interface to implement, for example, a specific UWB-enabled application provided only by the manufacturer. On the other hand, unlike shown, depending on the embodiment, both the first UWB device and the second UWB device may be a ranging device using the Framework API, or both the first UWB device and the second UWB device may be a ranging device using a proprietary interface. may be

The first electronic device 210a and the second electronic device 220a include UWB-enabled Application Layer (UWB-enabled Application) 211a and 221a, Frameworks 212a and 222a, and OOB component (OOB subsystem) 213a and 223a. ), Secure Component (214a, 224a) and / or UWBS (215a, 225a) may include, respectively. Depending on the embodiment, some components may be omitted or additional components may be further included.

The first electronic device 210a and the second electronic device 220a may create an OOB connection (channel) through the OOB components 213a and 223a, and establish a UWB connection (channel) through the UWBS 215a and 225a. created to communicate with each other.

Frameworks 212a and 222a may serve to provide access to profiles, individual UWB settings, and/or notifications. The frameworks 212a and 222a are a set of software components, and may include, for example, Profile Manager, OOB Connector, Secure Service, and/or UWB service.

The OOB components 213a and 223a may be hardware components including a MAC layer and/or a physical layer for OOB communication (eg, BLE communication). The OOB components 213a and 223a may communicate with OOB components of other devices. In an embodiment, the first UWB device 210a and the second UWB device 220a may create an OOB connection (channel) using the OOB components 213a and 223a, and establish a UWB session through the OOB channel. parameters can be exchanged. In this disclosure, OOB components 213a and 223a may be referred to as OOB subsystems.

Secure Component 214a , 224a may be a hardware component that interfaces with a framework and/or UWBS to provide RDS. As an embodiment, the Secure Components 214a and 224a may be SE (eg, eSE), TEE (or TA (trusted application) in TEE), or Strongbox (SB).

The UWBSs 215a and 225a may be hardware components including a UWB MAC Layer and a UWB Physical Layer. The UWBSs 215a and 225a may perform UWB session management and communicate with UWBSs of other UWB devices. In one embodiment, the first UWB device 210a and the second UWB device 220a use the parameters exchanged with each other through the UWB session established through the UWBS 215a and 225a, and the transaction of UWB ranging and service data. can be performed.

In the present disclosure, the UWB-enabled Application Layer and/or Framework may be implemented by an application processor (AP) (or processor). Accordingly, in the present disclosure, it may be understood that the operation of the UWB-enabled Application Layer and/or Framework is performed by the AP (or processor).

2B illustrates an exemplary configuration of a communication system including an electronic device supporting a UWB-based payment service.

The embodiment of FIG. 2B may be an example of the embodiment of FIG. 2A .

Referring to FIG. 2B , a communication system 200b that provides a UWB-based payment service may include a first electronic device (a first UWB device) 210b and a second electronic device (a second UWB device) 220b. have. In FIG. 2B , a first electronic device may be referred to as a first UWB device, and a second electronic device may be referred to as a second UWB device.

The first electronic device 210b may be a user's electronic device (eg, a user's mobile device) for a UWB-based payment service. The first electronic device 210b includes at least one UWB enabled Wallet Application (UWB enabled application) 211b-1 and 211b-2, a UWB enabled Wallet Framework (Framework) 212b, an OOB component 213b, and at least one security device. components 214b-1, 214b-2 and/or UWBS 215b. For a description of each component, reference may be made to the description of FIG. 2A .

Meanwhile, in the embodiment of FIG. 2B, for convenience of explanation, it is described that the UWB enabled application corresponds to the UWB enabled Wallet Application, and the Framework corresponds to the UWB enabled Wallet Framework, but the embodiment is not limited thereto, and various types of other Various UWB enabled applications and frameworks for providing services may be implemented. In FIG. 2B , the UWB enabled Wallet Application may be referred to as a UWB enabled application, and the UWB enabled Wallet Framework may be referred to as a Framework.

(1) The UWB enabled applications 211b-1 and 211b-2 may support at least one of the following features.

- Hosting an applet (payment applet) for UWB-based payment in SE (eg, eSE) or Trusted Application (Trusted Payment Application) for UWB-based payment in TEE

- When requested by the Framework, the arrangement information of anchors for estimating the position of the first electronic device and the UWB block structure (eg, ranging block structure) are provided

- Communication with the second electronic device and backend server for personalization of payment applet or Trusted Payment Application (TPA)

(2) Framework 212b may support at least one of the following features.

- Estimate the location of the first electronic device

- Implement UCI commands

- Provides a set of APIs for UWB enabled applications to access UWBS and OOB components

(3) The OOB component 213b may support the following features.

- Implement OOB connection operation (eg, BLE connection operation)

(4) The Trusted Payment Application 211b-2 may be included in the TEE, and may support at least one of the following features.

- Support TEE Client API

- Implement Trusted Application

- implement a secure channel protocol to communicate with the second electronic device in a secure manner

- Hosting payment credentials and cryptographic keys for secure channels

- Hosting sensitive information (eg card information) to support UWB-based payment services

(5) The payment applet 211b-1 may be included in the SE (eSE) and may support at least one of the following features.

- Support APDU

- implement a secure channel protocol to communicate with the second electronic device in a secure manner

- Hosting payment credentials and cryptographic keys for secure channels

- Hosting sensitive information (eg card information) to support UWB-based payment services

Each component of the first electronic device 210b may communicate with another component through a predefined interface IF. Hereinafter, each interface will be described.

- IF#1: an interface between the UWBS 215b of the first electronic device 210b and the UWBS of another electronic device (eg, the UWBS 223b of the second electronic device 220b). IF#1 may be used to exchange UWB messages and/or payment transactions.

- IF#2: an interface between the OOB component 213b of the first electronic device 210b and the OOB component of another electronic device (eg, the OOB component 222b of the second electronic device 220b). IF#2 can be used to exchange OOB messages.

- IF#3: Interface between Framework (212b) and UWBS (215b). IF#3 may be used to exchange UCI messages. For example, IF#3 may be used to exchange UCI messages for establishing a secure channel between the Trusted Payment Application 211b-2 and the UWBS 215b.

- IF#4: the interface between the UWB enabled application (211b-2) and the Trusted Payment Application (211b-2) in the TEE. IF#4 can be used to exchange TEE Commands through the TEE Client API. For example, IF#4 may be used to exchange TEE Commands for establishing a secure channel between the Trusted Payment Application 211b-2 and the UWBS 215b.

- IF#A: the interface between the UWB enabled application (211b-1, 211b-2) and the UWBS (215b). IF#A may be, for example, a SUS external API.

- IF#B: the interface between the UWB enabled application (211b-2) and the Payment Applet (214b-1) in the SE (eSE). IF#B can be used to exchange APDUs via OMAPI. For example, IF#B may be used to exchange APDUs for establishing a secure channel between the eSE and UWBS.

- IF#C: the interface between the OOB component (213b) and the Framework (212b) or UWB enabled applications (211b-1, 211b-2).

- IF#D: the interface between the UWB enabled application (211b-1, 211b-2) and the Framework (212b). IF#D may be an API (Framework API) provided by the Framework 212b.

The second electronic device 220b may be an electronic device of a business operator (eg, a point of service (PoS) terminal of retail) for a UWB-based payment service. The second electronic device 220b may include a terminal application 221b, an OOB component 222b, and/or a UWBS 223b. As an embodiment, the terminal application 221b may be a UWB enabled application.

3 shows an exemplary configuration of a framework included in an electronic device supporting a UWB-based service.

The framework 300 of FIG. 3 may be an example of the framework of FIGS. 2A and 2B . The framework 300 of FIG. 3 may be, for example, FiRa Framework defined in FIRA CONSORTIUM.

The framework 300 may be a set of logical software components. The UWB-enabled Application may interface with the framework through the framework API provided by the framework 300 .

Referring to FIG. 3 , the framework 300 may include a Profile Manager 310 , an OOB Connector 320 , a Secure Service 330 , and/or a UWB Service 340 . However, depending on the embodiment, some components may be omitted or additional components may be further included.

The Profile Manager component 310 may manage Profile(s) available on a Ranging Device (UWB device). The Profile may be a set of parameters required to establish a successful UWB session between Ranging Devices (UWB devices). For example, a profile may contain a parameter indicating which secure channel (eg OOB secure channel) is used, a UWB/OOB configuration parameter, a parameter indicating whether the use of a particular security component is mandatory, and/or a file in the ADF. It may contain parameters related to the structure. In addition, Profile Manager can abstract UWB and OOB configuration parameters from UWB-enabled applications.

The OOB Connector component 320 may be a component for establishing an OOB connection between Ranging Devices (UWB devices). The OOB Connector 320 may handle a Discovery Phase and a Connection Phase for providing a UWB-based service.

The Secure Service component 330 may play a role of interfacing with a security component such as a Secure Element (SE) or a Trusted Execution Environment (TEE). The security component may be a component that interfaces with UWBS to deliver UWB ranging data to UWBS.

The UWB Service component 340 may be a component that provides access to UWBS.

* As described above, a UWB enabled application such as a UWB enabled Wallet Application can interact with the framework to use UWBS and OOB through the API provided by the framework. In addition, the UWB enabled application may be associated with at least one security component for storing credentials (credential), encryption key (cryptographic key) and other sensitive information (sensitive information). For example, a UWB enabled application may have an eSE (or Applet in the eSE) (a first security component) and/or a TEE (or a Trusted application (TA) in the TEE) (a second security component) as a security component. .

Meanwhile, the TA in the TEE may directly or indirectly interact with the UWBS.

If the UWBS is connected to the TA through an intermediate entity (eg, Framework), the UWBS may indirectly communicate with the TA. This type of mode may be referred to as a bypass mode.

If the UWBS is physically connected to the Driver TA (Secure OS) in the TEE, the UWBS can communicate directly with the TA. This type of mode may be referred to as an attached mode. In the case of the attached mode, it may be understood that the UWBS is included in the TEE area.

<Example A>

Embodiment A corresponds to the embodiment related to the bypass mode described above. Hereinafter, Embodiment A will be exemplarily described with reference to FIGS. 4 to 15 .

4 illustrates an exemplary operation of a communication system for performing secure ranging using a first secure component according to an exemplary embodiment of the present disclosure.

In the embodiment of FIG. 4 , the first security component may be a Secure Element (eg, embedded SE (eSE)). SE is a secure security module based on the tamper resistant characteristic, but if the contractual relationship between various entities is not established, there are restrictions in installing and running the application.

The eSE refers to a fixed SE that is fixed and used in an electronic device. The eSE is usually manufactured exclusively for the manufacturer at the request of the terminal manufacturer, and may be manufactured including the operating system and framework. The eSE remotely downloads and installs an applet-type service control module, and can be used for various security services such as, for example, electronic wallet, ticketing, e-passport, and digital key.

In the present disclosure, a first security component is distinguished from a second security component that is a security component such as a TEE (or TA in the TEE) or Strongbox.

The TEE may be, for example, a S/W-centered security environment that creates a virtual separated environment based on codes supported by a specific chipset (eg, ARM-based). TEE does not have tamper resistant characteristics, but has advantages of large available memory, high speed, and low cost compared to SE. In addition, since various service providers can be used immediately within the range allowed by the mobile manufacturer, it has the advantage of lower complexity between entities compared to SE.

Strongbox may be, for example, a physical security chip based on Javacard OS. Strongbox, like TEE, also has the advantage of lower complexity between entities compared to SE.

Meanwhile, the second security component is not limited to the aforementioned TEE or Strongbox, and may be a security component having the same or similar characteristics to the TEE or Strongbox.

As will be described below, there is a difference between the case of using the first security component and the case of using the second security component in a key provisioning procedure, a procedure for transferring a session key for security ranging to UWBS, and the like.

Referring to FIG. 4 , the communication system 400 includes a first electronic device 410 , a second electronic device 420 , and/or a service provider 430 .

4 , the first electronic device (first UWB device) 410 and the second electronic device (second UWB device) 420 may be one of the electronic devices described above with reference to FIGS. 1 to 3 . For example, the first electronic device (the first UWB device) 410 may be, for example, a Smart Ranging Device, and the second electronic device (the second UWB device) 420 may be, for example, a Ranging Device or a Smart Ranging Device. can

The service provider 430 may be an entity that provides a UWB-enabled application and provides a key for secure ranging.

Referring to FIG. 4 , the first electronic device 410 includes a UWB-enabled application 411 , a framework 412 , and an OOB component 413 belonging to a non-secure world, and a secure area. It may include a Secure element (SE) (a first security component) belonging to (secure world) and a UWBS 414 . The second electronic device 420 may include an Application 421 , an OOB component 422 , and/or a UWBS 423 .

The UWB-enabled Application 411 may request UWB functions and connect to the UWBS 414 through the Framework 412 .

Framework 412 provides access to different Profiles. As illustrated in FIG. 3 , the Framework 412 may include Profile Manager, OOB Connector, Secure Service, and/or UWB Service components.

The SE (eg, eSE) may include an Applet 415 and/or a Secure UWB Service (SUS) Applet 416 . The Applet 415 may include at least one Application Dedicated File (ADF) required to safely generate a Ranging Data Set (RDS). For example, as shown, Applet 415 includes each ADF provided by each service provider (SP) (eg, ADF of SP1 (ADF(SP1)) and ADF of SP2 (ADF(SP2))). can do. The ADF may be provided by the service provider, for example, in the key provisioning phase. In addition, Applet 415 may forward the RDS to UWBS 414 via SUS Applet 416 . In one embodiment, the RDS may include a session ID and/or UWB Session Key for a specific UWB session.

The OOB component 413 is connected to the OOB connector of the Framework 412 , and may establish an OOB connection (eg, a Bluetooth low energy (BLE) connection) between Ranging Devices (UWB Devices). For example, between the first electronic device 410 and the second electronic device 420 through the OOB component 413 of the first electronic device 410 and the OOB component 422 of the second electronic device 420 . An OOB connection may be established.

UWBS 414 manages UWB hardware. The UWBS 414 may perform a UWB session with the UWBS of another ranging device (eg, the UWBS 423 of the second electronic device 420 ). The UWBS 414 is managed by the Framework 412 and may receive an RDS required for secure ranging from the SE.

Referring to FIG. 4 , in operation 1 (discovery operation), the first electronic device 410 and the second electronic device 420 may perform a service discovery procedure through the OOB component 413,422. The service discovery procedure may include a Secure Channel (SC) negotiation operation.

In operation 2 (secure channel establishment operation), the first electronic device 410 and the second electronic device 420 use a framework to securely share data between electronic devices (eg, FiRa devices) through a secure channel between devices. (eg, SC#1, SC#2) may be set. The Secure Channel may be opened through an OOB channel (connection).

In operation 3 (RDS generation/delivery operation), a UWB session key (URSK) may be exchanged between the Applet 415 and the SUS Applet 416 . For example, the UWB Ranging Session Key (URSK) of the Applet 415 may be transmitted to the SUS Applet 416 through communication with the SUS Applet 416 . Also, the session ID may be passed to the UWBS 414 via the SUS Applet 416 . To this end, a secure channel between the Applet 415 and the SUS Applet 416 and a secure channel between the SUS Applet 416 and the UWBS 414 may be established first. The UWBS 414 may acquire the corresponding RDS from the SUS Applet 416 through the established Secure Channel. The session ID and UWB session key may be generated by the Applet 415 .

In operation 4 (security ranging operation), the first electronic device 410 and the second electronic device 420 may perform a secure ranging procedure through the UWBSs 414 and 423 . The obtained URSK may be used by UWBS for secure ranging.

5 illustrates an exemplary configuration and operation of an electronic device that performs secure ranging using a first secure component according to an exemplary embodiment of the present disclosure.

In the embodiment of FIG. 5 , the electronic device (UWB device) 510 may be one of the electronic devices described above with reference to FIGS. 1 to 3 . For example, the electronic device 510 may be, for example, a Smart Ranging Device, and the first security component may be a Secure Element (eg, eSE).

Referring to FIG. 5 , the electronic device 510 includes a UWB-enabled application 511 , a framework 512 , and a first security component 513 , and may communicate with an external electronic device 520 .

In the embodiment of FIG. 5 , the Framework 512 may communicate with another Ranging device and the first security component 513 through an APDU interface. The APDU interface is based, for example, on ISO/IEC 7816-4. For example, the Framework 512 of the electronic device 510 receives an APDU command (SELECT ADF (OID)) for selecting the ADF identified by the OID from the external Ranging Device (eg, FiRa Device) 520 and , may transmit the received APDU command to the first security component 513 . In addition, the Framework 512 may receive a response to the APDU command from the first security component 513 , and transmit the received response to an external Ranging Device (eg, FiRa Device) 520 . The response may include a Cryptogram, an Encrypted Message (EncMsg) and/or a Message Authentication Code (MAC).

On the other hand, this APDU interface can only be called by the Framework (512) and cannot be called by the Application (511). Accordingly, when using the APDU interface, the UWB-enabled Application 511 can only serve to provide the Service Profile to the Framework 512 using, for example, the ServiceInit() API. That is, the UWB-enabled Application 511 cannot be actively operated.

6 illustrates an exemplary configuration and operation of an electronic device that performs secure ranging using a second secure component according to an exemplary embodiment of the present disclosure.

In the embodiment of FIG. 6 , the electronic device (UWB device) 610 may be one of the electronic devices described above with reference to FIGS. 1 to 3 . For example, the electronic device 610 may be, for example, a Smart Ranging Device, and the second security component may be a TEE or a Strongbox (SB).

Referring to FIG. 6 , the electronic device 610 includes a UWB-enabled application 611 , a framework 612 , and a second security component 613 , and may communicate with an external electronic device 620 .

In one embodiment, the second secure component 613 may include, for example, an implementation function of secure channel 1 (SC01) and/or a key implementation function. For example, the second security component 613 may include a MAC Privacy key (eg, MAC Privacy key having 123 as a key value) corresponding to the application (eg, an application having abc as Appid) and/or an application (eg, abc) It may include an ENC Privacy key (eg, an ENC Privacy key having 456 as a key value) corresponding to an application having Appid as Appid. In one embodiment, a MAC Privacy key may be used for generating a message authentication code, and an ENC Privacy key may be used for encryption. Such a secure channel key may be provided by, for example, a service provider in a key provisioning step. The key provisioning step may be performed before the discovery step.

In the embodiment of FIG. 6 , the Framework 612 may communicate with the second security component (TEE/SB) 613 through a set of Framework APIs rather than the APDU interface. In one embodiment, the Framework API set includes, for example, Register() for application registration, setSecureMessagingSession() for establishing a secure messaging session, and/or setRangingData() for setting ranging data (or RDS). It may contain APIs.

Unlike the embodiment of FIG. 5 that uses the APDU interface, this Framework API may be called by the Application 611 . Accordingly, when using this Framework API, the Framework 612 is in charge of logic, and the UWB-enabled Application 611 uses the API to set detailed parameters for secure ranging and provide various services (eg, FiRa service). ) and provide related data to the Framework. Through this, the embodiment of FIG. 6 is advantageous in terms of maintenance and reliability of the application by the service provider compared to the embodiment of FIG. 5 .

7A illustrates a method for an electronic device to establish a secure channel between a first secure component and UWBS according to an exemplary embodiment of the present disclosure.

In the embodiment of FIG. 7A , the electronic device 710 may be, for example, the electronic device having the configuration of FIG. 5 , and the first security component may be an SE (eg, eSE).

Referring to FIG. 7A , the electronic device 710 may include a UWB-enabled Application 711 , a Framework 712 , a UWBS 713 , and a first security component 714 .

In the embodiment of FIG. 7A , a secure channel is established directly between the UWBS 713 and the first secure component 714 by the APDU interface. As shown, the secure channel is a symmetric key based secure channel in which the UWBS 713 and the first secure component 714 share the same shared key (eg, a shared secret key (“sharedScret=K”)).

7B illustrates a method for an electronic device to establish a secure channel between a second secure component and UWBS according to an exemplary embodiment of the present disclosure.

In the embodiment of FIG. 7B , the electronic device 720 is, for example, the electronic device having the configuration of FIG. 6 , and the second security component may be a TEE and/or an SB.

Referring to FIG. 7B , the electronic device 720 may include a UWB-enabled application 721 , a framework 722 , a UWBS 723 , and a second security component 724 . The second secure component 724 may be a TEE or a strongbox, and the TEE may include a TA.

In the embodiment of FIG. 7B , a secure channel is established between the UWBS 723 and the second secure component 724 via the Framework 722 by a function call (API call). That is, a secure channel may be established via the Framework 722 rather than directly established between the UWBS 723 and the security component 724 . For example, a secure channel (first secure channel) is established between the TEE (or SB) 724 and the Framework 722 , and a secure channel (second secure channel) is established between the Framework 722 and the UWBS 723 . ) is established, a secure channel may be indirectly established between the TEE (or SB) 724 and the UWBS 723 . This will be further described below with reference to FIGS. 9A and 9B.

In the embodiment of FIG. 7B , the secure channel may be an asymmetric key or a symmetric key based secure channel. That is, in the embodiment of FIG. 7B , the secure channel may be established based on an asymmetric cryptographic algorithm or a symmetric cryptographic algorithm. As such, unlike in the embodiment of FIG. 7A using the first security component, in the embodiment of FIG. 7B using the second security component, an asymmetric key-based secure channel may be established.

8 is a flowchart of a method for providing an RDS by an electronic device including a second security component according to an exemplary embodiment of the present disclosure.

For UWB security ranging, the electronic device must perform End to End encryption (E2EE) communication with an external electronic device. To this end, a specific session key (URSK) shared with an external device must be securely transferred from the secure component to the UWBS. In the embodiment of FIG. 8 , for this purpose, an embodiment in which the session key can be securely transmitted from the security component to the UWBS will be described.

In the embodiment of FIG. 8 , the electronic device 810 may be, for example, the electronic device having the configuration of FIG. 6 , and the electronic device 810 includes a framework 811 , a UWBS 812 , and a second security component 813 . ), and may communicate with the external electronic device 820 . The second security component 813 may be a TEE (or a TA within a TEE) and/or an SB. The TEE may include a Trusted Application (TA). Meanwhile, although not shown, the electronic device 810, like other UWB devices, may include at least one application (UWB-enabled application), and the framework and the UWB-enabled application may include at least one processor (eg, may be implemented by an application processor (AP). Accordingly, in the present disclosure, the operation of the framework and/or the UWB-enabled application may be expressed as the operation of the processor.

In the embodiment of FIG. 8 , the second security component 813 secures the security corresponding to the first application (eg, a UWB-enabled Application having abc as an identifier for identifying the application (eg, Application ID (AppID), UUID)) A secure channel corresponding to a channel key (eg, a key having 123 as a key value) and a second application (eg, UWB-enabled Application having xyz as an identifier for identifying an application (eg, Application ID (AppID), UUID)) Assume that it contains a key (eg, a key having 789 as a key value). As an embodiment, the secure channel key may include a key for encryption and/or a key for message authentication. However, the present invention is not limited thereto, and the second secure channel may include a larger number of secure channel keys or a single secure channel key.

In operation 8010 , the external electronic device 820 may transmit a secure channel request (a first secure channel request) to the electronic device 810 . For example, the external electronic device 820 may transmit the first secure channel request including the OID to the electronic device 810 . The first secure channel request may be a request for creating a secure channel between the external electronic device 820 and the electronic device 810 . That is, the first secure channel request may be a request for creating a secure channel between devices. The transmitted first secure channel request may be transmitted to the Framework 811 of the electronic device 810 .

In operation 8020 , the Framework 811 may identify an application identifier (eg, AppID) matching the OID included in the first secure channel request. Through this, the Framework 811 may convert the OID into an AppID. Here, AppID may be an ID for identifying a UWB-enabled application provided by a service provider. In the present disclosure, AppID may be distinguished from applet ID (AID) for identifying the aforementioned applet. In an embodiment, the Framework 811 may include a mapping table (list) between OIDs and AppIDs.

In operation 8030 , the Framework 811 may transmit the second secure channel request corresponding to the first secure channel request to the second secure component 813 of the electronic device 810 . For example, the Framework 811 may forward the second secure channel request including the AppID that matches the OID of the first secure channel request to the second secure component 813 .

In operation 8040 , the electronic device 810 may establish a secure channel between the second security component 813 (or the electronic device 810 ) of the electronic device 810 and the external electronic device 820 . In one embodiment, the secure channel is associated with a UWB-enabled Application identified by an AppID included in the second secure channel request, and is established directly or indirectly between the external electronic device 820 and the second secure component 813 . can be

In operation 8050 , the electronic device 810 may perform a parameter exchange procedure for a UWB session with the external electronic device 820 through the established secure channel. Through this, the electronic device 810 may negotiate the value of the set parameter with the external electronic device 820 . For example, the electronic device 810 may negotiate values of parameters such as Session ID and/or URSK through the established secure channel. The exchanged parameters may be stored in the second secure component 813 . In one embodiment, the parameter may include a UWB performance parameter and/or a UWB configuration parameter.

In operation 8060 , the framework 811 may transmit a command to set the ranging data RDS to the second security component 813 . For example, the Framework 811 (or UWB-enabled application) may call/use the setRangingData() API/command for the second security component 813 . setRangingData() has a function to allow the second security component 813 to prepare (or set/create) the RDS. That is, setRangingData( ) may be an API used to allow the second security component 813 to set the RDS. setRangingData() can include the AppID for the application to identify which application has called this API.

In operation 8070 , the second security component 813 may prepare (or set/create) the RDS. For example, a TEE (or a TA within a TEE) may prepare an RDS. In one embodiment, the RDS may include a Session ID and/or a URSK.

In operation 8080 , the second security component 813 may transmit a response corresponding to a command to set the ranging data RDS to the Framework 811 . For example, the second security component 813 may transmit a return/response (API Return) corresponding to setRangingData(AppID) to the Framework 811 . In an embodiment, the return may include a value (API Return: RDS ready) indicating that the RDS is ready (or set/created).

In operation 8090 , the Framework 811 may transmit a command to transmit the RDS to the UWBS to the second security component 813 . For example, the Framework 811 (or UWB-enabled application) may call/use the PushRDStoUWBS( ) API/command for the second security component 813 . PushRDStoUWBS( ) has a function of allowing the second security component 813 to transmit (or push) the prepared RDS to the UWBS. That is, PushRDStoUWBS( ) may be an API used to allow the second security component 813 to deliver the RDS to the UWBS. PushRDStoUWBS() may include an AppID for an application corresponding to the prepared RDS.

In operation 8100 , the electronic device 810 may establish a secure channel between the UWBS 812 and the second secure component 813 . Through this, a secure channel may be established between the UWBS 812 and the second secure component 813 in the device. For example, a secure channel may be established between the UWBS and the TEE (or the TA within the TEE). As described above in FIG. 7B , a secure channel between the UWBS 812 and the second secure component 813 may be indirectly established, for example, through the Framework 811 . An example of this secure channel establishment procedure will be described below with reference to FIGS. 9A and 9B.

In operation 8110 , the second security component 813 may deliver the encrypted RDS to the UWBS 812 through the established secure channel. For example, the TEE (or the TA in the TEE) may encrypt the RDS using the encryption key (K_ENC) obtained through the secure channel establishment procedure, and transmit the encrypted RDS to the UWBS 812 . Through this, the RDS can be safely delivered (pushed) from the second security component to the UWBS.

In operation 8120 , the Framework 811 may transmit a ranging start command for starting a UWB session to the UWBS 812 . For example, the Framework 811 may transmit a UCI command (UCI: Ranging Start()) for starting a UWB session/ranging to UWBS. Ranging Start() may include AppID. In one embodiment, an AppID may be associated with a Session ID that identifies the UWB session.

In operation 8130 , the UWBS 812 may transmit a response corresponding to the ranging start command to the framework 811 . In one embodiment, the response may include a status value indicating whether the ranging start command has been accepted or not. For example, the response may include an OK value indicating that the ranging start command is accepted, or a NOK value indicating that the ranging start command is not accepted.

In operation 8140 , the electronic device 810 may perform secure ranging with the external electronic device 820 through the UWBS 812 . In this case, the UWBS 812 may perform Secure Ranging using URSK.

As in the embodiment of FIG. 8 , in the electronic device including the second security component, the RDS including the URSK may be pushed from the second security component to the UWBS by an API call of the application. For example, the RDS may be transferred from the TEE (or TA within the TEE) to the UWBS through the PushRDStoUWBS (AppID) API call of the application.

On the other hand, the secure ranging operation using the session key delivered by the second security component shown in FIG. 8 , the secure ranging operation using the session key delivered by the first security component shown in FIG. 4 and the external device point of view can be seen the same.

<First embodiment of secure channel establishment procedure between UWBS and a second secure component (eg, TEE)>

9A illustrates a secure channel establishment procedure between UWBS and a secure component using a symmetric scheme according to an exemplary embodiment of the present disclosure.

The secure channel setting procedure of FIG. 9A may be an example of the secure channel setting procedure of operation 8100 of FIG. 8 .

The symmetric method of FIG. 9A corresponds to a method of exchanging random values with each other and generating a session key based on the corresponding random value. In this case, a cryptogram is utilized to prove that you have the key for authentication. The generated session key may include a session key (s_ENC) (first session key) for encryption and/or a session key (s_MAC) (second session key) for message authentication.

In the embodiment of FIG. 9A , the electronic device may include a framework 911 , a UWBS 912 , and a security component 913 .

In the embodiment of FIG. 9A , secure component 913 and UWBS 912 may include a pre-shared shared key (eg, K1, K2) for a Symmetric scheme using a Symmetric cryptographic algorithm. Each key may be stored in the secure component, for example, through a key provisioning operation, which will be described with reference to FIG. 10B .

The secure channel establishment procedure of FIG. 9A may be initiated when the PushRDStoUWBS() API is called, as in operation 9100, for example. For example, when a command for pushing RDS to UWBS is transmitted from a framework (or UWB-enabled application) to a secure component, a secure channel establishment procedure may be initiated. However, the embodiment is not limited thereto.

Referring to FIG. 9A , in operation 9101 , the security component 913 generates a random value r and transmits it to the framework 912 . The security component can be TEE or Strongbox. As described above, the TEE may include the TA, and the operation of the security component that is the TEE may be understood as the operation of the TA in the TEE.

In operation 9102 , the Framework 911 transmits the received random value r to the UWBS 912 . The random value r may be referred to as a first random value.

In operation 9103, the UWBS 912 generates a random value (r') operation (Gen random r'), a first session key (s_enc) generation operation (Gen SessionKey s_enc), a second session key (s_MAC) generation operation (Gen) SessionKey s_MAC) and/or cryptogram (q) generation operation (Gen cryptogram q) may be performed.

The UWBS 912 may generate a random value r' through a random value generation operation. The random value r′ may be referred to as a second random value.

The UWBS 912 may generate a first session key (s_enc) used for encryption through a first session key generation operation.

The UWBS 912 may generate a second session key (s_MAC) used for message authentication through a second session key generation operation.

The UWBS 912 may generate a cryptogram (q) through a cryptogram generation operation. A cryptogram (q) may be referred to as a first cryptogram.

In operation 9104 , the UWBS 912 may send a random value (r′) and a cryptogram (q) to the secure component 913 . The random value (r′) and cryptogram (q) may be transmitted to the security component 913 through the framework 911 .

In operation 9105 , the security component performs a first session key (s_enc) generation operation (Gen SessionKey s_enc), a second session key (s_MAC) generation operation (Gen SessionKey s_MAC), a cryptogram (q) verification operation (Verify cryptogram (q)) and/or a cryptogram (p) generation operation (Gen cryptogram p) may be performed. In one embodiment, the session key may be generated based on a secure channel key and a random value.

The security component 913 may generate a first session key (s_enc) used for encryption through a first session key generation operation.

The security component 913 may generate a second session key (s_MAC) used for message authentication through a second session key generation operation.

The security component 913 may verify the cryptogram (q) received from the UWBS 912 through a cryptogram verification operation.

The security component 913 may generate a cryptogram (p) through a cryptogram generating operation. The cryptogram (p) may be referred to as a second cryptogram.

In operation 9106 , the secure component 913 may send the cryptogram (p) to the UWBS 912 . The cryptogram(p) may be delivered to the security component 913 through the framework 911 .

In operation 9107 , the UWBS 912 may perform a cryptogram (p) verification operation (Verify cryptogram (p)). The UWBS 912 may verify the cryptogram (p) received from the security component 913 through the cryptogram verification operation.

In operation 9108 , the Framework 911 may perform a random challenge operation on the UWBS 912 and the security component 913 . For example, as illustrated, the Framework 911 may transmit a random challenge (random value) to the UWBS 912 and the security component 913 through a random challenge operation.

In operation 9109 , the Framework 911 may receive a response to the random challenge from the UWBS 912 and the security component 913 . For example, as shown, the Framework 911 receives a MAC generated based on the second session key (s_MAC) used for random challenge and message authentication from the USBS 912 and the security component 913, respectively. can As an embodiment, to generate the MAC, a Hash-based Message Authentication Code (HMAC) algorithm or a Cipher-based Message Authentication Code (CMAC) algorithm may be used.

Also, the Framework 911 may determine whether the MAC (first MAC) received from the UWBS 912 and the MAC (second MAC) received from the security component 913 match.

Through this process, the UWBS 912 is ready to receive the URSK (or RDS), and the Framework 911 and the security component 913 are ready to push the URSK (or RDS) to the UWBS 912 . can be completed For example, if the MAC (first MAC) received from the UWBS 912 and the MAC (second MAC) received from the security component 913 match, the UWBS 912 receives the URSK (or RDS). Ready to do so, Framework 911 and security component 913 may be ready to pass URSK (or RDS) to UWBS 912 .

<Second embodiment of secure channel establishment procedure between UWBS and a second secure component (eg, TEE)>

9B shows an example of a procedure for establishing a secure channel between UWBS and a secure component using an asymmetric scheme according to an exemplary embodiment of the present disclosure.

The secure channel setting procedure of FIG. 9B may be an example of the secure channel setting procedure of operation 8100 of FIG. 8 .

The asymmetric method of FIG. 9B is characterized in that a shared secret is generated using an elliptic curve (ECC)-based ephemeral key to satisfy Perfect Forward Secrecy (PFS). The generated shared secret key can be used to generate a session key. In addition, the asymmetric method requires a certificate and a private key (static key) stored by the mobile vendor in advance for authentication, and the ephemeral key and the static key are configured to match the ECC algorithm on both sides, and a shared secret can be generated and utilized.

In the embodiment of FIG. 9B , the electronic device may include a framework 921 , a UWBS 922 , and a security component 923 . As an embodiment, the secure component 923 may be a TEE or an SB. As described above, the TEE may include the TA, and the operation of the security component that is the TEE may be understood as the operation of the TA in the TEE.

In the embodiment of FIG. 9B , UWBS 922 and security component 923 each include a key and a certificate for an asymmetric scheme using an asymmetric cryptographic algorithm. For example, the security component (TA) includes the TA's private key/public key (Priv/Pub_TA), the TA's certificate (Cert_TA), and/or the UWBS's certificate (Cert_UWB), and the security component (SB) includes the SB's private key. /Public key (Priv/Pub_SB), SB's certificate (Cert_SB) and/or UWB's certificate (Cert_UWB), UWBS includes UWBS's private/public key (Priv/Pub_UWB), TA's certificate (Cert_TA), and/or the SB's certificate (Cert_SB). Each key may be stored in the secure component, for example, through a key provisioning operation, which will be described with reference to FIG. 10B .

Referring to FIG. 9B , in operation 9201 , the security component 923 may perform a first temporary key (e) generation operation (Gen ephemeral key e). For example, the TEE (or TA) may generate the first temporary key e through the first temporary key generation operation. In one embodiment, the temporary key e may be generated before the PushRDStoUWBS() API is called, for example, as in operation 9200, but is not limited thereto.

The security component 923 may further generate a signature value signed(e) for the first temporary key e. For example, the TEE (or TA) may further generate a signature value (signed(e)) for the first temporary key (e) by using the TA's private key (Priv_TA). In the present disclosure, the first temporary key (e) may be referred to as Pub_e, and the signature value (signed(e)) for the first temporary key may be referred to as signed(Pub_e).

In operation 9202 , the security component 923 transmits the first temporary key and a signature value for the first temporary key (“e || signed(e)”) to the Framework 921 , and in operation 9203 , the Framework 921 sends the received first temporary key and the signature value of the first temporary key (“e || signed(e)” or “Pub_e || signed(Pub_e)”) to UWBS.

In operation 9204, the UWBS 922 may perform an operation for verifying a signed temporary key (signed e) (Verify signed e) and an operation for generating a second temporary key (e') (Gen ephemeral key e'). For example, the UWBS 922 may verify the signature value (signed(e)) for the first temporary key using the TA's certificate (or the TA's public key (Pub_TA)), and the second temporary key The second temporary key e' may be generated through the generation operation. As an embodiment, a shared secret may be generated/calculated based on the first temporary key (e) and the second temporary key (e'). In this disclosure, the second temporary key (e') may be referred to as Pub_e'.

The UWBS 922 may further generate a signature value (singed(e') or signed(Pub_e', Pub_e)) for the second temporary key (e'). For example, the UWBS 922 may further generate a signature value for the second temporary key (e') using the private key (Priv_UWBS) of the UWBS.

In operation 9205, the UWBS 922 obtains the second temporary key and a signature value for the second temporary key ("e' || signed(e')" or "Pub_e' || signed(Pub_e', pub_e)"). send to the Framework 921, and in operation 9206, the Framework 921 receives the second temporary key and a signature value for the second temporary key ("e' || signed(e')" or "Pub_e' || signed(Pub_e', pub_e)") to the security component 923 .

In operation 9207, the security component 923 calculates the shared secret key S using the second temporary key (Pub_e') and the first temporary key (pub_e), the shared secret key S and the pre-shared parameters (eg, 1234) (first context), generating operation of session key (K_ENC) used for encryption, and session key for MAC based on shared secret key S and pre-shared parameters (eg ABCD) (second context) (K_MAC) generation operation may be performed. For example, the TEE (or TA) generates a shared secret key S using the second temporary key (e') and the first temporary key (e), and shares it using a preset key derivation function (KDF). A session key (K_ENC) for encryption may be generated from the secret key S and the first context, and a session key (K_MAC) for message authentication may be generated from the shared secret key S and the second context using a preset KDF.

In operation 9208, the UWBS 922 calculates the shared secret key S using the second temporary key (Pub_e') and the first temporary key (pub_e), the shared secret key S and the pre-shared parameters (eg, 1234). ) (the first context) (the first context), and the operation of generating the session key (K_ENC) used for encryption, and the session key for the MAC based on the shared secret key S and pre-shared parameters (e.g. ABCD) (second context) (second context). K_MAC) generation operation may be performed. For example, the UWBS 922 generates a shared secret key S using the second temporary key (Pub_e') and the first temporary key (pub_e), and uses the preset KDF to generate the shared secret key S and the first context. A first session key (K_ENC) for encryption may be generated from , and a second session key (K_MAC) for message authentication may be generated from the shared secret key S and the second context using a preset KDF. This allows the UWBS 922 and the security component 923 to possess the same key for encryption (K_ENC) and key for message authentication (K_MAC).

Meanwhile, in the illustrated embodiment, operation 9208 is exemplified as being performed after operation 9205, but operation 9208 may be performed at any time after operation 9204. For example, operation 9208 may be performed after operation 9204 and before operation 9205 .

In operation 9209 , the framework 921 may perform a random challenge operation on the UWBS 922 and the security component 923 . For example, as illustrated, the Framework 921 may transmit a random challenge (random value) to the UWBS 922 and the security component 923 through a random challenge operation.

At operation 9210 , the Framework 921 may receive a response to the random challenge from the UWBS 922 and the security component 923 . For example, as shown, the Framework 921 receives the MAC generated based on the second session key (K_MAC) used for random challenge and message authentication from the UWBS 922 and the security component 923, respectively. can As an embodiment, to generate the MAC, a Hash-based Message Authentication Code (HMAC) algorithm or a Cipher-based Message Authentication Code (CMAC) algorithm may be used.

Also, the Framework 921 may determine whether the MAC (first MAC) received from the UWBS 922 and the MAC (second MAC) received from the security component 923 match.

Through this process, the UWBS 922 is ready to receive the URSK (or RDS), and the Framework 921 and the security component 923 are ready to push the URSK (or RDS) to the UWBS 922 . can be completed For example, if the MAC (first MAC) received from UWBS 922 and the MAC (second MAC) received from security component 923 match, then UWBS 922 receives the URSK (or RDS). Ready to do so, Framework 921 and security component 923 may be ready to pass URSK (or RDS) to UWBS 922 .

<Third embodiment of secure channel establishment procedure between UWBS and a second secure component (eg, TEE)>

9C illustrates another example of a procedure for establishing a secure channel between UWBS and a secure component using an asymmetric scheme according to an exemplary embodiment of the present disclosure.

The secure channel setting procedure of FIG. 9C may be an example of the secure channel setting procedure of operation 8100 of FIG. 8 .

The asymmetric method of FIG. 9c is characterized in that a shared secret is generated using an elliptic curve (ECC)-based ephemeral key to satisfy Perfect Forward Secrecy (PFS). The generated shared secret key can be used to generate a session key. In addition, the asymmetric method requires a certificate and a private key (static key) stored by the mobile vendor in advance for authentication, and the ephemeral key and the static key are configured to match the ECC algorithm on both sides, and a shared secret can be generated and utilized.

In the embodiment of FIG. 9C , for convenience of description, it is assumed that the electronic device is an electronic device for providing a UWB-based payment service (eg, the first electronic device of FIG. 2B ) and the security component is TEE (TA). , but not limited thereto.

In the embodiment of FIG. 9C , the electronic device may include a UWB enabled Wallet Application (UWB enabled application) 921 , a Wallet Framework (Framework) 932 , a UWBS 933 and a Trusted Payment Application (Trusted Application) 934 . can

In the embodiment of FIG. 9C , UWBS 933 and Trusted Payment Application (TPA) 934 each include a key and a certificate for an asymmetric scheme using an asymmetric cryptographic algorithm. For example, the TPA 934 includes a TPA secret key (private key) (SK.TPA), a TPA certificate (CERT.TPA) and/or a root certificate (ROOT.OEM), and the UWBS includes the UWBS private key ( private key) (SK.UWBS), a UWBS certificate (CERT.UWBS), and/or a root certificate (ROOT.OEM). Each key may be stored in the secure component, for example, through a key provisioning operation, which will be described with reference to FIG. 10B .

Table 1 below shows an example of a key and data used to establish a secure channel between UWBS and TEE (TPA/TA).

Key name Type/Length Purpose Presence CERT.TPA
CERT.UWBS ECC-P256 Public key certificate of the UWBS and Trusted Payment Application. This certificate is issued by Certificate Authority (e.g. Mobile OEM). Mandatory SK.TPA
SK.UWBS ECC-P256 Secret (Private) key of the Trusted Payment Application and UWBS to prove ownership of the authorization certificate. Mandatory shared credential AES-128 Derived shared credential by shared secret from static keys and shared secret from ephemeral keys. This value is K-MAC in accordance with the section 9.1.1.4. Optional

Table 2 below shows an example of certificates (eg, TPA's certificate (CERT.TPA) and UWBS's certificate (CERT.UWBS)) that are exchanged to establish a secure channel between UWBS and TEE (TPA/TA). .

Tag Length Description Presence 0x7F21 Certificate Mandatory 0x93 1-16 serial number Mandatory 0x42 variable CA Identifier Optional 0x5F20 16 Subject identifier Mandatory 0x95 One Key Usage('82' digital signature verification, or '88' encipherment for confidentiality; see [GPCS] Table 11-17) Optional 0x5F25 4 Effective Date (YYYYMMDD, BCD format) Optional 0x5F24 4 Expiration Date (YYYYMMDD, BCD format) Optional for device, not present for reader 0x53 1-127 Discretionary Data (unspecified format). Can be used to store the OID corresponding to the credentials, useful in case SELECT ADF with multiple selection must be supported. Optional 0x73 1-127 Discretionary Data (BER-TLV encoded) Optional 0x7F49 Public Key Data Object Mandatory 0xB0 65 Public Key Point Q (in uncompressed encoding as specified in [TR-03111] section 3.2.1) Mandatory 0xF0 One Key Parameter Reference (00 for NIST P256) Mandatory 0x5F37 64 signature value Mandatory

Referring to FIG. 9C , in operation 9301 , the UWB enabled wallet application 931 may transmit a command for obtaining a temporary key from the TPA to the TPA 934 . For example, the UWB enabled Wallet Application 931 may transmit a TEE command (eg, TEE Client API CMD: WALLET_GET_EPHEMERAL_KEY) for obtaining a temporary key and/or a signed temporary key from the TPA to the TPA 934 .

Table 3 below shows an example of a TEE command for WALLET_GET_EPHEMERAL_KEY.

Description This function is to get ephemeral key and signed ephemeral key from Payment Trusted Application. Data is composed ephemeral key and signature of the ephemeral key so those are totally 64bytes(512bit). commandID 11 params[1] - Output data buffer : a buffer of 64 bytes, aligned on a byte boundary
- Data flow direction: output Error TBD (0x00000001 - 0xFFFEFFFF)

In operation 9032, the TPA 934 generates a temporary key (ePK.TPA) of the TPA, and sends a response including the temporary key (ePK) of the TPA and/or the certificate (CERT.TPA) of the TPA to the UWB enabled Wallet Application ( 931) can be forwarded. For example, the TPA 934 generates the TPA's temporary key (ePK.TPA), and a TEE response (eg, TEE Client) that includes the TPA's temporary key (ePK.TPA) and the TPA's certificate (CERT.TPA). API Return: ePK.TPA | CERT.TPA) can be delivered to the UWB enabled Wallet Application (931).

In operation 9033 , the UWB enabled Wallet Application 931 may transmit the received TPA temporary key (ePK.TPA) and/or the TPA certificate (CERT.TPA) to the Framework 932 . For example, the UWB enabled Wallet Application 931 may call an API (eg, Framework API) and transmit the received TPA's temporary key (ePK) and TPA's certificate (CERT.TPA) to the Framework 932 .

In operation 9034 , the Framework 932 may transfer the received TPA's temporary key (ePK) and/or the TPA's certificate (CERT.TPA) to the USBS 933 . For example, the Framework 932 may transmit a UCI command (eg, UCI CMD: WALLET_PUT_EPHEMERAL_KEY_FROM_TEE_CMD) including the received TPA's temporary key (ePK) and/or TPA's certificate (CERT.TPA) to the USBS 933 . have. WALLET_PUT_EPHEMERAL_KEY_FROM_TEE_CMD may be a command for putting a temporary key and certificate from TEE (TPA/TA) into UWBS.

Table 4 below shows an example of a UCI command for WALLET_PUT_EPHEMERAL_KEY_FROM_TEE_CMD.

WALLET_PUT_EPHEMERAL_KEY_FROM_TEE_CMD Payload Field(s) Length
(Bits) Value/ Description command 0 Put the ephemeral key and certificate from TEE to UWBS payload length 8 The length of Payload ePK.TPA 256 Ephemeral key from Trusted Payment Application CERT.TPA variable Certificate of Trusted Payment Application

In operation 9305 , the USBS 933 may generate a shared secret and may generate an AES key. For example, the USBS 933 generates a UWBS temporary key (ePK.UWBS), and uses the UWBS temporary key (ePK.UWBS) and the received TPA temporary key (ePK.TPA) to generate a shared secret S. can create Also, the USBS 933 may generate an AES Key (K_ENC) for encryption and an AES Key (K_MAC) for message authentication using the generated shared secret S.

In operation 9306 , the USBS 933 may transfer the generated temporary key of UWBS (ePK.UWBS) and the certificate of UWBS (CERT.UWBS) to the Framework 932 . For example, the USBS 933 may transmit a UCI response (eg, UCI RSP: WALLET_PUT_EPEHERAL_KEY_FROM_TEE) including the generated UWBS temporary key (ePK.UWBS) and UWBS certificate (CERT.UWBS) to the Framework 932 . have. WALLET_PUT_EPEHERAL_KEY_FROM_TEE_RSP may be a response to WALLET_PUT_EPHEMERAL_KEY_FROM_TEE_CMD.

Table 5 below shows an example of WALLET_PUT_EPEHERAL_KEY_FROM_TEE_RSP.

WALLET_PUT_EPHEMERAL_KEY_FROM_TEE_RSP Payload Field(s) Length
(bits) Value/ Description Status 8 For various status values refer to Table 37 in UCI Specification of FiRa Consortium payload length 8 The length of Payload ePK.UWBS 256 Ephemeral key from UWBS CERT.UWBS variable Certificate of UWBS

In operation 9307 , the Framework 932 may transmit the received UWBS temporary key (ePK.UWBS) and/or UWBS certificate (CERT.UWBS) to the UWB enabled Wallet Application 931 . For example, the Framework 932 provides an API response (eg, API Return: ePK.UWBS | CERT.UWBS) including the received UWBS's temporary key (ePK.UWBS) and/or UWBS's certificate (CERT.UWBS). can be delivered to the UWB enabled Wallet Application (931).

In operation 9308 , the UWB enabled Wallet Application 931 may transmit a command for putting a temporary key from UWBS to the TPA 934 . For example, the UWB enabled Wallet Application 931 may transmit a TEE command (eg, TEE Client API CMD: WALLET_PUT_EPHEMERAL_KEY) to the TPA 934 for putting the temporary key and/or the signed temporary key from UWBS into the TPA. have.

Table 6 below shows an example of a TEE command for WALLET_PUT_EPHEMERAL_KEY.

Description This function is to put ephemeral key and signed ephemeral key from UWBS to Trusted Payment Application so those are totally 64bytes(512bit). commandID 12 params[0] -Input data buffer : a buffer of 64 bytes, aligned on a byte boundary
-Data flow direction: input Error TBD (0x00000001 - 0xFFFEFFFF)

In operation 9309 , the TPA 934 may generate a shared secret and may generate an AES key. For example, the TPA 934 may generate a shared secret S by using the received UWBS temporary key (ePK.UWBS) and its own (TPA) temporary key (ePK.TPA). In addition, the TPA 934 may generate an AES Key (K_ENC) for encryption and an AES Key (K_MAC) for message authentication using the generated shared secret S.

In operation 9310 , the TPA 934 may transmit a response to the command for inserting the temporary key from the UWBS to the UWB enabled Wallet Application 931 . For example, the TPA 934 may transmit a TEE response indicating OK/NOK (eg, TEE Client API Return: OK/NOK) to the UWB enabled Wallet Application 931 .

9D illustrates a procedure for UWBS to deliver an RDS to a secure component through a secure channel between the UWBS and the secure component according to an exemplary embodiment of the present disclosure.

In the embodiment of FIG. 9D , a secure channel between the UWBS and the secure component may be established, for example, through the secure channel establishment procedure of FIG. 9C .

In the embodiment of FIG. 9D , for convenience of description, it is assumed that the electronic device is an electronic device for providing a UWB-based payment service (eg, the first electronic device of FIG. 2B ) and the security component is TEE (TA). , but is not limited thereto.

In the embodiment of FIG. 9D , the electronic device includes a UWB enabled Wallet Application (UWB enabled application) 941 , a Wallet Framework (Framework) 942 , a UWBS 943 , and a Trusted Payment Application (Trusted Application) 944 . can

In operation 9401 , the UWB enabled wallet application 941 may transmit a random challenge (random value) to the TPA 944 . For example, the UWB enabled Wallet Application 941 may transmit a TEE command (eg, TEE Client API CMD: WALLET_PUT_CHALLENGE) including a random challenge to the TPA 944 . WALLET_PUT_CHALLENGE is used to obtain a MAC (eg, CMAC) from the TPA, the input includes a random value, and the output includes a random value and the MAC value of the shared secret.

Table 7 below shows an example of a TEE command for WALLET_PUT_CHALLENGE.

Description This function is to get CMAC from Trusted Payment Application. Input with random value and output with CMAC value of the random value and shared secret. This can check whether UWBS and Trusted Payment Application have same shared secret. commandID 21 params[0] - Input data buffer　: a buffer of 16 bytes, aligned on a byte boundary- Data flow direction　: input params[1] - Output data buffer: same length as input buffer, aligned on a byte boundary.- Data flow direction: output Error TBD (0x00000001 - 0xFFFEFFFF)

In operation 9402 , the TPA 944 may transfer the MAC (MAC.TPA) of the TPA to the UWB enabled Wallet Application 941 . For example, the TPA 944 generates a MAC (MAC.TPA) based on the received random challenge and the shared secret, and a TEE response including the MAC (MAC.TPA) (eg, TEE Client API Return: MAC. TPA) to the UWB enabled Wallet Application 941 .

In operation 9403 , the UWB enabled wallet application 941 may transmit a random challenge (random value) to the framework 942 . For example, the UWB enabled Wallet Application 941 may transmit a random challenge (random value) to the Framework 942 through an API (Framework API) call.

In operation 9404 , the Framework 942 may forward the received random challenge to the UWBS 943 . For example, the Framework 942 may transmit the received random challenge to the UWBS 943 with a UCI command (eg, WALLET_PUT_CHALLENGE_CMD) including the UWBS 943 . WALLET_PUT_CHALLENGE_CMD may be used to obtain the MAC (MAC.UWBS) of UWBS from UWBS.

Table 8 below shows an example of WALLET_PUT_CHALLENGE_CMD.

WALLET_PUT_CHALLENGE_CMD Payload Field(s) Length
(bits) Value/ Description command 0 Get the MAC.UWBS from UWBS Nonce 128 Random number used at once

In operation 9405 , the UWBS 943 may transfer the MAC (MAC.UWBS) of the UWBS to the Framework 942 . For example, the UWBS 943 generates a MAC (MAC.UWBS) based on the received random challenge and the shared secret, and sends a UCI response (eg, WALLET_PUT_CHALLENGE_RSP) including the MAC (MAC.UWBS) to the Framework 942 . can be passed to

Table 9 below shows an example of WALLET_PUT_CHALLENGE_RSP.

WALLET_PUT_CHALLENGE_RSP Payload Field(s) Length
(bits) Value/ Description Status 8 For various status values refer to Table 37 in UCI Specification of FiRa Consortium

In operation 9406 , the Framework 942 may transmit the received MAC (MAC.UWBS) of the UWBS to the UWB enabled Wallet Application 941 . For example, the Framework 942 may transmit the MAC (MAC.UWBS) of UWBS to the UWB enabled Wallet Application 941 through an API return.

In operation 9407, the UWB enabled Wallet Application 941 may determine whether the MAC (MAC.TPA) of the TPA and the MAC (MAC.UWBS) of the UWBS are the same.

In operation 9408 , the UWB enabled Wallet Application 941 may transmit a command for obtaining an RDS to the TPA 944 . For example, if the MAC (MAC.TPA) of the TPA and the MAC (MAC.UWBS) of the UWBS are the same, the UWB enabled Wallet Application 941 uses a TEE command to obtain an RDS (eg, TEE Client API Command: TEE WALLET_GET_RDS) may be passed to the TPA 944 . WALLET_GET_RDS can be used to get encrypted RDS from TPA.

Table 10 below shows an example of a TEE command for WALLET_GET_RDS.

Description This function is to get encrypted RDS from Trusted Payment Application. commandID 31 params[0] - Value　: a=Encryption Key ID- Data flow direction　: input params[1] - Output data buffer: a buffer of 64bytes, aligned on a byte boundary.
- Data flow direction: output Error TBD (0x00000001 - 0xFFFEFFFF)

In operation 9409 , the TPA 944 may transmit an encrypted RDS (Encrypted_blob) to the UWB enabled Wallet Application 941 . For example, the TPA 944 transmits a TEE response (eg, TEE Client API Return: Encrypted_blob | MAC.eRDS) including the encrypted RDS (Encrypted_blob) and the encrypted RDS MAC (MAC.eRDS) to the UWB enabled Wallet Application (941).

In operation 9410 , the UWB enabled Wallet Application 941 may transmit the received encrypted RDS (Encrypted_blob) to the Framework 942 . For example, the UWB enabled Wallet Application 941 may transmit the encrypted RDS (Encrypted_blob) and the encrypted RDS MAC (MAC.eRDS) to the Framework 942 through a Framework API (API) call.

In operation 9411 , the Framework 942 may transmit the received encrypted RDS (Encrypted_blob) to the UWBS 943 . For example, the Framework 942 may transmit a UCI command (eg, WALLET_PUT_ENCRYPTED_RDS_CMD) including an encrypted RDS (Encrypted_blob) and a MAC (MAC.eRDS) of the encrypted RDS to the UWBS 943 . WALLET_PUT_ENCRYPTED_RDS_CMD can be used to put RDS of UWBS from UWBS.

Table 11 below shows an example of WALLET_PUT_ENCRYPTED_RDS_CMD.

WALLET_PUT_ENCRYPTED_RDS_CMD Payload Field(s) Length
(bits) Value/ Description command 0 Get the capability data from UWBS payload length 8 The length of Payload Encrypted RDS variable RDS, which is encrypted by K-ENC in section 9.1.1.4 MAC of encrypted RDS 128 MAC of encrypted RDS, which is derived by K-MAC in section 9.1.1.4.

In operation 9412 , UWBS 943 may pass the response to Framework 942 . For example, the UWBS 943 may transmit a UCI response (eg, WALLET_PUT_ENCRYPTED_RDS_RSP) corresponding to the UCI command to the Framework 942 . WALLET_PUT_ENCRYPTED_RDS_RSP may include information indicating a status (OK/NOK) of whether the encrypted RDS has been normally received.

Table 12 below shows an example of WALLET_PUT_ENCRYPTED_RDS_RSP.

WALLET_PUT_ENCRYPTED_RDS_RSP Payload Field(s) Length Value/ Description Status 1 Octet For various status values refer to Table 37 in UCI Specification of FiRa Consortium

10A illustrates a key provisioning method for an electronic device including a first security component according to an exemplary embodiment of the present disclosure.

The electronic device of FIG. 10A may be the electronic device of FIG. 5 , and the first security component may be an SE (eg, eSE).

Referring to FIG. 10A, in operation 1, for key provisioning of the Service Provider (SP) 1011, the Provisioning Authority (PA) 1012 may request an SD (Security Domain) Owner 1013 for authorization, and , in operation 2 , the SD Owner 1013 may provide the PA credential to the first security component 1014 based on the request. In operation 3 , the SP 1011 may request the ADF(s) from the PA 1012 , and in operation 4 , the PA 1012 provides the ADF(s) to the first security component 1014 based on the request. can do. In operation 5 , the SP 1011 may perform personalization on the ADF provided to the first security component 1014 .

As such, in order for the service provider 1011 to provide key provisioning for the first security component 1014 , cooperation of several entities (PAs, SD owners, etc.) in various business contract relationships is required. Accordingly, it is difficult for the service provider 1011 to directly provide the key to the first security component 1014 . That is, it becomes difficult for the service provider 1011 to provide the key flexibly and efficiently.

10B illustrates a key provisioning method for an electronic device including a second security component according to an embodiment of the present disclosure.

The electronic device of FIG. 10B may be the electronic device of FIG. 6 , and the second security component may be a TEE (TA) or an SB.

In the embodiment of FIG. 10B , the electronic device may include a mobile platform (eg, an Android platform) 1022 and a second security component 1023 . In one embodiment, the mobile platform may include the aforementioned Framework.

Referring to FIG. 10B , in operation 1 , the service provider 1021 calls an API for key provisioning, and in operation 2 , the mobile platform 1022 provides an attestation to the second security component 1023 . can do. In operation 3 , the second security component 1023 transmits a certificate to the mobile platform 1022 , and in operation 4 , the mobile platform 1022 transmits the certificate to the service provider 1021 . In operation 5 , the service provider 1021 may transmit the encrypted key to the mobile platform 1022 , and in operation 6 , the mobile platform 1022 may transmit the encrypted key to the second security component 1023 .

In the embodiment of FIG. 10B that uses a second secure component, unlike the embodiment of FIG. 10A that uses a first secure component, the service provider 1021 uses its own credentials in a secure manner. may be imported into a trusted area, for example, TEE or SB. In this case, the mobile platform (or framework) 1022 of the electronic device only needs to provide an API for the provisioning method. Accordingly, the service provider 1021 can provide the key flexibly and efficiently.

11 illustrates an attestation procedure for key provisioning for an electronic device including a second security component according to an embodiment of the present disclosure.

In the embodiment of FIG. 11 , the electronic device may be the electronic device of FIG. 6 , and the second security component may be a TEE (TA) or an SB.

In the embodiment of FIG. 11 , the attestation procedure may be a part of the procedure of FIG. 10 . The attestation procedure is performed before key provisioning.

Referring to FIG. 11 , in operation 1101, the UWB-enabled Application of the electronic device requests a nonce to a service provider (server), and in operation 1102, the service provider provides a nonce to UWB-enabled based on the request. It can be provided to the application.

In operation 1103, the UWB-enabled Application may transmit an attestation request including the nonce to the Framework, and in operation 1104, the Framework may transmit this attest (attestation request) to the second security component.

In operation 1105 , the second security component may return an attachment response (Blob) based on an attest (attestation request) to the framework. In one embodiment, an attestation response (Blob) may include a nonce, measurement(s), Device ID, signature and/or certificate. In operation 1106, the Framework may transmit the blob to the UWB-enabled application, and in operation 1107, the UWB-enabled application may transmit the blob to the service provider.

In operation 1108 , the service provider may extract the public key from the blob and encrypt the credential (eg, Secure Channel Key) using a key wrapping method based on the public key.

In operation 1109, the service provider may transmit a wrapped key to the UWB-enabled application, and in operation 1110, the UWB-enabled application may transmit the wrapped key to the second security component. In operation 1111 , the second security component may import the wrapped key along with the OID and/or AppID.

Through this procedure, the key (secure channel key) may be securely imported into the second secure component by the service provider.

12 shows an exemplary configuration of an electronic device according to an exemplary embodiment of the present disclosure.

In the embodiment of FIG. 12 , the electronic device 1200 may be, for example, a Smart Ranging device or a Ranging device.

Referring to FIG. 12 , the electronic device 1200 includes at least one application 1210 , a Framework 1220 , a UWBS 1230 , and/or a security component 1240 (eg, TA and/or Strongbox).

Each application 1210 is identified by AppID, and may call/use the Framework API of the Framework 1220 . In one embodiment, the application 1210 may be a UWB-enabled Application.

The Framework 1220 includes an OOB Connector 1221 and/or a Secure Service 1222 , and may interface with the application 1210 through the Framework API 1223 . The Framework API 1223 is, for example, a Register() API for application registration, a setSecureMessagingSession() API for establishing a secure messaging session, a setRangingData() API for setting ranging data (or RDS), and/or PushURSKtoUWBS() API for delivery of URSK (or RDS) to UWBS may be included.

The security component 1240 supports a Cryptogram generation function (genCryptogram) and/or an encrypted message generation function (genEncyptedMsg), and a security corresponding to the application having a secure channel key corresponding to the application (eg, AppID(#ABC)). A channel key (eg, SC02Key) and a secure channel key (eg, SC01Key) corresponding to an application having an AppID (#XYZ)) may be included. For example, the SB 1241 supports a Cryptogram generation function (genCryptogram) and/or an encrypted message generation function (genEncyptedMsg), and a secure channel key corresponding to an application with an AppID (#XYZ) (eg, SC01Key)). may include As another example, the TEE (TA of TEE) 1242 supports a Cryptogram generation function (genCryptogram) and/or an encrypted message generation function (genEncyptedMsg), and a secure channel key corresponding to an application with an AppID (#XYZ). (eg, SC01Key)).

In one embodiment, the secure component 1240 may generate/store a session ID and/or a UWB session key (URSK). The session ID and/or UWB session key may be passed from the secure component 1240 to the UWBS 1230 via the framework 1220 by, for example, a call to the pushURSKtoUWBS( ) API of the application 1210 .

13 is a flowchart illustrating a method of an electronic device according to an embodiment of the present disclosure.

In the embodiment of FIG. 13 , the electronic device may be a Smart Ranging Device or a Ranging Device. For a detailed description of each operation of the embodiment of FIG. 13 , reference may be made to the descriptions described above with reference to FIGS. 1 to 12 . In the embodiment of FIG. 13 , the operation of the electronic device may be, for example, an operation of a framework (or application) of the electronic device or an operation of a controller (or processor) controlling the framework (or application) of the electronic device. have.

The electronic device may transmit a request for setting a ranging data set for secure ranging to the security component ( 1310 ). For example, the electronic device may transmit a request for setting a ranging data set for secure ranging to a TEE (or a TA within the TEE). In the present disclosure, the ranging data set may be a set of data required for UWB ranging. In an embodiment, the ranging data set may include at least one of session ID information for a UWB session associated with secure ranging, and session key information for protecting the UWB session.

The electronic device may transmit a request for transmitting the ranging data set to the UWB subsystem to the security component ( 1320 ). For example, the electronic device may transmit a request for transferring the data set to the UWB subsystem to the TEE (or the TA in the TEE). In an embodiment, the ranging data set may be transferred from the secure component to the UWB subsystem using a secure channel established between the secure component and the UWB subsystem through the framework.

In one embodiment, sending a request to set a ranging data set comprises calling a framework API (setRangingData( ) API) that a security component requests to set the ranging data set, The work API may include an application ID for identifying an application that has called the framework API.

In one embodiment, the operation of sending the request for transferring the ranging data set to the UWB subsystem includes a framework API (PushRDStoUWBS() API) that the security component requests to transfer the ranging data set to the UWB subsystem. Including an operation of calling, the framework API may include an application ID for identifying an application that has called the framework API.

In one embodiment, the framework further comprises sending, to the UWB subsystem, a command to start secure ranging, wherein the command to start secure ranging includes an application ID for identifying an application associated with security ranging. may include

In one embodiment, the secure channel between the secure component and the UWB subsystem may be an asymmetric key based secure channel.

In one embodiment, the security component may be a Trusted Execution Environment (TEE) or Strongbox.

14 is a diagram illustrating a structure of a first electronic device according to an embodiment of the present disclosure.

The first electronic device of FIG. 14 may be an electronic device (eg, Smart Ranging Device) including a second security component (eg, TEE or SB).

Referring to FIG. 14 , the first electronic device may include a transceiver 1410 , a controller 1420 , and a storage 1430 . In the present disclosure, the controller may be defined as a circuit or an application-specific integrated circuit or at least one processor.

The transceiver 1410 may transmit/receive signals to and from other electronic devices. The transceiver 1410 may transmit/receive data using, for example, UWB communication.

The controller 1420 may control the overall operation of the UWB in-band discovery method according to the embodiment proposed in the present disclosure. For example, the controller 1420 may control a signal flow between blocks to perform an operation according to the above-described flowchart. Specifically, the controller 1420 may control, for example, the operation of the method for secure ranging described with reference to FIGS. 1 to 13 .

The storage unit 1430 may store at least one of information transmitted/received through the transceiver 1410 and information generated through the control unit 1420 . For example, the storage unit 1430 may store information and data for security ranging described with reference to FIGS. 1 to 13 .

15 is a diagram illustrating a structure of a second electronic device according to an embodiment of the present disclosure.

The second electronic device of FIG. 15 may be an electronic device (eg, a Smart Ranging Device or a Ranging Device) that communicates with the first electronic device of FIG. 14 .

Referring to FIG. 15 , the second electronic device may include a transceiver 1510 , a controller 1520 , and a storage 1530 . In the present disclosure, the controller may be defined as a circuit or an application-specific integrated circuit or at least one processor.

The transceiver 1510 may transmit/receive signals to and from other electronic devices. The transceiver 1510 may transmit/receive data using, for example, UWB communication.

The controller 1520 may control the overall operation of the UWB in-band discovery method according to the embodiment proposed in the present disclosure. For example, the controller 1520 may control a signal flow between blocks to perform an operation according to the above-described flowchart. Specifically, the controller 1520 may control, for example, the operation for security ranging described with reference to FIGS. 1 to 13 .

The storage unit 1530 may store at least one of information transmitted and received through the transceiver 1510 and information generated through the control unit 1520 . For example, the storage unit 1530 may store information and data for security ranging described with reference to FIGS. 1 to 13 .

<Example B>

Embodiment B corresponds to an embodiment related to the above-described attached mode. Hereinafter, Embodiment A will be exemplarily described with reference to FIGS. 16 to 27 .

* Fig. 16 shows an exemplary configuration of a UWB device including an SE.

In the embodiment of FIG. 16 , the UWB device 1600 may be a UWB device (eg, FiRa Smart Device or FiRa Device) including a Secure Element (eg, eSE) as a security component.

As described above, the SE is a secure security module based on a tamper resistant characteristic, and the eSE refers to a fixed SE that is fixed and used in an electronic device.

Referring to FIG. 16 , the UWB device 1600 may include at least one application (UWB-enabled Application) 1610 , a Framework 1620 , a Secure element 1630 , and/or a UWBS 1640 . For a description of the UWB-enabled Application 1610 and the Framework 1620, reference may be made to the description described above with reference to FIGS. 1 to 3 .

In one embodiment, SE (eg, eSE) 1630 may include a Service Applet (Applet) and/or a Secure UWB Service (SUS) Applet. Applet may include at least one Application Dedicated File (ADF) required to securely generate secure data (eg, Ranging Data Set (RDS)). For example, each Applet may include an ADF provided by each service provider (SP). The ADF may be provided by the service provider in the key provisioning phase. Applets can also forward RDS to UWBS via SUS Applets.

In one embodiment, the RDS includes a ranging session key (UWB ranging session key) indicating a key used to secure a UWB ranging session and/or a session ID identifying the RDS (or session associated with the RDS) can do. In this case, the ranging session key and the session ID must be the same in the initiator and the responder. In addition, RDS at least one ranging parameter (eg, AoA (Angle of Arrival), proximity (Proximity Distance)), client-specific data and / or multicast responder-specific key (Multicast responder-specific key) optional may include more.

UWBS 1640 manages UWB hardware. The UWBS 1640 may perform a UWBS and UWB session of another ranging device. The UWBS 1640 is managed by the Framework 1620 and may receive an RDS required for secure ranging from the SE 1630 .

In one embodiment, each component of the UWB device 1600 may communicate with each other through a predefined interface. For example, the application 1610 and the framework 1620 may communicate through a predefined Framework Application Programming Interface (API). The framework 1620 and the SE (eSE) 1630 may communicate through a predefined Object Management Application Programming Interface (OMAPI). The framework 1620 and the UWBS 1640 may communicate through a predefined UCI. The UWBS 1640 and the SE (eSE) 1630 may communicate through a predefined SUS API. However, the above-described interfaces are merely examples of interfaces for each component to communicate with each other, and according to an embodiment, each component may communicate with each other using different types of interfaces.

17 shows the operation of a UWB device including an SE.

The UWB device 1700 of the embodiment of FIG. 17 may be the UWB device of FIG. 16 . As shown, the UWB device 1700 may include at least one application (UWB-enabled Application) 1710 , a Framework 1720 , a Secure element (eg, eSE) 1730 , and/or a UWBS 1740 . have. The UWB device 1700 may communicate with another UWB device 1750 . In an embodiment, the UWB device 1700 may operate as a controlee that receives a control message (information) for UWB ranging from another UWB 1750 device.

Referring to FIG. 17 , in procedure 1 (operation 1), a UWB device 1700 may perform a procedure for exchanging UWB session parameters with another UWB device 1750 . In an embodiment, the UWB device 1700 may use a secure channel established using an OOB component (eg, a BLE component) for exchanging UWB session parameters. In one embodiment, the UWB session parameter is a ranging session key (UWB ranging session key) indicating a key used to secure a UWB ranging session and/or a session ID identifying an RDS (or a session associated with the RDS) may include. In one embodiment, the UWB session parameters may be generated by an Applet of the UWB device 1700 and/or another UWB device 1750 . The UWB session parameters exchanged through procedure 1 may be stored in the eSE 1730 .

In procedure 2 (operation 2), the framework 1720 may request the UWB parameters to the eSE 1730 , and the eSE 1730 may return the UWB parameters to the framework 1720 in response to the request. have. In one embodiment, the framework 1720 and the eSE 1730 may use a predefined OMAPI for exchanging UWB parameters. In one embodiment, the UWB parameters may include some or all of the UWB session parameters stored in the eSE 1730 . For example, the UWB parameter may include a session ID in the UWB session parameter. The UWB parameter may further include some or all of the UWB device information (eg, controlee info) parameters stored in the eSE 1730 .

In procedure 3 (operation 3), the framework 1720 and the UWBS 1740 may perform a procedure for setting UWB parameters. In one embodiment, the framework 1720 may pass the session ID to the UWBS 1740 . The framework 1720 and the UWBS 1740 may use a predefined UCI for setting UWB parameters.

In procedure 4 (operation 4), the UWBS 1740 may perform an operation to obtain security parameters from the eSE 1730 . For example, UWBS 1740 may look for a UWB session to retrieve security parameters. In one embodiment, the UWBS 1740 may obtain the RDS from the eSE 1730 using the session ID passed through the framework 1720 . In this case, the UWBS 1740 may acquire the RDS using a secure channel established between the UWBS 1740 and the eSE 1730 . In one embodiment, UWBS 1740 may use a predefined SUS API (eg, SUS external API) to obtain security parameters.

Meanwhile, in the case of the embodiment of FIG. 17 , in order for the framework 1720 to call the UWBS 1740 for security ranging, for example, a UWB session parameter (eg, a session ID) is required. Therefore, as in procedure 2 (operation 2), the UWB session parameters securely stored in the eSE 1730 must be decrypted and transmitted to the framework 1720 . In this case, a security parameter such as a session ID may be exposed, which may cause a security problem. In addition, in the case of the embodiment of FIG. 17, access rules must be set (eg, R/W from remote/local) for all parameters, which may cause a burden on access control. In addition, in the case of the embodiment of Fig. 17, due to the computational performance and memory constraints of the eSE 1730, there is a limit in processing a number of applications. Hereinafter, embodiments that can solve these problems will be described with reference to each drawing.

18 illustrates an exemplary configuration of a UWB device including a TEE according to an embodiment of the present disclosure.

Referring to FIG. 18 , the UWB device 1800 includes at least one application (UWB-enabled Application) 1810 , a framework 1820 , and/or a TEE 1830 . The UWB device 1800 may further include an OOB component. The framework 1820, UWBS 1833, UWB-enabled Application 1810, and OOB components of FIG. 18 are basically, for example, the frames described above in FIGS. 1 to 3 except for newly defined/described contents in this disclosure. You can follow the definition/description of work, UWBS, UWB-enabled Application, and OOB components.

Referring to FIG. 18 , the TEE 1830 may include at least one Trusted Application (TA) 1831 , a Trusted OS (Secure OS) 1832 , and/or a UWBS 1833 . In the embodiment of Figure 6, UWBS 1833 may be included in the TEE area, as shown. That is, the UWBS 1833 may be directly connected to the Secure OS (Driver TA) 1832 of the TEE 1830 . Thus, the UWBS 1833 may have a higher level of reliability and security than those located outside the TEE area.

The TEE 1830 is an environment for executing code, and may have a high level of trust. Reliability in the TEE 1830 has a higher level of trust in validity, isolation, and access control for items stored in the TEE area (space) when compared to a general-purpose software environment. can mean Accordingly, the TA 1831 and the Secure OS 1832 running in the TEE area may have higher reliability. In one embodiment, the TEE 1830 (or TA 1831 ) may communicate with other components via a predefined interface (eg, TEE Client API). For example, the TEE 1830 (or TA 1831 ) may communicate with the application 1810 through a predefined interface (eg, TEE Client API).

The TA 1831 is an application of the TEE 1830 and is referred to as a TA in order to be distinguished from the uncertain characteristics of the application in a Rich Operating System Execution Environment (REE). In the present disclosure, the TA 1831 (or the ADF of the TA) may serve to generate/store/deliver the RDS, and to the framework 1820 (or the UWBS 1833 in communication with the framework) It can serve as a contact point for In this disclosure, the TA 1831 may be identified by an ID (eg, UUID) defined for the TA. In this disclosure, the TA 1831 may be referred to as a FiRa TA. As described above, the RDS may include a ranging session key (UWB ranging session key) indicating a key used to secure a UWB ranging session and/or a session ID identifying the RDS (or session associated with the RDS). can In this case, the ranging session key and the session ID must be the same in the initiator and the responder. In addition, RDS at least one ranging parameter (eg, AoA (Angle of Arrival), proximity (Proximity Distance)), client-specific data and / or multicast responder-specific key (Multicast responder-specific key) optional may include more.

The Secure OS 1832 is an OS hosted by the TEE 1830 and may be a Trusted OS as distinct from a Rich OS (eg, Android) hosted by the rest of the device (REE). The TA 1831 and the Secure OS 1832 may communicate through a predefined TEE Core API. In general, the TA 1831 may operate in such a way that a command is issued to an external device (peripheral) through the Secure OS 1832 using the TEE Core API. In this disclosure, the Secure OS 1832 may be referred to as a driver TA.

Meanwhile, as in the embodiments of FIGS. 16 and 17 , when the security component of the UWB device is the eSE, communication between the UWBS and the eSE is performed through a method in which the UWBS transmits a command to the eSE. In contrast, as in the embodiment of FIG. 18 , in the case of the TEE, the TA generally communicates with the external device through a method of transmitting a command to the external device through the Secure OS. Therefore, when the UWBS is recognized as only one external device and the TA and UWBS communicate through the above-described general interfacing method, a burden of separately implementing the UWBS chipset for eSE and the UWBS chipset for TEE may occur. Therefore, a new scheme for interfacing between TA and UWBS needs to be considered.

Hereinafter, embodiments in which the UWBS and the TA included in the TEE communicate with each other will be exemplarily described with reference to each drawing. In the following embodiment, the UWBS communicates with the TA to obtain the RDS stored in the TA as an example, but is not limited thereto, and the UWBS obtains other types of security data/parameters stored in the TA. It is obvious to those skilled in the art that the same or similar contents to be described below may also be applied to the above.

Example 1: Example in which UWBS pulls RDS from TA (eg, UWBS operates as an initiator initiating a procedure for RDS delivery (acquisition), and TA operates as a responder responding to it)

Hereinafter, Embodiment 1 will be exemplarily described with reference to FIGS. 19 to 21 .

19 illustrates an operation of a UWB device including a TEE according to an embodiment of the present disclosure.

The UWB device of FIG. 19 may be, for example, the UWB device of FIG. 18 .

Referring to FIG. 19 , the UWB device 1900 may include a TEE 1910 and a framework 1920 . In one embodiment, the TEE 1910 may include a TA 1911 , a Secure OS (Driver TA) 1912 , and/or a UWBS 1913 . In the embodiment of FIG. 19, the UWBS 1913 included in the TEE area does not simply play the role of one external device (peripheral) from the point of view of the TA (or Secure OS) 1911, but initiates the RDS acquisition procedure. It can act as a subject. For example, the UWBS 1913 may operate as an initiator that transmits an RDS acquisition (request) command for security ranging. In this case, the TA 1911 may operate as a responder that transmits the RDS in response to the RDS acquisition command transmitted from the UWBS 1913 . Accordingly, in the embodiment of FIG. 19 , the TA 1911 does not operate in a manner that directly pushes the RDS to the UWBS 1913 using the TEE Core API.

19, the UWBS 1913 may request an RDS for security ranging from the TA 1911, and the TA 1911 may transmit the RDS to the UWBS 1913 in response to the request. In this case, regardless of the type of security component, UWBS may be implemented to perform a consistent operation (role) for the security component from the viewpoint of the UWBS 1913 . That is, regardless of whether the security component is a TEE or an SE (eSE), the UWBS operation (role) for the security component for RDS acquisition can be configured identically. Accordingly, design of the UWBS chipset can be facilitated because it is possible to design without distinction of security components.

In addition, in the case of the embodiment of FIG. 19 , as described above, the TA 1911 cannot perform a procedure of pushing the RDS using the previously defined TEE Core API. Accordingly, a secure channel for the entire path between the UWBS 1913 and the TA 1911, including the path between the UWBS 1913 and the Secure OS 1912, needs to be established.

In addition, in the case of the embodiment of FIG. 19 , a hardware interface (eg, Serial Peripheral Interface (SPI), inter-integrated circuit (I2C), etc.) for the UWBS 1913 may be separately defined for TEE and REE. In this case, a specific procedure (process) can be flexibly configured by using an interface for TEE or an interface for REE according to a required security level. For example, RDS-related processing for secure ranging may be performed through an interface for TEE, and for example, processing for general ranging may be configured to be performed through an interface for REE.

In addition, in the case of the embodiment of Fig. 19, the framework 1920 sends a command including the application ID and/or instance ID (random ID) of the application instead of transmitting the command including the session ID to the UWBS 1913. It can be transmitted to the TA (1911) and / or UWBS (1913).

Here, the application ID may be an ID for identifying an application, and the instance ID may be an ID (eg, a random value assigned to each session) for identifying a session instance associated with the application identified by the application ID. For example, when a plurality of sessions (session instances) are set for one application (application instance), each session of the corresponding application may be identified by an application ID and an instance ID. As another example, when only one session is established for one application, the session of the corresponding application may be identified by an instance ID (or application ID). As such, when using the application ID and/or instance ID instead of using the session ID to identify the session, a security problem caused by exposing the session ID (security parameter) to the framework 1920 for RDS acquisition can be resolved. In this disclosure, the instance ID may be referred to as a session instance ID.

An exemplary operation of the embodiment of FIG. 19 will be described below with reference to FIG. 21 .

20 illustrates an operation of a UWB device including a TEE and an SE according to an embodiment of the present disclosure.

Referring to FIG. 20 , the UWB device 2000 may include a TEE 2010 , an SE (eg, eSE) 2020 , and a framework 2030 . In one embodiment, TEE 2010 may include TA 2011 , Secure OS 2012 and/or UWBS 2013 .

The embodiment of FIG. 20 corresponds to a hybrid-type embodiment in which the TEE 2010 and the SE 2020 are used together as a security component. Therefore, it is necessary to efficiently configure the operation of the UWBS 2013 for each security component. That is, it is necessary to implement it in a way that improves compatibility.

The configuration and operation of the TEE 2010 of the embodiment of FIG. 20 may follow the configuration and operation of the TEE 1910 of the embodiment of FIG. 19 . For example, the UWBS 2013 is included in the TEE area, and a hardware interface (eg, SPI, I2C, etc.) for the UWBS 2013 may be separately defined for the TEE and the REE. In addition, the UWBS 2013 may request an RDS for security ranging to the TA 2011 , and the TA 2011 may transmit the RDS to the UWBS 2013 in response to the request. In addition, the framework 2030 sends a command including the application ID and/or instance ID (random ID) of the application to the TA (2011) for RDS acquisition, instead of transmitting the command including the session ID to the UWBS 2013 ) and/or UWBS (2013).

20 , since two types of security components are included in the UWB device 2000 , the UWB device 2000 may operate in two operation modes. For example, the UWB device 2000 may operate in a TEE mode or an SE (eSE) mode. Here, the TEE mode may be a mode in which the framework 2030 and the UWBS 2013 operate with the TEE 2011 (that is, a mode using the TEE 2011 as a security component), and the SE mode is the framework 2030 and UWBS 2013 may be in a mode in which SE (eSE) 2020 operates (ie, a mode using SE 2020 as a security component). In one embodiment, in TEE mode, UWBS 2013 may obtain security data (eg, RDS) from TEE 2010 (eg, TA 2011 of TEE), and in SE mode UWBS 2013 is secure Data (eg, RDS) may be obtained from SE 2020 (eg, SUS Applet of eSE).

In the TEE mode, as described above in FIG. 19 , the UWBS 2013 transmits a request (command) for RDS acquisition to the TA 2011, and the TA 2011 transmits the RDS to the UWBS 2013 in response to the request. ) can be passed as Similarly, in the SE mode, the UWBS 2013 forwards a request (command) for RDS acquisition to the SUS Applet of the eSE 2020, and the SUS Apple of the eSE 2020 responds to this request and transfers the RDS to the UWBS 2013 ) can be passed as As such, in both modes, the USBS 2013 can act as an initiator initiating the RDS acquisition procedure. That is, the UWBS 2013 may perform the same role and operation for RDS acquisition regardless of the type of security component. For example, UWBS 2013 may pass the same commands for RDS acquisition to a security component (TEE (TA) or SE). Therefore, it has the advantage that the UWBS chip design is easy.

Meanwhile, the command of the framework 2030 for the UWBS 2013 may be different depending on the operation mode. For example, in the TEE mode, the framework 2030 may transmit a command including the application ID and/or instance ID to the UWBS 2013 and/or the TA 2011, and in the SE mode, the framework 2030 (2013) may transmit a command including the session ID to the UWBS (2013).

As such, in the case of the hybrid method in which the TEE (2010) and the SE (2020) are used together, embodiment 1 with high compatibility (an embodiment in which UWBS pulls RDS from a security component (TA)) is advantageous in terms of chip design has As such, in the Hybrid case, the method of Example 1 may be advantageous compared to the method of Example 2, which will be described later.

21 illustrates a method for a first UWB device to perform security ranging with a second UWB device according to an embodiment of the present disclosure.

In the embodiment of FIG. 21 , the first UWB device 2100a may be the UWB device of FIG. 18 , and the second UWB device 2100b may be a device that performs security ranging with the first UWB device 2100a. . As shown, the first UWB device 2100a may include a UWBS 2113a, a TEE 2110a including a Secure OS 2112a and a TA 2111a, and a framework 2120a.

In the embodiment of FIG. 21 , the first UWB device 2100a corresponds to a UWB device operating according to the method (Example 1) described above with reference to FIG. 19 .

Referring to FIG. 21 , in operation 2101 , the second UWB device 2100b sends a SELECT command for selecting an object identified by an object ID (OID) to the first UWB device 2100a to the first UWB device 2100a. can be sent to In one embodiment, the SELECT command may include an OID. In one embodiment, the application may have a data structure including a root-level GDF and at least one ADF. In this case, the object may be one of at least one ADF included in the application. In one embodiment, the ADF may serve to generate/store/deliver the RDS.

In operation 2102, the framework 2120a of the first UWB device 2100a identifies an application (eg, an application including an ADF identified by the OID) associated with the object identified by the OID, the application ID of the application, and / or an instance ID (random ID) may be transmitted to the TA 2111a. As described above, the application ID may be an ID for identifying an application, and the instance ID may be an ID (eg, a random value assigned to each session) for identifying a session instance associated with the application identified by the application ID. For example, when a plurality of sessions (session instances) are set for one application (application instance), each session of the corresponding application may be identified by an application ID and an instance ID. As another example, when only one session is established for one application, the session of the corresponding application may be identified by an instance ID (or application ID). As such, when an application ID and/or an instance ID are used instead of using the session ID to identify the session, the security problem caused by exposing the session ID (security parameter) to the framework for RDS acquisition can be solved. can In this disclosure, the instance ID may be referred to as a session instance ID.

In operation 2103, the first UWB device 2100a and the second UWB device 2100b may establish a secure channel. A secure channel may be established between the TA 2111a of the first UWB device 2100a and a secure component (eg, TA or SUS Applet) of the second UWB device 2100b. In one embodiment, the secure channel may be established via OOB, such as BLE. Through this secure channel, UWB parameters can be exchanged.

In operation 2104, the TA 2111a may generate/prepare an RDS used for security ranging based on the exchanged UWB parameters.

In operation 2105, the TA 2111a may deliver a notification indicating that the RDS is ready to the framework 2120a.

In operation 2106 , the framework 2120a may transmit a PULL command to take the RDS from the TA 2111a to the UWBS 2113a . In one embodiment, the framework 2120a may send a PULL command along with an application ID and/or an instance ID. For example, the framework 2120a may transmit a PULL command including an application ID and/or an instance ID.

In operation 2107, the UWBS 2113a may transmit a SELECT command to the TA 2111a, and the TA 2111a may transmit a SELECT response corresponding to the SELECT command to the UWBS 2113a. In an embodiment, the SELECT command may include identification information (eg, UUID) of the TA 2111a. Through this, the TA 2111a to search for the RDS may be selected.

In operation 2108, the UWBS 2113a transmits a first authentication command (GENERAL AUTHENTICATE (Part 1 (1/2): GET RANDOM)) to the TA 2111a to obtain a random challenge from the TA 2111a. , and the TA 2111a may transmit a response corresponding to the first authentication command to the UWBS 2113a. Further, in operation 2109, in response to the random challenge, the UWBS 2113a, along with the encrypted challenge, a second authentication command (GENERAL AUTHENTICATE (Part 1 (2/2)) for establishing a secure channel with the TA 2111a: Mutual Authentication)) may be transmitted to the TA 2111a, and the TA 2111a may transmit a response corresponding to the second authentication command to the UWBS 2113a. Through these operations 2108 to 2109, a secure channel may be established between the UWBS 2113a and the TA 2111a.

In operation 2110, the UWBS 2113a may transmit a GET command (GET URSK) for obtaining the RDS to the TA 2111a, and the TA 2111a may transmit a Response corresponding to the GET command to the UWBS 2113a. . In one embodiment, this GET command may include a session ID (UWB session ID) to identify the RDS, and this Response may include RDS data (eg, ranging session key) corresponding to the session ID . Through this, UWBS can acquire RDS data.

In operation 2111, the UWBS 2113a may transmit a notification (Done) indicating that the UWBS 2113a has normally obtained RDS data to the framework 2120a. In one embodiment, this notification may be transmitted in response to the PULL command in operation 2106 .

In operation 2112, the UWBS 2113a may perform secure ranging with the UWBS of the second UWB device 2100b using the obtained RDS data. For example, the UWBS 2113a may perform secure ranging with the UWBS of the second UWB device 2100b by using the STS generated using the ranging session key of the RDS.

In this way, when the UWB device operates according to the first embodiment, it is possible to design the UWBS without distinction of security components, thereby making it easy to design the UWBS chipset. However, it is difficult to utilize the existing API of the TA, and it is necessary to establish a secure channel for the entire path between the UWBS and the TA, including the path between the UWBS and the Secure OA.

Each of the above-described operations exemplifies specific operations performed in each configuration, and the order of operations is not limited only to the order in which they are described. For example, each operation may be performed in an order different from the described order.

Hereinafter, an embodiment (Embodiment 2) different from Embodiment 1 focusing on compatibility will be exemplarily described with reference to FIGS. 22 to 23 . Embodiment 2 may be, for example, an embodiment centered on efficiency.

Embodiment 2: TA pushes RDS to UWBS (eg, TA operates as an initiator initiating a procedure for RDS delivery (acquisition), and UWBS operates as a responder responding thereto)

Hereinafter, Embodiment 2 will be exemplarily described with reference to FIGS. 22 to 23 .

22 illustrates an operation of a UWB device including a TEE according to another embodiment of the present disclosure.

The UWB device of FIG. 22 may be, for example, the UWB device of FIG. 18 .

Referring to FIG. 22 , the UWB device 2200 may include a TEE 2210 and a framework 2220 . In one embodiment, TEE 2210 may include TA 2211 , Secure OS 2212 and/or UWBS 2213 . In the embodiment of FIG. 22 , the UWBS 2213 included in the TEE area performs the role of one external device (peripheral) from the viewpoint of the TA 2211 (or the Secure OS 2212). Therefore, unlike the embodiment of FIG. 19 , in the embodiment of FIG. 22 , the TA 2211 may operate by directly pushing the RDS to the UWBS 2213 using the TEE Core API. That is, regardless of the request of the UWBS 2213 , the TA 2211 may deliver the RDS to the UWBS 2213 . Therefore, it has the advantage of being easy to implement. That is, Embodiment 2 is more advantageous than Embodiment 1 in terms of operational efficiency of the TA.

In addition, in the case of the embodiment of Fig. 22, since secure communication is performed through a predefined TEE Core API between the TA 2211 and the Secure OA 2212, for RDS delivery, not the entire path, but the Secure OA 2212 ) and only the secure channel for the path between the UWBS 2213 needs to be established.

In addition, in the case of the embodiment of FIG. 22 , a hardware interface (eg, SPI, I2C, etc.) for the UWBS 2213 may be separately defined for TEE and REE. In this case, a specific procedure (process) can be flexibly configured by using an interface for TEE or an interface for REE according to a required security level. For example, RDS-related processing for secure ranging may be performed through an interface for TEE, and for example, processing for general ranging may be configured to be performed through an interface for REE.

In addition, in the case of the embodiment of FIG. 22 , the framework sends a command including the application ID and/or instance ID (random ID) of the application to the TA 2211 instead of sending the command including the session ID to the UWBS 2213 . ) and/or UWBS 2213 .

Here, the application ID may be an ID for identifying an application, and the instance ID may be an ID (eg, a random value assigned to each session of the application) for identifying a session instance associated with the application identified by the application ID. For example, when a plurality of sessions (session instances) are set for one application (application instance), each session of the corresponding application may be identified by an application ID and an instance ID. As another example, when only one session is established for one application, the session of the corresponding application may be identified by an instance ID (or application ID). As such, when an application ID and/or an instance ID are used instead of using the session ID to identify the session, the security problem caused by exposing the session ID (security parameter) to the framework for RDS acquisition can be solved. can In this disclosure, the instance ID may be referred to as a session instance ID.

However, in the case of the embodiment (Example 2) of FIG. 22, when SE (eSE) is used together with the TEE 2210, the operation of the UWBS 2213 for the TEE 2210 and the UWBS 2213 for the SE In comparison with the embodiment (Embodiment 1) in FIG. 19, since the operation of , must be implemented separately, it is not easy in terms of chip design. Accordingly, Embodiment 2 may be more advantageous in the case of using only TEE as a security component.

An exemplary operation of the embodiment of FIG. 22 will be described below with reference to FIG. 23 .

23 illustrates a method for a first UWB device to perform security ranging with a second UWB device according to another embodiment of the present disclosure.

In the embodiment of FIG. 23 , the first UWB device 2300a may be the UWB device of FIG. 18 , and the second UWB device 2300b may be a device that performs security ranging with the first UWB device 2300a . . As shown, the first UWB device 2300a may include a UWBS 2313a, a TEE 2310a including a Secure OS 2312a and a TA 2311a, and a framework 2320a.

In the embodiment of FIG. 23 , the first UWB device 2300a corresponds to the UWB device operating according to the method (Example 2) described above with reference to FIG. 22 .

Referring to FIG. 23 , in operation 2301 , the second UWB device 2300b may transmit a SELECT command for selecting an object identified by an object ID (OID) to the first UWB device 2300a. In one embodiment, the SELECT command may include an OID. In one embodiment, the application may have a data structure including a root-level GDF and at least one ADF. In this case, the object may be one of at least one ADF. In one embodiment, the ADF may serve to generate/store/deliver the RDS.

In operation 2302 , the framework 2320a of the first UWB device 2300a identifies an application (eg, an application including an ADF identified by the OID) associated with the object identified by the OID, the ID of the application and/or Alternatively, an instance ID (random ID) may be transmitted to the TA 2311a.

Here, the application ID may be an ID for identifying an application, and the instance ID may be an ID (eg, a random value assigned to each session) for identifying a session instance associated with the application identified by the application ID. For example, when a plurality of sessions (session instances) are set for one application (application instance), each session of the corresponding application may be identified by an application ID and an instance ID. As another example, when only one session is established for one application, the session of the corresponding application may be identified by an instance ID (or application ID). As such, when an application ID and/or an instance ID are used instead of using the session ID to identify the session, the security problem caused by exposing the session ID (security parameter) to the framework for RDS acquisition can be solved. can In this disclosure, the instance ID may be referred to as a session instance ID.

In operation 2203, the first UWB device 2300a and the second UWB device 2300b may establish a secure channel. A secure channel may be established between the TA 2311a of the first UWB device 2300a and a secure component (eg, TA or SUS Applet) of the second UWB device 2300b. In one embodiment, the secure channel may be established via OOB, such as BLE. Through this secure channel, UWB parameters can be exchanged.

In operation 2304 , the TA 2311a may generate an RDS used for security ranging based on the exchanged UWB parameters.

In operation 2305, the TA 2311a may deliver a notification indicating that the RDS is ready to the framework 2320a.

In operation 2306 , the framework 2320a may transmit a PUSH command to send an RDS to the UWBS (ie, a PUSH command for the TA to push the RDS to the UWBS) to the TA 2311a. In one embodiment, the framework 2320a may send the PUSH command together with the application ID and the instance ID. For example, the framework 2320a may transmit a PUSH command including an application ID and an instance ID.

In operation 2307 , the TA 2311a may transmit a request for establishing a secure channel between the Secure OS 2312a and the UWBS 2313a to the Secure OS (Driver TA) 2312a. In the TEE 2310a, between the TA 2311a and the Secure OS 2312a is in a secure state, so in order to safely transfer the RDS generated in the TA 2311a to the UWBS 2313a, between the Secure OS 2312a and the UWBS 2313a A secure channel needs to be established. Hereinafter, a procedure for establishing a secure channel between the Secure OS 2312a and the UWBS 2313a through operations 2308 to 2312 will be described.

In operation 2308, the Secure OS 2312a may generate a random value p, and transmit the generated random value p to the UWBS 2313a. In operation 2309, the UWBS 2313a may generate a session key K (eg, a session key for security of a message) based on the random value p. For example, the UWBS 2313a may generate the session key K based on the received random value p and/or the random value q generated by the UWBS 2313a. Also, the UWBS 2313a may generate encrypted data (cryptogram) based on the session key (K).

In operation 2310 , the UWBS 2313a may transmit the generated cryptogram and/or the random value q to the Secure OS 2312a. In operation 2311, the Secure OS 2312a may generate a session key K based on the random value q. For example, the Secure OS 2312a may generate the session key K based on the received random value q and/or the random value p generated by the Secure OS 2312a. Also, the Secure OS 2312a may generate encrypted data (cryptogram) based on the session key (K).

In operation 2312 , the Secure OS 2312a may transmit the generated cryptogram to the UWBS 2313a. Through this, the same session key K can be shared between the Secure OS 2312a and the UWBS 2313a, and subsequent operations can be protected using this session key K. Through these operations 2308 to 2312, a secure channel may be established between the UWBS 2313a and the Secure OS 2312a.

In operation 2313, the Secure OS 2312a determines that a notification (OK) indicating that a secure channel has been established between the UWBS 2313a and the Secure OS 2312a or that a secure channel is not established between the UWBS 2313a and the Secure OS 2312a. A notification (NOK) may be transmitted to the TA 2311a. In one embodiment, this notification may be transmitted in response to the request of operation 2307 .

In operation 2314, when a secure channel is established between the UWBS 2313a and the Secure OS 2312a, the TA 2311a may deliver the RDS to the UWBS 2313a through the secure channel. For example, the TA 2311a may transmit the RDS to the UWBS 2313a through the Secure OS 2312a using the session key K. For example, the TA 2311a may encrypt the RDS using the session key K and transmit it to the UWBS 2313a.

In operation 2315 , the UWBS 2313a may perform secure ranging with the UWBS of the second UWB device 2300b using the obtained RDS data. For example, the UWBS 2313a may perform secure ranging with the UWBS of the second UWB device 2300b by using the STS generated using the ranging session key of the RDS.

Each of the above-described operations exemplifies specific operations performed in each configuration, and the order of operations is not limited only to the order in which they are described. For example, each operation may be performed in an order different from the described order.

24 shows the configuration of a UWB device according to an embodiment of the present disclosure.

The UWB device of FIG. 24 may be an example of the UWB device of FIG. 18 .

Referring to FIG. 24 , a UWB device 2400 may include a TEE 2410 , a framework 2420 , and at least one application (UWB-enabled Application) 2430 . At least one application 2430 is located outside the TEE, and may be distinguished from the TA 2411, which is an application inside the TEE. The application 2430 outside the TEE has lower security than the TA 2411 . In the present disclosure, the framework 2420 may be referred to as a FiRa framework, the application 2430 may be referred to as a FiRa application, and the TA 2411 may be referred to as a FiRa TA.

In one embodiment, the TEE 2410 may include at least one TA 2411 , a Secure OS (Driver TA) 2412 , and/or a UWBS 2413 . The TA 2411 and the Secure OS 2412 may communicate through the TEE core API, and the TA 2411 and other components outside the TEE (eg, the application 2430) may communicate through the TEE Client API.

In one embodiment, the TA 2411 may include at least one ADF. An ADF may be identified by an OID. For example, as shown, the TA 2411 may include an ADF identified by OID#1 and an ADF identified by OID#2. In this case, each ADF may include an application certificate (AppCert), an application ID (AppID), an instance ID, and/or a secure channel key parameter (SC Key Parameter) (eg, secure channel key ID) of the corresponding application.

In one embodiment, the framework 2420 is one of an application certificate (AppCert), an application ID (AppID), an instance ID, and/or a secure channel key parameter (SC Key Parameter) (eg, secure channel key ID) stored in each ADF. It may include at least one. Through this, the framework 2420 may identify a message delivered from an external UWB device and serve to connect it to a specific TA 2411 . For example, when a specific OID is called from an external UWB device, the framework 2420 identifies it and passes the APP ID and/or instance ID of the application associated with the OID to the TA 2411, so that the TA 2411 is You can identify the session of the corresponding application. In this case, the TA 2411 transmits the RDS associated with the session to the UWBS 2413 in response to the request of the UWBS 2413 according to a preset scheme, or the RDS associated with the session regardless of the request of the UWBS 2413 . RDS can be pushed to UWBS 2413 .

25 is a flowchart illustrating a method of a UWB device according to an embodiment of the present disclosure.

In the embodiment of FIG. 25 , the UWB device may be the UWB device of FIG. 18 or the UWB device of FIG. 24 . The operation of the UWB device of FIG. 25 may be the operation according to the first embodiment described with reference to FIGS. 19 to 21 .

Referring to FIG. 25 , the UWB subsystem may receive a command (PULL command) to get a ranging data set (RDS) for secure ranging from the security application (TA) from the framework ( 2510 ).

The UWB subsystem may establish a secure channel with the secure application based on the command ( 2520 ). The procedure for establishing a secure channel between the UWB subsystem and the secure application may refer to the description of FIG. 21 .

The UWB subsystem may receive the RDS through a secure channel established from the secure application (2530). In one embodiment, the security application may forward the RDS in response to the request of the UWB subsystem. The RDS delivery procedure may refer to the description of FIG. 9 .

In one embodiment, the UWB subsystem and the security application are included in the TEE area, and the RDS may include a ranging session key used to secure the UWB ranging session.

In an embodiment, the PULL command may include at least one of an application ID of the application or an instance ID associated with one of at least one session established by the application.

In one embodiment, a first interface for communicating with a component within the TEE area and a second interface for communicating with a component outside the TEE area may be configured for the UWB subsystem.

In one embodiment, the framework may be included outside the TEE area.

In an embodiment, the UWB subsystem may perform secure ranging with the UWB subsystem of another UWB device by using the ranging session key included in the RDS.

26 is a flowchart illustrating a method of a UWB device according to another embodiment of the present disclosure.

In the embodiment of FIG. 26 , the UWB device may be the UWB device of FIG. 18 or the UWB device of FIG. 24 . The operation of the UWB device of FIG. 26 may be the operation according to the first embodiment described with reference to FIGS. 19 to 21 .

Referring to FIG. 26 , the security application (TA) may receive a command to transmit a ranging data set (RDS) for secure ranging to the UWB subsystem from the framework ( 2610 ).

The secure application may transmit a request for establishing a secure channel between the secure OS of the secure application and the UWB subsystem to the secure OS based on the command ( 2620 ). The procedure for establishing a secure channel between the secure OS and the UWB subsystem may refer to the description of FIG. 23 .

The secure application may deliver the RDS to the UWB subsystem through the established secure channel (2630).

27 is a diagram illustrating a structure of an electronic device according to an embodiment of the present disclosure.

In the embodiment of FIG. 27 , the electronic device may correspond to the UWB device of FIG. 18 , an electronic device including the UWB device of FIG. 18 , or an electronic device included in some components of the UWB device of FIG. 18 .

Referring to FIG. 27 , the electronic device may include a transceiver 2710 , a control unit 2720 , and a storage unit 2730 . In the present disclosure, the controller may be defined as a circuit or an application-specific integrated circuit or at least one processor.

The transceiver 2710 may transmit/receive a signal to/from another entity. The transceiver 2710 may transmit/receive data for UWB ranging, for example.

The controller 2720 may control the overall operation of the electronic device according to the embodiment proposed in the present disclosure. For example, the controller 2720 may control a signal flow between blocks to perform an operation according to the above-described flowchart. Specifically, the controller 2720 may control, for example, the operation of the electronic device described with reference to FIGS. 13 to 26 .

The storage unit 2730 may store at least one of information transmitted and received through the transceiver 2710 and information generated through the control unit 2720 . For example, the storage unit 2730 may store, for example, information and data necessary for the security ranging described with reference to FIGS. 13 to 26 . In specific embodiments of the present disclosure described above, components included in the present disclosure Elements are expressed in the singular or plural according to the specific embodiment presented. However, the singular or plural expression is appropriately selected for the context presented for convenience of description, and the present disclosure is not limited to the singular or plural element, and even if the element is expressed in plural, it is composed of the singular or singular. Even an expressed component may be composed of a plurality of components.

Meanwhile, although specific embodiments have been described in the detailed description of the present disclosure, various modifications are possible without departing from the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the described embodiments and should be defined by the claims described below as well as the claims and equivalents.

Claims (15)

A method of an electronic device for performing secure ranging, the method comprising:
sending a request for establishing a ranging data set for the secure ranging to a security component; and
sending a request to the security component to deliver the ranging data set to the UWB subsystem;
and the ranging data set is transferred from the secure component to the UWB subsystem using a secure channel established between the secure component and the UWB subsystem.
According to claim 1,
The operation of sending a request for setting the ranging data set includes:
and calling, by the security component, a framework API requesting to set the ranging data set, wherein the framework API includes an application ID for identifying an application that called the framework API.
According to claim 1,
Transmitting a request for transferring the ranging data set to the UWB subsystem includes:
and calling, by the security component, a framework API requesting to transmit the ranging data set to the UWB subsystem, wherein the framework API receives an application ID for identifying an application that called the framework API. Including method.
According to claim 1,
Transmitting a request for transferring the ranging data set to the UWB subsystem includes:
and an application passing a command to the UWB subsystem to obtain the ranging data set with the security component.
According to claim 1,
The ranging data set includes at least one of session ID information for the UWB session associated with the secure ranging, and session key information for protecting the UWB session.
According to claim 1,
further comprising, by the framework, sending a command to start the security ranging to the UWB subsystem,
The method of claim 1, wherein the command to initiate secure ranging includes an application ID for identifying an application associated with the secure ranging.
The method of claim 1,
and the secure channel between the secure component and the UWB subsystem is an asymmetric key based secure channel.
According to claim 1,
The method of claim 1, wherein the security component is a Trusted Execution Environment (TEE) or Strongbox.
An electronic device for performing security ranging, comprising:
Memory; and
a processor coupled to the memory, the processor comprising:
sending a request for setting a ranging data set for the secure ranging to a security component;
send to the secure component a request to forward the ranging data set to the UWB subsystem;
and the ranging data set is transferred from the secure component to the UWB subsystem using a secure channel established between the secure component and the UWB subsystem through the framework.
10. The method of claim 9,
The operation of sending a request for setting the ranging data set includes:
and calling, by the security component, a framework API for requesting to set the ranging data set, wherein the framework API includes an application ID for identifying an application that has called the framework API. .
10. The method of claim 9,
Transmitting a request for transferring the ranging data set to the UWB subsystem includes:
and calling, by the security component, a framework API requesting to transmit the ranging data set to the UWB subsystem, wherein the framework API receives an application ID for identifying an application that called the framework API. including, an electronic device.
10. The method of claim 9,
The ranging data set includes at least one of session ID information for the UWB session associated with the secure ranging, and session key information for protecting the UWB session.
10. The method of claim 9,
the processor is further configured to send a command to initiate the secure ranging to the UWB subsystem;
The command for starting the security ranging includes an application ID for identifying an application related to the security ranging.
10. The method of claim 9,
and the secure channel between the secure component and the UWB subsystem is an asymmetric key based secure channel.
10. The method of claim 9,
The electronic device, wherein the security component is a Trusted Execution Environment (TEE) or Strongbox.

Images