Encrypt media with custom algorithm like ZRTP

[Kamyar Ghajar]

Hey,

I have a project running about secure end to end call with specified custom encryption algorithm, so I've decided to use webrtc to support this feature in my app (native on ios & android and electron-atom with chromium for desktop). I know that the default encryption in webrtc is using DTLS-SRTP, but I must use another extra encryption algorithm for media (not the data channel) for additional security purposes like ZRTP. Is there a way to do so over webrtc before giving the media streams to the webrtc library, without changing the webrtc build?

I don’t need to disable the default encryption procedure in webrtc, but I must setup a custom encryption method even as an extra encryption to satisfy the project’s essentials.

If I should change the webrtc build, is there an article or documentation showing the proper way to do so?

[Alexandre GOUAILLARD]

On Sat, Jan 28, 2017 at 5:04 PM, Kamyar Ghajar <k.gh...@gmail.com> wrote:

Hey,

I have a project running about secure end to end call with specified custom encryption algorithm, so I've decided to use webrtc to support this feature in my app (native on ios & android and electron-atom with chromium for desktop). I know that the default encryption in webrtc is using DTLS-SRTP, but I must use another extra encryption algorithm for media (not the data channel) for additional security purposes like ZRTP. Is there a way to do so over webrtc before giving the media streams to the webrtc library, without changing the webrtc build?

No.

 

I don’t need to disable the default encryption procedure in webrtc, but I must setup a custom encryption method even as an extra encryption to satisfy the project’s essentials.

If I should change the webrtc build, is there an article or documentation showing the proper way to do so?

No, 

... but you can always look at webrtc/pc/channel.cc and search for ProtectRtp() to see how the encryption is done at the channel layer before pushing it down to the transport layer.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8323f0a1-e402-440c-96b9-b93bf21958eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

President - CoSMo Software Consulting, Singapore

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

• 
  

[Kamyar Ghajar]

Thanks Alexandre, I will look into it...but what is this then: https://tools.ietf.org/html/draft-johnston-rtcweb-zrtp-02

I've read it and it says ZRTP ca be use on the data channel of webrtc to detect MiTM attacks.

On Monday, January 30, 2017 at 4:11:29 PM UTC+3:30, Alexandre GOUAILLARD wrote:

On Sat, Jan 28, 2017 at 5:04 PM, Kamyar Ghajar <k.gh...@gmail.com> wrote:

Hey,

I have a project running about secure end to end call with specified custom encryption algorithm, so I've decided to use webrtc to support this feature in my app (native on ios & android and electron-atom with chromium for desktop). I know that the default encryption in webrtc is using DTLS-SRTP, but I must use another extra encryption algorithm for media (not the data channel) for additional security purposes like ZRTP. Is there a way to do so over webrtc before giving the media streams to the webrtc library, without changing the webrtc build?

No.

 

I don’t need to disable the default encryption procedure in webrtc, but I must setup a custom encryption method even as an extra encryption to satisfy the project’s essentials.

If I should change the webrtc build, is there an article or documentation showing the proper way to do so?

No, 

... but you can always look at webrtc/pc/channel.cc and search for ProtectRtp() to see how the encryption is done at the channel layer before pushing it down to the transport layer.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8323f0a1-e402-440c-96b9-b93bf21958eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexandre GOUAILLARD]

they key part of the document is:

"Intended status: Informational"

It is not implemented, and it s up to you to use it if you want to. You can try to contact the author for details.

In general, getting the certificate on one side, sending them over to the remote peer through the signalling path, and then checking that those are indeed the certificates that were used for the inbound media on the remote peer should be enough to check against such attacks. it only works if you're using webrtc in a p2p configuration (with or without turn server), and will not work if there is a media server on the media path between the peers, since most media server terminate the encryption anyway.

HTH.

Alex. 

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/1d4df162-00f1-468b-90f4-04d01efc1025%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Andrei Pachtarou]

Hi

I'm researching now the same problem

"add additional secure layer to to standard webrtc implementation"

Maybe can give me advice or helpful links.

[Andrei Pachtarou]

Hi

I'm researching now the same problem

"add additional secure layer to to standard webrtc implementation"

Maybe can give me advice or helpful links.

Thank you!

On Monday, January 30, 2017 at 2:18:03 PM UTC+3, Kamyar Ghajar wrote: