Encryption

Hi

I want to start looking at encryption using OpenH323 and I
am wondering 
if the good people on this list perhaps can help me a bit.
My 
application uses its own data-transport, i.e. I only use
OpenH323 for 
signaling. I also have the encryption up and running
(AES-128).

My problem is how I do the signaling first tell the other
side that I am 
capable of encryption and secondly how I can decide on the
shared key to 
be used for encryption.

I have really tried Googling this, but without any success.

Anybody out there that can help me?

A huge thanks in advance!

-Peter
------------------------------------------------------------
------------
Check the FAQ before asking! - http://www.
openh323.org/~openh323/fom.cgi
The OpenH323 Project mailing list, using Mailman. To
unsubscribe or
change your subscription options, goto
htt
p://www.openh323.org/mailman/listinfo/openh323
Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
------------------------------------------------------------
------------

Peter

Opal now supports TLS transport.
There really is no easy way to detect whether the remote
supports the 
proposed transport security proposal.
You might want to also look at DNS SRV (H323 Annex O) record
lookups to 
detect the remote TLS port (SIP uses this)

You may want to also read the draft standard H460.spn from
here.
h
ttp://www.packetizer.com/voip/h323/doc_status.html
OpenH323 now fully supports H460.  Opal has partial support.

Remember each "hop" EP->GK->EP must have TLS
support (or force call 
signalling not to GK route and go end to end then you have
problems with 
NATs/proxies)

The two "official" preferred methods of doing key
exchange is MiKey 
(H235.7) and sdescriptions (H235.8)  with SRTP
ht
tp://www.packetizer.com/voip/h323/standards.html

Now that's the official way it is suppose to be done and I
have experience 
with similar key exchange mechanisms (particularly H235.6)
and can tell you 
from experience that there is a lot of interoperability
problems especially 
with some popular brands of gateways. All these standards
rely on the fact 
that the key exchange is done in the H.245 OLC and each
capability sent on 
the wire contains a duplicate set of key material so for 50
capabilities 50 
copies of the same key material  (I really hope they fixed
that with recent 
standards). Most gateways cannot handle huge or different
H.245 messages 
and will just reject the message outright.

I am not a proponent of either TLS or SRTP simple because of
major inter 
operability issues discussed above.

How I would do it is to use the caller authentication
support in OpenH323 
and create a H.235 cryptoToken (see H.235.1&2) with the
key material in it 
and add it to the setup & callproceed or connect
messages to do the 
exchange. The H235Authenticator class is factory loaded so
it should be 
relatively easy to create your own H235Authenticator and add
it to your 
project. I would also look at shared secret encryption to
protect the key 
material from being snoped. I would not use TLS as it's not
very 
interoperable.  Having the key material in the H.225 call
signalling is far 
more usable as almost every H.323 device will accept it so
you device will 
be able to talk unsecure to all other devices (EP/GK/GW) and
secure to your 
built devices.

Simon


At 03:28 PM 17/10/2006, you wrote:
>Hi
>
>I want to start looking at encryption using OpenH323 and
I am wondering if 
>the good people on this list perhaps can help me a bit.
My application 
>uses its own data-transport, i.e. I only use OpenH323
for signaling. I 
>also have the encryption up and running (AES-128).
>
>My problem is how I do the signaling first tell the
other side that I am 
>capable of encryption and secondly how I can decide on
the shared key to 
>be used for encryption.
>
>I have really tried Googling this, but without any
success.
>
>Anybody out there that can help me?
>
>A huge thanks in advance!
>
>-Peter
>--------------------------------------------------------
----------------
>Check the FAQ before asking! - http://www.
openh323.org/~openh323/fom.cgi
>The OpenH323 Project mailing list, using Mailman. To
unsubscribe or
>change your subscription options, goto
>htt
p://www.openh323.org/mailman/listinfo/openh323
>Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
>--------------------------------------------------------
----------------


------------------------------------------------------------
------------
Check the FAQ before asking! - http://www.
openh323.org/~openh323/fom.cgi
The OpenH323 Project mailing list, using Mailman. To
unsubscribe or
change your subscription options, goto
htt
p://www.openh323.org/mailman/listinfo/openh323
Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
------------------------------------------------------------
------------

Thank you Simon! That was way more information than I had
ever hoped 
for! Seems like a rather complex issue though,

I am wondering if anybody here has actually added encryption
to OpenH323 
already?

Also, a H323 question. Is it true that you have to involve a
GK to do 
encryption between two EPs? Or can place a direct call from
one EP to 
another EP and still have encryption?

-Peter
------------------------------------------------------------
------------
Check the FAQ before asking! - http://www.
openh323.org/~openh323/fom.cgi
The OpenH323 Project mailing list, using Mailman. To
unsubscribe or
change your subscription options, goto
htt
p://www.openh323.org/mailman/listinfo/openh323
Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
------------------------------------------------------------
------------

On Wed, 18 Oct 2006 10:05:48 +0200
Peter Parnes <Peter.Parnesltu.se> wrote:

> Thank you Simon! That was way more information than I
had ever hoped 
> for! Seems like a rather complex issue though,
> 
> I am wondering if anybody here has actually added
encryption to OpenH323 
> already?
> 
> Also, a H323 question. Is it true that you have to
involve a GK to do 
> encryption between two EPs? Or can place a direct call
from one EP to 
> another EP and still have encryption?

To add to Simon's excellent response, there are two parts to
implementing media encryption:

  1) Exchanging keys

  2) Doing the (de)encryption of RTP media

I've added SRTP encryption to OPAL, which takes care of (2).
I also
added secure TLS signalling for H.323, so all we need is key
exchange 
which is (1) above.

To do this, I looked at H.235.8 (also called H.235-SRTP)
which is the
standard way to do SRTP key exchange for H.323. It's
horribly complex,
and in the end, I gave up.

I think Simon's suggestion of adding a non-standard key
exchange is
probably the easiest way to do this. Alternatively, if you
can wait for
a few weeks, we will have ZRTP key exchange which will work
for both
H.323 and SIP.

   Craig

------------------------------------------------------------
-----------
 Craig Southeren          Post Increment – VoIP Consulting
and Software
 craigspostincrement.com.au                  
www.postincrement.com.au

 Phone:  +61 243654666      ICQ: #86852844
 Fax:    +61 243656905      MSN: craig_southerenhotmail.com
 Mobile: +61 417231046      Jabber: craigsjabber.org

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting

------------------------------------------------------------
------------
Check the FAQ before asking! - http://www.
openh323.org/~openh323/fom.cgi
The OpenH323 Project mailing list, using Mailman. To
unsubscribe or
change your subscription options, goto
htt
p://www.openh323.org/mailman/listinfo/openh323
Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
------------------------------------------------------------
------------

Peter

At 04:05 PM 18/10/2006, you wrote:
>Thank you Simon! That was way more information than I
had ever hoped for! 
>Seems like a rather complex issue though,

It is good that people understand how encryption is
currently done and the 
standard methods involved especially as these are now being
developed for Opal.

>I am wondering if anybody here has actually added
encryption to OpenH323 
>already?

Yes, I have added encryption to OpenH323 see
www.pacphone.com  The 
encryption is an proprietary add-on library much like what
you are trying 
to do and uses the caller authentication support in OpenH323
to do the key 
exchange in the H.225 channel as I suggested in the previous
email. This 
method is completely custom and non-standard.


>Also, a H323 question. Is it true that you have to
involve a GK to do 
>encryption between two EPs? Or can place a direct call
from one EP to 
>another EP and still have encryption?

Unlike SIP, you do NOT have to involve the GK to the
encryption process at 
all (PacPhone doesn't) and any legacy GK should support the
routing of the 
encrypted calls, unless you need to secure the signalling
channel. However 
you should have a method to encrypt the key exchange
material components in 
the signalling to avoid MiTM (man in the middle) attacks.
For instance: 
PacPhone uses PKI and symmetric key encryption to secure the
key material.

Simon




------------------------------------------------------------
------------
Check the FAQ before asking! - http://www.
openh323.org/~openh323/fom.cgi
The OpenH323 Project mailing list, using Mailman. To
unsubscribe or
change your subscription options, goto
htt
p://www.openh323.org/mailman/listinfo/openh323
Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
------------------------------------------------------------
------------

Ok!

My goal here is to be able to talk to hardware H323
equipment like 
Tandberg MCUs and EPs. I have no problem creating a
proprietary solution 
(on my own)  I must
admit though that I do not enough yet about what 
Tandberg etc talks on the encryption side (besides the
actual encryption 
being AES-128).

Simon and Craig, how far are your contributions from being
able to talk 
to a Tandberg?

-Peter
------------------------------------------------------------
------------
Check the FAQ before asking! - http://www.
openh323.org/~openh323/fom.cgi
The OpenH323 Project mailing list, using Mailman. To
unsubscribe or
change your subscription options, goto
htt
p://www.openh323.org/mailman/listinfo/openh323
Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
------------------------------------------------------------
------------

Craig

I think they ignored the kiss principal when they developed
SRTP, I 
certainly agree with H.235.8 (H.323 equivalent of SIP
sdescriptions), it's 
a dog and the reason that H.235.8 was selected over H.235.7
(MiKey) was a 
problem (mainly coming from the SIP people) with the delay
in doing 
diffie-hellman key exchanges (far more secure than
symmentric key of 
sdescriptions) at the start of the media setup and the
subsequent 2-3 sec 
dead spot before the media can start to flow.

Now with ZRTP, (which does it key exchange completely in the
media channel, 
no signalling channel involvement) and very inter operable
with most 
equipment, due to not involving the signalling is far worse
than the 
problems with MiKey since the media channel must first be
established 
before the key exchange can occur. It also AFAIK does not
account for the 
key exchange failing and the notifying the user the media is
not being 
encrypted.  The reason it is popular is that it is the only
thing that will 
work with any form of inter operability with existing SIP
Servers in SIP.

Doing the exchanges in H.225 signalling masks the problem of
delay of media 
establishment as security association (common key
generation) is done prior 
to even the remote party even ringing allowing the called
party to exercise 
some form of authentication on the caller and to notify the
users that the 
call will be encrypted prior to answering the call. The ITU
are not really 
interested in standardizing this method as it cannot be
reproduced in SIP 
(because of UDP packet size restraints and the fact SIP does
not have an 
end-to-end signalling channel like H.225) and they already
have like 3 
other interoperable methods.

It's all becoming like a revolving door, the basic fact is
that SIP is 
commercially unsecurable and H.323 is just following it
around and around.

Simon


At 06:23 PM 18/10/2006, you wrote:
>On Wed, 18 Oct 2006 10:05:48 +0200
>Peter Parnes <Peter.Parnesltu.se> wrote:
>
> > Thank you Simon! That was way more information
than I had ever hoped
> > for! Seems like a rather complex issue though,
> >
> > I am wondering if anybody here has actually added
encryption to OpenH323
> > already?
> >
> > Also, a H323 question. Is it true that you have to
involve a GK to do
> > encryption between two EPs? Or can place a direct
call from one EP to
> > another EP and still have encryption?
>
>To add to Simon's excellent response, there are two
parts to
>implementing media encryption:
>
>   1) Exchanging keys
>
>   2) Doing the (de)encryption of RTP media
>
>I've added SRTP encryption to OPAL, which takes care of
(2). I also
>added secure TLS signalling for H.323, so all we need is
key exchange
>which is (1) above.
>
>To do this, I looked at H.235.8 (also called H.235-SRTP)
which is the
>standard way to do SRTP key exchange for H.323. It's
horribly complex,
>and in the end, I gave up
>
>I think Simon's suggestion of adding a non-standard key
exchange is
>probably the easiest way to do this. Alternatively, if
you can wait for
>a few weeks, we will have ZRTP key exchange which will
work for both
>H.323 and SIP.
>
>    Craig
>
>--------------------------------------------------------
---------------
>  Craig Southeren          Post Increment ­ VoIP
Consulting and Software
>  craigspostincrement.com.au                  
www.postincrement.com.au
>
>  Phone:  +61 243654666      ICQ: #86852844
>  Fax:    +61 243656905      MSN: craig_southerenhotmail.com
>  Mobile: +61 417231046      Jabber: craigsjabber.org
>
>  "It takes a man to suffer ignorance and smile.
>   Be yourself, no matter what they say."   Sting
>
>--------------------------------------------------------
----------------
>Check the FAQ before asking! - http://www.
openh323.org/~openh323/fom.cgi
>The OpenH323 Project mailing list, using Mailman. To
unsubscribe or
>change your subscription options, goto
>htt
p://www.openh323.org/mailman/listinfo/openh323
>Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
>--------------------------------------------------------
----------------


------------------------------------------------------------
------------
Check the FAQ before asking! - http://www.
openh323.org/~openh323/fom.cgi
The OpenH323 Project mailing list, using Mailman. To
unsubscribe or
change your subscription options, goto
htt
p://www.openh323.org/mailman/listinfo/openh323
Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
------------------------------------------------------------
------------

Peter

I have no idea what Tandberg uses. The only solution I can
think of is to 
get ethereal and determine what type of cryptoToken they are
using 
(signed/hashed/encrypted) and see what method they might be
using. It could 
be using a variant of H.235.6 (unlikely it will be H.235.7
or H.235.8) but 
who knows.

Sorry I can't help you more.

Simon

At 07:12 PM 18/10/2006, you wrote:
>Ok!
>
>My goal here is to be able to talk to hardware H323
equipment like 
>Tandberg MCUs and EPs. I have no problem creating a
proprietary solution 
>(on my own)  I must
admit though that I do not enough yet about what 
>Tandberg etc talks on the encryption side (besides the
actual encryption 
>being AES-128).
>
>Simon and Craig, how far are your contributions from
being able to talk to 
>a Tandberg?
>
>-Peter
>--------------------------------------------------------
----------------
>Check the FAQ before asking! - http://www.
openh323.org/~openh323/fom.cgi
>The OpenH323 Project mailing list, using Mailman. To
unsubscribe or
>change your subscription options, goto
>htt
p://www.openh323.org/mailman/listinfo/openh323
>Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
>--------------------------------------------------------
----------------


------------------------------------------------------------
------------
Check the FAQ before asking! - http://www.
openh323.org/~openh323/fom.cgi
The OpenH323 Project mailing list, using Mailman. To
unsubscribe or
change your subscription options, goto
htt
p://www.openh323.org/mailman/listinfo/openh323
Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
------------------------------------------------------------
------------

Let me explain the second paragraph again

ZRTP is very good and should interoperate with most SIP
& H.323 systems as 
the key exchange is done entirely in the RTP stream. However
it still 
suffers from the same problems of Mikey with "dead
air" at the start of the 
call while the key exchange is being negotiated.

Simon


At 07:57 PM 18/10/2006, you wrote:

>Craig
>
>I think they ignored the kiss principal when they
developed SRTP, I 
>certainly agree with H.235.8 (H.323 equivalent of SIP
sdescriptions), it's 
>a dog and the reason that H.235.8 was selected over
H.235.7 (MiKey) was a 
>problem (mainly coming from the SIP people) with the
delay in doing 
>diffie-hellman key exchanges (far more secure than
symmentric key of 
>sdescriptions) at the start of the media setup and the
subsequent 2-3 sec 
>dead spot before the media can start to flow.
>
>Now with ZRTP, (which does it key exchange completely in
the media 
>channel, no signalling channel involvement) and very
inter operable with 
>most equipment, due to not involving the signalling is
far worse than the 
>problems with MiKey since the media channel must first
be established 
>before the key exchange can occur. It also AFAIK does
not account for the 
>key exchange failing and the notifying the user the
media is not being 
>encrypted.  The reason it is popular is that it is the
only thing that 
>will work with any form of inter operability with
existing SIP Servers in SIP.
>
>Doing the exchanges in H.225 signalling masks the
problem of delay of 
>media establishment as security association (common key
generation) is 
>done prior to even the remote party even ringing
allowing the called party 
>to exercise some form of authentication on the caller
and to notify the 
>users that the call will be encrypted prior to answering
the call. The ITU 
>are not really interested in standardizing this method
as it cannot be 
>reproduced in SIP (because of UDP packet size restraints
and the fact SIP 
>does not have an end-to-end signalling channel like
H.225) and they 
>already have like 3 other interoperable methods.
>
>It's all becoming like a revolving door, the basic fact
is that SIP is 
>commercially unsecurable and H.323 is just following it
around and around.
>
>Simon
>
>
>At 06:23 PM 18/10/2006, you wrote:
>>On Wed, 18 Oct 2006 10:05:48 +0200
>>Peter Parnes <Peter.Parnesltu.se> wrote:
>>
>> > Thank you Simon! That was way more information
than I had ever hoped
>> > for! Seems like a rather complex issue though,
>> >
>> > I am wondering if anybody here has actually
added encryption to OpenH323
>> > already?
>> >
>> > Also, a H323 question. Is it true that you
have to involve a GK to do
>> > encryption between two EPs? Or can place a
direct call from one EP to
>> > another EP and still have encryption?
>>
>>To add to Simon's excellent response, there are two
parts to
>>implementing media encryption:
>>
>>   1) Exchanging keys
>>
>>   2) Doing the (de)encryption of RTP media
>>
>>I've added SRTP encryption to OPAL, which takes care
of (2). I also
>>added secure TLS signalling for H.323, so all we
need is key exchange
>>which is (1) above.
>>
>>To do this, I looked at H.235.8 (also called
H.235-SRTP) which is the
>>standard way to do SRTP key exchange for H.323. It's
horribly complex,
>>and in the end, I gave up
>>
>>I think Simon's suggestion of adding a non-standard
key exchange is
>>probably the easiest way to do this. Alternatively,
if you can wait for
>>a few weeks, we will have ZRTP key exchange which
will work for both
>>H.323 and SIP.
>>
>>    Craig
>>
>>----------------------------------------------------
-------------------
>>  Craig Southeren          Post Increment ­ VoIP
Consulting and Software
>>  craigspostincrement.com.au                  
www.postincrement.com.au
>>
>>  Phone:  +61 243654666      ICQ: #86852844
>>  Fax:    +61 243656905      MSN:
craig_southerenhotmail.com
>>  Mobile: +61 417231046      Jabber: craigsjabber.org
>>
>>  "It takes a man to suffer ignorance and
smile.
>>   Be yourself, no matter what they say."  
Sting
>>
>>----------------------------------------------------
--------------------
>>Check the FAQ before asking! - http://www.
openh323.org/~openh323/fom.cgi
>>The OpenH323 Project mailing list, using Mailman. To
unsubscribe or
>>change your subscription options, goto
>>htt
p://www.openh323.org/mailman/listinfo/openh323
>>Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
>>----------------------------------------------------
--------------------
>
>
>--------------------------------------------------------
----------------
>Check the FAQ before asking! - http://www.
openh323.org/~openh323/fom.cgi
>The OpenH323 Project mailing list, using Mailman. To
unsubscribe or
>change your subscription options, goto
>htt
p://www.openh323.org/mailman/listinfo/openh323
>Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
>--------------------------------------------------------
----------------


------------------------------------------------------------
------------
Check the FAQ before asking! - http://www.
openh323.org/~openh323/fom.cgi
The OpenH323 Project mailing list, using Mailman. To
unsubscribe or
change your subscription options, goto
htt
p://www.openh323.org/mailman/listinfo/openh323
Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
------------------------------------------------------------
------------