Encryption used in M56 Webrtc

[Raju S N]

Hi,

When I started exploring the security aspects of the RTP,  it was clear that ECDSA is used for certificate generation.

Wanted to explore a bit further and see the encryption used in the engine.

When i browsed through the webrtc code, found the following options in the code.

ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

Which means both AES 128 & 256 are supported in the engine.

My question is what is the default encryption supported ?

And whether we can specify an option - AES 128 / AES 256 for a call in PeerConnection or any other APIs?

Would appreciate any inputs on the same.

Thanks,

Raju

[Christoffer Jansson]

Hi,

in Chrome, you can call upon RTCPeerConnection.generateCertificate(certParams) and specify what type of certificate you want, example here.

/Chris

--

---
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/15ed8d44-ef0e-4203-92be-1648eef1d608%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

/Chris

[Philipp Hancke]

2017-01-20 15:59 GMT+01:00 Raju S N <samudr...@gmail.com>:

Hi,

When I started exploring the security aspects of the RTP,  it was clear that ECDSA is used for certificate generation.

Wanted to explore a bit further and see the encryption used in the engine.

When i browsed through the webrtc code, found the following options in the code.

ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

Which means both AES 128 & 256 are supported in the engine.

That is for the DTLS handshake.

SRTP is using either AES_CM_128_HMAC_SHA1_80 or  AES_CM_128_HMAC_SHA1_32 from RTC 4568.

My question is what is the default encryption supported ?

And whether we can specify an option - AES 128 / AES 256 for a call in PeerConnection or any other APIs?

Would appreciate any inputs on the same.

Thanks,

Raju

--

---
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.

[Warren McDonald]

The ability to access SRTP GCM modes, including 256 AES is under development see https://bugs.chromium.org/p/webrtc/issues/detail?id=5222 

This has been unblocked for certain cases recently and is available via "PeerConnectionFactoryInterface::Options" rtc::CryptoOptions 

This does not seem to be exposed via the JS Web API, so I am not sure how this would be enabled or set as preferred in browsers.

On Tuesday, 24 January 2017 00:40:15 UTC+11, Philipp Hancke wrote:

2017-01-20 15:59 GMT+01:00 Raju S N <samudr...@gmail.com>:

Hi,

When I started exploring the security aspects of the RTP,  it was clear that ECDSA is used for certificate generation.

Wanted to explore a bit further and see the encryption used in the engine.

When i browsed through the webrtc code, found the following options in the code.

ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

Which means both AES 128 & 256 are supported in the engine.

That is for the DTLS handshake.

SRTP is using either AES_CM_128_HMAC_SHA1_80 or  AES_CM_128_HMAC_SHA1_32 from RTC 4568.

My question is what is the default encryption supported ?

And whether we can specify an option - AES 128 / AES 256 for a call in PeerConnection or any other APIs?

Would appreciate any inputs on the same.

Thanks,

Raju

--

---
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.

[Warren McDonald]

Enabling GCM Ciphers for SRTP is now available in Canary 59 under a flag  Negotiation with GCM cipher suites for SRTP in WebRTC  There does not seem to be any control for 128 or 256.

It would be good to know what the behaviour is supposed to be when CGM is enabled. Will it try to negotiate to highest consensus level avail to both endpoints?

Assuming GCM is enabled by default in future, will there be any control over the negotiated level via RTCConstraints 

@juberti is there any documentation coming on this front?

[Warren McDonald]

I have tested this today in Canary 59.0.3056 and can see in webrtc-internals that googcomponent audio shows the SRTP cipher as CGM 256 when a call is negotiated with another Canary browser with the flag enabled on both. Still at standard 128 SHA1 SRTP cipher when negotiating with stable. 

  

So without further changes we know that between Chrome instances will be able to provide AES 256, when GCM becomes enabled by default. 

Initial observations indicate only a relatively small CPU overhead for enabling AES 256 compared to the video processing load. 

Thanks to all who worked on getting this unblocked and out for testing.