TPM 32-bit key handles

Question

I've been exploring the TPM world and have tried out a few different libraries (i.e. Trousers, jTSS, JSR321, and TPM/J). Based on a number of requirements TPM/J fits the bill and I'm able to accomplish the majority of the operations necessary like binding/unbinding, signing/verifying, etc.

However one issue that I have come across is the key handle. According to the specs issued by the Trusted Computing Group, 1.2 and 2.0, both declare that key handles are 32-bit values. When I run TPM/J and I load a key the TPM issues a key OUTSIDE of the 32-bit space.

For example if I run the following command:

sudo java edu.mit.csail.tpmj.tools.TPMLoadKey testkey.key SRK ""

I receive the following output:

Parsing command-line arguments ...

Using SRK as parent.
parentPwd = null, Encoded (NULL [no authorization]) = null

Read testkey.key ...

Loading the key into the TPM ...
keyHandle = 0xc5e94bf9

If my calculations (and some online conversion tools I found) are correct then the key handle above computes to 3,320,400,889 which is OUTSIDE 32-bits. I believe 32-bit signed values are limited to around 2 billion.

This becomes a problem because when I issue the following command:

sudo java -cp $CLASSPATH edu.mit.csail.tpmj.tools.TPMUnbind HelloWorld.txt.enc 0xc5e94bf9

I get the following output:

Parsing command-line arguments ...

Exception in thread "main" java.lang.NumberFormatException: For input string: "c5e94bf9"
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.lang.Integer.parseInt(Integer.java:484)
    at bayanihan.util.params.Params.getInt(Params.java:67)
    at edu.mit.csail.tpmj.tools.TPMUnbind.main(TPMUnbind.java:71)

Just as a sanity check if I use the TPMUnbind command above and wait until I load a key that can be handled by Java int type (i.e. falls within 32-bit range) then the command runs just fine.

Has anyone else encountered this? Thanks in advance.

Answer 1

0xc5e94bf9 is a 32 bit number.

In hexadecimal representation one 'digit' represents 4 bits. Thus a 8-bit number ranges from 0x00 to 0xFF. So 2 hex-digits, also called nibbles.

16 bit would be 0x0000 to 0xFFFF

And your case 32 bit: 0x00000000 to 0xFFFFFFFF

The link you found for signed integers states -2,147,483,648 to 2,147,483,647. If you interprete this as unsigned, it would be 0 to 4,294,967,296 in decimal representation. Thus 3,320,400,889 is in the range.

---

Now to the error you get: That's a bug in TPM/J. It uses

Integer.parseInt( s.substring( 2 ), 16 );

to parse the input string. The parseInt()-method does not work for hexadecimal numbers larger than 0x7FFFFFFF.