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)
• General Engineering & Computer Science (AREA)
• Computer Hardware Design (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)

Applications Claiming Priority (2)

Publications (1)

Family

ID=60202076

Family Applications (1)

Country Status (5)

Families Citing this family (6)

Family Cites Families (11)

• 2017
  • 2017-05-18 FR FR1754413A patent/FR3066666B1/fr active Active
• 2018
  • 2018-05-17 US US16/614,535 patent/US11303453B2/en active Active
  • 2018-05-17 CN CN201880042967.2A patent/CN111164933A/zh active Pending
  • 2018-05-17 EP EP18723562.7A patent/EP3625928A1/de active Pending
  • 2018-05-17 WO PCT/EP2018/062974 patent/WO2018211026A1/fr unknown

Also Published As

Similar Documents

Legal Events