FR3156561A1 - Method for centralized management of at least one action approval process - Google Patents

Abstract

Method for managing an approval process of at least one 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 comprising the steps of, by means of a hardware security module (HSM1), generating the series of views of the approval process and communicating the series of views to an orchestrator service (ORC, SRV1); by means of the orchestrator service, providing all or part of the series of views to a personal security device (PSDi). Figure 3

Description

Method for centralized management of at least one action approval process

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

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.

There FIG. 1 schematically 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.

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 an appropriate 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.

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.

However, an exception to this rule is made in the case of shared management of crypto-asset accounts, in which a request to carry out a transaction on a crypto-asset account can only be executed after receiving the agreement of at least one approving user and satisfying a governance rule. As illustrated in the FIG. 2 , in this case, a transaction administration server SRV0 is provided coupled to 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 crypto-asset 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 (OP ₁ … OP _N ), for example a role of co-owner ("shared-owner"), administrator, transaction approver, etc. The server SRV0 hosts a transaction administration platform TPF allowing certain operators to request the commitment of actions.

It will be noted, in addition, that in order to ensure a very high degree of security for account holders 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.

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.

In the context of such shared management of crypto-asset accounts, an OPi operator generally includes 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.

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.

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.

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.

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.

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 needed to implement the approval process.

Summary

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.

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, at the request of the personal security device.

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.

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.

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.

According to one embodiment, the views are sent to the personal security device by the orchestrator service via smart card commands of the APDU type defined by the ISO/IEC 7816 standard.

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.

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.

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.

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.

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.

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 item.

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.

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.

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

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

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.

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 all or part of the views generated by the hardware security module.

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.

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.

According to one embodiment, the views are sent to the personal security device by the orchestrator service via smart card commands of the APDU type defined by the ISO/IEC 7816 standard.

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.

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

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

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:

- there FIG. 1 previously described schematically represents a classic system of non-mutualized management of crypto-asset accounts,

- there FIG. 2 previously described schematically represents a classic system for shared management of crypto-asset accounts,

- there FIG. 3 shows an embodiment of a system for the shared management of crypto-asset accounts allowing the implementation of the method,

- there FIG. 4 shows in more detail a personal safety device present in the system of the FIG. 3 ,

- there FIG. 5 is a sequence diagram describing steps in the action approval process management process,

- there FIG. 6 and the FIG. 6 describe the steps of the diagram of the FIG. 5 ,

- there FIG. 7 shows a view structure used in one embodiment of the method,

- there FIG. 8 shows a descriptor of a view made according to the view structure of the FIG. 7 ,

- there FIG. 9 , there FIG. 9 , there FIG. 9 , there FIG. 9 , there FIG. 9 , there FIG. 9 , there FIG. 9 , there FIG. 9 , there FIG. 9 , there FIG. 9 , there FIG. 9 , show examples of objects present in the view structure of the FIG. 7 ,

- there FIG. 10 shows a first example of a series of views associated with the performance of an action, and

- there FIG. 11 shows a second example of a series of views associated with performing an action.

Detailed description

There FIG. 3 shows the general architecture of a first embodiment of a system for shared management of cryptoasset accounts implementing the method for managing action approval processes according to the present disclosure.

The system includes a hardware security module HSM1, a server SRV1 and OPi operators (OP ₁ … 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.

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.

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 can 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 approver operators approve transactions initiated by themselves or other operators.

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.

In one embodiment shown in the FIG. 4 , 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 shared management system for crypto-asset accounts. Such an architecture is that, for example, of the Ledger Stax device, which is equipped with a touch screen 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 touch screen and a USB/Bluetooth communication interface (the microcontroller).

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.

Back to the FIG. 3 , 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.

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.

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.

The system can 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 K0 master key from master keys specific to co-owners, or an action to carry out a transaction. Each action is associated with a series of views necessary to implement the action approval process, intended to be displayed by the PSDi personal security devices at the user's discretion.

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.

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.

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 APDU (“Application Protocol Data Unit”) commands and responses of the type described by the ISO/IEC 7816 protocol for smart cards.

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.

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.

In the example implementation of the method described below, the following notations and values will be used:

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.

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.

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.

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.

There FIG. 5 is a sequence diagram that shows an example of carrying out the process in relation to the performance of an action that is approved here by sending a response to a previously received challenge, this response consisting here in the signing of the challenge. The steps represented on the FIG. 5 are detailed in Figures 6A, 6B and will be described in more detail below.

S01 - Exec Action Add

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.

S02 - Prepare Action Add

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.

S03 - k = ECDH (PSDi, HSM1)

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

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.

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.

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

At step S04, the governance service GOV prepares a set of views V1 to V _N necessary for the implementation of the approval process of the action Aj by the operator OPi. Furthermore, it generates a challenge using a random binary word generator.

S05 – ENC(V1,k), ENC(V2,k),... ENC(V _N ,k), ENC(CHALLENGE, k)

At step S05, the governance service GOV encrypts each view V1 to _VN 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 VN ₊₁ . The ENC encryption function used is for example the AES function or the AES-GCM function.

S06 – Send ENC(V1,k), ... ENC(V _N ,k), ENC(CHALLENGE,k)

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

S10 – CUT{ENC(Vi,k)} = DT1//DT2//DT3//..//DTn

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.

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

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.

S12 – SW1, SW2 = 9000

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.

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

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. The repetition of steps S11, S12 and S13 forms the loop “VIEWLOOP(Vi)”. When P1 is equal to 00, all data blocks DTi have been received and the personal security device PSDi exits the VIEWLOOP loop for the view Vi considered.

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

In a next 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.

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.

U10 – USR CHOICE

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 carry out 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, preferably with 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 in 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.

S15 – USR CHOICE = New Vi or REFUSED or AGREE?

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.

S16A – Next Action = [i, 9000]

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 user makes a final decision forms an “ACTIONLOOP(Ai)” loop for sending to the personal security device PSDi all the views of the series of views associated with the action Ai that have been requested by the user. It will be noted that some views of the series of views 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.

S16B – SW1, SW2 = REFUSE

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 means 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.

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

At step S16, the PSDi personal security device sends an APDU response to the ORC orchestrator service 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.

S110 – CUT{ENC(CHALLENGE,k)} = DT1//DT2//DT3//..//DTn

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.

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

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 including the P1 field which can be equal to 80 or 00.

S112 – SW1, SW2 = 9000

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

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

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 data blocks DT1 to DT _N have been received. The repetition of steps S111, S112 and S113 forms the “CHALOOP” loop. When P1 is equal to 00, all data blocks DTi have been received and the PSDi personal safety device exits the CHALOOP loop to go to a step S114.

S114 – CHALLENGE=DEC((DT1//DT2//DT3//..//DTn), k)

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.

In some embodiments the size of the challenge is small enough to form only a single 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.

S20 – SIGN=SIGN(CHALLENGE)dPi

At a step S20 ( FIG. 6 ), 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.

S21 – [SIGN, SW1, SW2]

At a step S21, the PSDi personal security device 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.

S22 - SW1, SW2 = 6100 or 9000?

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.

S23 – GET RESPONSE (00C0000000)

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.

S30 – Send {SIGN}

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

S31 – INITIATE Action Add

At a step S31, the governance service GOV of the HSM1 module, after having verified that the signature SIGN is valid using 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, receiving the agreement of a single user will not be sufficient to initiate the action Aj.

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.

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.

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.

In addition to these measures, according to one embodiment of the method, the views are designed according to a view structure which 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 FIG. 7 The view includes CT containers and OB objects. A CT container may include a plurality of OB objects but may also include another container itself including objects.

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.

Each view constructed according to this view structure is materialized in binary form by a descriptor consisting of the concatenation of container descriptors and descriptors of the objects contained in the containers. FIG. 8 shows, without limitation, an example of a descriptor of a CTi container containing objects OBi, OBj, OBk, OBl.

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 OBi object, contains for example:

- an object identification field [OBJECT],

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

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

- 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”,

- 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.

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.

To clarify, Figures 9A to 9K show examples of objects.

There FIG. 9 shows a "button" type object 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 a "delete" type action which has been accepted by the operator).

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

There FIG. 9 shows a "text only" object whose [TEXT] field is "Whitelist creation canceled".

There FIG. 9 shows an object of type "field value"("TagValue") whose [TEXT] field is "number of addresses", and whose [DATA] field here contains the value of a variable representing a number of addresses, here the value "24".

There FIG. 9 shows a "navigation bar" type object offering three options "cancel", "previous view" and "next view", and whose [ACTION] field defines three different actions corresponding to each of these options.

There FIG. 9 shows an object of type "text bar with icon" whose [TEXT] field is "Removed addresses".

There FIG. 9 shows an object of type "left button bar whose [TEXT] field is "Whitelist edition" and whose [ACTION] field is "previous view".

There FIG. 9 shows 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 "page number" (here "14").

There FIG. 9 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.

There FIG. 9 shows an object of type "view" whose [TEXT] field is empty.

There FIG. 9 shows a QR Code type object whose [TEXT] field is empty and whose [DATA] field contains the numeric value of the QR code.

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.

There FIG. 10 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.

There FIG. 11 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. View V06 is chained to a final view V07 inviting the user to accept the administration rule.

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 architecture of the system that has been described in the foregoing is likely to be modified with the evolution of technologies. In particular, it could be intended to have the ORC orchestrator program executed by the HSM1 hardware security module, or at least some of its functionality 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 functionality of the orchestrator service is executed by a server separate from the hardware security module.

Claims (24)

Method for managing an approval process for an action by at least one user (USR), in which 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 (HSM1, GOV), to govern the approval process and initiate the execution of the action after its approval by the user, and
- a personal security device (PSDi) to display views from the view series and receive user approval,
process characterized in that it comprises the steps consisting of:
- provide an orchestrator service (ORC) executed by a server (SRV1),
- using the Hardware Security Module (HSM1), generate the series of views (Vi) of the approval process and communicate the series of views to the orchestrating 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. A method according to claim 4, comprising the steps of:
- by means of the orchestrator service, cut (S10) each view in its encrypted form and provide the personal security device with encrypted data blocks (DTi), and
- using the personal security device, concatenate the received encrypted data blocks and decrypt (S14) the obtained bit string, to reconstruct the view. Method according to one of claims 1 to 5, in which the views are sent to the personal security device (PSDi) by the orchestrator service (ORC) via smart card commands of the APDU type defined by the ISO/IEC 7816 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), send (S111-S113) a challenge to the personal security device, and
- using the personal security device, generate (S20) a response (SIGN) to the challenge and send 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 the receipt (S30) of a valid challenge response has the value of approval by the user as to the performance of 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, in which the challenge is sent to the personal security device at the same time as 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 data 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. The method of 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,
- the reconstruction (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
- the reconstruction of the view by the personal security device, from the description of the view. Method according to one of claims 13 and 14, in which 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 administration actions of cryptoasset accounts, said administration actions comprising at least one of the following actions:
- approval of a transaction using a crypto-asset account,
- approval of an action to generate a crypto-asset account master key,
- the approval of actions of acceptance or revocation of operators able to participate in actions of administration of crypto-asset accounts. 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), to govern the approval process and initiate the execution of the action after its approval by the user, and
- a personal security device (PSDi) to display views from the view series and receive user approval,
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 view series (Vi) of the approval process and communicate the view series 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 in which the views are sent to the personal security device (PSDi) by the orchestrator service (ORC) via smart card commands of the APDU type defined by the ISO/IEC 7816 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 administration actions of cryptoasset accounts, said administration actions comprising at least one of the following actions:
- approval of a transaction using a crypto-asset account,
- approval of an action to generate a master key for a crypto-asset account,
- the approval of actions of acceptance or revocation of operators able to participate in actions of administration of crypto-asset accounts.