System and method for managing access rights and authorizations

Abstract

Device and Method for Managing Access Rights and Authorizations This description concerns a method for managing access to the use of an automated system, comprising: - providing an identification value, associated with a user, to a first device; - generating, via a secure circuit of the first device, an account address based on a master key associated with the first device, the identification value, and a context value; - sending a transaction to the account address in a blockchain; - validating or invalidating the transaction, by the blockchain, based on the balance associated with the account address in the blockchain; and - if the transaction is validated by the blockchain, authorizing the first device to grant the user access to the automated system. Figure for the abstract: Fig. 8

Description

Title of the invention: Device and method for managing access rights and authorizations. Technical field

[0001] This description relates generally to the management of access rights and authorizations of a user to a device or equipment. Previous technique

[0002] An industrial site typically includes several pieces of equipment, such as automated systems and doors, access to which must be controlled, as well as authorizations to perform one or more operations and / or actions. In particular, this equipment is, for example, supplied by a vendor and used by users such as service providers or subcontractors. Generally, users of the industrial site's equipment come from different entities. Furthermore, the industrial site operator may want a user to have access to only certain equipment and, for example, only during a specific time period. The operator may also want another user to have access to other equipment, or to the same equipment but during a different time period. Access authorization to the industrial site's equipment is generally managed using electronic elements and / or components.It is important that the operator of the industrial site has the ability to manage access rights to equipment, and for example to add a certain degree of temporal granularity.

[0003] Since the equipment is used by users from several entities, it is important to keep track, or maintain a history, of equipment usage. Indeed, if the equipment malfunctions, causing an incident for example, it is important to be able to trace the individual or organization responsible for the malfunction. For example, a malfunction could result from incorrect equipment settings, improper handling, incorrect training, etc.

[0004] It is therefore important that, in the event of a malfunction, an audit by an authorized person allows for tracing the history of users who have operated the defective equipment. However, for data protection purposes, it is equally important that this history, as well as the data related to each user, not be accessible by unauthorized third parties. In particular, it is important that the operator of the industrial site, the equipment suppliers, the various entities employing the users, and any person with access, for example to a server where the history logs are stored, do not have access to the data. related to the different users. There is therefore a need for a solution to achieve these objectives, which present a technical problem. Summary of the invention

[0005] One embodiment provides for a method of managing, by a first device, access to the use of an automated system by a user, the method comprising: - the provision of an identification value, associated with the user, to the first device; - the generation, by a secure circuit of the first device, of an account address based on a master key associated with the first device, the identification value and a context value; - sending a transaction, including a cost value, to the account address in a blockchain; - the validation or invalidation of the transaction, by the blockchain, based on the balance associated with the account address in the blockchain and the cost value; and - if the transaction is validated by the blockchain, the authorization, by the first device, of access to the use of the machine for the user.

[0006] According to one embodiment, authorization to access the use of the automated system includes activation of the automated system by the first device.

[0007] According to one embodiment, the transaction is validated by the blockchain when the balance associated with the account address is greater than or equal to the cost value.

[0008] According to one embodiment, the transaction is an account-to-account transaction or a transaction to a smart contract.

[0009] According to one embodiment, the generation of the account address includes: - the generation of a first key by deriving, by application by the secure circuit, a key derivation function associated with the BitCoin Improvement Proposal 32 standard of the master key according to a first index path; - the generation of a first public key by multiplying a first part of the leaf key with a generating point of the elliptic curve associated with the cryptographic system of the BitCoin Improvement Proposal 32 standard; and - generating the account address by applying a hash function to the leaf public key.

[0010] According to one embodiment, the derivation of the master key along the first index path comprises: - the application of a first index value by the differentiation function, the first index value being a constant value; and - following the application of the first index value, the application of a second index value, a third index value, and a fourth index value, the the second and third index values ​​being dependent on the identification value associated with the user and the fourth index value corresponding to the contextual value.

[0011] According to one embodiment, the second index value corresponds to the 31 least significant bits of the identification value and the third index value corresponds to the 31 most significant bits of the identification value.

[0012] According to one embodiment, the master key is a value on 2N bytes, the first key is a value on 2N bytes, and the first part of the first key corresponds to the first N bytes of the first key, N being an integer.

[0013] According to one embodiment, the context value corresponds to a date encoding of at least one day on which access to the use of the first device is authorized for the user.

[0014] According to one embodiment, the context value further includes an encoding of a time range or a geographical location associated with the first device.

[0015] According to one embodiment, the above method further comprises providing, via an external device, at least one credit to the account address in the blockchain by: - the provision, by the first device, of a second public key and a code string associated with the first device; - the generation of the account address, by the external device, based on the second public key and the code string; and - the provision of at least one credit on the account address in the blockchain.

[0016] According to one embodiment, the second public key corresponds to a first part of a second key, the second key being obtained by the first device by derivation of the master key according to the first index value, and wherein the external device is configured to generate the account address on the basis of a key derivation, on the basis of the second public key and the code string and on the basis of the second, third and fourth index values.

[0017] According to one embodiment, the provision of the identification value to the first device is carried out by the user, by presenting a user device in which the identification value is stored, the provision being carried out by near field communication between the user device and the first device.

[0018] One embodiment provides a first device comprising a secure circuit in which a seed value is stored, the first device being configured to, following the provision of an identification value by a user: - generate an account address based on a master key associated with the first device, the identification value and a context value; - send a transaction, including a cost value, to the account address in a blockchain; and - if the transaction is validated by the blockchain, allow the user access to use an automated system.

[0019] One embodiment provides a system comprising: - the first device above; - a blockchain configured to validate or invalidate the transaction sent by the first device, based on the balance associated with the account address in the blockchain and the cost value; and - an external device, configured to generate the account address based on a second public key and the code string, provided by the first device, the identification value and a context value and to provision at least one credit on the account balance at the account address in the blockchain.

[0020] According to one embodiment, the account address is generated by applying a key derivation function associated with the BitCoin Improvement Proposal32 standard. Brief description of the drawings

[0021] These features and advantages, as well as others, will be described in detail in the following description of particular embodiments, given by way of non-limiting example, in relation to the accompanying figures, among which:

[0022] [Fig.1] is a diagram illustrating an access system comprising different users having access rights on an automated system at an industrial site;

[0023] [Fig.2] is a representation, in the form of different layers, of the operation of the digital blockchain technology;

[0024] [Fig.3] represents a user device and an equipment device configured for the implementation of an access authorization process, according to an embodiment of the present description;

[0025] [Fig.4] illustrates the authentication of a user with a piece of equipment, according to one embodiment of the present description;

[0026] [Fig.5] illustrates a hierarchical key derivation structure according to the BIP32 standard;

[0027] [Fig.6] illustrates the generation of an anonymized authentication value for a user, according to one embodiment of the present description;

[0028] [Fig.7] illustrates an exchange between a device used by an operator of the industrial site and the equipment device, according to an embodiment of the present description;

[0029] Figure 8 illustrates the generation, by the device used by the operator, of a anonymized authentication value, according to an embodiment of this description; and

[0030] [Fig.9] illustrates the generation of the same anonymized authentication value, by the device used by the operator and by the equipment device, according to an embodiment of the present description. Description of the implementation methods

[0031] The same elements have been designated by the same reference numerals in the different figures. In particular, the structural and / or functional elements common to the different embodiments may have the same reference numerals and may have identical structural, dimensional and material properties.

[0032] For the sake of clarity, only the steps and elements useful for understanding the described embodiments have been shown and are detailed. In particular, blockchain technology, key derivation processes, and the BIP32 standard (from the English "Bitcoin Improvement Proposal 32") are known to those skilled in the art and are not described in detail.

[0033] Unless otherwise specified, when referring to two elements connected together, this means directly connected without intermediate elements other than conductors, and when referring to two elements connected (in English "coupled") together, this means that these two elements can be connected or linked through one or more other elements.

[0034] In the following description, when reference is made to absolute position qualifiers, such as the terms "front", "back", "top", "bottom", "left", "right", etc., or relative position qualifiers, such as the terms "above", "below", "superior", "inferior", etc., or to orientation qualifiers, such as the terms "horizontal", "vertical", etc., reference is made, unless otherwise specified, to the orientation of the figures.

[0035] Unless otherwise specified, the expressions "approximately", "roughly", and "on the order of" mean to within 10% or 10°, preferably to within 5% or 5°.

[0036] Figure 1 is a diagram illustrating an access system comprising different users 102, 104, and 106 with access rights to a PLC 108 at an industrial site. Users 102, 104, and 106 are, for example, employees of the same or different companies working at the industrial site. In particular, users 102, 104, and 106 each possess a user device 110, 112, and 114, respectively. For example, user devices 110, 112, and 114 are badges provided by an operator of the industrial site. For example, user devices 110, 112, and 114 grant access to users 102, 104, and 106, respectively. and 106 for the use of the PLC 108. The use of the PLC includes, for example, activating the PLC 108 to unlock a door, supply power to a machine or other type of electronic circuit, deactivate an intrusion alarm system, etc. As an example, the PLC 108 is an actuator that allows a door to be opened or an industrial machine to be operated. The user devices 110, 112, and 114 each include, for example, a Near Field Communication (NFC) circuit.

[0037] The PLC 108 includes, or is connected to, one or more equipment devices 116. In particular, the equipment device 116 includes a near-field communication circuit. The equipment device 116 is further configured to activate or control the PLC 108, for example, via control signals. The industrial site includes, for example, a plurality of PLCs. Each PLC then includes, or is connected to, one or more equipment devices 116.

[0038] In order to use the PLC 108, each user 102, 104, or 106 identifies themselves to the device 116 via their user device 110, 112, or 114. The equipment device 116 is then configured to authorize or deny the use of the PLC 108, based on this identification. For example, the equipment device 116, or the PLC 108, includes a timer or stopwatch (not shown). For example, when the equipment device 116 authorizes a user to access the PLC 108, the timer is started. When the counter reaches a threshold duration, on the order of one or more hours, the equipment device 116 is configured to refuse access to the automaton 108 so that the user 102 no longer has access to it, or can no longer manipulate it.

[0039]

[0040] According to one embodiment, the device equipment 116 is configured to perform a transaction, based on identification, to a blockchain 118, implemented, for example, by a remote server connected to the device equipment 116 via a wired and / or wireless network. By way of example, the blockchain is a so-called public blockchain, for example accessible from the internet, such as Bitcoin or Ethereum blockchains. In other examples, the blockchain is a consortium blockchain or a private blockchain.

[0041] Fig. 2 is a representation, in the form of different layers, of the operation of the digital blockchain technology.

[0042] A layer 200 represents the peer-to-peer network. Each block 201 represents a node of the network, for example, a machine. The machines exchange information among themselves in a distributed manner. In particular, in a blockchain, there is no From the central server, the information is replicated on each machine. As an example, each device (equipment 116) constitutes a node for the blockchain (118).

[0043] A 202 layer represents a blockchain consensus protocol. The purpose of this layer is to grant consensus among the machines. The consensus protocol allows the machines to agree on the information they store in a shared and replicated ledger. The security of the protocol is implemented, for example, by a "coin," such as a cryptocurrency for permissionless blockchains or fuel for permissioned blockchains.

[0044] An optional layer 204 represents the execution of smart contracts. Smart contracts are computer code executed in a distributed manner by all nodes participating in the consensus mechanism. The execution of smart contracts is such that the result of the operations performed by each node achieves consensus among a majority of nodes to be validated. Smart contracts are, for example, further configured to encode fungible or non-fungible tokens. For example, fungible tokens are encoded by smart contracts such as ERC20 (Ethereum Request for Comment). For example, non-fungible tokens are encoded by smart contracts such as ERC721 (Ethereum Request for Comment). Both ERC20 and ERC721 smart contracts are implemented on the Ethereum blockchain network.Other examples exist and are known to those in the field. Tokens constitute a currency of exchange within a single community on a blockchain.

[0045] A layer 206 represents distributed applications developed to use the system resulting from layers 200, 202, and optionally 204. These applications allow transactions to be sent to the blockchain, either to activate a function of a smart contract or to transfer credits directly to layer 200. When a transaction is made to a smart contract or when credits are transferred from one user's account on the blockchain to another, it is ensured, for example, that the sender's account balance is positive and contains credits. A transaction to a smart contract requires payment of the smart contract's execution cost; this cost is called "gas" and is generally paid in credits.

[0046] Figure 3 shows the user device 110 and the equipment device 116 configured to implement a method for authorizing access to the use of the PLC 108 of Figure 1, according to an embodiment of this description. The device 110 includes an identification value (UID), for example stored in non-volatile memory within the user device 110. The value The identification value of a user device is unique; that is, two different user devices each contain a different identification value. For example, user device 110 is provided to a user, such as a worker on the industrial site, by the industrial site operator. The identification value of user device 110 is therefore known to the industrial site operator. For example, the identification value is stored in user device 110 in unencrypted form. For example, the identification value is a value encoded on at least 31 bits. In another example, the identification value is a value encoded on fewer than 31 bits.

[0047] The equipment device 116 includes a secure circuit 304 comprising non-volatile memory in which a seed value is stored. The seed value is a secret value provisioned in the circuit 304, for example, by the supplier of the equipment device 116. This value is, in particular, not known by the operator of the industrial site or by the user 102. The secure circuit 304 includes, for example, a cryptographic circuit 306 (CRYPTO) configured for key derivation. According to one embodiment, the cryptographic circuit is configured to derive keys according to the BIP32 standard.

[0048] Fig. 4 illustrates the authentication of user 102 with the equipment device 116, associated with the automaton 108, according to an embodiment of the present description.

[0049] According to one embodiment, when user 102 authenticates itself, via user device 110, to equipment device 116, secure circuit 304 is configured to generate an account address (@ACCOUNT GENERATION) based on the identification value and the seed value. This generation is performed, for example, by cryptographic circuit 306. The secure circuit is then configured to send a transaction (TRANSACTION) to the blockchain 118. The transaction is then recorded in the blockchain 118 when the balance associated with the account address is positive. When the transition is recorded, the equipment device 116 is configured to allow the use of the automaton 108 by user 102. In the case where the balance associated with the account address is zero, the transaction is refused by the blockchain 118 and the equipment device 116 refuses the use of the automaton 108 by user 102..

[0050] According to one embodiment of the present description, consultation of the blockchain 118 by a third party does not allow the latter to trace back to the user 110, nor to trace back to the equipment device 116, nor to trace the actions carried out by the user 110 on the automaton 108. The user 110 then acts in an anonymized manner on a digital system associated with the industrial site.

[0051] According to one embodiment, in order to give access rights to user 110, the operator of the industrial site is able to construct the account address, based on the identification value and a public key provided by the equipment device 116. The operator of the industrial site is then able to provision the balance of the account at the account address in the blockchain 118, so that user 110 can act on the automaton 108.

[0052] Figure 5 illustrates a hierarchical key derivation structure according to the standard BIP32. In particular, the key derivation illustrated in [Fig. 5] is performed by the cryptographic circuit 306 and results in the account address. Specifically, an anonymized user authenticator 110 consists of the account address sending to the blockchain 118. In particular, the account address is constructed using a deterministic hierarchical wallet structure, introduced in the BIP32 standard.

[0053] The seed value (SEED) is used to generate a master key (MASTER). The master key is also a secret value, stored in the 304 circuit. In particular, the master key cannot be extracted from the secure 304 circuit. The seed value and the master key are, for example, values ​​encoded on 2N bytes, where N is an integer, for example, 32. A key derivation function is then applied to the master key. The key derivation function is applied to the master key based on an index path. The index path consists of several index values. Each index value corresponds to a derivation at one level. As an example, the index values ​​are N-bit values ​​less than or equal to 2^-1-

[0054] By way of example, in a first level (LEVEL 1), a first index value (IDX[1]) is applied to the master key. Depending on the value of the first index value, several derived key values ​​are obtained. For example, a key KEY[1][0] is obtained when the first index value is equal to a first value. Another key KEY[1][1] is obtained when the first index value is equal to a second value (IDX[1]=1). For an n+1 number of values ​​that can be taken by the first index value (IDX[1]=0,..., IDX[1]=n), an n+1 number of keys (KEY[1][0],..., KEY[1][n]) are obtained. For example, for a seed value and a 64-byte master key, the derived key values ​​are also 64 bytes.

[0055] By way of example, in a second level (LEVEL 2), a second index value (IDX[2]) is applied to the derived keys at the first level. Depending on the value of the second index value, several derived key values ​​are obtained. For example, for each of the derived keys KEY[1][j], 0 < j < H, a key KEY[j][2][0] is obtained when the second index value is equal to a first value IDX[2]=0. For each of the derived keys KEY[1][j], 0 < j < II, a key KEY[j][2][l] is obtained when the second index value is equal to a second value IDX[2]=1. For a number n+1 of possible values ​​for the second index value (IDX[2]=0, IDX[2]=n), a number (n+1) of keys is obtained from the n+1 derived key values ​​at the first level. As an example, the derived key values ​​at the second level are also 64 bytes long.

[0056] The keys are successively derived, up to a level K (LEVEL K), to which a K-th index value (IDX[K]) is applied. For example, the K-th index value can take n+1 different values ​​(IDX[K]=0,..., IDX[K]=n), and each key derived at the K-th level is therefore differentiable into n+1 new keys at the K-th level. In particular, each key at the K-th level is differentiable from the master key via a unique derivation path. A derivation path then corresponds to the sequence, or line, comprising the index values ​​used to obtain said key at the K-th level.

[0057] According to one embodiment, the account address is generated by the cryptographic circuit 306 during the identification of user 102 via user device 110 by applying a derivation path to the master key constructed from the seed value. For example, the account address is obtained by derivation of the master key. The first derivation is performed based on a constant index value, less than or equal to 231, for example, the OxCAFE value, or any other value. The resulting key is then a level 1 key and is equal to the derivation along the index path master / OxCAFE, where the symbol / denotes the derivation and where master corresponds to the value of the master key. A second-level derivation is performed based on an index value dependent on the identification value of user device 110.For example, at the second derivation level, the index value used corresponds to the 31 least significant bits (UID(LSB)) of the identification value. The index path is then equal to master / 0xCAFE / UID(LSB). As an example, at the third derivation level, the index value used corresponds to the 31 most significant bits (UID(MSB)) of the identification value. The index path is then equal to master / OxCAFE / UID(LSB) / UID(MSB). In cases where the length of the identification value is less than 31 bits, the 31 most significant bits are conventionally all equal to 0. At the fourth derivation level, the index value for the derivation includes contextual information.As an example, the index value used on the fourth level corresponds to today's date, for example in a DDMMYYYY format concatenating today's date, month and year, the date corresponding to the date for which the industrial site operator wishes to authorize access to the PLC 108 to user 102. The key derived on the fourth level is then, for example, derived. according to the path master / OxCAFE / UID(LSB) / UID(MSB) / DDMMYYYY. In other examples, the index value used at the fourth level incorporates a finer or broader temporal granularity than simply the day month year format. For example, the index value used at the fourth level incorporates a time range for a given date. In this case, the industrial site operator wants user 102 to have access to PLC 108 only during this time range. In another example, the index value used at the fourth level corresponds to the concatenation of several days. In this case, the industrial site operator wants, for example, user 102 to have access to PLC 108 for several consecutive days.

[0058] By way of example, and optionally, an additional derivation is carried out on a fifth level. By way of example, this additional derivation is carried out on the basis of an index value including additional contextual information, such as, for example, location coordinates, such as GPS (Global Positioning System) coordinates, of the industrial site or of the PLC 108. The key resulting from the application of the index path on the four or five levels is hereinafter referred to as the leaf key.

[0059] The leaf key is, for example, a 2N byte key, for example 64 bytes. The first N bytes of the leaf key correspond, for example, to a private key, hereinafter referred to as the leaf private key (LEAF_SK). The last N bytes correspond, for example, to a chain code, hereinafter referred to as the leaf chain code.

[0060] A public key, hereinafter referred to as the leaf public key (LEAF_PK) and associated with the leaf private key, corresponds to the multiplication in an elliptic curve cryptographic system between the leaf private key and the generator point of the cryptographic system. In particular, the cryptographic system is the elliptic curve system known to those skilled in the art as secp256kl.

[0061] The account address, hereinafter referred to as the leaf account address, is then obtained by hashing the leaf public key. For example, when the 118 blockchain is an Ethereum blockchain, the leaf account address corresponds to the 20 least significant bytes of the output of a hash function taking the leaf public key as input. For example, the hash function used is the one known to those skilled in the art as keccak256. In another example, when the 118 blockchain is of the Bitcoin type, the leaf account address is constructed as the output of the hash function known as H160 taking the leaf public key as input, to which a base-58 encoding is applied followed by the addition of a Cyclic Redundancy Check (CRC) code.

[0062] Figure 6 illustrates the generation of an anonymized authentication value for a user, according to one embodiment of this description. In particular, the anonymized authentication value corresponds to the leaf account address generated by the secure 304 circuit, more specifically the cryptographic 306 circuit, as described in relation to Figure 5. In particular, the index path used for generating the leaf key is, for example, master / OxCAFE / UID(LSB) / UID(MSB) / DDMMYYYY. In other examples, the first index is equal to a constant less than 231, different from OxCAFE. By way of example, the first index value comprises hexadecimal characters. By way of example, the fourth index value comprises a finer or coarser granularity than a date in DDMMYYYY format, and includes, for example, a time range.As an example, the index path includes a fifth index, comprising an additional contextual indication, for example the GPS coordinates of the industrial site, or of the PLC 108.

[0063] The leaflet account address is then used by the equipment device 116 to send a transaction on the blockchain 118. According to the blockchain 118 technology, the transaction is, for example, an account-to-account value transaction or a smart contract transaction. The transaction requires, for example, that the sender's balance, i.e., the leaflet account, be positive. In particular, the transaction sent to the leaflet account address in the blockchain 118 includes an indication of a cost value. If the leaflet account balance has enough credit to pay the cost value, and gas if necessary, the transaction is validated by the blockchain 118; otherwise, it is rejected.

[0064] According to one embodiment, the operator of the industrial site is able to credit the account addresses of the various users interacting with the site. In order to guarantee the anonymity of actions, the operator of the industrial site is able to construct the leaflet account addresses of the various users in order to credit them.

[0065] Figure 7 illustrates an exchange between a device used by an operator of the industrial site and the equipment device 116, according to an embodiment of this description. In particular, the industrial site operator does not have access to the seed value contained in the secure circuit 304 and therefore cannot directly generate the anonymized authenticator. Indeed, the seed value cannot be extracted from the secure circuit 304. Furthermore, the industrial site operator does not have access to the keys generated by the cryptographic circuit 306 and by applying the derivation function. However, index values ​​such as the identification value and the contextual indications used for the index path are public values.

[0066] According to one embodiment, the operator of the industrial site transmits a request (GET_DEV_AUT) to the equipment device 116 via a device 700. For example, the device 700 is a computer connected by a wired and / or wireless network to the equipment device 116 and to the blockchain 118. Following this request, the equipment device 116, and more specifically the cryptographic circuit 306, is then configured to generate a derivation path (PATH) corresponding to the derivation of the master key based on the first index value. The first index value is, in particular, a constant value. In the examples in this description, this value is arbitrarily set to OxCAFE. In particular, the key derivation function used is the derivation function associated with the BIP32 standard and is the same as that used for the generation of the leaf keys described in relation to [Fig. 6].Applying the master / OxCAFE derivation path to the seed value results in an extended key DEV KEY, of 2N bytes. The first N bytes correspond, for example, to a private key DEV_SK, and the last N bytes, for example, to a code string CHAINCODE. The 306 cryptographic circuit is then configured to calculate a public key DEV_PK associated with the private key DEV_SK. In particular, the public key is equal to the elliptic curve multiplication of the private key DEV_SK with the generating point of the elliptic curve of the secp256kl cryptographic system.

[0067] Device 116 is then configured to return the DEV_PK public key and the code string (DEV_PK; CHAINCODE) to device 700. In particular, the value of the DEV_PK public key depends on the seed value of the secure device 304. The DEV KEY and the DEV_PK public key are therefore unique. In other words, for two different devices, the DEV KEY and DEV_PK keys, and the DEV_SK private key, will differ.

[0068] Figure 8 illustrates the generation, by device 700, of an anonymized authentication value, according to one embodiment of this description. In particular, device 700 includes a key derivation application 800 (PK DERIVATION) according to the BIP32 standard. Specifically, this key derivation is performed using a public key and a code string. Upon receiving the DEV_PK public key and the code string, device 700, via the key derivation application and the application of a hash function, is configured to generate the account leaf address, identical to that generated by device equipment 116 when user 110 presents their user device 102.

[0069] Cryptographic key derivation functions according to the BIP32 standard are such that derivation from a public key has the same result as derivation from the associated private key, multiplied by the generating point of the elliptic curve secp256kl.

[0070] When the industrial site operator wants to generate the sheet account address for user 102 for a given day or time period, they provide device 700 with the identification value contained in user device 110, as well as contextual information, such as the current date and / or the time period during which access will be granted. Device 700 also receives from equipment device 116 the public key DEV_PK and the code string CHAINCODE retrieved following the industrial site operator's request, as described in relation to [Fig. 7]. Device 700, via application 800, applies a key derivation path D / UID(LSB) / UID(MSB) / DDMMYYYY, where D corresponds to the concatenation of the public key DEV_PK and the code string.In other words, application 800 is configured to construct a derivation path, starting from D and using as its first index the second index value used by the 306 circuit, i.e., the 31 least significant bits of the identification value; as its second index the third index value used by the 306 circuit, i.e., the 31 most significant bits of the identification value; and as its third index the fourth index value used by the 306 circuit, i.e., the contextual information. For example, other index values, corresponding for instance to contextual location information, are applied. In particular, the sequence of index values ​​used by application 800 corresponds exactly to the sequence, starting from the second index value, used by the cryptographic circuit 306 during the generation of the leaf key, as described in relation to [Fig. 5].The leaf public key (LEAF PK) then corresponds to the first N bytes of the leaf key. In particular, the leaf public key corresponds to the leaf public key generated by the 304 secure circuit, as described in relation to [Fig. 6]. The leaf account address is then obtained by hashing the leaf public key, using the same hashing method implemented by the 304 secure circuit and as described in relation to [Fig. 6]. For example, when the 118 blockchain is an Ethereum blockchain, the leaf account address corresponds to the 20 least significant bytes of the output of a hash function taking the leaf public key as input. For example, the hash function used is the one known to those skilled in the art as keccak256.In another example, when the blockchain is of type Bitcoin, the leaf account address is constructed as the output of the hash function known as H160, taking the leaf public key as input, to which a base-58 encoding is applied, followed by the addition of a Cyclic Redundancy Check (CRC). This same account address will be generated by the cryptographic circuit 306 upon receiving the identification value from device 110. In particular, the two addresses, the one generated by application 800 and the one generated... via cryptographic circuit 306, are identical if the contextual information matches. For example, if the industrial site operator indicates a first date when generating the leaf address by application 800 and user 102 presents their user device 110 to the equipment device 116 on a different date, the index values ​​including the contextual information will differ and the generated leaf addresses will be different.

[0071] The operator of the industrial site therefore has the ability to generate, via the device 700 and the application 800, a sheet account address for each user of each of the site's automata, and this according to a predefined time granularity.

[0072] According to one embodiment, the operator of the industrial site credits the credit sheet account to authorize its use. To do this, the industrial site operator sends a transaction, containing a value—that is, a positive amount of credit—to the ledger account address generated by application 800 in blockchain 118. For example, the number of credits transmitted depends on a usage intended by the site operator for user 102. For instance, the number of credits corresponds to the number of connections authorized by user 102 on PLC 108. In another example, the number of credits corresponds to a duration, for example, a number of hours, during which user 102 is authorized to use PLC 108. When the ledger account balance is zero, user 102 no longer has access to PLC 108. Blockchain 118 is then configured so that no transaction is free in credits.Credits are used, for example, to pay for goods, or fuel and / or gas.

[0073] Fig. 9 illustrates the generation of the same anonymized authentication value by the device 700 used by the operator and by the equipment device 116, in particular by the cryptographic circuit 306, according to an embodiment of the present description.

[0074] A block 900 illustrates the generation of the sheet account address for user 102, on the side of the industrial site operator, via device 700, and in particular application 800. A block 902 illustrates the generation of the DEV_PK public key, following a request from the user, as well as the generation of the sheet account address, following the identification of user 102.

[0075] As described in relation to [Fig.7], when the operator of the industrial site wants to provision the user's account, in order to guarantee access to the automaton 108, he must generate the leaf account address for the user 102 in order to credit the balance of his account on the blockchain 118.

[0076] Device 700 is then configured to send a request to device equipment 116. The secure circuit 304, and more specifically the circuit Cryptographic key 306 then generates the DEV_PK public key and the code string specific to device 116. Specifically, the extended key DEV KEY is first generated by applying the index path MASTER / ID1, where ID1 is the first index value, described here as equal to OxCAFE but which can take any value less than 231. In one example, this first index value is identical for each device 116. In another example, the first index value differs from one device 116 to another. The private key DEV_SK, corresponding, for example, to the first N bytes of the extended key DEV KEY, is then multiplied by the generating point of the elliptic curve associated with the secp256kl cryptographic system. The public key DEV_PK results from this multiplication.The public key DEV_PK and the code string CHAINCODE corresponding, for example, to the last N bytes of the extended key DEV KEY are provided, in response to the request, to device 700.

[0077] The site operator also provides the user ID value 102, to whom they wish to grant access to the automated system 108, as well as one or more contextual pieces of information, such as the current date for which access is desired, the time range, etc. From this information, the device 700 generates an index path (PATH2). For example, the first index value of this path ID2 is equal to the N least significant bits of the user ID value 102. For example, the second index value of this path ID3 is equal to the N most significant bits of the user ID value 102. For example, the third index value of this path ID3 corresponds to the contextual information, for example, in the format of today's date DDMMYYYY.

[0078] Device 700, through the execution of application 800, then successively derives the concatenation D of the public key DEV_PK and the code string provided by device equipment 116 by the index value ID2, then by the index value ID3, and then by the index value ID4. The derivation paths followed by application 800 are consecutively D / ID2, D / ID2 / ID3, and D / ID2 / ID3 / ID4. The key resulting from the derivation path implemented by application 800 corresponds to the leaf key LEAF KEY, the first N bytes of which correspond, for example, to the public key LEAF_PK. The leaf address LEAF ACCOUNT is then generated by applying the hash function, as described in relation to [Fig. 6].

[0079] When the LEAF ACCOUNT address is generated on the side of the industrial site operator, the latter carries out a transaction to provision the balance at the LEAF ACCOUNT address on the 118-block chain.

[0080] When user 102 wants to interact with or manipulate the automated system 108, they identify themselves, via their user device 110, to the equipment device 116. During identification, the identification value contained in the device User 110 is transmitted, for example via near-field communication, to device 116. The account address is then generated by cryptographic circuit 306 by applying an index path (PATH1). The derivation is performed from the master key MASTER, constructed from the seed value SEED. The index path used by cryptographic circuit 306 corresponds to the derivation based on a first index value ID1, equal to a constant, for example, OxCAFE. The subsequent index values ​​applied correspond to those applied by device 700, that is, the value ID2, corresponding, for example, to the N least significant bits of the identification value, then the value ID3, corresponding, for example, to the N most significant bits of the identification value, and finally the value ID4, corresponding to the contextual information.Application 800 and device 116 are therefore configured to generate the ID4 index value in the same format. For example, when the ID4 index value corresponds to today's date in DDMMYYYY format, device 116 includes a clock, and the ID4 index value is the current date in DDMMYYYY format. The ID4 index value is therefore not fixed and depends on the context; for example, it depends on the day on which user 102 logs in. Deriving the master key from the sequence of indexes ID1, ID2, ID3, and ID4 then results in the leaf key. The leaf account address then corresponds to applying the hash function to the multiplication of the first N bytes of the leaf key by the generating point of the elliptic curve of the secp256kl cryptographic system.

[0081] Access to the automaton 108 is then authorized by the equipment device 116 only if the balance of the paper account, in the blockchain is positive and sufficient.

[0082] When user 102 authenticates with device 116 via their user device 110, device 116 generates the LEAF KEY and then the LEAF ACCOUNT address. Device 116 then issues a transaction from the LEAF ACCOUNT address, digitally signed with the LEAF KEY. When the LEAF ACCOUNT balance is zero, or does not contain sufficient funds to pay the amount indicated in the transaction and / or the fuel required to execute the operation, the transaction is canceled. Device 116 is then configured to reject user 102's access request.

[0083] By way of example, in the case where the 118 blockchain is configured to implement smart contracts, each transaction includes a gas cost paid in credits for the operation targeted in the smart contract. This cost corresponds to the gas. In particular, the gas corresponds to the cost expended by the 118 blockchain to verify the transaction. The fuel is then paid for in credits. If the account balance The slip does not contain enough credits to pay for the gas, the transaction is cancelled and access to ATM 108 is denied to user 102.

[0084] For example, if the 118 blockchain is configured to perform account-to-account value transfer operations, the transaction is validated if the balance of the ledger account is positive and sufficient. For example, for each transaction validated on the ledger account, the balance of the ledger account is debited by one or more credits.

[0085] An authorized person is able to read the addresses of the transaction-issuing accounts in the blockchain over an audited period. For example, the authorized person reviews a schedule that includes information on the users involved, the DEV KEY public keys of the equipment devices, the users' identification values, and the day or time slot during which the audit takes place. The authorized person then follows the procedure described in relation to [Fig. 8] to construct the addresses of the accounts to be credited. Once the account addresses are reconstructed, the authorized person verifies, for example, whether they match. In particular, the authorized person verifies which identification value corresponds to an account address implicated in a malfunction.Since the operator of the industrial site knows the identification values ​​associated with the users, it is then possible for the authorized person to trace back to a user.

[0086] One advantage of the described embodiments is that the blockchain does not contain a history of access rights that have been granted or denied. The implemented system does not include a variable in the blockchain encoding whether authorization is granted or denied. Indeed, the transactions sent by the equipment devices are not carried out according to a request-response system. The transaction is simply validated if the balance of the sending account is positive and rejected otherwise.

[0087] Another advantage of the described embodiments is that consulting the blockchain allows neither tracing back to the identity of the user, nor tracing back to the equipment device, nor tracing the actions performed by the user on the automaton 108.

[0088] Another advantage of these embodiments is that access rights are granted based on contextual information, including, for example, temporal granularity. This contextual information, encoded in one or more index values ​​for key derivation, allows for fine-grained management of access permissions. For example, permissions are granted for a specific period and associated with a device. Consulting the blockchain does not reveal this contextual information.

[0089] Various embodiments and variations have been described. A person skilled in the art will understand that certain features of these various embodiments and variations could be combined, and other variations will become apparent to a person skilled in the art. In particular, with regard to the type of blockchain used, it may be a public, private, or consortium blockchain, implementing smart contract and / or account-to-account transactions. Similarly, the index values ​​used for key derivation may vary, especially with regard to the first index value ID1. Although described here as the OxCAFE value, this value is only an example, and any other value may be used. Likewise, although the description is based on an example of an industrial site, the access rights management process described applies to any other example.

[0090] Finally, the practical implementation of the embodiments and variants described is within the reach of a person skilled in the art, based on the functional indications given above.

Claims

Demands

1. A method for managing, by a first device (116), access to the use of an automated system (108) by a user, the method comprising: - providing an identification value (UID), associated with the user (102, 104, 106), to the first device; - generating, by a secure circuit (304) of the first device, an account address (LEAF ACCOUNT) on the basis of a master key associated with the first device, the identification value and a context value; - sending a transaction, including a cost value, to the account address in a blockchain (118); - validating or invalidating the transaction, by the blockchain, on the basis of the balance associated with the account address in the blockchain and the cost value; and - if the transaction is validated by the blockchain, the authorization, by the first device (116), of access to the use of the automaton (108) for the user.

2. A method according to claim 1, wherein the authorization to access the use of the automaton (108) includes the activation of the automaton (108) by the first device (116).

3. A method according to claim 1, wherein the transaction is validated by the blockchain (118) when the balance associated with the account address (LEAF ACCOUNT) is greater than or equal to the cost value.

4. A method according to claim 1 or 2, wherein the transaction is an account-to-account transaction or a transaction to a smart contract.

5. A method according to any one of claims 1 to 3, wherein the generation of the account address (LEAF ACCOUNT) comprises: - the generation of a first key (LEAF KEY) by deriving, through the secure circuit (304), a key derivation function associated with the BitCoin Improvement Proposal 32 (BIP32) standard of the master key along a first index path (PATH1); - the generation of a first public key (LEAF_PK) by multiplying a first part of the first key with a generating point of the elliptic curve associated with the cryptographic system of the BitCoin Improvement Proposal 32 (BIP32) standard; and - the generation of the account address (LEAF ACCOUNT) by applying a hash function to the leaf public key.

6. A method according to claim 4, wherein the derivation of the master key along the first index path comprises: - the application of a first index value (ID1), by the derivation function, the first index value being a constant value; and - following the application of the first index value, the application of a second index value (ID2), a third index value (ID3) and a fourth index value (ID4), the second and third index values ​​being dependent on the identification value associated with the user (102) and the fourth index value corresponding to the contextual value.

7. A method according to claim 5, wherein the second index value (ID2) corresponds to the 31 least significant bits of the identification value and the third index value (ID3) corresponds to the 31 most significant bits of the identification value.

8. A method according to any one of claims 4 to 6, wherein the master key is a value of 2N bytes, the first key (LEAF KEY) is a value of 2N bytes, and the first part of the first key corresponds to the first N bytes of the first key, N being an integer.

9. A method according to any one of claims 1 to 7, wherein the context value corresponds to a date encoding of at least one day on which access to the use of the first device (116) is authorized for the user (102).

10. A method according to claim 8, wherein the context value further includes an encoding of a time range or geographical location associated with the first device (116).

11. A method according to any one of claims 1 to 9, further comprising providing, via an external device (700), at least one credit to the LEAF ACCOUNT address in the blockchain (118) by: - the provision, by the first device (116) of a second public key (DEV_PK) and a code string associated with the first device; - the generation of the account address (LEAF ACCOUNT), by the external device, on the basis of the second public key and the code string; and - the provisioning of at least one credit on the account address in the blockchain (118).

12. A method according to claim 11 in its dependence on claim 5, wherein the second public key corresponds to a first part of a second key (DEV KEY), the second key being obtained by the first device (116) by derivation of the master key according to the first index value (ID1), and wherein the external device (700) is configured to generate the account address on the basis of a key derivation, on the basis of the second public key and the code string and on the basis of the second, third and fourth index values ​​(ID2, ID3, ID4).

13. A method according to any one of claims 1 to 11, wherein the provision of the identification value to the first device is carried out by the user, by presenting a user device (110) in which the identification value is stored, the provision being carried out by near-field communication between the user device and the first device.

14. First device (116) comprising a secure circuit (304) in which a seed value (SEED) is stored, the first device being configured to, following the provision of an identification value by a user (102): - generate a LEAF ACCOUNT address on the basis of a master key associated with the first device, the identification value and a context value; - send a transaction, including a cost value, to the account address in a blockchain (118); and - if the transaction is validated by the blockchain, allow the user (102) access to use an automaton (108).

15. System comprising: - the first device (114) according to claim 14; - a blockchain (118) configured to validate or invalidate the transaction sent by the first device, based on the balance associated with the account address in the blockchain and the cost value; and - an external device (700), configured to generate the account address (LEAF ACCOUNT) based on a second public key and code string, provided by the first device, the identification value and a context value and to provision at least one credit on the account balance to the account address in the blockchain.

16. System according to claim 15, wherein the account address (LEAF ACCOUNT) is generated by applying a key derivation function associated with the BitCoin Improvement Proposal 32 standard.

Images