Method for centralized management of at least one action approval process

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

Title of the invention: Method for centralized management of at least one action approval process Technical field

[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 called "hardware wallets" or "personal security devices" PSDs ("Personal Security Devices") appeared, 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] [Fig.l] 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.

[0004] When the personal security device PSD is first put into service, it generates a master key KO from which it can subsequently derive private keys Kj of 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 support such as an engraved metal plate, which he 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) in French (https: / / fr.wikipedia.org / wiki / Hardware_Security_Module). It is generally the rule that the HSM does not store the user's private keys and only ensures the control of 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 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 [Fig.2], in this case, a transaction administration server SRVO is provided, coupled with a hardware security module HSMO having access to a memory MEM in which the master key KO is recorded, making it possible to generate the derived keys Kj of the crypto-asset accounts whose management is shared. The hardware security module HSMO executes a governance service GOV in which governance rules have been recorded, making it possible to assign roles to OPi operators (OPi... OPN), for example a role of co-owner ("shared-owner"), administrator, transaction approver, etc.The SRVO 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 HSMO hardware security module. The HSMO 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 HSMO module performs the requested action or initiates its execution. If this action is the execution of a transaction, the HSMO 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 personal security device PSDi which is connected to a host device HDVi. The host device HDVi allows the personal security device PSDi to be connected to the administration server SRVO and to the hardware security module HSMO.

[0010] In this type of application, performing actions generally requires USRi users to navigate pages, or "views," which are displayed on their PSDi personal security devices. Generally, each action that can be performed is associated with an action approval process and at least one governance rule. The action approval process is embodied 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 closes the approval process. When the final view is reached, the user is given the option to agree or not to agree to the action to be performed, for example by pressing an approval button or a rejection button.

[0011] Ultimately, as 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, the implementation of 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 allowing them to generate such views and link them together. Indeed, a personal security device generally comprises a secure element for executing such a program, and a microcontroller to ensure communications with the outside world. A secure element is a semiconductor chip comprising cryptographic calculation means and implementing various countermeasures aimed at countering attacks by fraudsters, 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] In addition, each update of the GOV governance service of the HSMO module involves updates of the PSDi personal security devices, so that they are capable of generating 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 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, at the request of the personal security device.

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

[0018] According to 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, cutting each view in 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] 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.

[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 the receipt of a valid challenge response has the value of approval by the user as to the performance of the action.

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

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

[0026] According to one embodiment, the personal security device is configured to, after receiving approval from the user 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.

[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 string of binary data.

[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 containing each of the objects.

[0031] According to one embodiment, the method is implemented for the approval of administration actions of cryptoasset accounts, said administration actions comprising at least one of the following actions: the approval of a transaction at 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 for 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.

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

[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 approval of actions administration of cryptoasset accounts, 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. 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 [Fig.l] previously described schematically represents a classic system non-mutualized management of crypto-asset accounts,

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

[0042] - [Fig.3] shows an embodiment of a shared management system of crypto-asset accounts enabling the implementation of the process,

[0043] - [Fig.4] shows in more detail a personal safety device present in the system of [Fig.3],

[0044] - [Fig.5] is a sequence diagram describing steps of the method of management of the action approval process,

[0045] - [Fig.6A] and [Fig.6B] describe the steps of the diagram of [Fig.5],

[0046] - [Fig.7] shows a view structure used in one embodiment of the process,

[0047] - [Fig.8] shows a descriptor of a view made according to the view structure of the [Fig.7],

[0048] - [Fig.9A], [Fig.9B], [Fig.9C], [Fig.9D], [Fig.9E], [Fig.9F], [Fig.9G], [Fig.9H], [Fig.91], [Fig.9J], [Fig.9K], show examples of objects present in the view structure of [Fig.7],

[0049] - [Fig. 10] shows a first example of a series of views associated with the realization of an action, and

[0050] - [Fig.l 1] shows a second example of a series of views associated with the realization carrying out an action. Detailed description

[0051] [Fig.3] 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 comprises a hardware security module HSM1, a server SRV1 and OPi operators (OPi... OPN). 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 the FIPS 140-2 level III standard.

[0053] OPi operators can connect to the SRV1 server via a secure data link httpsl. The SRV 1 server can connect to the HSM1 module via a secure data link https2. 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 KO and keys Kj derived from the master key KO 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 KO of the set of cryptoasset accounts, from master keys that are specific to them. 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 physical user USRi who can act on both the HDVi host device or the personal security device PSDi.

[0056] In an embodiment shown in [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 O AP 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).

[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 may be computing entities executed by personal computers or servers. These different types of operator devices may coexist in the system described herein.

[0058] Returning to [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 signature service. The SIGN1 signature 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 SRV 1 server but could also be executed by any other server or device associated with the system.

[0059] The MEM memory receiving the master key KO 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, dHl, a public key, respectively PPi, PHI, and a certificate, respectively CPi, CH1. The certificate CPi or CH1 comprises the public key PPi or PHI 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 can be configured to allow various types of actions, such as actions for integrating or excluding operators, for example approvers, co-owners, or administrators, an action for generating a KO master key from master keys specific to co-owners, or an action for carrying out a transaction. Each action is associated with a series of views necessary for implementing the action approval process, intended to be displayed by the PSDi personal security devices at the user's discretion.

[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 of a determined 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 they 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 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 KO master key may result in the provision to the hardware security module, by each personal security device requested, of data enabling this KO master key 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 KO master key.

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

[0065] It will be recalled here that an APDU command includes a four-byte header CLA (Class), INS (Instruction), PI, P2, and a variable-length conditional body that includes fields [Le field] [Data field] [Le field]. The number of bytes present in the data field of an APDU command is indicated by the Le 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 "trader", of two bytes SW1, SW2.

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

[0068] SW1,SW2 = 9000: sending an APDU response comprising 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] PI = 80(MORE) or 00 (END): When the PI 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 PI 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 are equal to 6100, it means that the data in the response data field is not complete and more data must be sent to make the response complete. When the bytes are equal to 9000, it means that all the data has been sent.

[0071] GET RESPONSE: The GET RESPONSE command is for example sent 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 them 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] [Fig. 5] is a sequence diagram showing an exemplary embodiment of the method in relation to performing an action that is approved here by sending a response to a previously received challenge, this response here consisting of signing the challenge. The steps shown in [Fig. 5] are detailed in Figures 6A, 6B and will be described in more detail in the following.

[0073] SOI - Exec Action Add

[0074] At an SOI step, 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 - Prepared Action Add

[0076] At a 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. It will be assumed in the following, for the sake of simplification of the presentation, that the agreement of a single OPI operator, equipped with a PSDi personal security device, must be required here. However, the steps which are described in the following can be performed at the same time 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 device PSDi, 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) hashing algorithm on 256 bits. The authentication of the PSDi device and the HSM1 module is done using 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 [Vl,V2,...VN]Aj; GEN CHALLENGE

[0082] At a step S04, the governance service GOV prepares a set of views VI to VN necessary for the implementation of the approval process of the action Aj by the operator OPi. Furthermore, it generates a challenge by means of a random binary word generator.

[0083] S05 - ENC(Vl,k), ENC(V2,k),... ENC(VN,k), ENC(CHALLENGE, k)

[0084] At a step S05, the governance service GOV encrypts each view VI 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+i- The ENC encryption function used is for example the AES function or the AES-GCM function.

[0085] S06 - Send ENC(Vl,k),... ENC(VN,k), ENC(CHALLENGE,k)

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

[0087] S10 - CUT{ENC(Vi,k)} = DTl / / DT2 / / DT3 / / .. / / DTn

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

[0089] Sll-[DTi,Pl] (i = 1-m)

[0090] At a step SI 1, 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 VI of the series of views. The orchestrator service ORC sends to the personal security device PSDi the first data block DTI of the set of data blocks DTi resulting from the division of the encrypted view Vi during the first execution of step SI 1, then the following data blocks during the following iterations. Each data block DTi is sent in an APDU command including the PI field which can be equal to 80 or 00 as seen above.

[0091] S12 - SW1, SW2 = 9000

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

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

[0094] In a step S13, the personal security device PSDi determines whether the PI field is equal to 80 or 00. If PI is equal to 80, the personal security device PSDi repeats step S1 1 to receive a new data block DTi, and so on until all the data blocks DTI to DTN have been received. The repetition of steps S1 1, S12 and S13 forms the loop “VIEWLOOP(Vi)”. When PI is equal to 00, all the data blocks DTi have been received and the personal security device PSDi exits the VIEWLOOP loop for the view Vi considered.

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

[0096] In a following 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 DTI data block. In this case, step S10 is not performed, step SU is executed only once for sending the single data block, and step S14 only includes the operation decryption of 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 which 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 agreement on carrying 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 password phrase, 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 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 device PSDi goes to a step S16A. If the user refuses the action (“REFUSE”), the device PSDi goes to a step S16B. If the user agrees to perform the action (“AGREE”), the device PSDi goes to a step S16C.

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

[0103] In step S16A, the personal security device PSDi determines what is 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 of the steps S14, U10 and S15 until the final decision of the user forms a loop "ACTIONLOOP(Ai)" of 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 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 = REFUSED

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

[0106] S16C - Next Action = [N+l, 9000]

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

[0108] IF 10 - CUT{ENC(CHALLENGE,k)} = DTl / / DT2 / / DT3 / / .. / / DTn

[0109] At a step S1 10, 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 DTI, DT2... DTn, or “chunks” of the encrypted challenge. In the present embodiment, the encrypted challenge is in fact processed in the same way as a view, in accordance with what has been indicated regarding step S16C.

[0110] Slll - [DTi, PI] (i = 1—>n)

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

[0112] S112-SW1, SW2 = 9000

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

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

[0115] At a step SI 13, the PSDi device determines whether the PI field is equal to 80 or 00. If PI is equal to 80, the PSDi device repeats step SI 1 to receive a new data block DTi of rank i=i+1, and so on until all the blocks of DTI to DTN data have been received. Repeating steps SI 11, SI 12 and SI 13 forms the “CHALOOP” loop. When PI is equal to 00, all DTi data blocks have been received and the PSDi personal safety device exits the CHALOOP loop to go to step SI 14.

[0116] SI 14 - CHALLENGE=DEC((DTl / / DT2 / / DT3 / / .. / / DTn), k)

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

[0118] In certain embodiments the size of the challenge is sufficiently small to form only a single DTI data block. In this case step SI 10 is not performed, step SI 11 is executed only once and step SI 14 only comprises the operation of decrypting the single data block.

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

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

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

[0122] At a step S21, the personal security device PSDi sends an APDU response comprising 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 appearing 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 a 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 a step S23. If SW1, SW2 is equal to 9000, the ORC orchestrator service goes to a step S30.

[0125] S23 - GET RESPONSE (00C0000000)

[0126] In step S23, the ORC orchestrator service sends to the PSDi device the GET RESPONSE command coded “00C0000000”, 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, by means of responses to GET RESPONSE commands.

[0127] S30 - Send {SIGN}

[0128] At a step S30, the orchestrator service ORC has received the entire signature SIGN and send it to the GOV governance service 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 which has just been 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 the PSDi personal security devices of the need to generate the views necessary for conducting the action approval process. The personal security devices now only fulfill a passive function of displaying and collecting the operators' actions.

[0134] In addition to these measures, according to an embodiment of the method, the views are designed according to a view structure which considerably reduces their size 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 [Fig.7]. 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 comprises a top container CTI, a middle container CT2 and a bottom container CT3. In this example, the container CTI receives objects OBI and OB10, the container CT2 receives objects OB7, OB8 and the object OB10, the 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. [Fig.8] shows, without limitation, an example of a descriptor of a container CTi containing objects OBi, OBj, OBk, OBI.

[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 it is possible to place data. 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 that 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 that indicates an action to be performed if the user exerts pressure on 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 can in some cases be displayed alongside text 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 makes it possible to obtain 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 reconstituted the descriptors by concatenating the DTi data blocks and decrypting the whole, they reconstitute 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 memory space much smaller than that occupied by a conventional view generation program.

[0144] To clarify the ideas, Figures 9A to 9K show examples of objects.

[0145] [Fig.9A] shows 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 a “delete” type action which has been accepted by the operator).

[0146] [Fig.9B] shows an object of the “long press button” type 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).

[0147] [Fig.9C] shows a “text only” type object whose [TEXT] field is “Whitelist creation canceled”.

[0148] [Fig.9D] shows an object of type “field value” (“Tag Value”) whose field [TEXT] is “number of addresses”, and whose field [DATA] here contains the value of a variable representing a number of addresses, here the value “24”.

[0149] [Fig.9E] 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] [Fig.9F] shows an object of type “text bar with icon” whose [TEXT] field is “Removed addresses”.

[0151] [Fig.9G] shows an object of type “left button bar” whose [TEXT] field is “Whitelist edition” and whose [ACTION] field is “previous view”.

[0152] [Fig.9H] 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”).

[0153] [Fig.91] 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] [Fig.9J] shows an object of type “view” whose [TEXT] field is empty.

[0155] [Fig.9K] shows a QR Code type object whose [TEXT] field is empty and whose [DATA] field contains the numerical value of the QR code.

[0156] Still to fix the ideas, figures 10 and 11 show simplified examples of chained views which can be generated by the HSM1 module by means of the view structure which has just been described.

[0157] [Fig. 10] shows a view V01 which is chained to a final view V02 inviting the user to accept the deletion 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] [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.

[0159] Although having been 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 numerous 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

Claims

1. 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 (S 11-S 13) to the personal security device all or part of the views generated by the hardware security module (HSM1).,

2. A method according to claim 1, comprising the step of, by means of the orchestrator service, providing (S 11-S 13) 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.

3. Method according to one of claims 1 and 2, wherein the provision of at least one view to the personal security device comprises the cutting (S 10) 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 (S 14) of the view by the personal security device when the plurality of data blocks have been received, by concatenating the data blocks.

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

5. Method according to claim 4, comprising the steps of: - by means of the orchestrator service, cutting (S 10) each view in its encrypted form and provide the personal security device with encrypted data blocks (DTi), and - by means of the personal security device, concatenate the received encrypted data blocks and decrypt (S 14) the resulting bit string, to reconstruct the view.

6. Method according to one of claims 1 to 5, in which the views are sent to the personal security device (PSDi) by the or-chestrator service (ORC) via smart card commands of the APDU type defined by the ISO / IEC 7816 standard.

7. 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 (S11-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).

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

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

10. Method according to one of claims 7 to 9, in which 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.

11. 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, OBI) located inside the view.

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

13. 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 string of binary data.

14. Method according to claim 13, comprising: - a step of cutting (S 10) 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, - reconstituting (S 14) the description of the view by the personal security device when the plurality of data blocks has been received, by concatenating the data blocks, and - reconstituting the view by the personal security device, from the description of the view.

15. Method according to one of claims 13 and 14, wherein the view structure comprises a plurality of objects (OBi, OBj, OBk, OBI).

16. The method of claim 15, wherein the view structure comprises at least two main containers (CT1-CT3) each containing objects (OBi, OBj, OBk, OBI).

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

18. 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 performance of the action after its approval by the user, and - a personal security device (PSDi) to display views of the series of views 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 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 (SI 1-S13) to the personal security device all or part of the views generated by the hardware security module (HSM1).

19. The system of claim 18, wherein the orchestrator service is configured to slice (S 10) 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 (S 14) the view when the plurality of data blocks have been received, by concatenating the data blocks.

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

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

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

23. The system of claim 22, wherein the view structure comprises a plurality of objects (OBi, OBj, OBk, OBI).

24. 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: - 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 active.

Images