Encrypted communications

Abstract

Examples are provided to demonstrate solutions for end-to-end encryption. Figure from the abstract: [Fig. 5]

Description

Title of the invention: Encrypted communications technical field

[0001] This disclosure relates to the field of encrypted communications. Previous technique

[0002] Communication security is an issue in various industrial sectors. In particular, a great deal of information is now exchanged via conference sessions. These sessions are generally real-time and involve multiple participants connected to the conference session via an electronic device. Encrypting communications during these conference sessions can be complex.

[0003] The present disclosure improves this situation. Summary

[0004] In this regard, a method for exchanging end-to-end encrypted data between a first terminal and a second terminal participating in a conference session managed by a media server is proposed, in which a communication channel is established between the media server and a browser of the first terminal, and in which the method comprises: a first encryption, by the second terminal, of a multimedia stream, based on a first encryption key associated with the conference session; a sending, by the second terminal to the media server, of the encrypted multimedia stream; a second encryption, by the media server, of the multimedia stream already encrypted using an encryption key negotiated between the browser of the first terminal and the media server to communicate over the communication channel; then a sending, by the media server to the first terminal, of the multimedia stream.

[0005] Optionally, the method further includes a first decryption, by the first terminal, of the multimedia stream received from the media server, from the encryption key negotiated between the browser of the first terminal and the media server; and a second decryption, by the first terminal, of the multimedia stream from a second encryption key allowing the decryption of a multimedia stream encrypted by the first encryption key.

[0006] Optionally, the second decryption includes: loading a bytecode file containing a function for decrypting a data stream; and an execution of the decryption function on the multimedia stream.

[0007] Optionally, the browser of the first terminal further includes an encoding module for encoding or decoding multimedia streams from a plurality of encoded sources, wherein the method further includes: an encoding, by the second terminal, of the multimedia stream from a first encoded source; and when the first coded value belongs to the plurality of coded values: decoding the multimedia stream from the browser's encoding module.

[0008] Optionally, when the first coded element does not belong to the plurality of coded elements supported by the coding module, the method further comprises: loading a bytecode file containing a function for decoding a data stream encoded from the first encoded file; and an execution of the decoding function on the multimedia stream encoded by the first encoded.

[0009] Optionally, the communication channel between the media server and the browser is established in accordance with a WebSocket protocol; and the sending, by the media server to the first terminal, of the multimedia stream via the communication channel established between the media server and the browser of the first terminal includes: writing the multimedia stream into the communication channel established between the media server and the browser.

[0010] The application also relates to a terminal suitable for connecting to a conference session managed by a media server, the terminal comprising a browser, in which the terminal is configured to: apply a first encryption of a multimedia stream from a third encryption key associated with the conference session; apply a second encryption of the encrypted media stream using the third encryption key, based on an encryption key negotiated between the browser and the media server to encrypt the media streams exchanged between the media server and the browser; and transmit the encrypted multimedia stream to the media server.

[0011] Optionally, the terminal can also be configured to: obtain, from the media server, a multimedia stream encrypted a first time from a first encryption key of another terminal participating in the conference, and encrypted a second time from an encryption key negotiated between the browser and the media server to encrypt the multimedia streams exchanged between the media server and the browser; apply an initial decryption of the multimedia stream received from the media server, using the encryption key negotiated between the browser and the media server; and apply a second decryption of the multimedia stream received from the media server, using a second encryption key to decrypt a multimedia stream encrypted by the first encryption key.

[0012] Optionally, the application of the second decryption of the multimedia stream includes: loading a bytecode file containing a function for decrypting a data stream; and an execution of the decryption function on the multimedia stream.

[0013] The application further relates to a media server configured to manage a conference session in which at least a first terminal and a second terminal participate, in which the media server is configured to: receive, from the second terminal, an encrypted multimedia stream to transmit to the other participants in the conference session; and apply encryption to the already encrypted multimedia stream using an encryption key negotiated with a browser on the first terminal.

[0014] The application further relates to a computer program product comprising instructions for implementing all or part of any of the processes presented in this disclosure when this program is executed by a processor.

[0015] Finally, the application relates to a non-transient computer-readable recording medium on which is recorded a program for the implementation of all or part of any of the processes presented in this disclosure when this program is executed by a processor. Brief description of the drawings

[0016] Other features, details and advantages will become apparent upon reading the detailed description below, and upon analysis of the accompanying drawings, on which:

[0017] [Fig.1] schematically represents an example of communication architecture according to the present disclosure.

[0018] [Fig.2] schematically represents an example of a terminal according to the present disclosure.

[0019] [Fig.3] schematically represents an example of a first terminal according to the present disclosure.

[0020] [Fig.4] schematically represents an example of a media server according to the present disclosure.

[0021] [Fig.5] schematically represents an example of a data exchange process end-to-end encrypted.

[0022] [Fig.6] schematically represents another example of a method for exchanging end-to-end encrypted data.

[0023] [Fig.7] schematically represents yet another example of a method for exchanging end-to-end encrypted data.

[0024] [Fig.8] schematically represents yet another example of a method for exchanging end-to-end encrypted data.

[0025] [Fig.9] schematically represents yet another example of a method for exchanging end-to-end encrypted data.

[0026] [Fig. 10] schematically represents examples of operations that can be implemented by a terminal according to this disclosure. Description of the implementation methods

[0027] The inventor noted that conference sessions allowing the exchange of audio or video data streams could involve participants using the functionalities offered by browsers to process and play back the exchanged data streams. The data stream exchanges in these conference sessions rely on the Real-Time Transport Protocol (RTP), meaning that these data exchanges conform to RFC 3550.

[0028] However, using a browser to exchange data streams with a media server (which is the server that manages the conference session, including redirecting data streams to participants) adds complexity to data exchange because the means of communicating with a browser are limited and subject to standards. Therefore, while using a browser to participate in this type of conference is advantageous, it complicates the transfer of data streams during the conference session. It is particularly advantageous to use a browser because the various browsers available are maintained and regularly updated by their respective developers and offer good performance for processing and reading the real-time data streams exchanged during the conference session.Furthermore, most computers are sold with a browser-type application, so a computer owner does not need to download a dedicated application to participate in a conference session.

[0029] The inventor notably observed that when a first participant in the conference session uses a browser, the conference session does not allow for end-to-end encryption of a data stream sent by a second participant to the first participant. Indeed, the inventor astutely observed that the data stream transmitted by the second participant and encrypted by An encryption key used during the conference session was decrypted by the media server before being 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, as it is decrypted by the media server at some point, then re-encrypted and transmitted over the existing communication channel between the media server and the browser.

[0030] In particular, when the communication channel between the media server and the browser of the first participant uses a WebRTC Application Programming Interface (described in particular in RFC 8835), the specification of the proposed communication channels for communicating audio and / or video streams using the WebRTC API does not allow the transmission of data streams other than RTP-compliant (unencrypted) audio and / or video data streams, which are then encrypted to conform to the protocol via the key negotiated according to the DTLS-SRTP protocol between the media server, acting as a WebRTC client, and the browser.

[0031] This disclosure proposes a solution that enables end-to-end encryption during a conference session, even when a participant uses a browser to join the session, and even when the browser uses the WebRTC API to communicate with the server. Specifically, the solution proposes directly transmitting the encrypted stream with an initial encryption key associated with the conference session via the communication channel between the media server and the browser. This stream is then encrypted once and subsequently re-encrypted using the encryption key negotiated between the media server and the browser.

[0032] The browser will then decrypt this stream twice, where the first decryption will use the key negotiated between the media server and the browser, and the second decryption will use a second key associated with the conference session, as detailed below. In particular, the browser, and more specifically the browser's JavaScript engine, will be able to execute code instructions to perform the second decryption using the second key associated with the conference session, so that the data stream will be end-to-end encrypted between the first and second participants.

[0033] Furthermore, since a function including code instructions for deciphering the data stream has already been developed for participants not using a browser, the solution can also offer to reuse this function, stored in a dedicated file as bytecode, which will be loaded by the browser's JavaScript engine and which can be executed from within the JavaScript engine. Thus, rather than developing a new function in JavaScript to decrypt the data stream, which requires maintaining two different codes, the code is reused and executing such code as bytecode allows for faster execution of the decryption function compared to this function being interpreted and executed from JavaScript instructions.

[0034] An example of a communication architecture 1 in which a conference session enabling the exchange of multimedia data streams can be implemented is now described with reference to [Fig. 1].

[0035] A data stream, or stream, is defined in this disclosure as corresponding to at least two successive data packets. An audio data stream, or audio stream, is defined as corresponding to at least two successive audio data packets. A video data stream, or video stream, is defined as corresponding to at least two successive video data packets.

[0036] In this disclosure, a multimedia stream can correspond to an audio data stream or a video data stream. In audio-video conferences, therefore, both an audio data stream and a video data stream are transmitted, i.e., two multimedia streams of different types.

[0037] The communication architecture 1 comprises a media server 3, a first terminal 2a, and a second terminal 2b. The communication architecture 1 may include more than two terminals 2, and may include as many terminals as there are participants in the conference session. However, the present patent application is limited to a representation of the architecture with two terminals 2, since the solution proposed by this disclosure can be understood simply with two terminals 2.

[0038] The conference session allows for the exchange of multimedia streams between terminals in near real-time. Multimedia streams transmitted by sending terminals during the conference session are sent to the media server 3, which can then distribute them to the receiving terminals participating in the conference session. The media server 3 is sometimes referred to as the "session server" in French or the "media server" in English.

[0039] It should be noted that a terminal emitting a first multimedia stream can, subsequently or simultaneously, be a terminal receiving a second multimedia stream emitted by another emitting terminal participating in the conference session.

[0040] In a first alternative, the conference session can thus refer to an audio conference in which terminals may exchange audio streams in near real time via a media server 3.

[0041] In a second alternative, the conference session may refer to a videoconference in which terminals may exchange video streams in near real time via a media server 3.

[0042] In a third alternative, the conference session may refer to an audio-video conference in which terminals may exchange audio and video streams in near real time via a media server 3.

[0043] It should be noted that in the first or third alternative, the audio streams may, for example, correspond to push-to-talk (PTA) communications. PTA communications, more commonly known as push-to-talk or press-to-transmit, are bidirectional (non-simultaneous) communications based on a user pressing a physical or virtual button to switch from receive mode to transmit mode and vice versa. These communications use half-duplex communication channels.

[0044] A terminal can thus correspond to a fixed or mobile communication device. A communication device is mobile in the sense that it is not connected, either physically via a cable or over a short distance, for example via the use of a Wi-Fi, NFC, or Bluetooth protocol, to a communication network. A mobile communication device, on the other hand, is designed to communicate data over long distances via a telecommunications network, for example, a mobile network, so that it can exchange data while roaming. A mobile communication device could, for example, be a mobile phone.

[0045] During the conference session, the data packets of the multimedia streams transmitted by the terminals are encapsulated according to an internet protocol. This protocol is notably defined in the RFC 791 standard.

[0046] In this disclosure, the data streams exchanged by the terminals during the conference session may be encapsulated according to an SRTP (Secure Real-time Transport Protocol). A data stream encapsulated according to an SRTP protocol should be understood in this application as a data stream arranged to comply with an SRTP protocol, that is, to comply with a protocol defined in particular in RFC 3711.

[0047] A multimedia stream transmitted by a sending terminal during the conference session is also encoded using an encoding code implemented by the sending terminal. Depending on the type of data in the multimedia stream, audio or video, the encoding codes are different.

[0048] In examples, an audio encoding codec may correspond to one of the following: GSM, iLBC, Speex, AMR-WB, EVS, OPUS. In examples, a video encoding codec may correspond to one of the following: VP8, VP9, ​​AVI, H264.

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

[0050] The memory 22 can store code instructions executed by the processor 21. The memory 22 may, for example, comprise ROM (Read-Only Memory), RAM (Random Access Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), or any other suitable type of storage medium. The memory may, for example, include optical, electronic, or magnetic storage media.

[0051] A terminal 2 may also include a microphone 23 for acquiring an audio stream.

[0052] A terminal 2 may also include a camera 24 for acquiring a video stream.

[0053] An example of terminal 2 comprising a processor 21, a memory 22, a microphone 23 and a camera 24 is illustrated in particular in [Fig.2].

[0054] An example of a first terminal 2a is shown in [Fig.3]. In this example, terminal 2a includes a BRO browser.

[0055] A BRO browser, also referred to as a "browser" in English, is a software unit designed to access and display the World Wide Web, notably through the interpretation and execution of code instructions in the JavaScript language. A BRO browser is thus software that implements HTTP (Hypertext Transfer Protocol) requests to connect to HTTP servers (web servers). BRO browsers are, for example, those commonly used by the general public. A BRO browser may include several modules developed by various publishers, which will be detailed later. Consequently, by using an existing BRO browser, it becomes unnecessary to develop and maintain modules already provided by the browser.

[0056] A software unit can, in particular, be implemented by the processor 21 of a terminal. Therefore, the BRO browser can be implemented by the processor 21 of the first terminal 2a.

[0057] The BRO browser includes a JM JavaScript engine, which designates the software unit enabling the interpretation and execution of code instructions in JavaScript language in order to execute the various functions and modules of the BRO browser.

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

[0059] In a first alternative, the COM communication module may, for example, include a WebRTC API. The media server 3 may then also include a WebRTC API to communicate with the corresponding WebRTC API of the first terminal 2a. In this first alternative, an encryption key for encrypting the exchanges on the communication channel is negotiated between the media server 3 and the BRO browser of the first terminal 2a according to a DTLS-SRTP (Datagram Transport Layer Security-Secure Real Time Protocol) protocol, notably defined by RFC 5764. It should be noted that the multimedia data streams are exchanged via a data channel ("Datachannel" in the WebRTC API specification) of the WebRTC API, and not via the function defined for transmitting multimedia streams according to the WebRTC API specification.Indeed, the WebRTC API specification defines a function for transmitting multimedia streams, but this function does not allow the transmission of already encrypted multimedia streams. The inventor therefore cleverly repurposed the WebRTC API to transmit encrypted multimedia streams via a specific communication channel, called a Datachannel in the WebRTC API, instead of the function defined by the WebRTC API for transmitting these multimedia streams. Since this function does not allow the transmission of already encrypted streams, it requires decrypting the stream before retransmission, and therefore does not allow end-to-end encryption.

[0060] In a second alternative, the COM communication module may, for example, include a WebSocket module enabling communication with the media server 3 in accordance with the WebSocket protocol. The WebSocket protocol is defined in particular in RFC 6455. In this second alternative, an encryption key is used to encrypt the exchanges on the channel Communication is negotiated between the media server 3 and the BRO browser of the first terminal 2a using the TLS (Transport Layer Security) protocol, specifically defined by RFC 8446 version 1.3 (other versions are, of course, possible). The communication channel created according to the WebSocket protocol allows the exchange of encrypted multimedia streams without having to decrypt them before re-encrypting them using the key negotiated according to the TLS protocol. It should be noted that using the WebSocket protocol to transmit multimedia streams from a conference session, which must be transmitted in near real-time, is an ingenious use of this protocol, which was not originally intended for this type of communication.Indeed, the WebSocket protocol is configured to exchange data packets according to the TCP (Transmission Control Protocol, defined in RFC 793), which is not the preferred protocol for exchanging SRTP data packets. More specifically, data transmission using the UDP (User Datagram Protocol) has lower latency than TCP and does not interrupt the data flow in case of packet loss, unlike TCP, so TCP is not chosen for real-time communications. Therefore, this second alternative cleverly uses the WebSocket protocol to transmit SRTP data packets using TCP.

[0061] In examples, the BRO browser may include an I / D encoding module, which is a software unit for encoding or decoding multimedia streams. More specifically, the I / D encoding module is configured to allow the encoding and decoding of a data stream from a plurality of encodings supported by the I / D module. An I / D encoding module for the BRO browser may, for example, correspond to a WebCodecs API. The WebCodecs API is a standard proposed by the World Wide Web Consortium (W3C) that enables the decoding and encoding of multimedia streams via a browser.

[0062] In examples, the BRO browser may include a multimedia stream LEC playback module. The LEC playback module is a software unit that can, in particular, read a decoded multimedia data stream. The multimedia data stream may, for example, be decoded by the I / D coding module and then provided to the LEC playback module for playback. The LEC module may, in particular, include an audio stream playback module and / or a video stream playback module, depending on the nature of the conference session. The audio stream LEC playback module may, for example, include a WebAudio API that allows playback of an audio stream formatted, in particular, according to pulse code modulation (PCM).

[0063] In examples, the BRO browser may also include a BC bytecode module. A BC bytecode module can be a software unit that allows the JM JavaScript engine to load and use functions contained in a bytecode file. In this respect, the BC bytecode module may be implemented directly in the JM JavaScript engine, or it may be a separate module from the JM JavaScript engine that can be used by the JM JavaScript engine, as shown in [Fig. 3].

[0064] A bytecode file is a file containing data represented in bytecode, that is, data in an intermediate format between source code, written by a developer or an intelligent model, and machine code, executed by a processor. Bytecode is sometimes referred to as "intermediate code" or "octet code" in technical literature. Thus, a bytecode file can, in particular, be a file containing already compiled code instructions.

[0065] A bytecode file can therefore include one or more functions, including a function library, which, once imported by the JavaScript engine using the BC bytecode module, can be used by the JM JavaScript engine. The advantage of the BC bytecode module is that it allows the use of functions coded in programming languages ​​other than JavaScript, precompiled and stored in a bytecode file, so that when these functions are executed by the JavaScript engine, they are executed more quickly. Furthermore, as mentioned previously, this also avoids maintaining functions designed to do the same thing in several different programming languages.

[0066] In these examples, the BC bytecode module may include a module enabling the JM JavaScript engine to load and use functions contained in a WebAssembly file. A WebAssembly file has a file extension of the form ".wasm". WebAssembly is a standard proposed by the World Wide Web Consortium. It should be noted that the BC bytecode module may, of course, include other modules enabling the JM JavaScript engine to load and use functions contained in bytecode file types other than WebAssembly.

[0067] The first terminal 2a can thus store a bytecode file, for example in its memory 22, comprising a function for decrypting a multimedia stream. The decryption function can, in particular, decrypt the multimedia stream using an encryption key associated with the conference session. The stored bytecode file can, for example, be a WebAssembly file.

[0068] Where reference is made in this disclosure to an encryption key associated with the conference session, at least two different options can be considered for accessing that encryption key.

[0069] In a first option, the same encryption key is shared by all terminals participating in the conference session. In this case, a sending terminal encrypts a multimedia data stream that it transmits using this encryption key, and a receiving terminal decrypts a multimedia data stream that it receives using this key. In this first option, the encryption of the conference session data streams is symmetrical.

[0070] In a second option, a specific terminal participating in the conference session obtains a public encryption key with which it encrypts the data streams it transmits. Furthermore, each of the other terminals participating in the conference session (i.e., the terminals other than the specific terminal) obtains a private encryption key (or information enabling the recovery of the private encryption key), associated with the public encryption key of the specific terminal, and enabling the decryption of data streams transmitted by the specific terminal that are encrypted using the public key. Consequently, each terminal in the conference session stores a public key and at least one private key (in practice, a plurality of private keys), where each private key is associated with a public key of another terminal participating in the conference session.Thus, a given terminal in the conference session can decrypt, using the private key associated with the public key of another terminal in the conference session, the data streams transmitted by that other terminal. In this second option, the encryption of the conference session's data streams is asymmetric.

[0071] Encryption keys, whether for symmetric or asymmetric encryption, can be transmitted to the conference session terminals by the media server 3, or by a key management server, also known as a Key Management System (KMS). When a private key is not transmitted directly to a terminal, information enabling the determination of this private key at the terminal level can be transmitted by the media server 3 or the key management server (KMS).

[0072] In some examples, the bytecode file containing the decryption function may also include a function for decoding a multimedia stream encoded from a first encoded version, and possibly from other encoded versions. In other examples, terminal 2a stores another bytecode file containing the function for decoding a multimedia stream encoded from the first encoded version, and possibly from other encoded versions. The first encoded version may, in particular, correspond to an AMR-WB, EVS, or OPUS encoded version. The decoding function allows, for example, decoding A multimedia stream encoded with a specific bytecode allows access to an audio stream, enabling playback by an audio player, particularly the LEC player. The bytecode decoding function can thus decode audio data streams encoded with bytes that are not supported by the browser's C / D module.

[0073] A media server 3 may include a processor 31 and a memory 32. An example of a media server 3 including a processor 31 and a memory 32 is illustrated in particular in [Fig. 4]. The processor 31 may be adapted to implement functions implemented by the media server 3 in this disclosure. The processor 31 may, for example, be a microprocessor. The processor 31 may, in particular, be a component of an integrated circuit, in particular a component of a microcontroller, a component of a Field-Programmable Gate Array (FPGA), or a component of an Application-Specific Integrated Circuit (ASIC).

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

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

[0076] Examples of a method for exchanging end-to-end encrypted data between the first terminal 2a and the second terminal 2b participating in a conference session managed by the media server 3 are now described with reference to Figures 5 to 9. As explained previously, the media server 3 transmits multimedia data streams to the conference session participants in real time. Furthermore, a communication channel is established between the media server 3 and the BRO browser of the first terminal 2a. The conditions for establishing this communication channel have also been described previously.

[0077] It should be noted that the figures associated with the process examples 100 are merely illustrations of the process examples 100, representing, by means of blocks, the various operations possibly included in the process and described later in this document. As such, the illustrations do not convey any sequence between the operations. In other words, the operations described with reference to the figures These operations are not necessarily performed sequentially and may, in particular, be performed in a different order than shown in the figures, or be performed in parallel, unless a given operation requires the result of another operation to be performed. Similarly, it is not necessary for each operation to be performed once before the same operation is repeated a second time. The frequency of each operation's execution is independent and is not necessarily linked to the execution of other operations.

[0078] As illustrated by block 110, method example 100 includes a first encryption of a multimedia stream to be transmitted to the participants of the conference session. The first encryption 110 is performed by the second terminal 2b, for example by its processor, using a first encryption key associated with the conference session. The conditions for obtaining an encryption key associated with the conference session have been described previously.

[0079] As illustrated by block 120, method example 100 includes sending the encrypted multimedia stream to the media server 3. The sending is performed by the second terminal 2b, and can, for example, be implemented by its processor. Consequently, the media server 3 receives the multimedia stream encrypted with the first encryption key associated with the conference session of the second terminal 2b.

[0080] As illustrated by block 130, method example 100 includes a second encryption of the already encrypted multimedia stream. The second encryption is performed by the media server 3, for example by its processor 31, using an encryption key negotiated between the BRO browser of the first terminal 2a and the media server 3 for communication over the communication channel. Details of the encryption key negotiated between the BRO browser of the first terminal 2a and the media server 3 have been described previously. It is therefore understood that at the end of block 130, the multimedia stream transmitted by the second terminal 2b is encrypted by two different encryption keys: the first encryption key associated with the conference session, and the encryption key negotiated between the media server 3 and the BRO browser of the first terminal 2a.

[0081] As illustrated by block 130, method example 100 includes sending the multimedia stream to the first terminal 2a. The multimedia stream is sent by the media server 3, for example following a command from its processor 31, and corresponds to the multimedia stream encrypted twice by the two encryption keys. The twice-encrypted multimedia stream is sent over the communication channel established between the media server 3 and the BRO browser of the first terminal 2a.

[0082] Thus, method 100 according to this disclosure allows the sending of an end-to-end encrypted multimedia stream between a first terminal 2a participating in the session a conference via its browser, and a second terminal 2b also participating in the conference session. The multimedia stream is not decrypted at the media server 3 before being retransmitted over the communication channel established between the media server 3 and the browser of the first terminal 2a.

[0083] In examples and as illustrated by block 150, the process 100 may further include a first decryption of the multimedia stream received from the media server 3. The first decryption is carried out by the first terminal 2a, for example by its processor, from the encryption key negotiated between its browser BRO and the media server 3.

[0084] In examples and as illustrated by block 160, the process 100 can further include a second decryption of the multimedia stream already decrypted once in block 150. The second decryption is carried out by the first terminal 2a, for example by its processor, from a second encryption key allowing the decryption of a multimedia stream encrypted by the first encryption key.

[0085] In a first option where the encryption is symmetric, the second encryption key can correspond to the first encryption key. In a second option where the encryption is asymmetric, the first encryption key can correspond to the public key of the second terminal 2b, and the second encryption key can correspond to the private key associated with the public key of the second terminal 2b.

[0086] Examples of process 100 including the first and second decryption are illustrated in particular in [Fig.6].

[0087] In some examples, the second decryption block 160 may include a block 161 and a block 162. These examples are illustrated in particular in [Fig.7].

[0088] Block 161 may correspond to the loading of a bytecode file containing a function for decrypting a data stream. This loading may, in particular, be performed by the JavaScript engine JM of the BRO browser on the first terminal 2a from the BC bytecode module. The bytecode file may, in particular, be a WebAssembly file, as explained previously.

[0089] Block 162 may correspond to an execution of the decryption function on the multimedia stream that has already been decrypted once. The execution of the decryption function may, in particular, be carried out by the JavaScript engine JM of the BRO browser on the first terminal 2a using the bytecode module BC. The decryption function for the data stream of the bytecode file can thus rely on the second encryption key to decrypt a multimedia stream encrypted with the first encryption key.

[0090] In some examples, the process 100 may further include encoding the multimedia stream from the first encoded step. This encoding is represented by block 105 in [Fig. 8]. The encoding is performed by the second terminal 2b, specifically before the first encryption proposed by block 110. Consequently, when the multimedia stream is received by the first terminal 2a, it is encoded by the first encoded step in addition to being encrypted with two different encryption keys.

[0091] In examples including block 105 and in a first alternative where the first encoded string belongs to the plurality of encoded strings supported by the BRO browser's I / D encoding module of the first terminal 2a, method 100 may further include decoding the multimedia stream from the BRO browser's encoding module. The decoding is illustrated by block 170 in [Fig. 8]. This first alternative enables decoding via the BRO browser's E / D decoding module, which runs faster than the decoding in the second alternative shown below, since it can be performed directly in the native processor environment of the first terminal 2a. In contrast, the browser's E / D decoding module is limited to a certain number of encoded strings and, in particular, does not support widely used encoded strings such as AMR-WB.

[0092] In examples including block 105 and in a second alternative where the first coded does not belong to the plurality of coded supported by the I / D coding module of the BRO browser of the first terminal 2a, the method 100 may further include a block 180 and a block 181, as illustrated in [Fig.8].

[0093] Block 180 can correspond to the loading of a bytecode file containing a function for decoding a data stream encoded from the first encoded stream. The bytecode file can be a WebAssembly file. The bytecode file can be the same as the one containing the decryption function that is loaded in block 161, or it can be a different file. When it is the same file, it is not necessary to load it twice. The loading of the bytecode file can, in particular, be performed by the JavaScript engine JM of the BRO browser of the first terminal 2a from the bytecode module BC.

[0094] Block 181 may correspond to an execution of the decoding function of the multimedia stream encoded by the first encoded and loaded during block 180. The execution of the decoding function may in particular be implemented by the JavaScript engine JM of the BRO browser of the first terminal 2a from the bytecode module BC.

[0095] In this second alternative, since the decoding function is executed by the BRO browser's JavaScript JM engine, this function is not executed directly by the processor of the first terminal 2a, but is executed via the JavaScript JM engine that is simulated by this processor. Since the execution of the decoding function is implemented in a Because the environment is simulated by the processor, rather than directly in the processor's native environment, decoding is not performed as quickly as in the first alternative. However, this second alternative allows decoding multimedia streams encoded with codes not supported by the I / D encoding module, so any encoding can be used for the conference session.

[0096] In a first option in which the communication channel between the media server 3 and the BRO browser is established using a WebRTC API, block 140, which sends the multimedia stream from the media server 3 to the BRO browser of the first terminal 2a, may include a block 141. Block 141 may include writing the multimedia stream to a WebRTC API DataChannel created between the media server 3 and the BRO browser. As explained previously, it is writing the multimedia stream to a WebRTC API DataChannel that avoids decrypting the multimedia stream at the media server 3 level.

[0097] In a second option in which the communication channel between the media server 3 and the BRO browser is established using a WebSocket protocol, block 140, which sends the multimedia stream from the media server 3 to the BRO browser of the first terminal 2a, may include a block 142. Block 142 may include writing the multimedia stream to the communication channel established according to the WebSocket protocol. The communication channel established according to the WebSocket protocol is open between the media server 3 and the BRO browser of the first terminal.

[0098] These two alternatives comprising blocks 141 and 142 are notably represented in [Fig.9].

[0099] Examples of terminal configurations according to this disclosure are now presented with reference to [Fig. 10]. The terminal is adapted to participate in a conference session managed by a media server 3. It includes a BRO browser that can include any of the elements presented for the first terminal 2a. A communication channel is established between the media server 3 and the terminal's BRO browser.

[0100] The terminal can be configured to implement at least one of the operations shown below, for example, through its processor. Furthermore, the terminal can be configured to implement at least one operation performed by the first terminal 2a and described implicitly or explicitly with reference to any of the process examples 100 in this disclosure. For the sake of brevity, the operations already described as being performed by the first terminal 2a in the various process examples 100 are not described again here.

[0101] The terminal can be configured to establish a communication channel between its BRO browser and the media server 3. Examples of modules or APIs for establishing such a channel have been described in this disclosure. This operation of establishing a communication channel is represented by block 145 in [Fig. 10].

[0102] The terminal can be configured to perform initial encryption of a multimedia stream it has acquired, for example, via its microphone 23 or camera 24. This initial encryption is performed using a third encryption key associated with the conference session. In the first option, where the encryption is symmetric, the third encryption key can be the encryption key of the conference session. In the second option, where the encryption is asymmetric, the third encryption key can be the terminal's public key. In this 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 explained previously. This initial encryption operation is represented by block 210 in [Fig. 10].

[0103] The terminal can be configured to perform a second encryption of the media stream already encrypted once by the third encryption key. The second encryption is performed using an encryption key negotiated between the terminal's BRO browser and the media server 3. It is understood that the negotiated encryption key used here depends on how the communication channel between the BRO browser and the media server is established, in particular whether it is a communication channel established using the WebSocket protocol, or using the WebRTC API. This second encryption operation is represented by block 220 in [Fig. 10].

[0104] The terminal can be configured to transmit an encrypted multimedia stream a first time using the third encryption key and a second time using the encryption key negotiated between the terminal's BRO browser and the media server. This operation of transmitting the multimedia stream encrypted by two different encryption keys is represented by block 230 in [Fig. 10].

[0105] In a first alternative, block 230 of transmission of the twice-encrypted multimedia stream may for example include a writing of the twice-encrypted multimedia stream into the communication channel linking its browser and the media server 3 opened in accordance with the WebSocket protocol.

[0106] In a second alternative, block 230 of transmission of the twice-encrypted multimedia stream may for example include a writing of the twice-encrypted multimedia stream into a data channel of the communication channel linking its browser and the media server 3 created from the WebRTC API.

[0107] The terminal configuration examples according to this disclosure therefore allow the terminal to send and receive encrypted streams from its browser within the context of a conference session without these streams being decrypted by the media server 3. Thus, the terminal configurations according to this disclosure allow end-to-end encryption of communications to be applied.

[0108] The patent application further relates to a media server 3 according to any one of the configurations shown in this disclosure. The media server 3 can be configured to implement at least one of the operations shown with reference to the process examples 100, for example through its processor 31.

[0109] Thus, the media server according to this disclosure makes it possible to offer end-to-end encryption of multimedia streams exchanged by the terminals participating in the conference session that it manages, even if terminals exchange multimedia streams via their browser.

[0110] The application further relates to a computer program product comprising instructions for implementing any of the terminal or media server configurations presented in this disclosure when that configuration is implemented by a processor.

[0111] Finally, the application relates to a non-transient computer-readable recording medium on which is recorded a program for the implementation of any of the terminal or media server configurations presented in this disclosure when that configuration is implemented by a processor.

[0112] The various examples and configurations described in this patent application may optionally be combined to produce further examples or configurations. Furthermore, in the following claims, the terms used shall not be interpreted as limiting these claims to the specific examples or configurations disclosed in the description, but shall be interpreted as including all possible examples and configurations, as well as any element equivalent to an element indicated in the claims.

Claims

Demands

1. A method (100) for exchanging end-to-end encrypted data between a first terminal (2a) and a second terminal (2b) participating in a conference session managed by a media server (3), wherein a communication channel is established between the media server (3) and a browser (BRO) of the first terminal (2a), and wherein the method comprises: a first encryption (110), by the second terminal (2b), of a multimedia stream, using a first encryption key associated with the conference session; a sending (120), by the second terminal (2b) to the media server (3), of the encrypted multimedia stream; a second encryption (130), by the media server (3), of the already encrypted multimedia stream using an encryption key negotiated between the browser (BRO) of the first terminal (2a) and the media server (3) to communicate over the communication channel;then a transmission (140), by the media server (3) to the first terminal (2a), of the multimedia stream.;

2. A method according to the preceding claim, further comprising: a first decryption (150), by the first terminal (2a), of the multimedia stream received from the media server (3), from the encryption key negotiated between the browser (BRO) of the first terminal (2a) and the media server (3); and a second decryption (160), by the first terminal (2a), of the multimedia stream from a second encryption key enabling the decryption of a multimedia stream encrypted by the first encryption key.

3. A method according to the preceding claim, wherein the second decryption (160) comprises: a loading (161) of a bytecode file comprising a function for decrypting a data stream; and an execution (162) of the decryption function on the multimedia stream.

4. A method according to any one of the preceding claims, wherein the browser (BRO) of the first terminal (2a) further comprises an encoding module (E / D) for encoding or decoding multimedia streams from a plurality of encoded, wherein the method further comprises: an encoding (105), by the second terminal (2b), of the multimedia stream from a first encoded; and when the first encoded belongs to the plurality of encoded: a decoding (170) of the multimedia stream from the browser's encoding module (E / D) (BRO).

5. A method according to the preceding claim, wherein when the first coded does not belong to the plurality of coded supported by the encoding module (E / D), the method further comprises: a loading (180) of a bytecode file comprising a function for decoding a data stream encoded from the first coded; and an execution (181) of the decoding function on the multimedia stream encoded by the first coded.

6. A method according to any one of the preceding claims, wherein the communication channel between the media server (3) and the browser (BRO) is established in accordance with a WebSocket protocol; wherein a transmission (140), by the media server (3) to the first terminal (2a), of the multimedia stream via the communication channel established between the media server (3) and the browser (BRO) of the first terminal comprises: a writing of the multimedia stream into the communication channel established between the media server (3) and the browser (BRO).

7. Terminal (2a) adapted to connect to a conference session managed by a media server (3), the terminal (2a) comprising a browser (BRO), wherein the terminal is configured to: apply a first encryption (210) of a multimedia stream from a third encryption key associated with the conference session; apply a second encryption (220) of the multimedia stream encrypted from the third encryption key, from an encryption key negotiated between the browser (BRO) and the media server (3) to encrypt the multimedia streams exchanged between the media server (3) and the browser (BRO); and transmit (230) the encrypted multimedia stream to the media server (3).

8. Terminal according to the preceding claim, wherein the terminal is also configured to: obtain (145), from the media server (3), a multimedia stream encrypted a first time from a first encryption key of another terminal participating in the conference, and encrypted a second time from an encryption key negotiated between the browser (BRO) and the media server (3) to encrypt the multimedia streams exchanged between the media server (3) and the browser (BRO); apply a first decryption (150) of the multimedia stream received from the media server (3), from the encryption key negotiated between the browser (BRO) and the media server (3); and apply a second decryption (160) of the multimedia stream received from the media server (3), from a second encryption key enabling the decryption of a multimedia stream encrypted by the first encryption key.

9. Terminal (2a) according to claim 8, wherein the application of the second decryption (160) of the multimedia stream comprises: a loading (161) of a bytecode file comprising a function for decrypting a data stream; and an execution (162) of the decryption function on the multimedia stream.

10. Media server (3), configured to manage a conference session in which at least a first terminal (2a) and a second terminal (2b) participate, wherein the media server (3) is configured to: receive, from the second terminal (2b), an encrypted multimedia stream to transmit to the other participants in the conference session; and apply encryption (130) to the already encrypted multimedia stream using an encryption key negotiated with a browser (BRO) of the first terminal (2a).

Images