freeMXF.org

Open discussion about freeMXF.org tools and MXF in general
It is currently Thu Mar 28, 2024 5:48 pm
Board index » MXF Categories » freeMXF.org Tools



Post new topic Reply to topic  [ 9 posts ] 
Author
Search for:
Message

Offline
Board User

Joined: Thu Sep 01, 2005 1:51 pm
Posts: 6
Location: Germany

Post Posted: Tue May 23, 2006 12:41 pm 
Top  
Hi,

i have a problem with building the MIC for encrypted KLVs. I'm using the HashHMACSHA1 class like this:

8<---------------------------------------------------------------

UInt8 hash_key[16] =
{ 0x56, 0x56, 0x56, 0x56, 0x56, 0x56, 0x56, 0x56,
0x56, 0x56, 0x56, 0x56, 0x56, 0x56, 0x56, 0x56 };

DataChunkPtr HashKey = BuildHashKey(16, hash_key);
HashPtr Hasher = new HashHMACSHA1();
Hasher->SetKey(HashKey);
Hasher->HashData(size, buf);
DataChunkPtr Hash = Hasher->GetHash();

8<---------------------------------------------------------------

size is:
length of the encrypted source value (IV+Check+SourceValue+Padding)
+ 20 (Byte) for length & value of the TrackFileID
+ 12 (Byte) for length & value of the SequenceNumber
+ 4 (Byte) for the length of the MIC

buf holds the associated data.

The calculated MIC is not identical to the MIC in the given encrypted KLV.
So, is this the right approach in principle?

Thanks,
Florian

 Profile ICQ  

Offline
Insider

Joined: Thu Apr 15, 2004 10:39 am
Posts: 198
Location: Scotland

Post Posted: Tue May 23, 2006 1:40 pm 
Top  
A couple of points:

1) The 2nd parameter of the BuildHaskKey() method is the encryption key used for the encrypted KLV - this is unlikely to be "VVVVVVVVVVVVVVVV" as used in your example (are you actually replacing this with the cipher key?)

2) The lengths are BER and so may not be constant!

Otherwise it sounds OK

 Profile WWW  

Offline
Board User

Joined: Thu Sep 01, 2005 1:51 pm
Posts: 6
Location: Germany

Post Posted: Tue May 23, 2006 1:47 pm 
Top  
Thanks for your reply.

The key is correct, its for testing only.
I also considered the BER coded length, these are the concrete values in my case only, sorry.

 Profile ICQ  

Offline
Insider

Joined: Thu Apr 15, 2004 10:39 am
Posts: 198
Location: Scotland

Post Posted: Tue May 23, 2006 3:30 pm 
Top  
Are you hashing the encrypted data, or the plaintext?

 Profile WWW  

Offline
Board User

Joined: Thu Sep 01, 2005 1:51 pm
Posts: 6
Location: Germany

Post Posted: Tue May 23, 2006 4:21 pm 
Top  
I'm hashing the encrypted data. Is this wrong?

 Profile ICQ  

Offline
Insider

Joined: Thu Apr 15, 2004 10:39 am
Posts: 198
Location: Scotland

Post Posted: Tue May 23, 2006 4:24 pm 
Top  
Yes - you should be hashing the encrypted data (otherwise the hash of the plaintext gives an extra vector to attack the encryption!)

 Profile WWW  

Offline
Board User

Joined: Thu Sep 01, 2005 1:51 pm
Posts: 6
Location: Germany

Post Posted: Tue May 30, 2006 8:32 am 
Top  
I took a look at the asdcplib and i think i found some problems in your hashing procedure.

I think BuildHashKey() generates a false key, because the MICKey shall be generated this way:

Code:
MICKey = trunc( HMAC-SHA-1( CipherKey, 0x00112233445566778899aabbccddeeff ) )

where trunc selects the first 128-bits of the output.

BuildHashKey() doesn't use the CipherKey directly, but instead CipherKey^=0x36 via SetKey().

Also i think SetKey() should call SHA1_Update(&Context, KeyBuffer_i, 64) with Size instead of 64. Same thing in GetHash() with KeyBuffer_o.

What do you think?

 Profile ICQ  

Offline
Insider

Joined: Thu Apr 15, 2004 10:39 am
Posts: 198
Location: Scotland

Post Posted: Sat Jun 03, 2006 3:33 pm 
Top  
I think that you are misunderstanding the way SetKey works - if you look in RFC 2104 ("HMAC: Keyed-Hashing for Message Authentication") you will see that the 0x36 value you see in SetKey is the initialization of ipad. (opad is also initialized to 64 * 0x5c here).

The code you quoted from section 7.10 of the AS-DCP spec shows that setting the MICkey involves a pass through the entire HMAC-SHA-1 algorithm - including the setting of ipad and opad.

The reason that 64 bytes are set into SHA1_Update in SetKey is that this is the size of ipad which gets included in the hash at the start of the HMAC calculation (opad is included at the end)

I hope that asdcplib calculates its HMAC in the same way as MXFLib. If you add the following test function to mxfcrypt.cpp, then try this with the HMAC-SHA-1 test cases from RFC 2202 ("Test Cases for HMAC-MD5 and HMAC-SHA-1") you will find that the results are correct.

Code:
bool TestHMAC(DataChunkPtr Key, DataChunkPtr Data, DataChunkPtr ExpectedResult)
{
   ASSERT(ExpectedResult->Size == 20);

   printf("Key =%s\nData=%s\nHash=%s\n", Key->GetString().c_str(), Data->GetString().c_str(), ExpectedResult->GetString().c_str());

   HashPtr Hasher = new HashHMACSHA1();

   Hasher->SetKey(Key);
   Hasher->HashData(Data);
   DataChunkPtr Result = Hasher->GetHash();

   bool Ret = true;

   if(Result->Size != 20)
   {
      error("Result not 20 bytes\n");
      error("Actual Result=%s\n", Result->GetString().c_str());
      Ret = false;
   }
   else
   {
      if(memcmp(ExpectedResult->Data, Result->Data, 20) != 0)
      {
         error("Actual Result=%s\n", Result->GetString().c_str());
         Ret=false;
      }
   }

   if(!Ret) printf("*FAILED*\n\n");
   else printf("OK\n\n");

   return Ret;
}

 Profile WWW  

Offline
Board User

Joined: Thu Sep 01, 2005 1:51 pm
Posts: 6
Location: Germany

Post Posted: Tue Jun 06, 2006 7:34 am 
Top  
I knew how ipad and opad are used, but i thought that they are not needed to generate the key. The asdcplib (AS_DCP_AES.cpp,v 1.11) works this way:

Code:
void SetKey(const byte_t* key)
  {
    static byte_t key_nonce[KeyLen] = { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77,
               0x88, 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff };
#ifndef ASDCP_WITHOUT_OPENSSL
    byte_t sha_buf[SHA_DIGEST_LENGTH];

    // 7.10: MICKey = trunc( SHA1 ( key, key_nonce ) )
    SHA_CTX SHA;
    SHA1_Init(&SHA);
    SHA1_Update(&SHA, key, KeyLen);
    SHA1_Update(&SHA, key_nonce, KeyLen);
    SHA1_Final(sha_buf, &SHA);
    memcpy(m_key, sha_buf, KeyLen);

    Reset();
#endif // ASDCP_WITHOUT_OPENSSL
  }


I took a closer look at the documents, and now i think you are right. The HMAC-procedure is missing in the asdcplib SetKey function.

The file i'm working with was generated with the asdcplib and i think the MICs are probably incorrect.

Thanks for your help!

 Profile ICQ  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

Jump to:  


Who is online

Users browsing this forum: Google [Bot] and 64 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group :: Style based on FI Subice by phpBBservice.nl :: All times are UTC