2:44 p.m.
Folks,
Sorry for what might be an obvious question ...
What is the right command sequence to destroy keys, despite the users
possibly still having context files?
I read something about resetting the seed for a hierarchy through the
TPM2_Clear operation (presumably the tpm2_clear command can do this).
But that is too drastic.
I just want to kill off a single key and make it not usable. If I kill
off a parent presumably I can destroy a whole tree of keys. But that
just moves the problem, potentially up to a primary key.
What is the right way to do this?
I suppose there is some trick whereby you make a policy not able to be
satisfied. But then it seems you still need to retain state to prevent
the key from being used. I would rather just have all the key state be
gone and not able to be recreated.
Thanks,
-ted
--
Ted H. Kim, PhD
ted.h.kim(a)oracle.com
+1 310-258-7515
1:38 p.m.
Of the many ways, you can achieve this here is a way to do it with PolicyPcr --> Extend
a random value to debug-PCR (PCR#16) and create a key with policypcr referencing the debug
PCR.
As long as no other data is extended into the debug-PCR from this point on the key can be
used indefinitely as long as pcrpolicy is satisfied.
Extend the debug-PCR once again with another random value once ready to dump the key. The
only reason to use debug-PCR 16 is if you do not want to disturb other PCR values
potentially invalidating the authorization of other TPM objects.
Note: Instead of extending the debug-PCR with a random value, you can also achieve the
same result by simply issuing tpm2_pcrreset on the debug-PCR which will change the pcr
contents to 0. This will happen anyway when the system or TPM restarts.
12:46 p.m.
Imran,
Thanks for your response. Some questions and maybe some bigger issues:
So imagine we have hundreds or thousands of users/accounts. Each has
their own little tree of a primary key and the children underneath. Does
your suggestion scale to that level? I may be showing my ignorance, but
are there enough of those debug-PCRs?
Also if I get you correctly, the debug-PCRs are transient things in that
a system/TPM restart resets them.
Plus it sort of has what I feel is a not so good thing. When we get rid
of a key, we still need to keep the PCR around to block people from
using the deleted item. I feel like when we delete, intuitively we
should be getting rid of state.
Architecturally, I feel like some how we should be able to kill off the
primary key and thereby invalidate everything in its tree of objects.
And also, we should be able to prevent the exact same primary key from
being recreated. I guess I am not sure how to do this.
From trying the commands, it seems if we make the key persistent and
give the user a serialized handle (tpm2_evictcontrol -o), evicting the
key seems to be enough to invalidate the handle. But if the user has the
context file, we can't really prevent them from using the key. And so
how do we prevent them from getting a context file in the first place.
It looks like the way tpm2_create and tpm2_load work, you can't really
stop them from getting the context file. Well I have probably gone too
far down this line of thinking already.
But I am open whatever suggestions people have about how to destroy key
without having to do tpm2_clear.
Thanks,
-ted
On 5/30/20 1:38 PM, Imran Desai wrote:
Of the many ways, you can achieve this here is a way to do it with
PolicyPcr --> Extend a random value to debug-PCR (PCR#16) and create a key with
policypcr referencing the debug PCR.
As long as no other data is extended into the debug-PCR from this point on the key can be
used indefinitely as long as pcrpolicy is satisfied.
Extend the debug-PCR once again with another random value once ready to dump the key. The
only reason to use debug-PCR 16 is if you do not want to disturb other PCR values
potentially invalidating the authorization of other TPM objects.
Note: Instead of extending the debug-PCR with a random value, you can also achieve the
same result by simply issuing tpm2_pcrreset on the debug-PCR which will change the pcr
contents to 0. This will happen anyway when the system or TPM restarts.
_______________________________________________
tpm2 mailing list -- tpm2(a)lists.01.org
To unsubscribe send an email to tpm2-leave(a)lists.01.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
--
Ted H. Kim, PhD
ted.h.kim(a)oracle.com
+1 310-258-7515
2:27 p.m.
Ted,
Per your problem statement,
1. There is one unique primary object per user.
2. There is a multitude of such users.
3. There are multiple keys created under each of the primary object.
4. Invalidating the primary object would invalidate all the keys under the primary object
and thus the user.
To create unique primary keys you can add unique data to objects created with
tpm2_createprimary using the option "-u, --unique-data".
To create multiple keys simply run tpm2_create referencing the unique primary object as
the parent.
To be able to invalidate the unique primary object, have its authorization policy set to
policyNV referencing an NV index of type TPM_NT_BITS. The NV index is of size equal to the
number of bits that can accommodate the total number of users. Now, use tpm2_nvsetbits to
represent the invalidation of a specific key.
Example. You have 16 users. NV Index of size 2 bytes.
0x0000 ==> All keys are active.
tpm2_nvsetbits ==> 0x0001 ==> Key#1 invalidated since policyNV since operandB
changed and is not equal to 0000 anymore.
and so on...
315
days inactive
318
days old
3 comments
2 participants
participants (2)
-
Imran Desai -
ted.h.kim＠oracle.com