vtpm_managerd and default passwords

vtpm_managerd and default passwords

[Luke]

Looking through the code in tools/vtpm_manager/manager/vtpm_manager.c, I
see that when you start the vtpm_manager for the first time, that it
takes ownership of the TPM and sets the password to be 20 unprintable
ascii characters (0xff 20 times).

This seems to work fine, but later, I want to create a key with the TPM.
 I've made a file using python, using:

a = ""
for i in range(20):
	a = a + "\xff"
open("ascii_file","w").write(a)

when I use that as the password, I still get TPM_AUTHFAIL.
This is using the createkey utility found at:
http://domino.research.ibm.com/comm/research_projects.nsf/pages/gsal.TCG.html/$FILE/tpm-3.2.0.tar.gz

It's pretty straightforward, so I'm wondering if I'm not understanding
how the SRK password gets set in actuality.

Any ideas on what I might be doing wrong/how to fix this?

Specifically, should vtpm_managerd take an SRK password as a parameter?
 This seems much more sane.  Does this exist already, and I've just
missed it?

Apologies if this is more xen-user than xen-devel.

RE: vtpm_managerd and default passwords

[Cihula, Joseph]

Luke <> scribbled on Thursday, July 26, 2007 7:57 AM:
> Looking through the code in
> tools/vtpm_manager/manager/vtpm_manager.c, I see that when you start
> the vtpm_manager for the first time, that it takes ownership of the
> TPM and sets the password to be 20 unprintable ascii characters (0xff
> 20 times). 
> 
> This seems to work fine, but later, I want to create a key with the
>  TPM. I've made a file using python, using:
> 
> a = ""
> for i in range(20):
> 	a = a + "\xff"
> open("ascii_file","w").write(a)
> 
> when I use that as the password, I still get TPM_AUTHFAIL.
> This is using the createkey utility found at:
>
http://domino.research.ibm.com/comm/research_projects.nsf/pages/gsal.TCG
.html/$FILE/tpm-3.2.0.tar.gz
> 
> It's pretty straightforward, so I'm wondering if I'm not understanding
> how the SRK password gets set in actuality.
> 
> Any ideas on what I might be doing wrong/how to fix this?

>From looking at the createkey utility source, it appears that it creates
a SHA-1 hash of the SRK auth provided on the command line.  The vTPM
Manager does not SHA the SRK auth.  So I think that you will need to add
another option to createkey that takes a provided auth as-is and then
try your file of all ff's.

> Specifically, should vtpm_managerd take an SRK password as a
>  parameter? This seems much more sane.  Does this exist already, and
> I've just missed it?

vTPM Manager is not intended to run alongside other TPM applications.
It does not use a TSS, and so it would not work well to try and use the
TPM simulataneously.  Similarly, it is not the expected use model that
once you have started using vTPM Manager that you will stop it, do some
things with the TPM, and then run it again.

Can you describe how you would like to use the TPM and vTPM?

> 
> Apologies if this is more xen-user than xen-devel.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: vtpm_managerd and default passwords

[Luke St.Clair]

On Jul 26, 2007, at 4:53 PM, Cihula, Joseph wrote:

>
>> From looking at the createkey utility source, it appears that it  
>> creates
> a SHA-1 hash of the SRK auth provided on the command line.  The vTPM
> Manager does not SHA the SRK auth.  So I think that you will need  
> to add
> another option to createkey that takes a provided auth as-is and then
> try your file of all ff's.
>
>> Specifically, should vtpm_managerd take an SRK password as a
>>  parameter? This seems much more sane.  Does this exist already, and
>> I've just missed it?
>
> vTPM Manager is not intended to run alongside other TPM applications.
> It does not use a TSS, and so it would not work well to try and use  
> the
> TPM simulataneously.  Similarly, it is not the expected use model that
> once you have started using vTPM Manager that you will stop it, do  
> some
> things with the TPM, and then run it again.
>
> Can you describe how you would like to use the TPM and vTPM?

My goal is to be able to do all of the following, though no two need  
to occur simultaneously

1) Run vtpm_managerd
2) create tpm keys in the dom0
3) create vtpm keys in the domu

Fixing the createkey worked like a charm in the dom0.

I still get TPM IOErrors in the domU though.

Can keys still be created using the VTPM?  Do they persist over  
multiple vtpm_managerd sessions?

If keys can be created, can anyone give an idea of how to do so?

-- 
Luke

Re: vtpm_managerd and default passwords

[Luke]

Luke St.Clair wrote:
> 
> On Jul 26, 2007, at 4:53 PM, Cihula, Joseph wrote:
> 
>>
>>> From looking at the createkey utility source, it appears that it creates
>> a SHA-1 hash of the SRK auth provided on the command line.  The vTPM
>> Manager does not SHA the SRK auth.  So I think that you will need to add
>> another option to createkey that takes a provided auth as-is and then
>> try your file of all ff's.
>>
>>> Specifically, should vtpm_managerd take an SRK password as a
>>>  parameter? This seems much more sane.  Does this exist already, and
>>> I've just missed it?
>>
>> vTPM Manager is not intended to run alongside other TPM applications.
>> It does not use a TSS, and so it would not work well to try and use the
>> TPM simulataneously.  Similarly, it is not the expected use model that
>> once you have started using vTPM Manager that you will stop it, do some
>> things with the TPM, and then run it again.
>>
>> Can you describe how you would like to use the TPM and vTPM?
> 
> My goal is to be able to do all of the following, though no two need to
> occur simultaneously
> 
> 1) Run vtpm_managerd
> 2) create tpm keys in the dom0
> 3) create vtpm keys in the domu
> 
> Fixing the createkey worked like a charm in the dom0.
> 
> I still get TPM IOErrors in the domU though.
> 
> Can keys still be created using the VTPM?  Do they persist over multiple
> vtpm_managerd sessions?
> 
> If keys can be created, can anyone give an idea of how to do so?

The solution was quite simple - I simply hadn't taken ownership of the
virtual TPM from within the domU.

It is fixed now, and works quite well.  I've yet to check persistence
over sessions, but at least key creation/loading is working.