Patent Description:
The present disclosure relates to an authentication method between terminals having a proximity communication function and terminals implementing the same method. More particularly, the present disclosure relates to an authentication method performed between terminals with an ultra-wide band (UWB) communication function and terminals for performing authentication using the same method.

Recently, ultra-wide band (UWB) communication technologies have begun to be used for accurate distance measurement and data transmission with enhanced security. Specifically, the UWB communication technology has attracted great attention as a technology that accurately measures a relative position or distance between terminals indoors and outdoors, or controls access to buildings or vehicles and enables payment in stores or on public transportation without contact.

The Fine Ranging (FiRa) Consortium is a group of related companies that define standardized UWB communication technology, and the consortium has been defining technical specifications as a convenient way to use UWB technology and authentication and security for UWB technology.

Meanwhile, the current FiRa specification is defined to establish a secure channel via the "GENERAL AUTHENTICATE" command before performing authentication between terminals. However, since the current secure channel establishment process defined in the FiRa specification requires much time with a complicated procedure, it is difficult to quickly perform authentication between terminals (e.g., within about <NUM> second). Therefore, such a problem may decrease the usability and convenience of the UWB communication technology according to the FiRa specification.

[Sa] Prior art patent document <CIT>, paragraph [<NUM>], discloses that Bluetooth Low Energy, BLE, can be used for out-of-band, OOB, communications for credential discovery and application selection in case the credential device hosts multiple Ultra Wide Band, UWB, applications. A secure communication channel is established between the credential device <NUM> and the reader device <NUM>. The secure communication channel is used by the reader device <NUM> to retrieve the access credential. After successful authentication of the access credential, the reader device negotiates the UWB RF parameters and shares a temporary session key (e.g. using a security token service STS seed) with the credential device <NUM>. At this point the out-of-band communication may be terminated and secure ranging with UWB is started.

Technical aspects to be achieved through one embodiment by the present disclosure provide an authentication method between terminals having a proximity communication function and terminals implemented to perform authentication using the same method.

More detailed technical aspects to be achieved through one embodiment by the present disclosure provide a method capable of quickly and safely performing authentication between terminals with a proximity communication function and terminals implemented to performing authentication using the same method.

Technical aspects to be achieved through one embodiment by the present disclosure also provide an authentication method designed to be easily reflected in the current FiRa specification.

The technical aspects of the present disclosure are not restricted to those set forth herein, and other unmentioned technical aspects will be clearly understood by one of ordinary skill in the art to which the present disclosure pertains by referencing the detailed description of the present disclosure given below.

According to some embodiments of the present disclosure, an authentication key may be previously shared between terminals, and a session key for ultra-wide band (UWB) ranging between the terminals may be generated using the shared authentication key and a random value. Accordingly, authentication between the terminals may be performed in a safe manner without using (establishing) a secure channel, an authentication process may be simplified, and time taken for authentication may be significantly reduced. Furthermore, the power consumed during authentication may be minimized.

In addition, the authentication key can be kept safely by storing the authentication key in a certain field of the application dedicated file (ADF).

In addition, the authentication key may be kept more safely by encrypting and storing the authentication key using an encryption key for a secure channel previously shared between the terminals.

In addition, the authentication key may be shared in an encrypted state using an encryption key for a secure channel previously shared between the terminals, thereby safely sharing the authentication key between the terminals.

Furthermore, since a new authentication mode that fails to use (establish) the secure channel may be added by the certain field in the ADF, the disclosed authentication method can be easily reflected in the current FiRa specification.

According to claim <NUM> of the present disclosure, there is provided an authentication method in a secure channel unused mode on a first terminal in which Fine Ranging (FiRa) applet is executed. The method includes generating a session basic information including a random value, transmitting the generated session basic information to a second terminal without establishing a secure channel with the second terminal, generating session data including a session key from the generated session basic information by using an authentication key pre-shared with the second terminal, and performing ultra-wide band (UWB) ranging with the second terminal by using the generated session data.

According to claim <NUM> of the present disclosure, there is provided an authentication method in a secure channel unused mode on a second terminal in which Fine Ranging (FiRa) applet is executed. The method includes receiving a session basic information including a random value from a first terminal without establishing a secure channel with the first terminal, generating session data including a session key from the received session basic information by using an authentication key pre-shared with the first terminal, and performing ultra-wide band (UWB) ranging with the first terminal by using the generated session data.

According to another embodiments of the present disclosure, there is provided an authentication method in a secure channel unused mode on a first terminal in which Fine Ranging (FiRa) applet drives. The method includes acquiring an authentication key, being a key used to perform ultra-wide band (UWB) ranging-based authentication with a second terminal in the secure channel unused mode, storing the acquired authentication key in a first field of an application dedicated file (ADF), and sharing the acquired authentication key with the second terminal via a secure channel.

According to another embodiments of the present disclosure, there is provided an authentication method in a secure channel unused mode on a second terminal in which Fine Ranging (FiRa) applet drives. The method comprises receiving an authentication key from a first terminal via a secure channel, being a key used to perform ultra-wide band (UWB) ranging-based authentication with the first terminal in the secure channel unused mode, and storing the received authentication key in a first field of an application dedicated file (ADF).

Hereinafter, preferred embodiments of the present disclosure will be described with reference to the attached drawings. Advantages and features of the present disclosure and methods of accomplishing the same may be understood more readily by reference to the following detailed description of preferred embodiments and the accompanying drawings. The present disclosure may, however, be embodied in many different forms and should not be construed as being limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete and will fully convey the concept of the disclosure to those skilled in the art, and the present disclosure will only be defined by the appended claims.

In adding reference numerals to the components of each drawing, it should be noted that the same reference numerals are assigned to the same components as much as possible even though they are shown in different drawings. In addition, in describing the present disclosure, when it is determined that the detailed description of the related well-known configuration or function may obscure the gist of the present disclosure, the detailed description thereof will be omitted.

Unless otherwise defined, all terms used in the present specification (including technical and scientific terms) may be used in a sense that can be commonly understood by those skilled in the art. In addition, the terms defined in the commonly used dictionaries are not ideally or excessively interpreted unless they are specifically defined clearly. In this specification, the singular also includes the plural unless specifically stated otherwise in the phrase.

In addition, in describing the component of this disclosure, terms, such as first, second, A, B, (a), (b), can be used. These terms are only for distinguishing the components from other components, and the nature or order of the components is not limited by the terms. If a component is described as being "connected," "coupled" or "contacted" to another component, that component may be directly connected to or contacted with that other component, but it should be understood that another component also may be "connected," "coupled" or "contacted" between each component.

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

<FIG> is a view illustrating an exemplary system to which an authentication method may be applied according to some embodiments of the present disclosure. Specifically, <FIG> illustrates an access control system.

As illustrated in <FIG>, an exemplary access control system may include a first terminal <NUM> and a plurality of second terminals 20a to 20c. Although not illustrated in <FIG>, the exemplary access control system may further include a remote server.

The first terminal <NUM> may be a device that authenticates the second terminals 20a to 20c by proximity communication and controls access to the second terminals 20a to 20c (or a user with the terminals) based on the authentication results. For example, the first terminal <NUM> may previously register the plurality of second terminals 20a to 20c by executing a registration process, may measure a distance from the second terminals 20a to 20c via communication with the second terminals 20a to 20c disposed physically adjacent to each other, may authenticate the second terminals 20a to 20c, and may identify the second terminals 20a to 20c using previously registered information. For example, the first terminal <NUM> may detect the second terminals 20a to 20c registered in advance to provide a function of allowing access only to registered terminals.

The first terminal <NUM> may be, for example, a digital door lock that controls human access in buildings and/or houses, but the scope of the present disclosure is not limited thereto.

The first terminal <NUM> may include a proximity (or short-range) communication module. For example, the first terminal <NUM> may include one or more communication modules configured to support at least some communication technologies such as near field communication (NFC), Bluetooth (BLE), Bluetooth Low Energy (BLE), Ultra-Wide Band (UWB), and Wi-Fi.

The second terminals 20a to 20c are devices used for user access (or authentication), and may include, for example, a smart key, a smart phone, or the like. However, the scope of the present disclosure is not limited thereto. Hereinafter, for the convenience of explanation, the reference numeral "<NUM>" is used when one of the second terminals 20a to 20c is indicated or when the plurality of second terminals 20a to 20c are collectively indicated.

Similar to the first terminal <NUM>, the second terminal <NUM> may also include a proximity (or short-range) communication module. For example, the second terminal <NUM> may also include one or more communication modules configured to support communication technologies such as NFC, Bluetooth, BLE, UWB, and Wi-Fi. In addition, the second terminal <NUM> may further include a FIDO security authentication module.

Meanwhile, in some embodiments, the authentication key may be previously shared between the first terminal <NUM> and the second terminal <NUM>. In addition, when the first terminal <NUM> and the second terminal <NUM> are physically adjacent to each other, the authentication is performed between the terminals <NUM> and <NUM> in a safe manner without establishing (using) a secure channel according to the FiRa specification. Accordingly, the authentication and access control of the second terminal <NUM> may be performed quickly, and the present embodiment associated therewith will be described in detail later with reference to <FIG> below.

So far, an exemplary access control system to which the authentication method according to some embodiments of the present disclosure may be applied has been described. Hereinafter, the terminals <NUM> and <NUM> in which the authentication method according to some embodiments of the present disclosure is implemented will be briefly described with reference to <FIG>.

<FIG> is an exemplary block diagram illustrating terminals in which an authentication method is implemented according to some embodiments of the present disclosure.

As illustrated in <FIG>, the first terminal <NUM> may include one or more applications <NUM> and an applet <NUM>, and the second terminal <NUM> may also include one or more applications <NUM> and an applet <NUM>. However, <FIG> illustrates only components associated with the embodiment of the present disclosure. Accordingly, it may be found by a person skilled in the art to which the present disclosure belongs that other universal components (e.g., a processor, a memory, and an input/output interface) may be further included in addition to the components illustrated in <FIG>. In addition, the components of the first terminal <NUM> and the second terminal <NUM> illustrated in <FIG> represent functional elements that are functionally distinguished from each other, and may be implemented in a form in which a plurality of components are integrated with each other in an actual physical environment or in a form in which a specific functional element is separated into a plurality of sub-functional elements. Hereinafter, each component will be described in detail.

First, the application <NUM> driven by the first terminal <NUM> may be an application in which a controller-side function defined in the FiRa specification is implemented. The application <NUM> may include a FiRa framework and/or an application using the FiRa framework. In addition, the application <NUM> may further include an application configured to implement functions according to various purposes, such as access authentication, unlocking, vehicle operation, and payment, in which the first terminal <NUM> is utilized.

The application <NUM> may establish a communication channel (e.g., a secure channel) with another terminal, for example, the second terminal <NUM>, via any communication module provided in the first terminal <NUM>, and exchange data through the established communication channel.

The applet <NUM> driven by the first terminal <NUM> may be a component that provides functions, such as UWB communication and authentication, to the application <NUM> of the first terminal <NUM>. The applet <NUM> may be executed (driven) within a secure element (e.g., an embedded secure element (eSE)) of the first terminal <NUM>. However, the scope of the present disclosure is not limited thereto. The applet <NUM> may collectively refer to different kinds of applets driven by the first terminal <NUM>.

As illustrated, the applet <NUM> may include a FiRa applet <NUM> and a secure UWB service (SUS) applet <NUM>. The applet <NUM> may further include another applet defined in the FiRa specification (or implemented in the FiRa specification). The FiRa applet <NUM> may support a variety of functions required for terminal authentication, such as authentication key generation, and a session management function for UWB communication with a counterpart terminal (e.g., the terminal <NUM>).

Detailed functions and operations of the application <NUM> and the applet <NUM> will be described in more detail with reference to <FIG> below.

Next, the configuration of the second terminal <NUM> will be described.

The application <NUM> driven by the second terminal <NUM> may be an application in which a controlee-side function is implemented in the FiRa specification. The application <NUM> may include a FiRa framework and/or the application using the FiRa framework. In addition, the application <NUM> may further include an application configured to implement functions according to various purposes, such as access authentication, unlocking, vehicle operation, and payment, in which the second terminal <NUM> is utilized.

The application <NUM> may establish a communication channel (e.g., a secure channel) with another terminal, for example, the first terminal <NUM>, via any communication module provided in the second terminal <NUM> and exchange data via the established communication channel.

The applet <NUM> driven by the second terminal <NUM> may be a component that provides functions, such as UWB communication and authentication, to the application <NUM> of the second terminal <NUM>. The applet <NUM> may be executed (driven) within the secure element of the second terminal <NUM>, but the scope of the present disclosure is not limited thereto. The applet <NUM> may collectively refer to different kinds of applets driven by the second terminal <NUM>.

As illustrated, the applet <NUM> may also include a FiRa applet <NUM> and a SUS applet <NUM>, and the applet <NUM> may further include another applet defined in the FiRa specification (or configured to implement a function defined in the FiRa specification). Alternatively, the second terminal <NUM> may further include an applet other than the applet <NUM>. A further description of the applet <NUM> will be additionally referenced in the description of the applet <NUM> of the first terminal <NUM>.

So far, the terminals <NUM> and <NUM> according to some embodiments of the present disclosure have been described with reference to <FIG>. Hereinafter, an authentication method according to some embodiments of the present disclosure will be described.

As described above, in the current FiRa specification, since the secure channel is established via the "GENERAL AUTHENTICATE" command (or message) before performing authentication between the terminals, it is difficult to quickly perform authentication between terminals. To solve this problem, the inventors of the present disclosure have devised a new authentication method.

Specifically, the present inventors have devised a method capable of previously sharing an authentication key (i.e., a key used for UWB ranging-based authentication) between the terminals and quickly and safely performing authentication using the pre-shared authentication key and a random value without establishing the secure channel. In addition, the present inventors have designed an authentication method in a form that the method can be easily reflected in the current FiRa specification such that FiRa specification-based terminals can use the designed authentication method.

Specifically, in order to maintain compatibility with the current FiRa specification and easily reflect the designed authentication method in the FiRa specification, the present inventors have designed a new authentication mode to be set using an application dedicated file (ADF), and also designed the method so that authentication is performed by terminals according to the designed authentication method in the case where a setting value of the ADF is in the new authentication mode. In the following description, the newly defined authentication mode may be referred to as a "secure channel unused mode" or a "fast authentication mode.

For example, as illustrated in Table <NUM> below, the fast authentication mode may be set (added) using the extended option field of the ADF, and more specifically, the fast authentication mode may be set (added) via the field that sets a UWB session key derivation scheme (e.g., see <NUM>: Fast authentication). However, the scope of the present disclosure is not limited thereto, and a fast authentication mode may be set in another manner. For example, the new authentication mode may be set (added) using an RFU area of the extended option field, an application data field of the ADF, or other elements other than the ADF.

However, in order to provide convenience of understanding, a further description will be continued hereinafter assuming that the "fast authentication mode" is set as described in Table <NUM> above.

Hereinafter, some embodiments of an authentication method devised with reference to <FIG> will be described in more detail.

First, <FIG> is an exemplary flowchart illustrating a schematic flow of an authentication method according to some embodiments of the present disclosure.

As illustrated in <FIG>, the authentication method according to embodiments may be composed of a plurality of processes <NUM> to <NUM>, for example, an authentication key acquisition process <NUM>, an authentication key sharing process <NUM>, an authentication process <NUM>, and an authentication key deletion process <NUM>. Although <FIG> illustrates how the processes <NUM> to <NUM> are performed sequentially, the scope of the present disclosure is not limited thereto, and the order of performing the processes <NUM> to <NUM> may vary in some cases.

In the authentication key acquisition process <NUM>, the first terminal <NUM> may acquire an authentication key. For example, the first terminal <NUM> may generate the authentication key by itself or may receive the authentication key from the outside. The present process <NUM> will be described in detail later with reference to <FIG>.

Next, in the authentication key sharing process <NUM>, the authentication key may be shared between the first terminal <NUM> and the second terminal <NUM>. For example, the first terminal <NUM> may share the authentication key by transmitting the acquired authentication key to the second terminal <NUM> via the secure channel. The secure channel between the first terminal <NUM> and the second terminal <NUM> may be established based on the FiRa specification. The present process <NUM> will be described in detail later with reference to <FIG>.

Next, in the authentication process <NUM>, the authentication may be performed between the first terminal <NUM> and the second terminal <NUM>. For example, the first terminal <NUM> and the second terminal <NUM> may generate the session data including a session key using the shared authentication key, and may perform UWB ranging-based authentication using the generated session data. The present process <NUM> will be described in detail later with reference to <FIG>.

Next, in the authentication key deletion process <NUM>, the authentication key shared via the authentication key sharing process <NUM> may be deleted. The present process <NUM> will be described in detail later with reference to <FIG>.

The authentication method according to some embodiments of the present disclosure has been schematically described with reference to <FIG>. Hereinafter, each of the process <NUM> to <NUM> constituting the authentication method will be described in detail.

First, an authentication key acquisition process <NUM> according to some embodiments of the present disclosure will be described in detail with reference to <FIG>.

<FIG> is an exemplary flowchart illustrating an authentication key acquisition process according to an embodiment of the present disclosure. However, this is only a preferred embodiment for achieving the object of the present disclosure, and some steps may be added or deleted as necessary.

As illustrated in <FIG>, the present embodiment relates to a method in which the first terminal <NUM> directly generates the authentication key, and may be performed between the FiRa applet <NUM> and the application <NUM>. However, the initiation of the authentication key acquisition process may be performed by an external request.

Specifically, the present embodiment may begin at a step S41 in which the application <NUM> transmits an authentication key generation request. For example, the application <NUM> may transmit an authentication key generation request message to the FiRa applet <NUM> driven in the secure element. The authentication key generation request may be implemented, for example, via a "GET DATA" command (or message) (e.g., a command Application Protocol Data Unit (APDU) message) specified in the FiRa specification. As a more specific example, when the "GET DATA" command (e.g., a command for reading the authentication key in a predefined authentication key storage area) is received without the authentication key, the FiRa applet <NUM> may be implemented to generate the authentication key. However, the scope of the present disclosure is not limited thereto. In the following description, "transmission of the request" may mean an operation of transmission of the request message.

In a step S42, in response to a received request, the FiRa applet <NUM> may generate the authentication key. A detailed process of the present step is illustrated in <FIG>.

As illustrated in <FIG>, the authentication key generation step S42 may begin when the FiRa applet <NUM> receives the authentication key generation request message (S51).

In a step S52, the FiRa applet <NUM> may check a tag of the authentication key request message. For example, the FiRa applet <NUM> may check whether the tag of the received request message is an application data tag. In <FIG>, because a value of the application data tag defined in the FiRa specification is "0xBF76," the tag of the message is compared with "0xBF76.

In a step S53, the FiRa applet <NUM> may determine whether a current authentication mode is the fast authentication mode (i.e., a secure channel unused mode) by using the extended option field of the ADF.

For example, as illustrated, it may be checked whether a second byte value of the extended option field is "0xC0. " The reason for checking whether the second byte value is "0xC0" is that when the fast authentication mode is defined as "<NUM>" (a value of <NUM>-<NUM> bits) (see Table <NUM>), the value of the second byte becomes "0xC0. " As described above, when the fast authentication mode is defined in another way (e.g., in the case of using different values or other fields), the present step may also be modified accordingly.

In a step S54, the FiRa applet <NUM> may determine whether the authentication key is present. For example, the FiRa applet <NUM> may determine whether the authentication key is present in a certain field (i.e., a predefined authentication key area) of the ADF using an instance UID (Unique IDentifier) of the ADF. In this case, the predefined authentication key area may be, for example, the application data field of the ADF, but the scope of the present disclosure is not limited thereto. However, for the convenience of understanding, a further description will be continued hereinafter assuming that the authentication key is stored in the application data field of the ADF. In response to determining that the authentication key fails to be present, a step S55 may occur.

In the step S55, the FiRa applet <NUM> may generate the authentication key. For example, the FiRa applet <NUM> may generate the authentication key using a random value generation algorithm or a key generation algorithm widely known in the art to which the present disclosure belongs. The generated authentication key may be stored in the application data field of the ADF, or may be stored in an encrypted state to improve security. For example, the generated authentication key may be stored in the encrypted state by an encryption key for the secure channel that is pre-shared according to the FiRa specification.

In a step S56, the FiRa applet <NUM> may generate a message indicating performance results. For example, the FiRa applet <NUM> may generate an error message according to the performance results (e.g., a message tag mismatch, an authentication mode mismatch, etc.), or a result message including the generated authentication key or a pre-stored authentication key. In this case, the authentication key may be included in the result message in the encrypted state by the encryption key to improve security. For example, the authentication key may be encrypted with the encryption key for the secure channel.

Table <NUM> below illustrates a format of the result message that may be generated in the step S56 described above.

In Table <NUM> above, since key data refers to an authentication key and a value of "0x7A" is a tag value of a message newly defined in association with the authentication key acquisition process, the value can be changed arbitrarily.

Meanwhile, although not illustrated in <FIG>, the FiRa applet <NUM> may check whether the secure channel is established (e.g., it may check whether the secure channel is established with an external terminal when the authentication key acquisition process is initiated by a request of the external terminal) in some cases, and when the secure channel is found not to be established, the FiRa applet <NUM> may stop the authentication key generation process and generate an error message.

It will be described again with reference to <FIG>.

In the step S43, the FiRa applet <NUM> may transmit an authentication key generation result to the application <NUM>. For example, the FiRa applet <NUM> may transmit the result message generated in the aforementioned step S56 to the application <NUM>. The transmission of such a result message may be implemented, for example, with a "GET DATA RESPONSE" command defined in the FiRa specification. However, the scope of the present disclosure is not limited thereto. In the following description, "transmission of the result" may mean an operation of transmission of the result message.

So far, the authentication key acquisition process according to one embodiment of the present disclosure has been described with reference to <FIG> and <FIG>. Hereinafter, the authentication key acquisition process according to another embodiment of the present disclosure will be described with reference to <FIG> and <FIG>.

<FIG> is an exemplary flowchart illustrating the authentication key acquisition process according to another embodiment of the present disclosure. However, this is only a preferred embodiment for achieving the object of the present disclosure, and some steps may be added or deleted as necessary.

As illustrated in <FIG>, the present embodiment relates to a method in which the first terminal <NUM> receives an authentication key from the outside, and may be performed between the FiRa applet <NUM> and the application <NUM>.

Specifically, the present embodiment may begin at step S61 in which the application <NUM> receives the authentication key from the outside. In this case, the secure channel may be established between the first terminal <NUM> and the outside in a manner defined in the FiRa specification.

In a step S62, the application <NUM> may transmit the authentication key to the FiRa applet <NUM>. The transmission of the authentication key may be implemented, for example, with a "PUT DATA" command defined in the FiRa specification. However, the scope of the present disclosure is not limited thereto.

In a step S63, the FiRa applet <NUM> may store the authentication key. A detailed process of the present step is illustrated in <FIG>.

As illustrated in <FIG>, an authentication key storage step S63 may begin when the FiRa applet <NUM> receives an authentication key transmission message (S71). A format of the authentication key transmission message may be designed, for example, as illustrated in Table <NUM> below, but the scope of the present disclosure is not limited thereto. As described above, the key data means the authentication key.

In a step S72, the FiRa applet <NUM> may check the tag of the authentication key transmission message. For example, the FiRa applet <NUM> may check whether the tag of the received transmission message is an application data tag.

In a step S73, the FiRa applet <NUM> may determine whether the current authentication mode is the fast authentication mode by using the setting value in the extended option field of the ADF.

In a step S74, the FiRa applet <NUM> may check whether the secure channel is established with the outside.

In a step S75, the FiRa applet <NUM> may determine whether the authentication key is present. For example, the FiRa applet <NUM> may determine whether the authentication key is present in the application data field of the ADF using the instance UID of the authentication key transmission message. In response to determining that the authentication key fails to be present, a step S76 may occur.

In the step S76, the FiRa applet <NUM> may store the authentication key. For example, the FiRa applet <NUM> may store the authentication key received in the application data field of the ADF. In this case, the FiRa applet <NUM> may store the authentication key in the encrypted state to improve security. For example, the authentication key may be encrypted using the encryption key for the secure channel.

In some cases, even when the authentication key is present, the FiRa applet <NUM> may store the received authentication key. For example, the FiRa applet <NUM> may update (replace) the existing (stored) authentication key with the received authentication key.

In a step S77, the FiRa applet <NUM> may generate a message indicating the performance results. For example, the FiRa applet <NUM> may generate the error message (e.g., a message tag mismatch, an authentication mode mismatch, the presence of the authentication key, the non-establishment of the secure channel, etc.), or the result message including the stored authentication key, according to the performance results. In this case, the authentication key may be included in the result message in the encrypted state by the encryption key to improve security. For example, the authentication key may be encrypted with the encryption key for the secure channel.

A format of the result message that may be generated in the step S77 may be designed, for example, as illustrated in Table <NUM> below. However, the scope of the present disclosure is not limited thereto.

In the step S64, the FiRa applet <NUM> may transmit an authentication key storage result to the application <NUM>. For example, the FiRa applet <NUM> may transmit the result message generated in the step S77 described above to the application <NUM>.

So far, the authentication key acquisition process <NUM> according to some embodiments of the present disclosure has been described with reference to <FIG>. Hereinafter, the authentication key sharing process <NUM> according to some embodiments of the present disclosure will be described in detail with reference to <FIG>.

<FIG> is an exemplary flowchart illustrating the authentication key sharing process <NUM> according to some embodiments of the present disclosure. However, this is only a preferred embodiment for achieving the object of the present disclosure, and some steps may be added or deleted as necessary.

As illustrated in <FIG>, the authentication key sharing process <NUM> according to embodiments may begin at a step S81 of establishing the secure channel between the first terminal <NUM> and the second terminal <NUM>. Refer to the FiRa specification for a detailed process of establishing the secure channel using a "GENERAL AUTHENTICATE" message. In addition, although not illustrated in <FIG>, after establishing the secure channel, a step of setting a UWB environment between the first terminal <NUM> and the second terminal <NUM> according to the FiRa specification may be further performed. Refer also to the FiRa specification for a detailed process of setting the UWB environment.

In a step S82, the first terminal <NUM> may generate an authentication key sharing message. The authentication key sharing message may include, for example, the authentication key and the UID of the ADF. However, the scope of the present disclosure is not limited thereto. A detailed process of the present step is illustrated in <FIG>.

As illustrated in <FIG>, the FiRa applet <NUM> may generate the authentication key sharing message in response to an authentication key sharing request of the application <NUM> and transmit the generated message to the application <NUM> (S91 to S93). In this case, the authentication key may be included in the authentication key sharing message in the encrypted state by the encryption key to improve security. For example, the authentication key may be encrypted with the encryption key for the secure channel.

The authentication key sharing request may be implemented, for example, with "TUNNEL" and "PUT DATA" commands as defined in the FiRa specification, and an authentication key sharing message transmission may be implemented with a "DISPATCH RESPONSE" command as defined in the FiRa specification. However, the scope of the present disclosure is not limited thereto.

A format of the authentication key sharing message that may be generated in a step S92 may be designed, for example, as illustrated in Table <NUM> below. However, the scope of the present disclosure is not limited thereto.

In a step S83, the first terminal <NUM> may transmit the authentication key sharing message to the second terminal <NUM>. The transmission of the authentication key sharing message may be implemented, for example, with a "DISPATCH REQUEST" command defined in the FiRa specification. However, the scope of the present disclosure is not limited thereto.

In a step S84, the second terminal <NUM> may receive the authentication key sharing message and store the authentication key included in the message. A detailed process of the present step is illustrated in <FIG>.

As illustrated in <FIG>, the application <NUM> may receive the authentication key sharing message and transmit the authentication key to the FiRa applet <NUM>, and the FiRa applet <NUM> may store the authentication key and transmit the stored result to the application <NUM> (S94 to S96). herein, the transmission of the authentication key storage result may be implemented for example, with the "DISPATCH RESPONSE" command defined in the FiRa specification. However, the scope of the present disclosure is not limited thereto.

A detailed process of the step S95 is illustrated in <FIG>.

As illustrated in <FIG>, an authentication key storage step S95 may begin when the FiRa applet <NUM> receives the authentication key sharing message (S101). A format of the authentication key sharing message may be designed, for example, as illustrated in Table <NUM> below, but the scope of the present disclosure is not limited thereto. As described above, the key data means the authentication key.

In a step S <NUM>, the FiRa applet <NUM> may check the tag of the authentication key sharing message. For example, the FiRa applet <NUM> may check whether the tag of the received shared message is the application data tag.

In a step S <NUM>, the FiRa applet <NUM> may determine whether the current authentication mode is the fast authentication mode by using the setting value of the extended option field of the ADF.

In a step S104, the FiRa applet <NUM> may check whether the secure channel is established with the first terminal <NUM>.

In a step S105, the FiRa applet <NUM> may determine whether the authentication key is present. For example, the FiRa applet <NUM> may determine whether the authentication key is present in the application data field of the ADF using the instance UID of the authentication key sharing message. In response to determining that the authentication key fails to be present, a step S <NUM> may occur.

In the step S106, the FiRa applet <NUM> may store the authentication key. For example, the FiRa applet <NUM> may store a received authentication key in the application data field of the ADF.

In a step S107, the FiRa applet <NUM> may generate the message indicating the performance results. For example, the FiRa applet <NUM> may generate the error message (e.g., a message tag mismatch, an authentication mode mismatch, the presence of the authentication key, the non-establishment of the secure channel, etc.), or the result message including the stored authentication key, according to the performance results. In this case, the authentication key may be included in the result message in the encrypted state by the encryption key to improve security. For example, the authentication key may be encrypted with the encryption key for the secure channel.

A format of the result message that may be generated in the step S107 may be designed, for example, as illustrated in Table <NUM> below. However, the scope of the present disclosure is not limited thereto.

In a step S85, the second terminal <NUM> may transmit the authentication key storage result to the first terminal <NUM>. For example, as illustrated in <FIG>, the application <NUM> of the second terminal <NUM> may transmit the result message generated in a step S96 to the application <NUM> of the first terminal <NUM>. Herein, the transmission of the authentication key storage result may be implemented, for example, with the "DISPATCH REQUEST" command defined in the FiRa specification. However, the scope of the present disclosure is not limited thereto.

So far, the authentication key sharing process <NUM> according to some embodiments of the present disclosure has been described with reference to <FIG>. As described above, the authentication key may be securely shared between the terminals <NUM> and <NUM> through a secure channel. In addition, the authentication key may be shared in the encrypted state using the encryption key for a pre-shared secure channel, thus more safely sharing the authentication key between the terminals <NUM> and <NUM>. In addition, the authentication may be quickly performed between terminals <NUM> and <NUM> without establishing the secure channel during actual authentication by using the shared authentication key.

Hereinafter, the authentication process <NUM> according to some embodiments of the present disclosure will be described in detail with reference to <FIG>.

<FIG> is an exemplary flowchart illustrating an authentication process <NUM> according to some embodiments of the present disclosure. However, this is only a preferred embodiment for achieving the object of the present disclosure, and some steps may be added or deleted as necessary.

As illustrated in <FIG>, the authentication process <NUM> according to the embodiments may begin at a step S111 in which the first terminal <NUM> generates session basic information. The session basic information is information that underlies generation of session data (or information used to generate the session data), and may include, for example, the instance UID of an ADF and the random value. However, the present disclosure is not limited thereto.

More specifically, as illustrated in <FIG>, the FiRa applet <NUM> may generate the session basic information in response to a request of the application <NUM> and transmit the generated session basic information to the application <NUM> (S121 to S123). The request for generating session basic information may be implemented, for example, with the "GET DATA" command defined in the FiRa specification. However, the scope of the present disclosure is not limited thereto.

A detailed process of a step S122 is illustrated in <FIG>.

As illustrated in <FIG>, a session basic information generation step S122 may begin when the FiRa applet <NUM> receives the request message (S131).

In a step S132, the FiRa applet <NUM> may check the tag of the received request message. In other words, the FiRa applet <NUM> may check whether the tag value of the received request message matches a predefined tag value of a session basic information-related message. <FIG> illustrates that the predefined tag value is "0xDA30", but the value may be changed arbitrarily.

In a step S133, the FiRa applet <NUM> may generate the session basic information including the random value. As described above, the session basic information may include the random value, and the instance UID of the ADF (that is, an ADF at a controller).

In a step S134, the FiRa applet <NUM> may generate the message indicating the performance results. For example, the FiRa applet <NUM> may generate the error message according to the performance results (e.g., a message tag mismatch, etc.), or may generate the result message including the session basic information, according to the performance results.

A format of the result message that may be generated in the step S134 may be designed, for example, as illustrated in Table <NUM> below. However, the scope of the present disclosure is not limited thereto.

In a step S112, the first terminal <NUM> may transmit the generated session basic information to the second terminal <NUM>.

In steps S113-<NUM> and S1 <NUM>-<NUM>, each of the first terminal <NUM> and the second terminal <NUM> may generate the session data based on the session basic information. The session data may include, for example, a session ID, a session key, and a sub-session key, as defined in the FiRa specification. However, the scope of the present disclosure is not limited thereto.

More specifically, as illustrated in <FIG>, the FiRa applets <NUM> and <NUM> may generate session data in response to the request of the applications <NUM> and <NUM> and transmit the generated session data to the applications <NUM> and <NUM> (S124-<NUM> to S126-<NUM>, and S124-<NUM> to S126-<NUM>). The request for generation of the session data may be implemented, for example, with the "PUT DATA" command and a "TERMINATE SESSION" message, as defined in the FiRa specification, but the scope of the present disclosure is not limited thereto.

Detailed processes of steps S125-<NUM> and S125-<NUM> are illustrated in <FIG>.

As illustrated in <FIG>, the session data generation step S125-<NUM> (or S125-<NUM>) may begin when the FiRa applet <NUM> receives the request message (S141).

In a step S <NUM>, the FiRa applet <NUM> may check the tag of the received request message. Specifically, the FiRa applet <NUM> may check whether the tag of the received request message is a session data tag. In <FIG>, because a value of the session data tag defined in the FiRa specification is "0xBF78", the tag of the request message is compared with "0xBF78.

A format of the request message that may be received in a step S <NUM> may be designed, for example, as illustrated in Table <NUM> below. However, the scope of the present disclosure is not limited thereto. Refer to the FiRa specification for the detailed descriptions of each field in Table <NUM> below.

In a step S143, the FiRa applet <NUM> may determine whether the current authentication mode is the fast authentication mode by using the setting value of the extended option field of the ADF.

In a step S144, the FiRa applet <NUM> may generate the session data including the session key. Herein, the session data may be data for UWB ranging as defined in the FiRa specification. In more detail, the FiRa applet <NUM> may acquire the authentication key from the application data field of the ADF using the ADF instance UID of the received session basic information, and may generate the session data (e.g., a session ID, a session key, and a sub-session key) using the acquired authentication key, the instance UID of the ADF, and the random value. However, a specific method of generating the session data may vary according to embodiments.

In one embodiment, the FiRa applet <NUM> may generate encryption data by encrypting the instance UID of the ADF and the random value with the authentication key, and may derive the session ID and the session key from the generated encryption data. For example, a portion (e.g., <NUM>-<NUM> bytes) of the encryption data may be a session ID, and a hash value of the encryption data may be the session key. However, the scope of the present disclosure is not limited thereto. According to the present embodiment, since the session ID and the session key are generated using the pre-shared authentication key and the random value, the security of UWB ranging-based authentication may be sufficiently ensured even if the secure channel is not established.

In another embodiment, the FiRa applet <NUM> may further generate the session data by using the encryption key for a pre-shared secure channel. For example, the FiRa applet <NUM> may generate the encryption data by using the encryption key for the secure channel as an initial vector and encrypting the instance UID of the ADF and the random value with the authentication key (e.g., encryption using an AES algorithm). In addition, the FiRa applet <NUM> may derive the session ID and the session key from the encryption data generated in a manner similar to the previous embodiment. Therefore, the security of UWB ranging-based authentication may be further improved.

In a step S145, the FiRa applet <NUM> may generate the message indicating the performance results. For example, the FiRa applet <NUM> may generate the error message (e.g., a message tag mismatch, an authentication mode mismatch, etc.), or may generate the result message including the session data, according to the performance results.

In steps S1 <NUM>-<NUM> and S1 <NUM>-<NUM>, each of the first terminal <NUM> and the second terminal <NUM> may set data for UWB ranging based on the generated session data. The ranging data may include, for example, the session data as defined in the FiRa specification. However, the scope of the present disclosure is not limited thereto.

More specifically, as illustrated in <FIG>, the FiRa applets <NUM> and <NUM> may transmit ranging data to SUS applets <NUM> and <NUM> in response to the request of the applications <NUM> and <NUM>, leading to setting the ranging data (S127-<NUM> and S128-<NUM>, and S127-<NUM> and S128-<NUM>). A request for generation the ranging data may be implemented, for example, with a "PUT DATA" command defined in the FiRa specification. However, the scope of the present disclosure is not limited thereto. Refer also to the FiRa specification for setting the ranging data.

In a step S115, the UWB ranging may be performed between the first terminal <NUM> and the second terminal <NUM>. Refer to the FiRa specification for a detailed process of the UWB ranging.

So far, the authentication process <NUM> according to some embodiments of the present disclosure has been described with reference to <FIG>. As described above, the session key for the UWB ranging may be safely generated using the pre-shared authentication key and the random value. Accordingly, the authentication may be performed between the terminals <NUM> and <NUM> in a safe manner without using (establishing) the secure channel, and the time taken for authentication may be significantly reduced. In addition, the power consumed during the authentication may be minimized.

Hereinafter, the authentication key deletion process <NUM> according to some embodiments of the present disclosure will be described in detail with reference to <FIG>.

<FIG> is an exemplary flowchart illustrating the authentication key deletion process <NUM> according to some embodiments of the present disclosure. However, this is only a preferred embodiment for achieving the object of the present disclosure, and some steps may be added or deleted as necessary.

As illustrated in <FIG>, the authentication key deletion process <NUM> according to embodiments may being at a step S151 of establishing the secure channel between the first terminal <NUM> and the second terminal <NUM>.

In a step S152, the first terminal <NUM> may generate the authentication key deletion request message. A detailed process of the present step is illustrated in <FIG>.

As illustrated in <FIG>, the FiRa applet <NUM> may generate the authentication key deletion request message including the instance UID of the ADF (i.e., the controller-side ADF to be deleted) in response to the authentication key deletion request of the application <NUM>, and may transmit the generated message to the application <NUM> (S161 to S163). The authentication key deletion request may be implemented, for example, with the "TUNNEL" and "PUT DATA" commands specified in the FiRa specification, and the transmission of the authentication key deletion request message may be implemented with the "DISPATCH RESPONSE" command specified in the FiRa specification. However, the scope of the present disclosure is not limited thereto.

In a step S153, the first terminal <NUM> may transmit the authentication key deletion request message to the second terminal <NUM>.

In a step S154, the second terminal <NUM> may delete the authentication key. A detailed process of the present step is illustrated in <FIG>.

As illustrated in <FIG>, the FiRa applet <NUM> may delete the authentication key in response to the authentication key deletion request (e.g., reception of the authentication key deletion request message) of the application <NUM>, and may transmit the deletion result to the application <NUM> (S164 to S166). The transmission of the deletion result may be implemented, for example, with the "DISPATCH RESPONSE" command defined in the FiRa specification. However, the scope of the present disclosure is not limited thereto.

A detailed process of the step S165 is illustrated in <FIG>.

As illustrated in <FIG>, an authentication key deletion step S165 may begin at a step S171 in which the FiRa applet <NUM> receives the request message from the application <NUM>. For example, the FiRa applet <NUM> may receive the authentication key deletion request message including a key data deletion tag and the instance UID of the ADF.

A format of the request message that may be received in step S171 may be designed, for example, as illustrated in Table <NUM> below. However, the scope of the present disclosure is not limited thereto. In Table <NUM> below, the value of "0x7B" is a tag value of a newly defined message in association with the authentication key deletion process, and the value may be changed arbitrarily.

In a step S172, the FiRa applet <NUM> may check the tag of the received request message. For example, the FiRa applet <NUM> may check whether the tag of the received request message is the application data tag.

In a step S174, the FiRa applet <NUM> may check whether the secure channel is established with the first terminal <NUM>.

In a step S175, the FiRa applet <NUM> may determine whether the authentication key is present. For example, the FiRa applet <NUM> may determine whether the authentication key is present in the application data field of the ADF using the instance UID of the ADF included in the authentication key deletion request message. In response to determining that the authentication key is present, a step S176 may occur.

In the step S176, the FiRa applet <NUM> may delete the authentication key. In other words, the FiRa applet <NUM> may delete the authentication key stored in the application data field of the ADF.

In a step S177, the FiRa applet <NUM> may generate the message indicating the performance results. For example, the FiRa applet <NUM> may generate the error message (e.g., a message tag mismatch, an authentication mode mismatch, the non-presence of the authentication key, the non-establishment of the secure channel, etc.), or may generate result message notifying the success of the deletion, according to the performance results.

In a step S155, the second terminal <NUM> may transmit the result of deleting the authentication key to the first terminal <NUM>.

In step S156, the first terminal <NUM> may also delete the authentication key. The present step is similar to the step S154 described above, and a description thereof will be omitted herein (refer to steps S164 to S166 for the description of steps S167 to S169).

So far, the authentication key deletion process <NUM> according to some embodiments of the present disclosure has been described with reference to <FIG>.

Meanwhile, according to the current FiRa specification, a method capable of confirming an ADF list managed by the FiRa applet (e.g., <NUM>) fails to be defined, and when the instance UID is not known, the presence or absence of a certain ADF cannot be determined. For example, when the instance UID is not known, the presence or absence of the certain ADF may not be determined using a "SELECT ADF" command. Accordingly, a command (or message) capable of acquiring a list of ADFs managed by the FiRa applet (e.g., <NUM>) needs to be additionally defined. Such a command may be easily implemented with a command of "GET DATA" and a new tag value (e.g., "0xBFAD") associated with ADF information, and a response message to the corresponding command may be designed, for example, as described in Table <NUM>.

Hereinafter, an exemplary computing device <NUM> capable of implementing the first terminal <NUM> and/or the second terminal <NUM> described above will be briefly described with reference to <FIG>.

<FIG> illustrates a diagram illustrating a hardware configuration of the computing device <NUM>.

As illustrated in <FIG>, the computing device <NUM> may include one or more processors <NUM>, a bus <NUM>, a communication interface <NUM>, a memory <NUM> configured to load a computer program <NUM> performed by the processor <NUM>, and a storage <NUM> configured to store the computer program <NUM>.

The processor <NUM> may control an overall operation of each component of the computing device <NUM>. The processor <NUM> may include at least one of a central processing unit (CPU), a micro-processor unit (MPU), a micro-controller unit (MCU), a graphical processing unit (GPU), or any type of processor known in the technical field of the present disclosure. In addition, the processor <NUM> may perform an arithmetic operation on at least one applet, application, and/or program for the purpose of executing the method/operation according to various embodiments of the present disclosure. The computing device <NUM> may include one or more processors <NUM>.

Next, the memory <NUM> may store different kinds of data, instructions, and/or information. The memory <NUM> may load one or more computer programs <NUM> from storage <NUM> to execute method/operations according to various embodiments of the present disclosure. An example of the memory <NUM> may be a RAM, but the present invention is not limited thereto.

Next, the bus <NUM> may provide a communication function between components of the computing device <NUM>. The bus <NUM> may be implemented as various types of buses such as an address bus, a data bus, and a control bus.

Next, the communication interface <NUM> may support wired or wireless communication of the computing device <NUM>. For example, the communication interface <NUM> may support various types of proximity communication, and may further support a variety of communication methods. The communication interface <NUM> may include a communication module known in the technical field of the present disclosure.

Next, the storage <NUM> may non-temporarily store one or more computer programs <NUM>. The storage <NUM> may include a non-volatile memory such as a flash memory, a hard disk, a removable disk, or any type of computer-readable recording medium known in the technical field to which the present disclosure belongs.

The computer program <NUM> may include one or more instructions in which methods/operations according to a variety of embodiments of the present disclosure are implemented. When the computer program <NUM> is loaded into the memory <NUM>, the processor <NUM> may perform the methods/operations according to a variety of embodiments of the present disclosure by executing the loaded instructions.

For example, the computer program <NUM> may include the instructions implementing the operations of the application <NUM> and the applet <NUM>. In this case, the first terminal <NUM> according to some embodiments of the present disclosure may be implemented with the computing device <NUM>. As another example, the computer program <NUM> may include instructions implementing operations of the application <NUM> and the applet <NUM>. In this case, the second terminal <NUM> according to some embodiments of the present disclosure may be implemented with the computing device <NUM>.

So far, the exemplary computing device <NUM> capable of implementing the terminals <NUM> and <NUM> according to some embodiments of the present disclosure has been described with reference to <FIG>.

The technical features of the present disclosure described so far may be embodied as computer readable codes on a computer readable medium. The computer readable medium may be, for example, a removable recording medium (CD, DVD, Blu-ray disc, USB storage device, removable hard disk) or a fixed recording medium (ROM, RAM, computer equipped hard disk). The computer program recorded on the computer readable medium may be transmitted to other computing device via a network such as internet and installed in the other computing device, thereby being used in the other computing device.

Although operations are shown in a specific order in the drawings, it should not be understood that desired results can be obtained when the operations must be performed in the specific order or sequential order or when all of the operations must be performed. In certain situations, multitasking and parallel processing may be advantageous. According to the above-described embodiments, it should not be understood that the separation of various configurations is necessarily required, and it should be understood that the described program components and systems may generally be integrated together into a single software product or be packaged into multiple software products.

Claim 1:
An authentication method in a secure channel unused mode on a first terminal (<NUM>) in which Fine Ranging, FiRa, applet (<NUM>) is executed, the method comprising:
generating (S111) a session basic information comprising a random value;
transmitting (S112) the generated session basic information to a second terminal (<NUM>) without establishing a secure channel with the second terminal (<NUM>);
generating (S113-<NUM>) session data comprising a session key from the generated session basic information by using an authentication key pre-shared with the second terminal (<NUM>); and
performing (S115) ultra-wide band, UWB, ranging with the second terminal (<NUM>) by using the generated session data.