[20150822 Update] For the record, I didn’t find the right ITU-REC document when I wrote this post, and misguided by a claim of HUAWEI VP9650 which says it has AES256 supported, but when I sending out a call from VP9650, it showed a new DH group DH1536, so I made my conclusion arbitary, DH1536 means AES256, obviously, it’s a terrible mistake.
Planning to upgrade to H.235 encryption from AES128 to AES256, but don’t know where to start.
Did not find a short way to achieve that.
We wished to get some informations about AES256 by capturing some pcap files of some other Video Conference solution providers.
But did not find a device which actually supports H.235 + AES256 feature.
So we returned to the ITU-REC document for more details. The right ITU-REC should be T-REC-H.235.6-201401-I!!PDF-E.pdf.
Some key steps of implementing H.235.
1. SETUP: Caller send a public key token DHSet of in H.225 SETUP, which includes:
1) halfkey: contains the random public key of one party
2)modsize: contains the DH-prime
3)generator: contains the DH-group
1. Public key token DHSet of in H.225 SETUP
2. CONNECT: Callee generate a private key token by using the public key of caller, and send it back to the caller in its H.225 CONNECT, also including halfkey, modsize and generator.
2. Private key token of DHSet in H.225 CONNECT
3. TCS: Both caller and callee send their H.245 TCS with H.235 capabilities.
3. Sample H.245 TCS with H.235 capability
4. MasterSlave determination
5. Master generate a media key which will be used to encrypt/decrypt the media.
5a. OLC(from master): Open a logical channel with a specified H.235 media, and send to the slaver
H235Key in H.245 OLC
5b. OLC ACK(from master): Reply the media key to the OLC requester(Slaver)
H235Key in H.245 OLC ACK
6. Some other H.245 request/indication messages, such as encryptionUpdateRequest, encryptionUpdate.
H.235 encryption related node definitions:
1. The tokenOID in H.225 SETUP and CONNECT message:
1a. H600’s tokenOID
Item0: 0.0.8.235.0.1.5
Item0: 0.0.8.235.0.1.5
Item2: 0.0.8.235.0.3.24
Item3: 0.0.8.235.0.3.43
1b. Huawei MCU’s tokenOID
ProductId: VP9650, versionId: V200R001C02B018SP07 Apr 28 2014 16:15:31+08
Item0: 0.0.8.235.0.1.5
Item1: 0.0.8.235.0.3.44
Item2: 0.0.8.235.0.3.43
Item3: 0.0.8.235.0.3.24
1c. Huawei TE40’s tokenOID
ProductId: TEx0, versionId: Release 1.1.24.5
Item0: 0.0.8.235.0.3.43
Item1: 0.0.8.235.0.3.24
http://www.oid-info.com/get/0.0.8.235.0.1.5
http://www.oid-info.com/get/0.0.8.235.0.3.24
http://www.oid-info.com/get/0.0.8.235.0.3.43
http://www.oid-info.com/get/0.0.8.235.0.3.44
“T” {itu-t (0) recommendation (0) h (8) 235 version (0) 2 5} {itu-t (0) recommendation (0) h (8) 235 version (0) 1 5} Used in Procedures I and IA as the baseline ClearToken for the message authentication and replay protection and optionally also for Diffie-Hellman key management as described in D.7.1.
“DH1024” {itu-t (0) recommendation (0) h (8) 235 version (0) 2 43} 1024-bit DH group
“DH1536” {itu-t (0) recommendation (0) h (8) 235 version (0) 3 44} 1536-bit DH group
From chapter D.11 List of object identifiers of <T-REC-H.235-200308-S!!PDF-E.pdf>, P.70-71
[20150822 Update]
Earlier when I wrote this post, I didn’t find the right ITU/T standard(T-REC-H.235.6-201401-I!!PDF-E.pdf).
The information I got was that HUAWEI VP9650 supports AES256, and when I tried to sending out a call on VP9650, I got to know it supports following DH groups:
Item0: 0.0.8.235.0.1.5
Item1: 0.0.8.235.0.3.44
Item2: 0.0.8.235.0.3.43
Item3: 0.0.8.235.0.3.24
So I made my conclusion arbitarty that DH1536 is our goal: AES256, but turned out I was terribly wrong. (I don’t know why VP9650 sending out max to DH1536 while it claims having AES 256 supported)
2. Media encryption algorithm definitions on H.245 TCS, OLC, OLC ACK,etc:
The most frequently used/seem types are:
2a. AES 128 bit CBC: 2.16.840.1.101.3.4.1.2
2b. DES 56 bit CBC(Voice encryption using DES in CBC mode and 512-bit DH-group): 1.3.14.3.2.7
2.16.840.1.101.3.4.1.1 – id-aes128-ECB
2.16.840.1.101.3.4.1.2 – id-aes128-CBC
2.16.840.1.101.3.4.1.3 – id-aes128-OFB
2.16.840.1.101.3.4.1.4 – id-aes128-CFB
2.16.840.1.101.3.4.1.6 – id-aes128-GCM
2.16.840.1.101.3.4.1.7 – id-aes-CCM
2.16.840.1.101.3.4.1.21 – id-aes192-ECB
2.16.840.1.101.3.4.1.22 – id-aes192-CBC
2.16.840.1.101.3.4.1.23 – id-aes192-OFB
2.16.840.1.101.3.4.1.24 – id-aes192-CFB
2.16.840.1.101.3.4.1.26 – id-aes192-GCM
2.16.840.1.101.3.4.1.27 – id-aes192-CCM
2.16.840.1.101.3.4.1.41 – id-aes256-ECB
2.16.840.1.101.3.4.1.42 – id-aes256-CBC
2.16.840.1.101.3.4.1.43 – id-aes256-OFB
2.16.840.1.101.3.4.1.44 – id-aes256-CFB
2.16.840.1.101.3.4.1.46 – id-aes256-GCM
2.16.840.1.101.3.4.1.47 – id-aes256-CCM
Source : http://www.alvestrand.no/objectid/2.16.840.1.101.3.4.1.html
About DH key exchange:
1. http://baike.baidu.com/view/551692.htm
2. http://www.rosoo.net/a/201507/17349.html
3. Diffie-Hellman, http://www.cryptopp.com/wiki/Diffie-Hellman
4. rfc3526: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE), https://www.ietf.org/rfc/rfc3526.txt
5. Huawei VP9650(which claims having AES256 supported): http://e.huawei.com/cn/related-page/products/enterprise-network/telepresence-video-conferencing/infrastructure/vp9600/TPVC_MCU_VP9600
You can use H323plus and the GNU Gatekeeper to test AES256 in H.323.
Compile H323Plus with –enable-h235-256 and then the sample application “Simple”.
H323Plus supports AES128 and key length up to 8K.
GnuGk also supports adding encryption to calls, including AES256. Check out the “H235 Media” options in the manual.
Dear Jan,
Thanks very much for your answer to me.
I once was planning to replace our current H.323 stack with H323Plus, but it’s a really big project considering the tremendous products we’ve pushed to the markets.
Most of the concerns are about the compatibility issues, because we made a lot of private/non-standard implementations for our H.323 stack and products built on it. Some of the private implementations even have nothing to do with H.323 protocol, such as using a secondary TCP connection to communicate some private protocol through out our products working along with H.225 and H.245.
But we are also facing standardization requirements when conferencing with other manufacturers, AES256 is only one of them.
I’m still pushing my boss if we can turn to some open source projects for our new projects, MT and MCU, and AES256 requirement could be a chance, although the chance is small.
Whatever the results, GnuGK is definitely a best option for me to run test our implmentations including but not limits to AES256. Thanks again for your helping, and also thanks to your great work. I’m really appreciated!