0

During a WebRTC call, an offerer and an answerer share offer & answer SDPs to each other respectively.
I suppose that the peers will be using some information (like fingerprint etc.) from their respective SDPs to encrypt the data, so that the other peer can decrypt and consume the media stream.

Is it like: offerer has those encrypt-decrypt info in the "offer SDP" and answerer shares in the "answer SDP"?

The purpose for this is to try out a possible implementation for an Selective Forwarding Unit (SFU), where a user uploads a stream only once. Now their offer SDP is stored somewhere in the server along with few initial signalling bytes. Whichever peer wants consume that stream, would be shared the same offer and it should work, because the encrypt-decrypt key would be part of the offer SDP.

This question is related to an effort to find out a possible solution for:
Is there any alternative approach to implement WebRTC SFU, to have only 1 upload stream?

iammilind
  • 68,093
  • 33
  • 169
  • 336

2 Answers2

4

Encryption in WebRTC is done using DTLS (or DTLS-SRTP). This means the encryption keys (for both directions) are negotiated between the peers with the first few UDP packets of the connection.

This encryption is using a self-signed certificate whose fingerprint you can find in the a=fingerprint: line of the SDP and is validated against this.

When forwarding media packets to another client, the SFU therefore needs to decrypt and reencrypt.

Philipp Hancke
  • 15,855
  • 2
  • 23
  • 31
  • Thanks. Let's say A & B got connected. A is sharing media, while B is muted. Server *stores* A's very first few thousand bytes. Now C gets into the picture as a listener like B. We first send C the *stored* A's bytes. Then we send the A's ongoing live stream bytes meant for B. Is this possible? – iammilind Dec 25 '20 at 11:51
  • that isn't how it is typically done. When C joins, the SFU requests a keyframe from A and can then decode any subsequent video frame. – Philipp Hancke Dec 25 '20 at 11:54
  • Our intention is the avoid multiple uploads from "A" and at the same time want to avoid the SFU altogether, where 1 level of extra decrypt & re-encrypt happens. Yes, whatever I wrote above is not something done typically. But my question is that, is it possible in theory? Are we breaking any WebRTC requirements? – iammilind Dec 25 '20 at 13:29
0

All WebRTC traffic (media tracks, data channels) is authentified and encrypted using keys that were negotiated during the SDP exchange (offer/answer). The exchagne is invulnerable to eavesdropping: if an attacker is able to receive a copy of the offer/answer exchange, they won't be able to intercept the WebRTC traffic. On the other hand, the exchange is vulnerable to man-in-the-middle attacks: if an attacker is able to modify the offer/answer exchange, they might be able to eavesdrop and spoof the media traffic.

Therefore, the offer/answer exchange does not need to be encrypted, but it does need to be authentified. The most common way to perform the exchange is to use a channel protected by TLS (for example https or a WebSocket over TLS), but this does not necessarily authentify a client. If more security is desired, other solutions are possible; for example, it is easy enough to use the crypto.subtle API to authentify the SDP using a shared key.

jch
  • 5,382
  • 22
  • 41
  • Sorry, I am unable to derive useful info from your answer :-). Does offerer encrypts media data based on offer SDP or answer SDP? – iammilind Dec 27 '20 at 13:10