Method for capturing packets from an encrypted session

Abstract

The invention relates to a method for capturing data packets from an encrypted session established between a terminal unit and a data server, said data packets comprising data for determining a security key used to encrypt the data packets, the method being implemented by a device routing the data packets between the terminal unit and the data server and comprising: analyzing a plurality of data packets transmitted by the terminal unit and destined for the server; identifying, from the plurality of analyzed data packets, a collaboration data packet, said collaboration data packet comprising the determining data corresponding to a security key used to encrypt a data packet transmitted by the terminal unit to the data server prior to the terminal unit sending said collaboration data packet; and decrypting the received collaboration data packet using the security key corresponding to the determining data from the identified collaboration data packet.

Description

Technical Field

[0001] This invention relates to the transmission of multiplexed data streams in protocols (such as transport protocols) of communication infrastructure, and aims to provide a solution to allow processing to be applied to a specific data stream in a set of transmitted data streams. Background Technology

[0002] In communication networks, data flow routing is becoming increasingly secure, achieved through authentication and confidentiality mechanisms applied to the data exchanged between two peers. This security has been enhanced with the adoption of HTTP / 2 (Hypertext Transfer Protocol / 2) over TLS (Transmission Control Protocol) and TCP (Transmission Control Protocol), followed by the rapid development of the QUIC (Fast UDP Internet Communication) transport protocol. This QUIC protocol is widely used by various web browsers and application servers. QUIC combines the transport, multiplexing, and protection functions of RTP (Real-Time Transport Protocol), MPTCP (Multipath TCP), TCP, SCTP (Stream Control Transfer Protocol), and TLS protocols into a single protocol. Its security is further enhanced by integrated authentication and confidentiality mechanisms for signaling data present in the packet header and key updates from the initial message exchange (handshake process) within the protocol. It should also be noted that the QUIC protocol is an example of a protocol with this level of security and multiplexing of several data streams within a single connection; however, these features are also applicable to other protocols. Therefore, the MPTCP, HTTP3, SCTP, SPDY, and HTTP2 protocols also allow multiplexing of several data streams, and thus have the limitations described below.

[0003] Operators routing data transmitted via protocols such as QUIC face challenges in two areas: firstly, identifying data streams due to security mechanisms like encryption; and secondly, multiplexing data streams within a single data session. This can occur, for example, in the context of vehicle data service development. It's worth noting that Europe is currently deploying an eCall service. eCall represents an initiative by the European Commission aimed at eventually introducing a public service-based automated emergency call system (eCall) in all vehicles sold in the EU, allowing a vehicle involved in an accident (regardless of which EU country) to immediately call emergency services while simultaneously sending a set amount of data, including its precise location. This system is based on a geolocation-enhanced version of the single European emergency number 112, allowing emergency services to respond more quickly based on the severity of the accident and the type of vehicle involved.

[0004] Therefore, by integrating a networked unit called a TCU (Telematics Control Unit) equipped with a SIM card, automakers have begun deploying eCall services in all new models released since April 2018. However, the development of this eCall assistance service appears to be accompanied by other services provided by this TCU unit. These services could be driver assistance services, entertainment services, or even vehicle control services. The data associated with these different services requires different processing by the operator. Thus, customers can be charged for data related to entertainment services, vehicle control data can be copied for use in case of problems, and assistance data can be given high priority because this data must not experience any delay during its transmission. For example, this data transmitted by the TCU unit also has the specific characteristic of being routed to one or more indiscriminate servers. In fact, content providers or data caching solution providers appear to be able to send or receive multiple types of data (assistance, entertainment, control, etc.) from the various types mentioned above. Document US 2005-0177506 A1 describes a solution for differentiating streams for billing associated with each stream, but the proposed solution is based on differentiating streams according to IP address. This solution is ineffective for the aforementioned problem because the operator's routing equipment assumes these flows all originate from a single device, such as a TCU unit, and therefore from a single IP address. It should be noted that the destination address also cannot distinguish flows, because if the content server or caching server is a receiver of several different flows, the address could also be a common address for various multiplexed data flows.

[0005] The purpose of this invention is to provide an improvement over the prior art. Summary of the Invention

[0006] The present invention uses a method to improve this situation, a method for identifying a first message related to a first application from a set of messages associated with multiple applications, the first message being transmitted by a terminal unit to a data server by means of a routing device capable of applying processing to attributes associated with the first message, the method being implemented by the terminal unit and comprising:

[0007] - Add attributes related to the first message to the information data packet, which incorporates the processed attributes;

[0008] - Apply tags to information data packets that include added attributes;

[0009] - Transmit the data packet containing the applied tags to the data server.

[0010] Therefore, this method allows operators managing devices such as routers or DPI (Deep Packet Inspection) devices, or any other devices in a communication network, to explicitly identify messages from a set of messages without complex processing. This identification is becoming increasingly complex, partly because content servers merge a wide variety of independent services, and partly because protocols increasingly multiplex messages from various applications or terminals that transmit messages via terminal units. In such cases, identifiers such as the IP addresses of terminal units and / or data servers are insufficient to definitively identify messages from applications or terminals. This method allows terminal units to identify and merge certain messages within specific data packets based on various attributes, such as the terminal as the message source, the type of application, or even the application being used and the associated quality of service. Therefore, the unit constructs a data packet that merges messages received from devices in the network for specific processing, and applies a tag to the packet, for example, by modifying parameters used to mark the message, in a way that allows the device to quickly identify the packet when reading the tag parameters, so that processing can then be applied to the message added to the packet by the terminal unit.

[0011] According to one aspect of the identification method, the terminal unit transmits multiple messages to the data server in a secure session between the terminal unit and the data server.

[0012] This identification method becomes particularly important when data is exchanged securely between a terminal unit and a server (i.e., via a connection that guarantees message confidentiality). In this case, only a device possessing the key used to decrypt the message can access the message content. Now, this method allows the terminal unit to apply a flag, for example, to the unencrypted portion of the data packet containing the message by modifying a flag parameter, enabling the device to perform processing that neither requires access to the data packet content nor modification of the data packet.

[0013] According to another aspect of this identification method, the information data packet is a data packet of the Secure Stream Multiplexing (SMU) protocol.

[0014] Secure stream multiplexing protocols such as QUIC, HTTP / 2, or HTTP / 3 offer advantages for implementing this identification method. For example, the QUIC protocol offers numerous advantages to content providers and users, particularly its message multiplexing capabilities and inherent protection of header data. This method can be advantageously implemented by adding messages to QUIC packets that can be processed by the device. In practice, this protocol is increasingly supported by user units and data servers, allowing for message multiplexing. This labeling of QUIC packets allows the device to quickly distinguish between packets to be processed and other packets that do not require processing and are routed to the data server.

[0015] According to another aspect of this identification method, the secure flow multiplexing protocol is one of the following protocols: MPTCP, SCTP, QUIC, HTTP2, SPDY, and HTTP3.

[0016] QUIC, HTTP / 2, and HTTP / 3 protocols are increasingly being used by content providers and device providers for data transmission. An advantage of using these protocols is the ability to deploy this approach quickly.

[0017] According to another aspect of this identification method, the protocol is the QUIC protocol, and the application of the markers includes modifying the binary elements in the "spin bit" and / or "reserved bit".

[0018] The spin bit is a bit in the header of the QUIC protocol. This bit is particularly useful for calculating the latency of data transmission between the transmitter and receiver. The use of this bit allows devices to quickly identify QUIC packets to be processed. This bit is included in the QUIC protocol specification and is therefore supported by all QUIC applications, but it is not always used, especially when latency calculation is not required.

[0019] The use of two "reserved bits" enables the differentiation of four stream management packets, allowing the device to apply four different processing methods to the messages included in the management packets that include these four options. In addition to the "spin bit," the use of "reserved bits" allows for eight different processing methods to be applied to the messages in the stream management packets. The terms spin bit and reserved bit are associated with the QUIC protocol and it is conceivable that bits with the same function can be used in any secure stream multiplexing protocol.

[0020] According to another aspect of this identification method, the information data packet includes attributes corresponding to a specific application.

[0021] This method can be implemented to apply processing to a specific application. Therefore, the terminal unit can instantiate several stream management packets, each including a message related to a specific application, and the application is tagged (in this case, corresponding to modified tag parameters) to be specific to the stream management packet. Thus, the device can apply specific processing to the stream management packets based on the different parameters of each packet.

[0022] According to another aspect of this identification method, the terminal unit is a device for accessing a local area network (LAN), which routes multiple messages from and to terminals on the LAN.

[0023] This identification method can be advantageously implemented by devices used for accessing a local area network (such as an access gateway in a home network or a TCU-type unit in a vehicle network). In practice, the terminal unit can distinguish between different applications and merge messages from these different applications into separate data packets, allowing devices in the network routing the packets to apply specific processing based on the packet's tagging parameters.

[0024] According to another aspect of the invention, the identification method includes selecting the first message based on one or more criteria from the following list before adding the attribute:

[0025] -The first application is included in the list of applications managed by the terminal unit;

[0026] - The first message is received from the terminal, whose identifier is included in the list of identifiers managed by the terminal unit.

[0027] - The first message includes data related to quality of service, which is included in a dataset managed by the terminal.

[0028] This identification method can be advantageously implemented for a limited number of applications. For example, consider only applications that generate data for charging users, and whose messages are added to the management packet. The method can also be instantiated against a list of terminals, regardless of whether this is independent of the applications used by those terminals. Message data (such as IP addresses or even quality-of-service related fields) can also be used to determine whether to add the message to the management packet, regardless of whether this is associated with the application and / or terminal that supports that application.

[0029] The various aspects of the identification methods described above can be implemented independently of each other or in combination with each other.

[0030] The present invention also relates to a method for processing attributes related to a first message concerning a first application, the first message being transmitted from a terminal unit to a data server, the method being implemented by a device that routes the first message and is capable of applying processing to attributes related to the first message, the method comprising:

[0031] - Detect information data packets including attributes added by the terminal unit based on the tags applied to the received information data packets;

[0032] - Process attributes included in the received information data packets.

[0033] This processing method allows processing to be applied to data packets that potentially combine several messages requiring processing. Therefore, the method allows processing to be applied based on information present, for example, in the packet header. Thus, even if the useful data in the data packet is encrypted, the device transmitting the packet can still apply quality-of-service (QoS) related processing by counting some of the messages transmitted through the device based on the tagging parameters of the data packet that affect the messages to be processed.

[0034] According to one aspect of the processing method, the processing includes counting at least one piece of data related to the application based on the attribute being processed.

[0035] In an environment where data packets can be transmitted via applications that charge individual entities, modifying the tagging parameters of data packets that include application-related messages allows for charging specific entities for those packets. Thus, for example, tagged data packets might include messages to charge vehicle managers, and these packets are easily identifiable so that they can be counted by intermediate devices.

[0036] According to one aspect of the method of the invention, the processing method further includes receiving and applying processing related to a second message concerning a first application based on attributes included in a second information data packet having applied tags, the second information data packet being received from a data server and sent to a terminal.

[0037] This processing method can be advantageously implemented for data packets transmitted between terminal units and data servers. For example, in cases where data packets are counted for billing purposes or for specific processing of data packets, it may be necessary to apply processing to bidirectional data packet streams transmitted from terminal units to servers or from data servers to terminal units.

[0038] The various aspects of the processing methods described above can be implemented independently of each other or in combination with each other.

[0039] The present invention also relates to an apparatus for identifying a first message related to a first application from a set of messages associated with multiple applications, the set of messages being transmitted by a terminal unit to a data server by means of a routing device capable of applying processing to attributes associated with the first message, the apparatus comprising:

[0040] - A tagging module that can:

[0041] - Add attributes related to the first message to the information data packet, which incorporates the processed attributes;

[0042] - Apply tags to information data packets that include added attributes;

[0043] - A transmitter that can transmit data packets containing applied tags to the data server.

[0044] Such a device, capable of implementing all embodiments of the above-described identification method, is intended for implementation in devices such as those used for accessing a local area network (e.g., home gateways, terminal or router-type devices) within a communication network.

[0045] The present invention also relates to an apparatus for processing attributes related to a first message concerning a first application, the first message being transmitted from a terminal unit to a data server, the data server being capable of applying processing to the attributes related to the first message, the apparatus comprising:

[0046] - A detector that can detect information data packets including attributes added by the terminal unit based on the tags applied to the received information data packets;

[0047] - Processing module, which is capable of processing attributes included in the received information data packet.

[0048] Such an apparatus capable of implementing all embodiments of the above processing methods is intended for implementation in devices such as routers, firewalls, flow inspection devices (deep packet inspection), or even data servers in communication networks. The invention also relates to a system for processing attributes related to a first message concerning a first application transmitted from a terminal unit to a data server, the system comprising at least one identification device and at least one processing device.

[0049] The present invention also relates to a computer program including instructions for implementing the steps of the corresponding identification and processing methods described above when these programs are executed by a processor and a recording medium, the recording medium being readable by an identification device and a processing device that have recorded the computer program.

[0050] The present invention further improves this situation by means of a method for capturing data packets from an encrypted session established between a terminal unit and a data server, the data packets including data for determining a security key for encrypting the data packets, the method being implemented by a device routing data packets between the terminal unit and the data server and comprising:

[0051] - Analyze multiple data packets transmitted by the terminal unit and sent to the server;

[0052] - Identify cooperative data packets from multiple analyzed data packets, the cooperative data packets including deterministic data corresponding to a security key used to encrypt data packets transmitted from the terminal unit to the data server before the terminal unit sends the cooperative data packets;

[0053] - Use a security key corresponding to the identified data in the cooperative data packet to decrypt the received cooperative data packet.

[0054] When the connection between a terminal unit and a data server is secure, particularly encrypted, the device used to route the data cannot access the content of the data packets exchanged between the unit and the server. One option to remedy this is to provide the device with the security key used by both the terminal unit and the data server. However, this provision can lead to security failures in data exchange and requires the systematic transmission of keys to the device, which represents a security concern. In some cases, however, the device must be able to apply specific processing to certain data packets, involving specific billing for certain applications or the transmission of certain data to regulatory agencies. Therefore, this method allows the terminal unit to insert cooperative data packets into all data packets routed by the device, indicating, by means of definite data present in the data packet (e.g., one or more bits typically set to a device-recognizable value in the packet header), that the data packet is a cooperative data packet to be decrypted using a key determined by the definite data with the specific value. Thus, this method advantageously allows cooperation between the terminal unit and the device routing the data, enabling the device to apply processing to cooperative data transmitted by the terminal unit. Furthermore, this method allows security keys no longer used for data transmission between the terminal unit and the data server to be reused for cooperation between the terminal unit and the device. The device can be a router, firewall, or any other device that provides session data processing. Specifically, the data server can perform the actions described for this device. In this case, the data server receives cooperative data packets and processes them using a security key corresponding to the identified data. Encryption and decryption include all data protection modes that can be used to guarantee the confidentiality of the exchanged data packets, particularly quantum or homography protection techniques.

[0055] According to one aspect of this capture method, the data is determined to be a binary phase element indicating a key change used by the terminal and the data server to encrypt and decrypt data packets exchanged between the terminal unit and the data server.

[0056] As is well known, phase fixing is used, for example, in protocols, to allow one end of a session to notify the other end of changes in the security key for the data to be exchanged. If such a bit is set to 0, and one end (such as a terminal unit) changes it to 1 for data transmitted to the data server from that moment on, the data server will use the key corresponding to the 1 bit corresponding to the phase change to decrypt the received data. In this case, according to the binary phase element, the key corresponding to bit 0 is no longer used for encrypting and decrypting data exchanged between the terminal unit and the data server, but can be used to encrypt cooperative data packets transmitted from the terminal unit to the device.

[0057] According to one aspect of this capture method, cooperative packets are packets of secure data multiplexing protocols such as QUIC, and cooperative packets are identified based on one or more of the following parameters:

[0058] - Fixed phase;

[0059] - The value of the spin bit in the QUIC data packet;

[0060] - The value of the RR bit in the QUIC data packet;

[0061] - Connection identifier.

[0062] The terminal unit can transmit various information to the device, possibly encrypting it using a security key associated with the value of a binary deterministic element. For example, it is advantageous to use a connection identifier previously negotiated between the terminal unit and the device when exchanging encryption / decryption keys or by exchanging specific messages. This effectively allows both devices (i.e., the terminal unit and the device) to know the information. The use of spin bits and / or RR bits in QUIC packets can replace, or even supplement, the connection identifier used to enrich the signaling transmitted to the device and explicitly inform the device that it is a cooperative packet requiring its processing.

[0063] According to one aspect of the capture method, the cooperative data packets are identified after the detection of these data packets is activated in the device, and the values ​​of the determined data of these data packets are different from the values ​​of the determined data of a plurality of consecutive data packets previously received from the terminal unit.

[0064] The device can continuously activate the detection of cooperative data packets, or it can even activate this detection based on a specific event, thereby reducing the resource requirements for activating and processing the data packet after detecting a binary data packet with a value set to 0. Activation can be performed after the device receives an activation message transmitted by the terminal unit, notifying the device that cooperative data packets will be received in the next few seconds. Activation can also be performed when the device continuously receives several data packets with a defined data value set to a certain value (e.g., 1), notifying the device that the encryption key corresponding to the 0 value is no longer used to encrypt data transmitted to the data server, but can be used to send cooperative data packets, thus allowing the discarded decryption key to be reused to encrypt data arriving at the data server. Therefore, for example, after receiving multiple consecutive data packets with a defined data value set to 1, receiving a data packet with a value set to 0 can notify the device that this data packet is a cooperative data packet.

[0065] According to one aspect of this capture method, after the session between the terminal unit and the data server ends, the terminal unit transmits the security key associated with the determined data to the device.

[0066] According to this embodiment, after the terminal unit sends the cooperative data packet and after the session between the terminal unit and the data server ends, a security key, for example, corresponding to a binary deterministic element, is transmitted. This ensures that the security key cannot be used for other purposes, such as decrypting the transmitted data packet while the session is still being established. After the session is closed, the device saves the cooperative data packet using the encryption key transmitted by the terminal unit and decrypts it using the key transmitted after the session ends.

[0067] According to one aspect of this capture method, the security key associated with the identified data is used to protect the exchange of data packets in previous sessions between the terminal unit and the data server.

[0068] Protocols such as QUIC or TLS require that the encryption key used to encrypt data exchanged in a session be changed at specific times. Therefore, the terminal unit and the data server obtain, for example, the encryption key for the new exchange based on the key previously used for exchange in a previous session. Thus, the key used for exchange in a previous session is no longer used to obtain the key for subsequent data exchange and can be advantageously used to encrypt and send cooperative data packets transmitted from the terminal unit to the device.

[0069] According to one aspect of this capture method, the security key associated with the determined data is a key negotiated between the terminal unit and the data server during the session initialization step.

[0070] During the session establishment phase, such as the handshake phase, a security key, also known as "secret cooperation," can be negotiated between the terminal unit and the data server. This is especially true if there is no prior session between the terminal unit and the data server. This security key (which can be secret cooperation) can be advantageously used to encrypt and decrypt cooperation data packets.

[0071] According to one aspect of this capture method, when multiple packets are routed to a data server, cooperative packets are removed from those multiple packets.

[0072] In one embodiment, during a session with a data server, cooperative data packets are removed from multiple data packets sent by the terminal unit. This is particularly relevant when the session between the terminal unit and the data server is one-way, as cooperative data packets intended for the device are of no interest to the data server. Removing cooperative data packets also prevents data server malfunctions where the server is not intended to receive data packets containing binary deterministic elements corresponding to an encryption key that is no longer typically used to encrypt data packets between the terminal unit and the data server.

[0073] According to one aspect of the method of the present invention, the capture method further includes analyzing and identifying cooperative data packets from data packets transmitted from a data server to a terminal unit and decrypting the cooperative data packets as described above.

[0074] Specifically, in the case of a two-way session between the terminal unit and the data server, the device can apply processing, such as counting operations, to data packets received from both the terminal unit and the data server. In this case, the implemented method will be the same as that applied to data packets received from the terminal unit, and the device can also avoid removing cooperative data packets from the data packets transmitted to the data server, allowing the server to consider the presence of cooperative data packets and set itself as a binary element of the cooperative data packets transmitted to the device.

[0075] The various aspects of the capture methods described above can be implemented independently of each other or in combination with each other.

[0076] The present invention also relates to a method for counting application-related data transmitted from a terminal unit to a data server via a device using an encrypted session between a terminal unit and a server, the method being implemented by the terminal unit and comprising:

[0077] - Transmit multiple data packets, each data packet including data used to determine a security key for encrypting that data packet;

[0078] - Increment a counter for data related to the application (e.g., data transferred to a data server);

[0079] - Before sending the cooperative data packet, an incrementing counter is added to the cooperative data packet, which includes determined data corresponding to a security key used to encrypt data packets in multiple data packets exchanged between the terminal unit and the data server;

[0080] - Send a cooperative data packet containing the added counter to the data server.

[0081] For a given application, the counting method implemented by the terminal unit allows the device to have information about the amount of data exchanged in a one-way or two-way link between the terminal unit and the data server. Therefore, this method allows the solution to the problem of the device accessing encrypted data packets. Thus, this method allows the user to securely transmit counting information to the device via a counter that increments for each data packet associated with a given application (possibly by reusing the security key of a data packet previously used for a session). Therefore, the device can then apply processing such as billing to the entity responsible for paying for the data packets transmitted and possibly received by the terminal unit for the corresponding application.

[0082] According to one aspect of the invention, the counting method further includes sending a security key to the device corresponding to determined data of the cooperative data packet.

[0083] Since the device does not know the security key corresponding to the binary element in most cases, the terminal unit can transmit the key once the session between the terminal unit and the data server ends, for example, so that the device can effectively access the contents of the cooperative data packet.

[0084] According to one aspect of the invention, the counting method further includes the device previously sending an activation message for activating the capture method to a data server.

[0085] Specifically, when the session between the terminal unit and the data server is a two-way session, the terminal unit may need to transmit a message to the data server to activate the capture method, thereby notifying the data server that it may have received a data packet containing binary elements corresponding to a security key that is no longer in use. This activation message may also notify the data server to activate a counting method corresponding to the marking method implemented by the terminal unit for data packets sent to the terminal unit.

[0086] The various aspects of the counting methods described above can be implemented independently of each other or in combination with each other.

[0087] The present invention also relates to an apparatus for capturing data packets from an encrypted session established between a terminal unit and a data server, the data packets including data for determining a security key for encrypting the data packets, the apparatus comprising:

[0088] - Analyzer, which is capable of analyzing multiple data packets transmitted by the terminal unit and sent to the server;

[0089] - An identification module that can identify cooperative data packets among multiple analyzed data packets, the cooperative data packets including deterministic data corresponding to a security key used to encrypt data packets transmitted from the terminal unit to the data server before the terminal unit sends the cooperative data packets;

[0090] - A decryption module that can decrypt received cooperative data packets using a security key corresponding to the specific data in the identified cooperative data packets.

[0091] Such a device, capable of implementing all embodiments of the above-described capture method, is intended for implementation in devices such as routers, firewalls, flow inspection devices (deep packet inspection), or even data servers in communication networks.

[0092] The present invention also relates to an apparatus for counting application-related data transmitted from a terminal unit to a data server via a device using an encrypted session between a terminal unit and a server, the apparatus comprising:

[0093] - A transmitter capable of transmitting multiple data packets, each including data for determining a security key used to encrypt the data packet;

[0094] - A computer capable of incrementing a counter for application-related data and adding the incrementing counter to a cooperative data packet containing determined data corresponding to a security key before sending the cooperative data packet, the security key being used to encrypt data packets in multiple data packets exchanged between the terminal unit and the data server;

[0095] - A transmitter that can transmit cooperative data packets, including the added counters, to the data server.

[0096] Such a device, capable of implementing all embodiments of the above counting method, is intended for implementation in devices such as those used for accessing a local area network (e.g., home gateways, terminal or router-type devices) in communication networks.

[0097] The present invention also relates to a system for counting application-related data transmitted from a terminal unit to a data server via a device using an encrypted session between a terminal unit and a server, the system comprising at least one capturing device and at least one counting device.

[0098] The present invention also relates to a computer program including instructions for implementing the steps of the corresponding capture and counting methods described above when these programs are executed by a processor and a recording medium, the recording medium being readable by a capture device and a counting device that have recorded the computer program.

[0099] The aforementioned program can be written in any programming language and can take the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form or in any other desirable form.

[0100] The aforementioned information medium can be any entity or device capable of storing programs. For example, the medium can include storage devices such as ROMs (e.g., CD-ROMs or microelectronic circuit ROMs), or even magnetic recording devices.

[0101] Such storage devices can be, for example, hard disks, flash memory, etc. Furthermore, the information medium can be a transmissible medium, such as electrical or optical signals, which can be routed via cables or optical fibers, radio waves, or other means. The program according to the invention can be downloaded, in particular, over an internet-type network.

[0102] Alternatively, the information medium may be an integrated circuit incorporating a program, the circuit being adapted to execute or be used to execute the relevant method. Attached Figure Description

[0103] Other features and advantages of the invention will become more apparent after reading the following description of specific embodiments, provided by way of simple illustrative and non-limiting examples, and the accompanying drawings, in which:

[0104] [ Figure 1 This illustrates an embodiment of the identification method according to the first aspect of the present invention;

[0105] [ Figure 2 This illustrates an embodiment of a method for capturing data packets according to an embodiment of the present invention;

[0106] [ Figure 3 This illustrates an embodiment of the identification method according to an embodiment of the present invention;

[0107] [ Figure 4 This illustrates an embodiment of the identification method according to another embodiment of the present invention;

[0108] [ Figure 5 This illustrates an embodiment of a counting method according to an embodiment of the present invention;

[0109] [ Figure 6[This illustrates an embodiment of the counting method according to another embodiment of the present invention;]

[0110] [ Figure 7 The image shows a discrimination device according to an embodiment of the present invention;

[0111] [ Figure 8 A processing apparatus according to an embodiment of the present invention is shown;

[0112] [ Figure 9 A capture device according to an embodiment of the present invention is shown;

[0113] [ Figure 10 The image shows a counting device according to an embodiment of the present invention. Detailed Implementation

[0114] Throughout the remainder of the specification, embodiments of the invention are presented in the context of a communication infrastructure. This infrastructure can be implemented to route communication data to fixed or mobile terminals, and, depending on the specific device or virtualization functionality deployed, can be used to route and process data from residential or enterprise customers.

[0115] [ Figure 1[The following describes an embodiment of the identification method according to a first aspect of the invention, which will be mentioned in the first example. According to this first aspect, terminal unit 30 transmits several messages F1, F2, F3 to data server 20. These messages F1, F2, F3 are routed in network 100, which specifically includes access device 40 and device 50 for routing messages exchanged between terminal unit 30 and data server 20. Messages F1, F2, F3 transmitted by terminal unit 20 may be transmitted by terminal unit 30 or even by another terminal (such as terminal 60), and are routed from terminal unit 30 to data server 20 via access device 40, which connects terminal unit 30 to network 100 and device 50. According to this aspect, terminal unit 30 is a TCU-type unit in vehicle 10 that transmits messages F1 and F2, and terminal 60 is, for example, a smartphone for a vehicle passenger that transmits message F3. Various messages F1, F2, F3 may require specific processing by device 50, and therefore it may be possible to identify various messages.] For example, when it is known that the transmission of messages F1, F2, and F3 can charge different entities, it is necessary to be able to effectively record the number of messages F1 and / or F2 and / or F3. However, according to existing technology, device 50 may have difficulty accessing the content of messages F1, F2, and F3 because these messages may be specifically encrypted. Accordingly, when it is known that message F3 requires charging passengers of vehicle 10, message F3 related to the application used by the passenger is integrated into an information data packet and transmitted to the data server by TCU 30. To enable device 50 to easily identify the information data packet, the terminal unit applies a marker, for example, by modifying the information elements of the unencrypted header of the data packet, so that device 40 can easily identify and process the data packet among the various messages F1, F2, and F3 that it must route. The added message F3 may correspond to data from the application, or even data specific to the processing of device 50. For example, message F3 may correspond to the amount of data exchanged between terminal 60 and data server 20. Therefore, terminal unit 30, which can effectively intervene in messages transmitted on its own behalf or on behalf of terminals such as terminal 60, cooperates with the device by transmitting information data packets that can be processed by device 50. Access device 40 can also act as device 50, and terminal unit 30 can also be a residential gateway (also called a box) or even a smartphone-type unit. Information data packets including message F3 can also be encrypted using an encryption key, and then device 50 can decrypt the information data packets received from terminal unit 30 using a decryption key corresponding to the encryption key used for encryption. It should be noted that if messages related to different applications need to be processed by device 50, terminal unit 30 can include messages related to both applications in the information data packets by, for example, using tags applied to the data packets to distinguish between the various messages. Therefore, the tags can include application-specific tags.For example, if message F4([). Figure 1 If a message (not shown in the image) is transmitted from terminal 60 to data server 20, the terminal unit can insert messages F3 and F4 into the information data packet, and device 50 can process the information data packet according to the tags applied by user unit 30.

[0116] refer to[ Figure 2 This illustrates an embodiment of a method for capturing data packets according to an embodiment of the present invention. Figure 2 Entities 10, 20, 30, 40, and 50 shown in the diagram are related to […]. Figure 1 Entities 10, 20, 30, 40, and 50 shown in the diagram are identical. [ Figure 2 The image shows three applications, App1, App2, and App3. These applications, App1, App2, and App3, can be used in terminal unit 30 or a terminal (such as […]). Figure 1The device 50 is used or activated on the terminal 60 shown. Like the access device 40, the device 50 routes data packets related to applications App1, App2, and App3 transmitted by the terminal unit 30 to the data server 20, and routes data packets transmitted by the data server 20 to the terminal unit 30. An encrypted session is established between the terminal unit 30 and the data server 20 to route the data packets. One or more encrypted sessions can be implemented, for example, one for each application App1, App2, and App3, or one session for all applications App1, App2, and App3. The data packets exchanged between the terminal unit 30 and the data server 20 include data used to determine a security key for encrypting the data packets. For example, this data may involve one or more bits, allowing the terminal unit 30 and the data server 20 to agree on a security key for encrypting and decrypting data, and to indicate the key or key changes using information provided by the determining data (e.g., present in the unencrypted header of the data packet). The device 50, which routes the various data packets exchanged between the terminal unit 30 and the data server 20, analyzes these data packets, and more specifically analyzes the data used to determine the key for the data packets. A series of data packets associated with application App1 are encrypted using an encryption key (e.g., a private key), and the value of the deterministic data corresponding to this key is assumed to be v1. Device 50 analyzes this data and checks that the data values ​​have not changed before transmitting these data packets to a data server. Then, the device receives data packets with deterministic data having an assumed value of v0, which has already been used to exchange data packets from previous connections in the session or to send data packets from previous protected phases for the same connection. This deterministic data value v0 is no longer used for data packet exchange between terminal unit 30 and the data server because all data packets include the value v1 as deterministic data. Device 50 determines that the data packet is a cooperative data packet containing data intended for use by the device and decrypts the contents of the data packet using a decryption key corresponding to the value v0, which is no longer used for data exchange between terminal unit 30 and data server 20. Therefore, the encryption key previously used for exchanging data packets between terminal unit 30 and data server 20 can be reused to transmit information to device 50 in data packets encrypted with the reused key. This does not change the end-to-end security between terminal unit 30 and data server 20, because the key used to encrypt cooperative data packets transmitted from terminal unit 30 (or data server 20) to device 50 is no longer used to encrypt data packets exchanged between terminal unit 30 and data server 20. The security key associated with a specific data value of v0 can be used by device 50 before or after sending cooperative data packets, and device 50 is able to store cooperative data packets so that they can be decrypted once the key is received.Therefore, the user equipment can implement a counting method to inform device 50 about the number of data packets or the amount of data, or about the session duration in cooperative data packets including a counter that increments for each transmitted data packet, the counter corresponding to the number of transmitted data packets, the amount of data incremented for each transmitted data packet, or the duration for which it increments whenever a new data packet is transmitted. Therefore, device 50 can utilize the counter information included in cooperative data packets decrypted using a key corresponding to the data used to determine the cooperative data packets.

[0117] Now refer to [ Figure 3 This illustrates an embodiment of the identification method according to one embodiment of the present invention. Entities 10, 20, 30, 40, 50, 60, and 100 are equivalent to those in [ Figure 1 ]and[ Figure 2 Entities with the same reference numerals are shown in the figures. Specifically, according to an alternative, terminal unit 30 is a device for accessing a local area network (such as a residential gateway) or a device for accessing a vehicle network (such as a TCU). During step 200, terminal unit 30 is attached to and connected to access device 40. Consider establishing a session between terminal unit 30 and data server 20. According to an alternative, the session can be established via a secure connection between terminal unit 30 and data server 20. During step 300, smartphone 60 transmits a message to terminal unit 30 related to application App1 (e.g., an online game) and intended for use with data server 20, and during step 301, the terminal unit transmits this message to data server 20. During step 302, terminal unit 30 transmits a message to data server 20 related to application App2, for example, for managing vehicle 10. These two messages require different processing by routing device 50; the message related to application App2 needs to be backed up by device 50, especially in the case of insurance auditing. Access devices 40 and 50 route various messages transmitted during steps 301 and 302 to data server 20. Terminal unit 30 maintains a list of applications to which specific actions are to be taken. For example, for application App2, it must send messages related to that application to device 50. According to another example, terminal unit 30 identifies messages based on the terminal transmitting these messages or even based on information in the messages themselves (e.g., information related to quality of service). According to this example, the terminal unit must copy attributes related to the message into the data packet sent to device 50.

[0118] According to one example, during optional step 303, terminal unit 30 selects messages from the set of messages to be transmitted to data server 20 according to criteria. For example, the terminal unit may compare the relevant application with the transmitted messages. According to the example, retaining messages related to application App2 may result in specific processing by device 50. According to another example, terminal unit 30 may transmit to device 50 attributes related to messages sent by a terminal, particularly, for example, from terminal 60. According to yet another example, terminal unit 30 may transmit attributes related to messages including specific routing, protocols, or even quality of service or security information. Thus, all messages requiring a specific routing quality will be able to provide attributes related to the time terminal unit 30 sent the message, allowing device 50 to check whether the relevant message has been correctly routed according to the quality of service criteria indicated in the message, or even whether its temporal distribution corresponds to the expected application type (using shallow packet inspection techniques).

[0119] During step 304, according to one example, terminal unit 30 adds a message to an information packet. Several different message attributes can be combined in the information packet to limit the number of information packets transmitted. Alternatively, the attributes associated with the added message may correspond to a portion of the transmitted message, or even to one or more pieces of information related to application App2, such as: the number of messages, the duration of the session between terminal unit 30 and data server 20 for application App2, and the identifier of the terminal that transmitted the message related to application App2.

[0120] According to an alternative, the information packet may include attributes of messages specific to a single application, for example, regardless of whether the information packet only includes attributes related to application App2. However, in cases where the same processing needs to be applied to messages from different applications, it may be advantageous to combine attributes related to different applications but requiring the same processing by the device into the same information packet. For example, if the processing involves counting packets sent and related to two applications, App4 and App5, that are charged to the same entity, attributes (such as message counters related to applications App4 and App5) can be transmitted in a single information packet. The terminal unit 30 then applies a mark to the information packet during step 305, for example, by setting certain binary elements of the information packet to defined values. According to one example, the information packet may be a packet of a secure stream multiplexing protocol. This type of protocol offers the possibility of integrating security and multiplexing several streams, which is particularly attractive. In practice, if the terminal unit 30 wishes to transmit several information packets (each packet incorporating attributes of messages requiring specific processing), then the information packets can be securely transmitted by multiplexing different information packets within a single connection between the terminal unit 30 and the device 50. As an example, the secure flow multiplexing protocol can be QUIC, or even HTTP / 2 or HTTP / 3. In particular, QUIC has the advantage of including spin bits and reserved bits that can be used to apply marking to information packets. Binary elements of other secure flow multiplexing protocols (such as the spin bits or reserved bits of QUIC) can be used interchangeably to apply marking to information packets.

[0121] During step 306, terminal unit 30 sends an information data packet including one or more attributes of a message related to application App2. In this embodiment, the information data packet is considered to include messages transmitted by terminal unit 30 over a duration of 300 seconds. The information data packet, transmitted using the QUIC protocol, further includes a spin bit and a reserved bit set to 1. A tagging information that allows the received information data packet to be distinguished from other data packets informs device 50 that it is an information data packet and that processing needs to be applied to the information data packet using the attributes of the messages present in the information data packet received during step 306. During step 307, device 50 transmits a message to backup entity 70, which includes the attributes of the messages received during step 307 and thus allows logging of messages related to application App2 transmitted by terminal unit 30. Alternatively, during step 309, the information data packet is transmitted to data server 20. This is especially true when the processing performed by device 50 involves copying the received information data packet so that the order of data packets received by data server 20 is not distorted or incorrect due to the removal of data packets from the session between terminal unit 30 and data server 20. According to an alternative approach, the processing could involve counting the number of messages transmitted for the application. Therefore, if billing is to be differentiated for each user (the owner of vehicle 10, the owner of terminal 60, the administrator of user unit 30), it is necessary to count the amount of messages or data generated by the application and to pass the associated fees to the users or administrators using or managing the application. In this case, the attribute could be the number of messages or the amount of data in the messages sent.

[0122] According to another example, device 50 can also process messages related to application App2 transmitted from data server 20 to terminal unit 30. According to this example, during step 310, data server 20 sends messages related to application App2 to terminal unit 30. Steps 311 to 317 are equivalent to steps 303 to 309 described above, except that data server 20 performs the operations of terminal unit 30, and conversely, terminal unit 30 performs the operations performed by data server 20.

[0123] It should be noted that, in addition to or not except for the operations performed by device 50, access device 40 may also perform some or all of the operations performed by device 50.

[0124] refer to[ Figure 4 The diagram illustrates an embodiment of the identification method according to another embodiment of the present invention.

[0125] The identification method and corresponding processing method activate the QUIC extension QFLOW_A, which forces the exchange of QUIC packets in "flow management mode" so that only QUIC packets are counted as traffic to be charged to the owner of the SIM card in the vehicle's TCU module (terminal unit): the QUIC messages to be counted are merged into the marked QUIC packets. The extended QFLOW_A modifies the use of the spin bit field to mark the QUIC packets to be counted by the device.

[0126] In addition, according to the alternative, on the server, activating the extended QFLOW_A creates a flow table in the server, which is used to implement the "flow management" method for packets sent by the server.

[0127] Vehicle manufacturers typically develop OEM (Original Equipment Manufacturer) methods in dashboard tablets that allow the OS (Operating System), web browser, or application to merge streams of QUIC messages to be counted into tagged QUIC packets. This enables devices, such as those managed by mobile operators, to recognize these messages and count them when processing involves counting messages related to the flow. The QFLOW_A method is described in the "Flow Management" mode: the criterion used to merge messages in tagged packets is the identifier of the application that generated the messages in the tagged packets. Other merging modes are also common: for example, another criterion for merging messages could involve merging QUIC control messages to count "useful" data messages (i.e., excluding, for example, DNS control data) and be able to charge end users only for these data messages. Other processing could involve monitoring signaling for security purposes or faster routing of control messages in devices such as agents. A typical use of the method involves storing signaling for subsequent inspection of messages stored and transmitted in QUIC packets.

[0128] This method is applicable to modes where there are no visible markers on the outside of the data packets. A typical use of this mode is to speed up signaling in "reverse proxy" type devices, where signaling is routed to DPI type inspection functions (ranging, problem analysis, security, etc.).

[0129] The identification method can include various patterns that can be combined, for example:

[0130] ●QFLOW_A mode: Only messages sent by the client TCU (Terminal Unit) are added to the marked QUIC packets, and therefore only the sent data is counted as traffic charged by the manufacturer;

[0131] ●QFLOW_B mode: The QUIC extension indicates in the transmission parameter known as the "spin bit" that packets must be counted. Counting only the amount paid for by the manufacturer is sufficient (no need to charge the car owner);

[0132] ●QFLOW_C: The QUIC extension in the transport parameters indicates that the spin bit and the two RR bits of the QUIC protocol are used to describe the application identifier. Therefore, the 3 bits allow differentiation of 8 different applications (e.g., waze, gmap, etc.) or another combined standard (terminal identifier, QoS standard, etc.).

[0133] [ Figure 5 The steps of the method in this embodiment proposed in the document are as follows:

[0134] ●Step A: Create a QUIC connection between the TCU module (terminal unit) and the server (data server) without explicitly activating the QFLOW_A extension: the server infers from this that the spin bits of the QUIC protocol are used for QFLOW_A mode;

[0135] ●Steps B0 (and E0): The TCU module receives messages from the terminal's application App Serv 3. The TCU module knows (e.g., through the list of applications to be charged) that these messages need to be counted. Therefore, the TCU module receives the data to be counted by the device. It creates a QUIC packet that combines the data to be counted by the device. In cases where the QUIC packet includes data from several different applications, it can construct this data for each application;

[0136] ●Step B: The TCU module (and more specifically, its QUIC stack) receives data (messages) to be counted and added to the QUIC stream management packets (streams). The QUIC stack may include the received messages or only a portion of the messages, such as source and destination addresses, protocol type;

[0137] ●Step C0: The TCU module receives application App Serv 4-related messages that do not require counting by the device. It creates untagged QUIC messages (QUIC standard) and routes these messages to the server, which is the recipient of this data.

[0138] ● Step C (and Step E): The QUIC stack receives data (or messages) and processes it to include it in the QUIC packet created during step C0. It then sends the "untagged" QUIC packet to the server.

[0139] ●Step D: The server receives "untagged" QUIC packets, i.e., packets with their spin bit value set to 0. It should be noted that the device does not process these "untagged" packets;

[0140] ● Step E: Another terminal sends messages related to the application App Serv 3. These messages are counted as indicated in step BO. When the marked QUIC packet contains a sufficient number of messages and / or after a certain delay following the creation of the stream packet, the TCI module transmits the QUIC stream packet to the server;

[0141] ●Step Ebis: The device uses a spin bit marked as 1 to identify QUIC stream packets and apply processing. In the current case, the device counts the packets and adds the amount of data corresponding to application App Serv 3 by means of information transmitted in the stream packets (i.e., attributes related to application AppServ 3);

[0142] ●Step F: The server's QUIC stack receives QUIC stream data packets and processes the messages in the data packets;

[0143] ●Step G: The device routes the QUIC packets sent by the server to the terminal attached to the TCU module, or specifically to the TCU module, but does not apply any processing, as this is QFLOW_A mode. In QFLOW_B mode, the QUIC packets sent by the server are processed according to the processing applied to packets sent by the TCU module.

[0144] In QFLOW_B mode, step B above is modified so that the TCU module notifies the server to activate QFLOW_B mode, thereby instructing the use of spin bits to identify the transmission of messages to be counted in QUIC packets. Furthermore, steps F and G above are modified as follows:

[0145] ●Step F: When the server receives a QUIC packet with its spin bit set to 1, the server extracts the QUIC message from the packet (in this embodiment, the message itself is a QUIC packet) and stores the list of identifiers associated with the message in the flow table. Next, it processes each frame:

[0146] ○ Backup identifier;

[0147] ○ Process each QUIC stream packet;

[0148] ○ Responds to each QUIC stream packet;

[0149] ○ Add a response message (or an attribute associated with the response message) to the message received in the QUIC stream packet;

[0150] ●Step G: Send a QUIC stream data packet to the TCU module (by indicating the address of the terminal that generated the App Serv 3 message);

[0151] ●Step Gbis: The device identifies the QUIC stream data packets received from the server and applies message counting processing based on the messages or attributes present in the QUIC messages.

[0152] The QFLOW_C mode differs from the two modes mentioned above in its different identification of streaming data packets. Application processing can be differentiated based on the identification of the received streaming data packets. For example, processing can be based on the application, the entity responsible for paying for the message, the terminal transmitting the message, or even a combination of these criteria.

[0153] In one example, in this QFLOW_C mode, counting is performed based on the entity responsible for paying for the message. Message attributes are incorporated into a QUIC packet used to charge a specific entity.

[0154] - Use 3 spin bits and RR bits to distinguish several counting modes.

[0155] - These bits correspond to the message's billing entity:

[0156] {[Name: com.car.android.app, Payer: Company A, ID: 010];

[0157] [Name: com.netflix.android, app, payer: Company B, ID: 011];

[0158] [Name: com.poki.android.app, Payer: User C, ID: 110];

[0159] [Name: com.sponsordata.android.app, Payer: Administrator TCU, ID: 101].

[0160] In another example, the counting is managed by application category. In this example, the three spin bits and RR bits of the QUIC header indicate the category of the packet, i.e., a set of applications for which the message is to be merged and marked for subsequent processing by the device. An example is presented below:

[0161] {[Name: com.car.android.app, id: 100];

[0162] [Name: com.netflix.android.app, id: 101];

[0163] [Name: com.poki.android.app, ID: 110];

[0164] [Name: com.sponsordata.android.app, id: 111].

[0165] refer to[ Figure 5 This illustrates an embodiment of a method for counting data packets according to an embodiment of the present invention.

[0166] Entities 10, 20, 30, 40, 50, 60, and 100 are equivalent to [in [ Figure 1 ]、[ Figure 2 ]and[ Figure 3 Entities with the same reference numerals in the figure.

[0167] During step 400, terminal unit 30 is attached to and connected to access device 40. Consider establishing an encrypted session between terminal unit 30 and data server 20. This means that data packets exchanged between terminal unit 30 and data server 20 are encrypted using an encryption key (e.g., a private encryption key), and the data server decrypts the received data packets using a decryption key (e.g., a public key) corresponding to the encryption key. Accordingly, data packets transmitted from data server 20 to terminal unit 30 are encrypted and then decrypted. During step 401, terminal 60 transmits data packets related to application App4 to terminal unit 30, causing terminal unit 60 to transmit these data packets to data server 20, with which it has established a session, in step 402. According to one example, application App4 is a web access application. As indicated above, the data packets transmitted during step 402 are encrypted using a security key. The transmitted data packets further include determination data that informs data server 20 of the actual security key used to encrypt the data packets. According to one example, the determined data corresponds to the value of one or more binary elements in the packet header (e.g., binary phase elements defined in TLS and QUIC protocols used to notify the data server of key changes), where the new key is calculated based on an algorithm and the key previously used to exchange packets. Therefore, packets are exchanged consecutively using different keys, with key changes indicated by phase transitions. Thus, the determined data may correspond to phase transition bits or even phase transition bits and additional bits to enhance the information related to the key used by the terminal unit to send packets to the data server 20. During step 403, the terminal unit 30 sends packets related to application App6 to the data server 20. According to one example, application App6 is a security application that allows the location of vehicle 10 to be determined when the vehicle is moving and allows emergency services to be organized in the event of problems such as vehicle malfunction or accidents.

[0168] Throughout the remainder of the embodiment, it is assumed that the counting of data packets associated with application App5 (i.e., video streaming) must be performed by terminal unit 30 in such a way that data related to the video streaming service used by terminal 60 is actually charged to the user of the service, rather than to, for example, the owner of vehicle 10. This activation can be static, i.e., terminal unit 30 maintains a list of applications for which counting must be performed. This activation can also be dynamic, for example, after receiving a request from the platform to manage applications or data transmitted by terminal unit 30.

[0169] According to an alternative, during step 404, the terminal unit transmits a message to device 50 to activate a method for capturing data packets, which allows the device to be configured to listen in order to identify cooperative data packets transmitted by terminal unit 30, enabling the counting of data packets. During step 404, according to one example, the terminal unit may also indicate the connection identifier used that will be added to the cooperative data packets and that the device can actually identify. Therefore, cooperative data packets will be able to be identified from all data packets routed by device 50. It should be noted that if, for example, no activation message is transmitted, this connection identifier may be specifically transmitted to device 50. According to another alternative, the activation message may also include a decryption key that device 50 will use to potentially decrypt cooperative data packets based on the connection identifier included in the message. The activation message itself can be encrypted using a key that is initially available to device 50 in the message, which is not […]. Figure 5 As shown in the image.

[0170] According to another alternative, during step 405, the terminal unit transmits a message to the data server 20 to activate the capture method implemented by the device 50. This message aims, on the one hand, to inform the data server 20 that the key initially used to encrypt data packets between the terminal unit 30 and the data server 20 can be used to encrypt cooperative data packets for other purposes. Another purpose of this activation message is to inform the data server 20 to implement a counting method in a manner that counts the data packets exchanged in the bidirectional session between the terminal unit 30 and the data server 20, so as to, for example, charge the owner of the terminal 60.

[0171] During step 406, terminal 60 sends a request to data server 20 to access video streaming services via terminal unit 20, which connects terminal 60 to network 100.

[0172] During step 407, terminal unit 30 initializes a counter for data packets received from terminal 60 and related to application App5. The terminal unit increments the counter based on the number of data packets received from terminal 60. It should be noted that the counter may include the number of data packets or even the amount of data corresponding to the received data packets. According to one example, the counter uses megabits as the unit of measurement. According to one example, terminal unit 30 initializes a counter for each terminal and increments the counter for data packets sent by the corresponding terminal, or even uses the counter for application App5 independently of the terminal sending the data packets. According to another example, for a set of applications, the counter increments based on the data packets received from the terminals. Therefore, all data packets received from terminal 60 can be counted. According to this example, terminal unit 30 counts data packets related to applications App4 and App5.

[0173] During steps 408 and 409, terminal 60 sends a new data packet related to application App5, and terminal unit 30 increments the counter initialized during step 407.

[0174] During step 410, terminal unit 30 adds an incrementing counter to the cooperative data packet. This addition can be made after a period of time elapsed since the counter was initialized, once the counter reaches a certain amount of data or data packets, or even after a message is received from the management server. Terminal unit 30 also determines specific data to be added to the cooperative data packet. According to one example, this specific data corresponds to the encryption key previously used by terminal unit 30 to transmit data to data server 20. For example, the specific data could be specific data used to send data packets during steps 402 and / or 403, especially if this data is no longer used to send data packets during steps 406 and 409. According to an alternative, the cooperative data packet includes a connection identifier, as may be indicated in the activation message during step 405. According to another example, the connection identifier includes binary elements of the protocol, particularly binary elements of a Secure Data Multiplexing (SDM) protocol. According to one example, the connection identifier may include spin bits and reserved bits of the QUIC protocol, or equivalent bits of the HTTP2 or HTTP3 protocol. According to another alternative, the connection identifier may include data used to identify the data packet. According to this example, the device identifies cooperative data packets based on determined data, as indicated below.

[0175] During step 411, the terminal unit transmits a cooperative data packet to the data server 20 via device 50. The cooperative data packet includes data for determining an encryption key used to encrypt the cooperative data packet, as well as an incrementing counter and a possible connection identifier, which device 50 uses to identify the cooperative data packet among all received data packets.

[0176] If device 50 has already received the activation message during step 404, or even by default once it receives a data packet, the device performs analysis on the data packet received from terminal unit 30. This analysis may involve comparing the value of the connection identifier and / or the value of specific data in the received data packet.

[0177] During step 412, device 50 receives cooperative data packets and identifies them using a connection identifier (if present in the data packet) and / or data used to determine the encryption key used. In the latter case, receiving a data packet containing the determining data that is different from the data packets to be routed within a given time interval notifies device 50 that it is a cooperative data packet, knowing that previously received data packets no longer include the determining data. According to one example, when device 50 stops receiving data packets with the value v0 as determining data for a certain period and begins receiving data packets with the value v1, the device may initialize a timer, and if, after a certain delay following timer initialization, the device receives another data packet with the value v0 as determining data, this data packet is likely an information data packet. If this determining data corresponds to the encryption key recently used to exchange data packets between terminal unit 30 and data server 20, device 50 cannot decrypt the data packet, and the data packet will be incorrectly identified as a cooperative data packet because it does not have the key used to decrypt such a data packet. The data used to determine that the received information packet is different from the data received before and / or after the information packet was received can be used to detect the information packet. According to one example, the encryption / decryption key associated with the data used to determine the information packet can be used during a previous session between terminal unit 30 and the data server. According to another example, a session context can be maintained between terminal unit 30 (or a terminal connected to it) and data server 20, and when a new connection is established, the session context can be rebuilt, for example using cookies, and the key corresponding to the previous connection of the same session that maintained its context can be reused. According to yet another example, the encryption key associated with the determination data is used during the session initialization exchange (“handshake”) between terminal unit 30 and data server 20. If the identification is also based on or solely on a connection identifier, device 50 should then compare the value of the connection identifier with one or more values ​​of the identifier corresponding to the information packet.

[0178] According to the alternative, particularly in cases where device 50 has not previously received a key corresponding to the data used to identify the information data packet, during step 413, the terminal unit transmits a key for decrypting the received information data packet. This alternative helps avoid any errors and the decryption of data packets that are not information data packets but whose identifying data corresponds to the key actually used to encrypt / decrypt the data.

[0179] According to one example, during step 414, the device transmits a counter to billing unit 80, which converts the counter into billing information for the user to be transmitted to terminal 60. The counter may include information about application App5 and the terminal that has sent the data packet, or even timestamp information of the data packet related to application App5. Alternatively, during step 415, cooperative data packets are removed from all data packets to be sent to data server 20. Data server 20 does not need to receive the data packet if it knows that the information contained in the data packet is intended for processing by the device, and the data packet also contains deterministic data that is not normally used to decrypt data packets received from terminal unit 30.

[0180] According to one example, during step 416, the data server 20 implements the counting method implemented by the terminal unit 30 and is able to count data packets related to the application App5, initialize counters for these data packets, and add the counters to the information data packets transmitted to the terminal unit, such that the information data packets are sent to the device 50 after being identified by deterministic data, which may be different from the data used by the terminal unit 30 and / or different from the connection identifier, which may also be different from the connection identifier used for the information data packets transmitted by the terminal unit 30. In this respect, the exchange between the data server 20 and the device 50 can already be pre-generated according to step 404 described above.

[0181] During step 417, data server 20 transmits data packets related to application App5 via device 50, access unit 40, and terminal unit 30 to transmit video content required by terminal 60 during step 408. During step 416, device 50, which analyzes data packets received from data server 20, uses the aforementioned information to identify information data packets, and if the information data packet does not yet have a key that allows its decryption and a counter for extraction, it may store the information data packet for transmission to billing device 80 during step 419.

[0182] Therefore, the counting method implemented by terminal unit 30 and possibly by data server 20 enables device 50, which cooperates with billing device 80, to bill data packets and thus data of application App 5. Thus, the use of this method allows for counting of data associated with each application and allows for the reuse of encryption / decryption keys for data packets no longer used to transmit useful data including application data (i.e., data packets needed to access audio, video, or text from various applications).

[0183] refer to[ Figure 6 [This illustration shows an implementation of a counting method according to another embodiment of the present invention.]

[0184] The counting method and the corresponding capture method can be implemented according to several modes named RFLOW_A and RFLOW_B.

[0185] RFLOW_A mode is a one-way mode that does not require modification on the server because the device removes cooperative packets after receiving a signal from the terminal, after a period of time, or even after a certain amount of data has been received. Therefore, RFLOW_A mode defines cooperative packets that allow data exchange between the device (application type, counter) and the terminal in the QUIC protocol extension. Cooperative packets are encrypted using a key called 1-RTT, used in phase 0 of the QUIC protocol (session initialization). During or after connection termination, the terminal unit sends the 1-RTT key for QUIC phase 0 at a time of its choice. The device records all or some of the messages exchanged between the terminal unit and the data server to identify and decode cooperative packets upon receiving the cooperative key used to decrypt registered cooperative packets.

[0186] The differences between RFLOW_B and RFLOW_A modes are as follows. In addition to RFLOW_A, bidirectional RFLOW_B mode activates the extended (counting method) on the server by sending the QUIC COOP_MODE transmission parameter, for example, when establishing a session between the terminal unit and the data server. Therefore, when the server receives a 1-RTT message after the transition phase, it will not terminate the connection based on an error. In fact, if the server did not activate the counting method, it could consider receiving packets encrypted with a key that is no longer normally used to be an error. Furthermore, the server will also be able to send and receive cooperative packets.

[0187] [ Figure 6 This describes an example related to the RFLOW_A mode.

[0188] The UA (Terminal Unit) establishes a session with the data server (SRV) in order to route messages (or data packets) via, for example, a device (GW) managed by the operator of the communication network.

[0189] Step 0: Step (0) The terminal UA and the device GW exchange the encryption key ENC_KEY_UA and the decryption key DEC_KEY_UA.

[0190] Various types of encryption / decryption keys can be used, such as:

[0191] ● The device GW provides the UA with a key called the "external PSK" key, as defined in the document https: / / tools.ietf.org / html / draft-ietf-tls-tls13-cert-with-extern-psk-07;

[0192] ● The eSNI key for the DNS eSNI used to record the FQDN of the GW, as defined in the document https: / / tools.ietf.org / html / draft-ietf-tls-esni-05.

[0193] Step A: The device activates a method for capturing data packets received from the terminal unit (UA). It should be noted that this step can be performed after the UA receives the message for activating capture.

[0194] Step B: The “handshake” messages exchanged between the UA and SRV. These messages use a key identified through deterministic data corresponding to Phase 0. This key is the future cooperation key. Thereafter, it is referred to as the initial Phase 0 key or even the reconnection Phase 0 key, even if it can be any type of key described in Step 0.

[0195] Step C: Exchange application-related data packets (e.g., those sent by terminals connected to the UA and in [...]) between the UA and SRV. Figure 6 (Not shown in the image). At this point, the exchanged data packets may include specific data corresponding to either the ongoing phase (0 in the example) or the new phase (1 in the example). In practice, the data packets can be encrypted with a new encryption key.

[0196] Step D: The GW activates the RFLOW extension of the capture method after a delay of n ms, or after n consecutive packets containing deterministic data corresponding to the assumed active phase (0 in the example), in the absence of packets containing deterministic data corresponding to the new phase (1 in the example). This deterministic data should no longer be used to exchange packets between the UA and SRV after the encryption key change. From this point onward, packets of the previous phase (whose deterministic data corresponds to phase 0) are considered cooperative packets and captured, and removed by the GW from the packet stream exchanged between the UA and SRV.

[0197] According to one example, GW uses the standard flag bits of QUIC inverted packets as determining data.

[0198] In a generalized manner, the phase (determined data) will then be reversed again, returning to phase 0. The GW will then pause RFLOW extension if it detects a cooperative packet that it cannot decrypt. This packet will be sent to the server SRV and not stored by the GW. The GW will then reactivate RFLOW extension after a delay of n ms if there are no packets with the previous phase set to 1, or after n consecutive packets containing determined data corresponding to the new phase (0 in this example). These packets of the previous phase (called the cooperative phase) are captured by the GW and removed from the stream.

[0199] Step E: Exchange the untagged data packets with the determined data corresponding to the phase set to 1.

[0200] Step F: Count the messages (which may be data packets or different types of data) and add the counter to the cooperative data packet. Set the phase (deterministic data) of the cooperative data packet to 0. Send the cooperative data packet to the GW.

[0201] Step G: Capture the cooperative data packet, including the counter, by identifying the phase set to 0 used to determine the data. It should be noted that alternatively, or in addition to the transmission during step 0, the UA may send the decryption key associated with the initial phase 0 to the GW.

[0202] If RFLOW_B mode is implemented, the UA transmits the message used to activate the (counting method) extension to the SRV after or during the exchange of handshake messages.

[0203] Additionally, in this RFLOW_B mode, the GW does not remove cooperative packets from all packets routed by the GW between the UA and SRV. Therefore, cooperative packets with specific data corresponding to the cooperative packet (phase 0) are received by the SRV. Depending on the session established between the UA and SRV, the server SRV may send data to the UA in response to or without responding to packets received from the UA. The SRV implements a counting method, and the GW also captures cooperative packets transmitted from the SRV to the UA by selecting cooperative packets based on the value of specific data present in packets also received from the server SRV. In this RFLOW_B mode, the UA will also receive cooperative packets.

[0204] It should be noted that, according to previous techniques, in QUIC and TLS 1.3 protocols, the key used for the previous connection is used to reconnect the session. Based on this model, the corresponding counting and capture methods reclaim the 0-RTT key in order to mark cooperative packets to be recognized by the GW.

[0205] When a new session is involved, i.e., no session has been established previously, an implementation of the method described below can be deployed.

[0206] When the device UA and SRV establish their first connection (i.e., before the pre_shared_key extension is activated), once the handshake has ended and the master_secret has been obtained, the UA and SRV use the following operations to obtain the cooperation_secret:

[0207] cooperation_secret=QHKDF-Expand(master_secret, "coop s", hash.length).

[0208] This secret is then provided to the GW, which can (like the UA and SRV) use the following operations to compute the key and initialization vector (iv-initialization vector):

[0209] key=QHKDF-Expand(cooperation_secret, "key", key_length);

[0210] iv=QHKDF-Expand(cooperation_secret, "iv", iv_length).

[0211] Furthermore, it should be noted that RFLOW_A and RFLOW_B modes can be combined to enhance the level of cooperation by creating several modes for identifying cooperative packets through the GW:

[0212] ● The spin bit S identifies cooperative data packets, and the RR bits (R1, R2) distinguish several cooperative modes:

[0213] ○ In RFLOW_A mode, S is set to 1 to indicate that the packet is a cooperative packet (decrypted using the DEC_KEY_UA key).

[0214] ○ Advanced Options: Use R1 and R2 bits to distinguish four types of cooperative data packets:

[0215] ■ Read: 00 indicates that a QUIC packet is included in the GW readable zone;

[0216] ■Delete: 01 indicates a QUIC packet that can be read by the gateway and removed by the GW;

[0217] ■Update: 10 indicates that QUIC data packets (unencrypted) can be modified by GW using plain text;

[0218] ■Modification: 11 indicates the QUIC end-to-end data packets that are open to cooperation in write mode.

[0219] refer to[ Figure 7 The image shows an example of the structure of a discrimination device 500 according to an embodiment of the present invention.

[0220] The identification device 500 implements the identification method, and different embodiments of the identification method have been described above. The identification device can be implemented in a device in a communication network, such as a terminal unit, a device for accessing a local area network (e.g., a home gateway), a terminal, or a router.

[0221] For example, device 500 includes a processing unit 530 equipped with, for example, a microprocessor μP and controlled by a computer program 510 stored in memory 520 and implementing the identification method according to the invention. During initialization, the code instructions of the computer program 510 are loaded into, for example, RAM before being executed by the processor of processing unit 530.

[0222] This device 500 includes:

[0223] - Marking module 502, which is capable of:

[0224] - Add attributes related to the first message to the information data packet, which incorporates the processed attributes;

[0225] - Apply tags to information data packets that include added attributes;

[0226] - Transmitter 503, which is capable of sending data packets containing applied tags to a data server.

[0227] refer to[ Figure 8 The image shows an example of the structure of a processing device according to an embodiment of the present invention.

[0228] The processing device 600 implements the processing method, and various embodiments of the processing method have been described above. The processing device 600 can be implemented in a device in a communication network, such as a router, firewall, flow inspection device (deep packet inspection), or even a data server.

[0229] For example, device 600 includes a processing unit 630 equipped with, for example, a microprocessor μP and controlled by a computer program 610 stored in memory 620 and implementing the processing method according to the invention. During initialization, the code instructions of the computer program 610 are loaded into, for example, RAM before being executed by the processor of processing unit 630.

[0230] This device 600 includes:

[0231] - Receiver 601, which is capable of receiving information data packets from a terminal unit;

[0232] - Detector 602, which is capable of detecting information data packets including attributes added by the terminal unit based on the tags applied to the received information data packets;

[0233] - Processing module 603, which is capable of processing attributes included in the received information data packet.

[0234] refer to[ Figure 9 The image shows an example of the structure of a capture device 700 according to an embodiment of the present invention.

[0235] The capture device 700 implements the capture method, and various embodiments of the capture method have been described above. The capture device 700 can be implemented in devices in a communication network, such as routers, firewalls, flow inspection devices (deep packet inspection), or even data servers.

[0236] For example, device 700 includes a processing unit 730 equipped with, for example, a microprocessor μP and controlled by a computer program 710 stored in memory 720 and implementing the capture method according to the invention. During initialization, the code instructions of the computer program 710 are loaded into, for example, RAM before being executed by the processor of processing unit 730.

[0237] This device 700 includes:

[0238] - Receiver 704, which is capable of receiving multiple data packets from a terminal unit;

[0239] -Analyzer 701, which is capable of analyzing multiple data packets sent by the terminal unit and destined for the server;

[0240] - Identification module 702, which is capable of identifying cooperative data packets among multiple analyzed data packets, the cooperative data packets including deterministic data corresponding to a security key, the security key being used to encrypt data packets transmitted from the terminal unit to the data server before the terminal unit sends the cooperative data packets;

[0241] - Decryption module 703, which is capable of decrypting the received cooperative data packet using a security key corresponding to the specific data of the identified cooperative data packet.

[0242] refer to[ Figure 10 The diagram illustrates an example of the structure of a counting device 800 according to an embodiment of the present invention.

[0243] The counting device 800 implements a counting method, various embodiments of which have been described above. The counting device 800 can be implemented in a device in a communication network, such as a terminal unit, a device for accessing a local area network (e.g., a home gateway), or a terminal or router type device.

[0244] For example, device 800 includes a processing unit 830 equipped with, for example, a microprocessor μP and controlled by a computer program 810 stored in memory 820 and implementing the counting method according to the invention. During initialization, the code instructions of the computer program 810 are loaded into, for example, RAM before being executed by the processor of processing unit 830.

[0245] This device 800 includes:

[0246] - Transmitter 802,

[0247] - The transmitter is capable of transmitting multiple data packets, each of which includes data used to determine a security key for encrypting the data packet;

[0248] - The transmitter is able to transmit cooperative data packets, including the added counters, to the data server;

[0249] - Computer 801, which is capable of incrementing a counter for data related to an application, particularly data sent to a data server, and is capable of adding the incrementing counter to a cooperative data packet, which includes deterministic data corresponding to a security key used to encrypt data packets among multiple data packets exchanged between the terminal unit and the data server, before sending the cooperative data packet.

Claims

1. A method for capturing data packets from an encrypted session established between a terminal unit (30) and a data server (20), the data packets including data for determining a security key for encrypting the data packets, the method being implemented by a device (50) that routes the data packets between the terminal unit and the data server and comprising: - Analyze the data used to determine the security keys of multiple data packets transmitted by the terminal unit (30) and sent to the data server (20); - Identify cooperative data packets from the plurality of transmitted data packets, the cooperative data packets including determining data corresponding to the security key, the cooperative data packets including a first value of the determining data, the first value being different from a second value of data used to determine the security key of other data packets among the plurality of data packets, the first value corresponding to a security key used to encrypt data packets transmitted from the terminal unit to the data server before the terminal unit sends the cooperative data packets; - The received cooperative data packet is decrypted using a security key corresponding to a first value of determined data in the identified cooperative data packet, wherein the cooperative data packet includes application-related attributes.

2. The method as described in claim 1, wherein, The determined data is a binary phase element indicating a key change used by the terminal and the data server to encrypt and decrypt data packets exchanged between the terminal unit and the data server.

3. The method as claimed in claim 1 or claim 2, wherein, The cooperative data packet is a packet of the Secure Data Multiplexing Protocol (SDP), and the cooperative data packet is identified based on one or more of the following parameters: - Fixed phase; - The value of the spin bit in the QUIC data packet; - The value of the RR bit in the QUIC data packet; - Connection identifier.

4. The method of claim 1, wherein, The cooperative data packets are identified after the detection of these packets is activated in the device, and the values ​​of the determined data of these packets are different from the values ​​of the determined data of multiple consecutive data packets previously received from the terminal unit.

5. The method of claim 1, wherein, After the session between the terminal unit and the data server ends, the terminal unit transmits the security key associated with the determined data to the device.

6. The method of claim 1, wherein, The security key associated with the determined data is used to protect the exchange of data packets from previous sessions between the terminal unit and the data server.

7. The method of claim 1, wherein, The security key associated with the determined data is a key negotiated between the terminal unit and the data server during the session initialization step.

8. The method of claim 1, wherein, When the plurality of data packets are routed to the data server, the cooperative data packet is removed from the plurality of data packets.

9. The method of claim 1, further comprising analyzing and identifying cooperative data packets from the data packets transmitted from the data server to the terminal unit, and decrypting the cooperative data packets as described in claim 1.

10. A method for counting application-related data transmitted from the terminal unit (30) to the data server (20) via a device (50) using an encrypted session between a terminal unit (30) and a data server (20), the method being implemented by the terminal unit and comprising: - Transmit multiple data packets, each including data used to determine a security key for encrypting that data packet; - Increment the counters for data related to the application; - Add the incrementing counter to the cooperative data packet, the cooperative data packet including determination data corresponding to the security key, the cooperative data packet including a first value of the determination data, the first value being different from a second value of data used to determine the security key of other data packets among the plurality of data packets, the first value corresponding to a security key used to encrypt data packets among the plurality of data packets exchanged between the terminal unit and the data server before sending the cooperative data packet; - Send a cooperative data packet containing the added counter to the data server.

11. The method of claim 10, further comprising sending a security key to the device corresponding to determined data of the cooperative data packet.

12. The method of claim 10 or claim 11, further comprising the device previously sending a message to the data server to activate the method.

13. An apparatus (50) for capturing data packets from an encrypted session established between a terminal unit (30) and a data server (20), the data packets including data for determining a security key for encrypting the data packets, the apparatus comprising: - An analyzer that is capable of analyzing data used to determine the security keys of multiple data packets transmitted by the terminal unit (30) and sent to the data server (20); - An identification module capable of identifying cooperative data packets from the plurality of transmitted data packets, the cooperative data packets including determining data corresponding to the security key, the cooperative data packets including a first value of the determining data, the first value being different from a second value of data used to determine the security key of other data packets among the plurality of data packets, the first value corresponding to a security key used to encrypt data packets transmitted from the terminal unit to the data server before the terminal unit sends the cooperative data packets; - A decryption module that can decrypt a received cooperative data packet using a security key corresponding to a first value of determined data in the identified cooperative data packet, wherein the cooperative data packet includes application-related attributes.

14. An apparatus for counting application-related data transmitted from a terminal unit (30) to a data server (20) via a device (50) using an encrypted session between the terminal unit (30) and the data server (20), the apparatus comprising: - A transmitter capable of transmitting multiple data packets, each including data for determining a security key used to encrypt the data packet; - A computer capable of incrementing a counter for application-related data and adding the incremented counter to a cooperative data packet, the cooperative data packet including determination data corresponding to the security key, the cooperative data packet including a first value of the determination data, the first value being different from a second value of data used to determine the security key of other data packets among the plurality of data packets, the first value corresponding to a security key used to encrypt data packets among the plurality of data packets exchanged between the terminal unit and the data server before sending the cooperative data packet; - A transmitter that can transmit cooperative data packets, including the added counters, to the data server.

15. A system for counting application-related data transmitted from a terminal unit to a data server via a device using an encrypted session between a terminal unit and a data server, the system comprising at least one device as claimed in claim 13 and at least one device as claimed in claim 14.

16. A computer program product having a computer program stored thereon, the computer program including instructions for implementing the method as described in any one of claims 1 to 9 when the program is executed by a processor.

17. A computer program product having a computer program stored thereon, the computer program including instructions for implementing the method as described in any one of claims 10 to 12 when the program is executed by a processor.

Images