[h323plus] H.235 AES problem continue

Simon Horne s.horne at packetizer.com
Tue Dec 11 07:58:15 EST 2007


Bian

Polycom is not using H.235.6 key exchange and most certainly not using diffie-hellman. It is using symmetric key AES encryption which is AFAIK is NOT standard. The key material is encrypted using a secret shared private mechanism. 

Let me explain what this is
>         algorithmOID = 2.16.840.1.101.3.4.1.2                     
>       // <"OID_Z3" which means using AES 128 CBC mode
>         paramS = {                                                
>                   // means IV is 0
>         }
>         encryptedSessionKey =  16 octets {
>           c7 36 02 5c b7 ae b0 cc  97 c8 af bb d5 72 0f 19   

AlgorithmOID has nothing to do with the encryptedSessionKey. The AlgorithmOID notifies the remote what cipher to use DES 3DES or AES. This is standard identifier. Basically this tells the remote to use AES.

encryptionSessionKey is encrypted using an non-public known secret method. The only way you are going to decrypt this is if you know how the key is encrypted. AFAIK only polycom can provide you that information. It is not public knowledge.

Simon

> -----Original Message-----
> From: h323plus-bounces at lists.packetizer.com
> [mailto:h323plus-bounces at lists.packetizer.com]On Behalf Of Bian
> Sent: Tuesday, December 11, 2007 9:56 PM
> To: H323plus
> Subject: [h323plus] H.235 AES problem continue
> 
> 
> Hi
> 
> I have finished call procedure of H.235 and get same H.235 
> encryption check code with PVX. (See attach)
> This is the shared secret(PVX only display 8 bytes long, whereas 
> the h.235.6 indicate 16 bytes long see below). As slave, local 
> endpoint receive OpenLogicalChannel rerquest, which has a 
> parameter  H235_V3KeySyncMaterial. The param content is as below:
>      {
>         algorithmOID = 2.16.840.1.101.3.4.1.2                     
>       // <"OID_Z3" which means using AES 128 CBC mode
>         paramS = {                                                
>                   // means IV is 0
>         }
>         encryptedSessionKey =  16 octets {
>           c7 36 02 5c b7 ae b0 cc  97 c8 af bb d5 72 0f 19   
> .6.\.........r..
>         }
>       }
> 
> Then local endpoint begin to decrypt sessionKey from 
> encryptedSessionKey  using shared secret.
> But decryption is failed. Can anyone help to analyse where is the wrong.
> 
> The below is piece of code decrypting sessionKey (using openssl-0.9.8g)
> 
>     ret = EVP_DecryptInit(&ctx, EVP_aes_128_cbc(), NULL, NULL);
>     PAssert(ret, PLogicError);
>     ret = EVP_CIPHER_CTX_set_key_length(&ctx, 16);
>     PAssert(ret, PLogicError);
>     ret = EVP_DecryptInit(&ctx, EVP_aes_128_cbc(), key, NULL);  
> // IV is null here . key is same as PVX's  H.235 encryption check 
> code (PVX only display 8 bytes)
>     PAssert(ret, PLogicError);
> 
>     ret = EVP_DecryptUpdate(&ctx, buffer, &outl, (unsigned char 
> *)in.GetPointer(), 16);//    but the "outl" returned is 0 which 
> shall be 16 here I think.
>     len += outl;
>    ret = EVP_DecryptFinal(&ctx, buffer+len, &outl);  // return 0 
> here, means error is found
> 
> (Each entity shall take appropriate least significant bits from 
> the common shared Diffie-Hellman
> secret for the key encryption key (master key); i.e., the 56 
> least significant bits of the
> Diffie-Hellman secret for OID "X", OID "X1", OID "Y1" or OID "Y" 
> and the 168 least significant
> bits of the Diffie-Hellman secret for OID "Z", OID "Z1" or OID 
> "Z2" and the 128 least significant
> bits of the Diffie-Hellman secret for OID "Z3" or OID "Z2", see 
> also Table 6.)
> 
> Bian
> 
> 
>       ___________________________________________________________ 
> 天生购物狂,狂抢购物券,你还等什么! 
> http://cn.mail.yahoo.com/promo/taobao20/index.php
> 





More information about the h323plus mailing list