How does the encryption work exactly.

[shorne]

The encryption in the PacPhone uses a one time encryption key for the call which is negotiated directly between the calling parties (There is no other party involvement) The negotiation is carried in the first 2 VoIP messages ( I in either direction). If both parties support encryption it is used and if not then it proceeds as a standard unencrypted H.323 call.

The encryption key is generated by the joining of 2 half keys, 1 generated by each party for each call. This half-key is generated using trusted prime numbers which vary in length from 512 to 1536 bit depending on the cipher used. (ie DES 56 is 512 AES 256 is 1536)

The key exchange material is protected by 1024 bt digital certificate encryption using PacPhone's internal certificate. (This can be replaced by user supplied cerificate)

The following ciphers are supported
DES 56 bit (512 bit Prime)
AES 128 bit (1024 bit Prime)
3DES 168 bit (1024 bit Prime)
AES 256 bit (1536 bit Prime)

The Encrypted media is carried over the standard media protocol (RTP) so is fully compatible with other H.323 poxying devices.

The crypto engine used is OpenSSL and methodology employed is a variant of TLSv1.

For more information refer www.packetizer.com/labs.

[Guest]

Hi Shorne,

If I understood the key echange scheme you described its signed Diffie-Hellmann key exchange. My question is, can I use PacPhone with minisip since Minisip supports signed DH key-exchange.

Thanks in advance.
P.S. in case you are contact devlopers, will they support other key echange schems in their road map.

[shorne]

Firstly minisip is SIP, PacPhone is H.323 which is a completely different protocol.

PacPhone method of key exchange and encryption performance cannot be duplicated in SIP. The reason is that PacPhone includes the diffie-hellman key exchange embedded within pre-existing call signalling messages and is able to create the security association (shared key) before the first ring on the remote phone. Mikey does the exchange after the remote pickup which means a 1-3 sec delay in receiving audio which can be very annoying.

Also SIP messaging does not support the large messages required to do end-to-end certificate based authentication so it is impossible to authenticate the people in the call directly with eachother.

PacPhone does both highly secure media (no delay) and end to end authentication which at this time cannot be replicated in SIP.

[medo]

Dear Simon,

Thanks for the informative reply. I have two more questions that I hope you don't mind answering.

Q1/ Do you know about any phone -other than PacPhone- is utilizing eaRTP for media encryption (commercial or free-ware)?

Q2/ Has PacPhone been reported to work -with encrypted media- via Asterisk/GnuGK or other PBXs?

Q3/ Under what kind of licence eaRTP is published? If open, then we can make a channel on Asterisk for it.

I have to mention that eaRTP approche is indeed interesting (easy, strightforward, and solve many issues), but before wide deployment; we have to check interoperability.

Thanks in advance

[shorne]

Q1/ Do you know about any phone -other than PacPhone- is utilizing eaRTP for media encryption (commercial or free-ware)?

No at this time only PacPhone and softphones based on PacPhone support eaRTP. We are currently developing IP phones and gateways that support the technology

Q2/ Has PacPhone been reported to work -with encrypted media- via Asterisk/GnuGK or other PBXs?

PacPhone encryption will work through any standard H.323 proxy including GnuGK, Cisco etc without requiring any firmware updates. It can be routed through numereos intermediaries without losing encryption integrety or being susceptable to Man in the Middle attacks (MiTM) as the key exchange is encrypted end to end. It has been tested on GnuGK, Cisco and numerous other proxies. It also will work with any H.323 Gateway or Endpoint (in non-encrypted mode) as it is 100% interoperable with standard H.323 equipment and many people use PacPhone with PSTN Terminatoin services without issues.

Q3/ Under what kind of licence eaRTP is published? If open, then we can make a channel on Asterisk for it.

eaRTP is proprietry and can included as a binary library add on to the OpenH323 project. There should be no need for any special Asterisk channel as the standard H.323 channel should already be able to support eaRTP pass-through as it uses pre-existing H.323 valid syntax messages and only requires RTP. So it should work without problem from one eaRTP enabled device to another.

I have to mention that eaRTP approche is indeed interesting (easy, strightforward, and solve many issues), but before wide deployment; we have to check interoperability.

PacPhone is 100% compatible (as far as we are aware) to any H.323 proxy and end device. PacPhone will use standard RTP to non-eaRTP devices and eaRTP to enabled devices in a completely seemless manner.

Simon