All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yasuhiro Hosoda <hosoda-yasuhiro at ntt-el.com>
To: tpm2@lists.01.org
Subject: Re: [tpm2] tpm2-tss question
Date: Wed, 24 Oct 2018 14:03:04 +0900	[thread overview]
Message-ID: <9d5b32cf-47e9-9421-14c3-76f4309fa111@ntt-el.com> (raw)
In-Reply-To: 9F48E1A823B03B4790B7E6E69430724D010EB03680@exch2010c.sit.fraunhofer.de

[-- Attachment #1: Type: text/plain, Size: 3383 bytes --]

I checked the following combinations with my test program.

tpm2-abrmd-1.1.0 and  tpm2-tss-1.3.0
tpm2-abrmd-1.2.0 and  tpm2-tss-1.3.0
tpm2-abrmd-1.3.0 and  tpm2-tss-1.3.0

They worked well and I am convinced that sessions (no matter if policy 
or hmac or trial)
  are not virtualized.

Still, with the TPM2.0-TSS-1.0 resource manager, it seems that
sessions are virtualized.
Does it mean that the TPM2.0-TSS-1.0 resource manager dose not
comply with "TCG TSS 2.0 TAB and Resource Manager specification"?

Regards,
> Yes, sessions (no matter if policy or hmac or trial) are noirtualized.
>
> I assume tpm2-abrmd to be conforming to the spec.
> If you find any deviation, they'll most happily fix them
>
> ------------------------------------------------------------------------
> *From:* Yasuhiro Hosoda [hosoda-yasuhiro(a)ntt-el.com]
> *Sent:* Wednesday, April 11, 2018 10:38
> *To:* Fuchs, Andreas; tpm2(a)lists.01.org
> *Subject:* Re: [tpm2] tpm2-tss question
>
> Thank you very much for your answer.
>
> I understand that the spec. is that the handles of policy session are
> not virtualized
>
> I check the source programs of the resource managers.
> (TPM2,0-TSS-1.0 and tpm2-abrmd-1.2.0)
> It seems that HMAC sessions and Policy sessions are handled
> in the same way. Do you have any comment comment about
> implementations?
>
>> According to the spec, only key and sequence handles are virtualized.
>>
>> Thus for PolicySecret, the virtual and TPM handles for policySession 
>> shall be the same.
>>
>> For keys and sequences (such as authHandle in PolicySecret) the 
>> virtual and TPM handles differ.
>> But instead of the handle the key's / sequence's public name is used 
>> within the hmac calculation.
>>
>> Hope this helps...
>>
>> ------------------------------------------------------------------------
>> *From:* tpm2 [tpm2-bounces(a)lists.01.org] on behalf of Yasuhiro Hosoda 
>> [hosoda-yasuhiro(a)ntt-el.com]
>> *Sent:* Wednesday, April 11, 2018 08:11
>> *To:* william.c.roberts(a)intel.com; tpm2(a)lists.01.org
>> *Subject:* Re: [tpm2] tpm2-tss question
>>
>> I have one finding about the RM and PolicySecret command,
>>
>> It says in page 10 of the following document
>> "TCG TSS 2.0 TAB and Resource Manager specification"
>> https://trustedcomputinggroup.org/wp-content/uploads/TSS-2.0-TAB-Resource-Manager-SpecVer1.0-Rev18_review_END030918.pdf
>> that
>> "
>> The RM performs a mapping from the (unchanging) virtual handle to the 
>> (currently assigned) TPM
>> handle. It replaces the virtual handle with the TPM handle in the TPM 
>> command packet.
>>
>> NOTE: The TPM 2.0 library specification excludes the handle from 
>> command stream HMAC calculations to enable this
>> substitution."
>> This means that if the virtual handle and the (currently assigned) 
>> TPM differs,
>> the HMAC calculations for most of the commands go well.
>>
>> But, the PolicySecret command takes the policy handle to extend as a 
>> parameter for HMAC.
>> If, the virtual handle and the (currently assigned) TPM differs, the 
>> HMAC calculations
>> for this command doesn't go well and produces the error code 0x98e.
>> Is my understanding right?
>> If so, is there any workaround?
>>
>> Thank you in advance.
>
-----
  Yasuhiro Hosoda

NTT Electronics Corporation (NEL)


[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 7955 bytes --]

             reply	other threads:[~2018-10-24  5:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-24  5:03 Yasuhiro Hosoda [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-07-23  4:44 [tpm2] tpm2-tss question Yasuhiro Hosoda
2018-04-11 11:18 Fuchs, Andreas
2018-04-11  8:38 Yasuhiro Hosoda
2018-04-11  6:26 Fuchs, Andreas
2018-04-11  6:11 Yasuhiro Hosoda
2018-02-28 22:54 Yasuhiro Hosoda
2018-02-08 13:26 Yasuhiro Hosoda
2018-01-29 22:37 Yasuhiro Hosoda
2018-01-25 18:30 Roberts, William C
2018-01-18 23:11 Yasuhiro Hosoda
2018-01-18 18:11 Roberts, William C
2018-01-18 14:43 Yasuhiro Hosoda
2018-01-14 21:51 Roberts, William C
2018-01-12  9:46 Yasuhiro Hosoda
2017-12-26 17:30 Roberts, William C
2017-12-14  6:58 Yasuhiro Hosoda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9d5b32cf-47e9-9421-14c3-76f4309fa111@ntt-el.com \
    --to=tpm2@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.