trustedjava-support

[Trustedjava-support] TSS Authorization error (0x3113) when running "aik_create"

[Nektarios I. <ine...@gm...>]

Hello,

I am going to try to keep this as short as possible! This regards the
problem
I encountered with using the "aik_create" subcommand of jTpmTools.

The following is the error message I receive from jTpmTools:
----------------------------------------------------------------------------------------------------------

03:58:28:774 [INFO] PrivacyCa::processRequest (212): AIK blob size: 1390
iaik.tc.tss.api.exceptions.tsp.TcTspException:

TSS Error:
error layer: 0x3000 (TSP)
error code (without layer): 0x0113
error code (full): 0x3113
error message: Authorization failed.

at iaik.tc.tss.impl.java.tsp.internal.TcTspCommon.validateRespAuth(Unknown
Source)
at
iaik.tc.tss.impl.java.tsp.internal.TcTspInternal.TspLoadKeyByBlob_Internal(
TcTspInternal.java:105)
at iaik.tc.tss.impl.java.tsp.TcRsaKey.loadKey(Unknown Source)
at iaik.tc.apps.jtt.aik.Client.activateIdentity(Client.java:153)
at iaik.tc.apps.jtt.aik.AikCreate.execute(AikCreate.java:322)
....
----------------------------------------------------------------------------------------------------------
The line that causes this error is this:

 aikKey_.loadKey(srk);

It is found in the activateIdentity() method of "Client.java"

I am using Mario Strasse's tpm_emulator_0.5. Upon inspecting the
emulator's output I discovered that despite the TSS error the AIK key does
in fact get successfully loaded into the TPM:

----------------------------------------------------------------------------------------------------------
../tpm/tpm_storage.c:518: Info: TPM_LoadKey()
../tpm/tpm_cmd_handler.c:4125: Info: TPM command succeeded
----------------------------------------------------------------------------------------------------------

Long story short, I discovered that

aikKey_.loadKey(srk); [in Client.java]

causes a call to

TspLoadKeyByBlob_Internal(..) [in TcTspInternal.java]

which in turn calls

validateRespAuth() [in TcTspCommon.java]

This is where the error lies. For some reason, the validation check by the
last method fails.

As I mentioned in previous posts, I am using the TSS_WELL_KNOWN_SECRET for
my SRK
so there is is no reason for my SRK being the problem. (I have even tried
altering various options
in the source code where the SRK object is created but with no luck)

After commenting the following in validateRespAuth() [in TcTspCommon.java]:

if (!outAuthValues.getHmac().getDigest().equals(resAuthDataExpected)) {
             //<Nektarios> if validation fails do nothing
            //throw new
TcTspException(TcTssErrors.TSS_E_TSP_AUTHFAIL);

        }

 I was able to get command to complete:
----------------------------------------------------------------------------------------------------------
aik_create -a theAIKsecret -o theBIGsecret -l myAIK_0
----------------------------------------------------------------------------------------------------------
01:03:39:971 [INFO] AikUtil::createEKCertificate (123):    created EK
certificate on-the-fly
01:03:40:049 [WARN] PrivacyCa::<clinit> (86):    could not load CLIENT
PrivacyCA default certificate (ok on server)
01:03:40:054 [INFO] Client::overrideCertificates (123):    overriding
default EK certificate used by TSS
01:03:40:852 [INFO] PrivacyCa::processRequest (191):    included EK
certificate size: 1065 bytes
01:03:40:854 [WARN] XKMSClientBase::<clinit> (85):    could not load XKMS
responder default certificate
01:03:40:857 [INFO] PrivacyCa::processRequest (192):    SubjAltName:
id:49465800,SLD9630TT1.1,id:0104
01:03:40:857 [INFO] PrivacyCa::processRequest (199):    PE: not included
01:03:40:857 [INFO] PrivacyCa::processRequest (207):    CC: not included
01:03:40:889 [INFO] AikUtil::createPECertificate (176):    created PE
certificate on-the-fly
01:03:40:898 [INFO] AikUtil::createAIKCertificate (213):    created AIK
certificate on-the-fly
01:03:40:900 [INFO] PrivacyCa::processRequest (223):    AIK blob size: 1386
01:03:41:189 [INFO] AikCreate::execute (367):    AIK ActivateIdentity
succeeded!
01:03:41:191 [INFO] AikCreate::verifyAndPrintAikLabel (188):    received AIK
certificate with IdLabel: 'myAIK_0'
01:03:41:191 [INFO] AikCreate::execute (379):    AIK certificate written
into file: aik.cert
01:03:41:192 [INFO] AikCreate::execute (398):    AIK TPM key structure
written into file: aik.tpmkey
----------------------------------------------------------------------------------------------------------

And here's the TPM 's output:

----------------------------------------------------------------------------------------------------------
../tpm/tpm_storage.c:518: Info: TPM_LoadKey()
../tpm/tpm_cmd_handler.c:4125: Info: TPM command succeeded
..
.. (some output)
../tpm/tpm_identity.c:399: Info: TPM_ActivateIdentity()
../tpm/tpm_authorization.c:288: Info: tpm_verify_auth()
../tpm/tpm_authorization.c:288: Info: tpm_verify_auth()
../tpm/tpm_cmd_handler.c:4125: Info: TPM command succeeded
..
..(some output)
----------------------------------------------------------------------------------------------------------

The above raise a number of questions:

Why are the LoadKey() and ActivateIdentity() key successful in the TPM
emulator if
I skip the TSS validation? Is this expected?

What exactly is the purpose of validateRespAuth() ? What are the
2 hashes that is comparing? hashes of the SRK?

Best Regards,

Nektarios

[Trustedjava-support] TSS Authorization error (0x3113) when running "aik_create"

[Nektarios I. <ine...@gm...>]

 Hello,

>Yes, the SRK secret is currently hardwired in JTT to TSS_WELL_KNOWN_SECRET,
>this should be a command line option. However, if the SRK secret is wrong
the
>error would come from the TPM layer during CollateIdentity (because loading
>of the key fails)

Yes this is true. In fact, in some attempts I specified my own SRK secret
and intentionally
gave it wrong to jtt during "aik_create" and CollateIdentity complained
before ActivateIdentity
as expected.

>> What exactly is the purpose of validateRespAuth() ? What are the
>> 2 hashes that is comparing? hashes of the SRK?
>
>These are two different things, the secret used for the key itself and
>the hashing used for securing the communication with the TPM.

Hm.. from what I understand, validateRespAuth() compares two hash values
in the end. I have been printing the Hex strings of these two out and I can
see
the two hashes do not match, hence the exception given.

So what values affect the outcome of these two hashes? Can you give me more
details
on how the validateRespAuth works? (i.e what affects the two compared values

outAuthValues and resAuthDataExpected etc...). If  I'm not mistaken,
resAuthDataExpected is the re-calculated hash and outAuthValues is what is
collected
from the TPM ???

>It is the duty of both communication endpoints, TPM and TSS to check
> whether the exchange has been tampered with. If you just override
> the check in the TSS, well, of course it always works.
>Exactly.
>One way to debug this problem is to add debut statements to the
>TcTspInternal.TspLoadKeyByBlob_Internal method. You could do hexdumps of
the
>data being sent to the TPM and received from the TPM and compare this data
to
>the TPM spec.

OK I will try that as well.

>There is still no hint why it fails for you.
>TPMemu 0.5 + JTss 0.3, ok.
>Java version?
>32bit or 64bit Linux?
>Which Linux? GCC version? ...
>Maybe we can spot a difference...

My configuration is this:

* Tpm-emulator 0.5
* jTSS_0.1
* Java version:
    java version "1.6.0"
    Java(TM) SE Runtime Environment (build 1.6.0-b105)
    Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)
* 32-bit Fedora Core 6 Linux, Kernel 2.6.18-1.2798.fc6.i586
* GCC version: 4.1.2-13

If there are any other relevant info let me know and I will look it up.

Re: [Trustedjava-support] TSS Authorization error (0x3113) when running "aik_create"

[Martin P. <Mar...@ia...>]

Nektarios Ioannides wrote:
> As I mentioned in previous posts, I am using the TSS_WELL_KNOWN_SECRET for
> my SRK
> so there is is no reason for my SRK being the problem. (I have even tried
> altering various options
> in the source code where the SRK object is created but with no luck)

Yes, the SRK secret is currently hardwired in JTT to TSS_WELL_KNOWN_SECRET,
this should be a command line option. However, if the SRK secret is wrong the
error would come from the TPM layer during CollateIdentity (because loading
of the key fails)

> The above raise a number of questions:
> 
> Why are the LoadKey() and ActivateIdentity() key successful in the TPM
> emulator if
> I skip the TSS validation? Is this expected?
> 
> What exactly is the purpose of validateRespAuth() ? What are the
> 2 hashes that is comparing? hashes of the SRK?

These are two different things, the secret used for the key itself and
the hashing used for securing the communication with the TPM.

It is the duty of both communication endpoints, TPM and TSS to check
whether the exchange has been tampered with. If you just override
the check in the TSS, well, of course it always works.

There is still no hint why it fails for you.
TPMemu 0.5 + JTss 0.3, ok.
Java version?
32bit or 64bit Linux?
Which Linux? GCC version? ...
Maybe we can spot a difference...


HTH


-- 
Martin Pirker
IAIK, TU Graz

Re: [Trustedjava-support] TSS Authorization error (0x3113) when running "aik_create"

[Thomas W. <tc...@to...>]

Hello,

> Yes, the SRK secret is currently hardwired in JTT to TSS_WELL_KNOWN_SECRET,
> this should be a command line option. However, if the SRK secret is wrong
> the error would come from the TPM layer during CollateIdentity (because
> loading of the key fails)

Well - hardwired is probably not the right word. The default is 
TSS_WELL_KNOWN_SECRET but you can override it using the "-s" command line 
parameter.

> These are two different things, the secret used for the key itself and
> the hashing used for securing the communication with the TPM.

Correct.
However, there are some pitfalls behind the scenes. In TPM emulator there are 
some issues with the LoadKey2 function. jTSS therefore detects the emulator 
and falls back to the LoadKey function. This has been tested and is known to 
work.

> It is the duty of both communication endpoints, TPM and TSS to check
> whether the exchange has been tampered with. If you just override
> the check in the TSS, well, of course it always works.

Exactly.
One way to debug this problem is to add debut statements to the 
TcTspInternal.TspLoadKeyByBlob_Internal method. You could do hexdumps of the 
data being sent to the TPM and received from the TPM and compare this data to 
the TPM spec.

> There is still no hint why it fails for you.
> TPMemu 0.5 + JTss 0.3, ok.
> Java version?
> 32bit or 64bit Linux?
> Which Linux? GCC version? ...
> Maybe we can spot a difference...

Yes, a full list describing your setup would be helpful.

Regards,
-- 
Thomas Winkler
e-mail: tc...@to...