WO2020012079A1 - Gouvernance de sécurité du traitement d'une requête numérique - Google Patents

Gouvernance de sécurité du traitement d'une requête numérique Download PDF

Info

Publication number
WO2020012079A1
WO2020012079A1 PCT/FR2019/000113 FR2019000113W WO2020012079A1 WO 2020012079 A1 WO2020012079 A1 WO 2020012079A1 FR 2019000113 W FR2019000113 W FR 2019000113W WO 2020012079 A1 WO2020012079 A1 WO 2020012079A1
Authority
WO
WIPO (PCT)
Prior art keywords
entities
cooperating
creative
entity
request
Prior art date
Application number
PCT/FR2019/000113
Other languages
English (en)
Inventor
Nicolas Bacca
Olivier Tomaz
Original Assignee
Ledger, Sas
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ledger, Sas filed Critical Ledger, Sas
Priority to SG11202100263PA priority Critical patent/SG11202100263PA/en
Priority to JP2021500594A priority patent/JP2021525993A/ja
Priority to AU2019300287A priority patent/AU2019300287A1/en
Priority to CA3105894A priority patent/CA3105894A1/fr
Priority to US17/259,113 priority patent/US11757660B2/en
Priority to KR1020217004291A priority patent/KR20210028719A/ko
Priority to EP19745659.3A priority patent/EP3821564A1/fr
Priority to CN201980053226.9A priority patent/CN112970226A/zh
Publication of WO2020012079A1 publication Critical patent/WO2020012079A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3255—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Definitions

  • the invention relates to the security governance of the processing of a digital request and relates to a method for validating a digital request by a requesting entity, a method for processing a digital request implementing this method of validation of a digital request, applications of this method of validating a digital request and a system for implementing this method of validating a digital request, including at least two security processors.
  • security governance for the processing of a digital request must be considered in its broadest and generic sense, so as to include, in particular but not exclusively, a method of governance of an electronic signature, a method of governance of encryption or decryption of data, an electronic voting process, a governance process for banking or electronic payment transactions.
  • This security governance must be understood as representative of the processes making it possible to verify the compliance of the digital request of a requesting entity with the corpus of rules defined jointly by cooperating entities implementing security processors responsible for an application.
  • the expression "cooperating entity” must therefore be understood as being a person or a computer robot capable of using an application carried by a security processor.
  • the term "requesting entity” should be understood to mean the entity making the digital request.
  • the expression "digital request” must be understood to mean a message addressed to an electronic and computer means cooperating for a service and including a system for the implementation of this method of validation of a digital request.
  • Such a service can be, in particular but not exclusively, encryption or decryption of data, electronic voting, a bank or electronic payment transaction.
  • security processor must be understood as an electronic support device for applications implementing confidential data, and comprising a persistent memory, a volatile memory, a computer capable of performing cryptographic functions and in particular of authenticating all or part of the content of his memoirs by providing what is called here a "digital certificate".
  • the processor is qualified as security insofar as the content of the memories can only be modified with authentication with the device.
  • Document US 5,815,573 describes a method for generating a cryptographic key to be used by the pair of communicating parties while providing for the recovery of said key using the plurality of cooperating key recovery agents, comprising the steps of: : generate the plurality of shared key parts which are shared with the respective key recovery agents; generate the unshared key part which is not shared with any key recovery agent; generating said key based on said shared key portions and said unshared key portion; and making available the respective parts of said shared key parts to said key recovery agents to facilitate said recovery of said key by using said key recovery agents.
  • WO 2017/064124, W003077470 and WO9505712 describe methods for generating a common secret.
  • the document WO 2017/145016 describes a method and a system for determining the common secret for two nodes.
  • Each node has my respective asymmetric cryptographic pair, each pair comprising my master private key and my master public key.
  • Respective second private and public keys can be determined based on the master private key, the master public key and a deterministic key.
  • a common secret can be determined at the level of each of the nodes according to the second private and public keys.
  • m node can determine the common secret according to: a second private key based on the node's own master private key and the deterministic key; d'me second public key based on the master public key of the other node and the deterministic key.
  • the method and system can be adapted to digital wallets, blockchain technologies and the security of personal devices. With this process and this system, there is no sharing of a common secret.
  • the document W0 2017/145010 describes a process implemented by computer to control access to an IT resource such as, for example, a digital wallet.
  • the portfolio can be implemented using a block chain.
  • the implementation of the method during the initial configuration of the wallet may allow subsequent operations, such as wallet transactions, to be managed in a secure manner over an insecure channel, such as Internet.
  • a method may include the steps of dividing a verification element (such as a private key in an asymmetric cryptography pair) into a plurality of shares; determining a shared secret at at least two nodes in a network; and using the shared secret to transmit at least part of the verification element between said two nodes.
  • the shares can be divided in such a way that no single share is sufficient to obtain the verification element. This means that no party stores the entire private key, which provides improved key security. At least two parts are needed to restore the key. The units are stored in separate locations, one of which is an independent backup or secure storage location. If one of the other parts becomes unavailable, the part can be extracted from the backup to guarantee that the key (and thus the ordered resource) is always accessible.
  • the shared secret is generated at two different nodes independently of each other, then used to generate an encryption key.
  • the encryption key can be used to encrypt at least a part of the verification element, or a message comprising it, to ensure that said parts are transmitted securely. With this process, we do not make and share a common secret.
  • the processor is not secure, as previously defined.
  • WO 2016/130030 describes a method of protecting data using threshold cryptography, in which data is encrypted using cryptographic algorithms and a cryptographic key is divided into parts.
  • the method of data protection using threshold cryptography is characterized in that a unique identifier is assigned to encrypted data.
  • a unique identifier is assigned to encrypted data.
  • the encrypted data merged with some of the parts of the key is divided into fragments and a unique identifier previously assigned to the encrypted data is added to each fragment.
  • the same unique identifier is added to the share of each key that has not been merged with encrypted data.
  • the obtained fragments of data are deployed on physically separate devices comprising at least one processor and a non-volatile memory, and, for each fragment, information concerning the device on which it is deployed is saved.
  • the parts of the key which have not been merged with encrypted data are placed on physically separate devices comprising at least one processor and non-volatile memory, and, for each part of the key, information concerning the device on which it is stored are saved.
  • threshold cryptography secret sharing
  • a secret is divided by calculation into N parts using a threshold encryption scheme such that any M of the shares (M less than or equal to N) can be used to reconstruct the secret.
  • the N shares are distributed over a certain number of transmitted messages, assuming that a certain number of messages comprising a total of at least M actions will be received by the client.
  • the client uses at least M shares to reconstruct the secret using the threshold encryption scheme.
  • Security governance is known in which a requesting entity makes a request to a system including a security processor, the execution of which is conditional on the consent in fine from said security processor, of persons or computer robots, who have been previously authorized by an external authority playing the role of trusted third party.
  • the problem underlying the invention is to validate a digital request from a requesting entity and ultimately to be able to process this digital request, by submitting it to the prior consent of several entities, without having to resort to a trusted third party.
  • the invention relates to a method for validating a digital request
  • each entity from the plurality of cooperating entities ensures that each of the other entities from the plurality of entities implements an application identical to its own by cryptographically verifying the corresponding digital certificate
  • a said security processor is able to be implemented either by a cooperating entity in which case said security processor is specific to this cooperating entity or by several cooperating entities in which case said security processor is common to these cooperating entities , the method involving the implementation of at least two security processors.
  • each security processor to deliver a digital certificate of integrity on request:
  • security processors are chosen so that they each have their own first pair of asymmetric cryptographic keys
  • each security processor uses the private key of said first pair of keys to produce an electronic signature of all or part of the content of its memories
  • said electronic signature being a digital certificate of integrity of the corresponding signed content, and its authenticity can be verified using the public part of said first pair of keys.
  • the private part of said second pair of keys is used to produce the electronic signature of the public part of said first pairs of keys of each security processor
  • the cooperating entities in order to agree on said second pair of asymmetric cryptographic keys, use a pair of asymmetric cryptographic keys drawn randomly and shared between them or else said second pair of asymmetric cryptographic keys is that of a certification authority. external.
  • said own confidential data are drawn randomly by each of the cooperating entities, and / or introduced by the cooperating entities into the memory of the associated security processors, and / or extracted from the memory of the associated security processors.
  • the common secret is able to be cut, into cut parts so as to be reconstituted subsequently and / or in which at least some, or all, of the cut parts are suitable and sufficient. to reconstitute said common secret subsequently.
  • said common secret can be reconstituted with at least some of, or all, the so-called creative cut parts.
  • said common secret can only be used for the validation of one and only one digital request and cannot be stored persistently in any of the memories of the associated security processors.
  • each entity of the plurality of cooperating entities directly ensures that each of the other entities in the plurality of entities implements an application identical to its own by cryptographically verifying the corresponding digital certificate.
  • each entity of the plurality of cooperating entities ensures that each of the other entities in the plurality of entities implements an application identical to its own by cryptographically verifying the corresponding digital certificate, indirectly and through transitivity, by ensuring that '' a certain entity from the plurality of entities implements an application identical to its own by cryptographically verifying the corresponding digital certificate, this certain entity having itself ensured that the other entities from the plurality of entities are implementing the same application.
  • said own confidential data are transmitted confidentially, by means of an encryption and decryption algorithm, between the cooperating creative entities using at least one session key, said at least one session key being rendered unusable after the creation of 'a common secret.
  • the creative cooperating entities include a first pilot creative entity and the other creative cooperating entities
  • each creative cooperating entity implements its own key to communicate confidentially, by means of an encryption and decryption algorithm, with said first pilot creative entity,
  • said application includes an algorithm for exchanging session keys
  • each cooperating creative entity being said first pilot creative entity
  • the creative cooperating entities include a second pilot creative entity and the other creative cooperating entities
  • each signatory cooperating entity implements its own key to communicate confidentially, by means of an encryption and decryption algorithm, with said second pilot creative entity,
  • a plurality of session keys is used, so that each creative cooperating entity implements its own key to communicate confidentially, by means of an encryption and decryption algorithm, with said second pilot creative entity, said second pilot creative entity implements a process for verifying the integrity of said application carried by the security processor of each signatory cooperating entity, so that said second pilot creative entity ensures that each of the cooperating entities signatories implements an application identical to its own by cryptographically verifying the corresponding digital certificate,
  • said application includes an algorithm for exchanging session keys
  • said algorithm for exchanging session keys is initiated between, on the one hand, each of said other creative cooperating entities and each of the signatory cooperating entities and, on the other hand, said second pilot creative entity,
  • said other creative cooperating entities transmit, confidentially using their own session key, by means of an encryption and decryption algorithm, and not replayable , their so-called creative cut parts resulting from the same cut of the secret common to said second pilot creative entity, o said second pilot creative entity reconstitutes the common secret,
  • said second pilot creative entity divides the common secret into a number of signatory divided parts equal to the number of signatory cooperating entities, o said second pilot creative entity transmits, confidentially using session keys, using an encryption algorithm and deciphering, and not replayable, their said cut parts signatories of the secret common to said signatory cooperating entities.
  • cut parts originating from the same cut of the common secret are transmitted confidentially, by means of an encryption and decryption algorithm, between the cooperating entities using at least one session key, said at least one session key. being rendered unusable after the reconstitution of said common secret.
  • the cooperating entities include a pilot entity and the other cooperating entities,
  • each cooperating entity uses its own key to communicate confidentially, by means of an encryption and decryption algorithm, with said pilot entity,
  • said application includes an algorithm for exchanging session keys
  • the subject of the invention is a method for processing a digital request from a requesting entity, with a plurality of cooperating entities which are each capable of implementing a security processor loaded with the same application. necessary for processing said request, application for which each security processor delivers a digital certificate of integrity on request, which implements the method for validating a digital request which has just been described, so that said request is processed if and only if cooperating entities of the college of signatory cooperating entities implement said application by means of common secrecy.
  • the requesting entity transmits said digital request on the one hand to the college of cooperating entities, on the other hand to an electronic means capable of executing said request,
  • said electronic means executes said digital request as a function of said validation.
  • the subject of the invention is the application of the method for validating a digital request which has just been described, to a method for processing a digital request from a requesting entity as previously described or else , in particular, in particular an electronic signature governance process, an encryption and data encryption governance process, an electronic voting process, a governance process for bank or electronic money transactions.
  • the invention relates to a system for implementing the method of validating a digital request which has just been described, which comprises:
  • At least two security processors supporting an application necessary for processing said request, using confidential data, and comprising a persistent memory, a volatile memory, a computer capable of performing cryptographic functions and in particular of authenticating all or part of the content of its memories by providing a digital certificate of integrity on request, so that a plurality of cooperating entities are capable of each implementing a said security processor, and the content of the memories cannot be modified that with authentication,
  • FIG. 1 is a simplified diagram illustrating an example of a possible embodiment of a method for processing a digital request implementing a method for validating the request.
  • a requesting entity three cooperating entities, three security processors, and an electronic and computer means capable and intended to execute the request.
  • the arrows symbolize the operations carried out.
  • FIG. 2 is a simplified diagram which illustrates two possible embodiments with regard to the security processors and the cooperating entities, namely an embodiment in which the security processor is specific to a cooperating entity and an embodiment in which the processor security is common to several cooperating entities.
  • FIG. 3 is a simplified diagram illustrating an exemplary embodiment of a process for verifying the integrity of the application implemented, using a cryptographic process with asymmetric cryptographic keys.
  • Figure 4 is a simplified diagram corresponding to an exemplary embodiment with a second pair of asymmetric cryptographic keys.
  • Figures 5 [Fig. 5] and 6 [Fig. 6] are two simplified diagrams illustrating two exemplary embodiments so that the cooperating entities agree on a second pair of asymmetric cryptographic graphical keys, namely an embodiment with random draw and an embodiment involving an external certification authority.
  • Figure 7 is a simplified diagram illustrating that cooperating entities share their own confidential data and that digital processing is applied to all of them in order to create a common secret.
  • Figure 8a is a simplified diagram illustrating an embodiment in which the own confidential data are drawn randomly by each of the cooperating entities.
  • FIG. 8b is a diagram illustrating another embodiment in which the own confidential data are introduced by the cooperating entities into the memory of the associated security processors.
  • FIG. 9 is a simplified diagram illustrating that, by means of a cutting / reconstitution algorithm, the common secret is cut into cut parts and then reconstituted subsequently.
  • FIG. 10 is a simplified diagram illustrating the pooling of own confidential data and their digital processing in order to create a common secret, then its cutting by means of a cutting algorithm and its distribution between cooperating entities, then its reconstruction by means a reconstruction algorithm.
  • Figures 11 [Fig. 11] and 12 [Fig. 12] are two simplified diagrams illustrating two possible embodiments with regard to the application integrity verification process, namely a direct verification (FIG. 11 [FIG. 11]) and an indirect verification by transitivity (FIG. 12 [Fig. 12]).
  • a method for validating a digital request RN is applied to a method for processing a digital request RN from a requesting entity ED.
  • the security governance of the processing of a digital RN request must be considered in its broadest and generic sense, so as to include, in particular but not exclusively, a method of governance of an electronic signature, a method governance of encryption or decryption of data, an electronic voting process, a governance process for banking or electronic payment transactions.
  • the requesting entity ED is a person or a computer robot which is able to make or carry out the digital request RN and which, concretely makes or proceeds to this digital request RN.
  • the digital request RN is a message addressed to an appropriate electronic and computer MEI means.
  • a digital request RN and such electronic and computer means MEI are an Internet form carried by a server, filled in by the requesting entity ED.
  • the method for validating a digital request RN is sometimes called, by ellipse, method of validation and, by analogy, the method for processing a digital request RN is sometimes called, by ellipse, method of treatment.
  • the validation method implements a validation system SV which includes at least two security processors PS, support for an application AP necessary for processing the request RN, consequently suitable for this purpose, and implementing confidential data DC.
  • a security processor PS includes a persistent memory, a volatile memory, a computer capable of performing cryptographic functions and in particular to authenticate all or part of the content of its memories by providing a digital certificate of integrity AN on request.
  • the application AP is loaded into a memory of such a security processor PS and expresses the set of rules executed with confidential data DC and parameters.
  • the AP application includes at least one process for creating a common secret SC.
  • a plurality (at least two) of cooperating entities EC are provided, which are able and each intended to implement a security processor PS.
  • the contents of the memories of the PS security processors can only be modified with an authentication, which makes it possible to qualify the PS processors as being "security".
  • the validation system SV furthermore comprises a means suitable and intended for creating a common secret SC, a digital attestation algorithm, an encryption and decryption algorithm ALCD, a cutting / reconstitution algorithm of common secret SC, ALDE / ALRE, an algorithm for exchanging session keys ALEC, means of communication between the security processors PS and the entities EC, ED.
  • a security processor PS is for example a smart card.
  • a suitable means intended to create a common secret SC is based on an exclusive OR function (often called XOR); a digital attestation algorithm is an ECDSA algorithm (for Elliptic Curve Digital Signature Algorithm); an encryption and decryption algorithm is an AES (for Advanced Encryption Stamdard) algorithm; a common secret cutting / reconstruction algorithm SC is an SSS (for Shamir's Secret Sharing) algorithm; a session key exchange algorithm is a SCDH algorithm (for Elliptic Curve Diffie-Hellman), means of communication between the security processors PS and the entities EC, ED are telematic links.
  • ECDSA for Elliptic Curve Digital Signature Algorithm
  • AES for Advanced Encryption Stamdard
  • SC for Shamir's Secret Sharing
  • SCDH for Elliptic Curve Diffie-Hellman
  • the processing method implements the validation method mentioned above, so that the request RN is processed if and only if the cooperating entities EC of a college of cooperating entities signatories COECS referred to by the subsequently, implement the application AP by means of a common secret SC which is also discussed below.
  • the requesting entity ED transmits the request RN on the one hand to the college of cooperating entities COEC, on the other hand to an electronic and computer means MEI, designed and chosen so as to be able and intended to execute the RN request.
  • the COEC college of cooperating entities implements the validation process, using the common secret SC, with a view to validating the RN request.
  • the electronic and computerized means MEI then executes the request RN as a function of the validation.
  • the electronic and IT means MEI can be the subject of different embodiments, known or within the reach of those skilled in the art, depending on the RN request, the corresponding service and the environment in which the processing process takes place. of the RN request.
  • an electronic and computer-based MEI means is a computer, whatever its form.
  • the validation process makes it possible to ensure security governance, insofar as this leads to verifying the conformity of the digital request RN with the corpus of rules defined in common by the cooperating entities EC, and this by implementing the processors of PS security responsible for the AP application,
  • the cooperating entities EC are each a person or a computer robot capable of using the AP application.
  • FIG. 1 schematically representing the requesting entity ED, a plurality of cooperating entities EC comprising here three entities, three security processors PS, one per cooperating entity EC, the three cooperating entities EC and the three security processors PS forming a sort of "block" comprising a college of cooperating signatory entities COECS and their associated security processors PS, and the electronic and computer means MEI capable and intended to execute the request RN.
  • the reference arrow a symbolizes the request for validation of the RN request by the requesting entity ED in the "block".
  • the reference arrows b symbolize the validation process of the request RN of the requesting entity ED within the "block", by means of a process of reconstitution of common secret SC.
  • the reference arrow ç symbolizes the result of the validation transmitted by the "block” to the requesting entity ED and the reference d symbolizes the validated request transmitted to the electronic and IT MEI means.
  • the validation method is such that a plurality (at least two) of cooperating entities EC are capable of each implementing a security processor PS loaded with the same application AP, for which each security processor PS delivers a digital AN certificate of integrity on request.
  • the RN digital request is validated and ultimately processed by submitting it to the prior consent of several entities, without having to resort to a trusted third party.
  • the cooperating entities EC agree to the execution of the digital request RN, by means of the implementation of threshold cryptography technologies, while these cooperating entities EC will authenticate each other using the digital certificates AN issued by PS security processors.
  • FIG. 2 which takes up part of Figure 1 [Fig. 1] and illustrates two possible embodiments with regard to the security processors PS and the cooperating entities EC.
  • the security processor PS is specific to a cooperating entity EC.
  • the security processor PS is common to several cooperating entities. In all cases, the validation process involves the implementation of at least two PS security processors.
  • the validation method includes a process for verifying the integrity of the application AP such that, from the digital certificates AN issued by each security processor PS, each entity EC of the plurality of cooperating entities EC ensures that each of the other entities EC of the plurality of entities EC implements an application AP identical to its own by cryptographically verifying the corresponding digital certificate AN.
  • security processors PS are chosen so that they have each, in its own right, of a first pair of asymmetric cryptographic keys CC1.
  • each security processor PS uses the private key CPR1 of the first pair of keys CCI to produce (which is symbolized by the reference arrow a in FIG. 3 [Fig. 3 ]) an electronic signature of all or part of the content of its COMEM memories.
  • This electronic signature is worth digital certificate AN of integrity of the corresponding signed content, and its authenticity can be verified by using the public key CPU1 of the first pair of keys CCI.
  • the cooperating entities EC agree together on a second pair of asymmetric cryptographic keys CC2. Then, the private key CPR2 of the second pair of keys CC2 is implemented to produce the electronic signature of the public key CPU1 of the first pairs of keys CC1 of each security processor PS, previously mentioned. Thus, the cooperating entities EC are able to authenticate, by implementing the public key CPU2 of the second pair of keys CC2, the digital certificates AN of integrity delivered by each of the security processors PS.
  • Figure 4 Figure 4 [Fig.
  • the reference arrow a symbolizes the extraction of the public key CPU1 from the first pair of keys CCI and the reference arrow b symbolizes the signature, by the private key CPR2 of the second pair of keys CC2, of the key public CPU1 of the first pair of CCI keys.
  • the cooperating entities EC agree on a second pair of asymmetric cryptographic keys CC2.
  • the cooperating entities EC use a pair of asymmetric cryptographic keys randomly drawn and shared between them.
  • the second pair of asymmetric cryptographic keys CC2 is that of an external certification authority.
  • the reference arrow a symbolizes the supply of the public key CPU1 of the first pair of keys CCI to the external certification authority ACE
  • the reference arrow b symbolizes the implementation of the private key CPR2 of the second pair of key CC2 of the external certification authority ACE to sign the public key CPU1 of the first pair of keys CC1 (creation of digital certificate AN)
  • the reference arrow ç symbolizes the return of the signature electronic of the public key CPU1 of the first pair of keys CCI by the private key CPR2 of the second pair of keys CC2, with a view to its storage in the security processor PS.
  • the validation method also includes a process by which cooperating entities EC create a common secret SC and thus constitute a college of cooperating creative entities COECC.
  • cooperating entities EC pool their own confidential data DC and digital processing TN is applied to all of their own confidential data DC in order to create the common secret SC.
  • the reference arrow b in this figure symbolizes the own confidential data DC which are drawn randomly by each of the cooperating entities EC.
  • the reference arrow a in this figure symbolizes the own confidential data DC which are introduced by the cooperating entities EC into the memory of the associated security processors PS.
  • the own confidential data DC are extracted from the memory of the associated security processors PS.
  • the reconstruction of the common secret SC can be carried out from not all of the cut parts PDE, but only from some of them, which are then suitable and sufficient to reconstitute later said common secret SC.
  • all the cut parts PDE are necessary in order to subsequently reconstitute the common secret SC.
  • the common secret SC can then be reconstituted only from the PDE cut parts from the same cut and not from PDE cut parts from more than one cut.
  • cooperating entities EC pool their own confidential data DC (which is symbolized by the reference arrow a in FIG. 10 [Fig. 10]), the digital processing TN applied to all of this confidential data own DC in order to create the common secret SC, as it was previously exposed. Then, the common secret SC thus created is divided into a number of creative divided parts PDEC which is equal to the number of creative cooperating entities ECC constituting a college COECC, by means of an ALDE division algorithm (which is symbolized by the reference arrow b in figure 10 [Fig. 10]).
  • the PDEC creative cut parts are then distributed among the creative cooperating entities ECC, each of them retaining one of the PDEC creative cut parts (which is symbolized by the reference arrow ç in FIG. 10 [Fig. 10]).
  • the common secret SC is reconstituted with at least some of (two out of three in the case of FIG. 10 [Fig. 10]) creative cut parts PDEC. Or else, in one embodiment, the common secret SC is reconstituted with all of the creative cut parts PDEC.
  • the common secret SC can only be used for the validation of one and only one digital request RN and it cannot be stored persistently in any of the memories of the associated security processors PS.
  • each EC cooperating entity directly ensures this.
  • Figure 11 [Fig. 11] are represented three cooperating entities EC, three security processors PS with the applications AP.
  • the two reference arrows a in Figure 11 [Fig. 11] symbolize the issue by two cooperating entities EC to the third cooperating entity EC of the AN certificates of their own AP application.
  • the reference arrow b in FIG. 11 [Fig. 11] symbolizes the verification by the third cooperating entity EC that the applications of the first two cooperating entities EC are identical to its own. The verification is therefore direct.
  • each EC cooperating entity ensures that each of the other EC cooperating entities implements an AP application identical to its own by cryptographically verifying the digital certificate AN corresponding, not directly as in the first embodiment, but indirectly and through transitivity, by ensuring that a certain cooperating entity ECT implements an AP application identical to its own by verifying the certificate in a cryptographic manner corresponding digital AN, this certain ECT cooperating entity having itself ensured that the other EC cooperating entities implement the same AP application.
  • FIG. 12 are represented four cooperating entities EC, including the certain entity ECT, four security processors PS with the applications AP.
  • FIG. 12 symbolizes the issuance by two cooperating entities EC to the certain cooperating entity ECT, of AN certificates of their own AP application.
  • the reference arrow b in Figure 12 [Fig. 12] symbolizes the verification by this the certain cooperating entity ECT that the applications AP of the first two cooperating entities EC are identical to its own.
  • the reference arrow ç in Figure 12 [Fig. 12] symbolizes the issuance by the certain cooperating entity ECT to the fourth cooperating entity EC of a certificate AN of its own application AP, which is identical to that of the first two cooperating entities EC.
  • the reference arrow d in FIG. 12 [FIG. 12] symbolizes the verification by this fourth cooperating entity EC that the application AP of the certain cooperating entity ECT and therefore also in a transitive manner the application AP of the first two cooperating entities EC are identical to its own.
  • the verification is therefore here indirect.
  • the confidential own data DC are transmitted confidentially, by means of an encryption and decryption algorithm, between the cooperating creative entities ECC, using at least one session key, which session key is returned unusable after the creation of a common secret SC.
  • cut parts PDE originating from the same cut of the common secret SC are transmitted confidentially, by means of an encryption and decryption algorithm, between the cooperating entities EC using at least one session key, the session key being made unusable after the reconstitution of said common secret SC.
  • the cooperating creative entities ECC comprise a first pilot creative entity ECCP1 and the other cooperating creative entities ECCA1.
  • a plurality of session keys is used, so that each cooperating creative entity ECC implements its own key to communicate confidentially, by means of an encryption and decryption algorithm ALCD, with the first pilot creative entity ECCP1.
  • the AP application integrates a session key exchange algorithm, ALEC.
  • the first pilot creative entity ECCP1 initiates the algorithm for exchanging session keys ALEC with each of the other cooperating creative entities ECCA1.
  • the other cooperating creative entities ECCA1 transmit, confidentially using their own session key, using an encryption and decryption algorithm ALCD, and not replayable, their own confidential data DC to the first pilot creative entity ECCP1.
  • the cooperating creative entities ECC are able to apply digital processing to all of DC's own confidential data, thus creating the common secret SC.
  • the cooperating creative entities ECC comprise a second pilot creative entity ECCP2 and the other cooperating creative entities ECCA2.
  • a plurality of session keys is used, so that each cooperating signatory entity ECS implements its own key to communicate confidentially, by means of an encryption and decryption algorithm ALCD, with the second pilot creative entity ECCP2.
  • a plurality of session keys is also used, so that each cooperating creative entity ECC implements its own key to communicate confidentially, by means of an encryption and decryption algorithm ALCD, with the second pilot creative entity ECCP2.
  • the second pilot creative entity ECCP2 implements a process for verifying the integrity of the application AP carried by the security processor PS of each cooperating entity signing ECS, so that the second pilot creative entity ECCP2 ensures that each of the Cooperating signatory entities ECS implements an AP application identical to its own by cryptographically verifying the corresponding digital certificate AN.
  • the AP application includes an algorithm for exchanging ALEC session keys. Then, the algorithm for exchanging ALEC session keys is initiated between, on the one hand, each of the other cooperating creative entities ECCA2 and each of the signatory cooperating entities ECS and, on the other hand, the second pilot creative entity ECCP2.
  • the second pilot creative entity ECCP2 reconstructs the common secret SC.
  • the second pilot creative entity ECCP2 divides the common secret SC into a number of parts divided into signatory PDES equal to the number of cooperating entities signatory ES.
  • the second pilot creative entity ECCP2 transmits, confidentially using the session keys, by means of an encryption and decryption algorithm ALCD, and not replayable, their cut parts PDES signatories of the common secret SC to the cooperating entities signatories ECS.
  • the cooperating entities EC comprise a pilot entity ECP and the other cooperating entities ECA.
  • a plurality of session keys is used, so that each cooperating entity EC uses its own key to communicate confidentially, using an encryption and decryption algorithm ALCD, with the pilot entity ECP.
  • the AP application includes an algorithm for exchanging ALEC session keys.
  • the ECP pilot entity initiates the algorithm for exchanging ALEC session keys with each of the other EC cooperating entities.
  • the validation method includes, by means of the implementation of the integrity verification process of the AP application, a process by which ECC entities of the college of cooperating creative entities COECC designate the signatory cooperating entities ES, thus constituting a college of cooperating signatory entities COECS.
  • This college of COES signatory cooperating entities, taken as such, has access to the common secret SC.
  • the RN request is validated if and only if the ECS cooperating entities of the college of COECS signatory cooperating entities implement the AP application by means of the common secret SC. Depending on the case, it is all the signatory cooperating entities or only a quorum of the college of COECS signatory cooperating entities.
  • the college of COECC creative cooperating entities and the college of COECS signatory cooperating entities are separate, or the college of COECC creative cooperating entities and the college of COECS signatory cooperating entities are at least partly common.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

Procédé de validation d'une requête numérique (RN) dans lequel des entités coopérantes (EC) sont aptes à mettre en œuvre des processeurs de sécurité (PS) chargés avec une application (APP) de traitement de la requête (RN), chaque processeur délivrant une attestation numérique (AN) d'intégrité sur demande; qui comporte un processus de vérification d'intégrité de l'application (APP) tel que, à partir des attestations délivrées, chaque entité s'assure que chacune des autres entités met en œuvre une application (APP) identique à la sienne; qui comporte un processus par lequel des entités créent un secret commun (SC) et constituent ainsi un collège d'entités créatrices; qui comporte un processus par lequel des entités du collège d'entités créatrices désignent les entités signataires, constituant ainsi un collège d'entités coopérantes signataires (ECS), en sorte que, pris en tant que tel, il ait accès au secret commun (SC); de sorte que ladite requête (RN) est validée si et seulement si des entités du collège d'entités signataires (COECS) mettent en œuvre ladite application (APP) moyennant le secret commun (SC).

Description

Description
Titre de l’invention : Gouvernance de sécurité du traitement d’une requête numérique
L’invention est relative à la gouvernance de sécurité du traitement d’une requête numérique et a pour objet un procédé de validation d’une requête numérique par une entité demanderesse, un procédé de traitement d’une requête numérique mettant en œuvre ce procédé de validation d’une requête numérique, des applications de ce procédé de validation d’une requête numérique et un système pour la mise en œuvre de ce procédé de validation d’une requête numérique, incluant au moins deux processeurs de sécurité.
L’expression « gouvernance de sécurité du traitement d’une requête numérique » doit être considérée dans son acception la plus large et générique, de sorte à inclure, notamment mais non exclusivement, un procédé de gouvernance de signature électronique, un procédé de gouvernance de chiffrement ou déchiffrement de données, un procédé de vote électronique, un procédé de gouvernance de transactions bancaires ou monétiques.
Cette gouvernance de sécurité doit être comprise comme représentative des processus permettant de vérifier la conformité de la requête numérique d’une entité demanderesse au corpus de règles définies en commun par des entités coopérantes mettant en œuvre des processeurs de sécurité chargés d’une application. L’expression « entité coopérante » doit donc être comprise comme étant une personne ou un robot informatique apte à utiliser une application portée par un processeur de sécurité. L’expression « entité demanderesse » doit être comprise comme désignant l’entité qui fait la requête numérique. L’expression « requête numérique » doit être comprise comme signifiant un message adressé à un moyen électronique et informatique coopérant en vue d’un service et incluant un système pour la mise en œuvre de ce procédé de validation d’une requête numérique. Un tel service peut être, notamment mais non exclusivement, un chiffrement ou un déchiffrement de données, un vote électronique, une transaction bancaire ou monétique.
L’expression « processeur de sécurité » doit être comprise comme un dispositif électronique support pour des applications mettant en œuvre des données confidentielles, et comprenant une mémoire persistante, une mémoire volatile, un calculateur apte à réaliser des fonctions cryptographiques et notamment à authentifier tout ou partie du contenu de ses mémoires en fournissant ce que l’on dénomme ici une « attestation numérique ». Le processeur est qualifié de sécurité dans la mesure où le contenu des mémoires ne peut être modifié qu’avec une authentification auprès du dispositif.
Le terme « application » concernant l’application chargée dans une mémoire d’un tel processeur de sécurité doit être compris comme signifiant l’ensemble des règles exécutées avec des données confidentielles et des paramètres (incluant au moins un processus de création de secret). Le document US 5 815 573 décrit un procédé de génération d'une clé cryptographique à utiliser par me paire de parties communicantes tout en prévoyant la récupération de ladite clé en utilisant me pluralité d'agents de récupération de clé coopérants, comprenant les étapes consistant à: générer me pluralité de parties clés partagées qui sont partagées avec les agents de récupération de clé respectifs; générer me partie clé non partagée qui n'est partagée avec aucm agent de récupération de clé; générer ladite clé en fonction desdites parties de clé partagées et de ladite partie de clé non partagée; et rendre disponibles les parties respectives desdites parties de clé partagées auxdits agents de récupération de clé pour faciliter ladite récupération de ladite clé en utilisant lesdits agents de récupération de clé.
Parmi d’autres, les documents WO 2017/064124, W003077470 et WO9505712 décrivent des procédés pour générer un secret commun.
Le document WO 2017/145016 décrit m procédé et m système de détermination d' secret commun pour deux nœuds. Chaque nœud possède me paire cryptographique asymétrique respective, chaque paire comprenant me clé privée maîtresse et me clé publique maîtresse. Des deuxièmes clés privées et publiques respectives peuvent être déterminées en fonction de la clé privée maîtresse, de la clé publique maîtresse et d'une clé déterministe. Un secret commun peut être déterminé au niveau de chacun des nœuds en fonction des deuxièmes clés privées et publiques. Dans m exemple, m nœud peut déterminer le secret commun en fonction : d'une deuxième clé privée fondée sur la propre clé privée maîtresse du nœud et la clé déterministe ; d'me deuxième clé publique fondée sur la clé publique maîtresse de l'autre nœud et de la clé déterministe. Ce procédé et ce système peuvent être adaptés à des portefeuilles numériques, des technologies à enchaînements de blocs et à la sécurité de dispositifs personnels. Avec ce procédé et ce système, il n’y a pas de partage d’m secret commun.
Le document W0 2017/145010 décrit un procédé mis en œuvre par ordinateur pour commander l’accès à une ressource informatique telle que, par exemple, un portefeuille numérique. Dans un ou plusieurs modes de réalisation, le portefeuille peut être mis en œuvre à l’aide d’une chaîne de blocs. La mise en œuvre du procédé durant la configuration initiale du portefeuille peut permettre à des opérations ultérieures, telles que des transactions de portefeuille, d’être gérées d’une manière sécurisée sur un canal non sécurisé, tel qu’Intemet. Un procédé, selon un mode de réalisation peut comprendre les étapes consistant à diviser un élément de vérification (tel qu’une clé privée dans une paire de cryptographie asymétrique) en une pluralité de parts ; à déterminer un secret partagé au niveau d’au moins deux nœuds dans un réseau ; et à utiliser le secret partagé pour transmettre au moins une part de l’élément de vérification entre lesdits deux nœuds. Les parts peuvent être divisées de telle sorte qu’aucune part toute seule n’est suffisante pour obtenir l’élément de vérification. Ceci signifie qu’aucune partie ne stocke toute la clé privée, ce qui offre une sécurité améliorée de la clé. Au moins deux parts sont nécessaires pour restaurer la clé. Les parts sont stockées à des emplacements séparés dont l’un est un emplacement de sauvegarde ou de stockage sécurisé indépendant. Si l’une des autres parts devient indisponible, la part peut être extraite de la sauvegarde pour garantir que la clé (et ainsi la ressource commandée) est toujours accessible. Pour garantir la transmission sécurisée desdites parts, le secret partagé est généré au niveau de deux nœuds différents indépendamment l'un de l'autre, puis utilisé pour générer une clé de chiffrement. La clé de chiffrement peut être utilisée pour chiffrer au moins une part de l’élément de vérification, ou un message la comprenant, pour garantir que lesdites parts sont transmises de manière sécurisée. Avec ce procédé, on ne fabrique pas un secret commun et on ne le partage pas. De plus, le processeur n’est pas de sécurité, comme cela a été précédemment défini.
Le document WO 2016/130030 décrit un procédé de protection de données à l’aide d’une cryptographie à seuil, dans lequel des données sont chiffrées à l’aide d’algorithmes cryptographiques et une clé cryptographique est divisée en parts. Le procédé de protection de données à l’aide d’une cryptographie à seuil est caractérisé en ce qu’un identificateur unique est affecté à des données chiffrées. Ensuite, au moins une part de la clé cryptographique est fusionnée avec des données chiffrées. Ensuite, les données chiffrées fusionnées avec certaines des parts de la clé sont divisées en fragments et un identificateur unique précédemment affecté aux données chiffrées est ajouté à chaque fragment. Le même identificateur unique est ajouté à la part de chaque clé qui n’a pas été fusionnée avec des données chiffrées. Les fragments obtenus de données sont déployés sur des dispositifs physiquement séparés comprenant au moins un processeur et une mémoire non volatile, et, pour chaque fragment, des informations concernant le dispositif sur lequel il est déployé sont sauvegardées. Les parts de la clé qui n’ont pas été fusionnées avec des données chiffrées sont placées sur des dispositifs physiquement séparés comprenant au moins un processeur et une mémoire non volatile, et, pour chaque part de la clé, des informations concernant le dispositif sur lequel elle est stockée sont sauvegardées. Ce brevet vise la confidentialité et non l’authentification.
Dans le document US 6 182 214, la cryptographie à seuil (partage secret) est utilisée pour échanger un secret entre un serveur et un client sur un réseau non fiable. Spécifiquement, un secret est divisé par calcul en N parts en utilisant un schéma de cryptage à seuil tel que n'importe quel M des partages (M inférieur ou égal à N) peut être utilisé pour reconstruire le secret. Les N parts sont réparties sur un certain nombre de messages transmis, en supposant qu'un certain nombre de messages comprenant un total d'au moins M actions seront reçus par le client. Lors de la réception d'au moins M partages, le client utilise au moins M partages pour reconstruire le secret en utilisant le schéma de cryptage à seuil. Ce brevet vise la confidentialité pour le transfert d’un secret et non l’authentification.
On connaît une gouvernance de sécurité dans laquelle une entité demanderesse fait une requête auprès d’un système incluant un processeur de sécurité, dont l’exécution est conditionnée par le consentement in fine auprès dudit processeur de sécurité, de personnes ou robot informatiques, lesquels ont été préalablement habilités par une autorité extérieure jouant le rôle de tiers de confiance.
Une telle gouvernance a pour faiblesse la centralisation persistante des données confidentielles dans ledit processeur de sécurité. Et que les personnes ou robot informatiques ne peuvent attester sans tiers de confiance que les données confidentielles ne seront pas utilisées autrement que pour le consentement donné. Par ailleurs, une telle gouvernance a pour contrainte de devoir recourir à un tiers de confiance et à des processus d’habilitation rigides et complexes.
Tel est le contexte de l’invention et telle est l’interprétation qu’il convient de donner aux termes précédemment définis utilisés dans le texte.
Le problème à la base de l’invention est de valider une requête numérique d’une entité demanderesse et in fine de pouvoir traiter cette requête numérique, en la soumettant au consentement préalable de plusieurs entités, sans avoir à recourir à un tiers de confiance.
La solution apportée à ce problème consiste en ce que les entités coopérantes qui doivent consentir à l’exécution de la requête moyennant la mise en œuvre des technologies de la cryptographie à seuil, alors que ces entités coopérantes vont s’authentifier mutuellement en utilisant les attestations numériques délivrées par une pluralité de processeurs de sécurité.
Ci-après, un exposé de l’invention.
Selon un premier aspect, l’invention a pour objet un procédé de validation d’une requête numérique
- dans lequel une pluralité d’entités coopérantes sont aptes à mettre en œuvre chacune un processeur de sécurité chargé avec une même application nécessaire au traitement de ladite requête, application pour laquelle chaque processeur de sécurité délivre une attestation numérique d’intégrité sur demande,
qui comporte un processus de vérification d’intégrité de ladite application tel que, à partir des attestations numériques délivrées par chaque processeur de sécurité, chaque entité de la pluralité d’entités coopérantes s’assure que chacune des autres entités de la pluralité d’entités met en œuvre une application identique à la sienne en vérifiant de façon cryptographique l’attestation numérique correspondante,
- qui comporte un processus par lequel des entités coopérantes créent un secret commun et constituent ainsi un collège d’entités coopérantes créatrices,
-- qui comporte, moyennant la mise en œuvre du processus de vérification d’intégrité de ladite application, un processus par lequel des entités du collège d’entités coopérantes créatrices désignent les entités coopérantes signataires, constituant ainsi un collège d’entités coopérantes signataires, en sorte que ledit collège d’entités coopérantes signataires pris en tant que tel ait accès au secret commun,
de sorte que ladite requête est validée si et seulement si des entités coopérantes du collège d’entités coopérantes signataires mettent en œuvre ladite application moyennant le secret commun. Selon les réalisations, un dit processeur de sécurité est apte à être mis en œuvre soit par une entité coopérante auquel cas ledit processeur de sécurité est propre à cette entité coopérante soit par plusieurs entités coopérantes auquel cas ledit processeur de sécurité est commun à ces entités coopérantes, le procédé impliquant la mise en œuvre d’au moins deux processeurs de sécurité.
Selon une caractéristique, pour que chaque processeur de sécurité délivre une attestation numérique d’intégrité sur demande :
on met en œuvre des processeurs de sécurité choisis de sorte qu’ils disposent chacun, en propre, d’une première paire de clés cryptographiques asymétriques,
- à la demande d’une ou plusieurs entités coopérantes, chaque processeur de sécurité utilise la clé privée de ladite première paire de clés pour produire une signature électronique de tout ou partie du contenu de ses mémoires,
- ladite signature électronique valant attestation numérique d’intégrité du contenu signé correspondant, et son authenticité peut être vérifiée en utilisant la partie publique de la dite première paire de clés.
Selon une caractéristique, en vue du processus de vérification d’intégrité de ladite application,
- les entités coopérantes de ladite pluralité d’entités coopérantes conviennent ensemble d’une seconde paire de clés cryptographiques asymétriques,
- la partie privée de ladite seconde paire de clés est mise en œuvre pour produire la signature électronique de la partie publique desdites premières paires de clés de chaque processeur de sécurité,
- de sorte que lesdites entités coopérantes sont aptes à authentifier, en mettant en œuvre la partie publique de ladite seconde paire de clés, les attestations numériques d’intégrité délivrées par chacun des processeurs de sécurité.
Selon les réalisations, en vue de convenir de ladite seconde paire de clés cryptographiques asymétriques, les entités coopérantes utilisent une paire de clés cryptographiques asymétriques tirée aléatoirement et partagées entre elles ou bien ladite seconde paire de clés cryptographiques asymétriques est celle d’une autorité de certification externe.
Selon une caractéristique, pour créer un secret commun :
t des entités coopérantes de la pluralité d’entités coopérantes mettent en commun des données confidentielles propres,
un traitement numérique est appliqué à l’ensemble desdites données confidentielles propres, créant ainsi ledit secret commun. Selon les réalisations, les dites données confidentielles propres sont tirées aléatoirement par chacune des entités coopérantes, et/ou introduites par les entités coopérantes dans la mémoire des processeurs de sécurité associées, et/ou extraites de la mémoire des processeurs de sécurité associés.
Selon une caractéristique, moyennant un algorithme de découpage/reconstitution, le secret commun est apte à être découpé, en parties découpées de sorte à être reconstitué ultérieurement et/ou dans lequel au moins certaines des, ou toutes les, parties découpées sont aptes et suffisantes à reconstituer ultérieurement ledit secret commun.
Selon une réalisation :
- ledit secret commun une fois créé est découpé en un nombre de parties découpées créatrices, égal au nombre d’entités coopérantes créatrices,
- et lesdites parties découpées créatrices sont réparties entre les entités coopérantes créatrices, chacune des dites entités conservant l’une desdites parties découpées créatrices,
- de sorte qu’ultérieurement, ledit secret commun puisse être reconstitué avec au moins certaines des, ou toutes les, dites parties découpées créatrices.
Selon une possibilité, ledit secret commun ne peut être utilisé que pour la validation d’une et une seule requête numérique et ne peut être stocké de manière persistante dans aucune des mémoires des processeurs de sécurité associés.
Selon une première réalisation possible, lors de la mise en œuvre du procédé de validation, il est prévu un processus de vérification d’intégrité de ladite application tel que, a partir des attestations numériques délivrées par chaque processeur de sécurité, chaque entité de la pluralité d’entités coopérantes s’assure directement que chacune des autres entités de la pluralité d’entités met en œuvre une application identique à la sienne en vérifiant de façon cryptographique l’attestation numérique correspondante.
Selon une seconde réalisation possible, lors de la mise en œuvre du procédé de validation, il est prévu un processus de vérification d’intégrité de ladite application tel que, à partir des attestations numériques délivrées par chaque processeur de sécurité, chaque entité de la pluralité d’entités coopérantes s’assure que chacune des autres entités de la pluralité d’entités met en œuvre une application identique à la sienne en vérifiant de façon cryptographique l’attestation numérique correspondante, de façon indirecte et par transitivité, en s’assurant qu’une certaine entité de la pluralité d’entités met en œuvre une application identique à la sienne en vérifiant de façon cryptographique l’attestation numérique correspondante, cette certaine entité s’étant elle-même assurée que les autres entités de la pluralité d’entités mettent en œuvre la même application. Selon une caractéristique, lesdites données confidentielles propres sont transmises de manière confidentielle, moyennant un algorithme de chiffrement et déchiffrement, entre les entités coopérantes créatrices en utilisant au moins une clé de session, ladite au moins une clé de session étant rendue inutilisable après la création d’un secret commun.
Selon une réalisation :
- Les entités coopérantes créatrices comprennent une première entité créatrice pilote et les autres entités coopérantes créatrices,
- il est utilisé une pluralité de clés de session, de sorte que chaque entité coopérante créatrice met en œuvre une clé propre pour communiquer de manière confidentielle, moyennant un algorithme de chiffrement et déchiffrement, avec ladite première entité créatrice pilote,
- ladite application intègre un algorithme d’échange des clés de session,
- ladite première entité créatrice pilote, initie ledit algorithme d’échange de clés de session avec chacune des autres entités coopérantes créatrices,
- de sorte que lesdites autres entités coopérantes créatrices transmettent, de manière confidentielle en utilisant leur propre clé de session, moyennant un algorithme de chiffrement et déchiffrement, et non rejouable, leurs dites données confidentielles propres à ladite première entité créatrice pilote,
- le procédé étant réitéré, chaque entité coopérante créatrice étant ladite première entité créatrice pilote,
de sorte que les entités coopérantes créatrices sont aptes à appliquer un traitement numérique à l’ensemble desdites données confidentielles propres, créant ainsi ledit secret commun.
Selon une réalisation :
- les entités coopérantes créatrices comprennent une seconde entité créatrice pilote et les autres entités coopérantes créatrices,
- il est utilisé une pluralité de clés de session, de sorte que chaque entité coopérante signataire met en œuvre une clé propre pour communiquer de manière confidentielle, moyennant un algorithme de chiffrement et déchiffrement, avec ladite seconde entité créatrice pilote,
- il est utilisé une pluralité de clés de session, de sorte que chaque entité coopérante créatrice met en œuvre une clé propre pour communiquer de manière confidentielle, moyennant un algorithme de chiffrement et déchiffrement, avec ladite seconde entité créatrice pilote, ladite seconde entité créatrice pilote met en œuvre un processus de vérification d’intégrité de ladite application portée par le processeur de sécurité de chaque entité coopérante signataire, de sorte que ladite seconde entité créatrice pilote s’assure que chacune des entités coopérantes signataires met en œuvre une application identique à la sienne en vérifiant de façon cryptographique l’attestation numérique correspondante,
r ladite application intègre un algorithme d’échange des clés de session,
- est initié ledit algorithme d’échange de clés de session entre, d’une part, chacune des dites autres entités coopérantes créatrices et chacune des entités coopérantes signataires et, d’autre part, ladite seconde entité créatrice pilote,
- de sorte que :
o toutes les, ou au moins certaines des - en nombre suffisant à la reconstitution du secret commun -, dites autres entités coopérantes créatrices transmettent, de manière confidentielle en utilisant leur propre clé de session, moyennant un algorithme de chiffrement et déchiffrement, et non rejouable, leurs dites parties découpées créatrices issues d’un même découpage du secret commun à ladite seconde entité créatrice pilote, o ladite seconde entité créatrice pilote reconstitue le secret commun,
o ladite seconde entité créatrice pilote découpe le secret commun en un nombre de parties découpées signataires égal au nombre d’entités coopérantes signataires, o ladite seconde entité créatrice pilote transmet, de manière confidentielle en utilisant les clés de session, moyennant un algorithme de chiffrement et déchiffrement, et non rejouable, leurs dites parties découpées signataires du secret commun aux dites entités coopérantes signataires.
Selon une réalisation, des parties découpées issues d’un même découpage du secret commun sont transmises de manière confidentielle, moyennant un algorithme de chiffrement et déchiffrement, entre les entités coopérantes en utilisant au moins une clé de session, ladite au moins une clé de session étant rendue inutilisable après la reconstitution dudit secret commun.
Selon une réalisation :
· * les entités coopérantes comprennent une entité pilote et les autres entités coopérantes,
- il est utilisé une pluralité de clés de session, de sorte que chaque entités coopérantes met en œuvre une clé propre pour communiquer de manière confidentielle, moyennant un algorithme de chiffrement et déchiffrement, avec ladite entité pilote,
% ladite application intègre un algorithme d’échange des clés de session,
s.· ladite entité pilote, initie ledit algorithme d’échange de clés de session avec chacune des autres entités coopérantes,
de sorte que toutes les, ou au moins certaines des - en nombre suffisant à la reconstitution du secret commun -, dites autres entités coopérantes transmettent, de manière confidentielle en utilisant leur propre clé de session, moyennant un algorithme de chiffrement et déchiffrement, non rejouable, leurs dites parties découpées issues d’un même découpage du secret commun à ladite entité pilote. Selon les cas, le collège d’entités coopérantes créatrices et le collège d’entités coopérantes signataires sont distincts ou bien le collège d’entités coopérantes créatrices et le collège d’entités coopérantes signataires sont au moins pour partie communs.
Selon un deuxième aspect, l’invention a pour objet un procédé de traitement d’une requête numérique d’une entité demanderesse, avec une pluralité d’entités coopérantes qui sont aptes à mettre en œuvre chacune un processeur de sécurité chargé avec une même application nécessaire au traitement de ladite requête, application pour laquelle chaque processeur de sécurité délivre une attestation numérique d’intégrité sur demande, qui met en œuvre le procédé de validation d’une requête numérique qui vient d’être décrit, de sorte que ladite requête est traitée si et seulement si des entités coopérantes du collège d’entités coopérantes signataires mettent en œuvre ladite application moyennant le secret commun.
Selon une caractéristique :
- l’entité demanderesse transmet ladite requête numérique d’une part au collège d’entités coopérantes, d’autre part à un moyen électronique apte à exécuter ladite requête,
- le collège d’entités coopérantes met en œuvre un procédé de validation, moyennant ledit secret commun, en vue de la validation de ladite requête numérique,
ledit moyen électronique exécute ladite requête numérique en fonction de ladite validation.
Selon un troisième aspect, l’invention a pour objet l’application du procédé de validation d’une requête numérique qui vient d’être décrit, à un procédé de traitement d’une requête numérique d’une entité demanderesse comme précédemment décrit ou bien, notamment, notamment un procédé de gouvernance de signature électronique, un procédé de gouvernance de chif&etiient ou déchiffrement de données, un procédé de vote électronique, un procédé de gouvernance de transactions bancaires ou monétiques.
Selon un quatrième aspect, l’invention a pour objet un système pour la mise en œuvre du procédé de validation d’une requête numérique qui vient d’être décrit, qui comporte :
- au moins deux processeurs de sécurité support d’une application nécessaire au traitement de ladite requête, mettant en œuvre des données confidentielles, et comprenant une mémoire persistante, une mémoire volatile, un calculateur apte à réaliser des fonctions cryptographiques et notamment à authentifier tout ou partie du contenu de ses mémoires en fournissant une attestation numérique d’intégrité sur demande, de sorte qu’une pluralité d’entités coopérantes sont aptes à mettre en œuvre chacune un dit processeur de sécurité, et dont le contenu des mémoires ne peut être modifié qu’avec une authentification,
- un moyen apte à créer un secret commun, »un algorithme d’attestation numérique,
- un algorithme de chiffrement et déchiffrement,
- un algorithme de découpage / reconstitution de secret commun,
- un algorithme d’échange de clés de session,
- des moyens de communication entre les processeurs de sécurité et les entités.
On décrit maintenant brièvement les figures des dessins.
La figure 1 [Fig. 1] est un schéma simplifié illustrant un exemple de réalisation possible d’un procédé de traitement d’une requête numérique mettant en œuvre un procédé de validation de la requête. Sur cette figure sont symbolisés une entité demanderesse, trois entités coopérantes, trois processeurs de sécurité, et un moyen électronique et informatique apte et destiné à exécuter la requête. Les flèches symbolisent les opérations effectuées.
La figure 2 [Fig. 2] est un schéma simplifié qui illustre deux exemples de réalisation possible en ce qui concerne les processeurs de sécurité et les entités coopérantes, à savoir une réalisation dans laquelle le processeur de sécurité est propre à une entité coopérante et une réalisation dans laquelle le processeur de sécurité est commun à plusieurs entités coopérantes.
La figure 3 [Fig. 3] est un schéma simplifié illustrant un exemple de réalisation d’un processus de vérification d’intégrité de l’application mise en œuvre, moyennant un processus cryptographique à clés cryptographiques asymétriques.
En complément, la figure 4 [Fig. 4] est un schéma simplifié correspondant à un exemple de réalisation avec une seconde paire de clés cryptographiques asymétriques.
Les figures 5 [Fig. 5] et 6 [Fig. 6] sont deux schémas simplifiés illustrant deux exemples de réalisation afin que les entités coopérantes conviennent d’une seconde paire de clés crypto graphiques asymétriques, à savoir une réalisation avec tirage aléatoire et une réalisation impliquant une autorité de certification externe.
La figure 7 [Fig. 7] est un schéma simplifié illustrant que des entités coopérantes mettent en commun des données confidentielles propres et qu’un traitement numérique est appliqué à l’ensemble de celles-ci afin de créer un secret commun. La figure 8a [Fig. 8 a] est un schéma simplifié illustrant une réalisation dans laquelle les données confidentielles propres sont tirées aléatoirement par chacune des entités coopérantes.
La figure 8b [Fig. 8b] est un schéma illustrant une autre réalisation dans laquelle les données confidentielles propres sont introduites par les entités coopérantes dans la mémoire des processeurs de sécurité associés.
La figure 9 [Fig. 9] est un schéma simplifié illustrant que, moyennant un algorithme de découpage/reconstitution, le secret commun est découpé en parties découpées puis reconstitué ultérieurement.
La figure 10 [Fig. 10] est un schéma simplifié illustrant la mise en commun des données confidentielles propres et leur le traitement numérique afin de créer un secret commun, puis son découpage au moyen d’un algorithme de découpage et sa répartition entre entités coopérantes, puis sa reconstitution au moyen d’un algorithme de reconstitution.
Les figures 11 [Fig. 11] et 12 [Fig. 12] sont deux schémas simplifiés illustrant deux exemples de réalisation possible en ce qui concerne le processus de vérification d’intégrité de l’application, à savoir une vérification directe (figure 11 [Fig. 11]) et une vérification indirecte par transitivité (figure 12 [Fig. 12] ).
Ci-après un exposé détaillé de modes d’exécution de l’invention et de différentes réalisations, assorti d’exemples et de référence aux figures. Cet exposé doit être compris dans le contexte de l’invention et avec l’interprétation des termes, comme il a été présenté précédemment.
Dans une application possible, un procédé de validation d’une requête numérique RN, selon l’invention, est appliqué à un procédé de traitement d’une requête numérique RN d’une entité demanderesse ED.
Comme il a été exposé, la gouvernance de sécurité du traitement d’une requête numérique RN doit être considérée dans son acception la plus large et générique, de sorte à inclure, notamment mais non exclusivement, un procédé de gouvernance de signature électronique, un procédé de gouvernance de chiffrement ou déchiffrement de données, un procédé de vote électronique, un procédé de gouvernance de transactions bancaires ou monétiques.
L’ entité demanderesse ED est une personne ou un robot informatique qui est apte à faire ou à procéder à la requête numérique RN et qui, concrètement fait ou procède à cette requête numérique RN.
il La requête numérique RN est un message adressé à un moyen électronique et informatique MEI approprié. Dans des réalisations possibles, une telle requête numérique RN et un tel moyen électronique et informatique MEI sont un formulaire Internet porté par un serveur, rempli par l’entité demanderesse ED.
Dans la suite du texte, le procédé de validation d’une requête numérique RN est parfois appelé, par ellipse, procédé de validation et, par analogie, le procédé de traitement d’une requête numérique RN est parfois appelé, par ellipse, procédé de traitement.
Le procédé de validation met en œuvre un système de validation SV qui comporte au moins deux processeurs de sécurité PS, support d’une application AP nécessaire au traitement de la requête RN, par suite appropriée à cette fin, et mettant en œuvre des données confidentielles DC. Un tel processeur de sécurité PS comprend une mémoire persistante, une mémoire volatile, un calculateur apte à réaliser des fonctions cryptographiques et notamment à authentifier tout ou partie du contenu de ses mémoires en fournissant une attestation numérique d’intégrité AN sur demande. L’application AP est chargée dans une mémoire d’un tel processeur de sécurité PS et exprime l’ensemble des règles exécutées avec des données confidentielles DC et des paramètres. En l’espèce, l’application AP inclut au moins un processus de création de secret commun SC.
Dans le procédé de validation, il est prévu une pluralité (au moins deux) d’entités coopérantes EC, lesquelles sont aptes et destinées à mettre en œuvre chacune un processeur de sécurité PS.
Le contenu des mémoires des processeurs de sécurité PS ne peut être modifié qu’avec une authentification, ce qui permet de qualifier les processeurs PS comme étant « de sécurité ».
Le système de validation SV comporte en outre un moyen apte et destiné à créer un secret commun SC, un algorithme d’attestation numérique, un algorithme de chiffrement et déchiffrement ALCD, un algorithme de découpage / reconstitution de secret commun SC, ALDE/ALRE, un algorithme d’échange de clés de session ALEC, des moyens de communication entre les processeurs de sécurité PS et les entités EC, ED.
Les moyens constitutifs du système de validation SV, dont sont exposés par la suite les fonctions remplies et les résultats procurés, peuvent faire l’objet de différentes réalisations, connues ou à la portée de l’homme du métier, ainsi que de réalisations équivalentes pour assurer les mêmes fonctions et procurer des résultats identiques ou analogues. Dans une réalisation possible, un processeur de sécurité PS est par exemple une carte à puce.
Dans des réalisations possibles, un moyen apte et destiné à créer un secret commun SC est fondé sur une fonction OU exclusif (souvent appelée XOR) ; un algorithme d’attestation numérique est un algorithme ECDSA (pour Elliptic Curve Digital Signature Algorithm) ; un algorithme de chiffrement et déchiffrement est un algorithme AES (pour Advanced Encryption Stamdard) ; un algorithme de découpage / reconstitution de secret commun SC est un algorithme SSS (pour Shamir’s Secret Sharing) ; un algorithme d’échange de clés de session est un algorithme SCDH (pour Elliptic Curve Diffie-Hellman), des moyens de communication entre les processeurs de sécurité PS et les entités EC, ED sont des liaisons télématiques.
Ces réalisations sont données à titre purement exemplatif. Elles ne sont pas limitatives.
Le procédé de traitement met en œuvre le procédé de validation dont il a été question précédemment, de sorte que la requête RN est traitée si et seulement si des entités coopérantes EC d’un collège d’entités coopérantes signataires COECS dont il est question par la suite, mettent en œuvre l’application AP moyennant un secret commun SC dont il est également question par la suite. Pour ce faire, l’entité demanderesse ED transmet la requête RN d’une part au collège d’entités coopérantes COEC, d’autre part à un le moyen électronique et informatique MEI, conçu et choisi de sorte à être apte et destiné à exécuter la requête RN. Le collège d’entités coopérantes COEC met en œuvre le procédé de validation, moyennant le secret commun SC, en vue de la validation de la requête RN. Le moyen électronique et informatique MEI exécute alors la requête RN en fonction de la validation.
Par « collège d’entités » on entend plusieurs entités (au moins deux) ayant pour caractéristique commune de concourir à un même processus donné, comme notamment un processus de vérification d’intégrité ou un processus de création de secret commun, dont il est question par la suite.
Le moyen électronique et informatique MEI peut faire l’objet de différentes réalisations, connues ou à la portée de l’homme du métier, en fonction de la requête RN, du service correspondant et de l’environnement dans lequel se déroule le procédé de traitement de la requête RN.
Dans des réalisations possibles, un moyen électronique et informatique MEI est un ordinateur, quel qu’en soit la forme.
Le procédé de validation permet d’assurer une gouvernance de sécurité, dans la mesure où cela conduit à vérifier la conformité de la requête numérique RN au corpus de règles définies en commun par les entités coopérantes EC, et cela en mettant en œuvre les processeurs de sécurité PS chargés de l’application AP, Les entités coopérantes EC sont, chacune, une personne ou un robot informatique apte à utiliser l’application AP.
Le procédé de traitement incluant le procédé de validation est illustré de façon simplifiée par la figure 1 [Fig. 1] représentant de façon schématique, l’entité demanderesse ED, une pluralité d’entités coopérantes EC comprenant ici trois entités, trois processeurs de sécurité PS, un par entité coopérante EC, les trois entités coopérantes EC et les trois processeurs de sécurité PS formant une sorte de « bloc » comprenant un collège d’entités coopérantes signataires COECS et leurs processeurs de sécurité PS associés, et le moyen électronique et informatique MEI apte et destiné à exécuter la requête RN. La flèche de référence a symbolise la demande de validation de la requête RN par l’entité demanderesse ED au « bloc ». Les flèches de référence b symbolisent le processus de validation de la requête RN de l’entité demanderesse ED au sein du « bloc », moyennant un processus de reconstitution de secret commun SC. La flèche de référence ç symbolise le résultat de la validation transmise par le « bloc » à l’entité demanderesse ED et la référence d symbolise la requête validée transmise au le moyen électronique et informatique MEI.
Plus précisément, le procédé de validation est tel qu’une pluralité (au moins deux) d’entités coopérantes EC sont aptes à mettre en œuvre chacune un processeur de sécurité PS chargé avec la même application AP, pour laquelle chaque processeur de sécurité PS délivre une attestation numérique AN d’intégrité sur demande.
Ainsi, la requête numérique RN est validée et in fine traitée en la soumettant au consentement préalable de plusieurs entités, sans avoir à recourir à un tiers de confiance. En effet, les entités coopérantes EC consentent à l’exécution de la requête numérique RN, moyennant la mise en œuvre des technologies de la cryptographie à seuil, alors que ces entités coopérantes EC vont s’authentifier mutuellement en utilisant les attestations numériques AN délivrées par les processeurs de sécurité PS.
On se réfère maintenant à la figure 2 [Fig. 2] qui reprend une partie de la figure 1 [Fig. 1] et illustre deux réalisations possibles en ce qui concerne les processeurs de sécurité PS et les entités coopérantes EC. Dans une première réalisation (partie droite de la figure 2 [Fig. 2]), le processeur de sécurité PS est propre à une entité coopérante EC. Dans une seconde réalisation (partie gauche de la figure 2 [Fig. 2]), le processeur de sécurité PS est commun à plusieurs entités coopérantes. Dans tous les cas, le procédé de validation implique la mise en œuvre d’au moins deux processeurs de sécurité PS.
Le procédé de validation comporte un processus de vérification d’intégrité de l’application AP tel que, à partir des attestations numériques AN délivrées par chaque processeur de sécurité PS, chaque entité EC de la pluralité d’entités coopérantes EC s’assure que chacune des autres entités EC de la pluralité d’entités EC met en œuvre une application AP identique à la sienne en vérifiant de façon cryptographique l’attestation numérique correspondante AN. A cet effet, et dans une réalisation (voir schéma de la figure 3 [Fig. 3]), moyennant la mise en œuvre d’un processus cryptographique PCR, on met en œuvre des processeurs de sécurité PS choisis de sorte qu’ils disposent chacun, en propre, d’une première paire de clés cryptographiques asymétriques CC1. A la demande d’une ou plusieurs entités coopérantes EC, chaque processeur de sécurité PS utilise la clé privée CPR1 de la première paire de clés CCI pour produire (ce qui est symbolisé par la flèche de référence a de la figure 3 [Fig. 3]) une signature électronique de tout ou partie du contenu de ses mémoires COMEM. Cette signature électronique vaut attestation numérique AN d’intégrité du contenu signé correspondant, et son authenticité peut être vérifiée en utilisant la clé publique CPU1 de la première paire de clés CCI .
De plus, (voir schéma de la figure 4 [Fig. 4] ), les entités coopérantes EC conviennent ensemble d’une seconde paire de clés cryptographiques asymétriques CC2. Puis, la clé privée CPR2 de la seconde paire de clés CC2 est mise en œuvre pour produire la signature électronique de la clé publique CPU1 des premières paires de clés CC1 de chaque processeur de sécurité PS, précédemment mentionnées. Ainsi, les entités coopérantes EC sont aptes à authentifier, en mettant en œuvre la clé publique CPU2 de la seconde paire de clés CC2, les attestations numériques AN d’intégrité délivrées par chacun des processeurs de sécurité PS. Sur la figure 4 [Fig. 4], la flèche de référence a symbolise l’extraction de la clé publique CPU1 de la première paire de clés CCI et la flèche de référence b symbolise la signature, par la clé privée CPR2 de la seconde paire de clés CC2, de la clé publique CPU1 de la première paire de clés CCI .
On peut envisager deux réalisations afin que les entités coopérantes EC conviennent d’une seconde paire de clés cryptographiques asymétriques CC2. Dans une réalisation (voir schéma de la figure 5 [Fig. 5]), les entités coopérantes EC utilisent une paire de clés cryptographiques asymétriques tirée aléatoirement et partagées entre elles. Dans une autre réalisation (voir schéma de la figure 6 [Fig. 6]), la seconde paire de clés cryptographiques asymétriques CC2 est celle d’une autorité de certification externe. Ces deux réalisations ne sont pas exclusives d’autres, différentes, connues ou à la portée de l’homme du métier, procurant un résultat analogue.
Sur la figure 5 [Fig. 5], la flèche de référence a symbolise le tirage aléatoire et le partage de la clé privée CPR2 de la seconde paire de clés CC2 et la flèche de référence b symbolise la mise en œuvre de la clé privée CPR2 de la seconde paire de clés CC2 pour fournir la signature électronique de la clé publique CPR1 de la première paire de clés CCI .
Sur la figure 6 [Fig. 6] , la flèche de référence a symbolise la fourniture de la clé publique CPU1 de la première paire de clés CCI à l’autorité de certification externe ACE, la flèche de référence b symbolise la mise en œuvre de la clé privée CPR2 de la seconde paire de clé CC2 de l’autorité de certification externe ACE pour signer la clé publique CPU1 de la première paire de clés CC1 (création d’attestation numérique AN), et la flèche de référence ç symbolise le retour de la signature électronique de la clé publique CPU1 de la première paire de clés CCI par la clé privée CPR2 de la seconde paire de clés CC2, en vue de son stockage dans le processeur de sécurité PS.
Outre le processus de vérification d’intégrité de l’application AP, le procédé de validation comporte également un processus par lequel des entités coopérantes EC créent un secret commun SC et constituent ainsi un collège d’entités coopérantes créatrices COECC.
A cet effet, et dans une réalisation (voir schéma de la figure 7 [Fig. 7]), des entités coopérantes EC mettent en commun des données confidentielles propres DC et un traitement numérique TN est appliqué à l’ensemble de ces données confidentielles propres DC afin de créer le secret commun SC.
On peut envisager plusieurs réalisations concernant les données confidentielles DC. Dans une réalisation
(voir figure 8a [Fig. 8a]), la flèche de référence b de cette figure symbolise les données confidentielles propres DC qui sont tirées aléatoirement par chacune des entités coopérantes EC. Dans une autre réalisation (voir figure 8b [Fig. 8b]), la flèche de référence a de cette figure symbolise les données confidentielles propres DC qui sont introduites par les entités coopérantes EC dans la mémoire des processeurs de sécurité PS associés. Dans une autre réalisation, les données confidentielles propres DC sont extraites de la mémoire des processeurs de sécurité PS associés. Ces réalisations peuvent éventuellement être combinées. Les différentes réalisations ne sont pas exclusives d’autres, différentes, connues ou à la portée de l’homme du métier, procurant un résultat analogue.
Comme il est illustré par la figure 9 [Fig. 9], il est prévu que, moyennant un algorithme de découpage/reconstitution ALDE/ALRE, le secret commun SC est apte à être découpé, en parties découpées PDE de sorte à être reconstitué ultérieurement.
Sur la figure 9 [Fig. 9], la flèche de référence a symbolise un tel découpage et la flèche de référence b symbolise une telle reconstitution.
Selon la réalisation représentée sur la figure 9 [Fig. 9], la reconstitution du secret commun SC peut être réalisée à partir, non de toutes les parties découpées PDE, mais seulement de certaines d’entre elles, lesquelles sont alors aptes et suffisantes à reconstituer ultérieurement dit secret commun SC. Selon une autre réalisation, toutes les parties découpées PDE sont nécessaires afin de reconstituer ultérieurement le secret commun SC.
Selon une réalisation, il est procédé à plusieurs découpages successifs du secret commun SC en parties découpées PDE. Dans ce cas, selon une réalisation, et à des fins de sécurité, le secret commun SC ne peut ensuite être reconstitué qu’à partir des parties découpées PDE issues d’un même découpage et non à partir de parties découpées PDE issues de plusieurs découpages.
Selon la réalisation représentée sur la figure 10 [Fig. 10], des entités coopérantes EC mettent en commun des données confidentielles propres DC (ce qui est symbolisé par la flèche de référence a de la figure 10 [Fig. 10]), le traitement numérique TN appliqué à l’ensemble de ces données confidentielles propres DC afin de créer le secret commun SC, comme il a été précédemment exposé. Puis, le secret commun SC ainsi créé est découpé en un nombre de parties découpées créatrices PDEC qui est égal au nombre d’entités coopérantes créatrices ECC constituant un collège COECC, au moyen d’un algorithme de découpage ALDE (ce qui est symbolisé par la flèche de référence b de la figure 10 [Fig. 10]). Les parties découpées créatrices PDEC sont alors réparties entre les entités coopérantes créatrices ECC, chacune d’elles conservant l’une des parties découpées créatrices PDEC (ce qui est symbolisé par la flèche de référence ç de la figure 10 [Fig. 10] ). Puis, au moyen d’un algorithme de reconstitution ALRE, le secret commun SC est reconstitué avec au moins certaines des (deux sur trois dans le cas de la figure 10 [Fig. 10]) parties découpées créatrices PDEC. Ou bien, dans une réalisation, le secret commun SC est reconstitué avec toutes les parties découpées créatrices PDEC.
Selon une possibilité visant à davantage de sécurité, le secret commun SC ne peut être utilisé que pour la validation d’une et une seule requête numérique RN et il ne peut être stocké de manière persistante dans aucune des mémoires des processeurs de sécurité PS associés.
Deux réalisations possibles peuvent être envisagées en ce qui concerne le processus de vérification d’intégrité de l’application AP tel que, à partir des attestations numériques AN délivrées par chaque processeur de sécurité PS, chaque entité coopérante EC s’assure que chacune des autres entités coopérantes EC met en œuvre une application AP identique à la sienne en vérifiant de façon cryptographique l’attestation numérique correspondante AN.
Selon une première réalisation possible illustrée par la figure 11 [Fig. 11] , chaque entité coopérante EC s’en assure directement. Sur la figure 11 [Fig. 11] sont représentées trois entités coopérantes EC, trois processeurs de sécurité PS avec les applications AP. Les deux flèches de référence a de la figure 11 [Fig. 11] symbolisent la délivrance par deux entités coopérantes EC à la troisième entité coopérante EC des attestations AN de leur application AP propre. La flèche de référence b de la figure 11 [Fig. 11] symbolise la vérification par la troisième entité coopérante EC que les applications des deux premières entités coopérantes EC sont identiques à la sienne. La vérification est donc directe.
Selon une seconde réalisation possible illustrée par la figure 12 [Fig. 12] , chaque entité coopérante EC s’assure que chacune des autres entités coopérantes EC met en œuvre une application AP identique à la sienne en vérifiant de façon cryptographique l’attestation numérique AN correspondante, non pas de façon directe comme dans la première réalisation, mais de façon indirecte et par transitivité, en s’assurant qu’une certaine entité coopérante ECT met en œuvre une application AP identique à la sienne en vérifiant de façon cryptographique l’attestation numérique AN correspondante, cette certaine entité coopérante ECT s’étant elle-même assurée que les autres entités coopérantes EC mettent en œuvre la même application AP. Sur la figure 12 [Fig. 12] sont représentées quatre entités coopérantes EC, dont la certaine entité ECT, quatre processeurs de sécurité PS avec les applications AP. Les deux flèches de référence a de la figure 12 [Fig. 12] symbolisent la délivrance par deux entités coopérantes EC à la certaine entité coopérante ECT, des attestations AN de leur application AP propre. La flèche de référence b de la figure 12 [Fig. 12] symbolise la vérification par cette la certaine entité coopérante ECT que les applications AP des deux premières entités coopérantes EC sont identiques à la sienne. La flèche de référence ç de la figure 12 [Fig. 12] symbolise la délivrance par la certaine entité coopérante ECT à la quatrième entité coopérante EC d’une attestation AN de son application AP propre, laquelle est identique à celle des deux premières entités coopérantes EC. Et, enfin, la flèche de référence d de la figure 12 [Fig. 12] symbolise la vérification par cette quatrième entité coopérante EC que l’application AP de la certaine entité coopérante ECT et donc aussi de manière transitive l’application AP des deux premières entités coopérantes EC sont identiques à la sienne. La vérification est donc ici indirecte.
Selon une possibilité visant à davantage de sécurité, les données confidentielles propres DC sont transmises de manière confidentielle, moyennant un algorithme de chiffrement et déchiffrement, entre les entités coopérantes créatrices ECC, en utilisant au moins une clé de session, laquelle clé de session est rendue inutilisable après la création d’un secret commun SC.
De même, des parties découpées PDE issues d’un même découpage du secret commun SC sont transmises de manière confidentielle, moyennant un algorithme de chiffrement et déchiffrement, entre les entités coopérantes EC en utilisant au moins une clé de session, la clé de session étant rendue inutilisable après la reconstitution dudit secret commun SC.
Selon une réalisation possible, les entités coopérantes créatrices ECC comprennent une première entité créatrice pilote ECCP1 et les autres entités coopérantes créatrices ECCA1.
Il est utilisé une pluralité de clés de session, de sorte que chaque entité coopérante créatrice ECC met en œuvre une clé propre pour communiquer de manière confidentielle, moyennant un algorithme de chiffrement et déchiffrement ALCD, avec la première entité créatrice pilote ECCP1. L’application AP intègre un algorithme d’échange des clés de session, ALEC. Et, la première entité créatrice pilote ECCP1 initie l’algorithme d’échange de clés de session ALEC avec chacune des autres entités coopérantes créatrices ECCA1. Ce faisant, les autres entités coopérantes créatrices ECCA1 transmettent, de manière confidentielle en utilisant leur propre clé de session, moyennant un algorithme de chiffrement et déchiffrement ALCD, et non rejouable, leurs données confidentielles propres DC à la première entité créatrice pilote ECCP1.
Le procédé est ensuite réitéré, chaque entité coopérante créatrice ECC devenant la première entité créatrice pilote ECCP 1.
Ainsi, les entités coopérantes créatrices ECC sont aptes à appliquer un traitement numérique à l’ensemble des données confidentielles propres DC, créant ainsi le secret commun SC.
Selon une autre réalisation possible, les entités coopérantes créatrices ECC comprennent une seconde entité créatrice pilote ECCP2 et les autres entités coopérantes créatricesECCA2.
Il est utilisé une pluralité de clés de session, de sorte que chaque entité coopérante signataire ECS met en œuvre une clé propre pour communiquer de manière confidentielle, moyennant un algorithme de chiffrement et déchiffrement ALCD, avec la seconde entité créatrice pilote ECCP2.
Il est aussi utilisé une pluralité de clés de session, de sorte que chaque entité coopérante créatrice ECC met en œuvre une clé propre pour communiquer de manière confidentielle, moyennant un algorithme de chiffrement et déchiffrement ALCD, avec la seconde entité créatrice pilote ECCP2.
La seconde entité créatrice pilote ECCP2 met en œuvre un processus de vérification d’intégrité de l’application AP portée par le processeur de sécurité PS de chaque entité coopérante signataire ECS, de sorte que la seconde entité créatrice pilote ECCP2 s’assure que chacune des entités coopérantes signataires ECS met en œuvre une application AP identique à la sienne en vérifiant de façon cryptographique l’attestation numérique AN correspondante.
L’application AP intègre un algorithme d’échange des clés de session ALEC. Puis, est initié l’algorithme d’échange de clés de session ALEC entre, d’une part, chacune des autres entités coopérantes créatrices ECCA2 et chacune des entités coopérantes signataires ECS et, d’autre part, la seconde entité créatrice pilote ECCP2.
Ainsi, toutes les, ou au moins certaines des (en nombre suffisant à la reconstitution du secret commun SC) autres entités coopérantes créatrices ECCA2 transmettent, de manière confidentielle en utilisant leur propre clé de session, moyennant un algorithme de chiffrement et déchiffrement ALCD, et non rejouable, leurs parties découpées créatrices PDEC issues d’un même découpage du secret commun SC à la seconde entité créatrice pilote ECCP2.
La seconde entité créatrice pilote ECCP2 reconstitue le secret commun SC.
La seconde entité créatrice pilote ECCP2 découpe le secret commun SC en un nombre de parties découpées signataires PDES égal au nombre d’entités coopérantes signataires ES.
La seconde entité créatrice pilote ECCP2 transmet, de manière confidentielle en utilisant les clés de session, moyennant un algorithme de chiffrement et déchiffrement ALCD, et non rejouable, leurs parties découpées signataires PDES du secret commun SC aux entités coopérantes signataires ECS.
Selon une réalisation possible, les entités coopérantes EC comprennent une entité pilote ECP et les autres entités coopérantes ECA. Il est utilisé une pluralité de clés de session, de sorte que chaque entités coopérantes EC met en œuvre une clé propre pour communiquer de manière confidentielle, moyennant un algorithme de chiffrement et déchiffrement ALCD, avec l’entité pilote ECP. L’application AP intègre un algorithme d’échange des clés de session ALEC. L’entité pilote ECP initie l’algorithme d’échange de clés de session ALEC avec chacune des autres entités coopérantes EC. Ainsi, toutes les, ou au moins certaines des (en nombre suffisant à la reconstitution du secret commun SC) autres entités coopérantes ECA transmettent, de manière confidentielle en utilisant leur propre clé de session, moyennant un algorithme de chiffrement et déchiffrement ALCD, non rejouable, leurs parties découpées PDE issues d’un même découpage du secret commun SC à l’entité pilote ECP.
Comme il résulte de l’exposé qui précède, le procédé de validation comporte, moyennant la mise en œuvre du processus de vérification d’intégrité de l’application AP, un processus par lequel des entités ECC du collège d’entités coopérantes créatrices COECC désignent les entités coopérantes signataires ES, constituant ainsi un collège d’entités coopérantes signataires COECS. Ce collège d’entités coopérantes signataires COES, pris en tant que tel, a accès au secret commun SC.
Finalement, la requête RN est validée si et seulement si des entités coopérantes ECS du collège d’entités coopérantes signataires COECS mettent en œuvre l’application AP moyennant le secret commun SC. Selon les cas, il s’agit de toutes les entités coopérantes signataires ou seulement d’un quorum du collège d’entités coopérantes signataires COECS.
Selon les cas, le collège d’entités coopérantes créatrices COECC et le collège d’entités coopérantes signataires COECS sont distincts ou bien le collège d’entités coopérantes créatrices COECC et le collège d’entités coopérantes signataires COECS sont au moins pour partie communs.

Claims

Revendications
1. Procédé de validation d’une requête numérique (RN) :
dans lequel une pluralité d’entités coopérantes (EC) sont aptes à mettre en œuvre chacune un processeur de sécurité (PS) chargé avec une même application (APP) nécessaire au traitement de ladite requête (RN), application (APP) pour laquelle chaque processeur de sécurité (PS) délivre une attestation numérique (AN) d’intégrité sur demande,
qui comporte un processus de vérification d’intégrité de ladite application (APP) tel que, à partir des attestations numériques (AN) délivrées par chaque processeur de sécurité (PS), chaque entité (EC) de la pluralité d’entités coopérantes (EC) s’assure que chacune des autres entités (EC) de la pluralité d’entités (EC) met en œuvre une application (APP) identique à la sienne en vérifiant de façon cryptographique l’attestation numérique (AN) correspondante, qui comporte un processus par lequel des entités coopérantes (ECC) créent un secret commun (SC) et constituent ainsi un collège d’entités coopérantes créatrices (COECC),
qui comporte, moyennant la mise en œuvre du processus de vérification d’intégrité de ladite . application (APP), un processus par lequel des entités (ECC) du collège d’entités coopérantes créatrices (COECC) désignent les entités coopérantes signataires (ECS), constituant ainsi un collège d’entités coopérantes signataires (COECS), en sorte que ledit collège d’entités coopérantes signataires (COECS) pris en tant que tel ait accès au secret commun (SC), de sorte que ladite requête (RN) est validée si et seulement si des entités coopérantes (ECS) du collège d’entités coopérantes signataires (COECS) mettent en œuvre ladite application (APP) moyennant le secret commun (SC).
2. Procédé de validation d’une requête numérique (RN) selon la revendication 1 , dans lequel un dit processeur de sécurité (PS) est apte à être mis en œuvre soit par une entité coopérante (EC) auquel cas ledit processeur de sécurité (PS) est propre à cette entité coopérante (EC) soit par plusieurs entités coopérantes (EC) auquel cas ledit processeur de sécurité (PS) est commun à ces entités coopérantes (EC), le procédé impliquant la mise en œuvre d’au moins deux processeurs de sécurité (PS).
3. Procédé de validation d’une requête numérique (RN) selon l’une des revendications 1 et 2, dans lequel pour que chaque processeur de sécurité (PS) délivre une attestation numérique (AN) d’intégrité sur demande :
on met en œuvre des processeurs de sécurité (PS) choisis de sorte qu’ils disposent chacun, en propre, d’une première paire de clés cryptographiques asymétriques (CCI),
à la demande d’une ou plusieurs entités coopérantes (EC), chaque processeur de sécurité (PS) utilise la clé privée (CPR1) de ladite première paire de clés (CC1) pour produire une signature électronique de tout ou partie du contenu de ses mémoires,
ladite signature électronique valant attestation numérique (AN) d’intégrité du contenu signé correspondant, et son authenticité peut être vérifiée en utilisant la partie publique (CPU1) de la dite première paire de clés (CCI).
4. Procédé de validation d’une requête numérique (RN) selon l’une des revendications 1 à 3, dans lequel, en outre, en vue du processus de vérification d’intégrité de ladite application (APP), les entités coopérantes (EC) de ladite pluralité d’entités coopérantes (COEC) conviennent ensemble d’une seconde paire de clés cryptographiques asymétriques (CC2),
la partie privée (CPR2) de ladite seconde paire de clés (CC2) est mise en œuvre pour produire la signature électronique de la partie publique (CPU1) desdites premières paires de clés (CCI) de chaque processeur de sécurité (PS),
de sorte que lesdites entités coopérantes (EC) sont aptes à authentifier, en mettant en œuvre la partie publique (CPU2) de ladite seconde paire de clés (CC2), les attestations numériques (AN) d’intégrité délivrées par chacun des processeurs de sécurité (PS).
5. Procédé de validation d’une requête numérique (RN) selon la revendication 4, dans lequel, en vue de convenir de ladite seconde paire de clés cryptographiques asymétriques (CC2°, les entités coopérantes (EC) utilisent une paire de clés cryptographiques asymétriques tirée aléatoirement et partagées entre elles.
6. Procédé de validation d’une requête numérique (RN) selon la revendication 4, dans lequel, ladite seconde paire de clés cryptographiques asymétriques (CC2) est celle d’une autorité de certification externe (ACE).
7. Procédé de validation d’une requête numérique (RN) selon l’une des revendications 1 à 6, dans lequel, pour créer un secret commun (SC) :
des entités coopérantes (EC) de la pluralité d’entités coopérantes (EC) mettent en commun des données confidentielles propres (DC),
un traitement numérique (TN) est appliqué à l’ensemble desdites données confidentielles propres (DC), créant ainsi ledit secret commun (SC).
8. Procédé de validation d’une requête numérique (RN) selon la revendication 7 dans lequel les dites données confidentielles propres (DC) sont tirées aléatoirement par chacune des entités coopérantes (EC), et/ou introduites par les entités coopérantes (EC) dans la mémoire des processeurs de sécurité (PS) associées, et/ou extraites de la mémoire des processeurs de sécurité (PS) associés.
9. Procédé de validation d’une requête numérique (RN) selon l’une des revendications 1 à 8, dans lequel moyennant un algorithme de découpage/reconstitution (ALDE/ARE), le secret commun (SC) est apte à être découpé, en parties découpées (PDE) de sorte à être reconstitué ultérieurement et/ou dans lequel au moins certaines des, ou toutes les, parties découpées (PDE) sont aptes et suffisantes à reconstituer ultérieurement ledit secret commun (SC).
10. Procédé de validation d’une requête numérique (RN) selon la revendication 9, dans lequel : ledit secret commun (SC) une fois créé est découpé en un nombre de parties découpées créatrices (PDEC), égal au nombre d’entités coopérantes créatrices (ECC), et lesdites parties découpées créatrices (PDEC) sont réparties entre les entités coopérantes créatrices (ECC), chacune des dites entités (ECC) conservant l’une desdites parties découpées créatrices (PDEC),
de sorte qu’ultérieurement, ledit secret commun (SC) puisse être reconstitué avec au moins certaines des, ou toutes les, dites parties découpées créatrices (PDEC).
11. Procédé de validation d’une requête numérique (RN) selon l’une des revendications 1 à 10, dans lequel ledit secret commun (SC) ne peut être utilisé que pour la validation d’une et une seule requête numérique (RN) et ne peut être stocké de manière persistante dans aucune des mémoires des processeurs de sécurité (PS) associés.
12. Procédé de validation d’une requête numérique (RN) selon l’une des revendications 1 à 11, dans lequel lors de sa mise en œuvre, un processus de vérification d’intégrité de ladite application (APP) tel que, à partir des attestations numériques (AN) délivrées par chaque processeur de sécurité (PS), chaque entité (EC) de la pluralité d’entités coopérantes (EC) s’assure directement que chacune des autres entités (EC) de la pluralité d’entités (EC) met en œuvre une application (APP) identique à la sienne en vérifiant de façon cryptographique l’attestation numérique (AN) correspondante.
13. Procédé de validation d’une requête numérique (RN) selon l’une des revendications 1 à 11 dans lequel lors de sa mise en œuvre, un processus de vérification d’intégrité de ladite application (APP) tel que, à partir des attestations numériques (AN) délivrées par chaque processeur de sécurité (PS), chaque entité (EC) de la pluralité d’entités coopérantes (EC) s’assure que chacune des autres entités (EC) de la pluralité d’entités (EC) met en œuvre une application (APP) identique à la sienne en vérifiant de façon cryptographique l’attestation numérique (AN) correspondante, de façon indirecte et par transitivité, en s’assurant qu’une certaine entité (ECT) de la pluralité d’entités met en œuvre une application (APP) identique à la sienne en vérifiant de façon cryptographique l’attestation numérique (AN) correspondante, cette certaine entité (ECT) s’étant elle-même assurée que les autres entités (EC) de la pluralité d’entités (EC) mettent en œuvre la même application (APP).
14. Procédé de validation d’une requête numérique (RN) selon l’une des revendications 7 à 13 en ce qu’elles dépendent de la revendication 7, dans lequel lesdites données confidentielles propres (DC) sont transmises de manière confidentielle, moyennant un algorithme de chiffrement et déchiffrement (ALCD), entre les entités coopérantes créatrices (ECC) en utilisant au moins une clé de session, ladite au moins une clé de session étant rendue inutilisable après la création d’un secret commun (SC).
15. Procédé de validation d’une requête numérique (RN) selon l’une des revendications 7 à 14 en ce qu’elles dépendent de la revendication 7, dans lequel :
les entités coopérantes créatrices (ECC) comprennent une première entité créatrice pilote (ECCP1) et les autres entités coopérantes créatrices (ECCA),
il est utilisé une pluralité de clés de session, de sorte que chaque entité coopérante créatrice (ECC) met en œuvre une clé propre pour communiquer de manière confidentielle, moyennant un algorithme de chiffrement et déchiffrement (ALCD), avec ladite première entité créatrice pilote (ECCP1), ladite application (APP) intègre un algorithme d’échange des clés de session (ALEC), ladite première entité créatrice pilote (ECCP1), initie ledit algorithme d’échange de clés de session (ALEC) avec chacune des autres entités coopérantes créatrices (ECCA),
de sorte que lesdites autres entités coopérantes créatrices (ECCA) transmettent, de manière confidentielle en utilisant leur propre clé de session, moyennant un algorithme de chiffrement et déchiffrement (ALCD), et non rejouable, leurs dites données confidentielles propres (DC) à ladite première entité créatrice pilote (ECCP 1),
le procédé étant réitéré, chaque entité coopérante créatrice (ECC) étant ladite première entité créatrice pilote (ECCP 1),
de sorte que les entités coopérantes créatrices (ECC) sont aptes à appliquer un traitement numérique (TN) à l’ensemble desdites données confidentielles propres (DC), créant ainsi ledit secret commun (SC).
16. Procédé de validation d’une requête numérique (RN) selon l’une des revendications 9 à 15, en ce qu’elles dépendent de la revendication 9, dans lequel :
les entités coopérantes créatrices (ECC) comprennent une seconde entité créatrice pilote (ECCP2) et les autres entités coopérantes créatrices (ECCA),
il est utilisé une pluralité de clés de session, de sorte que chaque entité coopérante signataire (ECS) met en œuvre une clé propre pour communiquer de manière confidentielle, moyennant un algorithme de chiffrement et déchiffrement (ALCD), avec ladite seconde entité créatrice pilote (ECCP2),
il est utilisé une pluralité de clés de session, de sorte que chaque entité coopérante créatrice (EC) met en œuvre une clé propre pour communiquer de manière confidentielle, moyennant un algorithme de chiffrement et déchiffrement (ALCD), avec ladite seconde entité créatrice pilote (ECCP2),
ladite seconde entité créatrice pilote (ECCP2) met en œuvre un processus de vérification d’intégrité de ladite application (APP) portée par le processeur de sécurité (PS) de chaque entité coopérante signataire (ECS), de sorte que ladite seconde entité créatrice pilote (ECCP2) s’assure que chacune des entités coopérantes signataires (ECS) met en œuvre une application (APP) identique à la sienne en vérifiant de façon cryptographique l’attestation numérique (AN) correspondante,
ladite application (APP) intègre un algorithme d’échange des clés de session (ALEC), est initié ledit algorithme d’échange de clés de session (ALEC) entre, d’une part, chacune des dites autres entités coopérantes créatrices (ECCA) et chacune des entités coopérantes signataires (ECS) et, d’autre part, ladite seconde entité créatrice pilote (ECCP2),
de sorte que :
toutes les, ou au moins certaines des - en nombre suffisant à la reconstitution du secret commun (SC) -, dites autres entités coopérantes créatrices (ECC) transmettent, de manière confidentielle en utilisant leur propre clé de session, moyennant un algorithme de chiffrement et déchiffrement (ALCD), et non rejouable, leurs dites parties découpées créatrices (PDEC) issues d’un même découpage du secret commun (SC) à ladite seconde entité créatrice pilote (ECCP2),
ladite seconde entité créatrice pilote (ECCP2) reconstitue le secret commun (SC), ladite seconde entité créatrice pilote (ECCP2) découpe le secret commun (SC) en un nombre de parties découpées (PDE) signataires égal au nombre d’entités coopérantes signataires (ECS),
ladite seconde entité créatrice pilote (ECCP2) transmet, de manière confidentielle en utilisant les clés de session, moyennant un algorithme de chiffrement et déchiffrement (ALCD), et non rejouable, leurs dites parties découpées (PDE) signataires du secret commun (SC) aux dites entités coopérantes signataires (ECS).
17. Procédé de validation d’une requête numérique (RN) selon l’une des revendications 14 à 16 en ce qu’elle dépend de la revendication 9, dans lequel des parties découpées (PDE) issues d’un même découpage du secret commun (SC) sont transmises de manière confidentielle, moyennant un algorithme de chiffrement et déchiffrement (ALCD), entre les entités coopérantes (EC) en utilisant au moins une clé de session, ladite au moins mie clé de session étant rendue inutilisable après la reconstitution dudit secret commun (SC).
18. Procédé de validation d’une requête numérique (RN) selon l’une des revendications 14 à 16 en ce qu’elle dépend de la revendication 9, dans lequel :
les entités coopérantes (EC) comprennent une entité pilote (ECP) et les autres entités coopérantes (ECA),
il est utilisé une pluralité de clés de session, de sorte que chaque entités coopérantes (EC) met en œuvre une clé propre pour communiquer de manière confidentielle, moyennant un algorithme de chiffrement et déchiffrement (ALCD), avec ladite entité pilote (ECP), ladite application (APP) intègre un algorithme d’échange des clés de session (ALEC), ladite entité pilote (ECP), initie ledit algorithme d’échange de clés de session (ALEC) avec chacune des autres entités coopérantes (EC),
de sorte que toutes les, ou au moins certaines des - en nombre suffisant à la reconstitution du secret commun (SC) -, dites autres entités coopérantes (EC) transmettent, de manière confidentielle en utilisant leur propre clé de session, moyennant un algorithme de chiffrement et déchiffrement (ALCD), non rejouable, leurs dites parties découpées (PDE) issues d’un même découpage du secret commun (SC) à ladite entité pilote (ECP).
19. Procédé de validation d’une requête numérique (RN) selon l’une des revendications 1 à 18, dans lequel le collège d’entités coopérantes créatrices (COECC) et le collège d’entités coopérantes signataires (COECS) sont distincts.
20. Procédé de validation d’une requête numérique (RN) selon l’une des revendications 1 à 18, dans lequel le collège d’entités coopérantes créatrices (COECC) et le collège d’entités coopérantes signataires (COECS) sont au moins pour partie communs.
21. Procédé de traitement d’une requête numérique (RN) d’une entité demanderesse (ED), avec une pluralité d’entités coopérantes (EC) qui sont aptes à mettre en œuvre chacune un processeur de sécurité (PS) chargé avec une même application (APP) nécessaire au traitement de ladite requête (RN), application (APP) pour laquelle chaque processeur de sécurité (PS) délivre une attestation numérique (AN) d’intégrité sur demande, qui met en œuvre le procédé de validation d’une requête numérique (RN) selon l’une des revendications 1 à 20, de sorte que ladite requête (RN) est traitée si et seulement si des entités coopérantes (ECS) du collège d’entités coopérantes signataires (COECS) mettent en œuvre ladite application (APP) moyennant le secret commun (SC).
22. Procédé de traitement d’une requête numérique (RN) d’une entité demanderesse (ED) selon la revendication 21, dans lequel :
l’entité demanderesse (ED) transmet ladite requête numérique (RN) d’une part au collège d’entités coopérantes (COEC), d’autre part à un moyen électronique informatique (MEI) apte à exécuter ladite requête (RN),
le collège d’entités coopérantes (EC) met en œuvre un procédé de validation, moyennant ledit secret commun (SC), en vue de la validation de ladite requête numérique (RN),
ledit moyen électronique informatique (MEI) exécute ladite requête numérique (RN) en fonction de ladite validation.
23. Application du procédé de validation d’une requête numérique (RN) selon l’une des revendications 1 à 20, à un procédé de traitement d’une requête numérique (RN) d’une entité demanderesse (ED), notamment un procédé de gouvernance de signature électronique, un procédé de gouvernance de chiffrement ou déchiffrement de données, un procédé de vote électronique, un procédé de gouvernance de transactions bancaires ou monétiques.
24. Système pour la mise en œuvre du procédé de validation d’une requête numérique (RN) par une entité demanderesse (ED), selon l’une des revendications 1 à 20, qui comporte :
au moins deux processeurs de sécurité (PS) support d’une application (APP) nécessaire au traitement de ladite requête (RN), mettant en œuvre des données confidentielles (DC), et comprenant une mémoire persistante, une mémoire volatile, un calculateur apte à réaliser des fonctions cryptographiques et notamment à authentifier tout ou partie du contenu de ses mémoires en fournissant une attestation numérique (AN) d’intégrité sur demande, de sorte qu’une pluralité d’entités coopérantes (EC) sont aptes à mettre en œuvre chacune un dit processeur de sécurité (PS), et dont le contenu des mémoires ne peut être modifié qu’avec une authentification, un moyen apte à créer un secret commun (SC),
un algorithme d’attestation numérique (AN),
un algorithme de chiffrement et déchiffrement (ALCD)
un algorithme de découpage / reconstitution (ALDE/ALRE) de secret commun (SC), un algorithme d’échange de clés de session (ALEC),
des moyens de communication entre les processeurs de sécurité (PS) et les entités.
PCT/FR2019/000113 2018-07-11 2019-07-11 Gouvernance de sécurité du traitement d'une requête numérique WO2020012079A1 (fr)

Priority Applications (8)

Application Number Priority Date Filing Date Title
SG11202100263PA SG11202100263PA (en) 2018-07-11 2019-07-11 Security governance of the processing of a digital request
JP2021500594A JP2021525993A (ja) 2018-07-11 2019-07-11 デジタルリクエストの処理のセキュリティガバナンス
AU2019300287A AU2019300287A1 (en) 2018-07-11 2019-07-11 Security governance of the processing of a digital request
CA3105894A CA3105894A1 (fr) 2018-07-11 2019-07-11 Gouvernance de securite du traitement d'une requete numerique
US17/259,113 US11757660B2 (en) 2018-07-11 2019-07-11 Security governance of the processing of a digital request
KR1020217004291A KR20210028719A (ko) 2018-07-11 2019-07-11 디지털 요청 처리의 보안 거버넌스
EP19745659.3A EP3821564A1 (fr) 2018-07-11 2019-07-11 Gouvernance de sécurité du traitement d'une requête numérique
CN201980053226.9A CN112970226A (zh) 2018-07-11 2019-07-11 数字请求的处理的安全管理

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1870826 2018-07-11
FR1870826A FR3085815B1 (fr) 2018-07-11 2018-07-11 Gouvernance de securite du traitement d'une requete numerique

Publications (1)

Publication Number Publication Date
WO2020012079A1 true WO2020012079A1 (fr) 2020-01-16

Family

ID=65031569

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2019/000113 WO2020012079A1 (fr) 2018-07-11 2019-07-11 Gouvernance de sécurité du traitement d'une requête numérique

Country Status (10)

Country Link
US (1) US11757660B2 (fr)
EP (1) EP3821564A1 (fr)
JP (1) JP2021525993A (fr)
KR (1) KR20210028719A (fr)
CN (1) CN112970226A (fr)
AU (1) AU2019300287A1 (fr)
CA (1) CA3105894A1 (fr)
FR (1) FR3085815B1 (fr)
SG (1) SG11202100263PA (fr)
WO (1) WO2020012079A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115549929B (zh) * 2022-11-30 2023-03-10 北京时代亿信科技股份有限公司 基于零信任网络隐身的spa单包认证方法及装置

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995005712A2 (fr) 1993-08-13 1995-02-23 Frank Thomson Leighton Echange de codes secrets
US5815573A (en) 1996-04-10 1998-09-29 International Business Machines Corporation Cryptographic key recovery system
US6182214B1 (en) 1999-01-08 2001-01-30 Bay Networks, Inc. Exchanging a secret over an unreliable network
WO2003077470A1 (fr) 2002-03-13 2003-09-18 Koninklijke Philips Electronics N.V. Generation de cle a utilisateurs multiples a base polynomiale ainsi que procede et systeme d'authentification
WO2015118160A1 (fr) * 2014-02-10 2015-08-13 Thomson Licensing Procédés de signature pour distribuer des signatures partielles et/ou des signatures-seuils, procédés de validation correspondants et dispositifs électroniques correspondants
US20150229480A1 (en) * 2014-02-10 2015-08-13 Thomson Licensing Signing method delivering a partial signature associated with a message, threshold signing method, signature verification method, and corresponding computer program and electronic devices
WO2015160839A1 (fr) * 2014-04-17 2015-10-22 Hrl Laboratories, Llc Procédé de génération distribuée sécurisée et flexible de signatures numériques à sécurité proactive basées sur un algorithme de signature numérique à courbe elliptique (ecdsa)
WO2016130030A1 (fr) 2015-02-10 2016-08-18 Nord-Systems Sp. Z O.O. Procédé de protection de données à l'aide d'une cryptographie de seuil
WO2017064124A1 (fr) 2015-10-15 2017-04-20 Robert Bosch Gmbh Agencement de circuits de génération d'un secret ou d'une clé dans un réseau
WO2017145016A1 (fr) 2016-02-23 2017-08-31 nChain Holdings Limited Détermination d'un secret commun pour l'échange sécurisé d'informations et de clés cryptographiques déterministes et hiérarchiques
WO2017145010A1 (fr) 2016-02-23 2017-08-31 nChain Holdings Limited Stockage sécurisé résistant à une perte multipartite et transfert de clés cryptographiques pour des systèmes basés sur une chaîne de blocs conjointement avec un système de gestion de portefeuille

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10198272A (ja) * 1996-12-27 1998-07-31 Canon Inc 階層を有する鍵管理方法及び暗号システム、分散デジタル署名システム
US6246771B1 (en) * 1997-11-26 2001-06-12 V-One Corporation Session key recovery system and method
EP1254547B1 (fr) * 2000-02-08 2005-11-23 Swisscom Mobile AG Procede de demande de connexion unique
JP2005223773A (ja) * 2004-02-09 2005-08-18 Hitachi Ltd グループ内共通鍵の生成と共有方法およびその装置
JP4551202B2 (ja) * 2004-12-07 2010-09-22 株式会社日立製作所 アドホックネットワークの認証方法、および、その無線通信端末
WO2008085579A2 (fr) * 2006-10-25 2008-07-17 Spyrus, Inc. Procédé et système pour déployer des algorithmes cryptographiques avancés
WO2008147577A2 (fr) * 2007-01-22 2008-12-04 Spyrus, Inc. Dispositif de chiffrement de données portable avec fonctionnalité de sécurité configurable et procédé de chiffrement de fichier
US8588746B2 (en) * 2009-10-31 2013-11-19 SAIFE Technologies Incorporated Technique for bypassing an IP PBX
US9887989B2 (en) * 2012-06-23 2018-02-06 Pomian & Corella, Llc Protecting passwords and biometrics against back-end security breaches
US9124433B2 (en) * 2012-12-28 2015-09-01 Vasco Data Security, Inc. Remote authentication and transaction signatures
DE102013203257A1 (de) * 2013-02-27 2014-08-28 Bundesdruckerei Gmbh Lesen eines Attributs aus einem ID-Token
CA2855099C (fr) * 2013-06-27 2016-05-17 Infosec Global Inc. Protocole d'entente principale destine a generer une cle secrete partagee utilisee par une paire d'entites dans un systeme de communication de donnees
BR112017014632B1 (pt) * 2015-01-27 2023-12-26 Visa International Service Association Método implementado por computador, sistema de computador, e, mídia legível de computador
US10079677B2 (en) * 2015-06-05 2018-09-18 Apple Inc. Secure circuit for encryption key generation
CN107924437A (zh) * 2015-06-17 2018-04-17 瑞典爱立信有限公司 用于使得能够实现凭证的安全供应的方法以及相关无线装置和服务器
JP6449131B2 (ja) * 2015-10-23 2019-01-09 Kddi株式会社 通信装置、通信方法、およびコンピュータプログラム
US10158991B2 (en) * 2016-03-17 2018-12-18 M2MD Technologies, Inc. Method and system for managing security keys for user and M2M devices in a wireless communication network environment
WO2017201406A1 (fr) * 2016-05-19 2017-11-23 Arris Enterprises Llc Certificats rsa implicites
US20180007037A1 (en) * 2016-07-01 2018-01-04 Kenneth Wade Reese Transaction-specific shared secret in one-time password device
US10129223B1 (en) * 2016-11-23 2018-11-13 Amazon Technologies, Inc. Lightweight encrypted communication protocol
US10516543B2 (en) * 2017-05-08 2019-12-24 Amazon Technologies, Inc. Communication protocol using implicit certificates
US10797868B2 (en) * 2018-05-31 2020-10-06 Irdeto B.V. Shared secret establishment

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995005712A2 (fr) 1993-08-13 1995-02-23 Frank Thomson Leighton Echange de codes secrets
US5815573A (en) 1996-04-10 1998-09-29 International Business Machines Corporation Cryptographic key recovery system
US6182214B1 (en) 1999-01-08 2001-01-30 Bay Networks, Inc. Exchanging a secret over an unreliable network
WO2003077470A1 (fr) 2002-03-13 2003-09-18 Koninklijke Philips Electronics N.V. Generation de cle a utilisateurs multiples a base polynomiale ainsi que procede et systeme d'authentification
WO2015118160A1 (fr) * 2014-02-10 2015-08-13 Thomson Licensing Procédés de signature pour distribuer des signatures partielles et/ou des signatures-seuils, procédés de validation correspondants et dispositifs électroniques correspondants
US20150229480A1 (en) * 2014-02-10 2015-08-13 Thomson Licensing Signing method delivering a partial signature associated with a message, threshold signing method, signature verification method, and corresponding computer program and electronic devices
WO2015160839A1 (fr) * 2014-04-17 2015-10-22 Hrl Laboratories, Llc Procédé de génération distribuée sécurisée et flexible de signatures numériques à sécurité proactive basées sur un algorithme de signature numérique à courbe elliptique (ecdsa)
WO2016130030A1 (fr) 2015-02-10 2016-08-18 Nord-Systems Sp. Z O.O. Procédé de protection de données à l'aide d'une cryptographie de seuil
WO2017064124A1 (fr) 2015-10-15 2017-04-20 Robert Bosch Gmbh Agencement de circuits de génération d'un secret ou d'une clé dans un réseau
WO2017145016A1 (fr) 2016-02-23 2017-08-31 nChain Holdings Limited Détermination d'un secret commun pour l'échange sécurisé d'informations et de clés cryptographiques déterministes et hiérarchiques
WO2017145010A1 (fr) 2016-02-23 2017-08-31 nChain Holdings Limited Stockage sécurisé résistant à une perte multipartite et transfert de clés cryptographiques pour des systèmes basés sur une chaîne de blocs conjointement avec un système de gestion de portefeuille

Also Published As

Publication number Publication date
CA3105894A1 (fr) 2020-01-16
JP2021525993A (ja) 2021-09-27
EP3821564A1 (fr) 2021-05-19
SG11202100263PA (en) 2021-02-25
FR3085815A1 (fr) 2020-03-13
CN112970226A (zh) 2021-06-15
FR3085815B1 (fr) 2022-07-15
AU2019300287A1 (en) 2021-01-28
US11757660B2 (en) 2023-09-12
KR20210028719A (ko) 2021-03-12
US20210306162A1 (en) 2021-09-30

Similar Documents

Publication Publication Date Title
US11689371B2 (en) Techniques for securing digital signatures using multi-party computation
US20210357915A1 (en) Methods, devices, and systems for secure payments
EP3547203A1 (fr) Méthode et système de gestion d'accès à des données personnelles au moyen d'un contrat intelligent
TW201733302A (zh) 用於基於區塊鏈的系統結合錢包管理系統中的安全多方防遺失儲存及加密金鑰轉移
FR2952778A1 (fr) Procede de transmission de donnees securise et systeme de chiffrement et de dechiffrement permettant une telle transmission
EP1807967B1 (fr) Procede de delegation securisee de calcul d'une application bilineaire
US12014361B2 (en) Systems and methods for improved hot wallet security
EP3446436A1 (fr) Procédé d'obtention par un terminal mobile d'un jeton de sécurité
EP3398104A1 (fr) Deuxieme authentification dynamique d'une signature electronique utilisant un module materiel securise
FR3035248A1 (fr) Systeme-sur-puce a fonctionnement securise et ses utilisations
WO2020012079A1 (fr) Gouvernance de sécurité du traitement d'une requête numérique
WO2019228853A1 (fr) Methode d'etablissement de cles pour le controle d'acces a un service ou une ressource
CH716295A2 (fr) Procédé de signature multiple d'une transaction destinée à une blockchain, au moyen de clés cryptographiques distribuées parmi les noeuds d'un réseau pair-à-pair.
EP4012972A1 (fr) Méthode de divulgation sélective de données via une chaine de blocs
CN109784917B (zh) 基于对称密钥池的抗量子计算区块链保密交易系统和方法
CN111861736A (zh) 基于区块链的政务数据处理方法、装置和计算机设备
JPH08506217A (ja) 公正な暗号システム及びその使用方法
CH716294A2 (fr) Procédé de signature décentralisée, sous contrôle biométrique et sous conditions d'identification personnelle et de géolocalisation, d'une transaction destinée à une blockchain.
CH716299A2 (fr) Procédé de signature d'une transaction destinée à une blockchain, au moyen d'une clé cryptographique distribuée parmi les noeuds d'un réseau pair-à-pair.
CN117933991A (zh) 使用多方计算个人分布式密钥的金融交易系统及方法
CH716301A2 (fr) Procédé de signature d'une transaction destinée à une blockchain déployée sur un réseau pair-à-pair, au moyen d'une clé cryptographique distribuée parmi les noeuds d'un autre réseau pair-à-pair.
FR3107128A1 (fr) Procédé et dispositif d'évaluation de correspondance d'ensembles de données structurées protégées par le chiffrement
CH716300A2 (fr) Procédé de signature d'une transaction destinée à une blockchain, au moyen d'une clé cryptographique distribuée parmi les noeuds d'un réseau pair-à-pair sur lequel est déployée cette blockchain.
CH716292A2 (fr) Procédé de signature décentralisée, sous contrôle biométrique et sous condition de géolocalisation, d'une transaction destinée à une blockchain.
CH716302A2 (fr) Procédé de signature décentralisée d'une transaction destinée à une blockchain, suivant les instructions d'un contrat intelligent.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19745659

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3105894

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 2021500594

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019300287

Country of ref document: AU

Date of ref document: 20190711

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 20217004291

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2019745659

Country of ref document: EP

Effective date: 20210211