It's useful to be able to keep a copy of keys in multiple locations for backup purposes, and hence those keys have to be created migrateable. However, you then want to deploy thoses keys to their final useage locations and, ideally (in some circumatances) you want to be able to do this in such a way that that those keys cannot be further migtated (copied) from those final useage locations. Can this be done with TPM2.0? I looked and couldn't find anything on the subject.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been doing some of my own research into this, any what I have found is a bit confusing.
Firstly in the book "A Practical Guide to TPM 2.0" which has a familiar name in the authorship. ;-) Looking at the section 'Duplication' on p253, it mentions TPM2_DuplicationSelect and TPM2_DuplicateSelect. There is no mention of these in the spec, but the spec does mention TPM2_PolicyDuplicationSelect, so I assume this is a typo. However, it doesn't say how this is used in the context that I am looking for. For example, if I have a key that can currently be duplicated to anywhere, when I come to duplicate it, can I set a policy on it, such that it can only be duplicated to the parent I specify, before or as I duplicate it, so that when the key arrives at its detination and is imported, it can't be further duplicated elsewhere?
I am also looking at the book 'Trusted Computing Platforms: TPM2.0 in Context' pages 292-294 (from a Google search on the term TPM2_PolicyDuplicationSelect). This is a bit more confusing and seems to contradict the description 'Steps' on page 254-255 of the other book.
Also, a bit alarming, is the fact that keys can be created or imported with an encryptedDuplication object attribute set to clear. I have looked in the utils source code create.c and importpem.c and this attributes doesn't get a mention. Does this attribute default to being set?
I also notice in the set of utils, whilst there are many policyXXX.c files, there doesn't seem to be a policyduplicationselect.c or equivalent. Presumably, I would need to write this.
Any answers would be appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can't change a policy on a key (or any object or NV index).
The idea of TPM2_PolicyDuplicationSelect is that you can restrict the target parent, either at time of creation (if you know the parent), or at run time (through TPM2_PolicyAuthorize).
The way I understand the use case, use the inner wrapper when you're duplicating the key to a backup authority, then later to the target. The intermediary rewraps but cannot see the contents.
encryptedDuplication - the utilities are sample code for common use cases. They don't support every possible attribute. It's a tradeoff between user complexity and coverage. Modify as required.
There will (now) be a policyduplicationselect utility and sample scripts in the next release.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm.... I'm still not completely clear on how this is done and if it is possible.
Firstly, the backup is a bit of a red herring. Let's leave that out.
My (simplified down) scenario is this: I have a master key machine on which I create lots of keys to be re-assigned later. At a later date I decide I want to send one of the keys to a "user" machine, and we assume that the user has root access to that machine. What we need to be able to do is ensure that, having duplicated the key to that user machine, the user cannot further duplicate the key to another machine.
From (3) above, we will want to use TPM2_PolicyAuthorize when sending. However, once the key has been imported into the user machine, is that policy still in force so that the user cannot further duplicate the key? Or is this beyond what can be done with TPM2.0?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Does TPM2_PolicyDuplicationSelect do what you need? It permits selection of the target parent key. As long as the target parent key is fixed to a TPM, the child can't move further.
If you don't know the user machine in advance, TPM2_PolicyAuthorize can select the target key later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's useful to be able to keep a copy of keys in multiple locations for backup purposes, and hence those keys have to be created migrateable. However, you then want to deploy thoses keys to their final useage locations and, ideally (in some circumatances) you want to be able to do this in such a way that that those keys cannot be further migtated (copied) from those final useage locations. Can this be done with TPM2.0? I looked and couldn't find anything on the subject.
I have been doing some of my own research into this, any what I have found is a bit confusing.
Firstly in the book "A Practical Guide to TPM 2.0" which has a familiar name in the authorship. ;-) Looking at the section 'Duplication' on p253, it mentions TPM2_DuplicationSelect and TPM2_DuplicateSelect. There is no mention of these in the spec, but the spec does mention TPM2_PolicyDuplicationSelect, so I assume this is a typo. However, it doesn't say how this is used in the context that I am looking for. For example, if I have a key that can currently be duplicated to anywhere, when I come to duplicate it, can I set a policy on it, such that it can only be duplicated to the parent I specify, before or as I duplicate it, so that when the key arrives at its detination and is imported, it can't be further duplicated elsewhere?
I am also looking at the book 'Trusted Computing Platforms: TPM2.0 in Context' pages 292-294 (from a Google search on the term TPM2_PolicyDuplicationSelect). This is a bit more confusing and seems to contradict the description 'Steps' on page 254-255 of the other book.
Also, a bit alarming, is the fact that keys can be created or imported with an encryptedDuplication object attribute set to clear. I have looked in the utils source code create.c and importpem.c and this attributes doesn't get a mention. Does this attribute default to being set?
I also notice in the set of utils, whilst there are many policyXXX.c files, there doesn't seem to be a policyduplicationselect.c or equivalent. Presumably, I would need to write this.
Any answers would be appreciated.
Hmm.... I'm still not completely clear on how this is done and if it is possible.
Firstly, the backup is a bit of a red herring. Let's leave that out.
My (simplified down) scenario is this: I have a master key machine on which I create lots of keys to be re-assigned later. At a later date I decide I want to send one of the keys to a "user" machine, and we assume that the user has root access to that machine. What we need to be able to do is ensure that, having duplicated the key to that user machine, the user cannot further duplicate the key to another machine.
From (3) above, we will want to use TPM2_PolicyAuthorize when sending. However, once the key has been imported into the user machine, is that policy still in force so that the user cannot further duplicate the key? Or is this beyond what can be done with TPM2.0?
Does TPM2_PolicyDuplicationSelect do what you need? It permits selection of the target parent key. As long as the target parent key is fixed to a TPM, the child can't move further.
If you don't know the user machine in advance, TPM2_PolicyAuthorize can select the target key later.
Yes, I believe it does, and I think my question has been answered.
I'll try it out and see...