Patent ID: 12245024

DETAILED DESCRIPTION

Hereinafter, various embodiments are described in detail with reference to the accompanying drawings.

In describing embodiments, the description of technologies that are known in the art and are not directly related to the present invention is omitted. This is for further clarifying the gist of the present disclosure without making the present disclosure unclear.

For the same reasons, some elements may be exaggerated or schematically shown. The size of each element does not necessarily reflect the actual size of the element. The same reference numeral is used to refer to the same element throughout the drawings.

Advantages and features, and methods for achieving the same may be understood through the embodiments to be described below taken in conjunction with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed herein, and various changes may be made thereto. The embodiments disclosed herein are provided only to inform one of ordinary skilled in the art of the category of the present disclosure. The present disclosure is defined only by the appended claims. The same reference numeral denotes the same element throughout the specification.

The blocks in each flowchart and combinations of the flowcharts may be performed by computer program instructions. Since the computer program instructions may be equipped in a processor of a general-use computer, a special-use computer or other programmable data processing devices, the instructions executed through a processor of a computer or other programmable data processing devices generate means for performing the functions described in connection with a block(s) of each flowchart. Since the computer program instructions may be stored in a computer-available or computer-readable memory that may be oriented to a computer or other programmable data processing devices to implement a function in a specified manner, the instructions stored in the computer-available or computer-readable memory may produce a product including an instruction means for performing the functions described in connection with a block(s) in each flowchart. Since the computer program instructions may be equipped in a computer or other programmable data processing devices, instructions that generate a process executed by a computer as a series of operational steps are performed over the computer or other programmable data processing devices and operate the computer or other programmable data processing devices may provide steps for executing the functions described in connection with a block(s) in each flowchart.

Further, each block may represent a module, segment, or part of a code including one or more executable instructions for executing a specified logical function(s). Further, it should also be noted that in some replacement execution examples, the functions mentioned in the blocks may occur in different orders. For example, two blocks that are consecutively shown may be performed substantially simultaneously or in a reverse order depending on corresponding functions.

As used herein, the term unit means a software element or a hardware element such as a field-programmable gate array (FPGA) or an application specific integrated circuit (ASIC). A unit plays a certain role. However, the term unit is not limited as meaning a software or hardware element. A unit may be configured in a storage medium that may be addressed or may be configured to reproduce one or more processors. Accordingly, as an example, a unit includes elements, such as software elements, object-oriented software elements, class elements, and task elements, processes, functions, attributes, procedures, subroutines, segments of program codes, drivers, firmware, micro codes, circuits, data, databases, data architectures, tables, arrays, and variables. A function provided in an element or a unit may be combined with additional elements or may be split into sub elements or sub units. Further, an element or a unit may be implemented to reproduce one or more CPUs in a device or a security multimedia card. According to embodiments, a unit may include one or more processors.

As used herein, the term terminal or device may also be referred to as a mobile station (MS), user equipment (UE), user terminal (UT), terminal, wireless terminal, access terminal (AT), subscriber unit, subscriber station (SS), wireless device, wireless communication device, wireless transmit/receive unit (WTRU), mobile node, or mobile or may be referred to in other terms. Various embodiments of the terminal may include cellular phones, smart phones with wireless communication capabilities, personal digital assistants (PDAs) with wireless communication capabilities, wireless modems, portable computers with wireless communication capabilities, capturing/recording/shooting/filming devices, such as digital cameras, having wireless communication capabilities, game players with wireless communications capabilities, music storage and playback home appliances with wireless communications capabilities, Internet home appliances capable of wireless Internet access and browsing, or portable units or terminals incorporating combinations of those capabilities. Further, the terminal may include a M2M terminal and a MTC terminal/device, but is not limited thereto. In the disclosure, the terminal may be referred to as an electronic device or simply as a device.

Hereinafter, the operational principle of the disclosure is described below with reference to the accompanying drawings. When determined to make the subject matter of the present disclosure unclear, the detailed of the known functions or configurations may be skipped. The terms as used herein are defined considering the functions in the present disclosure and may be replaced with other terms according to the intention or practice of the user or operator. Therefore, the terms should be defined based on the overall disclosure.

Hereinafter, embodiments are described in detail with reference to the accompanying drawings. Further, although a communication system using UWB is described in connection with embodiments of the present disclosure, as an example, embodiments of the present disclosure may also apply to other communication systems with similar technical background or features. For example, a communication system using Bluetooth or ZigBee may be included therein. Further, embodiments of the present disclosure may be modified in such a range as not to significantly depart from the scope of the present disclosure under the determination by one of ordinary skill in the art and such modifications may be applicable to other communication systems.

When determined to make the subject matter of the present disclosure unclear, the detailed description of the known art or functions may be skipped. The terms as used herein are defined considering the functions in the present disclosure and may be replaced with other terms according to the intention or practice of the user or operator. Therefore, the terms should be defined based on the overall disclosure.

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 the recognition distance. In this case, WLAN is a technology based on IEEE 802.11 which enables access to the backbone network within a radius of about 100 m. WPAN is a technology based on IEEE 802.15 which includes Bluetooth, ZigBee, and 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 may enable secure and accurate ranging between devices.

Operations of a UWB-based service may include a service initiation step for initiating the UWB-based service, a key provisioning step for providing a key for security, 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 distance/direction (angle) between devices. According to some embodiments, some steps may be omitted or additional steps may be added.

The terminology used herein is provided for a better understanding of the disclosure, and changes may be made thereto without departing from the technical spirit of the disclosure.

Application dedicated file (ADF) may be, e.g., a data structure capable of hosting application specific data or security data (e.g., credential, cryptographic key) used by an application or SE (e.g., embedded SE (eSE)).

Application protocol data unit (APDU) may be a command and a response used when communicating with a secure element (eSE).

Application specific data may be, e.g., data used by a specific service and application regardless of the place (e.g., applet, device, etc.).

Controller may be a ranging device that defines and controls ranging control messages (RCM) (or control messages). In the disclosure, the ranging device may be, e.g., a ranging device (RDEV) or an enhanced ranging device (ERDEV) as defined in the IEEE Std 802.15.4/4z standard.

Controllee may be a ranging device using a ranging parameter in the RCM (or control message) received from the controller.

Unlike static STS, dynamic scrambled timestamp sequence (STS) may be an operation mode in which the STS is not repeated during a ranging session. In an embodiment, the STS may be managed by the ranging device, and the ranging session key that generates STS may be managed by a secure component.

Applet may be an applet that implements an APDU interface running on a secure component and is identified by an application (applet) ID (AID). This applet may host the data needed for secure ranging. In an embodiment, the applet may be, e.g., a FiRa applet.

“Ranging device” is a device that may communicate with another ranging device using a pre-defined profile (e.g., UWB-enabled door lock) or a device capable of supporting a pre-defined UWB ranging service for performing 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 an embodiment, the ranging device may be, e.g., a FiRa device.

UWB-enabled application may be an application using a Framework API for configuring an OOB Connector, a Secure Service, and/or a UWB service for a UWB session. In this disclosure, UWB-enabled Application may be abbreviated as an application or a UWB application. In an embodiment, the UWB-enabled application may be, e.g., a FiRa-enabled application.

Framework may be, e.g., a collection of logical software components including an out-of-band (OOB) connector, secure Service, and/or UWB service. In an embodiment, the framework may be, e.g., FiRa Framework.

OOB Connector may be a software component for establishing OOB communication (e.g., Bluetooth low energy communication) between ranging devices. In an embodiment, the OOB connector may be, e.g., a FiRa OOB connector.

Profile may be a previously defined set of UWB and OOB configuration parameters. In an embodiment, the profile may be, e.g., a FiRa profile.

Profile manager may implement a profile available on the ranging device. In an embodiment, the profile manager may be, e.g., a FiRa profile manager.

Smart ranging device may be a ranging device (e.g., physical access reader) capable of hosting one or more UWB-enabled applications and implementing the framework or a ranging device that implements a specific screen application provided by the manufacturer. The smart ranging device may be a ranging device capable of installing multiple UWB-enabled applications to support a UWB ranging-based service to perform a ranging session with another ranging device or smart ranging device. In an embodiment, the smart ranging device may be, e.g., a FiRa smart device.

Global dedicated file (GDF) may be a root level of application specific data including data required to establish a USB session.

Framework application programming interface (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 for identifying a service provider (SP).

OOB may be data communication that does not use UWB as an underlying wireless technology.

Responder may be a ranging device that responds to the Initiator in a ranging exchange.

STS may be a ciphered sequence for increasing the integrity and accuracy of ranging measurement timestamps. In an embodiment, the STS may be generated from the ranging session key.

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

Secure component may be a component that interfaces with UWBS for the purpose of providing RDS to UWBS, e.g., when dynamic STS is used. It may also host UWB-enabled application data.

SE may be a tamper-resistant secure hardware component that may be used as a secure component in the Ranging Device.

Secure service may be a component for interfacing with the secure component of the system, such as a TEE or secure element.

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

Secure UWB service (SUS) applet may be an applet on the secure component operating as an end point for the secure channel between secure components, such as UWBS and SE.

UWB service may be a component that provides access to the UWBS.

UWB session may be a session that may be established when the controller and controllee(s) may start UWB ranging. A UWB session may be a period from when the controller and the controlee start communication through UWB until when the controller and the controlee stop the communication. A UWB Session may include ranging, data transfer, and both.

UWB session ID may be an ID (e.g., an integer) for identifying the UWB session.

UWB Session Key may be a key used to protect the UWB Session. In an embodiment, the UWB session key may be used to generate the STS. In this disclosure, the UWB Session Key may be a UWB Ranging Session Key (URSK), and may be abbreviated as a session key.

UWB Subsystem (UWBS) may be a hardware component implementing the UWB PHY and MAC specifications. UWBS may have an interface to framework and an interface to secure component to search for RDS.

FIG.1illustrates an electronic device supporting a UWB-based service according to an embodiment.

The electronic device (UWB device)100ofFIG.1may be an electronic device supporting UWB ranging (e.g., UWB secure ranging), e.g., a smart ranging device.

Referring toFIG.1, the electronic device100includes a UWB-enabled application layer110, a common service & management layer120, and a UWBS130including a UWB MAC layer and a UWB physical layer. Alternatively, some layers may not be included in the electronic device100, or an additional layer (e.g., secure layer) may further be included.

The UWB-enabled application layer110is a layer of an application (e.g., FiRa-enabled application) using the framework API to constitute an OOB connector, secure service, and UWB service for, e.g., a UWB session.

The common service & management layer120defines a common component and procedure necessary to implement, e.g., UWB secure ranging.

The UWBS130is a component that includes a UWB MAC layer and a UWB physical layer. The UWBS may perform UWB-based communication for ranging (e.g., secure ranging) with the UWBS of another UWB device.

FIG.2illustrates a communication system including an electronic device supporting a UWB-based service according to an embodiment.

Referring toFIG.2, a communication system200includes a first electronic device210and a second electronic device220. In an embodiment, the first electronic device (first UWB device)210may be, e.g., a smart ranging device, and the second electronic device (second UWB device)220may be, e.g., a ranging device. Both the first electronic device and the second electronic device may support UWB ranging (e.g., UWB secure ranging).

The first electronic device210may host one or more UWB-enabled applications211which may be installed by the user (e.g., a mobile phone application based on the framework API.) The second electronic device220does not provide a framework API, and may use a proprietary interface to implement a specific UWB-enabled application221provided only by the manufacturer.

Alternatively, both the first electronic device210and the second electronic device220may be smart ranging devices or ranging devices.

The first electronic device210and the second electronic device220may respectively include a UWB-enabled application layer211,221, a framework212,222, an OOB component/connector213,223, a secure component214,224, and/or a UWBS215,225. The framework API, framework, OOB connector and/or secure component may be included in the framework, and some components may be omitted according to an embodiment.

The first electronic device210and the second electronic device220may generate an OOB connection (channel) through the OOB connector213,223(e.g., BLE connector) generate a UWB connection (channel) through the UWBS215,225, and communicate with each other.

FIG.3illustrates a framework included in an electronic device supporting a UWB-based service according to an embodiment.

The framework300ofFIG.3may be a FiRa framework.

The framework300may be a set of logical software components. The UWB-enabled application may interface with the framework300through the framework API provided by the framework300.

Referring toFIG.3, the framework300includes a profile manager310, an OOB connector320, a secure service330, and a UWB service340. Alternatively, some components may be omitted, and an additional component may further be included.

The profile manager310may manage a profile(s) available on the ranging device. The profile may be a set of UWB and OOB configuration parameters required to establish a successful UWB session between ranging devices. The profile manager310may abstract the UWB and OOB configuration parameters from the UWB-enabled application.

The OOB connector320may be a component for establishing an OOB connection between ranging devices. The OOB connector320may serve to interface with the00B connector. The OOB connector320may handle the discovery phase and connection phase for providing a UWB-based service.

The secure service330may serve to interface with a secure component, such as an SE, eSE, or a TEE. The secure component may be a component that interfaces with the UWBS to transfer UWB ranging data to the UWBS.

The SE is a safe secure module based on tamper resistant characteristics and, if no contract relationship is established between various entities, installation and driving of an application are limited.

The eSE means a fixed SE fixed and used in the electronic device. Typically, the eSE is produced only for the terminal manufacturer at the request of the terminal manufacturer and include an operating system and/or a framework. For the eSE, a service control module in the form of an applet may be remotely downloaded and installed and be used for various security services, such as e-wallet, ticketing, e-passport, or digital key.

The TEE may be an S/W-centered security environment that creates a virtual separated environment based on, e.g., a code supported by a specific chipset (e.g., ARM-based). The TEE has tamper resistant characteristics but has the advantages of large available memory, high speed, and low costs as compared with the SE. Further, since various service providers are immediately available within a range allowed by the mobile manufacturer, the TEE has the advantage of low complexity between entities as compared with the SE.

The UWB service340may be a component that provides access to the UWBS.

FIG.4illustrates an operation in which a UWB device including an SE performs secure ranging with another UWB device according to an embodiment.

InFIG.4, the first UWB device410may be a UWB device (e.g., FiRa smart device) including a secure element (e.g., eSE) as a secure component. The second UWB device420may be a UWB device (e.g., FiRa device) that performs secure ranging with the first UWB device410. The service provider430may be an entity that provides the UWB-enabled application and plays a role to provision a key for secure ranging.

As described above, the SE is a safe security module based on the tamper resistant characteristics, and the eSE means a fixed SE fixed and used in the electronic device.

Referring toFIG.4, the first electronic device410includes a UWB-enabled application411, a framework412, an OOB component413, an SE414, and a UWBS415. The second electronic device420includes an application421, an OOB component422, and a UWBS423. The UWB-enabled application, framework, and OOB component have been described above in connection withFIGS.1to3.

The SE (e.g., eSE)414includes an applet (service applet)414aand/or a secure UWB service (SUS) applet414b. The applet414amay include at least one ADF required to safely generate an RDS. For example, as shown, the applet414amay include each ADF (ADF (SP1) and ADF (SP2)) provided by each SP. The ADF may be provided by the service provider in the key provisioning step. Further, the applet414amay transfer the RDS through the SUS applet414bto the UWBS415. In an embodiment, the RDS may include a session ID and/or UWB session key for the UWB session.

The UWBS415manages the UWB hardware. The UWBS415may perform a UWB session with the UWBS of another ranging device. The UWBS415may be managed by the framework and receive an RDS necessary for secure ranging from the SE414.

Referring toFIG.4, in operation 1, the first UWB device410and the second UWB device420may perform a service discovery procedure through respective OOB components413,422. The service discovery procedure may include a secure channel (SC) negotiation operation. Thus, parameters for configuring an SC may be exchanged.

In operation 2, to safely share data, the first UWB device410and the second UWB device420may configure a secure channel (e.g., SC #1 and SC #2) therebetween, through the framework. The secure channel may be open through an OOB channel (connection). Through this secure channel, the RDS data including the UWB session key and/or session ID may be exchanged between the first UWB device410and the second UWB device420. In an embodiment, the RDS data may be generated by the applet.

The RDS may include a ranging session key (UWB ranging session key) indicating the key used for securing the UWB ranging session and/or a session ID for identifying the RDS (or session associated with the RDS). In this case, the ranging session key and session ID should be the same in the initiator and the responder. Optionally, the RDS may further include at least one ranging parameter (e.g., angle of arrival (AoA), proximity distance), the AID of the applet to perform final authentication through a UWB secure channel, client-specific data and/or a multicast responder-specific key.

In operation 3, the RDS data including the UWB session key and the session ID may be exchanged between the applet414aand the SUS applet414b. For example, the URSK of the applet414amay be transferred to the SUS applet414bthrough communication with the SUS applet414b. Further, the RDS data transferred to the SUS applet414bmay be transferred to the UWBS415for secure ranging. To that end, a secure channel between the applet and the SUS applet414band a secure channel between the SUS applet414band the UWBS415may first be configured. The UWBS415may obtain the corresponding RDS from the SUS applet414bthrough the configured secure channel.

In operation 4, the first UWB device410and the second UWB device420may perform a secure ranging procedure. The obtained UWB session key may be used by the UWBSs415,423for secure ranging. For example, the UWB session key may be used to generate an STS used for secure ranging.

FIG.5illustrates a method in which a UWBS of a UWB device including an SE obtains a ranging data set for secure ranging according to an embodiment.

The UWB device ofFIG.5may be the first UWB device ofFIG.4.

Referring toFIG.5, the UWB device may include a framework, a secure component, and a UWBS. The secure component ofFIG.5may be an eSE including an applet (service applet) and a SUS applet.

In operation 1, the applet may generate an RDS including a UWB session key and a session ID and transfer it to the SUS applet. In operation 2, the SUS applet may transfer a response to the reception of the RDS to the applet.

In operation 3, the eSE may transfer a notification indicating that the RDS has been transferred to the SUS applet to the framework. In an embodiment, this notification may include a session ID for identifying the RDS. In operation 4, the framework may transfer a command to start ranging (e.g., UCI command: start ranging) together with necessary parameters to the UWBS. In an embodiment, this command may include a session ID. Thus, the UWBS may initiate a procedure for performing ranging (secure ranging) for the session (ranging session) associated with the session ID.

To perform secure ranging, the UWBS should obtain the RDS from the SUS applet. To that end, the UWBS may initiate the procedure to obtain the RDS. For example, the UWBS may initiate a procedure including, e.g., operations 5 to 8, with the eSE (SUS applet) to obtain the RDS.

In operation 5, the UWBS may transmit a SELECT command including the AID of the SUS applet to the SUS applet, and the SUS applet may transmit a SELECT response corresponding to the SELECT command to the UWBS. Thus, an SUS applet to search for the RDS may be selected.

In operation 6, the UWBS may transmit an INITIALIZE UPDATE command to the SUS applet to initiate authentication (mutual authentication) for establishing a secure channel, and the SUS applet may transmit an INITIALIZE UPDATE response, corresponding to the INITIALIZE UPDATE command, to the UWBS. In operation 7, the UWBS may transmit an EXTERNAL AUTHENTICATE command for authentication to the SUS applet, and the SUS applet may transmit an EXTERNAL AUTHENTICATE response, corresponding to the EXTERNAL AUTHENTICATE command, to the UWBS. Through operations 6 and 7, a secure channel is configured between the UWBS and the SUS applet. For example, a secure channel may be configured between the UWBS and the user authentication. To configure such a secure channel, the UWBS should store the same symmetric key as the SUS applet in the eSE.

In operation 8, the UWBS may transmit a GET command for obtaining the RDS to the SUS applet, and the SUS applet may transmit a response corresponding to the GET command to the UWBS. In an embodiment, the GET command may include a session ID for identifying the RDS, and the response may include RDS data (e.g., ranging session key) corresponding to the session ID. Thus, the UWBS may obtain the RDS data.

In operation 9, the UWBS may transfer a notification indicating that the UWBS has obtained the RDS data to the framework.

In operation 10, the UWBS may perform secure ranging with the UWBS of another UWB device using the obtained RDS data. For example, the UWBS may perform secure ranging with the UWBS of the other UWB device using the STS generated using the ranging session key generated using the ranging session key of the RDS.

In the scheme ofFIG.5, since the UWBS needs to transfer multiple commands for performing encryption/message authentication operation to the SE (SUS applet) to obtain the RDS, an issue with performance may occur. Further, as the parameter, such as session ID, used for secure ranging should be exposed to the outside (e.g., framework) of the SE without being encrypted, an issue with security may arise. Further, since the UWBS having the nature of lower security than the SE should store the same symmetric key as the SE to configure a secure channel for RDS transfer, the security key may leak and, if the manufacturers of the SE and the UWBS differ, such an issue may arise where the different manufacturers should share the same security key. Embodiments for addressing such issues are described below with reference to the drawings.

FIG.6illustrates a UWB device including a TEE according to an embodiment.

Referring toFIG.6, a UWB device600includes a framework622, a secure component610, and a UWBS624. The UWB device600may further include at least one UWB-enabled application621a,621band OOB connector623. The framework622, UWBS624, UWB-enabled application621a,621b, and OOB connector623ofFIG.6may be, e.g., the framework, UWBS, UWB-enabled application, and OOB connector described above in connection withFIGS.1to3.

The secure component according toFIG.6may be a TEE610including at least one trusted application (TA)611and secure OS (trusted OS)612. The area of the UWB device may be divided into a TEE (TEE area)610and a rich operating system execution environment (REE) (REE area)620.

The TEE620is an environment where code is executed and may have a high level of trust. In the TEE610, trust may mean that it has a higher level of trust in the validity, isolation, and access control for items stored in the TEE area (space) as compared with general-purpose software environments. Accordingly, the TA611and secure OS612executed in the TEE610area may have higher trust. In an embodiment, the TEE610(or TA611) may communicate with another component through a pre-defined interface (e.g., TEE client API). For example, the TEE client API may be used by the framework622to transfer the RDS to the UWBS624. Further, the framework622may communicate with the UWBS624through a pre-defined interface (e.g., a UWB command interface (UCI)).

The TA611is the application of the TEE610and is denoted as TA to be distinguished from unclear characteristics of the application in the REE. In the disclosure, the TA611may serve to generate/store/transfer the RDS and may play a role as a contact point for the framework622(or the UWBS communicating with the framework). In the disclosure, the TA611may be identified by the ID (e.g., UUID) defined for the TA611. In the disclosure, the TA611may also be denoted as a FiRa TA.

The secure OS621is an OS hosted by the TEE610and may be a trusted OS distinguished from the rich OS (e.g., Android) hosted by the REE of the device.

The UWBS624is positioned outside the TEE area.

InFIG.6, the UWB device may be implemented to increase security, efficiency, and manageability, as described below.

(1) Security-Related

In the embodiment ofFIG.6, for security, the key (e.g., symmetric key) used in the UWB device600may be configured to be used only for a predetermined valid period. For example, the symmetric key used to encrypt the RDS may have an expiration date. Thus, as the important key for security is not stored for a long time, security may be increased. In the disclosure, the symmetric key used to encrypt the RDS may be denoted as an RDS encryption key, RDS encryption symmetric key, RDS security key, or RDS key.

The RDS may include a ranging session key (UWB ranging session key) indicating the key used for securing the UWB ranging session and/or a session ID for identifying the RDS (or session associated with the RDS). In this case, the ranging session key and session ID should be the same in the initiator and the responder of UWB ranging. The RDS may further include at least one ranging parameter (e.g., AoA, proximity distance), client-specific data and/or a multicast responder-specific key, as described below with reference toFIGS.7to11.

(2) Efficiency-Related

In the case of the UWB device600ofFIG.6, for efficiency, roles may be distinguished between the UWBS624and the TEE610by reflecting the characteristic of the RSA algorithm that public key computation is fast, and private key computation is slow. For example, the UWBS624may be configured to perform public key computation (encryption), and the TEE610may be configured to perform private key computation (decryption). In this case, the UWBS624may serve to generate a symmetric key (secret key/private key) used to encrypt the RDS stored in the TA611. The UWBS624may serve to encrypt the symmetric key generated using the public key of the TA611and transfer it to the TA611through the framework622. The TA611may serve to extract (decrypt) the symmetric key transferred from the UWBS624. The TA611may serve to encrypt the RDS using the extracted symmetric key and transfer it to the UWBS624through the framework622.

It is possible for the UWBS624to more efficiently and quickly obtain the RDS from the TA611by setting the roles between the UWBS624and the TA611reflecting such RSA algorithm characteristic. However, embodiments are not necessarily limited thereto.

Although efficiency (encryption/decryption processing rate) may be decreased as compared with the above-described scheme, the TA611can be configured to perform public key computation (encryption) and the UWBS624can be configured to perform private key computation (decryption). In this case, the TA611may serve to generate a symmetric key (secret key/private key) used to encrypt the RDS stored in the TA611. The TA611may serve to encrypt the symmetric key generated using the public key of the TA611(or UWBS624) and transfer it to the UWBS through the framework. The TA611may serve to encrypt the RDS using the generated symmetric key and transfer it to the UWBS624through the framework622. The UWBS624may serve to extract (decrypt) the symmetric key transferred from the TA611. Further, the UWBS624may serve to decrypt the encrypted RDS transferred from the TA611using the extracted symmetric key.

The operations between the framework622, UWBS624, and TEE610may be configured so that fewer commands than inFIG.5may be communicated through the framework622, rather than communication of many commands directly between the UWBS624and the TEE611. This is described below with reference toFIGS.7to11.

(3) Manageability-Related

In the case of the UWB device600ofFIG.6, for manageability, a TA certificate including the public key of the TA611may be configured to be stored in the UWBS624. Thus, the symmetric key used to generate a secure channel for transfer the RDS between the secure component610and the UWBS624need not be shared between different manufacturers (vendors), as described below with reference toFIG.9.

FIG.7illustrates a procedure performed between a UWBS and a framework for secure ranging in a UWB device according to an embodiment.

InFIG.7, the UWB device may include the TEE ofFIG.6. InFIG.7, the framework and the UWBS may communicate with each other using, e.g., a UCI interface (e.g., UCI command/response/notification).

In an embodiment, before the procedure between the framework and the UWBS is performed, the TA of the TEE may generate a private key and a public key and store them in the form of a certificate signed by the manufacturer (e.g., mobile OEM). The certificate may include the public key and/or private key of the TA.

In operation 1 ofFIG.7, the framework may transmit, e.g., a command to install a TA certificate (e.g., UCI command: Install Certificate) to the UWBS. The command may include the data of the TA certificate. In operation 2, the UWBS may verify the received TA certificate with a pre-stored root certificate. Thus, the verified TA certificate may be stored in the UWBS. An example of operations 1 and 2 is described below with reference toFIG.9.

In operation 3 ofFIG.7, the UWBS may generate a symmetric key used to encrypt the RDS and encrypt the generated symmetric key with the public key in the TA certificate. In an embodiment, the UWBS may generate additional data (information) associated with the symmetric key, along with the symmetric key. In an embodiment, the additional data, along with the symmetric key, may be encrypted with the public key of the TA. Thus, encrypted key data (encrypted key blob) may be generated.

The additional data may include at least one of timestamp information about the symmetric key (e.g., timestamp indicating the time of generation of the symmetric key), information about the valid time of the symmetric key (e.g., information about the expiration time), information about the authority of the symmetric key (e.g., identification information (UUID) of the TA), information for the integrity of the symmetric key (e.g., IV), or random number information for identifying the freshness of the symmetric key (e.g., random value).

The symmetric key timestamp information and/or valid time information may be used to identify whether the symmetric key is valid or has expired. As the symmetric key may be used as valid only for a predetermined valid time through the timestamp information, security may be increased.

The information about the authority of the symmetric key may be used to identify the TA that will be given authority for the symmetric key. Thus, only the TA assigned authority may use the symmetric key, so that security may be increased.

The information for the integrity of the symmetric key may be used to protect the integrity of the symmetric key, as well as confidentiality. Thus, security may be increased.

The random number information of the symmetric key may be used to identify whether the symmetric key has been properly transferred to the TA.

In operation 4 ofFIG.7, the UWBS may transmit the encrypted key data to the framework. The encrypted key data may include the encrypted symmetric key and/or encrypted additional data. As shown, the UWBS may transmit the encrypted key data through a notification (e.g., UCI notification: Encrypted key blob). For example, when a predetermined event occurs (e.g., when an encrypted event or a symmetric key generation event occurs), the UWBS may generate and transmit a notification including the encrypted key data. In another embodiment, the UWBS may transmit the encrypted key data in response (e.g., UCI response: GET_ENCRYPTED_KEY_RSP) to a request (command) (e.g., UCI command: GET_ENCRYPTED_KEY_CMD) of the framework. The framework may transfer the encrypted key data to the TA. An example of operations 3 and 4 is described below with reference toFIG.10.

Each of the above-described operations exemplifies a specific operation performed by each component, and the order of operations is not limited to the order described above. For example, each operation may be performed in an order different from the described order.

FIG.8illustrates a procedure performed between a framework and a TEE for secure ranging in a UWB device according to an embodiment.

InFIG.8, the UWB device may be a UWB device including the TEE ofFIG.6. The procedure ofFIG.8may be a procedure performed after the procedure ofFIG.7. InFIG.8, the operation performed by the TEE may be understood as a procedure performed by the TA of the TEE.

InFIG.8, the framework and the UWBS may communicate with each other using, e.g., a UCI interface. Further, the framework and the TEE may communicate with each other using, e.g., a TEE client API.

In operation 5 ofFIG.8, the TA may decrypt the encrypted key data. In an embodiment, the TA may decrypt the encrypted key data using private key of the TA. As described above, the encrypted key data may include the encrypted symmetric key and/or encrypted additional data. By description, the TEE may obtain the symmetric key and additional data. Thus, the symmetric key for encrypting the RDS for secure ranging may be shared between the UWBS and the TA. Further, additional data for identifying, e.g., the validity or authority of the symmetric key may be used by the TA.

In operation 6 ofFIG.8, the TEE may encrypt the RDS with a temporal symmetric key. The TEE may transfer the encrypted RDS to the framework.

In operation 7 ofFIG.8, the framework may transmit the encrypted RDS to the UWBS. In an embodiment, the framework may use the UCI interface to transmit the encrypted RDS to the UWBS.

In operation 8 ofFIG.8, the UWBS may decrypt the encrypted RDS. In an embodiment, the UWBS may decrypt the encrypted RDS using a pre-shared symmetric key. By the decryption, the UWBS may normally obtain the RDS.

In operation 9 ofFIG.8, the UWBS may perform secure ranging using the RDS. For example, the UWBS may perform secure ranging with the UWBS of the other UWB device using the STS generated using the ranging session key generated using the ranging session key of the RDS. An example of operations 5 to 9 ofFIG.8is described below with reference toFIGS.10and11.

Each of the above-described operations exemplifies a specific operation performed by each component, and the order of operations is not limited to the order described above. For example, each operation may be performed in an order different from the described order.

FIG.9illustrates a registration procedure of a UWB device according to an embodiment.

InFIG.9, the UWB device may be a UWB device including the TEE ofFIG.6. The UWB device may include a TA (TEE), a framework, and a UWBS.

The registration procedure ofFIG.9may be a procedure for previously registering data (information) necessary for the components of the UWB device. For example, the registration procedure may be a procedure for registering the TA certificate including the public key and/or private key of the TA in the UWBS.

The UWB device may perform a registration procedure with the manufacturer's server. In the disclosure, the manufacturer's server may be a server (e.g., mobile OEM backend server) operated by the manufacturer of the UWB device or the electronic device (e.g., mobile device) including the UWB device.

In operation9010ofFIG.9, the manufacturer's server may transfer a command (message) to install the manufacturer's certificate (e.g., mobile OEM's certificate) to the UWBS. The manufacturer's certificate may be denoted as a root certificate. Thus, the UWBS may store the manufacturer's root certificate. The root certificate may be used to verify the certificate of the TA signed by the manufacturer.

In operation9020, the TA may generate a private key (Pri) and a public key (Pub) of the TA.

In operation9030, the TA may transmit a certificate signing request for the certificate including the public key of the TA to the manufacturer's server. The certificate signing request may be used for the TA to obtain the TA certificate signed by the manufacturer. The manufacturer's server may generate a TA certificate signed with the manufacturer's key, based on the certificate signing request.

In operation9040, the manufacturer's server may transmit the TA certificate signed with the manufacturer's private key (e.g., mobile OEM's private key) to the TA.

In operation9050, the framework may request the TA certificate from the TA.

In operation9060, the TA may transmit the TA certificate (signed TA certificate) to the framework based on the request.

In operation9070, the framework may transmit the received TA certificate to the UWBS.

In operation9080, the UWBS may verify the TA certificate based on a pre-stored manufacturer certificate (root certificate).

In operation9090, the UWBS may transmit a result (e.g., OK/NOK) of verification for the TA certificate to the framework.

Through the registration procedure, the UWBS may obtain the TA certificate including the public key of the UWBS. The public key of the TA certificate may be used to encrypt the symmetric key generated by the UWBS, as described below with reference toFIG.10.

Each of the above-described operations exemplifies a specific operation performed by each component, and the order of operations is not limited to the order described above. For example, each operation may be performed in an order different from the described order.

FIG.10illustrates a procedure in which a UWB device transfers an encrypted symmetric key according to an embodiment.

InFIG.10, the UWB device may include the TEE ofFIG.6. As shown, the UWB device may include a TA (TEE), a framework, and a UWBS.

The transfer (sharing) procedure of the encrypted symmetric key ofFIG.10may be a procedure for encrypting the symmetric key generated by the UWBS and transferring it to the TA through the framework.

As described above, the symmetric key may be used for the TA to encrypt the RDS.

In operation1010ofFIG.10, the framework may send a GET command (e.g., UCI command: GET_ENCRYPTED_KEY_CMD) to obtain the encrypted symmetric key from the UWBS to the UWBS. The GET command may include ID information for identifying the TA (e.g., the TA's UUID) as input. The GET command for obtaining the encrypted symmetric key from the UWBS may be referred to as an encryption key acquisition command.

In operation1020, the UWBS may generate a symmetric key. In an embodiment, the UWBS may generate additional data (information) associated with the symmetric key, along with the symmetric key. The additional data may include at least one of timestamp information about the symmetric key (e.g., timestamp indicating the time of generation), information about the valid time of the symmetric key (e.g., information about the expiration time), information about the authority of the symmetric key (e.g., identification information (UUID) of the TA), information for the integrity of the symmetric key (e.g., IV or additional authentication data (aad)), or random number information for identifying the freshness of the symmetric key. The use of each piece of information (data) has been described above in connection withFIG.6.

In operation1030ofFIG.10, the UWBS may encrypt the symmetric key and/or additional data with the public key of the TA in the TA certificate. Thus, encrypted key data (encrypted blob) may be generated. This may be referred to as first encryption data.

In operation1040, the UWBS may transfer a response (e.g., UCI response: GET_ENCRYPTED_KEY_RSP) corresponding to the GET command to the framework. In an embodiment, the response may include encrypted key data. The encrypted key data may include the encrypted symmetric key and/or encrypted additional data.

In operation1050, the framework may transmit a SET command (e.g., TEE client API: SET_ENCRYTION_KEY) for setting an encrypted key on the TA to the TA. In an embodiment, the SET command may include the ID information about the TA (e.g., the UUID of the TA) and/or encrypted key data as input. In an embodiment, the framework may send a SET command to the TA identified by the ID information about the TA. In the disclosure, a SET command for setting an encrypted key on the TA may be referred to as an encryption key setting command.

In operation1060, the TA may decrypt the encrypted key data. In an embodiment, the TA may decrypt the encrypted key data using the TA's private key. Thus, the TA may obtain the symmetric key and/or additional data.

In operation1070, the TA may transmit a response (e.g., TEE client API: Response) corresponding to the SET command to the framework. In an embodiment, the response may include a random number. In an embodiment, the random number may be a random value of random number information included in the additional data.

In operation1080, the framework may transmit an ACK command (e.g., UCI command: ACK_ENCRYPTED_KEY_CMD) for requesting a reception acknowledgment (ACK) for the encrypted key (or encrypted key data) to the UWBS. In an embodiment, the ACK command may include the random number included in the response corresponding to the SET command. An ACK command for requesting a reception ACK for the encrypted key may be referred to as an encryption key identification command or an encryption key reception acknowledgment command.

In operation1090, the UWBS may include a response (e.g., UCI response: ACK_ENCRYPTED_KEY_RSP) corresponding to the ACK command. In an embodiment, the response will send, to the framework, a value (OK) indicating that the received random value is equal to the generated random value or a value (NOK) indicating that the received random value is different from the generated random value. Thus, the framework may identify whether the symmetric key generated by the UWBS is normally received by the TA.

Through the encrypted symmetric key transfer procedure, the symmetric key generated by the UWBS may be transferred to the TA. Thus, the UWBS and the TA may share the same symmetric key used for encryption/decryption of RDS. In this case, the TA may encrypt the RDS with the symmetric key and transfer it to the UWBS, and the UWBS may decrypt the encrypted RDS with the symmetric key, as described below with reference toFIG.11.

Each of the above-described operations exemplifies a specific operation performed by each component, and the order of operations is not limited to the order described above. For example, each operation may be performed in an order different from the described order.

FIG.11illustrates a procedure in which a UWB device transfers an encrypted RDS according to an embodiment.

InFIG.11, the UWB device may be a UWB device including the TEE ofFIG.6. As shown, the UWB device may include a TA (TEE), a framework, and a UWBS.

The procedure for transferring the encrypted RDS ofFIG.11may be a procedure for transferring the encrypted RDS generated by the TA to the UWBS through the framework. As described above, the RDS may be used for security ranging.

In operation1110ofFIG.11, the framework may transmit, to the TA, a GET command (e.g., TEE client API: GET_ENCRYPTED_RDS) to obtain the encrypted RDS from the TA. In an embodiment, the GET command may include ID information about the TA (e.g., the TA's UUID) as input. The GET command for obtaining the encrypted RDS from the TA may be referred to as an encrypted RDS acquisition command.

In operation1120, the TA may generate an RDS. The RDS may include a UWB ranging key and/or a session ID. Alternatively, the TA may identify whether a pre-shared symmetric key is valid. For example, the TA may identify whether the symmetric key is valid based on additional data (e.g., the expiration date of the symmetric key). If the symmetric key is valid (OK), the TA may encrypt the ID information about the UWBS and/or the RDS with the symmetric key.

In operation1130, the TA may transmit, to the framework, a response (TEE client API: Response) corresponding to the GET command. The response may include encrypted data (encrypted blob). The encrypted data may include encrypted RDS and/or encrypted UWBS ID information, referred to as second encryption data.

In operation1140, the framework may include a SET command (e.g., UCI command: SET_ENCRYPTED_RDS_CMD) for setting the encrypted RDS on UWBS. The SET command may include the encrypted data as input. The SET command for setting the encrypted RDS on the UWBS may be referred to as an encrypted RDS setting command.

In operation1150, the UWBS may decrypt the encrypted data. The UWBS may decrypt the encrypted data using the pre-shared symmetric key. Thus, the UWBS may obtain the RDS.

In operation1160, the UWBS may transmit a response (e.g., UCI response: SET_ENCRYPTED_RDS_RSP) corresponding to the SET command to the framework. The response may include a value (OK) indicating that the RDS is normally received or a value (NOK) indicating that the RDS is not normally received. Thus, the framework may identify whether the RDS transferred by the TA is well received by the UWBS.

In operation1170, the UWBS may perform secure ranging with the UWBS of another UWB device using the RDS. For example, the UWBS may perform secure ranging with the UWBS of the other UWB device using the STS generated using the ranging session key generated using the ranging session key of the RDS.

Each of the above-described operations exemplifies a specific operation performed by each component, and the order of operations is not limited to the order described above.

In the embodiment described above in connection withFIGS.6to11, an example has been described in which the UWB device includes a TEE as a secure component, and the UWBS of the UWB device generates/encrypts an RDS encryption key, and the TEE of the UWB device decrypts the RDS encryption key. Although the embodiment is preferable for providing high security and efficiency as compared with other embodiments, embodiments of the disclosure are not necessarily limited thereto.

For example, even when the UWB device includes an SE (eSE) as a secure component, the above-described embodiment may also apply. In this case, e.g., the SUS applet of the eSE may play a role as the TA of the TEE in the above-described embodiment. As another example, the above-described embodiment may also apply even where the TEE of the UWB device generates/encrypts the RDS encryption key, and the UWBS of the UWB device plays a role to decrypt the RDS encryption key.

FIG.12is a flowchart illustrating a method of a UWB device according to an embodiment.

InFIG.12, the UWB device may be the UWB device ofFIG.6. The UWB device may include a framework, a security component, and a UWBS. The security component may be a TEE including a TA. The method ofFIG.12may be performed by the framework (or a controller) of the UWB device.

Referring toFIG.12, in operation1210, first encryption data including a symmetric key encrypted by the public key of the secure application (TA) may be obtained from the UWB device and the first encryption data is transferred to the secure application. Operation1210may be performed according to the procedure/operations exemplified inFIGS.7and10.

Operation1210may include transmitting an encryption key acquisition command including identification information about the secure application to a UWB sub-system, receiving, from the UWB sub-system, a response corresponding to the encryption key acquisition command, including the first encryption data, and transmitting, to the secure application, an encryption key setting command including the identification information about the secure application and the first encryption data. In another embodiment, operation1210may include receiving, from the secure application, a response corresponding to the encryption key setting command, including random number information included in additional data associated with the symmetric key obtained from the first encryption data, transmitting, to the UWB sub-system, an encryption key ACK command, including the random number information, and receiving, from the UWB sub-system, a response corresponding to the encryption key acknowledgment command, including a value based on the random number information.

In operation1220, the UWB device may obtain second encryption data including an RDS encrypted with the symmetric key from the secure application and transfer the second encryption data to the UWB sub-system. Operation1220may be performed according to the procedure/operations exemplified inFIGS.8and11.

Operation1220may include transmitting an encryption RDS acquisition command including identification information about the secure application to the secure application, receiving, from the secure application, a response corresponding to the encryption RDS acquisition command, including the second encryption data, transmitting, to the UWB sub-system, an encryption RDS setting command including the second encryption data, and receiving, from the UWB sub-system, a response corresponding to the encryption RDS setting command. In an embodiment, the second encryption data may further include identification information about the UWB sub-system encrypted with the symmetric key.

The symmetric key is generated and encrypted by the UWB sub-system, and the RDS includes a ranging session key used to secure the UWB ranging session. The secure application may be included in the TEE area.

The first encryption data may further include additional data encrypted with the public key of the secure application. The additional data may include at least one of information for indicating the valid time of the symmetric key, information about the authority of the symmetric key, information for protecting the integrity of the symmetric key, or random number information associated with the symmetric key.

FIG.13illustrates a structure of an electronic device according to an embodiment.

InFIG.13, the electronic device may correspond to the UWB device ofFIG.6or may be an electronic device including the UWB device ofFIG.6.

Referring toFIG.13, the electronic device includes a transceiver1310, a controller1320, and a storage unit1330. The controller may be defined as a circuit or application-specific integrated circuit or at least one processor.

The transceiver1310may transmit and receive signals to/from other network entities. The transceiver1310may transmit/receive data for UWB ranging using, e.g., UWB communication.

The controller1320may control the overall operation of the electronic device. For example, the controller1320may control inter-block signal flow to perform the operations according to the above-described flowchart. Specifically, the controller1320may control the operations of the electronic device described above with reference toFIGS.1to12.

The storage unit1330may store at least one of information transmitted/received via the transceiver1310and information generated via the controller1320. For example, the storage unit1330may store information and data necessary for secure ranging described above with reference toFIGS.1to12.

In the above-described specific embodiments, the components included in the disclosure are represented in singular or plural forms depending on specific embodiments proposed. However, the singular or plural forms are selected to be adequate for contexts suggested for ease of description, and the disclosure is not limited to singular or plural components. As used herein, singular forms, e.g., a, an, and the, are intended to include the plural forms as well, unless the context clearly indicates otherwise.

While the disclosure has been particularly shown and described with reference to certain embodiments thereof, it will be understood by those of ordinary skill in the art that various changes in form and details may be made thereto without departing from the scope of the disclosure as defined by the appended claims and their equivalents.