Posted: Wed Jun 07, 2006 9:39 pm Post subject: [Asterisk-video] Secure video with srtp
We have a patch for srtp in the bug tracker. This patch assumes that
both streams, audio and video, share the same encryption
properties. Is that always the case? Can we have secure audio and
unsecure video? Different encryption algorithms?
Do they always use the same key?
Posted: Wed Jun 07, 2006 11:02 pm Post subject: [Asterisk-video] Secure video with srtp
Quote:
-----Original Message-----
From: asterisk-video-bounces@lists.digium.com
[mailto:asterisk-video-bounces@lists.digium.com] On Behalf Of
Olle E Johansson
Subject: [Asterisk-video] Secure video with srtp
We have a patch for srtp in the bug tracker. This patch
assumes that both streams, audio and video, share the same
encryption properties. Is that always the case? Can we have
secure audio and unsecure video? Different encryption algorithms?
Do they always use the same key?
Anyone that has looked into this?
/Olle
I checked RFC 3711, the interesting part is probably 3.2.3.
3.2.3. Mapping SRTP Packets to Cryptographic Contexts
Recall that an RTP session for each participant is defined [RFC3550]
by a pair of destination transport addresses (one network address
plus a port pair for RTP and RTCP), and that a multimedia session is
defined as a collection of RTP sessions. For example, a particular
multimedia session could include an audio RTP session, a video RTP
session, and a text RTP session.
A cryptographic context SHALL be uniquely identified by the triplet
context identifier:
context id = <SSRC, destination network address, destination
transport port number>
where the destination network address and the destination transport
port are the ones in the SRTP packet. It is assumed that, when
presented with this information, the key management returns a context
with the information as described in Section 3.2.
As noted above, SRTP and SRTCP by default share the bulk of the
parameters in the cryptographic context. Thus, retrieving the crypto
context parameters for an SRTCP stream in practice may imply a
binding to the correspondent SRTP crypto context. It is up to the
implementation to assure such binding, since the RTCP port may not be
directly deducible from the RTP port only. Alternatively, the key
management may choose to provide separate SRTP- and SRTCP- contexts,
duplicating the common parameters (such as master key(s)). The
latter approach then also enables SRTP and SRTCP to use, e.g.,
distinct transforms, if so desired. Similar considerations arise
when multiple SRTP streams, forming part of one single RTP session,
share keys and other parameters.
If no valid context can be found for a packet corresponding to a
certain context identifier, that packet MUST be discarded.
I'm not 100% sure, but I think it allows different RTP sessions (e.g. audio and video) to share a key, but they don't have to.
Would different encryption algorithms for audio and video bring any benefits?
Can we still consider it a secure call if only one is encrypted?
Posted: Thu Jun 08, 2006 4:37 am Post subject: [Asterisk-video] Secure video with srtp
On Thu, 2006-06-08 at 10:02 +0200, Christian Kr?tzfeldt wrote:
Quote:
> -----Original Message-----
> From: asterisk-video-bounces@lists.digium.com
> [mailto:asterisk-video-bounces@lists.digium.com] On Behalf Of
> Olle E Johansson
> Subject: [Asterisk-video] Secure video with srtp
>
> We have a patch for srtp in the bug tracker. This patch
> assumes that both streams, audio and video, share the same
> encryption properties. Is that always the case? Can we have
> secure audio and unsecure video? Different encryption algorithms?
> Do they always use the same key?
>
> Anyone that has looked into this?
>
> /Olle
I checked RFC 3711, the interesting part is probably 3.2.3.
[...]
I'm not 100% sure, but I think it allows different RTP sessions (e.g. audio and video) to share a key, but they don't have to.
Would different encryption algorithms for audio and video bring any benefits?
Can we still consider it a secure call if only one is encrypted?
The only scenario that I can think of that leaving the video unencrypted
would be if Asterisk was running on a platform that didn't have very
much CPU power (like a wireless router running OpenWRT) and couldn't
keep up with the flow.
I would think that we would want to be prepared for different encryption
parameters for different streams.
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum