Single Key Scheme (Z) problem under version 0.9

Jun 24, 2010 at 4:21 PM

Hi all,

Just want to report that I got error when I tried to use single key scheme (Z) under version 0.9.  I have no problem if I use version 0.8.5 using same the same input.  The following are the example of command A0 and command A6:

Client: 127.0.0.1:1766
Request: 1234A01001Z0E53AAC11C46406AZ
Parsing header and code of message 1234A01001Z0E53AAC11C46406AZ...
Searching for implementor of A0...
Found implementor ThalesSim.Core.HostCommands.BuildIn.GenerateKey_A0, instantiating...
Calling AcceptMessage()...
Exception while processing message
System.ArgumentOutOfRangeException: Index and length must refer to a location within the string.
Parameter name: length
   at System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length, Boolean fAlwaysCopy)
   at System.String.Substring(Int32 startIndex, Int32 length)
   at ThalesSim.Core.Message.XML.MessageParser.Parse(Message msg, MessageFields fields, MessageKeyValuePairs& KVPairs, String& result) in C:\Documents and Settings\wpak1\Desktop\ThalesSim 0.9\ThalesCore\Message\XML\MessageParser.vb:line 193
   at ThalesSim.Core.HostCommands.BuildIn.GenerateKey_A0.AcceptMessage(Message msg) in C:\Documents and Settings\wpak1\Desktop\ThalesSim 0.9\ThalesCore\HostCommands\BuildIn\GenerateKey_A0.vb:line 57
   at ThalesSim.Core.ThalesMain.WCMessageArrived(WorkerClient sender, Byte[]& b, Int32 len) in C:\Documents and Settings\wpak1\Desktop\ThalesSim 0.9\ThalesCore\ThalesMain.vb:line 705
Disconnecting client.
Calling Terminate()...
Implementor to Nothing
Client disconnected.

Request: 1111A60080E53AAC11C46406A02A86EEEBD6B800BZ
Parsing header and code of message 1111A60080E53AAC11C46406A02A86EEEBD6B800BZ...
Searching for implementor of A6...
Found implementor ThalesSim.Core.HostCommands.BuildIn.ImportKey_A6, instantiating...
Calling AcceptMessage()...
Exception while processing message
System.ArgumentOutOfRangeException: Index and length must refer to a location within the string.
Parameter name: length
   at System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length, Boolean fAlwaysCopy)
   at System.String.Substring(Int32 startIndex, Int32 length)
   at ThalesSim.Core.Message.XML.MessageParser.Parse(Message msg, MessageFields fields, MessageKeyValuePairs& KVPairs, String& result) in C:\Documents and Settings\wpak1\Desktop\ThalesSim 0.9\ThalesCore\Message\XML\MessageParser.vb:line 193
   at ThalesSim.Core.HostCommands.BuildIn.ImportKey_A6.AcceptMessage(Message msg) in C:\Documents and Settings\wpak1\Desktop\ThalesSim 0.9\ThalesCore\HostCommands\BuildIn\ImportKey_A6.vb:line 56
   at ThalesSim.Core.ThalesMain.WCMessageArrived(WorkerClient sender, Byte[]& b, Int32 len) in C:\Documents and Settings\wpak1\Desktop\ThalesSim 0.9\ThalesCore\ThalesMain.vb:line 705
Disconnecting client.
Calling Terminate()...
Implementor to Nothing
Client disconnected.

I have no problem if I use Double Key Scheme (U)

Client from 127.0.0.1:1768 is connected
Client: 127.0.0.1:1768
Request: 5354A01001UU71979DEB8587E2734F1E99D5DCAEF9ACU
Parsing header and code of message 5354A01001UU71979DEB8587E2734F1E99D5DCAEF9ACU...
Searching for implementor of A0...
Found implementor ThalesSim.Core.HostCommands.BuildIn.GenerateKey_A0, instantiating...
Calling AcceptMessage()...
Calling ConstructResponse()...
Calling ConstructResponseAfterOperationComplete()...
Attaching header/response code to response...
Sending: 5354A100U4B86D1E0D7C762AA1369DF5FCA88238FUEA05E3C3ED19B5042D9FAB8EF5A7BCA6C624DE
Calling Terminate()...
Implementor to Nothing

Thank you very much for creating such a great library!

 

Regards,

William

 

 

Coordinator
Jun 24, 2010 at 7:27 PM
Edited Jun 24, 2010 at 7:33 PM

That is indeed the default behavior of the simulator starting with the 0.9 edition.

 

I see that it was my fault for not bringing to the attention of users the fact that a new configuration parameter has been added in the ThalesParameters.xml - that is the DoubleLengthZMKs parameter which can be true or false.

 

The value of this parameter is meant to parallel the corresponding HSM configuration that is performed using the CS command. My understanding is that if you enable double length Zone Master Keys, you would then have to ensure that all host commands that accept encrypted ZMKs receive double or triple length keys (that is, ZMKs should have a format of 32H/1A + 32H/1A + 48H) and single-length keys are not acceptable. Both the A0 and A6 are such commands and the exception you're receiving happens because the message parser expects to find at least 32 hexadecimal characters.

 

In order to fall back to the simulator behavior as it was in previous versions, you may set the value of the DoubleLengthZMKs parameter to false and then restart the simulator. This is also what we're doing in order to test commands such as the A6 command - you may note that in relevant unit tests we call the method SwitchToSingleLengthZMKs() in order to switch the simulator to single-length ZMKs and the method SwitchToDoubleLengthZMKs() to switch back to double-length ZMKs.

Jun 24, 2010 at 10:10 PM

Hi Nick,

Thank you for your explanation.  I changed the DoubleLengthZMKs to false and I can perform the generate key (A0) using single key or double key.  However, I have problem to perform the Import key (A6) using double key.  I changed the DoubleLengthZMKs to true and got the same error.  The same command works under version 0.8.5.

Here is the message:

Client from 127.0.0.1:2502 is connected
Client: 127.0.0.1:2502
Request: 3333A6001U71979DEB8587E2734F1E99D5DCAEF9ACU482C4E722BB0CF1845E1E5BD16310119U
Parsing header and code of message 3333A6001U71979DEB8587E2734F1E99D5DCAEF9ACU482C4E722BB0CF1845E1E5BD16310119U...
Searching for implementor of A6...
Found implementor ThalesSim.Core.HostCommands.BuildIn.ImportKey_A6, instantiating...
Calling AcceptMessage()...
Calling ConstructResponse()...
Exception while processing message
ThalesSim.Core.Exceptions.XInvalidData: Invalid data for 3DEncrypt
   at ThalesSim.Core.Cryptography.TripleDES.TripleDESDecrypt(HexKey key, String data) in C:\Documents and Settings\wpak1\Desktop\ThalesSim 0.9\ThalesCore\Cryptography\TripleDES.vb:line 66
   at ThalesSim.Core.HostCommands.BuildIn.ImportKey_A6.ConstructResponse() in C:\Documents and Settings\wpak1\Desktop\ThalesSim 0.9\ThalesCore\HostCommands\BuildIn\ImportKey_A6.vb:line 91
   at ThalesSim.Core.ThalesMain.WCMessageArrived(WorkerClient sender, Byte[]& b, Int32 len) in C:\Documents and Settings\wpak1\Desktop\ThalesSim 0.9\ThalesCore\ThalesMain.vb:line 716
Disconnecting client.
Calling Terminate()...
Implementor to Nothing
Client disconnected.

=== [A6], starts 16:57:23.579 =======
[Key,Value]=[Key,482C4E722BB0CF1845E1E5BD16310119]
[Key,Value]=[Key Scheme,U]
[Key,Value]=[Key Scheme LMK,U]
[Key,Value]=[Key Type,001]
[Key,Value]=[ZMK,71979DEB8587E2734F1E99D5DCAEF9AC]
[Key,Value]=[ZMK Scheme,U]

To explain why I need to mix the double and single keys is: I am doing a project that translate the messages between two systems.  One system using single length ZMK and the other system using double length ZMK.  Will the Thales rules stop me to perform such functions? 

Again, thank you very much for your help.

Regards,

William

Coordinator
Jun 24, 2010 at 10:37 PM
I see. What is the clear value of the U482C4E722BB0CF1845E1E5BD16310119 key?
Jun 24, 2010 at 11:52 PM

Hi Nick,

I don't have the clear value of the key, I got the key from the A0 command, here is the request and response:

5354A01001UU71979DEB8587E2734F1E99D5DCAEF9ACU
  decoded as:
    5354                                 (msg header)                  
    A0                                   (command code)                
    1                                    (mode - generated under ZMK)  
    001                                  (ZPK)                         
    U                                    (double length)               
    U71979DEB8587E2734F1E99D5DCAEF9AC    (ZMK cryptogram)  
    U                                    (double length)               
5354A100U0E07CDC0161A0DE3B5AA44DF227EC9DEU482C4E722BB0CF1845E1E5BD16310119ABDEBC
  decoded as:
    5354                                 (msg header)        
    A1                                   (response code) 
    00                                   (error code)    
    U0E07CDC0161A0DE3B5AA44DF227EC9DE    (Key under LMK) 
    U482C4E722BB0CF1845E1E5BD16310119    (Key under ZMK) 
    ABDEBC                               (Key Check Value)

Thank for helping me to look into it.

Regards,

William

Coordinator
Jun 25, 2010 at 12:35 AM
Edited Jun 25, 2010 at 12:37 AM

The problem is caused by the way A6 tries to find the clear key, specifically the way it decrypts the key under the ZMK. I think I've corrected the problem, can you please download the 49684 change set and verify the fix?

Regarding key translation to another system, I'm not 100% sure how the import command will behave under a real HSM but I'm under the impression that the import command will not allow a single-length ZMK if the HSM has been configured for double-length ZMKs from the CS command. However, you can do one of the following:

  • Temporarily disable double-length ZMKs and use the import command wiht the single-length ZMK.
  • I assume two or more custodians have the clear value of the ZMK and import it in the new HSM from the console to get the ZMK under the LMK. Assuming you have two or more 16-hex components that are XORed to form to the final ZMK, you can instruct the custodians to perform the key import process again but type in their components twice. In theory that should produce a double-length ZMK but since the first and second parts will be the same, the result will be the same as having a single-length ZMK - however, you'll be able to use it with the A6 command.
Jun 25, 2010 at 12:32 PM

Hi Nick,

Your 49684 change set corrected the problem.

Thanks a million.

Regards,

William