EP3625928A1 - Procede de securisation d'une communication sans gestion d'etats - Google Patents

Procede de securisation d'une communication sans gestion d'etats

Info

Publication number
EP3625928A1
EP3625928A1 EP18723562.7A EP18723562A EP3625928A1 EP 3625928 A1 EP3625928 A1 EP 3625928A1 EP 18723562 A EP18723562 A EP 18723562A EP 3625928 A1 EP3625928 A1 EP 3625928A1
Authority
EP
European Patent Office
Prior art keywords
entity
message
data
key
communication method
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP18723562.7A
Other languages
German (de)
English (en)
Inventor
Paul-Emmanuel BRUN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Airbus Cybersecurity SAS
Original Assignee
Cassidian Cybersecurity 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 Cassidian Cybersecurity SAS filed Critical Cassidian Cybersecurity SAS
Publication of EP3625928A1 publication Critical patent/EP3625928A1/fr
Pending legal-status Critical Current

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/3234—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 additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y10/00—Economic sectors
    • G16Y10/75—Information technology; Communication
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y30/00—IoT infrastructure
    • G16Y30/10—Security thereof
    • 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/0435—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 symmetric encryption, i.e. same key used for encryption and decryption
    • 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
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • 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/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • 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/0822—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 key encryption key
    • 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/085—Secret sharing or secret splitting, e.g. threshold schemes
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/72—Signcrypting, i.e. digital signing and encrypting simultaneously
    • 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/045—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 hybrid encryption, i.e. combination of symmetric and asymmetric encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/71—Hardware identity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Definitions

  • the field of the invention relates to securing communications between two communicating entities, such as one or more entities managing sensors or driving actuators and a central entity managing remote hardware resources and communicating via network interfaces.
  • the invention relates in particular to secure communications that do not require state management.
  • the field of the invention also relates to securing the generation of control data or the control of actuators as well as the securing of the data as such in particular by establishing ad hoc secure communications offering architectural flexibility. and adaptable to the Internet of Things taking into account the limited computing resources.
  • the connected object When the connected object is active, it can be controlled by a connected control equipment, which could be the server, so the control equipment is able to transmit instructions to a connected object.
  • a connected control equipment which could be the server, so the control equipment is able to transmit instructions to a connected object.
  • loT Internet of Things
  • connected objects have limited resources to encrypt data but are also vulnerable to cyber attacks or physical attacks.
  • Some connected objects have for example an onboard electronic system with low processing capacity and are still intended to provide real-time information.
  • security processes developed for ⁇ such as Zigbee, providing communication between the sensor devices and the network access gateway. End-to-end security is not assured.
  • This type of security can be all the more limited as the sensor network is extended, because of the use of several successive networks. Indeed hundreds or even thousands of sensors can be used to supervise installations. Radio communications are generally preferred for cost reasons.
  • increased security may be necessary for certain equipment or installations, for example in the military field. Sensors and actuators thus interface with the real world in a wide range of systems.
  • the present invention aims at overcoming the drawbacks of the prior art by providing a method that secures transmissions between, on the one hand, a control equipment or a server and, on the other hand, one or more connected objects, the method also securing the operation in itself of remote entities.
  • the invention aims to overcome the aforementioned drawbacks.
  • the invention relates to a method of communication between at least two communicating entities, a first communicating entity generating at least one useful data message, transmitted to a second communicating entity, comprising a useful field comprising useful data and a header.
  • authentication method said method being characterized in that it comprises, for the generation of said message:
  • the message sent to the second communicating entity is transmitted in an application layer of a data network to which the first and the second communicating entity are connected.
  • the context parameter further includes one or more of the following:
  • a firmware update date of the first entity ⁇ A data representative of the memory space occupied by the firmware.
  • the context parameter is encrypted by a first asymmetric public key before being integrated into the transmitted message, said first asymmetric public key being stored in a memory of the first entity, the context parameter being decrypted by means of a first asymmetric private key stored in a memory of the second entity.
  • the second entity comprises a database storing a plurality of context parameters, each being associated with one of several first entities, the reception by the second entity of said message sent by the first entity comprising:
  • reception by the second entity of said message sent by the first entity further comprises:
  • ⁇ An update of the database of the second entity taking into account the context parameter and the identifier of the first entity received when the analysis indicates that an update or a new installation has taken place .
  • the context parameter is included in the authentication header, the signature being applied also to the context parameter.
  • the useful data comprise data collected by at least one sensor of the first communicating entity.
  • the communication method comprises a step of transmitting information comprising a symmetric shared secret key prior to the generation of said useful data transmission message, said symmetric shared secret key being used to generate the signature and to encrypt data. helpful.
  • the communication method comprises prior to the transmission step of the symmetric shared secret key
  • the communication method comprises a periodic renewal of the symmetric shared secret key comprising: A generation of a new symmetric secret key from a symmetric key generation module; ⁇ An encryption, by the second asymmetric private key, the symmetric secret key stored in a memory of the first entity;
  • the communication method comprises a periodic renewal of the private secret key comprising:
  • the useful data comprises the context parameter, the context parameter being generated and issued regularly.
  • the generation of said message comprises:
  • the security profile defines the conditions for generating a signature by the signature algorithm that is applied to the message payload, the context parameter and the message identifier.
  • the data signed by the signature algorithm comprise:
  • the invention relates to a communicating entity comprising at least one memory, a computer and a communication interface for executing the communication method of the invention.
  • the communicating entity comprises at least one data sensor.
  • the invention relates to a computer program comprising a set of instructions for implementing the communication method of the invention.
  • the secure communication method provides a solution that:
  • ⁇ possibly allows secure transmissions of command data transmitted from a control device to a connected object
  • ⁇ verifies the integrity of one or more components and one or more hardware configurations of the connected object
  • FIG. 1 a general diagram of a network architecture comprising a server and a plurality of clients implementing a method according to the invention
  • ⁇ figures 2 an exemplary architecture of a server and a client implementing a method of the invention
  • FIGS. 3A to 3B functions implemented in a method according to the invention
  • ⁇ Figure 4 the steps of a method of the invention
  • the invention relates to securing and authentication of communications between two communicating entities.
  • the description relates in particular to two entities respectively constituting a client and a server.
  • the client C1 is for example a connected object and the server S1 is of the data server type receiving, for use, the useful data Datai collected by a sensor of the connected object.
  • a first communicating entity C1 is designated, the communicating entity C1 transmitting useful data, for example collected by one or more sensors.
  • the sensors measure, for example, physical quantities such as temperatures, pressures, vibrations, forces and accelerations.
  • the first entity may include one or more actuators.
  • the first entity may also include a set of sensors and actuators, the sensors providing for example information on the state or position of the actuators.
  • the second communicating entity S1 is designated, the communicating entity S1 which receives the useful data.
  • the second communicating entity will for example be a central entity.
  • the second communicating entity may be connected to several first entities comprising sensors or actuators.
  • the second communicating entity S1 can in particular transmit commands to the first communicating entity Ci in order to control a function, configure a component or software, update software, or define new default configuration parameters.
  • a mesl message intended to transmit useful data Datai comprises two parts: a Tokeni authentication header and a useful field comprising useful Datai data.
  • the useful data message may comprise, in addition to useful datai data, data relating to the protocol or identifiers or else signatures.
  • the deported entity that corresponds to the first entity is, for example, the Client entity.
  • the remote entity comprises for example a computer, a memory and a communication interface including in particular several input and output ports.
  • the remote entity may be constituted by a computer, a tablet, a smartphone or industrial equipment type smart housing comprising sensors or actuators or any electronic equipment dedicated to an application to transfer data in a secure manner.
  • the first entity is for example a connected object comprising a sensor and generating data representative of the measurements performed by the sensor, transmitted to a server constituting the second communicating entity.
  • the first communicating entity C1 comprises, for example, an operating system or a firmware, also designated in English by Firmware.
  • the first entity thus realizes a set of functions for the management of its sensors and actuators but also to realize the securing of the data to be transferred.
  • the first entity is therefore associated with a device whose configuration enables it to identify itself in particular within a communication network or at least with the second communicating entity.
  • the first entity C1 thus comprises an identifier denoted C1_ld.
  • Such client equipment is indifferently noted C1, C2, Ci, ie [1; N].
  • the central entity that corresponds to the second entity is for example the server entity.
  • a server S1 comprises for example at least a memory and a computer and a communication interface.
  • the second entity S1 is for example a computer or a workstation connected to a network, such as the Internet, or a smartphone or tablet connected to a mobile network.
  • the second entity is for example configured to receive messages from different first entities and store the data received from these first entities.
  • the second entity is for example configured to send commands to different first entities.
  • the first entity S1 can decode or decrypt the received data by means of a Decoding_Module1 decoding module.
  • the first entity S1 stores for example in a database BDS1 data relating to a plurality of first entities such as connected objects.
  • the first entity S1 can also store cryptographic data it generates or receives from each first entity.
  • the first entity S1 comprises, for example, in memory cryptographic keys received from a first communicating entity such as C1, namely at least one symmetric private key KSec and an asymmetric public key KPub2.
  • the first entity S1 comprises for example in memory an asymmetric private key Kprivl and an asymmetric public key Kpubl. These keys can be generated for example by an ASymKGenl asymmetric private key generation module.
  • the second entity in the form of a data manager server for example provides management services of a set of sensors and actuators via first entities.
  • the second entity may also provide services to the first entities such as registering each first entity with the first entity.
  • the second entity is generally designated as the server entity and the first entity or entities as client entities, but the client and server functions may be reversed according to the steps of the method according to the invention. It should be noted that the second server entity S1 does not correspond, in particular, to an authentication server performing exclusively authentication functions in the sense of an authentication third party coupled with another data server.
  • the present invention makes it possible in particular to establish secure communications between at least one client and a data server providing security for the exchanged data.
  • the second communicating entity S1 comprises a database DBS1 making it possible in particular to record data relating to a plurality of first communicating entities.
  • the different first entities C1 to C4 communicate, to the second entity S1, useful data Datai collected by one or more sensors of each of the first entities or generated by internal functions to each first entity.
  • a module of a first entity for example performs a function of reading an identifier (IdCol) of a calculator (Co1) of the first entity (C1).
  • a module of a first entity for example performs a test function of the input and output ports to generate data representative of the used and unused input / output ports of the first entity (C1) and in particular the number of ports used.
  • a module of a first entity for example performs a function of reading a date of update of a firmware of the first entity.
  • a module of a first entity for example performs a function for calculating the memory space occupied by the firmware.
  • the method of the invention advantageously makes it possible to secure the datai useful data to be transmitted between two communicating entities, for example by a plurality of encryptions or controls.
  • the hardware configuration of the entity transmitting the payload message may in particular be verified.
  • the messages are transmitted in an application layer of the successive data network or networks, which makes it possible to secure end-to-end data transmission.
  • a data network used is for example the Internet network, a wired local network, a mobile network or a local radio network such as WiFi.
  • Symmetric key management implements, for example, a symmetric secret key exchange shared between the two communicating entities C1 and S1.
  • the symmetric secret key is generated in the first entity C1 by a SymKGen cryptographic component.
  • This SymKGen component makes it possible to generate at least one KSec shared symmetric secret key.
  • the symmetric key KSec is for example transmitted in a previously exchanged information between the first entity C1 and the second entity S1 so that these two entities both have a shared secret.
  • Fig. 3B shows an information transmission comprising the secret symmetric key.
  • the symmetric shared secret key KSec can be used to generate a Signl signature and to encrypt Datai payload data.
  • the resources required for shared secret key encryption are advantageously less than for an asymmetric private key.
  • the second entity S1 receiving the payload message is thus able to verify the authenticity of a signature Slgnl and to decipher the encrypted user data with this shared symmetric secret key.
  • the symmetric secret keys KSec can be renewed periodically by the first entity C1 and periodically transmitted to the second entity SI.
  • the same shared symmetric secret key is thus stored in a memory respectively of the first entity C1 and the second entity S1.
  • the method of the invention may include generating a pair of asymmetric cryptographic keys by the first entity C1 or by the second central entity S1.
  • the use of asymmetric public and private keys is preferably restricted with respect to the use of shared symmetric secret keys as previously described, so as to optimize the hardware resources required for data processing.
  • the asymmetric key generation function can be performed by a hardware or hardware cryptographic component of the equipment.
  • the asymmetric private key KPriv2 or KPrivI is for example stored in a memory or in a dedicated security component such as a TPM designating "Trusted Platform Module".
  • the first entity can read and store the KPubl public key generated by the second entity to encrypt data.
  • the second entity S1 comprises in particular an asymmetric key generator ASymKGenI and stores an asymmetric private key generated KPrivI.
  • the first entity C1 can also generate a private asymmetric key pair KPriv2 and public asymmetric key KPub2 for the second communicating entity, using an asymmetric key generator ASymKGen2.
  • the public asymmetric key KPub2 will then be transmitted to the second entity and stored in memory.
  • the second entity can then encrypt data intended for the first entity and decrypted from its stored asymmetric private key KPriv2.
  • a ContextPI context parameter is transmitted by the first entity C1 to the second entity S1.
  • the ContextPI context parameter is generated by a ContexPGen referenced context parameter generation module in FIG. 2.
  • the ContextPI context parameter comprises at least one piece of data representative of the hardware configuration of the first entity C1.
  • the ContextPI context parameter includes, for example, one or more of the following:
  • C1 or another hardware component such as a ROM, RAM or FLASH memory or other memory card;
  • ⁇ A data representative of the memory space occupied by the firmware or by another memorized subroutine.
  • An advantage of using a context parameter ContextPI relating to a hardware identifier of a component is to detect a possible hardware falsification by the second entity by comparing a hardware identifier initially stored with a hardware identifier included in a message of useful data.
  • An advantage of using a ContextPI context parameter with data representative of used or unused input / output ports is to detect a customer out of service or disconnected or unconnected or a fraudulent connection to the client. first entity.
  • This ContextPI context parameter is advantageously sent to the second communicating entity for control purposes by the second communicating entity.
  • the context parameter is encrypted before sending to the second entity.
  • a public key KPubl provided by the second entity is used for this purpose.
  • FIG. 5 represents the encryption of the context parameter ContextPI from the asymmetric public key KPubl of the second entity to be decrypted upon reception by the second entity S1 using its asymmetric private key KPhvl.
  • the method of the invention may include enlistment steps.
  • the enrollment is carried out prior to the transmissions of useful data Datai between two communicating entities C1 and S1
  • the enrollment allows to record a first entity and data relating to this first entity prior to the transmission of useful data.
  • This data relating to the first entity corresponds for example to the shared secret key.
  • the shared secret key can be renewed regularly, for security reasons.
  • the first entity C1 carries out an enrollment with the second entity
  • This request includes, for example, the identifier C1_ld and the context parameter ContextPI encrypted using the public key KPub2.
  • This solution is particularly efficient in terms of calculations since it allows to encrypt a short message, which includes the symmetric key, with an asymmetric key.
  • the identifiers of each first entity such as C1 in association with their context parameter are for example recorded in a database of the second entity S1.
  • the second entity S1 is then able to associate a first entity C1 with its ContextPI context parameter.
  • the enrollment may be initiated by the first or by the second entity.
  • the exchanges of public keys are for example automatically performed upon receipt of a first message MesEnr from one or the other of the entities C1, S1.
  • Key shares can also be made by a supervisory program accessing the second entity and the first entities.
  • the acquisition of a public key of the KPubl server can be generated by using a file such as an image, a captcha code, a bar code or a code 20, such as a QR code .
  • the acquisition of the public key of the KPubl server by the client can be carried out, in the latter case, by a reading of the code or the image comprising said key by means of capturing an image such as an optical sensor .
  • the method for generating a MesEnM enrollment request by the client C1 comprises a step of generating a public key of a client C1, denoted KPub2, and a key deprived of equipment rated KPriv2.
  • the method of generating an enrollment request can aim at extracting the public key C1 client from a memory of said client C1 to include it in the request.
  • the enrollment request can thus include the following data:
  • a mechanism for renewing asymmetric keys by the first entity or by the second entity can also be envisaged.
  • the new public key KPpub2 client can for example be transmitted to the server S1 through a new enrollment. Enrollment steps are then repeated.
  • the second entity S1 When the second entity S1 receives a payload message, the second entity S1 for example engages a step of decrypting the data by means of the shared secret key.
  • the decrypted data is then extracted and stored in a memory of the second entity S1.
  • the second entity S1 can then check the context parameter ContextPI and the client identifier C1_ld compared to the data stored in its database BDS1. If the comparison is valid, the message is authenticated and its processing is continued.
  • the second entity can, for example, stop processing and send an alert message.
  • the second entity can also initiate a check for updates of the first entities or connections of new entities.
  • FIG. 3C represents the step of transmitting a message Mes1 comprising datai payload data and a Tokenl authentication header.
  • the method of the invention makes it possible to exchange communications in a secure manner by defining messages whose security is "self-supporting", that is to say that each message Mes1 exchanged comprises its own security information for processing and to decipher the message sent.
  • the invention does not require in particular the establishment of a session between the two communicating entities providing a secure channel between these two entities.
  • the invention therefore comprises a mechanism for generating an authentication header of the data messages transmitted between the two entities.
  • the following description describes an embodiment in which the client C1, representing a first communicating entity, transmits a message Mes1 to the server S1, representing the second communicating entity, this message being verified by the server S1.
  • the client and server roles can, however, be reversed between the first and second communicating entities.
  • the invention implements a communication method making it possible to transmit messages of secured payload data Mes1 in particular thanks to the authentication header, denoted Tokenl.
  • the communication method can also be realized without prior enrollment.
  • the Tokenl authentication header is generated by a component of the client C1. On the server side, a component checks the authentication header received from the C1 client.
  • the Tokenl authentication header of the messages Mes1 transmitted comprises various data fields including the client identifier C1_ld.
  • the Tokenl may comprise a Mesjd identification of the Mes1 message, and possibly a PRO_SEC security profile which makes it possible to define the encryption or decryption conditions.
  • the security profile is generated by a Pro_SecGen security profile generation module.
  • the Tokenl may include a Signl signature.
  • the Tokenl authentication header can be, for example, integrated with the headers of the transport protocol used according to the communications made, such as an HTTP header, for example.
  • the authentication header is added to the list of headers of the transport application protocol used by the application.
  • the content of the authentication header generated by the present invention is associated with the "Authorization:" header of the HTTP / 1.1 protocol according to RFC [261]. 6].
  • the Mes1 message is generated by the Mess_Gen module by aggregating the Tokenl header to the Datai useful field.
  • a coding_Module1 coding module makes it possible to encrypt the data of the message.
  • the coding module then encrypts the data of the mes1 message according to the data to be encrypted or not, as indicated in the security profile, and the keys stored and necessary to perform these operations.
  • the calculator can retrieve a message identifier Mesjd which is generated by a message counter which generates message identifiers.
  • Figure 2 shows a component Mes_ID1 for generating and processing Mesjd message identifiers.
  • the message counter for example generates the Mesjd from a random, ie a RamdomPI random parameter and a Stampi expiration date.
  • RamdomPI randomness allows to define a unique identifier
  • the random state RamdomPI can for example be generated from a module for generating a random Ramdom modulel. The latter can be executed by the calculator.
  • the identifier of the message Mes_ID1 is computed in particular from a Stampl expiration date defined by a clock Clock_Module1 local clock module C1, the identifier Mesjd includes information on the expiration date Stampl message Mes1 that can be verified upon receipt by the server S1.
  • the Mesjd can be generated with a nonrandom parameter and a Stampl expiration date.
  • the message identifier Mes_ID1 can be, for example, calculated on the fly, that is to say in real time by a calculator of the communicating entity C1.
  • the identifier of the message My ID1 thus calculated is assigned to a message Mes1.
  • the PRO_SEC security profile makes it possible to define an algorithm that will be used to sign or encrypt the content to be transmitted.
  • the PRO_SEC security profile can be generated from a Pro_SecGen module, noted in Figure 2.
  • the Pro_SecGen module is used to preconfigure the PRO_SEC security profile to meet the requirements of a given application, a given context or an instruction issued by a user.
  • the security profile included in the payload message then provides information for the decode mode.
  • the PRO_SEC security profile can also be used to indicate and define whether the response to the message Mes1 sent by the server S1 must also be encrypted and according to which algorithm. This embodiment is particularly advantageous when the server transmits commands to the client C1.
  • the different communicating entities C1, S1, such as a server S1 and a plurality of clients Ci may comprise a configuration of predefined security profiles. Each predefined profile can be enabled to define a way to send and receive data with another entity.
  • a first security profile corresponds, for example, to the activation of a security parameter P1 incorporated in the authentication header Token of the mes1 message to be transmitted by the client C1 to the server S1.
  • This parameter P1 indicates the presence of an encryption of the Datai payload data transmitted.
  • the server S1 receiving this parameter P1 is capable of implementing a decryption of the data transmitted when the latter are encrypted.
  • a second profile corresponds, for example, to the activation of a security parameter P2 incorporated in the Tokeni authentication header of the message Mes1 to be transmitted by the client C1.
  • the P2 parameter is used to indicate that the Tokeni authentication header is signed.
  • Signl signature is in this case made by C1 client through the private key KPhvl client. Signl signature is included in the Tokeni authentication header.
  • This configuration has the advantage of making it possible to establish communications whose security is entirely self-supporting between two communicating entities C1, S1.
  • the various security profiles make it possible, for example, to adapt the security level of the data exchanges between the communicating entities C1, S1 according to the data exchange context or the type of data to be exchanged.
  • PRO_SEC security profiles can also use another security parameter representative of the signature format used for the authentication header. This parameter defines the use or not in the signature of:
  • the header may also be representative of the applied signature format defined by at least any of these data or a combination of these data:
  • a PRO_SEC security profile that it does not know, that is, that is not predefined in a memory of the entity, then a default profile can be used.
  • the enrollment may include the transmission of the definition of a PRO_SEC security profile.
  • an entity can then record the definition of the new security profile and use it to deploy an encryption policy for sent messages or decryption of received messages.
  • PRO_SEC security profile includes the designation of a signature generation algorithm such as RSA-SHA256 and where appropriate the designation of a data encryption algorithm, such as AES for example.
  • the PRO_SEC security profile therefore includes an indication of the presence of a Signl signature and the presence of data encryption, and if applicable, the PRO_SEC security profile includes the designation of the algorithms used to generate the signature or encrypt the data. data.
  • the Tokenl authentication header also comprises a signature of the data transmitted in the tokenl header.
  • a Signl signature is created using a Signing_Module1 signature generation algorithm.
  • the signature Sign1 is for example made by means of a public key KPub2 acquired by the communicating entity signing C1 or by means of the shared secret key KSec.
  • the signature is applied to a set of message elements including the payload of the message.
  • the context parameter can in particular be integrated with the useful data.
  • the context parameter can also be transmitted in the authentication header and be taken into account in the signed data.
  • the payload when signed, may correspond to the encrypted payload or unencrypted payload.
  • the signature Sign1 can for example be generated from the data: Mes_ID1, C1_ld, PRO_SEC and the content of the message Datai.
  • An algorithm based on an RSA method SHA256 can for example be implemented by the invention to generate the Sign1 signature.
  • SHA designates in the English terminology: "Secure Hash Algorithm" and corresponds to a cryptographic hash function.
  • the RSA is an asymmetric cryptographic algorithm using a pair of asymmetric keys. Both algorithms can be associated in a single encryption algorithm.
  • Algorithm can also be used according to the method of the invention. This is a public key digital signature algorithm.
  • the algorithm for generating a signature can also be automatically determined, among several algorithms, according to the equipment of the client or its operating system and for example according to the context parameter.
  • One advantage is to use existing resources on a device and to take into account the hardware configuration of the equipment.
  • a Tokenl authentication header field includes the generated Sign1 signature and another field may be provided in the Tokenl header to designate the algorithm for generating the Sign1 signature. Another field also refers to the data encryption algorithm Datai.
  • the data server S1 Upon receipt, the data server S1 will be able to decode the Sign1 signature by choosing the correct algorithm as indicated for decoding the Sign1 signature.
  • the term "protocol header" is used to differentiate it from the Tokenl authentication header of the invention.
  • the different fields of the http protocol of the following example can be used according to one embodiment of the invention to sign the authentication header.
  • the http request having for example the fom1 e following:
  • One or more data relating to the transport protocol data may be used.
  • Part of a field of a protocol header can also be used.
  • the Method field of the http protocol specifying the type of request whose particular values ⁇ GET, PUT, P0 $ 1 ⁇ , present in the request line of an http request is of interest for an interest in signing the header.
  • Tokenl authentication This consideration makes it possible in particular to avoid "replay" attacks by a third party by performing a different action than the initial request.
  • a message header of a transport application protocol is for example defined by a pair ⁇ key: value ⁇ .
  • the header [Expires: "Sat, 07 Nov 2015 00:59:59 GMT"] represents an expiration date of the request.
  • the type of request and the address of the resource to be interrogated are contained in the request line of the message, for example [POST http: / lcontrol_center_uri / rest / conso HTTP / 1 .1], and can be used to generate the Signl signature.
  • This embodiment is particularly advantageous for ensuring the integrity of the data exchanges.
  • the implementation of the secure communication method is preferably independent of the communication protocol.
  • the generation of a signature Sign1 involves the execution of a hash function of the unencrypted user data to be signed.
  • the useful data are for example encrypted before transmission.
  • an unauthorized third party retrieves a signed message, it is not possible for that third party to reconstruct the data that has been signed from the Signl signature.
  • the signature can also be applied to the encrypted payload.
  • the signature also makes it possible to verify that the signed transmitted data are not altered.
  • the message identifier Mes_ID1 which changes to each mes1 message, allows the hash function to generate a content of the signature totally different from one message to another.
  • Sign1 signature can also be applied to data to which a padding function is applied, i.e. a data filling function.
  • a padding function i.e. a data filling function.
  • the PRO_SEC security profile defines which algorithm is used to encrypt the data.
  • the PRO_SEC security profile is indicated in the Tokenl authentication header of the Mes1 message and is used to indicate the designation of the encryption algorithm.
  • the security profile PRO_SEC can also be part of the signed data.
  • the payload of the message Mes1 which is transmitted to the server S1 are encrypted with the algorithm determined by the client C1.
  • the data can then be decrypted, server side, through the indication of the algorithm used.
  • the data encryption algorithm can be automatically determined from a list of available algorithms, depending on the equipment of the client C1 or its operating system or the context parameter.
  • One advantage is to use existing resources on a device and according to its configuration.
  • An example of an algorithm according to the invention may be AES designating "Advanced Encryption Standard” in the English terminology. This is an advanced encryption standard also known as "Rijndael”.
  • Datai data are encrypted using a KSec shared symmetric secret key.
  • Encryption operations are advantageously optimized thanks to symmetric key encryption.
  • asymmetric key encryption including a public key and a private key can also be considered but involves operations on larger key sizes and therefore more complex and resource consuming for data processing.
  • PRO_SEC security profiles are a good indication of what type of signature or encryption. For example, it is specified whether a message has a signed header and encrypted content in one direction.
  • the client C1 is a connected object remotely controllable from an server S1 and an encryption of the data transmitted from the server S1 to the client C1 has been decided, then a mechanism involving the transmission of the security profile can also be put in place.
  • the field Mes_ID1 makes it possible to define a security against the attacks by replay of third messages.
  • FIG. 4 represents steps of the communication method of the invention from the point of view of a communicating entity that generates a message Mes1.
  • the method according to the invention makes it possible in particular to generate a message Mes1 and the succession of steps are denoted GEN (Mes1).
  • the method includes generating a Tokenl authentication header and Datai payload data.
  • a first step, denoted GEN (ContextP1), consists, for example, in the generation of the ContextPI context parameter. It comprises at least one datum representative of the hardware configuration of the equipment. For example, it may be a state variable of an input / output port such as the port labeled PortCI of the client C1.
  • the Portl port makes the data transmitted by C1 pass over the Net1 network, in particular to the server S1 via the PortSL port.
  • ContextPI context parameter may be a date of update of a "Firmware" CtrIProg, that is to say a hardware operating software of one or more components of the equipment.
  • App_C1 represents an application dedicated to the interactions with the environment by the management of sensors or actuators.
  • the context parameter may for example be representative of the number of sensors or actuators in use.
  • the context parameter ContextPI can be complex and comprise several values representative of a set of different hardware configurations of different components of the client C1, such as a sensor, a port, a memory, a microprocessor or an antenna.
  • the number of connected input and output ports can also be taken into account.
  • Data representative of the used and unused input and output ports may also be included in the context parameter.
  • Component identifiers can also be included in the ContextPI context parameter.
  • the ContextPI context parameter is automatically generated according to the variables that compose it.
  • the method comprises for example a next step of generating the PRO_SEC security profile denoted GEN (PRO_SEC).
  • the generated PRO_SEC security profile is embedded in the tokenl authentication header.
  • the method comprises, for example, a step of inserting the Sign1 signature, denoted JNS (Sign1), into the message Mes1.
  • the method comprises for example a next step of inserting the client identifier C1_ld, denoted INS (C1_ld) in the message Mes1.
  • INS client identifier
  • the identifier C1_ld is preferentially included in the authentication header.
  • the method comprises for example a following step INS (PRO_SEC) insertion of the PRO_SEC security profile which defines the conditions of encryption and the generation of a signature Signl.
  • INS PRO_SEC
  • the message Mes1 comprising the authentication header Tokenl and the payload Datai can then be generated GEN (Mesl) by the aggregation of the header and payload.
  • GEN Mesl
  • This useful data message can thus be sent, according to a communication protocol used, to transmit data between the client C1 and the server S1.
  • the data server that corresponds to one of the communicating entities of the invention is intended to manage data transmissions with a plurality of clients Ci. It comprises for this purpose a component making it possible to manage the equipment, such as a memory in which the database BDS1 stores the data of each client Ci such as the Cijd identifier and ContextPI context parameters.
  • the server S1 may include a memory for storing the data relating to the ciphers in association with each client equipment in a memory denoted DBS2 which stores asymmetric public keys KPub2 of the equipment C1, as well as the secret symmetric keys KSec shared.
  • DBS2 which stores asymmetric public keys KPub2 of the equipment C1, as well as the secret symmetric keys KSec shared.
  • the server executes a first function for storing client accounts and a second function for receiving and processing enrollment requests sent by client devices Ci.
  • the processing of a request includes, for example, data decryption operations and verification operations that the client equipment Ci is not suspended or revoked or that the received message is valid to verify, or that a hardware anomaly has occurred in the client equipment Ci.
  • the context parameter can for example be analyzed for a conformity analysis of the hardware configuration of the equipment.
  • the mes1 message sent by the client equipment C1 is received by the server S1 via a communication interface.
  • a component of the server S1 for example performs a step of checking the received message Mes1 and in particular its expiry date.
  • the server S1 comprises in particular a set of asymmetric keys comprising a public key KPubl and a private key KPhvl for decryption purposes, according to the parameters of the security profile.
  • the message Mes1, received by the server S1, has for example been encrypted, by the client C1, with the asymmetric public key of the KPubl server.
  • This asymmetric public key of the KPubl server was previously acquired by the equipment, for example, during its installation or during an enrollment.
  • a supervisor program can also be used to set up a client or server.
  • a verification of the Tokenl authentication header can be carried out by means of a verification module denoted Token_ChK1.
  • the verification of the message includes the control of the identifier of the message Mes_ID1, and in particular its expiration date.
  • the server S1 can refuse to accept the received message Mes1.
  • the server S1 may return a specific error containing the current date of the server. This variant allows the client C1 to resynchronize and reissue to new messages with valid Tokenl authentication headers.
  • the checking of the MESJD1 by the server S1 makes it possible to limit the network attacks by replaying message Mes1.
  • a second check performed by the server S1 may include checking whether the message Mes1 has already been received by the latter. If the message has already been received, that is, the MESJD1 of the received message Mes1 is identical to a MESJD of a previously received message, then the message Mes1 is not processed by the server S1.
  • the message identifier may also be signed, for example, using a shared symmetric secret key stored by the server. The validity of the message identifier is then also confirmed during the verification of the signature in the authentication header.
  • the server When the signature is made from a private asymmetric key, the server performs for example a reading of the public asymmetric key in memory of the server or directly to the equipment. Verification of the signature
  • the shared secret symmetric key KSec is stored in memory by the server S1 in order to be used to check the Sign1 signature.
  • Messages can also be signed using a KPubl public asymmetric key provided by the KPrivI server which then uses its private asymmetric key to verify the Signl signature.
  • a shared secret symmetric key will be used for equipment that does not have significant computing power.
  • the PRO_SEC security profile includes the format of the Signl signature whose signed data and the designation of the algorithm used.
  • the security profile PRO_SEC indicates for example that the useful data are encrypted with the shared secret symmetric key and allows the server S1 to initiate the decryption of the useful data dated Mes1 message thanks to the shared symmetric key KSec stored in memory by the server .
  • the security profile may also indicate that the payload is encrypted with the public asymmetric key provided by the server.
  • the server decrypts using its private asymmetric key.
  • encryption using a shared symmetric secret key is preferred for equipment with little computing power.
  • the decrypted useful data is then processed by the central data management server.
  • Datai useful data once decoded by the server S1, are processed by the APP_S1 module.
  • the specific use of the data retrieved by the central data management server is not described in the present description.
  • the APP_C1 component makes it possible, for example, to manage one or more sensors or one or more actuators.
  • the method of the invention makes it possible in particular to establish secure communication in the form of a request and acknowledgments between a client C1 and a server S1 without having to manage the states of a communication, that is to say without having to manage sessions between entities communicating.
  • the invention makes it possible to dispense with a complex preliminary protocol, such as VPN, between two communicating entities of a network.
  • the means of a secure communication according to the invention can in particular be implemented respecting the principles of a REST type architecture.
  • the invention also makes it possible to dispense with exchange of authentication certificates
  • Another advantage of the invention is also to induce a low cost of deployment since secure communication can be established quickly between two communicating entities. as soon as they are installed on the communication network or networks.
  • the solution of the invention also makes it possible to suspend or revoke a faulty equipment C1 detected by the server S1.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Power Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Procédé de communication entre au moins deux entités communicantes (C1, S1), une première entité communicante (C1) générant au moins un message de données comprenant des données utiles (Datai ) et un entête d'authentification (Tokeni), ledit procédé étant caractérisé en ce qu'il comporte: une génération d'un paramètre de contexte (ContextP1) comportant au moins une donnée représentative de la configuration matérielle (CtrIProg) de la première entité (C1); une génération d'un profil de sécurité (PRO_SEC) dans l'entête d'authentification (Token1) définissant les conditions: de chiffrement des données utiles (Datai ) du message; de génération d'une signature (Sign1) par un algorithme (Signing_Module1) appliqué au moins aux données utiles (Datai ) du message; une inclusion de ladite signature (Sign1) dans le message généré; une insertion d'un identifiant mémorisé (C1_ld) de la première entité communicante (C1) dans l'entête d'authentification (Token1); une insertion du profil de sécurité (PRO_SEC) dans les données utiles ou dans l'entête d'authentification.

Description

PROCEDE DE SECURISATION D'UNE COMMUNICATION SANS GESTION
D'ETATS
DOMAINE
Le domaine de l'invention concerne la sécurisation de communications entre deux entités communicantes, telles qu'une ou plusieurs entités gérant des capteurs ou pilotant des actionneurs et une entité centrale gérant des ressources matérielles à distance et communiquant via des interfaces réseaux.
L'invention se rapporte notamment aux communications sécurisées ne nécessitant pas de gestion d'états. Le domaine de l'invention concerne également la sécurisation dans la génération des données de contrôle ou dans le pilotage d'actionneurs ainsi que la sécurisation des données en tant que telles notamment par l'établissement de communications sécurisées ad hoc offrant une souplesse d'architecture et adaptable à l'Internet des objets en prenant en compte les ressources de calcul limitées.
ETAT DE L'ART
L'Internet des objets et les environnements fortement digitalisés s'accompagnent de la mise en place de flux d'information à des fins par exemple de gestion, de sauvegarde ou d'interactivité. On connaît ainsi des processus de sécurisation des communications tels que les réseaux privés virtuels désignés également par VPN (Virtual Private Network en anglais). On connaît également la mise en place de programme de sécurité tels que les antivirus permettant de se prémunir contre différents types d'attaques. Cependant ces moyens de défense sont généralement mis en œuvre sur des terminaux disposant de ressources très importantes tels que des smartphones, des tablettes ou des ordinateurs.
Actuellement, il existe aussi des solutions permettant de sécuriser des communications entre équipements par exemple au moyen de clefs asymétriques publiques et clefs privés asymétriques ou avec des tiers d'authentification, mais ces solutions impliquent des ressources de calcul importantes à assurer par l'objet connecté en matière de fonctions cryptographiques. Lorsque l'objet connecté est passif, c'est-à-dire qu'il ne gère pas de commande provenant d'un équipement de commande connecté, qui pourrait être le serveur, alors il transmet des données utiles collectées par le capteur vers le serveur.
Lorsque l'objet connecté est actif, il peut être commandé par un équipement de commande connecté, qui pourrait être le serveur, l'équipement de commande est donc susceptible de transmettre des instructions à un objet connecté.
Dans le domaine des objets connectés, il existe ainsi un besoin de sécuriser les communications entre les objets connectés transmettant des données et une entité centrale de gestion à distance.
En effet dans un environnement du type Internet des objets également désigné par loT (Internet of Things en anglais) les objets connectés disposent de ressources limitées pour encrypter les données mais sont également vulnérables à des attaques cybernétiques ou à des attaques physiques. Certains objets connectés disposent par exemple d'un système électronique embarqué ayant une faible capacité de traitement et sont tout de même destinés à fournir des informations en temps réel. Il existe également des processus de sécurisation développés pour ΙοΤ, tel que Zigbee, assurant une communication entre les dispositifs capteurs et la passerelle d'accès au réseau. La sécurité de bout en bout n'est alors pas assurée. Ce type de sécurité peut être d'autant plus limitée que le réseau de capteur est étendu, du fait de l'utilisation de plusieurs réseaux successifs. En effet des centaines voire des milliers de capteurs peuvent être utilisés pour superviser des installations. Les communications radio sont généralement préférées pour des raisons de coût. Enfin une sécurité accrue peut être nécessaire pour certains équipements ou installations comme par exemple dans le domaine militaire. Les capteurs et actionneurs assurent ainsi l'interface avec le monde réel dans une large gamme de systèmes.
La présente invention vise à pallier aux inconvénients de l'art antérieur en fournissant procédé sécurisant les transmissions entre d'une part un équipement de commande ou un serveur et d'autre part un ou plusieurs objets connectés, le procédé sécurisant par ailleurs le fonctionnement en lui- même des entités distantes.
RESUME DE L'INVENTION
L'invention vise à pallier aux inconvénients précités.
Selon un aspect, l'invention concerne un procédé de communication entre au moins deux entités communicantes, une première entité communicante générant au moins un message de données utiles, émis vers une seconde entité communicante, comprenant un champ utile comportant des données utiles et un entête d'authentification, ledit procédé étant caractérisée en ce qu'il comporte, pour la génération dudit message :
■ une génération d'un paramètre de contexte comportant au moins une donnée représentative de la configuration matérielle de la première entité;
■ une génération d'un profil de sécurité intégré dans l'entête d'authentification et définissant les conditions:
■ de chiffrement des données utiles du message ;
■ de génération d'une signature par un algorithme de signature appliqué au moins aux données utiles;
■ une génération de ladite signature intégrée dans l'entête d'authentification ;
■ une insertion d'un identifiant mémorisé de la première entité communicante dans l'entête d'authentification ;
■ une insertion du paramètre de contexte dans le champ utile ou dans l'entête d'authentification ;
■ une agrégation du champ utile et de l'entête.
Selon une particularité, le message émis à la seconde entité communicante est transmis dans une couche applicative d'un réseau de données auquel sont connectées la première et la seconde entité communicante.
Selon une particularité, le paramètre de contexte comprend en outre une ou plusieurs des données parmi les suivantes :
■ Un identifiant d'un calculateur de la première entité; ■ Une donnée représentative des ports d'entrée/sortie utilisés et non utilisés de la première entité ;
■ Une date de mise à jour d'un micrologiciel de la première entité ■ Une donnée représentative de l'espace mémoire occupé par le micrologiciel.
Selon une particularité, le paramètre de contexte est chiffré par une première clef publique asymétrique avant d'être intégré dans le message émis, ladite première clef publique asymétrique étant enregistrée dans une mémoire de la première entité, le paramètre de contexte étant déchiffré grâce à une première clef privé asymétrique enregistrée dans une mémoire de la seconde entité. Selon une particularité, la seconde entité comprend une base de données mémorisant une pluralité de paramètre de contexte, chacun étant associé à une parmi plusieurs premières entités, la réception par la seconde entité dudit message émis par la première entité comportant :
■ Une vérification que le paramètre de contexte et l'identifiant de la première entité reçus par la seconde entité sont présents dans la base de données ;
■ Un traitement dudit message reçu lorsque l'état de vérification est validé. Selon une particularité, la réception par la seconde entité dudit message émis par la première entité comporte en outre :
■ Une analyse par un gestionnaire d'application de la seconde entité afin de déterminer si une mise à jour d'un micrologiciel ou une installation d'une nouvelle première entité communicante a eu lieu ;
■ Une mise à jour de la base de données de la seconde entité prenant en compte le paramètre de contexte et l'identifiant de la première entité reçus lorsque l'analyse indique qu'une mise à jour ou qu'une nouvelle installation a eu lieu. Selon une particularité, le paramètre de contexte est inclus dans l'entête d'authentification, la signature étant appliquée également au paramètre de contexte.
Selon une particularité, les données utiles comprennent des données collectées par au moins un capteur de la première entité communicante. Selon une particularité, le procédé de communication comprend une étape transmission d'une information comprenant une clef secrète partagée symétrique préalable à la génération dudit message de transmission de données utiles, ladite clef secrète partagée symétrique étant utilisée pour générer la signature et pour chiffrer des données utiles.
Selon une particularité, le procédé de communication comprend préalablement à l'étape de transmission de la clef secrète partagée symétrique;
■ Une génération d'une seconde clef publique asymétrique et d'une seconde clef privée asymétrique par un module de génération de clefs asymétriques de la première entité, les dites clefs générées étant enregistrées dans une mémoire ;
■ Une transmission par la première entité vers la seconde entité d'une requête d'enregistrement comportant l'identifiant de la première entité, le paramètre de contexte et ladite seconde clef publique asymétrique;
■ Une transmission par la seconde entité vers la première entité d'un acquittement indiquant l'enregistrement de la première entité dans la base de données de la seconde entité ;
■ Un chiffrement à partir de la seconde clef privée asymétrique de la clef secrète symétrique.
Selon une particularité, le procédé de communication comprend un renouvellement périodique de la clef secrète partagée symétrique comportant: ■ Une génération d'une nouvelle clef secrète symétrique à partir d'un module de génération de clef symétrique ; ■ Un chiffrement, par la seconde clef privée asymétrique, de la clef secrète symétrique mémorisée dans une mémoire de la première entité ;
■ Une transmission de la nouvelle clef secrète partagée symétrique à la seconde entité.
Selon une particularité, le procédé de communication comprend un renouvellement périodique de la clef secrète privée comportant :
■ Une génération d'une nouvelle clef secrète symétrique à partir d'un module de génération de clef symétrique;
■ Une transmission de la nouvelle clef secrète partagée symétrique.
Selon une particularité, les données utiles comprennent le paramètre de contexte, le paramètre de contexte étant généré et émis régulièrement.
Selon une particularité, la génération dudit message comprend:
■ Une génération d'un identifiant de message calculé à partir :
o d'un paramètre généré aléatoirement et fourni par un module aléatoire et ;
o d'une date limite de validité générée par un module d'horloge;
■ Une insertion de l'identifiant de message dans l'entête d'authentification dudit message.
Selon une particularité, le profil de sécurité définit les conditions de génération d'une signature par l'algorithme de signature qui est appliqué aux données utiles du message, au paramètre de contexte et à l'identifiant de message.
Selon une particularité, les données signées par l'algorithme de signature comprennent :
■ le profil de sécurité ;
■ l'identifiant de la première entité. Selon un aspect l'invention concerne une entité communicante comprenant au moins une mémoire, un calculateur et une interface de communication pour l'exécution du procédé de communication de l'invention.
Selon un mode de réalisation, l'entité communicante comprend au moins un capteur de données.
Selon un aspect, l'invention concerne un programme d'ordinateur comportant un ensemble d'instructions pour la mise en œuvre du procédé de communication de l'invention. Avantageusement encore le procédé sécurisé de communication apporte une solution qui :
■ permet de choisir des dispositifs peu coûteux notamment du fait de leur capacités réduites en termes de charge de calculs pour l'objet connecté ;
■ permet de sécuriser les transmissions des données utiles pouvant être critiques vers un serveur gestionnaire de données;
■ permet possiblement de sécuriser les transmissions des données de commandes transmises d'un équipement de commande vers un objet connecté ;
■ permet de vérifier l'intégrité d'un ou plusieurs composants et d'une ou plusieurs configurations matérielles de l'objet connecté ;
■ permet une sécurisation des communications de bout en bout sur une grande variété de réseaux.
BREVE DESCRIPTION DES FIGURES
D'autres caractéristiques et avantages de l'invention ressortiront à la lecture de la description détaillée qui suit, en référence aux figures annexées, données à titre d'exemple, qui illustrent :
■ figure 1 : un schéma général d'une architecture réseau comportant un serveur et une pluralité de clients mettant en œuvre un procédé selon l'invention ;
■ figures 2: un exemple d'architecture d'un serveur et d'un client mettant en œuvre un procédé de l'invention ;
■ figures 3A à 3B: des fonctions mises en œuvre dans un procédé selon l'invention ; ■ figure 4 : des étapes d'un procédé de l'invention ;
■ figure 5 : des étapes de chiffrement et de déchiffrement du paramètre de contexte selon un exemple de réalisation. DESCRIPTION
Définitions
L'invention concerne la sécurisation et l'authentification de communications entre deux entités communicantes.
La description porte notamment sur deux entités constituant respectivement un client et un serveur. Le client C1 est par exemple un objet connecté et le serveur S1 est du type serveur de données recevant, pour les exploiter, les données utiles Datai collectées par un capteur de l'objet connecté.
On nomme dans la présente description une première entité communicante C1 , l'entité communicante C1 qui transmet des données utiles par exemple collectées par un ou plusieurs capteurs. Les capteurs mesurent par exemple des grandeurs physiques comme des températures, des pressions, des vibrations, des forces et des accélérations. La première entité peut comprendre un ou plusieurs actionneurs. La première entité peut également comprendre un ensemble de capteurs et d'actionneurs, les capteurs fournissant par exemple des informations sur l'état ou la position des actionneurs.
On nomme la seconde entité communicante S1 , l'entité communicante S1 qui reçoit les données utiles. La seconde entité communicante sera par exemple une entité centrale. La seconde entité communicante pourra être reliée à plusieurs premières entités comprenant des capteurs ou des actionneurs.
La seconde entité communicantes S1 peut notamment transmettre des commandes à la première entité communicante Ci afin de commander une fonction, configurer un composant ou un logiciel, mettre à jour un logiciel, ou encore définir de nouveaux paramètres de configuration par défaut.
Dans la présente description, le client correspond par exemple à la première entité communicante, le serveur correspondant à la seconde entité communicante. Dans la suite de la description un message mesl visant à transmettre des données utiles Datai comporte deux parties : une entête d'authentification Tokeni et un champ utile comportant des données utiles Datai . Le message de données utiles peut comprendre, outre des données utiles Datai , des données relatives au protocole ou des identifiants ou encore des signatures.
On entendra plus généralement pour la simplicité de lecture le champ utile comme les données utiles Datai que l'on pourra nommer également Datai .
Entité déportée
L'entité déportée qui correspond à la première entité est par exemple l'entité Client. L'entité déportée comprend par exemple un calculateur, une mémoire et une interface de communication comprenant notamment plusieurs ports d'entrée et de sortie. L'entité déportée peut être constituée par un ordinateur, une tablette, un smartphone ou encore un équipement industriel de type boîtier intelligent comprenant des capteurs ou des actionneurs ou tout équipement électronique dédié à une application visant à transférer des données de manière sécurisée.
La première entité est par exemple un objet connecté comportant un capteur et générant des données représentatives des mesures effectuée par le capteur, transmises à un serveur constituant la seconde entité communicante.
La première entité communicante C1 comprend par exemple un système d'exploitation ou un micrologiciel, également désigné en anglais par Firmware. La première entité réalise ainsi un ensemble de fonctions pour la gestion de ses capteurs et actionneurs mais également pour réaliser la sécurisation des données à transférer.
La première entité est donc associée à un équipement dont la configuration lui permet notamment de s'identifier au sein d'un réseau de communication ou à tout le moins auprès de la seconde entité communicante. La première entité C1 comprend donc un identifiant noté C1_ld. Un tel équipement client est indifféremment noté C1 , C2, Ci, ie[1 ;N].
Entité Centrale L'entité centrale qui correspond à la seconde entité est par exemple l'entité Serveur. Un serveur S1 comprend par exemple à minima une mémoire et un calculateur ainsi qu'une interface de communication. La seconde entité S1 est par exemple un ordinateur ou une station de travail connectée à un réseau, tel que le réseau internet, ou un smartphone ou une tablette connecté à un réseau mobile. La seconde entité est par exemple configurée pour recevoir des messages provenant de différentes premières entités et stocker les données reçues de ces premières entités. La seconde entité est par exemple configurée pour envoyer des commandes vers différentes premières entités.
La première entité S1 peut décoder ou déchiffrer les données reçues au moyen d'un module de décodage Decoding_Module1 .
La première entité S1 stocke par exemple dans une base de données BDS1 des données relatives à d'une pluralité de première entités tels que des objets connectés.
La première entité S1 peut aussi stocker des données cryptographiques qu'elle génère ou qu'elle reçoit de chaque première entité. La première entité S1 comporte par exemple en mémoire des clefs cryptographiques reçus d'une première entité communicante telle que C1 , à savoir au moins une clef privé symétrique KSec et une clef publique asymétrique KPub2.
La première entité S1 comporte par exemple en mémoire une clef privée asymétrique Kprivl et une clé publique asymétrique Kpubl . Ces clefs peuvent être générées par exemple par un module de génération de clef privé asymétrique ASymKGenl .
La seconde entité se présentant sous la forme d'un serveur gestionnaire de données fournit par exemple des services de gestion d'un ensemble de capteurs et d'actionneurs via des premières entités. La seconde entité peut également fournir des services aux premières entités tels que l'enregistrement de chaque première entité auprès de la première entité.
On désigne de manière générale la seconde entité comme étant l'entité serveur et la ou les premières entités comme des entités clients mais les fonctions de client et de serveur peuvent s'inverser selon les étapes du procédé selon l'invention. On note que la seconde entité serveur S1 ne correspond pas notamment à un serveur d'authentification réalisant exclusivement les fonctions d'authentification au sens d'un tiers d'authentification couplé avec un autre serveur de données.
Avantageusement, la présente invention permet notamment d'établir des communications sécurisées entre au moins un client et un serveur de données offrant une sécurisation des données échangées.
Comme représenté à la figure 1 la seconde entité communicante S1 comprend une base de données DBS1 permettant notamment d'enregistrer des données relatives à une pluralité de premières entités communicantes. Les différentes premières entités C1 à C4 communiquent, à la seconde entité S1 , des données utiles Datai collectées par un ou plusieurs capteurs de chacune des premières entités ou générées par des fonctions internes à chaque première entité. Un module d'une première entité réalise par exemple une fonction de lecture d'un identifiant (IdCol ) d'un calculateur (Co1 ) de la première entité (C1 ). Un module d'une première entité réalise par exemple une fonction de test des ports d'entrée et de sortie pour générer une donnée représentative des ports d'entrée/sortie utilisés et non utilisés de la première entité (C1 ) et notamment le nombre de ports utilisés. Un module d'une première entité réalise par exemple une fonction de lecture d'une date de mise à jour d'un micrologiciel de la première entité. Un module d'une première entité réalise par exemple une fonction de calcul de l'espace mémoire occupé par le micrologiciel.
Le procédé de l'invention permet avantageusement de sécuriser les données utiles Datai à transmettre entre deux entités communicantes par exemple par un plusieurs cryptages ou contrôles. La configuration matérielle de l'entité émettant le message de données utiles peut notamment être vérifiée.
Avantageusement les messages sont transmis dans une couche applicative du ou des réseaux de données successifs, ce qui permet de sécuriser la transmission de données de bout en bout. Un réseau de données utilisé est par exemple le réseau Internet, un réseau local câblé, un réseau mobile ou un réseau local radio tel que WiFi.
Gestion de clefs symétriques Le procédé de l'invention met, par exemple, en œuvre un échange de clef secrète symétrique partagée entre les deux entités communicantes C1 et S1 .
La clé secrète symétrique est générée, dans la première entité C1 , par un composant cryptographique SymKGen. Ce composant SymKGen permet de générer au moins une clef secrète symétrique partagée KSec.
La clef symétrique KSec est par exemple transmise dans une information échangée au préalable entre la première entité C1 et la seconde entité S1 afin que ces deux entités disposent toutes deux d'un secret partagé.
La figure 3B représente une transmission d'information comprenant la clef symétrique secrète. La clef secrète partagée symétrique KSec peut être utilisée pour générer une signature Signl et pour chiffrer les données utiles Datai . Les ressources nécessaires au cryptage par clé secrète partagée sont avantageusement moindres que pour une clé privée asymétrique. La seconde entité S1 recevant le message de données utiles est ainsi en mesure de vérifier l'authenticité de a signature Slgnl et de déchiffrer les données utiles chiffrées avec cette clef secrète symétrique partagée.
Les clefs secrètes symétriques KSec peuvent être renouvelées périodiquement par la première entité C1 et transmises périodiquement à la seconde entitéSI .
Une même clé secrète symétrique partagée est ainsi stockée dans une mémoire respectivement de la première entité C1 et de la seconde entité S1 .
Gestion de clefs asymétriques
Le procédé de l'invention peut comporter une génération d'un couple de clefs cryptographiques asymétriques par la première entité C1 ou par la seconde entité centrale S1 . L'utilisation des clés publiques et privées asymétriques est de préférence restreinte par rapport à l'utilisation des clés secrète symétriques partagées comme décrit auparavant, de façon à optimiser les ressources matérielles nécessaires pour les traitements de données.
La fonction de génération de clé asymétrique peut être réalisée par un composant cryptographique logiciel ou matériel de l'équipement. La clef privée asymétrique KPriv2 ou KPrivI est par exemple stockée dans une mémoire ou dans un composant de sécurité dédié comme par exemple un TPM désignant « Trusted Platform Module ».
La première entité peut lire et mémoriser la clé publique KPubl générée par la seconde entité pour crypter des données. La seconde entité S1 comprend notamment un générateur de clé asymétrique ASymKGenI et mémorise une clé privée asymétrique générée KPrivI .
La première entité C1 peut également générer un couple de clé asymétrique privée KPriv2 et clé asymétrique publique KPub2 destinée à la seconde entité communicante, en utilisant un générateur de clé asymétrique ASymKGen2. La clé asymétrique publique KPub2 sera alors transmise à la seconde entité et stockée en mémoire. La seconde entité peut alors chiffrer des données destinées à la première entité et déchiffrée à partir de sa clé privée asymétrique KPriv2 mémorisée. Paramètre de contexte
Selon le procédé de l'invention un paramètre de contexte ContextPI est transmis par la première entité C1 à la seconde entité S1 .
Le paramètre de contexte ContextPI est généré par un module de génération du paramètre de contexte référencé ContexPGen sur la figure 2.
Le paramètre de contexte ContextPI comprend au moins une donnée représentative de la configuration matérielle de la première entité C1 .
Le paramètre de contexte ContextPI comprend, par exemple, une ou plusieurs des données parmi les suivantes :
■ Un identifiant IdCol d'un calculateur Co1 de la première entité
C1 ou d'un autre composant matériel tel qu'une mémoire ROM, RAM ou FLASH ou autre carte mémoire;
■ Une donnée représentative des ports d'entrée/sortie utilisés et non utilisés de la première entité C1 ;
■ Une date de mise à jour DM_Co1 d'un micrologiciel CtrIProg de la première entité C1 ou une donnée de mise à jour d'un autre sous- programme mémorisé ;
■ Une donnée représentative de l'espace mémoire occupé par le micrologiciel ou par un autre sous- programme mémorisé. Lorsqu'un programme est installé sur une mémoire stable de la première entité, c'est-à-dire, par exemple, un espace mémoire modifié uniquement en cas de mise à jour du Firmware, il est possible de détecter un sous-programme pirate rajouté en mémoire à des fins malveillantes, du fait de l'espace supplémentaire occupé.
Un avantage de l'utilisation d'un paramètre de contexte ContextPI relatif à un identifiant matériel d'un composant est de détecter une éventuelle falsification de matériel par la seconde entité en comparant un identifiant matériel mémorisé initialement avec un identifiant matériel inclus dans un message de données utiles.
Un avantage de l'utilisation d'un paramètre de contexte ContextPI comportant une donnée représentative des ports d'entrée/ sortie utilisés ou non utilisés est de détecter une fonction hors de service du client ou débranchée ou non-connectée ou une connexion frauduleuse à la première entité.
Ce paramètre de contexte ContextPI est avantageusement envoyé à la seconde entité communicante à des fins de contrôle par la seconde entité communicante.
Le paramètre de contexte est par exemple crypté avant l'envoi à la seconde entité. Une clé publique KPubl fournie par la seconde entité est par exemple utilisée à cette fin.
La figure 5 représente le chiffrage du paramètre de contexte ContextPI à partir de la clef publique asymétrique KPubl de la seconde entité pour être déchiffrée à réception par la seconde entité S1 en utilisant sa clef privée asymétrique KPhvl .
Procédé de génération d'une requête d'enrôlement
Le procédé de l'invention peut comprendre des étapes d'enrôlement. L'enrôlement est réalisé de façon préalable aux transmissions des données utiles Datai entre deux entités communicantes C1 et S1 L'enrôlement permet d'enregistrer une première entité et des données relatives à cette première entité préalablement à la transmission de données utiles. Ces données relatives à la première entité correspondent par exemple à la clé secrète partagée. La clé secrète partagée peut être renouvelée régulièrement, par sécurité.
Comme représenté à la figure 3A, la première entité C1 procède à un enrôlement auprès de la seconde entité
S1 , en générant une requête notée MesEnM . Cette requête comprend par exemple l'identifiant C1_ld et le paramètre de contexte ContextPI crypté à l'aide de la clé publique KPub2.
Cette solution est performante notamment en termes de calculs puisqu'elle permet de chiffrer un message court, qui comprend la clef symétrique, avec une clef asymétrique.
Les identifiants de chaque première entité tel que C1 en association avec leur paramètre de contexte sont par exemple enregistrés dans une base de données de la seconde entité S1 .
La seconde entité S1 est alors capable d'associer une première entité C1 avec son paramètre de contexte ContextPI .
De manière non limitative, l'enrôlement peut être initié par la première ou par la deuxième entité. Les échanges de clefs publiques sont par exemple automatiquement effectués à réception d'un premier message MesEnr de l'une ou l'autre des entités C1 , S1 .
Les partages de clés peuvent aussi être réalisés par un programme de supervision accédant à la seconde entité et aux premières entités.
Selon d'autres exemples de réalisation, l'acquisition d'une clef publique du serveur KPubl peut être générée en utilisant un fichier tel qu'une image, un code captcha, un code barre ou un code 20, tel qu'un QR code. L'acquisition de la clef publique du serveur KPubl par le client peut être réalisée, dans ce dernier cas, par une lecture du code ou de l'image comprenant ladite clef par des moyens de capture d'une image tel qu'un capteur optique. Selon un mode de réalisation de l'invention, le procédé de génération d'une requête d'enrôlement MesEnM par le client C1 comprend une étape de génération d'une clef publique d'un client C1 , notée KPub2, et d'une clef privée d'un équipement notée KPriv2.
Dans ce dernier cas un couple de clefs est généré conjointement. Lorsque l'étape de génération du couple de clefs asymétrique a été préalablement effectué, le procédé de génération d'une requête d'enrôlement peut viser à extraire la clef publique du client C1 d'une mémoire dudit client C1 pour l'inclure dans la requête.
La requête d'enrôlement peut ainsi comprendre les données suivantes:
- le paramètre de contexte, ContextPI ;
- l'identifiant du client, C1_ld ;
- la clef publique asymétrique du client, KPub2. Un mécanisme de renouvellement de clefs asymétriques par la première entité ou par la seconde entité peut également être envisagé.
La nouvelle clef publique du client KPpub2 peut par exemple être transmise à destination du serveur S1 grâce à un nouvel enrôlement. Des étapes d'enrôlement sont alors réitérées.
Réception de la requête par le serveur
Lorsque la seconde entité S1 reçoit un message de données utiles, la seconde entité S1 engage par exemple une étape de déchiffrement des données au moyen de la clef secrète partagée.
Les données déchiffrées sont ensuite extraites et stockées dans une mémoire de la seconde entité S1 . La seconde entité S1 peut alors effectuer un contrôle du paramètre de contexte ContextPI et de l'identifiant du client C1_ld comparés aux données stockées dans sa base de données BDS1 . Si la comparaison est valide, le message est authentifié et son traitement est poursuivi.
Dans le cas contraire où les données comparées ne correspondent pas, la seconde entité peut, par exemple, stopper le traitement et envoyer un message d'alerte. La seconde entité peut également enclencher une vérification relative aux mises à jour des premières entités ou aux connexions de nouvelles entités.
Transmission des données utiles
Le procédé de communication de l'invention permet d'émettre et de recevoir des données sous forme de messages entre deux entités communicantes, ces messages sont notés Mes1 et comprennent les données utiles Datai . La figure 3C représente l'étape de transmission d'un message Mes1 comportant des données utiles Datai et un entête d'authentification Tokenl .
Le procédé de l'invention permet d'échanger des communications de manière sécurisée par la définition de messages dont la sécurité est « autoportée », c'est-à-dire que chaque message Mes1 échangé comprend ses propres informations de sécurité permettant de traiter et de déchiffrer le message envoyé.
L'invention ne nécessite pas notamment l'établissement d'une session entre les deux entités communicantes assurant un canal sécurisé entre ces deux entités.
L'invention comprend donc un mécanisme de génération d'entête d'authentification des messages de données transmis entre les deux entités.
La description qui suit décrit un mode de réalisation dans lequel le client C1 , représentant une première entité communicante, émet un message Mes1 vers le serveur S1 , représentant la seconde entité communicante, ce message étant vérifié par le serveur S1 . Les rôles de client et de serveur peuvent toutefois s'inverser entre les première et seconde entités communicantes.
Entête d'authentification d'un message Mes1
Consécutivement à l'étape d'enrôlement lorsqu'elle a lieu, l'invention met en œuvre un procédé de communication permettant de transmettre des messages de données utiles sécurisées Mes1 notamment grâce à l'entête d'authentification, noté Tokenl .
Le procédé de communication peut également être réalisé sans l'enrôlement préalable.
C'est par exemple le cas lorsque les données échangées dans le procédé d'enrôlement seraient définies par un programme superviseur dans chaque équipement C1 , S1 , comme par exemple l'échange des clefs publiques et des identifiants d'équipement.
L'entête d'authentification Tokenl est généré par un composant du client C1 . Côté serveur, un composant vérifie l'entête d'authentification reçu du client C1 . L'entête d'authentification Tokenl des messages Mes1 transmis comprend différents champs de données dont l'identifiant du client C1_ld.
Le Tokenl peut comprendre une identification Mesjd du message Mes1 , et éventuellement un profil de sécurité PRO_SEC qui permet de définir les conditions de chiffrement ou de déchiffrement. Le profil de sécurité est généré par un module de génération du profile de sécurité Pro_SecGen.
Le Tokenl peut comprendre une signature Signl .
L'entête d'authentification Tokenl peut être, par exemple, intégré aux entêtes du protocole transport utilisé selon les communications effectuées, comme un entête du protocole http par exemple.
Selon un mode de réalisation, l'entête d'authentification est ajouté à la liste des entêtes du protocole applicatif de transport utilisé par l'application.
Dans l'exemple du protocole HTTP, selon un mode de réalisation, le contenu de l'entête d'authentification générée par la présente invention est associé à l'entête «Authorization: »du protocole HTTP/1 .1 selon la RFC [261 6].
Le message Mes1 est généré par le module Mess_Gen en agrégeant l'entête Tokenl au champ utile Datai . Un module de codage coding_Module1 permet de chiffrer les données du message. Le module de codage chiffre alors les données du message Mes1 en fonction des données à chiffrer ou non, comme indiqué dans le profil de sécurité, et des clefs mémorisées et nécessaires pour effectuer ces opérations. Identifiant de message, Mes Id
Le calculateur peut récupérer un identifiant de message Mesjd qui est généré par un compteur de messages qui génère des identifiants de messages. La figure 2 représente un composant Mes_ID1 permettant de générer et traiter des identifiants de messages Mesjd.
Le compteur de message génère par exemple le Mesjd à partir d'un aléa, c'est-à-dire d'un paramètre aléatoire RamdomPI et d'une date d'expiration Stampi . L'aléa RamdomPI permet de définir un identifiant unique
Mesjd du message. L'état aléatoire RamdomPI peut être par exemple généré à partir d'un module de génération d'un aléa noté Ramdom Modulel . Ce dernier peut être exécuté par le calculateur.
Lorsque l'identifiant du message Mes_ID1 est calculé notamment à partir d'une date d'expiration Stampl définie par un module d'horloge Clock_Module1 locale de l'équipement C1 , l'identifiant Mesjd comprend une information relative à la date d'expiration Stampl du message Mes1 qui pourra être vérifiée à la réception par le serveur S1 .
Selon une alternative de réalisation, le Mesjd peut être généré avec un paramètre non aléatoire et une date d'expiration Stampl . L'identifiant de message Mes_ID1 peut être, par exemple, calculé à la volée, c'est-à-dire en temps réel par un calculateur de l'entité communicante C1 . L'identifiant du message Mes ID1 ainsi calculé est attribué à un message Mes1 .
Profil de sécurité
Selon un mode de réalisation, le profil de sécurité PRO_SEC permet de définir un algorithme qui sera utilisé pour signer ou chiffrer le contenu à transmettre. Le profil de sécurité PRO_SEC peut être généré à partir d'un module Pro_SecGen, noté à la figure 2. Le module Pro_SecGen permet de préconfigurer le profil de sécurité PRO_SEC de manière à répondre aux exigences d'une application donnée, d'un contexte donné ou d'une consigne émise par un utilisateur. Le profil de sécurité inclus dans le message de données utiles fournit alors des informations pour le mode de décodage.
Le profil de sécurité PRO_SEC peut aussi être utilisé pour indiquer et définir si la réponse au message Mes1 émise par le serveur S1 doit également être chiffrée et selon quel algorithme. Ce mode de réalisation est notamment avantageux lorsque le serveur transmet des commandes au client C1 .
Les différentes entités communicantes C1 , S1 , telles qu'un serveur S1 et une pluralité de clients Ci peuvent comprendre une configuration de profils de sécurité prédéfinis. Chaque profil prédéfini peut être activé pour définir une manière d'émettre et recevoir des données avec une autre entité.
Différents profils de sécurité peuvent ainsi être prédéfinis. Un premier profil de sécurité correspond par exemple à l'activation d'un paramètre de sécurité P1 incorporé dans l'entête d'authentification Tokeni du message Mes1 à transmettre par le client C1 au serveur S1 . Ce paramètre P1 Indique la présence d'un chiffrement des données utiles Datai transmises. Ainsi, le serveur S1 recevant ce paramètre P1 est capable de mettre en œuvre un déchiffrement des données transmises lorsque ces dernières sont chiffrées.
Un second profil correspond par exemple à l'activation d'un paramètre de sécurité P2 incorporé dans l'entête d'authentification Tokeni du message Mes1 à transmettre par le client C1 . Le paramètre P2 permet d'indiquer que l'entête d'authentification Tokeni est signé. La signature Signl est dans ce cas effectuée par le client C1 grâce à la clef privée du client KPhvl . La signature Signl est notamment incorporée dans l'entête d'authentification Tokeni .
Cette configuration a l'avantage de permettre d'établir des communications dont la sécurité est entièrement autoportée entre deux entités communicantes C1 , S1 .
Les différents profils de sécurité permettent par exemple d'adapter le niveau de sécurité des échanges de données entre les entités communicantes C1 , S1 selon le contexte d'échanges de données ou du type de données à échanger.
Les profils de sécurité PRO_SEC peuvent également utiliser un autre paramètre de sécurité représentatif du format de la signature utilisée pour l'entête d'authentification. Ce paramètre permet de définir l'utilisation ou non dans la signature de :
■ un ou plusieurs champs de données de l'entête d'authentification Tokeni du message;
■ des données utiles.
Un paramètre de sécurité
De l'entête peut également être représentatif du format de signature appliqué défini par au moins l'une quelconque de ces données ou une combinaison de ces données :
■ L'algorithme d'une fonction de hachage ;
■ L'algorithme de chiffrement ;
■ Le type de clef ; ■ L'indication des données à signer telle que par exemple les champs de données de l'entête d'authentification ainsi que les données utiles. Lorsqu'une entité reçoit un profil de sécurité PRO_SEC qu'elle ne connaît pas, c'est-à-dire qui n'est pas prédéfini dans une mémoire de l'entité, alors un profil par défaut peut être utilisé.
L'enrôlement peut notamment comprendre la transmission de la définition d'un profil de sécurité PRO_SEC. A réception, une entité peut alors enregistrer la définition du nouveau profil de sécurité et l'utiliser pour déployer une stratégie de chiffrement des messages émis ou de déchiffrement des messages reçus.
En outre, le profil de sécurité PRO_SEC comprend la désignation d'un algorithme de génération de signature comme par exemple RSA-SHA256 et le cas échéant la désignation d'un algorithme de chiffrement des données, comme par exemple AES.
Le profil de sécurité PRO_SEC comprend donc une indication sur la présence d'une signature Signl et sur la présence d'un chiffrement des données et le cas échéant, le profil de sécurité PRO_SEC comprend la désignation des algorithmes utilisés pour générer la signature ou chiffrer les données.
Signature
Selon un mode de réalisation, l'entête d'authentification Tokenl comprend également une signature des données transmises dans l'entête tokenl . Une signature Signl est créée au moyen d'un algorithme de génération d'une signature Signing_Module1 .
La signature Signl est par exemple réalisée au moyen d'une clef publique KPub2 acquise par l'entité communicante signant C1 ou au moyen de la clé secrète partagée KSec.
La signature est appliquée à un ensemble d'éléments du message dont les données utiles du message. Le paramètre de contexte peut notamment être intégré aux données utiles. Le paramètre de contexte peut aussi être transmis dans l'entête d'authentification et être pris en compte dans les données signées.
Les données utiles, lorsqu'elles sont signées, peuvent correspondre aux données utiles chiffrées ou aux données utiles non chiffrées.
La signature Signl peut par exemple être générée à partir des données: Mes_ID1 , C1_ld, PRO_SEC et du contenu du message Datai .
Un algorithme basé sur une méthode RSA SHA256 peut par exemple être mise en œuvre par l'invention pour générer la signature Signl . Nous rappelons que l'acronyme SHA désigne dans la terminologie anglo- saxonne : « Secure Hash Algorithm » et correspond à une fonction de hachage cryptographique. Le RSA est un algorithme de cryptographie asymétrique utilisant un couple de clefs asymétriques. Les deux algorithmes peuvent être associés dans un unique algorithme de chiffrement.
Un algorithme ECDSA désignant « Elliptic Curve Digital Signature
Algorithm » peut également être utilisé selon la méthode de l'invention. Il s'agit d'un algorithme de signature numérique à clef publique.
L'algorithme de génération d'une signature peut également être automatiquement déterminé, parmi plusieurs algorithmes, en fonction de l'équipement du client ou de son système d'exploitation et par exemple en fonction du paramètre de contexte. Un avantage est d'utiliser les ressources déjà existantes sur un équipement et de prendre en compte la configuration matérielle de l'équipement.
Un champ de l'entête d'authentification Tokenl comprend la signature Signl générée et un autre champ peut être renseigné dans l'entête Tokenl pour désigner l'algorithme permettant de générer la signature Signl . Un autre champ désigne également l'algorithme de chiffrement des données utiles Datai .
A la réception, le serveur S1 de données pourra décoder la signature Signl grâce au choix du bon algorithme tel qu'indiqué pour décoder la signature Signl .
Le terme « entête de protocole » est utilisé pour le différencier de l'entête d'authentification Tokenl de l'invention. A titre d'exemple, les différents champs du protocole http de l'exemple suivant peuvent être utilisés selon un mode de réalisation de l'invention pour signer l'entête d'authentification. La requête http ayant par exemple la fom1 e suivante :
· Entête:
POST http://control_center_urllrest/conso HTTP/1 .0
Accept : application/jsonUser-Agent: Mozil/a/4.0 (compatible; MSIE 5.0; Windows 95)
Authori:zation:JohnDo:Android22434:143089653303797:0neWa Signature_ RSA-SHA256_none: w9Bgirb8
• Corps de message (body) :
{"P l"-=2345,"HCHC"-=29384632,"HCHP"=2936241490}
Une ou plusieurs données relatives aux données du protocole transport peuvent être utilisées. Une partie d'un champ d'un entête du protocole peut également être utilisée. Par exemple, le champ Method du protocole http précisant le type de requête dont notamment les valeurs {GET, PUT, P0$1 }, présent dans la ligne de requête d'une requête http a un intérêt pour a un intérêt pour signer l'entête d'authentification Tokenl . Cette prise en compte permet notamment d'éviter les attaques de type « rejeu » par un tiers en réalisant une autre action que la requête initiale.
Un entête de message d'un protocole applicatif de transport est par exemple défini par un couple {clé :valeur}. Par exemple pour le protocole HTTP, l'entête [Expires: "Sat, 07 Nov 2015 00:59:59 GMT"] représente une date d'expiration de la requête. Selon ce même protocole, le type de requête et l'adresse de la ressource à interroger sont contenus dans la ligne d requête du message, par exemple [POST http:/lcontrol_center_uri/rest/conso HTTP/1 .1 ], et peuvent être utilisés pour générer la signature Signl .
Ce mode de réalisation est particulièrement avantageux pour assurer l'intégrité des échanges de données.
Selon ce même exemple, lorsque les données sont signées avec le couple [Expires: "Sat, 07 Nov 2015 00:59:59 GMT"], et avec le type de la requête HTTP, qui est dans ce cas une requête de type « POST », il n'est pas possible qu'une attaque par rejeu en réutilisant les mêmes données avec un type de requête différent ou/et avec une date d'expiration différente soit engagée par un tiers puisque dans ce cas la signature Signl ne sera pas reconnue par le serveur S1 .
On préfère toutefois une mise en œuvre du procédé de communication sécurisé de façon indépendante du protocole de communication.
La génération d'une signature Signl comprend par exemple l'exécution d'une fonction de hachage des données utiles non cryptées à signer. Les données utiles sont par exemple cryptées avant leur transmission. Ainsi, si un tiers, non autorisé, récupère un message signé, il n'est pas possible pour ce tiers de reconstituer les données qui ont été signées à partir de la signature Signl .
La signature peut également être appliquée aux données utiles cryptées.
La signature permet aussi de vérifier que les données transmises signées ne sont pas altérées.
La prise en compte dans les données signées de l'identifiant de message Mes_ID1 , qui change à chaque message Mes1 , permet grâce à la fonction de hachage de générer un contenu de la signature totalement différent d'un message à l'autre.
La génération d'une signature Signl peut également s'appliquer sur des données auxquelles une fonction de padding est appliquée, c'est-à-dire une fonction de remplissage des données. Chiffrement des données
Lorsque l'option du chiffrement des données d'un message émis par le client C1 est activée, le profil de sécurité PRO_SEC définit quel algorithme est utilisé pour chiffrer les données.
Le profil de sécurité PRO_SEC est indiqué dans l'entête d'authentification Tokenl du message Mes1 et permet d'indiquer la désignation de l'algorithme de chiffrement.
Le profil de sécurité PRO_SEC peut également faire partie des données signées Les données utiles du message Mes1 qui sont transmises au serveur S1 , sont chiffrées avec l'algorithme déterminé par le client C1 . Les données peuvent ensuite être déchiffrées, coté serveur, grâce à l'indication de l'algorithme utilisé.
L'algorithme de chiffrement des données peut être automatiquement déterminé, parmi une liste d'algorithmes disponibles, en fonction de l'équipement du client C1 ou de son système d'exploitation ou du paramètre de contexte. Un avantage est d'utiliser les ressources déjà existantes sur un équipement et en fonction de sa configuration.
Un exemple d'algorithme selon l'invention peut être AES désignant « Advanced Encryption Standard » dans la terminologie anglo-saxonne. Il s'agit d'un standard de chiffrement avancé également connu sous le nom de « Rijndael ».
D'autres algorithmes tels que Script ou Vscript peuvent être alternativement utilisés selon le procédé de l'invention. Les données utiles Datai sont chiffrées grâce à une clef secrète symétrique partagée KSec.
Les opérations de chiffrement sont avantageusement optimisées grâce au cryptage par clé symétrique.
L'utilisation du cryptage par clés asymétriques comprenant une clé publique et une clé privée peut également être envisagée mais implique des opérations sur des tailles de clés plus importantes et donc plus complexe et consommatrice de ressources pour le traitement des données.
Les profils de sécurité PRO_SEC indiquent avantageusement quel type de signature ou de cryptage. Il est par exemple précisé si un message comporte un entête signé et un contenu chiffré dans un sens.
Lorsque le client C1 est un objet connecté pilotable à distance à partir d'un serveur S1 et qu'un chiffrement des données émises du serveur S1 vers le client C1 a été décidé, alors un mécanisme impliquant la transmission du profile de sécurité peut également être mis en place.
Avantages de la transmission de champs dans l'entête
Le champ Mes_ID1 permet de définir une sécurité contre les attaques par rejeu de messages tiers.
Le champ C1_ld permet de définir une sécurité lorsqu'un équipement a été suspendu ou révoqué par le serveur S1 . La figure 4 représente des étapes du procédé de communication de l'invention du point de vue d'une entité communicante qui génère un message Mes1 .
Le procédé selon l'invention permet notamment de générer un message Mes1 et la succession d'étapes sont notées GEN(Mes1 ). Ce procédé comprend une génération d'un entête d'authentification Tokenl et des données utiles Datai .
Une première étape, notée GEN(ContextP1 ), consiste par exemple en la génération du paramètre de contexte ContextPI . Il comprend au moins une donnée représentative de la configuration matérielle de l'équipement. Il peut s'agir par exemple d'une variable d'état d'un port d'entrée/sortie tel que le port noté PortCI du client C1 . Le port Portl fait transiter les données émises par C1 sur le réseau Net1 notamment à destination du serveur S1 via le port PortSL
Selon d'autres exemples de réalisation, d'autres configurations matérielles peuvent être générées dans le paramètre de contexte ContextPI . Par exemple, il peut s'agir d'une date de mise à jour d'un « Firmware » CtrIProg, c'est-à-dire d'un logiciel d'exploitation matériel d'un ou plusieurs composants de l'équipement. App_C1 représente une application dédiée aux interactions avec l'environnement par la gestion de capteurs ou d'actionneurs. Le paramètre de contexte peut par exemple être représentatif du nombre de capteurs ou d'actionneurs en service.
Selon d'autres modes de réalisation, le paramètre de contexte ContextPI peut être complexe et comprendre plusieurs valeurs représentatives d'un ensemble de différentes configurations matérielles de différents composants du client C1 , tel qu'un capteur, un port, une mémoire, un microprocesseur ou une antenne. Le nombre de port d'entrée et de sortie connectés peut également être pris en compte. Une donnée représentative des ports d'entrée et de sortie utilisés et non utilisés peut également être intégrée au paramètre de contexte.
Des identifiants de composants peuvent également être intég dans le paramètre de contexte ContextPI . Le paramètre de contexte ContextPI est par exemple automatiquement généré en fonction des variables qui le composent.
Le procédé comprend par exemple une étape suivante de génération du profil de sécurité PRO_SEC notée GEN(PRO_SEC). Le profil de sécurité PRO_SEC généré est intégré dans l'entête d'authentification tokenl .
Le procédé comporte par exemple ensuite une étape d'insertion de la signature Signl , notée JNS(Sign1 ), dans le message Mes1 .
Le procédé comporte par exemple une étape suivante d'insertion de l'identifiant du client C1_ld, notée INS(C1_ld) dans le message Mes1 . L'identifiant C1_ld est préférentiellement inclus dans l'entête d'authentification.
Le procédé comprend par exemple une étape suivante INS(PRO_SEC) d'insertion du profil de sécurité PRO_SEC qui définit les conditions de chiffrement et de la génération d'une signature Signl .
Le message Mes1 comportant l'entête d'authentification Tokenl et les données utiles Datai peut alors être généré GEN(Mesl ) par l'agrégation de l'entête et des données utiles.
Ce message de données utiles peut ainsi être émis, selon un protocole de communication Utilisé, pour émettre des données entre le client C1 et le serveur S1 .
Serveur, Gestion des enrôlements
Le serveur de données qui correspond à une des entités communicantes de l'invention est destiné à gérer des transmissions de données avec une pluralité de clients Ci. Il comprend à cet effet un composant permettant de gérer les équipements, telle qu'une mémoire dans laquelle la base de donnée BDS1 enregistre les données de chaque client Ci tel que les identifiant Cijd et les paramètres de contexte ContextPI .
En outre, le serveur S1 peut comprendre une mémoire pour stocker les données relatives aux chiffrements en association avec chaque équipement client dans une mémoire notée DBS2 qui stocke des clefs publiques asymétrique KPub2 des équipements C1 , ainsi que les clefs symétriques KSec sécrètes partagées. Le serveur exécute par exemple une première fonction de stockage des comptes clients et une seconde fonction de réception et de traitement de requêtes d'enrôlement émises par des équipements clients Ci.
Le traitement d'une requête comprend par exemple des opérations de déchiffrement des données et des opérations de vérifications que l'équipement client Ci n'est pas suspendu ou révoqué ou que le message reçu est valide visant à vérifier, ou qu'une anomalie matérielle ne soit survenue dans l'équipement client Ci. Le paramètre de contexte peut par exemple être analysé pour une analyse de conformité de la configuration matérielle de l'équipement.
Serveur - réception d'un message, déchiffrement
Le message Mes1 émis par l'équipement client C1 est reçu par le Serveur S1 via une interface de communication. Un composant du serveur S1 réalise par exemple une étape de vérification du message reçu Mes1 et notamment sa date d'expiration.
Le serveur S1 comprend notamment un jeu de clefs asymétriques comprenant une clef publique KPubl et une clef privée KPhvl pour les besoins de déchiffrement, en fonction des paramètres du profile de sécurité.
Le message Mes1 , reçu par le serveur S1 , a par exemple été chiffré, par le client C1 , avec la clef publique asymétrique du serveur KPubl . Cette clef publique asymétrique du serveur KPubl a été préalablement acquise par l'équipement, par exemple, lors de son installation ou lors d'un enrôlement. Un programme de supervision peut également être utilisé pour paramétrer un client ou le serveur.
Une vérification de l'entête d'authentification Tokenl peut être réalisée grâce à un module de vérification notée Token_ChK1 .
Serveur - vérification de l'identifiant de message
La vérification du message comprend notamment le contrôle de l'identifiant du message Mes_ID1 , et en particulier sa date d'expiration. Lorsque la date d'expiration est périmée, le serveur S1 peut engager un refus du message reçu Mes1 .
Dans le cas d'un écart de date trop important, le serveur S1 peut renvoyer une erreur spécifique contenant la date courante du serveur. Cette variante permet que le client C1 puisse se resynchroniser et réémettre à un nouveau des messages avec des entêtes d'authentification Tokenl valides.
La vérification du MESJD1 par le serveur S1 permet de limiter les attaques réseau par rejeu de message Mes1 .
Une seconde vérification effectuée par le serveur S1 peut consister notamment à vérifier si le message Mes1 a déjà été reçu par ce dernier. Si le message a déjà été reçu, c'est-à-dire que le MESJD1 du message reçu Mes1 est identique à un MESJD d'un message précédemment reçu alors le message Mes1 n'est pas traité par le serveur S1 .
L'identifiant de message peut également être signé, par exemple, à l'aide d'une clé secrète symétrique partagée mémorisée par le serveur. La validité de l'identifiant de message est alors également confirmée lors de la vérification de la signature dans l'entête d'authentification.
Lorsque la signature Signl est invalide, le message Mes1 est par exemple rejeté par le serveur S1 .
Lorsque la signature est réalisée à partir d'une clé asymétrique privée, le serveur réalise par exemple une lecture de la clé asymétrique publique en mémoire du serveur ou directement auprès de l'équipement. Vérification de la signature
Lorsque les messages transmis sont signés avec une clef symétrique secrète partagée KSec, la clef symétrique secrète partagée KSec est stockée en mémoire par le serveur S1 afin d'être utilisée pour vérifier la signature Signl .
Les messages peuvent aussi être signés à l'aide d'une clef asymétrique publique KPubl fournie par le serveur KPrivI qui utilise alors sa clé asymétrique privée pour vérifier la signature Signl .
De préférence une clef symétrique secrète partagée sera utilisée pour des équipements ne disposant pas d'une puissance de calcul importante.
Le profil de sécurité PRO_SEC comprend notamment le format de la signature Signl dont les données signées et la désignation de l'algorithme utilisé.
Déchiffrement du message après vérifications Lorsque l'identifiant de message MESJD1 et que l'authentification du message Mes1 ont été vérifiés par le serveur S1 , ce dernier réalise par exemple le déchiffrement des données comme indiqué dans le profil de sécurité PRO_SEC.
Le profil de sécurité PRO_SEC indique par exemple que les données utiles sont chiffrées avec la clef symétrique secrète partagée et permet au serveur S1 d'engager le déchiffrement des données utiles datai du message Mes1 grâce à la clef symétrique partagée KSec stockée en mémoire par le serveur.
Le profil de sécurité peut également indique que les données utiles sont chiffrées avec la clef asymétrique publique fournie par le serveur. Dans ce cas le serveur réalise un décryptage à l'aide de sa clé asymétrique privée.
De préférence, le cryptage à l'aide d'une clé secrète symétrique partagée est préféré pour les équipements disposant de peu de puissance de calcul.
Les données utiles déchiffrées sont ensuite traitées par le serveur central de gestion de données.
On peut aussi envisager la transmission non chiffrée des données utiles. Dans ce cas, le non chiffrement des données utiles est indiqué dans le profil de sécurité.
Traitement du message après vérifications
Les données utiles Datai , une fois décodées par le serveur S1 , sont traitées par le module APP_S1 . L'utilisation spécifique des données récupérées par le serveur central de gestion des données n'est pas décrite dans la présente description. Réciproquement, coté client, le composant APP_C1 permet par exemple de gérer un ou plusieurs capteurs ou un ou plusieurs actionneurs.
Avantages
La méthode de l'invention permet notamment d'établir une communication de manière sécurisée sous forme de requête et acquittements entre un client C1 et un serveur S1 sans avoir à gérer les états d'une communication, c'est-à-dire sans avoir à gérer des sessions entre les entités communicantes. Ainsi, l'invention permet de s'affranchir d'un protocole préliminaire complexe, tel que VPN, entre deux entités communicantes d'un réseau.
Les moyens d'une communication sécurisée selon l'invention peuvent notamment être implémentés en respectant les principes d'une architecture de type REST.
L'invention permet également de s'affranchir d'échanges de certificats d'authentification Un autre avantage de l'invention est également d'induire qu'un faible coût de déploiement étant donné que la communication sécurisée peut être établie rapidement entre deux entités communicantes dès leur installation sur le ou les réseaux de communication.
La solution de l'invention permet également de suspendre ou de révoquer un équipement C1 défectueux détecté par le serveur S1 .

Claims

REVENDICATIONS
Procédé de communication entre au moins deux entités communicantes (C1 , S1 ), une première entité communicante (C1 ) générant au moins un message (Mes1 ) de données utiles, émis vers une seconde entité communicante (S1 ), comprenant un champ utile comportant des données utiles (Datai ) et un entête d'authentification (Tokenl ), ledit procédé étant caractérisée en ce qu'il comporte, pour la génération dudit message (Mes1 ):
■ une génération d'un paramètre de contexte (ContextPI ) comportant au moins une donnée représentative de la configuration matérielle (ctrIProg) de la première entité (C1 ) ;
■ une génération d'un profil de sécurité (PRO_SEC) intégré dans l'entête d'authentification (Tokenl ) et définissant les conditions:
■ de chiffrement des données utiles (Datai ) du message ;
■ de génération d'une signature (Signl ) par un algorithme de signature (Signing_Module1 ) appliqué au moins aux données utiles (Data 1 ) ;
■ une génération de ladite signature (Signl ) intégrée dans l'entête d'authentification ;
■ une insertion d'un identifiant mémorisé (C1_ld) de la première entité communicante (C1 ) dans l'entête d'authentification (Tokenl );
■ une insertion du paramètre de contexte (ContextPI ) dans le champ utile (Datai ) ou dans l'entête d'authentification (Tokenl );
■ une agrégation du champ utile (Datai ) et de l'entête (Tokenl ).
Procédé de communication selon la revendication 1 , caractérisé en ce que le message (Mes1 ) émis à la seconde entité communicante (S1 ) est transmis dans une couche applicative d'un réseau de données auquel sont connectées la première et la seconde entité communicante (C1 . S1 ).
Procédé de communication selon l'une quelconque des revendications 1 à 2, caractérisé en ce le paramètre de contexte (ContextPI ) comprend en outre une ou plusieurs des données parmi les suivantes : ■ Un identifiant (ldCc-1 ) d'un calculateur (Co1 ) de la première entité (C1 );
■ Une donnée représentative des ports d'entrée/sortie utilisés et non utilisés de la première entité (C1 ) ;
■ Une date de mise à jour (DM_Co1 ) d'un micrologiciel de la première entité (C1 ) ;
■ Une donnée représentative de l'espace mémoire occupé par le micrologiciel.
Procédé de communication selon l'une quelconque des revendications 1 à 3, caractérisé en ce que le paramètre de contexte (ContextPI ) est chiffré par une première clef publique asymétrique (KPubl ) avant d'être intégré dans le message émis, ladite première clef publique asymétrique (KPubl ) étant enregistrée dans une mémoire de la première entité (C1 ), le paramètre de contexte (ContextPI ) étant déchiffré grâce à une première clef privé asymétrique (KPhvl ) enregistrée dans une mémoire de la seconde entité (S1 ).
Procédé de communication selon l'une quelconque des revendications 1 à 4, caractérisé en ce que la seconde entité (S1 ) comprend une base de données (DBS1 ) mémorisant une pluralité de paramètre de contexte (ContextPI ), chacun étant associé à une parmi plusieurs premières entités (Ci), la réception par la seconde entité (S1 ) dudit message émis par la première entité (C1 ) comportant :
■ Une vérification que le paramètre de contexte (ContextPI ) et l'identifiant (C1_ld) de la première entité (C1 ) reçus par la seconde entité (S1 ) sont présents dans la base de données (DBS1 );
■ Un traitement dudit message (Mes1 ) reçu lorsque l'état de vérification est validé.
Procédé de communication selon la revendication 5, caractérisé en ce que la réception par la seconde entité (S1 ) dudit message émis par la première entité (C1 ) comporte en outre :
■ Une analyse par un gestionnaire d'application (App_S1 ) de la seconde entité (S1 ) afin de déterminer si une mise à jour d'un micrologiciel ou une installation d'une nouvelle première entité communicante a eu lieu ;
■ Une mise à jour de la base de données (DBS1 ) de la seconde entité (S1 ) prenant en compte le paramètre de contexte (ContextPI ) et l'identifiant de la première entité reçus lorsque l'analyse indique qu'une mise à jour ou qu'une nouvelle installation a eu lieu.
7. Procédé de communication selon l'une quelconque des revendications 1 à 6, caractérisé en ce que le paramètre de contexte (ContextPI ) est inclus dans l'entête d'authentification (Tokenl ), la signature (Signl ) étant appliquée également au paramètre de contexte (ContextPI ).
8. Procédé de communication selon la revendication 7, caractérisé en ce que les données utiles (Datai ) comprennent des données collectées par au moins un capteur (REF) de la première entité communicante (C1 ).
9. Procédé de communication selon l'une quelconque des revendications 7 à 8, caractérisé en ce qu'il comprend une étape transmission d'une information comprenant une clef secrète partagée symétrique (MesSyml ) préalable à la génération dudit message (Mes1 ) de transmission de données utiles (Datai ), ladite clef secrète partagée symétrique (KSec) étant utilisée pour générer la signature (Signl ) et pour chiffrer des données utiles.
10. Procédé de communication selon la revendication 9, caractérisé en ce qu'il comprend préalablement à l'étape de transmission de la clef secrète partagée symétrique (Ksec);
■ Une génération d'une seconde clef publique asymétrique (KPub2) et d'une seconde clef privée asymétrique (Kpriv2) par un module de génération de clefs asymétriques (AsymKGen2) de la première entité (C1 ), les dites clefs générées étant enregistrées dans une mémoire ;
■ Une transmission par la première entité (C1 ) vers la seconde entité (S1 ) d'une requête d'enregistrement (MesEnM ) comportant l'identifiant de la première entité (C1_ld), le paramètre de contexte (ContextPI ) et ladite seconde clef publique asymétrique (KPub2) ;
■ Une transmission par la seconde entité (S1 ) vers la première entité (C1 ) d'un acquittement indiquant l'enregistrement de la première entité (C1 ) dans la base de données (BDS1 ) de la seconde entité
(S1 );
■ Un chiffrement à partir de la seconde clef privée asymétrique (Kpriv2) de la clef secrète symétrique (Ksec). 1 1 . Procédé de communication selon la revendication 10, caractérisé en ce qu'il comprend un renouvellement périodique de la clef secrète partagée symétrique (KSec) comportant:
■ Une génération d'une nouvelle clef secrète symétrique (KSecNew) à partir d'un module de génération de clef symétrique (SynKGen) ; ■ Un chiffrement, par la seconde clef privée asymétrique (KPriv2), de la clef secrète symétrique (KSec) mémorisée dans une mémoire de la première entité (C1 ) ;
■ Une transmission de la nouvelle clef secrète partagée symétrique (KSec) à la seconde entité (S1 ).
12. Procédé de communication selon la revendication 10, caractérisé en ce qu'il comprend un renouvellement périodique de la clef secrète privée (Ksec) comportant :
■ Une génération d'une nouvelle clef secrète symétrique (KSecNew) à partir d'un module de génération de clef symétrique (SynKGen) ;
■ Une transmission de la nouvelle clef secrète partagée symétrique (KSecNew).
13. Procédé de communication selon l'une quelconque des revendications 1 à 6, caractérisé en ce que les données utiles comprennent le paramètre de contexte (ContextPI ), le paramètre de contexte (ContextPI ) étant généré et émis régulièrement.
14. Procédé de communication selon l'une quelconque des revendications 1 à 13, caractérisé en ce que la génération dudit message (Mes1 ) comprend: ■ Une génération d'un identifiant de message (Mes_ID1 ) calculé à partir :
o d'un paramètre généré aléatoirement (RamdomPI ) et fourni par un module aléatoire (Ramdom_Module1 ) et ; o d'une date limite de validité générée par un module d'horloge
(Clock_Module1 );
■ Une insertion de l'identifiant de message (Mes_ld1 ) dans l'entête d'authentification (Tokenl ) dudit message (Mes1 ). 15. Procédé de communication selon la revendication 15, caractérisé en ce que le profil de sécurité (PRO SEC) définit les conditions de génération d'une signature (Signl ) par l'algorithme de signature (Signing_Module1 ) qui est appliqué aux données utiles (batal ) du message (Mes1 ), au paramètre de contexte (Contextl ) et à l'identifiant de message (Mes_ID1 ).
16. Procédé de communication selon l'une quelconque des revendications 1 à 15, caractérisé en ce les données signées par l'algorithme de signature (Signl ) comprennent :
■ le profil de sécurité (PRO_SEC);
■ l'identifiant de la première entité (C1_ld).
17. Entité communicante caractérisée en ce qu'elle comprend au moins une mémoire, un calculateur et une interface de communication pour l'exécution du procédé de communication selon l'une quelconque des revendications 1 à 1 6.
18. Entité communicante selon la revendication 17 caractérisée en ce qu'elle comprend au moins un capteur de données.
19. Programme d'ordinateur comportant un ensemble d'instructions pour la mise en œuvre du procédé de communication de l'une quelconque des revendications 1 à 18.
EP18723562.7A 2017-05-18 2018-05-17 Procede de securisation d'une communication sans gestion d'etats Pending EP3625928A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1754413A FR3066666B1 (fr) 2017-05-18 2017-05-18 Procede de securisation d'une communication sans gestion d'etats
PCT/EP2018/062974 WO2018211026A1 (fr) 2017-05-18 2018-05-17 Procede de securisation d'une communication sans gestion d'etats

Publications (1)

Publication Number Publication Date
EP3625928A1 true EP3625928A1 (fr) 2020-03-25

Family

ID=60202076

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18723562.7A Pending EP3625928A1 (fr) 2017-05-18 2018-05-17 Procede de securisation d'une communication sans gestion d'etats

Country Status (5)

Country Link
US (1) US11303453B2 (fr)
EP (1) EP3625928A1 (fr)
CN (1) CN111164933A (fr)
FR (1) FR3066666B1 (fr)
WO (1) WO2018211026A1 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IT201800011129A1 (it) * 2018-12-14 2020-06-14 Toi Srl Sistema, dispositivo e metodo per trasferire in maniera sicura informazioni da un apparecchio a una blockchain
US11539517B2 (en) * 2019-09-09 2022-12-27 Cisco Technology, Inc. Private association of customer information across subscribers
US11811743B2 (en) * 2020-10-26 2023-11-07 Micron Technology, Inc. Online service store for endpoints
WO2023090918A1 (fr) * 2021-11-17 2023-05-25 Samsung Electronics Co., Ltd. Procédé et système d'annonce sécurisée liée dans un système à bande ultralarge (uwb)
CN114499969B (zh) * 2021-12-27 2023-06-23 天翼云科技有限公司 一种通信报文的处理方法、装置、电子设备及存储介质
US20240056651A1 (en) * 2022-08-09 2024-02-15 Dish Network, L.L.C. Digital rights management using a gateway/set top box without a smart card

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7530096B2 (en) * 2003-11-12 2009-05-05 Nokia Siemens Networks Oy Intermediate node aware IP datagram generation
CN101626294A (zh) * 2008-07-07 2010-01-13 华为技术有限公司 基于身份的认证方法、保密通信方法、设备和系统
EP2173058B1 (fr) * 2008-10-01 2012-02-29 Sap Ag Signatures digitales XML sans contexte et contexte réactive pour les messages SOAP
US8843764B2 (en) * 2011-07-15 2014-09-23 Cavium, Inc. Secure software and hardware association technique
US9124564B2 (en) * 2013-08-22 2015-09-01 Cisco Technology, Inc. Context awareness during first negotiation of secure key exchange
KR101521808B1 (ko) * 2014-02-20 2015-05-20 한국전자통신연구원 클라우드 환경에서의 상황인지형 보안 통제 장치, 방법, 및 시스템
US9641488B2 (en) * 2014-02-28 2017-05-02 Dropbox, Inc. Advanced security protocol for broadcasting and synchronizing shared folders over local area network
US9799142B2 (en) * 2014-08-15 2017-10-24 Daqri, Llc Spatial data collection
US9942201B1 (en) * 2015-12-16 2018-04-10 vIPtela Inc. Context specific keys
KR101795457B1 (ko) * 2016-09-27 2017-11-10 시큐리티플랫폼 주식회사 보안 기능이 강화된 디바이스의 초기화 방법 및 디바이스의 펌웨어 업데이트 방법
US10826876B1 (en) * 2016-12-22 2020-11-03 Amazon Technologies, Inc. Obscuring network traffic characteristics

Also Published As

Publication number Publication date
FR3066666B1 (fr) 2020-07-03
US20210144130A1 (en) 2021-05-13
WO2018211026A1 (fr) 2018-11-22
US11303453B2 (en) 2022-04-12
FR3066666A1 (fr) 2018-11-23
CN111164933A (zh) 2020-05-15

Similar Documents

Publication Publication Date Title
EP3625928A1 (fr) Procede de securisation d'une communication sans gestion d'etats
EP2820795B1 (fr) Procede de verification d'identite d'un utilisateur d'un terminal communiquant et systeme associe
EP3280089B1 (fr) Procédé de génération de clé et procédé de contrôle d'accès
EP3174241B1 (fr) Méthode d'établissement d'une communication sécurisée de bout en bout entre le terminal d'un utilisateur et un objet connecté
EP3375133B1 (fr) Procede de securisation et d'authentification d'une telecommunication
EP3222025B1 (fr) Procédé de contrôle d'accès a un système de production d'un système informatique non connecté à un système d'information dudit système informatique
WO2017055716A1 (fr) Procede et dispositif d'authentification ameliores
EP3238200A1 (fr) Entité électronique sécurisée, appareil électronique et procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée
EP3840324B1 (fr) Liaison série asynchrone sécurisée
EP3991381B1 (fr) Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion
WO2019228853A1 (fr) Methode d'etablissement de cles pour le controle d'acces a un service ou une ressource
FR3057973A1 (fr) Procede d'installation d'un certificat dans un calculateur de vehicule, calculateur et systeme associes
FR3032846A1 (fr) Procede de communication securisee entre un systeme d'exploitation d'un terminal et un dispositif distinct du terminal
EP3725025B1 (fr) Procede de communication securise
CN114726865B (zh) 数据质押方法、系统、电子装置和存储介质
Subhani et al. Smarter world, bigger threats: Understanding the internet of things
Assaig et al. Development of a lightweight IoT security system
EP3503500B1 (fr) Procédé pour créer une signature électronique à distance au moyen du protocole fido
FR3038414A1 (fr) Procede et systeme de controle d'acces a un service via un media mobile.
FR2956272A1 (fr) Authentification par mot de passe a usage unique
FR2900776A1 (fr) Procede de securisation de donnees
WO2013140078A1 (fr) Procede de generation et de verification d'identite portant l'unicite d'un couple porteur-objet

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20191218

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20201217