Encryption communication

Abstract

The invention relates to encrypted communication, and belongs to the technical field of encrypted communication. The present invention is a method for exchanging data in an end-to-end encryption manner between a first terminal and a second terminal, the first terminal and the second terminal participating in a conference session managed by a media server, in which a communication channel is established between the media server and a browser of the first terminal, and wherein the method comprises: first encrypting, by the second terminal, a multimedia stream using a first encryption key associated with the conference session; the encrypted multimedia stream is sent to the media server by the second terminal; performing, by the media server, a second encryption of the encrypted multimedia stream using an encryption key negotiated between the browser of the first terminal and the media server for communication over the communication channel; subsequently, the multimedia stream is sent, by the media server, to the first terminal.

Description

Technical Field

[0001] This invention relates to the field of encrypted communication. Background Technology

[0002] Communication security is a concern across various industrial sectors. In particular, a significant amount of information is currently exchanged via conference sessions. These sessions are typically real-time and involve multiple participants connected to the session via electronic devices. Encrypting communications during these conference sessions can prove complex.

[0003] This invention improves upon this situation. Summary of the Invention

[0004] To this end, a method is proposed for exchanging data in an end-to-end encrypted manner between a first terminal and a second terminal participating in a conference session managed by a media server, wherein a communication channel is established between the media server and the browser of the first terminal, and wherein the method includes:

[0005] The second terminal performs a first encryption on the multimedia stream using a first encryption key associated with the conference session;

[0006] The encrypted multimedia stream is sent to the media server by the second terminal;

[0007] The media server performs a second encryption on the already encrypted multimedia stream using an encryption key negotiated between the browser on the first terminal and the media server for communication on the communication channel; then,

[0008] The media server sends the multimedia stream to the first terminal.

[0009] Optionally, the method further includes the first terminal performing a first decryption on a multimedia stream received from the media server using an encryption key negotiated between the browser on the first terminal and the media server; and,

[0010] The first terminal uses a second encryption key to perform a second decryption on the multimedia stream, wherein the second encryption key is capable of decrypting the multimedia stream encrypted by the first encryption key.

[0011] Optionally, the second decryption includes:

[0012] Load the bytecode file containing the decryption functions used to decrypt the data stream; and,

[0013] The decryption function is executed on the multimedia stream.

[0014] Optionally, the browser of the first terminal further includes an encoding module, which allows the use of multiple codecs to encode or decode the multimedia stream, wherein the method further includes:

[0015] The second terminal encodes the multimedia stream using the first codec; and,

[0016] When the first codec is one of the plurality of codecs:

[0017] The multimedia stream is decoded using the browser's encoding module.

[0018] Optionally, when the first codec is not one of the plurality of codecs supported by the encoding module, the method further includes:

[0019] Load a bytecode file containing decoding functions for decoding a data stream encoded using the first codec; and,

[0020] The decoding function is executed on the multimedia stream encoded by the first codec.

[0021] Optionally, the communication channel between the media server and the browser is established according to the WebSocket protocol;

[0022] The media server then sends the multimedia stream to the first terminal via the communication channel established between the media server and the browser of the first terminal, including:

[0023] The multimedia stream is written to the communication channel established between the media server and the browser.

[0024] This application also relates to a terminal suitable for connecting to a conference session managed by a media server, the terminal including a browser, wherein the terminal is configured to:

[0025] The multimedia stream is first encrypted using a third encryption key associated with the conference session;

[0026] Using an encryption key negotiated between the browser and the media server, a second encryption is performed on the multimedia stream encrypted with the third encryption key to encrypt the multimedia stream exchanged between the media server and the browser; and,

[0027] The encrypted multimedia stream is transmitted to the media server.

[0028] Optionally, the terminal may also be configured to:

[0029] A multimedia stream is obtained from the media server. This multimedia stream has been first encrypted using a first encryption key from another terminal of the conference, and second encrypted using an encryption key negotiated between the browser and the media server for encrypting the multimedia stream exchanged between the media server and the browser.

[0030] Using the encryption key negotiated between the browser and the media server, a first decryption is performed on the multimedia stream received from the media server; and,

[0031] A second encryption key is used to perform a second decryption on the multimedia stream received from the media server, the second encryption key being capable of decrypting the multimedia stream encrypted by the first encryption key.

[0032] Optionally, applying the second decryption to the multimedia stream includes:

[0033] Load the bytecode file containing the decryption functions used to decrypt the data stream; and,

[0034] The decryption function is executed on the multimedia stream.

[0035] This application also relates to a media server configured to manage a conference session involving at least a first terminal and a second terminal, wherein the media server is configured to:

[0036] Receive, from the second terminal, an encrypted multimedia stream to be sent to other participants in the conference session; and,

[0037] The encrypted multimedia stream is encrypted using an encryption key negotiated with the browser of the first terminal.

[0038] This application also relates to a computer program product comprising instructions that, when executed by a processor, are used to implement all or part of any of the methods proposed in this invention.

[0039] Finally, this application relates to a non-transient computer-readable storage medium having a program stored thereon that, when executed by a processor, implements all or part of any of the methods proposed in this invention. Attached Figure Description

[0040] Other features, details, and advantages will become apparent after reading the following detailed description and analyzing the accompanying drawings, in which:

[0041] [ Figure 1 The diagram illustrates an example of a communication architecture according to the present invention.

[0042] [ Figure 2The diagram schematically illustrates an example of a terminal according to the present invention.

[0043] [ Figure 3 The illustration schematically depicts an example of a first terminal according to the invention.

[0044] [ Figure 4 The image schematically illustrates an example of a media server according to the present invention.

[0045] [ Figure 5 This illustration represents an example of a method for exchanging data in an end-to-end encrypted manner.

[0046] [ Figure 6 This schematically illustrates another example of a method for exchanging data in an end-to-end encrypted manner.

[0047] [ Figure 7 This schematically illustrates yet another example of a method for exchanging data in an end-to-end encrypted manner.

[0048] [ Figure 8 This schematically illustrates yet another example of a method for exchanging data in an end-to-end encrypted manner.

[0049] [ Figure 9 This schematically illustrates yet another example of a method for exchanging data in an end-to-end encrypted manner.

[0050] [ Figure 10 The illustration schematically shows an example of operation that can be implemented by a terminal according to the invention. Detailed Implementation

[0051] The inventors noted that conference sessions that allow the exchange of audio or video data streams may involve participants using browser-provided functions to process and read the exchanged data streams. The data stream exchange in these conference sessions is based on the Real-Time Transport Protocol (RTP), meaning that these data exchanges conform to the RFC 3550 standard.

[0052] However, exchanging data streams with a media server (i.e., the server that manages the conference session, particularly the server that redirects data streams to participants) using a browser increases the complexity of data exchange because the means of communicating with a browser are limited and standards-bound. Furthermore, while using a browser to participate in such meetings is advantageous, this use complicates the transmission of data streams during the conference session. Using a browser is particularly advantageous because the various browsers available on the market are maintained and regularly updated by their respective publishers, and offer attractive performance in processing and reading the real-time data streams exchanged during a conference session. Moreover, most computers are sold pre-installed with browser-like applications, so computer owners do not need to download dedicated applications to participate in conference sessions.

[0053] The inventors specifically noted that when the first participant in a conference session uses a browser, the session cannot provide end-to-end encryption of the data stream sent from the second participant to the first participant. In fact, the inventors astutely observed that the data stream transmitted by the second participant and encrypted with the encryption key used in the conference session is decrypted at the media server and then re-encrypted using a key negotiated between the media server and the first participant's browser. Therefore, the data stream transmitted from the second participant to the first participant in the conference session is not end-to-end encrypted because it is decrypted by the media server at some point and then re-encrypted and transmitted through the existing communication channel between the media server and the browser.

[0054] Specifically, when the communication channel between the media server and the browser of the first participant uses the WebRTC application programming interface (referred to as the "API" in the remainder of this invention), particularly the API described in RFC 8835, the communication channel specification proposed for communicating audio and / or video streams using the WebRTC API does not allow the transmission of any data streams other than audio and / or video data streams conforming to the RTP protocol (unencrypted), which are subsequently encrypted to conform to the protocol using a key negotiated between the media server and the browser according to the DTLS-SRTP protocol, which acts as a WebRTC client.

[0055] Therefore, this invention proposes a solution that allows end-to-end encryption within a conference session framework, even when participants are using a browser to engage in the session, and even when the browser is communicating with the server using the WebRTC API. Specifically, this solution proposes to directly transmit a stream encrypted using a first encryption key associated with the conference session via the communication channel between the media server and the browser. This stream has already been encrypted initially and therefore requires re-encryption using an encryption key negotiated between the media server and the browser.

[0056] The browser then decrypts the stream twice: the first decryption uses a key negotiated between the media server and the browser, and the second decryption uses a second key associated with the conference session, as detailed below. Specifically, the browser, and more specifically its JavaScript engine, will be able to execute code instructions to perform the second decryption using the second key associated with the conference session, thus enabling end-to-end encryption of the data stream between the first and second participants.

[0057] Furthermore, since the function containing the code instructions for decrypting the data stream has already been developed for participants who do not use a browser, this solution can also propose reusing this function. This function is stored as bytecode in a dedicated file, which will be loaded by the browser's JavaScript engine and executed from the JavaScript engine. Therefore, instead of developing a new JavaScript function to decrypt the data stream—which would require maintaining two different sets of code—the solution reuses the code and executes it as bytecode, which is much faster than interpreting and executing the function based on JavaScript instructions.

[0058] Now for reference Figure 1 An example of a communication architecture 1 is described that enables conference sessions that allow the exchange of multimedia data streams.

[0059] In this invention, a data stream or flow is defined as corresponding to at least two consecutive data packets. An audio data stream or audio stream is defined as corresponding to at least two consecutive audio data packets. A video data stream or video stream is defined as corresponding to at least two consecutive video data packets.

[0060] In this invention, a multimedia stream can correspond to an audio data stream or a video data stream. In audio-visual conferencing, both audio and video data streams are transmitted simultaneously, i.e., two different types of multimedia streams.

[0061] Communication architecture 1 includes a media server 3, a first terminal 2a, and a second terminal 2b. Communication architecture 1 may contain more than two terminals 2, and may contain as many terminals as there are participants in a conference session. However, this patent application is limited to illustrating an architecture with two terminals 2, as the solution proposed in this invention can be clearly understood through the two terminals 2.

[0062] The conference session allows for near real-time exchange of multimedia streams between terminals. During the conference session, the multimedia stream transmitted by the sending terminal is sent to media server 3, which can then distribute it to the receiving terminals participating in the conference session. Media server 3 is sometimes referred to as the "session server".

[0063] It should be noted that the terminal that sends the first multimedia stream can subsequently or simultaneously become the terminal that receives the second multimedia stream sent by another sending terminal participating in the conference session.

[0064] In the first alternative, the conference session could therefore refer to an audio conference, in which terminals may be directed to exchange audio streams in near real-time via media server 3.

[0065] In the second alternative, the conference session may refer to a video conference, in which terminals may be directed to exchange video streams in near real-time through media server 3.

[0066] In the third alternative, the conference session can refer to an audio-visual conference, in which terminals may be directed to exchange audio and video streams in near real-time through a media server 3.

[0067] It should be noted that in the first or third alternative, the audio stream can, for example, correspond to push-to-talk communication. Push-to-talk (also known as press-to-transmit) communication is bidirectional (non-simultaneous) communication, based on the user pressing a physical or virtual button to switch from receive mode to send mode and vice versa. These communications use a half-duplex communication channel.

[0068] Therefore, a terminal can correspond to either a fixed or mobile communication device. A communication device is mobile in that it is not physically connected to a communication network via cables, or it connects over short distances, for example, by using Wi-Fi, NFC, or Bluetooth protocols. Conversely, a mobile communication device is adapted to communicate data over long distances via telecommunications networks, such as mobile networks, so that it can exchange data while roaming. A mobile communication device can, for example, correspond to a mobile phone.

[0069] During a conference session, data packets of multimedia streams sent by terminals are encapsulated according to the Internet Protocol (IP). This protocol is specifically defined in the RFC 791 standard.

[0070] In this invention, the data streams exchanged by terminals during a conference session can be encapsulated according to the SRTP protocol (Secure Real-time Transport Protocol). In this application, data streams encapsulated according to the SRTP protocol are understood to be arranged as SRTP-compliant data streams, i.e., conforming to the protocol specifically defined in RFC 3711.

[0071] During a conference session, the multimedia stream sent by the sending terminal is also encoded by a codec implemented by the sending terminal. The codec varies depending on the type of data (audio or video) in the multimedia stream.

[0072] In some examples, the audio codec may correspond to one of the following: GSM, iLBC, Speex, AMR-WB, EVS, OPUS. In some examples, the video codec may correspond to one of the following: VP8, VP9, ​​AV1, H264.

[0073] Terminal 2 may include a processor 21 and a memory 22. The processor 21 may be adapted to implement the functions used by terminal 2. In other words, the processor of the first terminal 2a may be configured to implement the functions used by the first terminal 2a, and the processor of the second terminal 2b may be configured to implement the functions used by the second terminal 2b. The processor 21 may be, for example, a microprocessor. The processor 21 is particularly a component of an integrated circuit, especially a component of a microcontroller, a component of an FPGA (Field-Programmable Gate Array), or a component of an ASIC (Application-Specific Integrated Circuit).

[0074] Memory 22 may store code instructions executed by processor 21. Memory 22 may include, for example, ROM (Read-Only Memory), RAM (Random Access Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), or any other suitable type of storage device. Memory may include, for example, optical, electronic, or magnetic storage devices.

[0075] Terminal 2 may also include a microphone 23 for capturing audio streams.

[0076] Terminal 2 may also include a camera 24 for capturing video streams.

[0077] An example of a terminal 2 that includes a processor 21, memory 22, microphone 23, and camera 24 is particularly shown in Figure 2 As shown in the image.

[0078] Figure 3 An example of a first terminal 2a is shown. In this example, terminal 2a includes a browser (BRO).

[0079] A browser blooper (BRO) refers to a software unit designed for accessing and displaying the World Wide Web, specifically through interpreting and executing JavaScript code instructions. Therefore, a browser blooper corresponds to software that implements HTTP (Hypertext Transfer Protocol) requests, allowing connections to HTTP servers (web servers). A browser blooper, for example, corresponds to a well-known browser. A browser blooper may include multiple modules developed by their respective publishers, which will be described in detail below. Therefore, by relying on existing browser bloopers, there is no need to develop and maintain the modules already provided by the browser.

[0080] The software unit can be implemented, in particular, by the processor 21 of the terminal. Therefore, the browser BR0 can be implemented by the processor 21 of the first terminal 2a.

[0081] Browser RO includes JavaScript Engine JM, which refers to the software unit that allows the interpretation and execution of JavaScript language code instructions to perform various functions and modules of the browser RO.

[0082] The browser BRO also includes a communication module COM, which allows it to communicate with the media server 3. In this case, the media server 3 may include a corresponding communication module. The communication module COM allows the establishment of an encrypted communication channel between the browser BRO and the media server 3. The creation of the encrypted communication channel between the first terminal 2a and the media server 3 can be initiated by the media server 3 (through its communication module) or by the first terminal 2a. In particular, the browser BRO's communication module COM allows the exchange (i.e., sending and receiving) of multimedia streams with the media server 3.

[0083] In the first alternative, the communication module COM may, for example, include a WebRTC API. The media server 3 may subsequently also include a WebRTC API for communicating with the corresponding WebRTC API of the first terminal 2a. In this first alternative, the encryption key exchanged over the encrypted communication channel is negotiated between the media server 3 and the browser BR0 according to the DTLS-SRTP (Datagram Transport Layer Security-Secure Real Time Protocol) protocol, specifically defined in RFC 5764. It should be noted that the multimedia data stream is exchanged via the WebRTC API's data channel ("data channel" in the WebRTC API specification), rather than via a function defined for transmitting multimedia streams according to the WebRTC API specification. In fact, the WebRTC API specification defines a function for transmitting multimedia streams, but this function does not allow the transmission of encrypted multimedia streams. Therefore, the inventors cleverly switched to using the WebRTC API to transmit encrypted multimedia streams through a specific communication channel (called a data channel in the WebRTC API), instead of using the functions defined by the WebRTC API to transmit these multimedia streams, because the functions do not allow the transmission of encrypted streams and require decryption of the stream before retransmission, thus disallowing end-to-end encryption.

[0084] In a second alternative, the communication module COM may, for example, include a WebSocket module that allows communication with the media server 3 according to the WebSocket protocol. The WebSocket protocol is specifically defined in RFC 6455. In this second alternative, the encryption key exchanged over the encrypted communication channel is negotiated between the media server 3 and the browser BR0 according to the TLS (Transport Layer Security) protocol, specifically defined in version 1.3 of RFC 8446 (other versions may also be considered). The communication channel created according to the WebSocket protocol allows the exchange of encrypted multimedia streams without decryption before re-encryption using the key negotiated according to the TLS protocol. It should be noted that using the WebSocket protocol to transmit multimedia streams for conference sessions that must be transmitted in near real-time is a clever use of the protocol, which was not originally designed for this type of communication. In fact, the WebSocket protocol is configured to exchange packets according to the TCP protocol (Transmission Control Protocol, specifically defined in RFC 793), which is not the preferred protocol for exchanging SRTP packets. More specifically, data transmission using the UDP (User Datagram Protocol) protocol has less latency than the TCP protocol and does not interrupt the data stream in the event of packet loss, unlike TCP, which is why TCP is not chosen for real-time communication. Therefore, this second alternative involves cleverly utilizing the WebSocket protocol to transmit SRTP packets using TCP.

[0085] In some examples, a browser BRO may include an encoding module E / D, which corresponds to a software unit used for encoding or decoding multimedia streams. More specifically, the encoding module E / D is configured to allow encoding and decoding of data streams using multiple codecs supported by the module E / D. The encoding module E / D for a browser BRO may, for example, correspond to the WebCodecs API. The WebCodecs API is a standard proposed by the World Wide Web Consortium (W3C) that allows multimedia stream decoding and encoding operations to be performed through a browser.

[0086] In some examples, a browser RO (Browser Original Equipment) may include a multimedia streaming playback module (LEC). The LEC is a software unit specifically designed to play decoded multimedia data streams. The multimedia data stream may be decoded, for example, by an encoding module (E / D converter) and then provided to the LEC for playback. The LEC may specifically include audio streaming playback modules and / or video streaming playback modules, depending on the nature of the conference session. The audio streaming playback module (LEC) may, for example, include a WebAudio API, which allows playback of audio streams, particularly those formatted according to pulse code modulation (PCM).

[0087] In some examples, the browser's BRO may also include a bytecode module BC. A bytecode module BC can correspond to a software unit that allows the JavaScript engine JM to load and use functions contained in a bytecode file. In this respect, the bytecode module BC can be implemented directly in the JavaScript engine JM, or it can be a module different from the JavaScript engine JM but usable by the JavaScript engine JM, such as... Figure 3 As shown.

[0088] A bytecode file is a file containing data represented in bytecode format; that is, data in an intermediate format between source code written by a developer or intelligent model and machine code executed by a processor. In technical literature, bytecode is sometimes referred to as "intermediate code" or "bytecode". Therefore, a bytecode file can specifically correspond to a file containing compiled code instructions.

[0089] Therefore, bytecode files can include one or more functions, particularly function libraries, which can be used by the JavaScript engine (JM) once imported by the bytecode module (BC). The advantage of bytecode modules (BC) is that they allow functions encoded, pre-compiled, and stored in bytecode files in programming languages ​​other than JavaScript, resulting in faster execution when these functions are executed by the JavaScript engine. Furthermore, as mentioned above, this avoids the need to maintain functions designed to achieve the same functionality in several different programming languages.

[0090] In these examples, a bytecode module BC can include a module that allows the JavaScript engine JM to load and use functions contained in a WebAssembly file. WebAssembly files have the ".wasm" extension. WebAssembly is a standard proposed by the World Wide Web Consortium. It should be noted that a bytecode module BC can, of course, include other modules that allow the JavaScript engine JM to load and use functions contained in bytecode file types other than WebAssembly.

[0091] Therefore, the first terminal 2a can store a bytecode file, for example, in its memory 22, which includes a decryption function for decrypting a multimedia stream. This decryption function can, in particular, use an encryption key associated with the conference session to decrypt the multimedia stream. The stored bytecode file may, for example, correspond to a file of type WebAssembly.

[0092] When referring to an encryption key associated with a conference session in this invention, at least two different options can be envisioned for accessing that encryption key.

[0093] In the first option, all terminals participating in the conference session share the same encryption key. In this case, the sending terminal uses the encryption key to encrypt its transmitted multimedia data stream, while the receiving terminal uses the key to decrypt its received multimedia data stream. In this first option, the data stream encryption in the conference session is symmetric.

[0094] In the second option, a specific terminal participating in the conference session obtains a public encryption key and uses that key to encrypt its transmitted data stream. Furthermore, each other terminal participating in the conference session (i.e., terminals other than the specific terminal) obtains a private encryption key associated with the specific terminal's public encryption key (or information allowing retrieval of that private encryption key), and is allowed to decrypt the data stream encrypted by that specific terminal using its public key. Therefore, each terminal in the conference session stores a public key and at least one private key (in practice, multiple private keys), where each private key is associated with the public key of another terminal in the conference session. Thus, a given terminal in the conference session can use the private key associated with the public key of another terminal in the conference session to decrypt the data stream transmitted by that other terminal. In this second option, the data stream encryption in the conference session is asymmetric.

[0095] The encryption key, whether in the context of symmetric or asymmetric encryption, can be transmitted to the terminals of the conference session by the media server 3 or by the key management server (also known as the key management system, KMS). When the private key is not directly transmitted to the terminal, information that allows the terminal to determine the private key can be sent by the media server 3 or by the key management server (KMS).

[0096] In some examples, the bytecode file containing the decryption function may also include functions for decoding a multimedia stream encoded using a first codec, and may include functions for other codecs. In other examples, terminal 2a stores another bytecode file containing decoding functions for decoding a multimedia stream encoded using a first codec, and may include functions for other codecs. The first codec may specifically correspond to the AMR-WB, EVS, or OPUS codecs. This decoding function enables, for example, decoding of a multimedia stream encoded with a specific codec, thereby obtaining an audio stream that can be played by an audio player (particularly by player LEC). Therefore, the bytecode file decoding function can allow decoding of audio data streams encoded using codecs that are not supported by the browser module E / D and are not among the many codecs it supports.

[0097] Media server 3 may include processor 31 and memory 32. An example of a media server 3 including processor 31 and memory 32 is provided below. Figure 4 As shown in the diagram. Processor 31 can be adapted to implement the functions used by media server 3 in this disclosure. Processor 31 can be, for example, a microprocessor. Processor 31 is particularly a component of an integrated circuit, especially a component of a microcontroller, a component of an FPGA (Field Programmable Gate Array), or a component of an ASIC (Application-Specific Integrated Circuit).

[0098] Memory 32 may store code instructions executed by processor 31. Memory 32 may include, for example, ROM (Read-Only Memory), RAM (Random Access Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), or any other suitable type of storage device. Memory 32 may include, for example, optical, electronic, or magnetic storage devices.

[0099] The media server 3 may also include a communication module (not shown) that allows the establishment of a communication channel with the first terminal 2a. This communication module may include a WebRTC API and / or a WebSocket module for communicating with the corresponding API or module of the first terminal 2a. These modules may be implemented by the processor 31 of the media server 3.

[0100] Now for reference Figures 5 to 9 This describes an example of a method for exchanging data in an end-to-end encrypted manner between a first terminal 2a and a second terminal 2b, both participating in a conference session managed by a media server 3. As described above, the media server 3 transmits multimedia data streams to the participants of the conference session in real time. Furthermore, a communication channel is established between the media server 3 and the browser BROWN. The conditions for establishing this communication channel have also been described above.

[0101] It should be noted that the accompanying figures related to the example of Method 100 are merely simplified illustrations of the example of Method 100. These figures use boxes to represent various operations that may be included in the method and described in the remainder of this document. Therefore, these figures do not show any order between the operations. In other words, the operations described with reference to the figures are not necessarily implemented one after another, and in particular, may be implemented in a different order than shown in the figures, or may be implemented in parallel, unless one operation requires the result of another operation to be implemented. Similarly, each operation need not be implemented the first time before the same operation is repeated a second time. The frequency of implementation of each operation is specific and not necessarily related to the implementation of other operations.

[0102] As shown in box 110, this example method 100 includes performing a first encryption on a multimedia stream to be transmitted to conference session participants. The first encryption 110 is performed by a second terminal 2b, for example by its processor, using a first encryption key associated with the conference session. The conditions for obtaining the encryption key associated with the conference session have been described above.

[0103] As shown in box 120, example method 100 includes sending an encrypted multimedia stream to media server 3. This sending is performed by a second terminal 2b and may be implemented, for example, by its processor. Thus, media server 3 receives from the second terminal 2b a multimedia stream encrypted using a first encryption key associated with the conference session.

[0104] As shown in box 130, example method 100 includes a second encryption of the already encrypted multimedia stream. The second encryption is performed by media server 3, for example by its processor 31, using an encryption key negotiated between browser BR0 and media server 3 for communication over the communication channel. Details regarding the encryption key negotiated between browser BR0 and media server 3 have been described above. Therefore, it can be understood that after box 130, the multimedia stream transmitted by the second terminal 2b is encrypted with two different encryption keys: a first encryption key associated with the conference session, and an encryption key negotiated between media server 3 and browser BR0.

[0105] As shown in box 140, example method 100 includes sending a multimedia stream to a first terminal 2a. The multimedia stream is sent by a media server 3, for example, following commands from its processor 31, and corresponds to a multimedia stream that is encrypted twice using two encryption keys. The double-encrypted multimedia stream is sent via a communication channel established between the media server 3 and the browser BROWN.

[0106] Therefore, the method 100 according to the invention allows the transmission of a multimedia stream with end-to-end encryption between a first terminal 2a participating in a conference session via its browser and a second terminal 2b also participating in the conference session. This multimedia stream is not decrypted at the media server 3 and is then retransmitted via a communication channel established between the media server 3 and the browser.

[0107] In some examples, and as shown in box 150, method 100 may also include a first decryption of the multimedia stream received from media server 3. The first decryption is performed by a first terminal 2a, for example by its processor, using an encryption key negotiated between its browser BR0 and media server 3.

[0108] In some examples, and as shown in box 160, method 100 may also include a second decryption of the multimedia stream that has already been decrypted for the first time in box 150. The second decryption is performed by the first terminal 2a, for example by its processor, using a second encryption key that allows decryption of the multimedia stream encrypted by the first encryption key.

[0109] In the first option of symmetric encryption, the second encryption key may correspond to the first encryption key. In the second option of asymmetric encryption, the first encryption key may correspond to the public key of the second terminal 2b, and the second encryption key may correspond to the private key associated with the public key of the second terminal 2b.

[0110] Examples of 100 methods, including both first and second decryption, are specifically included. Figure 6 As shown in the image.

[0111] In the examples, the second decryption box 160 may include boxes 161 and 162. These examples are particularly... Figure 7 As shown in the image.

[0112] Box 161 may correspond to loading a bytecode file containing decryption functions for decrypting the data stream. This loading can be performed, in particular, by the JavaScript engine JM of the browser's BRO using the bytecode module BC. This bytecode file is specifically a WebAssembly file, as described above.

[0113] Box 162 can correspond to executing a decryption function on a multimedia stream that has already undergone the first decryption. The execution of the decryption function can be performed by the browser's JavaScript engine JM using the bytecode module BC. Therefore, the decryption function used to decrypt the bytecode file data stream can rely on a second encryption key (which allows decryption of multimedia streams encrypted by the first encryption key) to perform decryption.

[0114] In some examples, method 100 may also include encoding the multimedia stream using a first codec. This encoding... Figure 8 The encoding is represented by box 105. This encoding is performed by the second terminal 2b, specifically before the first encryption performed by box 110. Therefore, when the multimedia stream is received by the first terminal 2a, it is encoded by the first codec in addition to being encrypted with two different encryption keys.

[0115] In some examples including box 105, and in a first alternative, when the first codec is one of several codecs supported by the browser BRO's encoding module E / D, method 100 may also include decoding the multimedia stream using the browser BRO's encoding module. This decoding... Figure 8 This is illustrated by box 170. This first alternative allows decoding via the BRO browser's decoding module E / D, and its execution speed is faster compared to the decoding in the second alternative described below, because it can be executed directly in the native environment of the first terminal 2a processor. On the other hand, the browser's decoding module E / D is limited to a specific number of codecs, and in particular does not support widely used codecs such as AMR-WB.

[0116] In some examples that include box 105, and in a second alternative, when the first codec is not one of the many codecs supported by the browser BRO's encoding module E / D, method 100 may also include boxes 180 and 181, as follows: Figure 8 As shown.

[0117] Box 180 may correspond to loading a bytecode file containing decoding functions for decoding a data stream encoded using a first codec. This bytecode file may be a WebAssembly file. This bytecode file may be the same as or a different file than the one loaded during box 161 containing the decryption functions. When it is the same file, it does not need to be loaded twice. The loading of this bytecode file may, in particular, be performed by the browser's JavaScript engine JM using the bytecode module BC.

[0118] Box 181 may correspond to the execution of a decoding function on a multimedia stream encoded by a first codec and loaded during box 180. The execution of this decoding function can, in particular, be implemented by the browser's JavaScript engine JM using the bytecode module BC.

[0119] In this second alternative, the decoding function is executed by the browser's (BRO) JavaScript engine (JM), not directly by the processor of the first terminal 2a, but through a JavaScript engine (JM) emulated by that processor. Because the decoding function is executed in a processor-emulated environment, rather than directly in the processor's native environment, the decoding speed is slower than the first alternative. On the other hand, this second alternative enables the decoding of multimedia streams encoded by codecs not supported by the encoding module (E / D), thus allowing any codec to be used in the conference session.

[0120] In the first option of establishing a communication channel between media server 3 and browser BRO using the WebRTC API, box 140, which sends a multimedia stream from media server 3 to browser BRO, may include box 141. Box 141 may include a data channel (DataChannel) for writing the multimedia stream to the WebRTC API, which is created between media server 3 and browser BRO. As mentioned above, it is precisely writing the multimedia stream to the WebRTC API data channel (DataChannel) that makes it possible to avoid decrypting the multimedia stream at media server 3.

[0121] In the second option of establishing a communication channel between media server 3 and browser BRO using the WebSocket protocol, box 140, which sends a multimedia stream from media server 3 to browser BRO, may include box 142. Box 142 may include writing the multimedia stream to the communication channel established using the WebSocket protocol. The communication channel established using the WebSocket protocol is opened between media server 3 and browser BRO.

[0122] These two alternatives, which include boxes 141 and 142, are particularly... Figure 9 The Chinese side indicated that...

[0123] Now for reference Figure 10 An example configuration of a terminal according to the present invention is described. This terminal is adapted to participate in a conference session managed by a media server 3. It includes a browser (BRO), which may include any elements proposed for a first terminal 2a. A communication channel is established between the media server 3 and the browser (BRO) of the terminal.

[0124] The terminal can be configured to implement at least one of the operations described below, for example, via its processor. Furthermore, the terminal can be configured to implement at least one operation performed by the first terminal 2a, which is implied or explicitly described when referring to any of the example methods 100 of the invention. For the sake of brevity, the operations already described in the various example methods 100 as being performed by the first terminal 2a will not be repeated here.

[0125] This terminal can be configured to establish a communication channel between its browser (BRO) and media server 3. Examples of modules or APIs for establishing such channels have been described in this invention. This operation of establishing a communication channel is... Figure 10 The middle part is represented by box 145.

[0126] The terminal can be configured to perform a first encryption on its captured multimedia streams (e.g., via its microphone 23 or camera 24). The first encryption is performed using a third encryption key associated with the conference session. In the first option of symmetric encryption, the third encryption key may correspond to the encryption key of the conference session. In the second option of asymmetric encryption, the third encryption key may correspond to the terminal's public key. In the latter case, the multimedia stream encrypted with the terminal's public key can be decrypted using the private key associated with the terminal's public key, as described above. This first encryption operation... Figure 10 The middle part is represented by box 210.

[0127] This terminal can be configured to perform a second encryption on a multimedia stream that has already been first encrypted with a third encryption key. The second encryption is performed using an encryption key negotiated between the browser (BRO) on this terminal and the media server (3). It is understood that the negotiated encryption key used here depends on how the communication channel between the browser (BRO) and the media server is established, specifically whether it is established according to the WebSocket protocol or using the WebRTC API. This second encryption operation... Figure 10 The middle part is represented by box 220.

[0128] This terminal can be configured to transmit multimedia streams that are first encrypted using a third encryption key and second encrypted using an encryption key negotiated between the terminal's browser (BRO) and the media server. This transmission of multimedia streams encrypted with two different encryption keys operates within... Figure 10 The middle part is represented by box 230.

[0129] In the first alternative, block 230 for transmitting the double-encrypted multimedia stream may, for example, include writing the double-encrypted multimedia stream into a communication channel connecting the browser and the media server 3, which is opened according to the WebSocket protocol.

[0130] In the second alternative, block 230 for transmitting the double-encrypted multimedia stream may, for example, include writing the double-encrypted multimedia stream into a data channel that connects the browser and the media server 3 to a communication channel created using the WebRTC API.

[0131] Therefore, the example configuration of the terminal according to the invention allows the terminal to send and receive encrypted streams using its browser within a conference session framework, without the media server 3 decrypting these streams. Thus, the terminal configuration according to the invention enables end-to-end encryption of communication applications.

[0132] This patent application also relates to a media server 3 in any configuration proposed according to the present invention. The media server 3 can be configured to implement at least one operation described in the reference example method 100, for example, via its processor 31.

[0133] Therefore, the media server according to the present invention allows end-to-end encryption of multimedia streams exchanged by terminals participating in a conference session under its management, even if these terminals exchange multimedia streams through their browsers.

[0134] This application also relates to a computer program product comprising instructions that, when implemented by a processor, enable the implementation of any configuration of the terminal or media server proposed in this invention.

[0135] Finally, this application relates to a non-transient computer-readable storage medium having a program stored thereon, which, when implemented by a processor, is used to implement any configuration of the terminal or media server proposed in this invention.

[0136] The various examples and configurations described in this patent application may be optionally combined to implement other examples or configurations. Furthermore, the terminology used in the following claims should not be construed as limiting these claims to the specific examples or configurations disclosed in the specification, but should be construed as including all possible examples and configurations as well as any element equivalent to an element indicated in a claim.

Claims

1. A method for exchanging data in an end-to-end encrypted manner between a first terminal and a second terminal, the first terminal and the second terminal participating in a conference session managed by a media server, wherein a communication channel is established between the media server and a browser of the first terminal, and wherein the method comprises: The second terminal performs a first encryption on the multimedia stream using a first encryption key associated with the conference session; The encrypted multimedia stream is sent to the media server by the second terminal; The media server performs a second encryption on the already encrypted multimedia stream using an encryption key negotiated between the browser on the first terminal and the media server for communication on the communication channel; subsequently, The media server sends the multimedia stream to the first terminal.

2. The method according to claim 1, further comprising: The first terminal uses an encryption key negotiated between the browser on the first terminal and the media server to perform a first decryption of the multimedia stream received from the media server. as well as, The first terminal uses a second encryption key to perform a second decryption on the multimedia stream, wherein the second encryption key is capable of decrypting the multimedia stream encrypted by the first encryption key.

3. The method according to claim 2, wherein the second decryption comprises: Load the bytecode file containing the decryption function used to decrypt the data stream; as well as, The decryption function is executed on the multimedia stream.

4. The method according to claim 1, wherein the browser of the first terminal further includes an encoding module, the encoding module allowing the use of multiple codecs to encode or decode the multimedia stream, wherein the method further includes: The second terminal encodes the multimedia stream using the first codec. as well as, When the first codec is one of the plurality of codecs: The multimedia stream is decoded using the browser's encoding module.

5. The method according to claim 4, wherein, When the first codec is not one of the plurality of codecs supported by the encoding module, the method further includes: Load a bytecode file containing decoding functions for decoding a data stream encoded using the first codec; and, The decoding function is executed on the multimedia stream encoded by the first codec.

6. The method according to claim 1, wherein the communication channel between the media server and the browser is established according to the WebSocket protocol; The multimedia stream is sent to the first terminal by the media server through the communication channel established between the media server and the browser of the first terminal, including: The multimedia stream is written to the communication channel established between the media server and the browser.

7. A terminal suitable for connecting to a conference session managed by a media server, the terminal including a browser, wherein the terminal is configured to: The multimedia stream is first encrypted using a third encryption key associated with the conference session; Using an encryption key negotiated between the browser and the media server, a second encryption is performed on the multimedia stream encrypted with the third encryption key to encrypt the multimedia stream exchanged between the media server and the browser. as well as, The encrypted multimedia stream is transmitted to the media server.

8. The terminal according to claim 7, wherein the terminal is further configured to: A multimedia stream is obtained from the media server. This multimedia stream has been first encrypted using a first encryption key from another terminal of the conference, and second encrypted using an encryption key negotiated between the browser and the media server for encrypting the multimedia stream exchanged between the media server and the browser. The multimedia stream received from the media server is first decrypted using the encryption key negotiated between the browser and the media server. as well as, A second encryption key is used to perform a second decryption on the multimedia stream received from the media server, the second encryption key being capable of decrypting the multimedia stream encrypted by the first encryption key.

9. The terminal according to claim 8, wherein applying the second decryption to the multimedia stream comprises: Load the bytecode file containing the decryption function used to decrypt the data stream; as well as, The decryption function is executed on the multimedia stream.

10. A media server configured to manage a conference session involving at least a first terminal and a second terminal, wherein the media server is configured to: Receive, from the second terminal, an encrypted multimedia stream to be sent to other participants in the conference session; and, The encrypted multimedia stream is encrypted using an encryption key negotiated with the browser of the first terminal.

Images