Method for the centralised management of at least one process for approving an action

Abstract

The invention relates to a method for managing a process for approving at least one action by at least one user, wherein the process for approving the action is associated with a series of views intended for the user, the method comprising the steps of generating, by means of a hardware security module (HSM1), the series of views of the approval process and communicating the series of views to an orchestrator service (ORC, SRV1); and providing, by means of the orchestrator service, a personal security device (PSDi) with all or part of the series of views.

Description

Method for centralized management of at least one action approval process

[0001] The present invention relates to a method for managing an approval process of an action by at least one user, in which the approval process of the action is associated with a series of views for the user, the method being implemented by means of a system comprising a hardware security module, for governing the approval process and initiating the performance of the action after its approval by the user, and a personal security device for displaying views of the series of views and receiving approval from the user. Background

[0002] In recent years, the development of cryptocurrencies or other types of cryptoassets managed by blockchains, such as non-fungible tokens ("NFTs") and smart contracts, has given rise to various means of storing and preserving the private and public keys attached to these different types of cryptoassets. This is how cryptoasset wallets, commonly known as "hardware wallets" or "personal security devices" (PSDs), have emerged, allowing the storage and preservation of these keys. A personal security device is a hardware device whose function is to store the private and public keys attached to cryptoasset accounts, and to sign transactions using these keys.

[0003] The diagram shows an example of a PSD personal security device, for example the device marketed by the applicant under the name "Ledger Blue" or "Ledger Stax", and an HDV host device running an HSW companion application, for example the "Ledger Live" application developed by the applicant. Since the PSD personal security device cannot connect directly to the Internet for security reasons, it is associated with the HDV host device to carry out transactions on the blockchain. The HDV host device is for example a computer, a mobile phone, a tablet or the like. The connection between the PSD personal security device and the HDV host device may be of the USB or Bluetooth type for example.

[0004] When the PSD personal security device is first put into service, it generates a master key K0 from which it can subsequently derive private keys Kj for crypto-asset accounts, and provides the user with a 24-word recovery phrase that the user must keep on a suitable physical medium, for example a sheet of paper or an unalterable medium such as an engraved metal plate, which the user must keep in a safe place.

[0005] Once connected to the host device, the PSD personal security device can interact with the companion software to allow a USR user to carry out transactions on a BCN blockchain or on decentralized exchange sites. The PSD personal security device can also communicate with a hardware security module (HSM) located in a data center. Such a hardware security module is also called a "transactional black box" (BTN) (https: / fr.wikipedia.org / wiki / Hardware_Security_Module). It is generally the case that the HSM does not store the user's private keys and only ensures the authenticity of the PSD personal security device, its commissioning, the updating of its operating system, the downloading of certified application programs, etc.

[0006] However, an exception to this rule is made in the case of shared management of cryptoasset accounts, in which a request to carry out a transaction on a cryptoasset account can only be executed after receiving the agreement of at least one approving user and satisfying a governance rule. As illustrated in the, in this case, a transaction administration server SRV0 is provided coupled with a hardware security module HSM0 having access to a memory MEM in which the master key K0 is recorded, making it possible to generate the derived keys Kj of the cryptoasset accounts whose management is shared. The hardware security module HSM0 executes a governance service GOV in which governance rules have been recorded, making it possible to assign roles to OPi operators (OP1… OP N), for example a role of co-owner ("shared-owner"), administrator, transaction approver, etc. The SRV0 server hosts a TPF transaction administration platform allowing certain operators to request the commitment of actions.

[0007] It will be noted, in addition, that in order to ensure a very high degree of security for the holders of accounts subject to such shared management, the applicant uses HSM hardware security modules hosted in secure data centers located in various parts of the world, and offering a very high level of security compliant, for example, with the FIPS 140-2 level 3 standard, and in which various additional hardware and software security features are also implemented.

[0008] When an OPi operator connects to the TPF transaction platform and requests the performance of an action, the requested action is communicated to the HSM0 hardware security module. The HSM0 module identifies the governance rule that applies to the requested action, then requests the agreement of OPi operators designated by this governance rule. When the agreement of the operators is received, the HSM0 module performs the requested action or initiates its performance. If this action is the performance of a transaction, the HSM0 module signs the transaction with the appropriate private key Kj and then broadcasts it on the relevant blockchain.

[0009] In the context of such shared management of crypto-asset accounts, an OPi operator generally comprises a natural person user USRi equipped with a PSDi personal security device which is connected to an HDVi host device. The HDVi host device allows the PSDi personal security device to be connected to the SRV0 administration server and the HSM0 hardware security module.

[0010] In this type of application, performing actions typically requires USRi users to navigate pages, or “views,” that are displayed on their PSDi personal security devices. Typically, each action that can be performed has an associated action approval process and at least one governance rule. The action approval process is represented by a set of chained views that each USRi user can navigate by making choices, allowing them to branch off, move forward, or move back, until they arrive at a final view that concludes the approval process. When the final view is reached, the user is given the option to agree or disagree with the action to be performed, for example, by pressing an approve or decline button.

[0011] Ultimately, since a shared crypto-asset account management system allows various actions to be carried out and each action is associated with a series of views allowing the action approval process to be implemented, implementing such a system involves managing a very large number of different views.

[0012] However, it turns out that PSDi personal security devices sometimes have limited memory space, which limits the number of views that can be generated and also limits the size of the program that allows them to generate such views and link them together. Indeed, a personal security device generally includes a secure element to execute such a program, and a microcontroller to ensure communications with the outside world. A secure element is a semiconductor chip comprising cryptographic computing means and implementing various countermeasures to counter fraudster attacks, capable of storing and manipulating data in compliance with the security rules and requirements set by a trusted authority. Due to the many countermeasures it implements, the memory space of a secure element is limited, whether it is its non-volatile memory or its volatile memory.

[0013] Additionally, each update of the GOV governance service of the HSM0 module involves updates to the PSDi personal security devices, so that they are able to generate new series of views corresponding to new actions offered by the governance service.

[0014] It might therefore be desirable to provide a method for managing an action approval process that significantly reduces the memory space required by personal security devices for generating the views to implement the approval process. Summary

[0015] Embodiments relate to a method for managing an approval process for an action by at least one user, wherein the approval process for the action is associated with a series of views for the user, the method being implemented by means of a system comprising a hardware security module, for governing the approval process and initiating the performance of the action after its approval by the user, and a personal security device for displaying views of the series of views and receiving approval from the user. The method comprises the steps of providing an orchestrator service executed by a server; by means of the hardware security module, generating the series of views of the approval process and communicating the series of views to the orchestrator service, and by means of the orchestrator service, providing to the personal security device some or all of the views generated by the hardware security module.

[0016] According to one embodiment, the method comprises the step of, by means of the orchestrator service, providing the personal security device with a first view of the series of views, then one or more subsequent or previous views of the series of views, upon request from the personal security device.

[0017] According to one embodiment, providing at least one view to the personal security device comprises the orchestrator service slicing the view into a plurality of data blocks, sending each data block to the personal security device, and the personal security device reconstructing the view when the plurality of data blocks have been received, by concatenating the data blocks.

[0018] In one embodiment, the hardware security module communicates each view to the orchestrator service in an encrypted form with an encryption key known to the personal security device but unknown to the orchestrator service.

[0019] According to one embodiment, the method comprises the steps of, by means of the orchestrator service, slicing each view into its encrypted form and providing the personal security device with encrypted data blocks, and by means of the personal security device, concatenating the received encrypted data blocks and decrypting the resulting bit string, to reconstruct the view.

[0020] In one embodiment, the views are sent to the personal security device by the orchestrator service via application protocol data units as defined by ISO / IEC 7816-4.

[0021] According to one embodiment, the method comprises a step of authenticating the personal security device by the hardware security module, the authentication step comprising the steps of, by means of the hardware security module, sending a challenge to the personal security device, and by means of the personal security device, generating a response to the challenge and sending it to the hardware security module.

[0022] According to one embodiment, the step of calculating and sending a response to the challenge is only carried out if the user communicates to the personal security device his approval of the action to be carried out.

[0023] According to one embodiment, the hardware security module is configured so that receipt of a valid challenge response constitutes user approval to perform the action.

[0024] According to one embodiment, the challenge is sent to the personal security device as a dummy view in the series of views, having a rank higher than the rank of the last view in the series of views.

[0025] In one embodiment, the challenge is sent to the personal security device along with a view, as data linked to an item within the view.

[0026] According to one embodiment, the personal security device is configured to, after receiving user approval on the action to be performed, send to the hardware security module all or part of a secret data item of the personal security device or data derived from this secret data.

[0027] According to one embodiment, a view provided by the hardware security module consists of a description of the view according to a view structure, the description being transformed into a binary data string.

[0028] According to one embodiment, the method comprises a step of cutting the binary data string forming a description of the view into a plurality of data blocks, sending each data block to the personal security device, reconstituting the description of the view by the personal security device when the plurality of data blocks have been received, by concatenating the data blocks, and reconstituting the view by the personal security device, from the description of the view.

[0029] According to one embodiment, the view structure comprises a plurality of objects.

[0030] According to one embodiment, the view structure comprises at least two main containers each containing objects.

[0031] According to one embodiment, the method is implemented for the approval of cryptoasset account administration actions, said administration actions comprising at least one of the following actions: the approval of a transaction by means of a cryptoasset account; the approval of an action of generating a cryptoasset account master key; the approval of actions of acceptance or revocation of operators able to participate in cryptoasset account administration actions.

[0032] Embodiments also relate to a system for managing an approval process for an action by at least one user, wherein the approval process for the action is associated with a series of views provided to the user, the system comprising a hardware security module, for governing the approval process and initiating the performance of the action after its approval by the user, and a personal security device for displaying views of the series of views and receiving approval from the user, the system also comprising an orchestrator service executed by a server, the hardware security module being configured to generate the series of views of the approval process and communicate the series of views to the orchestrator service, and the orchestrator service being configured to provide the personal security device with some or all of the views generated by the hardware security module.

[0033] According to one embodiment, the orchestrator service is configured to slice at least one view into a plurality of data blocks, and send the plurality of data blocks to the personal security device, the personal security device being configured to reconstruct the view when the plurality of data blocks have been received, by concatenating the data blocks.

[0034] According to one embodiment, the hardware security module is configured to communicate each view to the orchestrator service in an encrypted form with an encryption key known to the personal security device but unknown to the orchestrator service.

[0035] In one embodiment, the views are sent to the personal security device by the orchestrator service via application protocol data units as defined by ISO / IEC 7816-4.

[0036] According to one embodiment, a view provided by the hardware security module consists of a description of the view according to a determined view structure.

[0037] According to one embodiment, the view structure comprises a plurality of objects.

[0038] According to one embodiment, the system is configured for the approval of cryptoasset account administration actions, said administration actions comprising at least one of the following actions: the approval of a transaction by means of a cryptoasset account, the approval of an action of generating a cryptoasset account master key, the approval of actions of acceptance or revocation of operators able to participate in cryptoasset account administration actions. Summary description of the drawings

[0039] Embodiments of a method and system for managing action approval processes will be described in the following without limitation, in relation to the attached figures among which:

[0040] - the previously described schematically represents a classic system for non-mutualized management of crypto-asset accounts,

[0041] - the previously described schematically represents a classic system for the shared management of crypto-asset accounts,

[0042] - shows an embodiment of a system for the shared management of crypto-asset accounts enabling the implementation of the method,

[0043] - shows in more detail a personal security device present in the system of the,

[0044] - is a sequence diagram describing steps in the action approval process management process,

[0045] - laet ladescribe the steps of the diagram of the,

[0046] - shows a view structure used in an embodiment of the method,

[0047] - shows a descriptor of a view made according to the view structure of the,

[0048] - the, the, the, the, the, the, the, the, the, the, the, show examples of objects present in the view structure of the,

[0049] - shows a first example of a series of views associated with the performance of an action, and

[0050] - shows a second example of a series of views associated with the performance of an action. Detailed description

[0051] Lamontre shows the general architecture of a first embodiment of a system for shared management of crypto-asset accounts implementing the method for managing action approval processes according to the present disclosure.

[0052] The system includes a hardware security module HSM1, a server SRV1 and OPi operators (OP1… OP N ). The term "hardware security module" means a module of the type mentioned above, providing a high level of hardware and software security, for example, compliant with FIPS 140-2 Level III.

[0053] OPi operators can connect to the SRV1 server via a secure https1 data link. The SRV1 server can connect to the HSM1 module via a secure https2 data link. These secure data links can be of any other known type, e.g. VPN, TLS, etc.

[0054] The hardware security module HSM1 has access to a secure memory MEM in which a master key K0 and keys Kj derived from the master key K0 are stored, corresponding to a set of cryptoasset accounts subject to shared management. An OPi operator may be a co-owner ("shared-owner"), an administrator, a transaction approver, or any other role that can be defined. The administrators define governance rules. They can also, in certain embodiments, approve or even designate co-owners. The co-owners generate the master key K0 of the set of cryptoasset accounts, from master keys of their own. The approving operators approve transactions initiated by themselves or other operators.

[0055] In one embodiment, an OPi operator comprises a personal security device PSDi associated with an HDVi host device running a CAP companion application, for example the "Ledger Live" application developed by the applicant. The operator also comprises a natural person user USRi who can act on both the HDVi host device or the personal security device PSDi.

[0056] In an embodiment shown in the, a personal security device PSDi has a hardware wallet type architecture and comprises a secure element SE1 and a microcontroller MCU1. The microcontroller manages a USB1 interface of the USB type. In certain embodiments, the microcontroller also manages a BT1 interface of the Bluetooth type. The personal security device PSDi also comprises a touch screen TS (Touch Screen) directly controlled by the secure element SE1, and comprising a display DISP covered by a touch module TM (Touch Module). The secure element SE1 comprises a memory SMEM receiving its operating system OS1 as well as an application program OAP making it possible to use the personal security device as an operator of the system for the shared management of crypto-asset accounts.Such an architecture is, for example, that of the Ledger Stax device, which is equipped with a touchscreen directly controlled by the secure element. Such a PSDi personal security device is therefore the equivalent of a smart card (the secure element) equipped with a touchscreen and a USB / Bluetooth communication interface (the microcontroller).

[0057] In another embodiment, the PSDi personal security device and the HDVi host device form a single device, for example a so-called "blockchain" phone, comprising a hardware wallet integrated into the phone. In this case, greater computing power is available, provided by the application processor of the phone. In other embodiments, the OPi operators can be computing entities executed by personal computers or servers. These different types of operator devices can coexist in the system described herein.

[0058] Returning to the, the SRV1 server hosts a TPF transaction platform, an ORC orchestrator service and a BCAST service for broadcasting transactions on BCN blockchain networks. The HSM1 module includes and executes a GOV governance service and a SIGN1 transaction signing service. The SIGN1 signing service ensures the signing of a transaction using one of the keys Kj to which the HSM1 module has access, when the transaction has been approved by approving users whose identity and number are defined by a governance rule implemented by the GOV governance service. The BCAST service is shown here as a non-limiting example as executed by the SRV1 server but could also be executed by any other server or device associated with the system.

[0059] The MEM memory receiving the master key K0 and the keys Kj can be internal or external to the HSM1 module. The system is designed so that the MEM memory can only be read and written by the HSM1 module.

[0060] In one embodiment, the personal security devices PSDi and the HSM1 module are members of a public key infrastructure PA managed by a certification authority CA providing a public key PA. They each comprise a private key, respectively dPi, dH1, a public key, respectively PPi, PH1, and a certificate, respectively CPi, CH1. The certificate CPi or CH1 comprises the public key PPi or PH1 and a signature thereof produced by the certification authority using its private key dA. Thanks to these certificates, the validity of which can be verified using the public key PA of the trusted authority, each PSDi device can provide proof of its authenticity to the HSM1 module.

[0061] The system may be configured to allow various types of actions, such as actions to integrate or exclude operators, for example approvers, co-owners, or administrators, an action to generate a master key K0 from master keys specific to co-owners, or an action to carry out a transaction. Associated with each action is a series of views necessary to implement the approval process for the action, intended to be displayed by the PSDi personal security devices at the user's discretion. Such "views" may include graphical elements and / or text that are distinct from the data they may receive, or accompany. Examples will be described later in connection with Figures 9A to 9K.

[0062] When an action is to be performed, the system implements the action approval process management method according to the present disclosure. This method differs from a conventional method in that it considerably reduces the memory space required for the generation of views by the PSDi personal security devices. According to this method, instead of letting each PSDi personal security device generate the series of views for a given approval process, this series of views is generated by the HSM1 module. Once the series of views is generated by the HSM1 module, the latter provides it to the ORC orchestrator service of the SRV1 server. Then, the ORC orchestrator service transmits the views to the PSDi personal security devices, one after the other, as the latter request them.

[0063] Each type of action may also be associated with a type of approval. This may be express or implicit approval, which may be accompanied by the provision of data. In some embodiments, the mere provision of this data constitutes implicit approval. For example, the approval of an action of accepting or excluding an operator may be associated with the provision, by each personal security device requested, of a response to a challenge previously sent by the hardware security module. Such a response to a challenge may, for example, consist of signing the challenge. Sending this signature may constitute implicit approval of the action subject to approval. As another example, the approval of an action of generating a master key K0 may result in the provision to the hardware security module, by each personal security device requested, of data enabling this master key K0 to be generated.The data provided by each personal security device may, for example, be its own master key or part of it, possibly in encrypted form, or data, encrypted or not, generated from its master key. Sending this data may constitute implicit approval of the action of generating the master key K0.

[0064] In one embodiment, data links between the SRV1 server and the PSDi devices for communicating to the latter the views generated by the HSM1 module are established using smart card commands and responses of the APDU (“Application Protocol Data Unit”) type as defined by the ISO / IEC 7816-4 protocol.

[0065] It will be recalled here that an APDU command includes a four-byte header CLA (Class), INS (Instruction), P1, P2, and a variable-length conditional body that includes fields [Lc field] [Data field] [Le field]. The number of bytes present in the data field of an APDU command is indicated by the Lc field. The maximum number of bytes expected in the data field of the APDU response is indicated by the Le field (length of expected data). When the Le field is equal to zero, this means that the maximum number of available data bytes is requested. Finally, the Data field includes the data carried by the command.

[0066] It will also be recalled that an APDU response includes a variable length data field and a mandatory end message, called a "trailer", of two bytes SW1, SW2.

[0067] In the example implementation of the method described later, the following notations and values ​​will be used:

[0068] SW1,SW2 = 9000: Send an APDU response including only the two bytes SW1, SW2 set to the value 9000 meaning "No further qualification", or "nothing to report". This type of response is used as an acknowledgment of receipt of data present in an APDU command.

[0069] P1 = 80(MORE) or 00 (END): When the P1 field of a command is equal to 80, it means that the data provided in the command is not complete and that more data will follow. When the P1 field is equal to 00, it means that all the data has been transmitted.

[0070] SW1, SW2 = 6100 or 9000: When the SW1, SW2 bytes of a response equal 6100, it means that the data in the response data field is not complete and more data must be sent to complete the response. When the bytes equal 9000, it means that all the data has been sent.

[0071] GET RESPONSE: The GET RESPONSE command is sent, for example, when a previously received response includes the SW1, SW2 field equal to 6100, which means that the entity sending the responses still has data to provide, after which the entity sending commands sends the GET RESPONSE command. This command allows the entity that must send data to send it in a response to this command. When this command is coded "00C0000000" with an Le field equal to 0, this means that the sender of the command is waiting to be sent a response with a maximum number of bytes.

[0072] The is a sequence diagram that shows an example of carrying out the method in relation to the performance of an action that is approved here by sending a response to a previously received challenge, this response here consisting of the signing of the challenge. The steps shown in the are detailed in Figures 6A, 6B and will be described in more detail in the following.

[0073] S01 - Exec Action Add

[0074] At step S01, an operator connects to the TPF platform and requests the execution of an action Aj. The TPF platform transfers this execution request to the ORC orchestrator service.

[0075] S02 - Prepare Action Add

[0076] At step S02, the orchestrator service requests the governance service GOV of the HSM1 module to prepare the action Aj. The governance service then determines the applicable governance rule and the OPi operators whose approval must be obtained for the execution of the action. In the following, for the sake of simplification of the presentation, it will be assumed that the agreement of a single OPI operator, equipped with a PSDi personal security device, must be required here. However, the steps described below can be carried out simultaneously with several different operators, and therefore several PSDi personal security devices, if the applicable governance rule requires several approvals.

[0077] S03 - k = ECDH (PSDi, HSM1)

[0078] In a step S03, a handshake is performed between the personal security device PSDi and the governance service GOV, in order to define between the personal security device PSDi and the module HSM1 an ephemeral session key k which will allow the governance service GOV to send to the PSDi device, via the orchestrator service ORC, data encrypted using this session key.

[0079] In one embodiment, this step consists of an ECDH (Elliptic Curve Diffie–Hellman) based Diffie-Hellman key exchange, during which the two entities PSDi and HSM1 exchange ephemeral public keys and ephemeral certificates, each combining an ephemeral private key of its own with the ephemeral or static public key of the other entity to obtain the ephemeral session key k. In addition, the HSM1 module may have been configured to know the public key of the PSDi personal security device, which allows it to verify that the signature present in the ephemeral certificate of the PSDi device, generated from the static private key of the latter, is valid.

[0080] In a variant, this step implements the "Noise Protocol Framework" method (http: / www.noiseprotocol.org / noise.html) with the Curve25519 elliptic curve, an AES-GCM encryption function using an AES (Advanced Encryption Standard) key and the GCM (Galois / Counter Mode) encryption algorithm, and the SHA-256 (Secure Hash Algorithm) hash algorithm on 256 bits. The authentication of the PSDi device and the HSM1 module is done by means of an ECDSA (Elliptic Curve Digital Signature Algorithm) signature function and the public keys of each entity. In an embodiment called "K Pattern", the handshake is of the one-way handshake pattern between the PSDi personal security device and the ORC orchestrator service.

[0081] S04 – PREPARE [V1,V2,...V N ]Aj ; GEN CHALLENGE

[0082] At step S04, the governance service GOV prepares a set of views V1 to V Nnecessary for the implementation of the approval process of the action Aj by the OPi operator. In addition, it generates a challenge using a random binary word generator.

[0083] S05 – ENC(V1,k), ENC(V2,k),... ENC(V N ,k), ENC(CHALLENGE, k)

[0084] At step S05, the governance service GOV encrypts each view V1 to V N with the ephemeral session key k. The governance service GOV also encrypts the challenge with the key k, as if it were an additional view V N+1 The ENC encryption function used is for example the AES function or the AES-GCM function.

[0085] S06 – Send ENC(V1,k), ... ENC(V N ,k), ENC(CHALLENGE,k)

[0086] At step S06, the governance service GOV sends each of the encrypted views as well as the encrypted challenge to the orchestrator service ORC.

[0087] S10 – CUT{ENC(Vi,k)} = DT1 / DT2 / DTn

[0088] At a step S10, the orchestrator service ORC cuts each encrypted view Vi into a plurality of data blocks DT1, DT2… DTn, or “chunks” of the view Vi.

[0089] S11 – [DTi, P1] (i = 1→n)

[0090] At a step S11, the orchestrator service ORC initiates the first step of a loop “VIEWLOOP(Vi)” for sending a view Vi to the personal security device PSDi, starting with the first view V1 of the series of views. The orchestrator service ORC sends to the personal security device PSDi the first data block DT1 of the set of data blocks DTi resulting from the division of the encrypted view Vi during the first execution of step S11, then the following data blocks during the following iterations. Each data block DTi is sent in an APDU command including the field P1 which can be equal to 80 or 00 as seen above.

[0091] S12 – SW1, SW2 = 9000

[0092] At step S12, the PSDi personal safety device returns an APDU response equal to 9000, which confirms the correct reception of the DTi data block.

[0093] S13 - P1 = 80(MORE) or 00 (END)?

[0094] In a step S13, the personal security device PSDi determines whether the field P1 is equal to 80 or 00. If P1 is equal to 80, the personal security device PSDi repeats step S11 to receive a new data block DTi, and so on until all data blocks DT1 to DT N have been received. Repeating steps S11, S12 and S13 forms the loop “VIEWLOOP(Vi)”. When P1 is equal to 00, all DTi data blocks have been received and the PSDi personal safety device exits the VIEWLOOP loop for the view Vi considered.

[0095] S14 – Vi=DEC((DT1 / DT2 / DT3 / ... / DTn), k)

[0096] In a subsequent step S14, the personal security device PSDi concatenates all the received data blocks DTi, to reconstruct the encrypted view Vi ENC(Vi, k), and decodes the encrypted view using the ephemeral session key k, to obtain the view Vi. The personal security device PSDi then displays this view.

[0097] In some embodiments, the size of the views to be sent, or of some views to be sent, is small enough to form only one data block DT1. In this case, step S10 is not performed, step S11 is executed only once for sending the single data block, and step S14 only comprises the operation of decrypting the data block.

[0098] U10 – USR CHOICE

[0099] At a step U10, the user USRi makes a choice in the view displayed by his personal security device PSDi. This choice consists, for example, of pressing a hardware button or a touch button that is displayed in the view, for example a “previous” button if he wants to return to the previous view, “next” if he wants the “next” view, “refuse” if he refuses to give his consent to the performance of the action, or on the contrary “accept” if he accepts it. Various other means of receiving the user’s approval by the personal security device could of course be provided, such as voice approval by means of a specific word or passphrase with preferably identification of the user’s voice, manual entry of a password, etc. It will also be noted that the choice between “refuse” and “accept” is generally only offered on the last view of the series of views.Since the different views have been chained by the GOV governance service, the “previous” and “next” choices unambiguously designate the next view to be displayed by the PSDi personal security device.

[0100] S15 – USR CHOICE = New Vi or REFUSED or AGREE?

[0101] In a step S15, the personal security device PSDi determines whether the choice that the user made in step U10 consists of a request to display a new view or whether this choice consists of a final decision of acceptance or refusal which ends the decision process. If this choice consists of a request to display a new view (“New Vi”), the PSDi device goes to a step S16A. If the user refuses the action (“REFUSE”), the PSDi device goes to a step S16B. If the user agrees to perform the action (“AGREE”), the PSDi device goes to a step S16C.

[0102] S16A – Next Action = [i, 9000]

[0103] In step S16A, the personal security device PSDi determines the rank i of the next view to be displayed to the user and indicates this choice to the orchestrator service ORC by sending it a “Next Action” APDU response whose data field indicates the rank i of the new requested view Vi and whose fields SW1, SW2 are equal to 9000 to indicate that the previous view has been received and has been processed. The method is then returned to step S10 where the orchestrator service ORC divides the new requested view into data blocks DTi, then repeats the “VIEWLOOP(Vi)” loop. Steps S14, U10 and S15 are executed again. The repetition of the loop "VIEWLOOP(Vi)" and steps S14, U10 and S15 until the final decision of the user forms a loop "ACTIONLOOP(Ai)" for sending to the personal security device PSDi all the views of the series of views associated with the action Ai which were requested by the user.It will be noted that some views in the view series may never be displayed depending on the choices and paths taken by the user to arrive at the view by means of which he makes a final decision.

[0104] S16B – SW1, SW2 = REFUSE

[0105] In step S16B, the personal security device PSDi sends to the orchestrator service ORC an APDU response without data field in which the fields SW1, SW2 are set to a determined value which signifies that the user refuses the action. The orchestrator service ORC informs the governance service GOV which decides whether or not this refusal causes the cancellation of the action Aj. Indeed, in the case of an action associated with a governance rule which provides that the agreement of a simple majority of operators is sufficient to carry out the action, the refusal of an operator does not necessarily lead to the cancellation of the action.

[0106] S16C – Next Action = [N+1, 9000]

[0107] At step S16, the personal security device PSDi sends an APDU response to the orchestrator service ORC requesting it to send it a view of rank N+1. This view is fictitious since the series of views only includes N views. This fictitious view is nothing other than the challenge considered as a last view of the series of views.

[0108] S110 – CUT{ENC(CHALLENGE,k)} = DT1 / DT2 / DTn

[0109] In a step S110, if the length of the challenge exceeds the predetermined size of a data block DTi, the orchestrator service ORC cuts the encrypted challenge into a plurality of data blocks DT1, DT2… DTn, or “chunks” of the encrypted challenge. In the present embodiment, the encrypted challenge is in fact treated in the same way as a view, in accordance with what has been indicated regarding step S16C.

[0110] S111 – [DTi, P1] (i = 1→n)

[0111] At a step S111, the ORC orchestrator service initiates the first step of a “CHALOOP” loop for sending the challenge to the PSDi device. During the first step S11, the ORC orchestrator service sends to the PSDi device the first DTi data block of the set of data blocks resulting from the division of the challenge. The DTi data block is sent in an APDU command comprising the P1 field which can be equal to 80 or 00.

[0112] S112 – SW1, SW2 = 9000

[0113] At a step S112, the PSDi device returns an APDU response equal to 9000, which confirms the correct reception of the DTi data block.

[0114] S113 - P1 = 80(MORE) or 00 (END)?

[0115] In a step S113, the PSDi device determines whether the field P1 is equal to 80 or 00. If P1 is equal to 80, the PSDi device repeats step S11 to receive a new data block DTi of rank i=i+1, and so on until all the data blocks DT1 to DTN have been received. Repeating steps S111, S112 and S113 forms the “CHALOOP” loop. When P1 is equal to 00, all DTi data blocks have been received and the PSDi personal safety device exits the CHALOOP loop to go to a step S114.

[0116] S114 – CHALLENGE=DEC((DT1 / DT2 / DTn), k)

[0117] In step S114, the personal security device PSDi concatenates all of the received data blocks DTi to reconstruct the encrypted challenge, and decrypts it using the key k.

[0118] In some embodiments, the size of the challenge is small enough to form only one data block DT1. In this case, step S110 is not performed, step S111 is executed only once, and step S114 only comprises the operation of decrypting the single data block.

[0119] S20 – SIGN=SIGN(CHALLENGE)dPi

[0120] At step S20 (), the PSDi personal security device generates a response to the challenge. This response is here a signature of the challenge with its private key dPi, for example using the ECDSA signature function.

[0121] S21 – [SIGN, SW1, SW2]

[0122] At a step S21, the personal security device PSDi sends an APDU response including in its data field the response to the challenge, here the SIGN signature or a part thereof, accompanied by the bytes SW1, SW2. As indicated above, if the bytes SW1, SW2 are equal to 6100, this means that the SIGN signature data in the data field of the APDU response is not complete and that other data must be sent. When the bytes SW1, SW2 are equal to 9000, this means that all the data has been sent.

[0123] S22 - SW1, SW2 = 6100 or 9000?

[0124] At step S22, the ORC orchestrator service determines whether SW1, SW2 is equal to 6100 or 9000. If SW1, SW2 is equal to 6100, the ORC orchestrator service goes to step S23. If SW1, SW2 is equal to 9000, the ORC orchestrator service goes to step S30.

[0125] S23 – GET RESPONSE (00C0000000)

[0126] In step S23, the ORC orchestrator service sends the GET RESPONSE command coded "00C0000000" to the PSDi device, which means that it is waiting for the PSDi device to send it the next response with a maximum number of bytes. The ORC orchestrator service then returns to step S21. The repetition of steps S21, S22 and S23 forms a SIGNLOOP loop for reception by the ORC orchestrator service of the SIGN signature, via responses to GET RESPONSE commands.

[0127] S30 – Send {SIGN}

[0128] At step S30, the orchestrator service ORC has received the entire SIGN signature and sends it to the governance service GOV of the HSM1 module.

[0129] S31 – INITIATE Action Aj

[0130] At a step S31, the governance service GOV of the HSM1 module, after having verified that the signature SIGN is valid by means of the public key of the personal security device PSDi, initiates the initialization of the action Aj if the other conditions provided for by the governance rule associated with the action Aj are satisfied. If one of these conditions is to receive the agreement of several operators, the receipt of the agreement of a single user will not be sufficient to initiate the action Aj.

[0131] It follows from the above that according to the embodiment just described, the sending by the personal security device PSDi of a valid signature of the challenge is used to inform the governance service GOV that the user has given his agreement for the performance of the action Aj, so that no specific message is necessary to mark the user's agreement.

[0132] As indicated above, in certain embodiments no challenge is sent to the PSDi personal security devices participating in the action approval process. Their approval may then be accompanied by the sending of data specific to them, or consist of the sending of data specific to them, in particular secret data, in encrypted or unencrypted form, such as their master key, a fraction thereof, or data derived from their master key. In other embodiments, the sending of a response to a challenge is combined with the sending of data specific to the personal security devices, in particular secret data.

[0133] In summary, the action approval process management method just described relieves PSDi personal security devices of the need to generate the views necessary to conduct the action approval process. Personal security devices now only fulfill a passive function of displaying and collecting operator actions.

[0134] In addition to these measures, according to one embodiment of the method, the views are designed according to a view structure that considerably reduces their footprint and correspondingly reduces the number of DTi data blocks to be transmitted to the PSDi devices for the transmission of each view. An example of a view structure is shown in the. The view comprises CT containers and OB objects. A CT container may comprise a plurality of OB objects but may also comprise another container itself comprising objects.

[0135] In the example shown, the view includes a top container CT1, a middle container CT2 and a bottom container CT3. In this example, container CT1 receives objects OB1 and OB10, container CT2 receives objects OB7, OB8 and object OB10, container CT3 receives objects OB2, OB3, OB4.

[0136] Each view constructed in accordance with this view structure is materialized in a binary form by a descriptor consisting of the concatenation of container descriptors and descriptors of the objects contained in the containers. The following shows, without limitation, an example of a descriptor of a container CTi containing objects OBi, OBj, OBk, OBl.

[0137] The descriptor first contains a container identification field [CONTAINER CTi] accompanied by a field [SIZE, LOCATION] which indicates the size and location of the container in the view, then a field [DATA] in which data can be placed. The container descriptor then contains descriptors of the objects that the container contains. The descriptor of each object, for example the object OBi, contains for example:

[0138] - an object identification field [OBJECT],

[0139] - a [SIZE, LOCATION] field which indicates the size and location of the object in the container,

[0140] - a [TEXT] field which indicates the text displayed in the object,

[0141] - an [ACTION] field which indicates an action to be performed if the user presses the object (usable in the case of a touch screen), for example “next view”, “previous view”, “receive challenge”,

[0142] - a [DATA] field in which it is possible to insert data which may in certain cases be displayed alongside text-type data but which may in other cases not be displayed and used to control processes. For example, in one embodiment, the encrypted challenge is inserted into the [DATA] field of a button-type object whose [TEXT] field invites the user to accept an Aj action, and the action “read the encrypted challenge in the [DATA] field” is programmed in the [ACTION] field of the button.

[0143] Ultimately, the concatenation of all the container descriptors and all the object descriptors contained in each container descriptor produces a view descriptor forming a binary string of reasonable length. This view descriptor is encrypted using the key k by the governance service GOV before being sent to the orchestrator service ORC and divided into DTi data blocks by the latter. When the personal security devices have reconstructed the descriptors by concatenating the DTi data blocks and decrypting the whole set, they reconstruct the view by interpreting the descriptor. For this purpose, a view reconstruction program from a descriptor is provided in each personal security device. Such a program occupies a much smaller memory space than that occupied by a conventional view generation program.

[0144] To illustrate, Figures 9A to 9K show examples of objects.

[0145] Lamontre an object of type "button" whose [TEXT] field is "Yes, Cancel" ("yes, delete") and whose [ACTION] field indicates that the challenge must be requested from the ORC orchestrator service (case of an action of type "delete" which has been accepted by the operator).

[0146] Lamontre an object of type "long press button" whose [TEXT] field is "Hold to Sign" ("long press to sign") and whose [ACTION] field indicates that the challenge must be requested from the orchestrator service (case of an action of type "sign a transaction" which has been accepted by the operator).

[0147] Shows a "text only" object whose [TEXT] field is "Whitelist creation canceled".

[0148] Lamontre an object of type "field value" ("Tag Value") whose [TEXT] field is "number of addresses", and whose [DATA] field contains here the value of a variable representing a number of addresses, here the value "24".

[0149] Lamontre shows an object of type "navigation bar" offering three options "cancel" "previous view" and "next view" and whose [ACTION] field defines three different actions corresponding to each of these options.

[0150] Shows an object of type "text bar with icon" whose [TEXT] field is "Removed addresses".

[0151] Shows an object of type "left button bar" whose [TEXT] field is "Whitelist edition" and whose [ACTION] field is "previous view".

[0152] Lamontre an object of type "page indicator bar" whose [TEXT] field is "of" and whose [DATA] field contains the variable "page number" (here "2") and the variable "number of pages" (here "14").

[0153] Shows an object of type "Split Button" whose [TEXT] field contains the words "Cancel" and "Skip" and whose [ACTION] field defines the two corresponding actions.

[0154] Shows an object of type "view" whose [TEXT] field is empty.

[0155] Shows a QR Code type object whose [TEXT] field is empty and whose [DATA] field contains the numeric value of the QR code.

[0156] To further clarify the ideas, Figures 10 and 11 show simplified examples of chained views that can be generated by the HSM1 module using the view structure just described.

[0157] Lamontre shows a view V01 that is chained to a final view V02 inviting the user to accept the removal of the invitation of a crypto-asset account manager administrator. View V01 is also chained to an intermediate view V03. View V03 is chained to a final view V03 inviting the user to make a decision about inviting this administrator.

[0158] Lamontre shows a view V05 relating to the edition of a new crypto-asset account administration rule, which is chained to an intermediate view V06 which indicates the majority and quorum rules for the adoption of this rule. The view V06 is chained to a final view V07 inviting the user to accept the administration rule.

[0159] Although described in the context of a system for the shared management of cryptoasset accounts, it will be clear to those skilled in the art that the method for managing approval processes according to the present disclosure is applicable to the management of any type of action approval process, in many fields of application where a decision can be taken by a group of people equipped with personal security devices. Similarly, the term "approval" is not, in light of the examples cited, limiting. In particular, this term does not only mean that a passive approval is sent by the requested personal security devices. An approval can also consist, as seen above, in contributing to the performance of an action, for example by sending data allowing the action subject to approval to be performed.Finally, the system architecture described above is subject to change as technologies evolve. In particular, it could be planned to have the ORC orchestrator program executed by the HSM1 hardware security module, or at least some of its functionalities, such as the transmission of views to personal security devices. In this case, the HSM1 hardware security module can be considered as the server running the orchestrator service, even if other functionalities of the orchestrator service are executed by a server separate from the hardware security module.

Claims

Method for managing an approval process of an action by at least one user (USR), in which the approval process of the action is associated with a series of views for the user, the method being implemented by means of a system comprising:- a hardware security module (HSM1, GOV), for governing the approval process and initiating the performance of the action after its approval by the user, and- a personal security device (PSDi) for displaying views of the series of views and receiving the approval of the user, method characterized in that it comprises the steps of:- providing an orchestrator service (ORC) executed by a server (SRV1),- by means of the hardware security module (HSM1), generating the series of views (Vi) of the approval process and communicating the series of views to the orchestrator service (ORC), and- by ​​means of the orchestrator service,provide (S11-S13) to the personal security device all or part of the views generated by the hardware security module (HSM1)., The method of claim 1, comprising the step of, by means of the orchestrator service, providing (S11-S13) to the personal security device a first view of the series of views, then one or more subsequent or previous views of the series of views, upon request (S16A) from the personal security device. Method according to one of claims 1 and 2, in which the provision of at least one view to the personal security device comprises the cutting (S10) of the view by the orchestrator service into a plurality of data blocks (DTi), the sending of each data block to the personal security device, and the reconstitution (S14) of the view by the personal security device when the plurality of data blocks have been received, by concatenation of the data blocks. Method according to one of claims 1 to 3, in which the hardware security module communicates each view (Vi) to the orchestrator service in an encrypted form (ENC(Vi, k)) with an encryption key (k) known to the personal security device but unknown to the orchestrator service. Method according to claim 4, comprising the steps of:- by means of the orchestrator service, cutting (S10) each view in its encrypted form and providing the personal security device with encrypted data blocks (DTi), and- by ​​means of the personal security device, concatenating the received encrypted data blocks and decrypting (S14) the bit string obtained, to reconstruct the view. Method according to one of claims 1 to 5, wherein the views are sent to the personal security device (PSDi) by the orchestrator service (ORC) via application protocol data units as defined by the ISO / IEC 7816-4 standard. Method according to one of claims 1 to 6, comprising a step of authenticating the personal security device by the hardware security module, the authentication step comprising the steps of: - by means of the hardware security module (GOV, HSM1), sending (S111-S113) a challenge to the personal security device, and - by means of the personal security device, generating (S20) a response (SIGN) to the challenge and sending it (S21-S23) to the hardware security module (GOV, HSM1). The method of claim 7, wherein the step of calculating and sending a response to the challenge is only performed if the user communicates to the personal security device his approval of the action to be performed. The method of claim 8, wherein the hardware security module is configured so that receipt (S30) of a valid challenge response constitutes user approval to perform the action. Method according to one of claims 7 to 9, wherein the challenge is sent to the personal security device as a fictitious view of the series of views, having a rank (N+1) higher than the rank (N) of the last view of the series of views. Method according to one of claims 7 to 9, wherein the challenge is sent to the personal security device together with a view, as data ([DATA]) linked to an element (OBi, OBj, OBk, OBl) located inside the view. Method according to one of claims 1 to 11, in which the personal security device (PSDi) is configured to, after having received the user's approval on the action to be carried out, send to the hardware security module (GOV, HSM1) all or part of a secret data item of the personal security device or a data item derived from this secret data item. Method according to one of claims 1 to 12, in which a view provided by the hardware security module (HSM1) consists of a description of the view according to a view structure, the description being transformed into a binary data string. Method according to claim 13, comprising:- a step of cutting (S10) the binary data string forming a description of the view into a plurality of data blocks (DTi),- sending each data block to the personal security device,- reconstitution (S14) of the description of the view by the personal security device when the plurality of data blocks has been received, by concatenation of the data blocks, and- reconstitution of the view by the personal security device, from the description of the view. Method according to one of claims 13 and 14, wherein the view structure comprises a plurality of objects (OBi, OBj, OBk, OBl). The method of claim 15, wherein the view structure comprises at least two main containers (CT1-CT3) each containing objects (OBi, OBj, OBk, OBl). Method according to one of claims 1 to 16, for the approval of cryptoasset account administration actions, said administration actions comprising at least one of the following actions: - approval of a transaction by means of a cryptoasset account, - approval of an action of generating a cryptoasset account master key, - approval of actions of acceptance or revocation of operators able to participate in cryptoasset account administration actions. System for managing a process of approval of an action by at least one user (USR), in which the process of approval of the action is associated with a series of views provided for the attention of the user, the system comprising:- a hardware security module (HSM1, GOV), for governing the approval process and initiating the performance of the action after its approval by the user, and- a personal security device (PSDi) for displaying views of the series of views and receiving the approval of the user,system characterized in that it comprises an orchestrator service (ORC) executed by a server (SRV1), in that:- the hardware security module (HSM1) is configured to generate the series of views (Vi) of the approval process and communicate the series of views to the orchestrator service (ORC),and- the orchestrator service is configured to provide (S11-S13) to the personal security device all or part of the views generated by the hardware security module (HSM1)., The system of claim 18, wherein the orchestrator service is configured to slice (S10) at least one view into a plurality of data blocks (DTi), and send the plurality of data blocks to the personal security device, the personal security device being configured to reconstruct (S14) the view when the plurality of data blocks have been received, by concatenating the data blocks. System according to one of claims 18 and 19, in which the hardware security module (HSM1) is configured to communicate each view (Vi) to the orchestrator service in an encrypted form (ENC(Vi, k)) with an encryption key (k) known to the personal security device (PSDi) but unknown to the orchestrator service. System according to one of claims 18 to 20 wherein the views are sent to the personal security device (PSDi) by the orchestrator service (ORC) via application protocol data units as defined by the ISO / IEC 7816-4 standard. System according to one of claims 18 to 21, in which a view provided by the hardware security module (HSM1) consists of a description of the view according to a determined view structure. The system of claim 22, wherein the view structure comprises a plurality of objects (OBi, OBj, OBk, OBl). System according to one of claims 18 to 23, configured for the approval of cryptoasset account administration actions, said administration actions comprising at least one of the following actions: - approval of a transaction by means of a cryptoasset account, - approval of an action of generating a cryptoasset account master key, - approval of actions of acceptance or revocation of operators able to participate in cryptoasset account administration actions.

Images