Method for storing a cryptographic seed in a smart card containing a serial number

Abstract

A method for storing a cryptographic seed held by a crypto-asset hardware wallet (HW) in a smart card (SC) comprises the following steps: establishing (S01, S02) an encrypted communication channel (SCPA, SCPB) between the card and the hardware wallet; communicating (S10) a serial number held by the card to the hardware wallet and displaying the serial number by the hardware wallet; and detecting (S20) a user action confirming that the displayed serial number is identical to a serial number displayed on the card body, before transmitting (S40) the cryptographic seed to the card. (Abstract figure: Figure 5)

Description

Title of the invention: Method for saving a cryptographic seed in a smart card containing a serial number. Technical field

[0001] This disclosure relates to the safeguarding, in a smart card or similar device, of a secret held by an electronic device, and in particular of a cryptographic seed held by a hardware wallet of crypto-assets. Background

[0002] In the field of crypto-assets, the secure holding of a cryptographic seed is a crucial issue, particularly with regard to a BIP 32 seed used to generate deterministic and hierarchical keys associated with crypto-asset accounts on blockchains. This seed, generally stored in a hardware wallet, constitutes the primary key used to restore, manage, and transfer digital assets associated with one or more cryptographic addresses on one or more blockchains. The security and integrity of this seed are therefore fundamental, as its compromise can lead to the total and irreversible loss of the crypto-assets concerned.

[0003] To prevent the risk of loss or damage to the physical wallet containing the seed, various solutions have been considered for backing up this seed on an unalterable external medium. Among the known solutions is backing up the seed on a smart card, an option often appreciated by users due to its simplicity and ergonomic advantages.

[0004] However, the choice of the protocol for securing communication between the card and the wallet during the transfer of the seed, as well as the choice of the type of card used for saving the seed, remain problematic.

[0005] Various types of pre-configured cards, capable of establishing an encrypted communication channel with host equipment, are currently available on the market and sold between businesses ("B2B"). Such cards can be quickly integrated into an existing ecosystem, thus avoiding the complete development of a proprietary solution that is often costly and complex to implement.

[0006] The GlobalPlatform organization establishes, in particular, specifications for several types of cards that can implement standardized secure communication channels, known as "SCPs" ("Secure Channel Protocols"), to ensure the encryption and authentication of exchanges between the card and the host device. The protocols Currently known GlobalPlatforms include, among others, SCP01, SCP02, SCP03, and SCP10.

[0007] Older protocols, such as SCP01 or SCP02, are based on the DES or 3DES ("Data Encryption Standard") algorithm and are now considered insufficiently robust. They no longer meet the level of security required by modern uses, particularly in the context of cryptoassets, where key protection is critical.

[0008] The more modern SCP03 protocol uses encryption algorithms such as AES (Advanced Encryption Standard) to establish an encrypted channel. This protocol is widely adopted and considered secure for many applications. It provides a first level of protection, particularly against the interception of communications. However, SCP03 does not cover all conceivable attack scenarios for safeguarding a cryptographic seed. For example, even with the SCP03 channel in place, a highly motivated and sophisticated attacker could attempt to bypass certain steps or exploit vulnerabilities not covered by the encrypted channel alone. Thus, while adequate for many uses, the SCP03 protocol might be deemed insufficient with regard to the enhanced security requirements for safeguarding cryptographic seeds.

[0009] GlobalPlatform-compatible JavaCards, preconfigured for SCP03, are available from various manufacturers. They are generally shipped without customization and require configuration and software deployment. Such secure cards incorporate Secure Element microcontrollers with hardware cryptographic capabilities that conform to the GlobalPlatform specifications. Their operating system is provided by default with computing functionalities related to the SCP03 protocol, as well as the processing of standard commands, such as INITIALIZE UPDATE and EXTERNAL AUTHENTICATE.

[0010] The most recent protocol, SCP10, utilizes a mechanism based on the Elliptic Curve Diffie-Hellman (ECDH) for key generation and exchange, combined with AES for data encryption, thus offering a higher and more flexible level of security. In theory, SCP10 could better meet the need for ultra-secure seed transfer and storage. However, the deployment of SCP10 cards on the market is not yet widespread: these newer cards are less readily available and likely more expensive. Adopting SCP10 could therefore prove difficult, if not prohibitively so, in terms of cost and supply, at least for the time being.

[0011] There remains the option of a completely proprietary, custom-designed solution, without relying on standard SCPs. Such a solution could precisely meet the specific security needs of seed backup, but it would require complete control of the process, specialized software and hardware development, and high certification and maintenance costs. Moreover, in an ecosystem strongly oriented towards interoperability, a proprietary solution faces practical difficulties: reduced compatibility, the need for specialized partnerships, and a lack of flexibility in the face of evolving technologies.

[0012] For specific uses, such as storing cryptographic seeds, some specialized vendors offer pre-configured cards for this purpose. However, the available documentation remains insufficient regarding the processes actually used by these vendors, who remain secretive about their methods. The means of ensuring reliable two-way authentication, effectively protecting the seed during its transfer, and preventing its compromise once stored on the card are neither clearly established nor documented.

[0013] Thus, in the current state of the market and standards, no standardized, readily available and fully satisfactory solution clearly seems to be emerging to meet the high security requirements that apply to the transfer of a seed into a smart card.

[0014] There is therefore a clearly identified need to define a method for saving a cryptographic seed in a smart card, offering a level of security higher than that of available standards, without generating problematic costs or supply constraints.

[0015] It might therefore be desirable to propose a robust, reproducible process adapted to the requirements of the crypto-asset field, combining cryptographic strength, availability of hardware and rational implementation, in order to ensure that the seed is secure from its transfer until its long-term storage.

[0016] Independently of this first requirement, there is also a need to provide a method for backing up a cryptographic seed that can be partially secured by the user. Since the user is capable of vigilance, they could indeed be involved in securing the backup process to add an additional layer of security.

[0017] Independently of these two needs, there is also a need to provide a highly secure process for verifying that a cryptographic seed saved in a smart card corresponds to the cryptographic seed held by the hardware wallet from which it was transferred into the card or into which it was restored. Summary

[0018] Embodiments relate to a method for saving, in a smart card, a cryptographic seed held by a hardware crypto-asset wallet, the hardware wallet and the smart card each comprising a secure processor having volatile memory and non-volatile memory, the hardware wallet further comprising an information display means and an information input means, the method comprising the following steps: prior inscription of a serial number on the body of the card in a user-readable manner, and prior storage of the serial number in the card; establishment of a communication link between the hardware wallet and the card; establishment of an encrypted communication channel between the card and the hardware wallet; communication to the hardware wallet, via the encrypted communication channel, of the serial number held by the card;Receipt by the hardware wallet and display on the hardware wallet screen, for the user's attention, of the received serial number; detection or recording by the hardware wallet of at least one user action on the information input device, confirming that the serial number displayed on the screen is identical to the serial number displayed on the card body; by means of the hardware wallet, if the hardware wallet has detected or recorded said user action confirming that the serial number displayed on the screen is identical to the serial number displayed on the card body, transmission of the cryptographic seed to the card via the encrypted communication channel; and storage of the cryptographic seed by the card.

[0019] According to one embodiment, the method comprises the following steps: using the hardware wallet, entry of a personal identification code of the user, and transmission of the personal identification code to the card via the encrypted communication channel, and storage of the personal identification code by the card, the action of the user confirming that the serial number displayed on the screen is identical to the serial number displayed on the body of the card consisting of the entry by the user of the personal identification code.

[0020] According to one embodiment, the method includes a verification step by the hardware wallet of the cryptographic seed stored in the card, the verification step comprising the following steps: the hardware wallet sends a challenge to the card; the card generates a private key by derivation of the cryptographic seed, according to a derivation path; the card conducts a cryptographic computation from the challenge and the derived key, generates a result of this cryptographic computation, and sends this result to the hardware wallet; the hardware wallet generates the same private key by derivation of the cryptographic seed, according to the same derivation path; and the hardware wallet verifies, by means of the derived private key, the result of the cryptographic computation sent by the card.

[0021] According to one embodiment, the method includes a preliminary step of storing the derivation path in the hardware wallet and the card before they are put into service.

[0022] According to one embodiment, the derivation path is dynamically generated by the hardware wallet and the card from the challenge sent by the hardware wallet to the card and according to the same derivation path generation rule.

[0023] According to one embodiment, the cryptographic seed verification step is systematically initiated after the cryptographic seed has been saved in the card.

[0024] According to one embodiment, the cryptographic seed verification step can be initiated at any time at the user's request.

[0025] According to one embodiment, the encrypted communication channel comprises a first encrypted communication channel implementing a first encryption technique, in which is encapsulated a second encrypted communication channel implementing a second encryption technique, the second encrypted communication channel being encapsulated in the first encrypted communication channel, the process comprising the following steps: establishment between the card and the hardware wallet of the first encrypted communication channel; authentication of the card by the hardware wallet and authentication of the hardware wallet by the card, via the first encrypted communication channel;then establishment between the card and the hardware wallet, via the first encrypted communication channel, the second encrypted communication channel, the serial number held by the card being transmitted to the hardware wallet via the first encrypted communication channel before the establishment of the second encrypted communication channel, or via the second encrypted communication channel.

[0026] According to one embodiment, the method comprises the following steps: prior storage in the hardware wallet of a public key of a trusted authority, a static private key and a static public key of the hardware wallet, and a static certificate of the hardware wallet comprising a signature of the static public key of the hardware wallet by means of a private key of the trusted authority, prior storage in the card of the public key of the trusted authority, a static private key and a static public key of the card, and a static certificate of the card comprising a signature of the static public key of the card by means of the private key of the trusted authority.The authentication of the card by the hardware wallet and the authentication of the hardware wallet by the card, via the first encrypted communication channel and before the establishment of the second encrypted communication channel, includes a verification step by the wallet. hardware of the authenticity of the signature present in the static certificate of the card, and a verification step by the card of the authenticity of the signature present in the static certificate of the hardware wallet, using the public key of the trusted authority.

[0027] According to one embodiment, the method comprises, for the establishment of the second encrypted communication channel, the following steps: generation by the card of an ephemeral private key and public key; generation by the hardware wallet of an ephemeral private key and public key; transmission to the hardware wallet, via the first encrypted communication channel, of the ephemeral public key of the card; transmission to the card, via the first encrypted communication channel, of the ephemeral public key of the hardware wallet; generation of a secret shared by the card from the ephemeral public key of the hardware wallet and generation of the same secret shared by the hardware wallet from the ephemeral public key of the card; derivation of the secret shared by the card and derivation of the secret shared by the hardware wallet to obtain a common session key;and encryption of the second communication channel encrypted by the card and by the hardware wallet using the common session key.

[0028] According to one embodiment, the method comprises, for the establishment of the second encrypted communication channel, the following steps: generation by the card of an ephemeral certificate comprising the ephemeral public key of the card and a signature of the ephemeral public key by the static private key of the card; transmission to the hardware wallet, via the first encrypted communication channel, of the ephemeral certificate of the card; by means of the static public key of the card, verification by the hardware wallet of the authenticity of the signature present in the ephemeral certificate of the card; generation by the hardware wallet of an ephemeral certificate comprising the ephemeral public key of the hardware wallet and a signature of the ephemeral public key by the static private key of the hardware wallet; transmission to the card, via the first encrypted communication channel, of the ephemeral certificate of the hardware wallet;and using the static public key of the hardware wallet, verification by card of the authenticity of the signature present in the ephemeral certificate of the hardware wallet.

[0029] According to one embodiment, the second encryption technique is an elliptic curve cryptography comprising an exchange of ECDH elliptic curve Diffie Hellman keys for the generation of a shared secret.

[0030] According to one embodiment, the method comprises the first encryption technique is based on AES and conforms to the GlobalPlatform SCP03 specification.

[0031] According to one embodiment, the exchanges between the hardware wallet and the card are made via ISO7816 APDU units comprising APDU commands and APDU responses, and the exchanged APDU units are accompanied by a first message authentication code which is generated by means of a first cryptographic signature function.

[0032] According to one embodiment, the cryptographic seed is transmitted in APDU units in a doubly encrypted form, the generation of which comprises the following steps: a) encrypting the cryptographic seed in the second encrypted communication channel, in order to obtain a first encryption of the seed, b) calculating a message authentication code on the first encryption, by means of a second cryptographic signature function, c) concatenating the first encryption of the seed and the message authentication code, and d) encrypting the result of the concatenation within the first encrypted communication channel, in order to obtain the doubly encrypted form of the cryptographic seed.

[0033] According to one embodiment, the personal identification code is transmitted in APDU units in a doubly encrypted form, the generation of which comprises the following steps: a) encrypting the personal identification code in the second encrypted communication channel, in order to obtain a first encryption of the personal identification code, b) calculating a message authentication code on the first encryption of the personal identification code, by means of a second cryptographic signature function, c) concatenating the first encryption of the personal identification code and the message authentication code, and d) encrypting the result of the concatenation in the second encrypted communication channel, in order to obtain the doubly encrypted form of the personal identification code.

[0034] Embodiments also relate to a method of manufacturing a card capable of implementing the method described above, comprising the following steps: manufacturing a standard JAVA card having an operating system preconfigured to implement the GlobalPlatform SCP03 encrypted communication channel, downloading into the card an application program configured to implement the steps of the method and the second encrypted communication channel, and using as the first communication channel the GlobalPlatform SCP03 encrypted communication channel managed by the card's preconfigured operating system.

[0035] According to one embodiment, the method includes the step of including in the application program the public key of the trusted authority, the public and private keys and the static certificate of the card. Brief description of the drawings

[0036] Embodiments of a method for saving, restoring and verifying a cryptographic seed will be described below, without limitation, in relation to the accompanying figures, among which:

[0037] - Figure 1 shows an example of the architecture of a hardware portfolio comprising a cryptographic seed and an example of a smart card architecture used for seed saving,

[0038] - Figures from [Fig.2A] to [Fig.2H] show steps in a first method of saving the seed in the map,

[0039] - Figures from [Fig. 3A] to [Fig. 31] show steps in a second method of seed preservation,

[0040] - Figures from [Fig.4A] to [Fig.4I] show steps in a third seed preservation method combining characteristics of the first and second methods,

[0041] - Figure 5 describes one embodiment of the first backup method,

[0042] - Figure 6 describes an embodiment of the second backup method,

[0043] - Figure 7 describes an embodiment of the third backup method,

[0044] - Figures from [Fig.8A] to [Fig.8H] show steps in a first seed restoration process,

[0045] - Figures from [Fig.9A] to [Fig.9H] show steps in a second seed restoration process,

[0046] - Figures from [Fig.1OA] to [Fig.1OH] show steps in a third seed restoration process,

[0047] - Figure

[11] describes one embodiment of the first restoration process,

[0048] - Figure 12 describes one embodiment of the second restoration process,

[0049] - Figure 13 describes one embodiment of the third restoration process,

[0050] - Figure 14 describes steps of an algorithm for establishing a first channel encrypted communication between the wallet and the card,

[0051] - [Fig. 15] describes steps of an algorithm for transmitting a serial number from the map,

[0052] - Figures [Fig. 10A] and [Fig. 10B] describe steps in an establishment algorithm a second encrypted communication channel between the wallet and the card,

[0053] - Figure 17 describes steps of a card-based code recording algorithm PIN that is sent to him,

[0054] - Figure 18 describes steps of a seed saving algorithm,

[0055] - Figure 19 describes steps of a card verification algorithm for a code PIN that is sent to him,

[0056] - Figure 20 describes steps of a seed restoration algorithm in the wallet, and

[0057] - Figures [Fig. 21A] and [Fig. 21B] describe steps in a verification algorithm the seed held by the card. Detailed description

[0058] Figure 1 shows the architecture of a hardware wallet (HW) and the architecture of a smart card (CD) used for backing up or restoring a cryptographic seed held by the hardware wallet, according to this disclosure. In what follows, the hardware wallet will be referred to as "the wallet" and the smart card as "the card".

[0059] The wallet comprises a secure processor, here a secure element SE1 ("Secure Element"), a user information display means TS (User Display Resource), a user information input means KB (User Input Method), and a communication interface circuit INT1 (Integrated Communication Interface Circuit) controlled by a microcontroller microcontroller microcontroller (MCU) connected to the secure element SEL (Secure Element). The information display means TS is, for example, a touchscreen. The information input means KB is, for example, a touchscreen keyboard displayed by the touchscreen. In other embodiments, the input means KB is a physical keyboard and the display means TS is a non-touchscreen LCD or display. The display means TS and the input means KB are preferably controlled by the secure element but can also, in some embodiments, be controlled by the microcontroller microcontroller microcontroller (MCU).

[0060] The secure element comprises a non-volatile memory NVM1 and a volatile memory VM1. The non-volatile memory NVM1 includes a wallet operating system OS1, as well as an application program PGRW1 designed to implement the method of the invention.

[0061] The NVM1 non-volatile memory also includes a cryptographic MS seed. In some embodiments, this is a master seed generated in accordance with BIP 39 and used in accordance with BIP 32, namely to generate deterministic and hierarchical private / public key pairs associated with crypto-asset accounts on blockchains. As a reminder, BIP 39 defines the following steps that establish the link between the seed and what is commonly called a "recovery phrase" or "recovery phrase":

[0062] 1) Entropy generation or master seed: generation of random bits (128, 256 bits, etc).

[0063] 2) Adding a checksum: a SHA-256 hash is calculated of the entropy, then we take some bits from this hash and add them to the end of the original entropy.

[0064] 3) creation of the mnemonic phrase: we divide the sequence entropy + sum of control in 11-bit segments and each segment is associated with a word from the BIP 39 list.

[0065] 4) mnemonic phrase: this gives a list of 12, 15, 18, 21 or 24 words (depending on the size of the initial entropy).

[0066] 5) generation of a final seed: the mnemonic phrase (and possibly a optional passphrase) is converted into a binary sequence (usually 512 bits) via the PBKDF2-HMAC-SHA512 function (2048 iterations).

[0067] According to BIP 32 specification, this final 512-bit seed is then used to derive a master key and a chain code, from which all accounts and addresses in the HD wallet can be generated. The initial generation of the master key and the calculations leading to the final seed are generally performed by the wallet during its initial setup. The master key may also have been imported into the wallet by some restoration or transfer process, including the process that is the subject of this disclosure. It should be noted that the term "seed" is used here to refer primarily to the master key, or entropy.

[0068] In some embodiments, the wallet's non-volatile memory NVM1 may contain a static private key sKw and a static public key pKw assigned to the wallet, as well as a static certificate Cw and a public key pK of a trusted authority, for example, the wallet manufacturer. This static certificate includes at least the static public key pKw and a SIGN(pKw)sK signature of the public key pKw by a private key sK of the trusted authority, corresponding to the public key pK stored by the wallet. The certificate Cw may also include, in some embodiments, a "role-w" parameter assigned to the wallet.

[0069] The CD card comprises a CB card body (“Card Body”) in which is integrated a secure processor, generally a secure element SE2, and a communication interface circuit INT2 coupled to the secure element SE2. The secure element SE2 comprises a non-volatile memory NVM2 and a volatile memory VM2. The non-volatile memory NVM2 comprises a card operating system OS2, a PGRCA program, and an APPL-type “applet” application program that was loaded into the card during its customization.

[0070] The wallet and the card are designed to establish an LNK data link between them by means of their communication interfaces INT1, INT2. In the embodiment shown, the two communication interfaces are contactless and implement an NFC (Near Field Communication) protocol, for example based on the ISO / IEC 14443 standard. The LNK data link is then obtained by inductive coupling of the INT1, INT2 interfaces. including antenna coils and associated components. In practice, the SE2 secure element can be integrated into a micromodule inserted into the CB body of the board. Such a micromodule comprises a small antenna coil inductively coupled to a larger amplifying antenna, itself integrated into the board body. These elements are not shown in [Fig. 1] for the sake of schematic clarity.

[0071] In one embodiment, the PGRCA program is configured to establish an encrypted SCPA communication channel with the wallet, as well as to process encrypted channel management CAPDU commands conforming to ISO / IEC 7816, such as INITIALIZE UPDATE (0x80 50...), EXTERNAL AUTHENTICATE (0x84 82...), etc. In a particular embodiment, the card is a commercially available business-to-business JavaCard implementing the GlobalPlatform SCP03 standard. In this case, the PGRCA program is supplied with the card and pre-registered in its OS2 operating system.

[0072] In one embodiment, the APPL application program comprises two programs, PGRCB and PGRCS, which cooperate to implement the process. The PGRCB program establishes and manages, via the LNK link, a second SCPB communication channel. This second communication channel can, in one embodiment, be encapsulated within the first SCPA communication channel. The PGRCS program relies on the PGRCB program and implements the process, manages the MS seed, and in particular performs the steps of saving, restoring, and verifying the seed in the NVM2 non-volatile memory.

[0073] In one embodiment, the NVM2 non-volatile memory also includes a card serial number SN, which is also printed or engraved on the CB card body.

[0074] In one embodiment, the NVM2 memory also includes a static private key sKc and a static public key pKc assigned to the card, as well as a static certificate Ce of the card and the public key pK of the trusted authority. This static certificate includes at least the public key pKc and a SIGN(pKc)sK signature of the public key pKc by the private key sK of the trusted authority. The static certificate may also include, in some embodiments, a "role-c" parameter assigned to the card.

[0075] The serial number SN and / or the keys sKc, pKc, Pk and the Ce certificate can, in certain embodiments, be loaded into the non-volatile memory of the card during a personalization step which also includes loading the APPL application program into the non-volatile memory.

[0076] In the embodiments described below, the wallet will display a message to the user at the end of the backup process confirming the backup of the "recovery phrase." Despite this indication, intended to maintain language familiar to the user, the method of the invention can be implemented to back up the master seed as mentioned above. Furthermore, the method according to this disclosure is not limited to backing up a seed generated according to BIP 39 and used in accordance with BIP 32. The term "seed" should be understood to generally refer to any type of secret or any other type of seed defined according to specifications other than BIP 39 that must be backed up or restored.

[0077] Three variants, "backup 1", "backup 2", and "backup 3", of the process according to this disclosure will now be described. The "backup 1" process is illustrated in Figures 2A to 2H, the "backup 2" process is illustrated in Figures 3A to 31, and the "backup 3" process in Figures 4A to 41.

[0078] According to the "backup 1" method, Figures 2A to 2H, the user's vigilance is required to prevent the seed from being recorded on a counterfeit card. In these figures, the wallet has approximately the same dimensions as the card and is equipped with a touchscreen covering a large part of its surface. This screen is used to display instructions to the user during the backup process. It is also used to display keys for a virtual touchscreen keyboard that can detect a user action (for example, detecting a confirmation or back button action) or record a user action (for example, recording a code entered by the user).The card body clearly displays a user-readable serial number SN, in this case "141224-87E2", this same serial number being also stored in the non-volatile memory of the secure element SE2, as previously mentioned.

[0079] At a step illustrated in [Fig. 2A], the user selected the option to save the seed to the card from a menu in the wallet. The wallet displays a message prompting the user to bring the card close to the wallet ("tap card to start backup").

[0080] At a step illustrated in [Fig.2B], the user brought the card close to the wallet, and the latter established with the card the LNK wireless data link as well as an encrypted communication channel, then received from the card its serial number as recorded in the secure element SE2.

[0081] At a step illustrated in [Fig. 2C], the wallet displays the serial number and asks the user to verify that it matches the serial number displayed on the card body ("check serial number 141224-87E2"). The wallet displays also on the touch screen a confirmation button accompanied by the message "Press if OK".

[0082] At a step illustrated in [Fig. 2D], the user confirms the serial number match and presses the confirmation key, thereby performing an AC01 action detected by the wallet. Alternatively, if there is a mismatch between the displayed serial number and the one printed on the card, the user can cancel their save request, for example, by using the back arrows displayed on the screen.

[0083] At a step illustrated in [Fig. 2E], the wallet prepares to initiate the seed saving step, provided it has detected the user's AC01 action. The wallet displays a message prompting the user to tap and hold the card to back up the seed. This is because the user has moved the card away from the wallet in the meantime, so the LNK data link and the encrypted communication channel must be re-established. In a variant of the method, the wallet can ask the user, as early as step [Fig. 2A], to hold the card against the wallet until the backup process is complete, in order to prevent the contactless link from being re-established from step [Fig. 2E].Such an interruption of the contactless connection is only provided for ergonomic reasons, to allow the user to move the card away while handling the wallet.

[0084] At a step illustrated in [Fig. 2F], the user therefore brought the card close to the wallet again. The wallet then re-established the LNK link with the card as well as the encrypted communication channel.

[0085] At a step illustrated in [Fig.2G], the wallet proceeds to transfer the seed into the card and asks the user to keep the card close to the device ("keep holding").

[0086] At a step illustrated in [Fig.2H], the backup is completed and the wallet displays a success message indicating that the recovery phrase has been backed up ("Secret Recovery Phrase Backed Up").

[0087] According to the "backup 2" method, Figures 3A to 31, the user is required to create a personal identification code, or PIN code, before backing up the seed. This PIN code will be associated by the card with the backed-up seed and will then be requested by the latter during a restore step.

[0088] At a step illustrated in [Fig.3A], the wallet asks the user to bring the card closer to start the backup ("tap card to start backup").

[0089] At a step illustrated in [Fig.3B], the user brought the card closer to the wallet, and the latter established with the card the LNK data link as well as an encrypted communication channel.

[0090] At a step illustrated in [Fig.3C], the wallet asks the user to enter the PIN of their choice (“Choose PIN”) and displays a virtual touch keyboard for this purpose.

[0091] At a step illustrated in [Fig.3D], the user entered the PIN code of their choice and pressed a validation button.

[0092] In an optional step illustrated in [Fig. 3E], the wallet prompts the user to re-enter the retained PIN. The user complies and confirms their entry again.

[0093] At a step illustrated in [Fig. 3F], the wallet prepares to initiate the seed saving step, provided that the PIN code has been validly entered. The wallet displays a message prompting the user to bring the card close and hold it in that position to perform the seed saving ("tap and hold card to back up").

[0094] At a step illustrated in [Fig.3G], the user brought the card closer to the wallet and the wallet re-established the LNK link with the card as well as the encrypted communication channel.

[0095] At a step illustrated in [Fig.3H], the wallet proceeds to transfer the seed into the card and asks the user to keep the card close to the device ("keep holding").

[0096] At a step illustrated in [Fig.31], the backup is completed and the wallet displays a success message indicating that the recovery phrase has been backed up ("Secret Recovery Phrase Backed Up").

[0097] Finally, the "backup 3" method, shown in Figures 4A to 41, combines features of the "backup 1" and "backup 2" methods. The user is required to verify that the serial number displayed by the wallet matches the one printed on the card, and the user is also required to create a PIN before backing up the seed. To simplify the process and improve its usability, the user's entry of the PIN serves as confirmation that the displayed serial number is correct.

[0098] Thus, at a step illustrated in [Fig.4A], the wallet asks the user to bring the card closer to initialize the backup (“tap card to start backup”).

[0099] In a step illustrated in [Fig. 4B], the user brought the card close to the wallet. The wallet then established the LNK data link with the card, as well as an encrypted communication channel, and received the card's serial number as recorded in the secure element SE2.

[0100] At a step illustrated in [Fig.4C], the wallet displays the card's serial number and asks the user to enter their chosen PIN if the two serial numbers match ("Choose PIN for 141224-87E2 if Serial Numbers Match").

[0101] At a step illustrated in [Fig.4D], the user enters the PIN of their choice and presses a validation button, thereby performing an AC02 action detected by the wallet as a confirmation of the correspondence between the displayed serial number and the serial number on the card, as well as a confirmation of the entry of the PIN.

[0102] In an optional step illustrated in [Fig. 4E], the wallet prompts the user to re-enter the retained PIN. The user complies and confirms their entry again; in this case, action AC02 is only performed at this point.

[0103] At a step illustrated in [Fig. 4F], the wallet prepares to enter the seed saving step, provided that the PIN code has been validly entered. The wallet displays a message prompting the card to be brought close and held in that position ("tap and hold card to back up").

[0104] At a step illustrated in [Fig.4G], the user brought the card closer to the wallet, and the wallet re-established the LNK link with the card and the encrypted communication channel.

[0105] At a step illustrated in [Fig.4H], the wallet proceeds to transfer the seed into the card and asks the user to keep the card close to the device (“keep holding”).

[0106] At a step illustrated in [Fig.41], the backup is completed and the wallet displays a success message indicating that the recovery phrase has been backed up ("Secret Recovery Phrase Backed Up").

[0107] Figures 5, 6, and 7 describe embodiments of the "backup 1," "backup 2," and "backup 3" methods in which the transmission of the seed to the card, as well as the transmission of the PIN code (methods "backup 2" and "backup 3"), is carried out via a first encrypted SCPA communication channel implementing a first encryption technique, for example, symmetric, and a second encrypted SCPB communication channel implementing a second encryption technique, for example, asymmetric, the second channel being encapsulated within the first. Thus, the seed and the PIN code are transmitted in a super-encrypted form, that is, encrypted twice, first by an encryption key specific to the second SCPB channel, and then by an encryption key from the first SCPA channel.

[0108] In one embodiment, the first SCPA channel is a standard SCP03 GlobalPlatform channel, preconfigured in the board's operating system. The second SCPB channel is managed by the PGRCB program of the APPL application program loaded into the board.

[0109] Furthermore, according to an optional aspect of these embodiments, the wallet and the card implement mutual verification steps for their respective static certificates Cw, Ce. Each device verifies the validity of the signature present in the other device's static certificate using the public key of the trusted authority it holds. Advantageously, this verification is performed after the establishment of the first encrypted SCPA communication channel, and through it, each device communicates its static certificate to the other in encrypted form.

[0110] According to an optional but advantageous aspect of this embodiment, when the card's serial number SN is transmitted to the wallet for verification by the user (processes "backup 1" and "backup 3"), this serial number is transmitted from the card to the wallet in encrypted form via the SCPA channel or in super-encrypted form via the SCPB channel encapsulated in the SCPA channel.

[0111] Figure 5 describes the application of this embodiment to the "backup 1" process. The correspondences between the steps in Figures 2A to 2H and those described in Figure 5 are indicated in parentheses in what follows.

[0112] At step S00 ([Fig. 2A]), the wallet displays the message "Bring the card close to initiate backup" to the user. At step SOI ([Fig. 2B]), the wallet and the card exchange data to establish the first encrypted SCPA communication channel. At step S02 ([Fig. 2B]), the wallet verifies the card's certificate and the card verifies the wallet's certificate via the SCPA channel, the certificates being exchanged in encrypted form. Then, the two devices exchange data, again via the SCPA channel, to establish the SCPB channel. At step S10a ([Fig. 2B]), the card transmits the serial number to the wallet via SCPA or SCPB. At step S10b ([Fig. 2C]), the wallet receives the serial number and requests the user to verify it. At an S20 step, the wallet receives the user's agreement ([Fig.2D]) and then asks them ([Fig.2E]) to bring the card close and hold it for saving.The wallet and card then repeat the SOI step to re-establish the SCPA channel ([Fig. 2F]) and then the S02 step to verify their respective certificates. At an S40 step, the wallet transmits the MS seed to the card via SCPA and SCPB. During these steps, the wallet prompts the user to keep the card nearby ([Fig. 2G]). At an S41 step, the card decrypts the seed. At an S42 step, the card stores the seed. At an S43 step, the card sends a success message to the wallet, and the wallet receives the success message.

[0113] At step S50, the wallet and the card cooperate to implement an optional seed verification step, which consists of verifying that the seed held in the wallet is the same as the one held by the card. Once this verification is complete, the wallet indicates to the user that the recovery phrase has been saved ([Fig.2H]).

[0114] Figure 6 describes the application of the encrypted dual-channel embodiment to the "backup 2" process described in relation to Figures 3A to 3H. The wallet The wallet and card execute the SOO, SOI, and S02 steps (Figs. 3A, 3B) already described. At step S100, the wallet prompts the user to choose a PIN ([Fig. 3C]). At step S20', the wallet saves the user's PIN (Figs. 3D, 3E) and asks them to bring the card close and hold it to perform the save operation ([Fig. 3F]). When the contactless connection is re-established ([Fig. 3G]), the wallet and card execute the SOI and S02 steps again. At step S30, the wallet transmits the PIN to the card via SCPA and SCPB. At step S31, the card decrypts the PIN. During these steps and those that follow, the wallet prompts the user to hold the card close ([Fig. 3H]). At step S32, the card stores the PIN in its non-volatile memory. At step S33, the card sends a success message to the wallet.During the previously described steps S40, S41, S42, and S43, the wallet transmits the seed to the card via the encrypted communication channels SCPA and SCPB. The card decrypts the seed, stores it in its non-volatile memory, and sends a success message to the wallet. Before the wallet displays a successful transaction message, the optional seed verification step S50 can be implemented.

[0115] Figure 7 describes the application of the dual-channel encrypted embodiment to the "backup 3" process described in relation to Figures 4A to 4L. The process is initiated with steps S00, S01, S02, and S01a (Figs. 4A and 4B). At step S01c, the wallet receives the serial number and prompts the user to enter a PIN if the serial numbers match (Figs. 4C). At step S20', the wallet saves the PIN (Figs. 4D and 4E) and prompts the user to bring the card close for backup (Figs. 4F). Then, the wallet and the card execute steps S01 and S02 again (Figs. 4G). At step S30, the wallet transmits the PIN code to the card via the SCPA, SCPB channels, the card decrypts it at step S31, stores it at step S32, and then sends a success message to the wallet at step S33 ([Fig.4H]). Then, during steps S40, S41, S42, S43 ([Fig.4H]), the wallet transmits the seed to the card via SCPA and SCPB, the card receives it in encrypted form, decrypts it, then stores it in its non-volatile memory, and sends a success message to the wallet. Before the wallet displays a success message ([Fig.4I]), the optional S50 seed verification step can be implemented.

[0116] Figures 8A to 8H illustrate steps in an embodiment of a process " "Restore 1" implements the same security mechanisms as the "Backup 1" process described in relation to Figures 2A to 2H. User vigilance is again required to avoid retrieving a seed from a counterfeit card. At a step illustrated in [Fig. 8A], the user selected the option to restore the seed to the wallet, which then displays a message asking the user to tap the card ("tap card to start restore"). At a step illustrated in the[Fig. 8B], the user brings the card close, and the wallet establishes the LNK contactless connection and an encrypted channel, then receives the card's serial number. At a step illustrated in [Fig. 8C], the wallet displays the serial number and asks the user to verify that it matches the one on the card ("check serial number 141224-87E2"). It also displays a confirmation button ("Press if OK"). At a step illustrated in [Fig. 8D], the user confirms the match and presses the button, performing the AC01 action detected by the wallet. If there is no match, the user can cancel the restore request. At a step illustrated in [Fig. 8E], the wallet prepares to initiate the restore, provided it has detected the user's AC01 action. It displays a message prompting the user to bring the card close and hold it ("tap and hold card to restore"). At a step illustrated in [Fig.[8F], the user brings the card close, and the wallet re-establishes the LNK connection and the encrypted channel. At a step illustrated in [Fig. 8G], the card transfers the seed to the wallet, and the wallet asks the user to keep the card close ("keep holding"). At a step illustrated in [Fig. 8H], the restoration is complete, and the wallet displays a success message ("Secret Recovery Phrase Restored").

[0117] Figures 9A to 9H illustrate an embodiment of a "restore 2" process implementing the same security mechanisms as the "backup 2" process of Figures 3A to 3H, in which the user must provide the chosen PIN before the seed is restored. In a step illustrated in [Fig. 9A], the wallet prompts the user to tap the card to initiate the restore ("tap card to start restore"). In a step illustrated in [Fig. 9B], the user taps the card, and the wallet establishes the LNK data link and an encrypted communication channel with the card. In a step illustrated in [Fig. 9C], the wallet prompts the user to enter their PIN. In a step illustrated in [Fig. 9D], the user enters and validates the PIN. In a step illustrated in [Fig. 9E], the wallet prompts the user to tap the card to initiate the restore. At a stage illustrated on the [Fig.[9F], the user brings the card close, and the wallet re-establishes the LNK connection and the encrypted communication channel. The wallet transmits the PIN to the card, which checks if it matches the one stored during the backup. If it fails, the card refuses to continue the restoration process. If the two PINs match, the wallet asks the user to keep the card close ("keep holding") as illustrated in [Fig. 9G]. At a step illustrated in [Fig. 9H], the restoration is complete, and the wallet displays a success message ("Secret Recovery Phrase Restored").

[0118] Figures 10A to 10H illustrate an embodiment of a "restoration 3" process implementing the safety mechanisms of the "backup 3" process of the Figures 4A to 41. At a step illustrated in [Fig. 1OA], the wallet prompts the user to tap the card to initiate the restore process ("tap card to start restore"). At a step illustrated in [Fig. 1OB], the user taps the card, and the wallet establishes the LNK data link and an encrypted communication channel. At a step illustrated in [Fig. 1OC], the wallet displays the serial number and prompts the user to enter their PIN if the serial numbers match ("Enter PIN for 141224-87E2 if Serial Numbers Match"). At a step illustrated in [Fig. 1OD], the user enters their chosen PIN and confirms it, thus performing action AC02, which the wallet detects as a confirmation of the serial number match, in addition to confirming the PIN entry. At a step illustrated in [Fig.[lOE], the wallet displays a message prompting the user to tap and hold the card to restore the seed phrase. At a step illustrated in [Fig. 10F], the user taps the card, and the wallet re-establishes the LNK connection and the encrypted communication channel. The wallet transmits the PIN to the card, which checks if it matches the one stored during the backup. If it fails, the card refuses to continue the restoration process. If the comparison is successful, the wallet and card initiate the seed phrase restoration, and the wallet prompts the user to keep the card close ("keep holding") as illustrated in [Fig. lOG]. At a step illustrated in [Fig. lOH], the restoration is complete, and the wallet displays a success message indicating that the recovery phrase has been restored ("Secret Recovery Phrase Restored").

[0119] Figures 11, 12, and 13 describe embodiments of the "restoration 1," "restoration 2," and "restoration 3" processes in which the card's seed retrieval, and optionally the transmission of the PIN, is performed via the two encrypted communication channels SCPA and SCPB, implementing different encryption techniques. As before, the first encrypted communication channel, SCPA, can be a standard GlobalPlatform SCP03 channel preconfigured in the card's operating system. The wallet and card can also implement mutual verification steps for their static Cw, Ce certificates. Furthermore, when the card's serial number (SN) needs to be transmitted to the wallet for user verification, it can be transmitted in encrypted form via the SCPA channel or in super-encrypted form via the SCPB channel encapsulated within the SCPA channel.

[0120] Figure 11 describes the application of this embodiment to the process described in relation to Figures 8A to 8H. Steps similar to those previously described are designated by the same reference numerals.

[0121] At step S00', the wallet displays the message "Bring the card close to initiate restoration" ([Fig. 8A]). At step SOI, the wallet and card exchange data to establish the encrypted SCPA communication channel ([Fig. 8B]). At step S02, each device verifies the other's static certificate via the SCPA channel ([Fig. 8B]), and then they establish the SCPB channel. At step S10a, the card transmits the serial number to the wallet via SCPA or SCPB. At step S10c, the wallet receives the serial number and asks the user to verify it ([Fig. 8C]). At step S200', the wallet receives the user's consent and then asks the user to bring and hold the card for restoration (Figs. 8E, 8F). The wallet and card then repeat steps SOI and S02. At step S400, the card transmits the MS seed to the wallet via the SCPA and SCPB channels ([Fig.8G]). At step S410, the wallet decrypts the seed.At step S420, the wallet stores the seed. The wallet and the card then cooperate for the optional step S50 of seed verification. Once this verification is complete, the wallet informs the user that the recovery phrase has been restored ([Fig.8H]).

[0122] Figure 12 describes the application of the dual-channel encrypted embodiment to the "restore 2" process described in relation to Figures 9A to 9H. The wallet and the card perform steps S00', S00, and S02 (Figs. 9A, 9B). At step S101 (Fig. 9C), the wallet prompts the user to provide the PIN chosen during the backup. At step S200' (Fig. 9D), the wallet saves the PIN and then prompts the user to bring the card close and hold it to perform the restore (Fig. 9E). When the contactless connection is re-established (Fig. 9F), the wallet and the card perform steps S00 and S02 again. At step S30, the wallet transmits the PIN to the card via the SCPA and SCPB channels. At step S31, the card decrypts the PIN. At an S320 stage, the card verifies the PIN code by comparing it to the one present in its non-volatile memory.If the comparison is successful, the card transmits the MS seed to the wallet at step S400 via the SCPA and SCPB channels ([Fig. 9G]). At step S410, the wallet decrypts the seed and stores it in its non-volatile memory at step S420. The wallet and card then cooperate for the optional step S50, which verifies the seed. Once this verification is complete, the wallet informs the user that the recovery phrase has been restored ([Fig. 9H]).

[0123] Figure 13 describes the application of the encrypted dual-channel mode to the "restoration 3" process described in relation to Figures 10A to 10H. The process is initiated by steps S00, S01, S02, and S10a (Figs. 10A, 10B). At step S10d (Fig. 10C), the wallet receives the serial number and prompts the user to enter their PIN if the serial numbers match. At step S200' (Figs. 10D, 10E), the wallet saves the PIN and prompts the user to bring the card close and hold it. for recovery. Next, the wallet and card execute the SOI and S02 steps again ([Fig. 10F]). At step S30, the wallet transmits the PIN to the card via the SCPA and SCPB channels. The card decrypts it at step S31 and verifies it at step S320. If the comparison is successful, the card transmits the MS seed to the wallet at step S400, via the SCPA and SCPB channels ([Fig. 10G]). The wallet decrypts it at step S410 and stores it at step S420. The wallet and card then cooperate for the optional seed verification step S50, after which the wallet informs the user that the recovery phrase has been restored ([Fig. 10H]).

[0124] Various aspects of the method of the invention have been described above, which can be implemented alone or in combination. The provision of a dual-channel encrypted with two different encryption techniques ensures enhanced security, as the seed and optionally the PIN are protected by a double layer of encryption. The dual channel also reduces the risk of interception or compromise of sensitive data, even if the first channel were to be weakened. The first SCPA channel can be a standard SCP03 channel compatible with a standard JavaCard. This allows the invention to be implemented without developing a specific card, by exploiting a pre-existing channel widely used in industry, with advantages in terms of interoperability, large-scale production, and maintenance thanks to the use of standardized components.Serial number (SN) verification assures the user that the card being used is the intended one and not a counterfeit, strengthening trust and reducing the risk of card substitution. User entry of a PIN adds a layer of enhanced local authentication, making simple card possession insufficient for access. The combination of SN verification and PIN entry provides dual security: card authenticity verification and user identification. This combination, if implemented, makes fraud more complex, as it requires simultaneously bypassing both physical and logical security measures. Transmission of the PIN via dual-channel encryption ensures that the PIN itself is protected by a double layer of encryption during transmission, further minimizing the risk of compromise.It unifies the method of securing sensitive data (seed and PIN), offering consistency in security protection and management. By combining all these features, the invention offers a high level of security and trust, adapting to standardized environments (JavaCard, SCP03) and making fraud or interception very difficult. However, it will be clear to those skilled in the art that each of these aspects can be implemented independently of the others.

[0125] Examples of algorithms implementing previously described steps will now be described, in which the SCPA channel is implemented on the basis A SCP03 GlobalPlatform feature is available on a standard JavaCard, accessed via an API. The calculations for the SCP03 channel, including the generation of IV initialization vectors as specified by GlobalPlatform, are implemented by the operating system vendor. Encryption and decryption of ISO / IEC 7816 APDU commands and responses for the SCP03 channel are also provided by the operating system. Once the cards are received, keys are installed on them for use by the SCP03 channel and the aforementioned APPL applet. This program handles all operations outside the SCP03 channel (storing the PIN code, storing the seed, etc.). The card's static certificate, used for authentication, is also loaded using this applet.

[0126] Thus, [Fig. 14] describes an algorithm for establishing the encrypted SCPA communication channel. [Fig. 15] describes an algorithm for transmitting the card's serial number. [Fig. 16A] and [Fig. 16B] describe an algorithm for establishing the encrypted SCPB communication channel. [Fig. 17] describes an algorithm for registering the PIN code with the card. [Fig. 18] describes an algorithm for saving the seed. [Fig. 19] describes an algorithm for verifying the PIN code with the card. [Fig. 20] describes an algorithm for restoring the seed. Figures 21A and 21B describe an algorithm for verifying the seed.

[0127] Table 1 below describes the different variables, keys and functions used by these algorithms.

[0128] [Tables] Notation Meaning SCPA First encrypted communication channel SCPB Second encrypted communication channel encapsulated within the SCPA channel KSA Static encryption key for the SCPA communication channel, which can be loaded into the wallet and card during personalization, see Figure 1. KSMA Static Message Authentication Code (MAC) key for the SCPA channel ("MAC key"), which can be loaded into the wallet and card during personalization, see Figure 1. KA Encryption key for a session of the SCPA channel KMA MAC key for a session of the SCPA channel SS Shared secret of the SCPB channel KB Encryption key for an SCPB channel session KMB MAC key for an SCPB channel session RDMw or "CH" Random number generated by the wallet, also called "challenge" or "nonce" depending on the context in which it is used RDMc or "CH" Random number generated by the card, also called "challenge" or "nonce". CRYPw Wallet cryptogram CRYPc Card cryptogram (sKw, pKw) Static wallet private and public key pair (sKc, pKc) Static card private and public key pair (sK, pK) Private and public key pair generated by a certificate authority and used to sign and verify static certificates PIN Personal identification code entered by the user SN Card serial number MS Cryptographic seed value held by HW M Square brackets mean that the value “x” is encrypted with the SCPA channel's KA session encryption key <x>In the figures, the left and right angle brackets indicate that the value "x" is encrypted with the SCPB channel's session encryption key KB. These angle brackets are only visible in the figures and are replaced by the angle brackets "<" and ">" in this text. IVA: Initialization vector for encryption and decryption of the SCPA channel, shared by the card and the wallet. IVB: Initialization vector for encryption and decryption of the SCPB channel, transmitted to the card by the wallet. GENIVA: Algorithm for generating the IVA vector, executed by both the wallet and the card to obtain the same IVA vector. When establishing a secure SCPA session, a Sequence Counter is negotiated. The reader and the card share the same set of derived session keys. From this counter, they each apply a cryptographic function (i.e., CMAC). ) to obtain an identical and synchronized IV vector for encryption and authentication. len(x) Length of the data "x" in number of bytes CAPDU ISO / IEC 7816 APDU command including the fields CLA, INS, PI, P2, LC, DATA RAPDU ISO / IEC 7816 APDU response including the fields DATA, SW MACGEN Function to generate a message authentication code (MAC) using block ciphers. A MAC code verifies that the data has not been modified (integrity) and that it comes from an authenticated source (authenticity). MACA MAC code calculated on the entire CAPDU command or RAPDU response in the SCPA channel ENC(key, IV, message) Symmetric encryption function. Encrypts a message based on a symmetric key ("key") and an IV initialization vector. DEC(key, IV, message) Symmetric decryption function.Decrypts a message based on a symmetric key ("key") and an initialization vector. IV KDF Key Derivation Function ("Key Derivation Function") allows the generation of a session key from a shared secret (SS) for SCPA and SCPB. KEX For "Key Exchange": secret sharing or key exchange function. Allows obtaining a shared secret (SS) between two parties, from public / private key pairs, which can be used as the session key for the SCPB channel. SIGN Signature and verification function, for example ECDSA-SIGN N-SECP256K1 or ECDSA-SIGN (Elliptic Curve Digital Signature Algorithm) based on the SECP256K1 curve. VERIF Signature and verification function, for example ECDSA-VERIF RIF-SECP256K1 based on the SECP256K1 curve. Cw(role-w, pKw, SIGN(role-w, pK w)sK) Static certificate of the portfolio. The certificate may optionally contain role data "role-w" assigned to the portfolio.It contains at least the static public key pKw of the wallet and a signature of the public key (and the "role-w" data if provided). (e) generated with the certificate authority's private key sK and using the SIGN function. (1) Cc(role-c, pKc, SIGN(role-c, pKc)sk) (1) Static card certificate according to a first implementation. The certificate may optionally contain role data "role-c" assigned to the card. It contains at least the card's static public key pKc and a signature of the public key (and the "role-c" data if provided) generated with the certificate authority's private key sK and using the SIGN function. (2) Cc(role-c, SN, pKc, SIGN(role-c, SN, pKc)sK) (2) Static card certificate according to a second implementation. The certificate contains, in addition to the aforementioned data, the card's serial number SN. The signature included in the certificate is in this case calculated from the role, the serial number SN and the public key of the card.GEN(skE, pKE) Algorithm for generating a pair of ephemeral private and public keys, for example, an elliptic curve key generation algorithm as defined by standards such as those in the SEC1 document ("Standards for Efficient Cryptography") or NIST specifications. (sKEw, pKEw) Ephemeral private and public key pair of the wallet, generated by the wallet for establishing the SCPB channel each time this channel is established. (sKEc, pKEc) Ephemeral private and public key pair of the card, generated by the card for establishing the SCPB channel each time this channel is established. CEw = (role-w, pKEw, SIGN(role-w, pKEw)sKw) Ephemeral certificate of the wallet. The certificate may optionally contain the role-w data. It contains at least the ephemeral public key pKEw of the wallet and the signature of its public key (and of the "role-w" data if provided) generated with its static private key sKw and by means of the SIGN function.CEc = (role-c, pK Ec, SIGN(role-c, p KEc)sKc) Ephemeral certificate of the card. The certificate may optionally contain the role-c data. It contains at least the ephemeral public key pKEc of the card and the signature of its public key (and of the "role-c" data if provided) generated with its static private key sKc and using the SIGN function.

[0129] The following tables describe examples of functions or algorithms that can be used by each SCPA channel, SCPB or at different stages of the process.

[0130] SCPA channel, table 2: ENC / DEC MACGEN KDF AES128-ENC AES128-DEC type CBC (1) CMAC-AES (2) CMAC-AES

[0131] Certificate verification and SS secret generation, Table 3: Hash SIGN VERIF KEX KDF SHA256 ECDSA-SIGN-S ECP256K1 (3) ECDSA-VERIF- SECP256K1 (3) ECDH-SECP256 Kl (4) (provides the shared secret SS) SHA256 (used to derive a key from the shared secret SS)

[0132] SCPB channel, for the transport of the PIN code and the MS seed, table 4: ENC DEC MACGEN Hash AES128-ENC type CB C AES128-DEC type CBC HMAC-SHA256 SHA256 Remarks :

[0133] (1) The AES128-ENC or -DEC function is based on the AES algorithm (“Advanced Encryption Standard”) with a 128-bit key, preferably in CBC mode (“Advanced Encryption Standard - Cipher Block Chaining”). “CBC” is a mode of operation used with AES to enhance security. It works by dividing the data into fixed-size blocks (e.g., 128 bits) and encrypting each block. Each block is chained with the previous block. The first data block is combined with the initialization vector IV using an XOR operation before being encrypted. Each subsequent block is combined with the previous encrypted block using the XOR function before being encrypted.

[0134] (2) The CMAC-AES (“Cipher-based Message Authentication Code using AES uses the AES algorithm to produce encrypted intermediate blocks. The data to be authenticated is divided into fixed-size blocks (for example, 128 bits). Each block is combined with the previous one using an XOR operation before being encrypted with AES. The final block undergoes special processing to prevent specific attacks. The last block produced is the MAC code, a short and unique value.

[0135] (3) The ECDSA-SIGN-SECP256K1 algorithm (“Elliptic Curve Digital Signature”) The algorithm generates a digital signature (r, s) from a private key and the hash of a message, using the secp256kl elliptic curve. It guarantees the authenticity and integrity of the message through a secure random number. ECDSA-VERIF-SECP256K1 is a verification algorithm that uses a public key, a message hash, and a signature (r, s) to verify that the signature was created with the corresponding private key. This verification relies on calculations specific to the secp256kl elliptic curve and ensures the validity of the signed message.

[0136] (4) ECDH (Elliptic Curve Diffie-Hellman) on the SECP256K1 curve, to generate the SS secret. General principles of algorithms:

[0137] The HW wallet and the CD card first establish a first encrypted SCPA communication channel. The first SCPA channel, based on the static keys KSA, KSMA and their derivatives KA, KMA, enables the encryption and protection of the exchanged APDU units. The APDU headers (CLA, INS, PI, P2, LC, LE) remain in plaintext, but the DATA field is encrypted and a MAC code ensures integrity.

[0138] Inside the SCPA channel, a second encrypted communication channel, SCPB, is created and encapsulated within the first. This channel is based on a shared secret, SS, which generates the session key KB for encrypting sensitive PIN and MS data, and the key KMB for generating MAC addresses from this data. Thus, the PIN or MS seed is first protected by the SCPB channel (KB encryption and MAC address with KMB), and then the already encrypted result is protected a second time by the SCPA channel (encryption with the key KA and MAC address with the key KMA) before being inserted into the APDU. Random data such as RDMw (hardware wallet nonce), RDMc (card nonce), and certificates enable mutual authentication. Prefixes in the data (e.g.,0000000000000000000000600004001) are specific standardized data strings (context format) used to obtain identical and consistent session keys on the side of the two mutually authenticating entities.

[0139] Establishment of the first encrypted SCPA communication channel, [Fig. 14]:

[0140] Step A01:

[0141] HW HW:

[0142] Generates RDMw

[0143] The wallet generates a random RDMw (nonce) number. This number will serve as a challenge for the card, in order to establish mutual authentication.

[0144] Step A03:

[0145] HW CD:

[0146] INITIALIZE UPDATE: RDMw

[0147] The wallet sends the CAPDU "INITIALIZE UPDATE" command to the card, containing the RDMw nonce. This is sent in clear text in the DATA field of the APDU command.

[0148] Step A05:

[0149] CD CD:

[0150] Generates RDMc

[0151] The map generates the RDMc nonce.

[0152] Step A07:

[0153] CD CD:

[0154] DATA = 00000000000000000000000600004001 II RDMw II RDMc

[0155] KMA = MACGEN(KSMA, DATA)

[0156] The hexadecimal sequence 00000000000000000000000600004001 is known to the card and the wallet and allows it to calculate the MAC KMA key of the SCPA channel.

[0157] Step A09:

[0158] CD CD:

[0159] DATA = 0000000000000000000000000004001 II RDMw II RDMc

[0160] CRYPc = MACGEN(KMA, DATA)

[0161] The hexadecimal sequence 0000000000000000000000000004001 is known to the card and the wallet. It allows the card to calculate its cryptogram with the KMA key.

[0162] Garlic Step:

[0163] HW «— CD:

[0164] RDMc, CRYPc

[0165] The card sends RDMc and CRYPc back to the wallet via a RAPDU response. The wallet receives the card challenge and the cryptogram used to verify the card's authenticity. The data is still in plaintext at this stage.

[0166] Step A13:

[0167] HW HW:

[0168] DATA = 00000000000000000000000600004001 II RDMw II RDMc

[0169] KMA = MACGEN (KSM A, DATA)

[0170] The hexadecimal sequence 00000000000000000000000100004001 is known to the card and the wallet and allows the wallet to calculate the KMA key.

[0171] Step A15:

[0172] HW HW:

[0173] DATA = 00000000000000000000000000004001 II RDMw II RDMc

[0174] MACGEN(KMA, DATA) = CRYPc

[0175] The wallet verifies the received cryptogram, CRYPC, by recalculating it and comparing it to the received cryptogram. If they are identical, the card is authenticated by the wallet.

[0176] Step A17:

[0177] HW HW:

[0178] DATA = 00000000000000000000000100004001 II RDMw II RDMc

[0179] CRYPw = MACGEN(KMA, DATA)

[0180] The wallet then calculates its own cryptogram CRYPw with the hexadecimal sequence 00000000000000000000000100004001 concatenated with RDMw and RDMc.

[0181] Step A19:

[0182] HW CD:

[0183] EXTERNAL AUTHENTICATE: CRYPw

[0184] The wallet sends the card the CAPDU command "EXTERNAL AUTHENTICATE" containing its cryptogram CRYPw.

[0185] Step A21:

[0186] CD CD:

[0187] DATA = 00000000000000000000000100004001 II RDMw II RDMc

[0188] MACGEN(KMA, DATA) = CRYPw

[0189] The card recalculates the CRYPw cryptogram and compares it to the one received. If they are identical, the wallet is authenticated.

[0190] Step A23:

[0191] CD CD:

[0192] DATA = 00000000000000000000000400004001 II RDMw II RDMc

[0193] KA = MACGEN(KSA, DATA)

[0194] The card then calculates the KA key using the MACGEN function and generates the KA session key, which will be used to encrypt and decrypt messages on the SCPA channel. From now on, the KA and KMA keys are defined on the card side.

[0195] Step A25:

[0196] HW «— CD:

[0197] SUCCESS

[0198] The card sends the response "SUCCESS" REPORT.

[0199] Step A27:

[0200] HW HW:

[0201] DATA = 00000000000000000000000400004001 II RDMw II RDMc

[0202] KA = MACGEN(KSA, DATA)

[0203] The wallet also calculates the KA key, using the same formula. Now, the wallet and the card share the KA and KMA keys of the SCPA channel.

[0204] Step A29:

[0205] HW HW:

[0206] GENIVA -> IVA

[0207] The portfolio generates the IVA initialization vector.

[0208] Step A31:

[0209] CD CD:

[0210] GENIVA -> IVA

[0211] The card generates the IVA initialization vector

[0212] In the preceding, the static keys KSA and KSMA are used to derive the session keys KA and KMA. Once the channel is established, the APDU's DATA fields are encrypted with the KA key and protected by a MAC address generated with the KMA key. The CAPDU headers (CLA, INS, PI, P2) remain in plaintext, but the DATA field remains confidential and intact. After step A27, the wallet and the card share the KA and KMA keys: the APDU data (the DATA field) can be encrypted with the KA key and protected by a MAC address generated with the KMA key.

[0213] Transmission of the card serial number, [Fig. 15]:

[0214] Step B00:

[0215] HW CD:

[0216] GET DATA: MAC A

[0217] The wallet sends a CAPDU "GET DATA" command to the card, where the DATA field (if not null) is encrypted using the key KA and accompanied by a MACA code generated with the key KMA. In practice, the DATA field may contain a "TAG" type data that indicates the type of data contained in the DATA field.

[0218] Step B02:

[0219] CD CD:

[0220] MACA = MACGEN(KMA, CAPDU)

[0221] The card recalculates the MACA code of the CAPDU command to verify that the received MACA code is correct.

[0222] Step B04:

[0223] CD CD:

[0224] [SN] = ENC(KA, IVA, SN)

[0225] The card encrypts its serial number SN with the key KA and the initialization vector IVA.

[0226] Step B06:

[0227] CD CD:

[0228] MACA = MACGEN(KMA, RAPDU)

[0229] The card calculates the MACA code of the RAPDU response that it will send to the wallet in the next step.

[0230] Step B08:

[0231] HW «—CD:

[0232] [SN] MACA

[0233] The card sends back to the wallet a response including its serial number in encrypted form [SN] accompanied by the MACA code of the RAPDU response.

[0234] Step B10:

[0235] HW HW:

[0236] MACGEN(KMA, CAPDU) = MACA

[0237] The wallet verifies the MACA code of the received response by recalculating it.

[0238] Step B12:

[0239] HW HW:

[0240] SN = DEC(KA, IVA, [SN])

[0241] The wallet decrypts the serial number SN with the key KA and the initialization vector IVA, stores it in its memory. It will then display it to the user as seen previously.

[0242] Once the SCPA channel is established, the steps above establish the second encrypted communication channel, SCPB. The two devices exchange certificates and generate the shared secret SS using the KEX function. They then derive the KB and KMB keys from the SS secret to create a second layer of encryption and MAC code for sensitive data such as the PIN or MS seed. This data is first encrypted in the SCPB channel (KB key) and accompanied by a MACpin or MACms code generated with the KMB key. The result of this encryption and the accompanying MACpin or MACms code are then encapsulated (over-encrypted) in the SCPA channel managed by the KA and KMA keys. The DATA or "payload" carried by the APDU commands and responses is doubly protected. Within the payload, this data is indeed protected by encryption and MAC code based on the KB and KMB keys of the SCPB channel.The encrypted payload is then itself further encrypted and protected by a MAC code from the KA and KMA keys of the SCPA channel, before being inserted into the APDUs.

[0243] Establishment of the second SCPB channel in the SCPA channel, figures 16A and 16B:

[0244] Step C01:

[0245] HW HW:

[0246] Generate RDMw

[0247] The wallet generates the nonce RDMw.

[0248] Step C03:

[0249] HW HW:

[0250] [RDMw] = ENC(KA, IVA, RDMw)

[0251] The wallet, the cipher, the nonce with the key KA and the initialization vector IVA.

[0252] Step C05:

[0253] HW HW:

[0254] MACA = MACGEN(KMA, CAPDU)

[0255] The wallet calculates the MACA code of the CAPDU command which will be sent to the next step.

[0256] Step C07:

[0257] HW CD:

[0258] GET CERTIFICATE: [RDMw], MACA

[0259] The wallet sends the CAPDU "GET CERTIFICATE" command to the card, including the encrypted nonce [RDMw] and the MACA code of the command. The CLA, INS, etc. fields of the command are in plaintext, but the DATA field = [RDMw] is encrypted with the key KA and protected by the MACA code.

[0260] Step C09:

[0261] CD CD:

[0262] MACGEN(KMA, CAPDU) = MACA

[0263] The card verifies the received MACA code.

[0264] Eyelash Stage:

[0265] CD CD:

[0266] RDMw = DEC(KA, IVA, [RDMw])

[0267] The card decrypts the nonce [RDMw] with the key KA and the initialization vector IVA.

[0268] Step C13:

[0269] CD CD:

[0270] [Ce] = ENC(KA, IVA, Ce)

[0271] The card encrypts its static certificate Ce.

[0272] Step C15:

[0273] CD CD:

[0274] MACA = MACGEN(KMA, RAPDU)

[0275] The card calculates the MACA code of a RAPDU response that it will send to the next step.

[0276] Step C17:

[0277] HW «— CD:

[0278] [This], MACA

[0279] The wallet receives the response containing the encrypted static certificate [Ce] of the card and the MACA code of the RAPDU response.

[0280] Step C19:

[0281] HW^HW:

[0282] MACGEN(KMA, RAPDU) = MACA

[0283] The wallet verifies the received MACA code with the RAPDU response.

[0284] Step C21:

[0285] HW HW:

[0286] Ce = DEC(KA, IVA, [Ce])

[0287] The wallet decrypts the card's static Ce certificate.

[0288] Step C23:

[0289] HW HW:

[0290] VERIF(pK, Ce)

[0291] The wallet verifies the validity of the Ce certificate using the VERIF(pK, Ce) function, from the public key pK of the certification authority.

[0292] Step C25:

[0293] HW HW:

[0294] MACA = MACGEN(KMA, CAPDU)

[0295] The wallet calculates the MACA code and the CAPDU command that it will send to the card in the next step.

[0296] Step C27:

[0297] HW CD:

[0298] GET CERTIFICATES: MACA

[0299] The wallet sends the "GET CERTIFICATE" command along with the MACA code.

[0300] Step C29:

[0301] CD CD:

[0302] MACGEN(KMA, CAPDU) = MACA

[0303] The card verifies the MACA code received with the order.

[0304] Step C31:

[0305] CD CD:

[0306] GEN(sKEc, pKEc)

[0307] CEc = (role-c, pKEc, SIGN (role-c, pKEc)sKc)

[0308] The card generates a pair of ephemeral private and public keys sKEc, pKEc using the GEN algorithm. The card then generates an ephemeral CEc certificate as described above, signed with its static private key sKc.

[0309] Step C33:

[0310] CD —> CD:

[0311] [CEc] = ENC(KA, IVA, CEc)

[0312] The card encrypts its ephemeral CEc certificate with the key KA.

[0313] Step C35:

[0314] CD —> CD:

[0315] MACA = MACGEN(KMA, RAPDU)

[0316] The card calculates the MACA code of the RAPDU response that it will send to the next step.

[0317] Step C37:

[0318] HW «—CD:

[0319] [CEc], MACA

[0320] The card sends the RAPDU response to the wallet, including its encrypted certificate [CEc] and the MACA code.

[0321] Step C39:

[0322] HW HW:

[0323] MACGEN(KMA, RAPDU) = MACA

[0324] The wallet checks the MACA code of the RAPDU response.

[0325] Step C41:

[0326] HW HW:

[0327] CEc = DEC(KA, IVA, [CEc])

[0328] The wallet decrypts the ephemeral certificate CEc = DEC(KA, IVA, [CEc]).

[0329] Step C43:

[0330] HW HW:

[0331] VERIF(pKc, CEc)

[0332] The wallet verifies the ephemeral CEc certificate with the VERIF function using the static public key pKc of the static card (contained in the previously verified static Ce certificate).

[0333] Step C45:

[0334] HW HW:

[0335] [Cw] = ENC(KA, IVA, Cw)

[0336] The wallet encrypts its static certificate Cw.

[0337] Step C47:

[0338] HW HW:

[0339] MACA = MACGEN(KMA, CAPDU)

[0340] The wallet calculates the MACA code of the CAPDU command which it will send to the card in the next step.

[0341] Step C49:

[0342] HW CD:

[0343] VALIDATE CERTIFICATES: [Cw], MACA

[0344] The wallet sends the "VALIDATE CERTIFICATE" command containing its encrypted static certificate.

[0345] Step C51:

[0346] CD CD:

[0347] MACGEN(KMA, CAPDU) = MACA

[0348] The card checks the CAPDU MAC code.

[0349] Step C53:

[0350] CD CD:

[0351] Cw = DEC(KA, IVA, [Cw])

[0352] The card decrypts the static Cw certificate.

[0353] Step C55:

[0354] CD CD:

[0355] VERIF(pK, Cw)

[0356] The card verifies the Cw certificate with the VERIF(pK, Cw) function using the public key of the certification authority.

[0357] Step C57:

[0358] CD CD:

[0359] MACA = MACGEN(KMA, RAPDU)

[0360] The card calculates the MACA code of the RAPDU response that it will send to the next step.

[0361] Step C59:

[0362] HW «— CD:

[0363] MACA

[0364] The card sends a response to the wallet without an error code.

[0365] Step C61:

[0366] HW HW:

[0367] MACGEN(KMA, RAPDU) = MACA

[0368] The wallet checks the MAC code of the response received from the card.

[0369] Step C63:

[0370] HW HW:

[0371] GEN(sKEw, pKEw)

[0372] CEw = (role-w, pKEw, SIGN(role-w, pKEw)sKw)

[0373] The wallet generates an ephemeral private and public key pair sKEw, pKEw using the GEN algorithm. The wallet then generates an ephemeral CEw certificate as described above, signed with its static private key sKw.

[0374] Step C65:

[0375] HW HW:

[0376] [CEw] = ENC(KA, IVA, CEw)

[0377] The wallet encrypts its ephemeral CEw certificate with the KA key.

[0378] Step C67:

[0379] HW HW:

[0380] MACA = MACGEN(KMA, RAPDU)

[0381] The wallet calculates the MACA code of the RAPDU command which it will send to the card in the next step.

[0382] Step C69:

[0383] HW CD:

[0384] VALIDATE CERTIFICATE: [CEw], MACA]

[0385] The wallet sends the card the "VALIDATE CERTIFICATE" command containing its encrypted ephemeral certificate. After these exchanges of static and ephemeral certificates and their verifications, both parties possess each other's ephemeral public keys.

[0386] Step C71:

[0387] CD CD:

[0388] MACGEN(KMA, CAPDU) = MACA

[0389] The card recalculates the MACA code of the received CAPDU command to verify that it is valid.

[0390] Step C73:

[0391] CD CD:

[0392] CEw = DEC(KA, IVA, [CEw])

[0393] The card decrypts the ephemeral CEw certificate.

[0394] Step C75:

[0395] CD CD:

[0396] VERIF(pKw, CEw)

[0397] The card verifies the CEw certificate with the VERIF(pKw, CEw) function using the wallet's static public key pKw.

[0398] Step C77:

[0399] CD CD:

[0400] SS = KEX(sKEc, pKEw)

[0401] KB = KDF(SS)

[0402] KMB = KDF(SS)

[0403] The card calculates the shared secret SS from its ephemeral private key sKEc and the The wallet's ephemeral public key, pKEw, is used. From SS, the card derives the KB and KMB keys of the second encryption channel, SCPB.

[0404] Step C79:

[0405] CD CD:

[0406] MACA = MACGEN(KMA, RAPDU)

[0407] The card calculates the MACA code of the RAPDU response that it will send to the wallet in the next step.

[0408] Step C81:

[0409] HW «— CD:

[0410] MACA

[0411] The card sends its RAPDU response to the wallet.

[0412] Step C83:

[0413] HW HW:

[0414] MACGEN(KMA, RAPDU) = MACA

[0415] The wallet checks the MAC code of the response.

[0416] Step C85:

[0417] HW HW:

[0418] SS = KEX(sKEw, pKEc)

[0419] KB = KDF(SS)

[0420] KMB = KDF(SS)

[0421] The wallet calculates the shared secret SS using its private key and the card's public key. From this, it derives the KB and KMB keys. At this stage, the wallet and the card share the KA and KMA keys of the SCPA channel and the KB and KMB keys of the SCPB channel, which can enable the implementation of a second layer of encryption within the SCPA channel.

[0422] Once the secure SCPA (KA, KMA) and SCPB (KB, KMB) channels are established, the PIN and MS seed can be sent to the card with double cryptographic encapsulation. The PIN and MS seed are first encrypted in the SCPB channel, and then the result is re-encrypted in the SCPA channel before being sent to the card. The steps described below enable the PIN provided by the user to be stored on the card.

[0423] PIN code registration by the card, [Fig. 17]:

[0424] Step D00:

[0425] HW HW:

[0426] Generates IVB

[0427] The portfolio generates a new IVB initialization vector.

[0428] Step D02:

[0429] HW HW:

[0430] <pin>= ENC(KB, IVB, PIN)

[0431] The wallet encrypts the user-supplied PIN code with the KB key.

[0432] Step D04:

[0433] HW HW:

[0434] MACpin = MACGEN(KMB, <pin>)

[0435] The wallet calculates a MACpin code from the encrypted PIN code.

[0436] Step D06:

[0437] HW HW:

[0438] PINdata = len(IVB) II IVB II len( <pin> ) Il <pin>He len(MACpin) He MACpin

[0439] The wallet assembles a PINdata by concatenating the data and the lengths of the IVB data, <pin>and MACpin in order to transmit the encrypted data <pin>à la carte.

[0440] Step D08:

[0441] HW HW:

[0442] [PINdata] = ENC(KA, IVA, PINdata)

[0443] The wallet encrypts PINdata with KA, IVA as encryption in the SCPA channel.

[0444] Step D10:

[0445] HW HW:

[0446] MACA = MACGEN(KMA, CAPDU)

[0447] The wallet calculates the MACA code of the CAPDU command which it will send to the card in the next step.

[0448] Step D12:

[0449] HW CD:

[0450] SET PIN: [PINdata], MACA

[0451] The wallet sends the SET PIN command to the card, along with the heavily encrypted data [PINdata] and the MACA code. The APDU has its headers in plain text, but the DATA field contains the [PINdata] data encrypted in the SCPA channel, which itself contains the PIN code encrypted in the SCPB channel.

[0452] Step D14:

[0453] CD CD:

[0454] MACGEN(KMA, CAPDU) = MACA

[0455] The card recalculates the MACA code of the received CAPDU command to verify that it is valid.

[0456] Step D16:

[0457] CD CD:

[0458] PINdata = DEC(KA, IVA, [PINdata])

[0459] The card decrypts PINdata in the SCPA channel to extract IVB, <pin>, et MACpin .

[0460] Etape D18:

[0461] CD CD :

[0462] MACGEN(KMB, <pin>) = MACpin

[0463] The MACGEN(KMB, <pin>) and compares it to the MACpin code present in PINdata. If the two codes are identical, the PIN code has not been altered.

[0464] Step D20:

[0465] CD CD:

[0466] PIN = DEC(KB, IVB, <pin>)

[0467] The card decrypts the PIN code in the SCPB channel.

[0468] Step D22:

[0469] CD CD:

[0470] STORE PIN

[0471] The card stores the PIN code in its memory.

[0472] Step D24:

[0473] CD CD:

[0474] MACA = MACGEN(KMA, RAPDU)

[0475] The card calculates the MACA code of the RAPDU response that it will send to the wallet in the next step.

[0476] Step D26:

[0477] HW «— CD:

[0478] MACA

[0479] The card sends a success or failure response to the wallet along with the MACA code.

[0480] Step D28:

[0481] HW^HW:

[0482] MACGEN(KMA, RAPDU) = MACA

[0483] The wallet checks the MAC address of the response. If the address is correct, the response is valid. If the response contains an error code, the wallet knows that the PIN has not been saved by the card. If the response does not contain an error code, the wallet knows that the PIN has been successfully saved by the card.

[0484] The steps described below allow the seed held by the wallet to be recorded in the card. These steps reproduce the same process as for the PIN code, but applied to the seed with a new IVB initialization vector.

[0485] Saving the seed, [Fig. 18]:

[0486] Step E00:

[0487] HW HW:

[0488] Generates IVB

[0489] The portfolio generates a new IVB initialization vector.

[0490] Step E02:

[0491] HW HW:

[0492] = ENC(KB, IVB, MS)

[0493] The wallet reads the value of the MS seed into its memory and encrypts it in the SCPB channel.

[0494] Step E04:

[0495] HW HW:

[0496] MACms = MACGEN(KMB, )

[0497] The wallet calculates the MAC code of the encrypted seed .

[0498] Etape E06:

[0499] HW HW:

[0500] MSdata = len(IVB) Il IVB II len( ) Il It's len(MACms) It's MACms

[0501] The wallet assembles MSdata by concatenating data and IVB data lengths, and MACms in order to transmit the encrypted data à la carte.

[0502] Step E08:

[0503] HW HW:

[0504] [MSdata] = ENC(KA, IVA, MSdata)

[0505] The MSdata encrypted wallet in the SCPA channel.

[0506] Step E10:

[0507] HW HW:

[0508] MACA = MACGEN(KMA, CAPDU)

[0509] The wallet calculates the MACA code of the CAPDU command which it will send to the card in the next step.

[0510] Step E12:

[0511] HW^CD:

[0512] SET MS: [MSdata], MACA

[0513] The wallet sends the "SET MS" command to the card.

[0514] Step E14:

[0515] CD —> CD:

[0516] MACGEN(KMA, CAPDU) = MACA

[0517] The card checks the MACA code of the order.

[0518] Step El8:

[0519] CD —> CD:

[0520] MSdata = DEC(KA, IVA, [MSdata])

[0521] The card decrypts the MSdata in the SCPA channel to extract IVB, and MACms.

[0522] Step E20:

[0523] CD CD:

[0524] MACGEN(KMB, ) = MACms

[0525] The card recalculates the MACms code and checks the MACms code present in the MSdata.

[0526] Step E22:

[0527] CD CD:

[0528] MS = DEC(KB, IVB, )

[0529] The card deciphers the seed in the SCPB channel.

[0530] Step E24:

[0531] CD —> CD:

[0532] STORE MS

[0533] The card stores the seed in its memory.

[0534] Step E26:

[0535] CD CD:

[0536] MACA = MACGEN(KMA, RAPDU)

[0537] The card calculates the MACA code of the RAPDU response that it will send to the wallet in the next step.

[0538] Step E28:

[0539] HW «— CD:

[0540] MACA

[0541] The card sends a success or failure response to the wallet.

[0542] Step E30:

[0543] HW HW:

[0544] MACGEN(KMA, RAPDU) = MACA

[0545] The wallet checks the MAC address of the response. If the address is correct, the response is valid. If the response contains an error code, the wallet knows that the seed was not saved by the card. If the response does not contain an error code, the wallet knows that the seed was successfully saved by the card.

[0546] PIN code verification by card, [Fig. 19]:

[0547] The PIN verification algorithm below comprises various steps identical to those of the PIN backup algorithm previously described, and designated by the same references.

[0548] Step D00:

[0549] HW HW:

[0550] Generates IVB

[0551] The portfolio generates a new IVB initialization vector.

[0552] Step D02:

[0553] HW HW:

[0554] <pin>= ENC(KB, IVB, PIN)

[0555] The wallet encrypts the user-supplied PIN code with the KB key.

[0556] Step D04:

[0557] HW HW:

[0558] MACpin = MACGEN(KMB, <pin>)

[0559] The wallet calculates a MACpin code from the encrypted PIN code.

[0560] Step D06:

[0561] HW HW:

[0562] PINdata = len(IVB) II IVB II len( <pin> ) Il <pin>He len(MACpin) He MACpin

[0563] The wallet assembles a PINdata by concatenating the data and the lengths of the IVB data, <pin>and MACpin to transmit the data <pin>à la carte.

[0564] Step D08:

[0565] HW HW:

[0566] [PINdata] = ENC(KA, IVA, PINdata)

[0567] The wallet encrypts PINdata with KA, IVA as encryption in the channel SCPA.

[0568] Step D10:

[0569] HW HW:

[0570] MACA = MACGEN(KMA, CAPDU)

[0571] The wallet calculates the MACA code of the CAPDU command which it will send to the card in the next step.

[0572] Step D120:

[0573] HW CD:

[0574] VERIFY PIN: [PINdata], MACA

[0575] The wallet sends the VERIFY PIN command to the card, along with the encrypted data [PINdata] and the MACA code.

[0576] Step D14:

[0577] CD CD:

[0578] MACGEN(KMA, CAPDU) = MACA

[0579] The card recalculates the MACA code of the received command to verify that it is valid.

[0580] Step D16:

[0581] CD —> CD:

[0582] PINdata = DEC(KA, IVA, [PINdata])

[0583] The card decrypts PINdata in the SCPA channel.

[0584] Step D18:

[0585] CD CD:

[0586] MACGEN(KMB, <pin>) = MACpin

[0587] The card calculates the MACGEN(KMB, <pin>) and compares it to the MACpin code present in PINdata. If the two codes are identical, the PIN code has not been altered.

[0588] Step D20:

[0589] CD CD:

[0590] PIN = DEC(KB, IVB, <pin>)

[0591] The card decrypts the PIN code in the SCPB channel.

[0592] Step D220:

[0593] CD CD:

[0594] VERIFY PIN

[0595] The card compares the decrypted PIN code to the one it has in memory.

[0596] Step D24:

[0597]

[0598]

[0599] CD CD: MACA = MACGEN(KMA, RAPDU) The card calculates the MACA code for the RAPDU response it will send to the wallet in the next step.

[0600]

[0601]

[0602]

[0603] Step D260: HW "— CD: MACA The card sends its RAPDU response along with the MACA code to the wallet. If the received PIN is incorrect, the RAPDU response data field contains an error code.

[0604]

[0605]

[0606]

[0607] Step D280: HW HW: MACGEN(KMA, RAPDU) = MACA The wallet checks the MACA code by recalculating it. If the MACA code is valid, the received RAPDU response is valid. If the response contains an error code, the wallet knows that the PIN entered by the user does not match the one on the card. If the response does not contain an error code, the wallet knows that the PIN has been validly identified by the card

[0608]

[0609]

[0610]

[0611]

[0612] Seed restoration, [Fig.20] : F00: HW HW : MACA = MACGEN(KMA, CAPDU) The wallet calculates the MACA code of the CAPDU command that it will send to the card in the next step.

[0613]

[0614]

[0615]

[0616]

[0617]

[0618]

[0619]

[0620]

[0621]

[0622]

[0623]

[0624]

[0625]

[0626] Step F02 : HW CD : RESTORE MS : MACA The wallet sends the restore command to the card. Step F04 : CD CD : MACGEN(KMA, CAPDU) = MACA The card checks the MAC code of the received restore command. Step F06 : CD CD : Generates IVB The card generates a new initialization vector. Step F08 : CD CD : .

[0627] = ENC(KB, IVB, MS)

[0628] The card reads the seed from its memory and encrypts it with the key KB.

[0629] Step F10:

[0630] CD CD:

[0631] MACms = MACGEN(KMB, )

[0632] The card calculates the MAC code of the encrypted seed.

[0633] Step F12:

[0634] CD CD:

[0635] MSdata = len(IVB) II IVB II len( ) Il It's len(MACms) It's MACms

[0636] The card generates the MSdata by concatenating the data and the lengths of the IVB data, and MACms in order to transmit the encrypted data to the wallet.

[0637] Step F14:

[0638] CD CD:

[0639] [MSdata] = ENC(KA, IVA, MSdata)

[0640] The card encrypts the MSdata in the SCPA channel.

[0641] Step F16:

[0642] CD CD:

[0643] MACA = MACGEN(KMA, RAPDU)

[0644] The card prepares the MACA code of the RAPDU response which it will send to the wallet in the next step.

[0645] Step Fl8:

[0646] HW «— CD:

[0647] [MSdata], MACA

[0648] The card sends to the wallet the RAPDU response containing the MSdata encrypted in the SCPA channel and accompanied by the MACA code.

[0649] Step F20:

[0650] HW HW:

[0651] MACGEN(KMA, RAPDU) = MACA

[0652] The wallet checks the MACA code of the response.

[0653] Step F22:

[0654] HW HW:

[0655] MSdata = DEC(KA, IVA, [MSdata])

[0656] The wallet decrypts the MSdata in the SCPA channel.

[0657] Step F24:

[0658] HW HW:

[0659] MACGEN(KMB, ) = MACms

[0660] The wallet verifies that the MACms code present in the MSdata is correct.

[0661] Step F26:

[0662] HW HW:

[0663] MS = DEC(KB, IVB, )

[0664] The wallet deciphers the MS seed in the SCPB channel.

[0665] Step F28:

[0666] HW HW:

[0667] STORE MS

[0668] The wallet stores the MS seed in its memory.

[0669] Seed verification:

[0670] As mentioned above, the S50 seed verification step by comparison can be scheduled after the seed has been backed up or restored. This step can also be executed at any time at the user's request by enabling this option in the wallet's features menu. Re-executing this step "at any time" at the user's request may be subject to a new verification of the card's serial number and / or the user's PIN.

[0671] According to this disclosure, a highly secure process is planned for carrying out this verification, which does not consist solely of verifying a hash of the seed or a signature thereof, and includes the following steps:

[0672] - the wallet sends a challenge to the card,

[0673] - the card generates a private key by derivation of the cryptographic seed, according to a bypass road,

[0674] - the card performs a cryptographic calculation based on the challenge and the private key derivative, and sends the result of this calculation to the portfolio,

[0675] - the wallet generates the same private key by seed derivation cryptographic, following the same derivation path,

[0676] - the wallet, based on the challenge and the derived private key, verifies the result of the calculation cryptographic value returned by the card. If this result is correct, it means that the seeds held by the wallet and the seed are identical.

[0677] In one embodiment, the card-driven cryptographic computation consists of generating a signature of the challenge using the derived private key. In this case, the hardware wallet can verify the signature using a signature verification function, so that it is not necessary for the hardware wallet to recalculate the signature and compare the obtained signature to the received signature, although this is also possible. In another embodiment, the cryptographic computation may consist of encrypting the The challenge is performed using the derived key. In this case, the hardware wallet recalculates this encryption and compares it to the one received from the card. Various other variations of this cryptographic calculation from the challenge and the derived key can be implemented, allowing the hardware wallet to verify that the card generated the same derived key and therefore holds the same seed, for example, an encryption of a combination of the challenge with other data, etc.

[0678] In one embodiment, the derivation path used by the wallet and the card is hard-coded into their non-volatile memories before they are put into service (personalization phase). In another variant, the derivation path is dynamically generated by the wallet and the card from the challenge sent by the wallet to the card, applying the same derivation path generation rule.

[0679] We will now describe an example of a seed verification algorithm In relation to Figures 21A and 21B, implementing the aforementioned embodiment, the hardware wallet verifies a challenge signature generated by the card. In this algorithm, the challenge, as well as the card-generated signature, is transmitted in a super-encrypted form through the SCPA and SCPB channels.

[0680] Step V01:

[0681] HW —> HW:

[0682] Generates CH

[0683] HW generates a CH challenge.

[0684] Step V03:

[0685] HW HW:

[0686] <ch>= ENC (KB, IVB, CH)

[0687] HW encrypts the CH challenge in the SCPB channel.

[0688] Step V05:

[0689] MACch = MACGEN(KMB, <ch>)

[0690] The wallet calculates a MACch code of the encrypted CH challenge.

[0691] Step V07

[0692] HW HW:

[0693] CHdata = len(IVB) II IVB II len( <ch> ) Il <ch>He len(MACch) He MACch

[0694] The wallet assembles CHdata by concatenating the data and IVB data lengths, <ch>and MACch in order to transmit the encrypted data <ch>à la carte.

[0695] Step V09:

[0696] HW HW:

[0697] [CHdata] = ENC(KA, IVA, CHdata)

[0698] The CHdata encrypted wallet in the SCPA channel.

[0699] Stage VII:

[0700] HW HW:

[0701] MAC A = MACGEN(KMA, C APDU)

[0702] The wallet calculates the MAC A code of the CAPDU command which it will send to the card in the next step.

[0703] Step V13:

[0704] HW CD:

[0705] [CHdata] Il MACA

[0706] The wallet sends a CAPDU command to the card containing the data [CHdata] and accompanied by the MACA code.

[0707] Step V15:

[0708] CD CD:

[0709] MACGEN(KMA, CAPDU) = MACA

[0710] The card recalculates the MACA code of the received command to verify that it is valid.

[0711] Step V17:

[0712] CD —> CD:

[0713] CHdata = DEC(KA, IVA, [CHdata])

[0714] The card decrypts CHdata in the SCPA channel to extract IVB, <ch>, and MACch.

[0715] Step V19:

[0716] CD —> CD :

[0717] MACGEN(KMB, <ch>) = MACch

[0718] The map recalculates MACGEN(KMB, <ch>) and compares it to the MACch code present in CHdata. If the two codes are identical, the CH challenge has not been altered.

[0719] Step V21:

[0720] CD CD:

[0721] CH = DEC(KB, IVB, <ch>)

[0722] The map deciphers the CH challenge in the SCPB channel.

[0723] Step V23:

[0724] CD CD:

[0725] mk II c = HMAC-SHA512(key = “Bitcoin seed”, data = MS)

[0726] H = H1 II Hr = HMAC-SHA512(key = c, data = 0x00 II mk II iO)

[0727] (H1: left part of H, Hr: right part of H)

[0728] skiO = (H1 + mk) mod n, where n is the order of the curve

[0729] ciO = Hr

[0730] H = H1 II Hr = HMAC-SHA512 (key = ciO, data = 0x00 II skiO II il)

[0731] skil = (H1 + skiO) mod n

[0732] cil = Hr

[0733] ​​H = H1 II Hr = HMAC-SHA512 (key = cil, data = skil II i2)

[0734] sKv = (H1 + skil) mod n

[0735] Using the calculations above, the card derives a private key sKv (seed verification private key) from the MS seed. Step V23 (and later step V47) involves calculating successive MAC addresses from the seed using the HMAC-SHA512 algorithm, which requires the use of a key. The initial key cited here as an example is "Bitcoin seed" from the BIP 32 specification, but any other key can be used, for example, "NAME Seed" or "Name" is a name given to the card. The HMAC-SHA512 algorithm allows the calculation of 64-byte MAC addresses, which can be separated into two 32-byte blocks. The second block, denoted "c", is called the "chain code". It is used as the key for calculating the next HMAC-SHA512.The calculation skiO = (H1 + mk) mod n allows us to calculate the first private key of the derivation chain: skiO is the key corresponding to index i0 of the derivation path, skil is the key corresponding to index il, and ski2 is the key corresponding to index i2. We perform a modular addition modulo n here because, for a curve of order n, we generally choose a scalar (here, the private key) lower than that order. If the scalar were greater than the order of the curve, there would be a scalar smaller than "n" that would give the same result, for example, for the calculation skiO * G. Then, we repeat the process with an HMAC-SHA512 calculation and a modular addition to obtain the private key of index il, and so on. If the derivation path consisted of only one index, we could stop at the calculation of skiO = (H1 + mk) mod n. The private signing key would then be skiO.

[0736] Step V25:

[0737] CD CD:

[0738] SIGNVERIF = SIGN(sKv, CH)

[0739] The card signs the CH challenge with the private key sKv to obtain a "SIGNVERIF" signature verifying the seed. The SIGN signature function is, for example, the ECDSA-SIGN function.

[0740] Step V27:

[0741] CD CD:

[0742] MACsignverif = MACGEN(KMB, <signverif>)

[0743] The card calculates the MAC code of the SIGNVERIF signature.

[0744] Step V29:

[0745] CD CD:

[0746] SIGNVERIFdata = len(IVB) Il IVB II len( <signverif> ) Il <signverif>It len(MACsignverif) It MACsignverif

[0747] The card assembles a SIGNVERIFdata by concatenating the data and the lengths of the IVB data, <signverif>and MACsignverif in order to transmit the encrypted data <signverif>to the wallet.

[0748] Step V31:

[0749] CD CD:

[0750] [SIGNVERIFdata] = ENC(KA, IVA, SIGNVERIFdata)

[0751] The card encrypts the SIGNVERIFdata in the SCPA channel.

[0752] Step V33:

[0753] CD CD:

[0754] MACA = MACGEN(KMA, RAPDU)

[0755] The card prepares the MACA code of the RAPDU response which it will send to the wallet in the next step.

[0756] Step V35:

[0757] HW «— CD:

[0758] [SIGNVERIFdata], MACA

[0759] The card sends to the wallet a response containing the SIGNVERIFdata encrypted in the SCPA channel and accompanied by the MACA code.

[0760] Step V37:

[0761] HW HW:

[0762] MACGEN(KMA, RAPDU) = MACA

[0763] The wallet checks the MACA code of the response.

[0764] Step V39:

[0765] HW HW:

[0766] SIGNVERIFdata = DEC(KA, IVA, [SIGNVERIFdata])

[0767] The wallet decrypts the SIGNVERIFdata in the SCPA channel.

[0768] Step V41:

[0769] HW HW:

[0770] MACGEN(KMB, <signverif>) = MACsignverif

[0771] The wallet verifies that the MACsignverif code present in the SIGNVERIFdata is correct.

[0772] Step V43:

[0773] HW HW:

[0774] SIGNVERIF = DEC(KB, IVB, <signverif>)

[0775] The wallet decrypts SIGNVERIF in the SCPB channel.

[0776] Step V45:

[0777] HW -> HW

[0778] mk II c = HMAC-SHA512(key = “Bitcoin seed”, data = MS)

[0779] H = H1 II Hr = HMAC-SHA512(key = c, data = 0x00 II mk II iO)

[0780] (H1: left part of H, Hr: right part of H)

[0781] skiO = (H1 + mk) mod n, where n is the order of the curve,

[0782] ciO = Hr

[0783] H = H1 II Hr = HMAC-SHA512(key = ciO, data = 0x00 II skiO II il)

[0784] skil = (H1 + skiO) mod n

[0785] cil = Hr

[0786] H = H1 II Hr = HMAC-SHA512 (key = cil, data = skil II i2)

[0787] sKv = (H1 + skil) mod n

[0788] pk = sKv * G, where G is the curve generator

[0789] The calculations performed by the portfolio at this stage are explained in step V23 and are the same as those produced by the map.

[0790] Step V47:

[0791] HW HW:

[0792] CHECK(pk, CH, SIGNVERIF)

[0793] The HW wallet here verifies the signature, but does not recalculate it. The verification algorithm takes the challenge, the signature, and the public key as input, and if the signature has been correctly calculated with the corresponding private key, then the algorithm will check for equality. In this case, the wallet displays a message confirming the success of the seed verification to the user if everything went well and if the received signature, SIGNVERIF, is valid.

[0794] It will be readily apparent to those skilled in the art that this seed verification method is susceptible to various variations and applications. Generally, this method can be applied to any card possessing a seed and capable of deriving a private key from the seed, regardless of how the seed was stored on the card. It will preferably be implemented through at least one encrypted channel, and preferably after implementing one or more security mechanisms, such as those proposed above, such as verification of the card's serial number, verification of a user PIN, or verification of a card certificate, which may themselves be implemented individually or in combination.

[0795] Furthermore, the term "card" in this description and the claims should not be interpreted restrictively and generally covers any portable object having the functionalities of a card. Generally, the LNK connection is not necessarily contactless. It can be established via ISO 7816 contact pads or any other means. The method can indeed be adapted to various media: cards from different manufacturers, secure USB keys, contactless keys forming the equivalent of a contactless card although having a thicker body, NFC mobile phones including a secure element capable of operating in contactless mode. Card emulation, etc. The process integrates easily with existing crypto-asset management systems, particularly implementations based on standard protocols such as SCP03. User involvement (serial number verification, PIN entry, etc.) enhances protection while also providing a user-friendly experience that avoids common errors, and the ability to verify the seed afterward ensures consistency between the wallet seed and the one stored on the card at all times. Finally, the term "seed" in the description and claims can cover any other type of confidential data or secret that requires the same level of protection during backup or restoration.Thus, as indicated in the preamble, this disclosure concerns the saving, in a smart card or similar device (namely a device having the same function and the same essential characteristics), of a secret held by an electronic device, and in particular of a cryptographic seed held by a hardware wallet of crypto-assets.< / signverif> < / signverif> < / signverif> < / signverif> < / signverif> < / signverif> < / signverif> < / ch> < / ch> < / ch> < / ch> < / ch> < / ch> < / ch> < / ch> < / ch> < / ch> < / pin> < / pin> < / pin> < / pin> < / pin> < / pin> < / pin> < / pin> < / pin> < / pin> < / pin> < / pin> < / pin> < / pin> < / pin> < / pin> < / pin> < / pin> < / pin> < / x>

Claims

Demands

1. A method for storing a cryptographic seed (MS) held by a hardware crypto-asset wallet (HW) in a smart card (CD), the hardware wallet and the smart card each comprising a secure processor (SE1, SE2) having volatile memory (VM1, VM2) and non-volatile memory (NVM1, NVM2), the hardware wallet further comprising an information display means (TS) and an information input means (KB), the method comprising the following steps: - pre-writing a serial number (SN) on the card body in a user-readable manner, and pre-storing the serial number (SN) in the card, - establishing a communication link (LNK) between the hardware wallet and the card, - establishing (SOI, S02, A01-A31, C01-C85) an encrypted communication channel (SCPA, SCPB) between the card and the hardware wallet, - communication (S10) to the wallet material,via the encrypted communication channel, the serial number held by the card, - reception (S1) by the hardware wallet and display on the hardware wallet screen, for the user's attention, of the received serial number, - detection (S20) or recording (S20') by the hardware wallet of at least one action (AC01, AC02) by the user on the information input means, confirming that the serial number displayed on the screen is identical to the serial number displayed on the card body, - by means of the hardware wallet, if the hardware wallet has detected (S20) or recorded (S20') said user action (AC01, AC02) confirming that the serial number displayed on the screen is identical to the serial number displayed on the card body, transmission (S40) of the cryptographic seed to the card via the encrypted communication channel (SCPA, SCPB), and - storage (S42) of the cryptographic seed by the card.

2. A method according to claim 1, comprising the following steps: - by means of the hardware wallet, entry (S20) of a user's personal identification code (PIN), and transmission (S30, B00-B12) of the personal identification code to the card via the encrypted communication channel (SCPA, SCPB), and - storage (S32) of the personal identification code by the card, process wherein the user's action confirming that the serial number displayed on the screen is identical to the serial number displayed on the card body consists of the user's entry (AC02) of the personal identification code (PIN).

3. A method according to any one of claims 1 and 2, comprising a step (S50) of verification by the hardware wallet of the cryptographic seed stored in the card, the verification step comprising the following steps: - the hardware wallet sends (VI3) a challenge to the card, - the card generates (V23) a private key (sKv) by derivation of the cryptographic seed, according to a derivation path, - the card conducts (V25) a cryptographic computation from the challenge and the derived key, generates a result (SIGNVERIF) of this cryptographic computation, and sends (V35) this result to the hardware wallet, - the hardware wallet generates (V45) the same private key by derivation of the cryptographic seed, according to the same derivation path, and - the hardware wallet verifies (V47) by means of the derived private key the result (SIGNVERIF) of the cryptographic computation sent by the card.

4. Method according to claim 3, comprising a preliminary step of storing the derivation path in the hardware wallet and the card before putting them into service.

5. A method according to claim 3, wherein the derivation path is dynamically generated by the hardware wallet and the card from the challenge sent by the hardware wallet to the card and according to the same derivation path generation rule.

6. A method according to any one of claims 3 to 5, wherein the step (S50) of verifying the cryptographic seed is systematically engaged after saving the cryptographic seed in the card.

7. A method according to any one of claims 3 to 6, wherein the step (S50) of verifying the cryptographic seed can be initiated at any time at the user's request.

8. A method according to any one of claims 1 to 7, wherein the encrypted communication channel comprises a first encrypted communication channel (SCPA) implementing a first encryption technique, in which is encapsulated a second encrypted communication channel (SCPB) implementing a second encryption technique, the second encrypted communication channel being encapsulated in the first encrypted communication channel, the method comprising the following steps: - establishment (SOI, A01-A31) between the card and the hardware wallet of the first encrypted communication channel (SCPA), - authentication (S02) of the card by the hardware wallet and authentication (S02) of the hardware wallet by the card, via the first encrypted communication channel, then establishment (S02, C01-C85) between the card and the hardware wallet, via the first encrypted communication channel (SCPA),of the second encrypted communication channel (SCPB), the serial number held by the card being transmitted to the hardware wallet (S 10) via the first encrypted communication channel before the establishment of the second encrypted communication channel, or via the second encrypted communication channel.

9. A method according to claim 8, comprising the following steps: - pre-storing in the hardware wallet (HW) a public key (pK) of a trusted authority, a static private key (sKw) and a static public key (pKw) of the hardware wallet, and a static certificate of the hardware wallet (Cw) comprising a signature (SIGN(pKw)sK) of the static public key of the hardware wallet by means of a private key (sK) of the trusted authority, - pre-storing in the card (CD) the public key (pK) of the trusted authority, a static private key (sKc) and a static public key (pKc) of the card, and a static certificate (Ce) of the card comprising a signature (SIGN(pKc)sK) of the static public key of the card by means of the private key of the trusted authority, a method in which the authentication (S02) of the card by the hardware wallet and the authentication (S02) of the hardware wallet by the card, via the first encrypted communication channel and before the establishment of the second encrypted communication channel, includes a verification step (S02, C23) by the hardware wallet of the authenticity of the signature present in the static certificate of the card, and a verification step (S02, C55) by the card of the authenticity of the signature present in the static certificate of the hardware wallet, by means of the public key (pK) of the trusted authority.

10. A method according to claim 9, comprising, for establishing the second encrypted communication channel, the following steps: - generation (C31) by the card of an ephemeral private key (sKEc) and a ephemeral public key (pKEc), - generation (C63) by the hardware wallet of an ephemeral private key (sKEw) and a ephemeral public key (pKEw), - transmission (C37) to the hardware wallet, via the first encrypted communication channel, of the ephemeral public key of the card, - transmission (C69) to the card, via the first encrypted communication channel, of the ephemeral public key of the hardware wallet, - generation (C77) of a secret shared by the card from the ephemeral public key (pKEw) of the hardware wallet and generation (C85) of the same secret shared by the hardware wallet from the ephemeral public key (pKEc) of the card,- Derivation (C77) of the secret shared by the card and derivation (C85) of the secret shared by the hardware wallet to obtain a common session key (KB), and - encryption of the second communication channel encrypted by the card and by the hardware wallet using the common session key (KB).

11. A method according to claim 10, comprising, for establishing the second encrypted communication channel, the following steps: - generation (C31) by the card of an ephemeral certificate (CEc) comprising the ephemeral public key (pKEc) of the card and a signature (SIGN) of the ephemeral public key by the static private key (sKc) of the card, - transmission (C33-C37) to the hardware wallet, via the first encrypted communication channel, of the ephemeral certificate of the card, - using the static public key (pKc) of the card, verification (C43) by the hardware wallet of the authenticity of the signature present in the ephemeral certificate of the card, - generation (C63) by the hardware wallet of an ephemeral certificate including the ephemeral public key (pKEw) of the hardware wallet and a signature (SIGN) of the ephemeral public key by the static private key (sKw) of the hardware wallet, - transmission (C65-C69) to the card, via the first encrypted communication channel, of the ephemeral certificate of the hardware wallet, and - using the static public key (pKw) of the hardware wallet, verification (C75) by the card of the authenticity of the signature present in the ephemeral certificate of the hardware wallet.

12. A method according to any one of claims 8 to 11, wherein the second encryption technique is an elliptic curve cryptography comprising an ECDH elliptic curve Diffie-Hellman key exchange for the generation of a shared secret.

13. A method according to any one of claims 8 to 11, wherein the first encryption technique is based on AES and conforms to the GlobalPlatform SCP03 specification.

14. A method according to any one of claims 8 to 13, wherein: - exchanges between the hardware wallet and the card are made via ISO7816 APDU units comprising APDU commands and APDU responses, - the exchanged APDU units are accompanied (B00, C07, C17, C27, C37, C49, C59, C69, C81, D12, D26, E12, E28) by a first message authentication code (MACA) which is generated (C05, C15, C25, C35, C47, C57, C67, C79, D10, D24, E10, E26) by means of a first cryptographic signature function (MACGEN).

15. A method according to any one of claims 8 to 14, wherein the cryptographic seed is transmitted (E02-E12) into APDU units in a doubly encrypted form ([MSdata]) the generation of which comprises the following steps: a) encrypt the cryptographic seed in the second encrypted communication channel (E02), in order to obtain a first encryption ( ) of the seed, b) calculate (E04) a message authentication code (MACms) on the first encryption ( ), using a second cryptographic signature function (MACGEN), c) concatenate the first cipher ( ) of the seed and the message authentication code (MACms), and d) encrypt (E08) the result of the concatenation (MSdata) within the first encrypted communication channel, in order to obtain the doubly encrypted form ([MSdata]) of the cryptographic seed.

16. A method according to any one of claims 8 to 15, wherein the personal identification code is transmitted in APDU units in a doubly encrypted form ([PINdata]) the generation of which comprises the following steps: a) encrypt (D02) the personal identification code in the second encrypted communication channel, in order to obtain a first encryption ( <pin>) of the personal identification code, b) calculate (D04) a message authentication code (MACpin) on the first encryption ( <pin>) of the personal identification code, using a second cryptographic signature function (MACGEN), c) concatenate the first cipher ( <pin>) the personal identification code and the message authentication code (MACpin), and d) encrypt the result of the concatenation (PINdata) in the second encrypted communication channel (D08), in order to obtain the doubly encrypted form ([PINdata]) of the personal identification code.

17. A method for manufacturing a card capable of implementing the method according to any one of claims 8 to 16, comprising the following steps: - manufacturing a standard JAVA board with an operating system pre-configured to implement GlobalPlatform's SCP03 encrypted communication channel, - uploading an application program configured to implement the process steps and the second encrypted communication channel to the board, and

18. - use as the first communication channel the encrypted SCP03 communication channel of GlobalPlatform managed by the pre-configured operating system of the board. Manufacturing method according to claims 9 and 17, comprising the step of including in the application program the public key of the trusted authority, the public and private keys and the static certificate of the card.< / pin> < / pin> < / pin>

Images