Patent Description:
With developments of mobile devices and information and communication technology, a common authentication provided through a secure element, hereinafter, also referred to as SE, such as a universal subscriber identity module (USIM), and a secure digital (SD) card, are increasingly being applied to an electronic payment.

However, the common SE may manage authentication means such as certificate authentications in a form of a file and thus, may a risk of accidents caused through replication of the certificate authentication or leakage of personal information. To minimize the risk, a one-time password (OTP) authentication may be performed using an existing OTP providing device of a user irrespective of a presence of the SE.

In general, an OTP providing apparatus may be provided in a form of, for example, an OTP token, a card type OTP terminal, and a USIM software-based OTP providing application.

However, the OTP providing device may be subject to be exposed to a security attack such as a debugging port and an internal memory attack. Also, the OTP providing device may also be vulnerable to software hacking on a terminal operating system (OS) and OTP applications.

Furthermore, when a security accident occurs in a certification authority or a service provider that provides electronic payment and mobile banking services, an issue that financial institutions being unable to avoid responsibility for illegal transactions based on leaked information may arise.

Conversely, a physically unclonable function (PUF) may provide an unpredictable digital value. Each PUF may provide a different digital value although the PUF is produced through the exactly same manufacturing process.

The PUF may also be referred to as, for example, a physical one-way function (POWF) practically impossible to be duplicated.

Due to the impossibility of replication, the PUF may be used as an identifier of a device for security and/or authentication. For example, the PUF may be used to provide a unique key for distinguishing a device from other devices.

The method of implementing a PUF, <CIT>, hereinafter, referred to as the '<NUM> patent, may be provided in advance. The '<NUM> patent provides a method of stochastically determining whether a via or an inter-layer contact between conductive layers of a semiconductor based on a process variation of the semiconductor.

The publication by <NPL>, describes a security system for a car using a physically unclonable function (PUF).

The publication by <NPL>, describes a system that can distinguish between a trusted party and an adversary based on a simple user password during authentication. The hardware authentication is accomplished by providing a seed to a linear feedback shift register, whose output will serve as the final challenge for a PUF block.

<CIT> discloses terminal devices that perform machine-to-machine (M2M) communication to perform password authentication by autonomously generating a personal identity number (PIN) value, which is not exposed externally, using a physical unclonable function (PUF). A terminal apparatus that performs M2M communication may include a PUF embedded in the terminal apparatus to generate an authentication key for password authentication associated with the terminal apparatus, and an authentication unit to perform the password authentication associated with the terminal apparatus using the authentication key generated by the PUF.

The claimed invention is defined by the independent claims. Preferred embodiments are recited in the dependent claims.

Reference will now be made in detail to embodiments of the present invention, examples of which are illustrated in the accompanying drawings, wherein like reference numerals refer to the like elements throughout. The embodiments are described below in order to explain the present invention by referring to the figures.

<FIG> is a block diagram illustrating a <NUM>-factor authentication apparatus <NUM> including a general secure element (SE) and a hardware-based one-time password (OTP) providing apparatus according to an example embodiment.

As an example, the <NUM>-factor authentication apparatus <NUM> may be included in at least a portion of an embedded SE of a hardware terminal, a storing medium, a subscriber identification module (SIM), and a smart card. Related descriptions will be provided with reference to <FIG> and <FIG>.

The <NUM>-factor authentication apparatus <NUM> may include an SE <NUM> to perform a first authentication process which is an authentication scheme widely used in general.

Here, the first authentication process may be, for example, an authentication process based on a password, a subscriber identifier, a user identification (ID), and an authentication certificate stored in the SE <NUM>.

In a typical electronic payment and mobile banking, the first authentication process may be performed using the SE <NUM> to authenticate a user and/or a device. Alternatively, a process of identifying an OTP value by an OTP device provided separately and/or an authentication certificate password or a digital signature.

The <NUM>-factor authentication apparatus <NUM> may also include a hardware-based (HW) OTP element <NUM>. In this disclosure, an OTP authentication process performed relatively to and/or independently of the first authentication process may also be referred to as, for example, a second authentication process.

A second authentication may be related to an OTP submission process requested from at least one of, for example, a trusted service manager (TSM), a mobile network operator (MNO), a contents provider, and a service provider.

Also, at least one of the first authentication and the second authentication may be related to at least one of, for example, a mobile credit card payment, an electronic wallet payment, a mobile banking, an in-app store purchase payment, a content purchase payment, a website login, and a cloud computing service login.

In an example, the HW OTP element <NUM> may be included in a single chip including the SE <NUM>.

Although the foregoing example describes that each of the SE <NUM> and the HW OTP <NUM> is included in a corresponding chip, the SE <NUM> and the HW OTP element <NUM> may be included in a single package. The SE <NUM> may be connected with the HW OTP element <NUM> is through a die-chip wiring.

In this example, an interface for external access to the HW OTP element <NUM> may be omitted. An access to the HW OTP element <NUM> may be allowed through only the SE <NUM> and thus, an attack route may be blocked.

In an example, in contrast to typical OTP providing apparatuses, the HW OTP element <NUM> may implement a key value used directly or in directly to generate an OTP value only through hardware in lieu of storing the key value in a non-volatile storage medium.

In an example, the HW OTP element <NUM> may include at least one PUF, and use at least a portion of the at least one PUF to generate the OTP value.

As an example, the PUF included in the HW OTP element <NUM> may be based on a process variation proposed in the '<NUM> patent as described above. However, the foregoing may be provided as an example and thus, another hardware configuration for generating a key value, for example, a digital value applied directly or indirectly to an OTP generation, through hardware based on the PUF may also be applicable thereto.

By implementing the HW OTP element <NUM> through hardware, for example, the PUF, vulnerability against a physical attack and replication may be enhanced. Accordingly, a safety of the authentication process may be ensured against a secure attack.

Also, when the HW OTP element <NUM> is implemented only through a hardware circuit and does not include a processing module, for example, a central processing unit (CPU) and a main chip unit (MCU), to process software, a system may be unchangeable in contrast to software and thus, a high-reliability and unmodulatable authentication process may be provided.

Descriptions related to the HW OTP element <NUM> including the PUF and OTP generation will be provided as an example with reference to <FIG>, <FIG>, <FIG>, and <FIG>.

<FIG> illustrates a package <NUM> including a chip corresponding to the HW OTP element <NUM> and a chip corresponding to the SE <NUM> of <FIG>.

As an authenticating element included in the package <NUM>, the SE <NUM> may be used to perform a first authentication process based on a typical method. In an example, the package <NUM> may include an HW OTP element <NUM> having a die-chip wiring with the SE <NUM>.

The aforementioned configuration may guarantee a compatibility of the package <NUM> with an authentication process based on general technology including the SE <NUM>.

For example, although the package <NUM> includes the SE <NUM> and the HW OTP element <NUM>, the package <NUM> may function as a chip performing the first authentication through the SW <NUM> similarly to a typical process when a second authentication by the HW OTP element <NUM> is not requested during an authentication process.

Also, since a manufacturing process of the package <NUM> is similar or identical to a general chip manufacturing process, the HW OTP element <NUM> may be included in a chip as a package, thereby minimizing a complexity in the manufacturing process.

The HW OTP element <NUM> may not directly display the generated OTP to be viewed by the user based on a scheme used by the typical OTP providing apparatus, and may transfer the generated OTP to the SE <NUM> such that the second authentication is performed seamlessly. In this example, the SE <NUM> may also safely encrypt the OTP received from the HW OTP element <NUM> and transfer the encrypted OTP externally. As described with reference to <FIG>, in an example, the HW OTP element <NUM> may display the generated OTP to be viewed by the user based on a different scheme.

<FIG> is a diagram illustrating various examples to which an authentication apparatus of <FIG> is applied.

The <NUM>-Factor authentication apparatus <NUM> of <FIG> and the package <NUM> of <FIG> may be included in a various types of products. In general, an SE may be included in a universal subscriber identity module (USIM) or a secure digital (SD) card. Similarly, the <NUM>-factor authentication apparatus <NUM> or the package <NUM> may be included in a USIM <NUM> or an SD card <NUM>.

Additionally, the <NUM>-factor authentication apparatus <NUM> or the package <NUM> may be provided in a form of an embedded secure element <NUM> included in an information and communications terminal <NUM> in manufacturing of the information and communications terminal <NUM>, for example, a smartphone.

<FIG> illustrates an HW OTP providing apparatus <NUM> according to an example embodiment.

In an example, an HW OTP providing apparatus <NUM> may correspond to the aforementioned HW OTP element, for example, the HW OTP element <NUM> and the HW OTP element <NUM>. In another example, the HW OTP providing apparatus may be an OTP providing apparatus implemented through hardware irrespective of a <NUM>-factor authentication.

Thus, hereinafter, for increased clarity and conciseness, descriptions related to a configuration and an operation of the HW OTP providing apparatus <NUM> will be provided based on an example in which the HW OTP providing apparatus is an OTP element included in a <NUM>-factor authentication apparatus or an example in which the HW OTP providing apparatus is a separate OTP providing apparatus. However, it is apparent that one of the examples is not excluded from this disclosure.

In an example, the HW OTP providing apparatus <NUM> may include a first PUF <NUM> to generate a private key such that a public key-private key based encryption and decryption is to be performed with an external CA. Hereinafter, the HW OTP providing apparatus <NUM> may also be referred to as, for example, the apparatus <NUM>.

Also, the HW OTP providing apparatus <NUM> may include a second PUF to generate a unique PIN for identifying the <NUM>. In this disclosure, the first PUF <NUM> may also be referred to as, for example, "PUF(private key)". The second PUF may also be referred to as, for example, "PUF(PIN)".

The HW OTP providing apparatus <NUM> may include a blocker <NUM>. The blocker <NUM> may function as a route through which a unique PIN for identifying the apparatus <NUM> is safely extracted before the apparatus <NUM> is distributed and/or utilized. The blocker <NUM> may be configured to physically block a PIN extraction route, for example, PIN_out after the PIN is initially extracted in a safe state, and may be implemented using a fuse as illustrate herein.

A public key generator <NUM> may generate a public key symmetric to the private key generated by the PUF(private key) based on the private key. When the public key is to be transmitted to an external CA, a symmetric-key based encryption module <NUM> may generate P by encrypting the public key using the PIN generated by the PUF(PIN) <NUM> as a key value such that P is transmitted to the external CA. In an example of a <NUM>-factor authentication apparatus illustrated in <FIG>, P may be transmitted through the SE <NUM>.

In response to a request for an OTP authentication process based on a challenge-response scheme, the external CA may transmit Q obtained by encrypting a random number, R corresponding to a challenge to the apparatus <NUM>.

Q obtained by encrypting R based on a unique public key of the apparatus <NUM> may be demodulated using the private key. Thus, a demodulation module <NUM> may demodulate Q using the private key, thereby restoring R corresponding to the challenge.

An OTP generator <NUM> may generate an OTP based on R.

When the OTP is transmitted to the external CA, the external CA may perform the OTP authentication process by verifying whether the received OTP matches an OTP generated by the external CA based on R.

Related descriptions will also be provided with reference to <FIG>.

<FIG> is a flowchart illustrating a process of initially extracting a PIN in an HW OTP providing apparatus according to an example embodiment.

In operation <NUM>, a serial number, SN, of a device <NUM> may be assigned to the device <NUM> in a factory <NUM> for manufacturing the device <NUM>. The device <NUM> may include PUF(PIN). In operation <NUM>, a PIN generated by the PUF(PIN) may be initially extracted and provided to the factory <NUM> with SN.

In operation <NUM>, the blocker, for example, the fuse, as described with reference to <FIG> may be physically shorted to block PIN_out.

In operation <NUM>, the factory <NUM> may provide SN and PIN to a CA <NUM> through a safe process. The CA <NUM> may manage SN and PIN through a matching.

The foregoing is provided as an example and thus, the CA <NUM> may perform the process performed in the factory <NUM> when SN∥PIN is to be transmitted to the CA <NUM> with an increased safety. Hereinafter, the factory <NUM> and the CA <NUM> may perform at least a portion of function of one another and thus, repeated descriptions will be omitted.

<FIG> is a flowchart illustrating a process of exchanging a public key between an HW OTP providing apparatus and a CA according to an example embodiment.

Public key exchanging process may be performed between a device <NUM> and a CA <NUM> in advance of an OTP authentication.

In operation <NUM>, the CA <NUM> may send a request for a public key PUB_KEYD to the device <NUM>. In operation <NUM>, in response to the request, the device <NUM> may generate P by encrypting SN and the public key PUB_KEYD based on a symmetric-key based encryption scheme using a PIN of the device <NUM>.

In operation <NUM>, P may be transmitted to the CA <NUM>. In operation <NUM>, the CA <NUM> may demodulate P using the PIN of the device <NUM> previously acquired in operation <NUM> of <FIG>.

In operation <NUM>, verification on SN may be performed. When a verification result is normal, in operation <NUM>, the public key PUB_KEYD may be registered to be used in a subsequent OTP authentication process. During the aforementioned process, a private key of the device <NUM> may not be extracted by the CA <NUM>. Also, since the private key of the device <NUM> is not externally exposed in any case, only the device <NUM> may be allowed to demodulate data encrypted using the public key PUB_KEYD.

Also, a self-replication of the device <NUM> based on the PUF may be impossible. When the public key PUB_KEYD of the device <NUM> is exposed from the CA <NUM> due to secure attack, or PIN is exposed, a device <NUM> other than the public key PUB_KEYD, for example, a device pretending to function as the device <NUM> may demodulate the data encrypted using the public key PUB_KEYD.

Accordingly, despite a security incident occurring at an end of the CA <NUM>, the CA <NUM> may not responsible for a payment transaction in which the encrypted data is successfully demodulated using the public key PUB_KEYD of the device <NUM>.

<FIG> is a flowchart illustrating a process of generating an OTP in an HW OTP providing apparatus and authenticating the generated OTP in a CA according to an example embodiment.

When a CA <NUM> is to authenticate a device <NUM>, the CA <NUM> may generate a random number, R corresponding to a challenge in a challenge-response scheme, and generate Q by encrypting R using a public key PUB_KEYD of the device <NUM>.

In operation <NUM>, the CA <NUM> may transmit Q to the device <NUM>. In operation <NUM>, the device <NUM> may restore Q by demodulating Q using a private key PRIV_KEYD of the device <NUM>.

In operation <NUM>, the device <NUM> may generate an OTP K using a predetermined method by providing R to an OTP generation module, for example, a module based on a hash type OTP generation algorithm processing.

In operation <NUM> the generated OTP K may be provided to the CA <NUM>. In this example, the OTP K may be provided through an encryption based on a safe scheme. As an example, when the device <NUM> previously acquires a public key PUB_KEYCA of the CA <NUM>, the OTP K may be provided by encrypting an OTP using the public key PUB_KEYCA.

Alternatively, based on a <NUM>-factor authentication method described with reference to <FIG>, the SE <NUM> may provide K generated by the HW OTP element <NUM> to the CA <NUM> based on an encryption scheme of the SE <NUM>.

In operation <NUM>, the CA <NUM> may generate an OTP value, S by using R based on the same scheme as that of the device <NUM>. In operation <NUM>, the CA <NUM> may verify whether S generated by the CA <NUM> is the same as K provided from the device <NUM>, thereby performing an OTP authentication process.

As described above, since Q is obtained by encrypting R transmitted from the CA <NUM> using the public key PUB_KEYD of the device <NUM>, an object other than the device <NUM> having the private key PRIV_KEYD that is not exposed externally may not be allowed to demodulate Q and restore R. Accordingly, in a case in which the public key PUB_KEYD is exposed by the CA <NUM>, the CA <NUM> may not responsible for restoration of R using the private key PRIV_KEYD and a transaction denied for this reason.

The aforementioned descriptions related to the OTP authentication process based on the challenge-response scheme are provided as an example and thus, an OTP authentication may be performed through various processes based on an implementation of an HW OTP providing apparatus. As a related example, a time-synchronization based OTP authentication will be described with reference to <FIG> and <FIG>.

<FIG> illustrates an example of comparison between an authentication process of a <NUM>-factor authentication apparatus and a general authentication process according to an example embodiment.

In general, a terminal and/or user authentication may be performed by only an SE <NUM> based on a <NUM>-factor authentication. For this reason, various secure risks, for example, a certificate authentication file leakage, illegal re-issue of certificate authentications, a password leakage, screen or keyboard hacking may potentially exist.

Although the OTP authentication is performed separately from the SE <NUM>, an OTP device may be implemented through software and thus, hacking risks may exist. Alternatively, since a key and data used in OTP generation are recorded in a storage medium, risks of OTP replication may also exist.

As described with reference to <FIG>, since a first authentication is performed by the SE <NUM> and a second authentication is performed by a PUF based HW OTP <NUM> that is not replicable and implemented with the SE <NUM>, a secure attack may not affect a <NUM>-factor authentication.

Accordingly, a high level of authentication reliability may be provided to commercial/financial transaction subjects and a TSM <NUM> managing future electronic commercial or financial transactions.

<FIG> illustrates an example of an HW OTP authentication process according to an example embodiment.

A user/terminal authentication performed by an HW OTP <NUM> may not be based on a successful authentication performed by the SE <NUM> using a typical scheme described with reference to <FIG>.

Depending on an example, an authentication process may be performed at a high level through an OTP authentication of the HW OTP <NUM> included in a terminal <NUM> and an external institute.

Thus, the authentication may be performed by only the HW OTP when a subject of electronic commerce/financial transaction or a TSM requires an authentication of the HW OTP <NUM>. When the HW OTP <NUM> transmits a PUF-based OTP, the TSM may authenticate the terminal <NUM> by verifying the OTP.

Accordingly, it is apparently understood that example embodiments are not limited to an example of the <NUM>-factor authentication.

<FIG> illustrates an example of safety of an HW OTP authentication according to an example embodiment.

A probability that an authentication number provided to a terminal <NUM> is extorted through a hacking may be present in an authentication process based on an authentication number, for example, a one-time authentication number including four or six digits, commonly used in a small sum payment in general.

As an example, a hacking tool or a malignant code may be installed in the terminal <NUM> to extort the authentication number through, for example, a screen hacking and a key input hacking. The extorted authentication number may be used in an authentication process performed in another terminal <NUM>.

However, replication of an HW OTP <NUM> may be impossible. Also, a proper OTP value may be generated only in the terminal <NUM> including the HW OTP <NUM> and thus, a high security level may be ensured.

As described above, since the OTP value generated by the HW OTP <NUM> is not output through, for example, a display of the terminal <NUM> and seamlessly transmitted to a certificate authority through a safe encryption, the authentication process may not be affected by the screen hacking and the key input hacking. In this example, an individual may not recognize the generated OTP value during the authentication process.

Furthermore, in this example, the aforementioned typical authentication based on a common authentication number and the authentication using the HW OTP <NUM> may be performed simultaneously. Thus, although the <NUM>-factor authentication is performed in practice, a user may recognize a scheme using the authentication number and may not recognize the OTP authentication process. Accordingly, a user convenience may be improved and the user may be aware of a trivial difference when compared to the typical authentication process.

<FIG> illustrates another example of safety of an HW OTP authentication according to an example embodiment.

An authentication process of an HW OTP <NUM> according to example embodiments may be used in transactions such as a financial trade and an electronic payment, and an account login process of a website or a cloud service.

In an example of a cloud service illustrated herein, an authentication may be performed in a terminal <NUM> using the HW OTP <NUM> in addition to and/or alternatively to a typical account information authentication based on, for example, e-mail, account identification (ID), password input. In this example, although an account theft is attempted in a terminal <NUM> through an extortion of the account information, an account access of the terminal <NUM> may not be allowed. The foregoing example may be based on a case in which the terminal <NUM> may not be allowed to perform the OTP authentication since the replication of the HW OTP <NUM> is impossible.

In terms of a cloud service, a user may store private photographs through synchronization, or important documents for business, schedules, and a social networking service (SNS) history may also be stored through the synchronization. Thus, through the account theft, an attacker may extort such information by performing synchronization or download.

Accordingly, the HW OTP authentication may prevent an account theft, thereby increasing a service reliability.

<FIG> illustrates an example of a method of applying an HW OTP authentication to a digital rights management (DRM) according to an example embodiment.

An HW OTP authentication according to example embodiments may also be applied to a contents copyright management such as a DRM in an online contents trade.

In operation <NUM>, a device <NUM> of a reliable certificate authority such as a TSM may provide an HW OTP public key of a device <NUM> when contents transmission is to be performed between a digital contents provider <NUM> and the device <NUM>. As illustrates with reference to <FIG> and <FIG>, the foregoing example may be based on a case in which the public key is used in data or information encryption and there is no probability that may be disguised as the terminal <NUM> when a private key for demodulation is absent.

To apply purchased digital contents, contents related to the DRM may need to be encrypted and decrypted. In a process of the encrypting and decrypting, a secret key scheme may be used for efficiency of encryption and decryption.

Thereafter, the digital contents provider <NUM> may encrypt the contents based on a random number R, and transmit the random number R used to decrypt the encrypted contents based on the public key in operation <NUM>.

In this example, only the private key of the terminal <NUM> may be allowed to decrypt the random number R used by the digital contents provider <NUM> for the contents DRM. Thus, the secret key may be restored to decrypt the contents in the terminal <NUM>.

<FIG> illustrates an example of a time synchronization based HW OTP providing apparatus according to an example embodiment.

Although the foregoing descriptions are provided based on an example of an HW OTP performing an OTP authentication using a challenge-response scheme, this disclosure is not limited thereto.

In an example, an apparatus <NUM> for generating an OTP through hardware based on a PUF may generate an OTP through an update performed by receiving an initial time value based on a time synchronization scheme.

In this example, a time information updater <NUM> may update the initial time value at a predetermined time interval, for example, at an interval of one minute, and provide the updated initial time value to an OTP generator <NUM>.

When a request for an OTP authentication is received from an external source, the OTP generator <NUM> may provide an OTP by generating the OTP based on the time information and a unique PIN of the apparatus <NUM> provided from PUF(PIN) <NUM>.

After the PIN is initially extracted and safely registered, a blocker <NUM> may physically block the PIN from the external source.

<FIG> is a flowchart illustrating a process of initially extracting a PIN from the HW OTP <NUM> of <FIG>.

In operation <NUM>, time synchronization information, for example, an initial time value, and a serial number, SN of a device <NUM> may be assigned to the device <NUM> in a factory <NUM> for manufacturing the device <NUM>.

In operation <NUM>, the device <NUM> may provide SN and a unique PIN provided from PUF(PIN) to the factory <NUM>. After an initial extraction, PIN_out may be blocked in operation <NUM>.

In operation <NUM>, the factory <NUM> may provide SN and PIN to a CA <NUM> through a safe process. The CA <NUM> may manage SN and PIN through a matching so as to use SN and PIN in a subsequent OTP authentication performed on the device <NUM> based on the time synchronization scheme. As described above, the CA <NUM> may perform the process performed in the factory <NUM> when SN∥PIN is to be transmitted to the CA <NUM> with an increased safety.

<FIG> is a flowchart illustrating a process of generating an OTP in an HW OTP providing apparatus of <FIG> and authenticating the generated OTP in a CA.

Each of a device <NUM> and a CA <NUM> may update synchronized time information through operations <NUM> and <NUM>. When an OTP authentication is necessary, in operation <NUM>, the device <NUM> may generate an OTP K based on the updated time information and a PIN of the device <NUM>. Thereafter, K may be safely encrypted as Q to be transferred to the CA <NUM>, and then decrypted to be K again.

In operation <NUM>, the CA <NUM> may perform verification through a comparison between K and S autonomously generated based on the time information and the PIN of the device <NUM> in operation <NUM>, thereby performing an OTP-based authentication on the device <NUM>.

The foregoing descriptions related to implementation and operation of an HW OTP may be provided with reference to <FIG> as an example and thus, it is apparent that various examples are applicable thereto.

Claim 1:
An authentication apparatus (<NUM>) comprising:
a secure element (<NUM>) to perform a first authentication process; and
an one-time password, OTP, element (<NUM>) comprising a physically unclonable function, PUF, to generate an OTP and perform a second authentication process related to an OTP submission process,
the OTP element (<NUM>) comprising a private key (PRIV_KEYD) generated using the PUF and a public key (PUB_KEYD) generated corresponding to and based on the private key (PRIV_KEYD),
wherein the first and second authentication process are processes of a <NUM>-factor authentication,
wherein the OTP element (<NUM>) is adapted to transmit the OTP externally through an input and output interface of the secure element (<NUM>) and is adapted to, in response to the second authentication process, when a random number (R) encrypted using the public key (PUB_KEYD) of the OTP element (<NUM>) is received from a certificate authority (<NUM>), decrypt the random number (R) using the private key (PRIV_KEYD), and generate the OTP using the decrypted random number (R),
wherein the OTP element (<NUM>) comprises a blocker (<NUM>) adapted to physically block a re-extraction of a PUF-PIN, that is used by the OTP element (<NUM>) to encrypt the public key (PUB_KEYD), after an extraction of the PUF-PIN and before the authentication apparatus (<NUM>) performs the second authentication process,
wherein the public key (PUB_KEYD) has been exchanged between the authentication apparatus (<NUM>) and the certificate authority (<NUM>) in advance of the authentication process, and
wherein the secure element provides an only access to the OTP element (<NUM>) to prevent external access to the OTP element (<NUM>).