[tpm2] Re: Help implementing "OR" PCR policy using C lib
Roberts, William C <william.c.roberts at intel.com>
| Newsgroups | dev.linux.lists.tpm2 |
|---|---|
| Message-ID | <SN6PR11MB3437132262D8B3A2CD130330B8879@SN6PR11MB3437.namprd11.prod.outlook.com> |
The best way to enable firmware updates is to use a mutable policy, either through policy signed (ie trust any policy signed with this key[1]) or through policyauthorizenv (Allows for mutable policies by referencing an NV Index [2]). The tpm2-tools have full examples in the man pages, and you can just play with the tools and then port it to ESYS. The tests in tpm2-tss also have examples of all the ESYS calls, but they are often times a bit contrived. When trying to create an OR policy, you essentially have: session A --> Policy X --> Policy Y .... --> Get Digest = Digest A session B --> Policy Q --> Policy W .... --> Get Digest = Digest B PolicyOR (Digest A, Digest B) = Final Digest Every policy event you run a session is an AND operation. So a policy can have 1 or more statements. You then take the digests of all those and feed it to the policy OR command which gives you the final digest that's used for policy value for an object. To satisfy the policy, you must run the commands on at least one branch that evaluates to true and pass all the same hashes back to policy OR to satisfy the policy. Its a bit awkward. So generally, you want to retain the policy hashes for each or branch, and then know which one you want to try or compute the hashes without using the TPM and only use the TPM for the branch that is going to be true... But it also depends on commands that are deferred evaluation (ie you don't know that fail until you try and auth with the policy) or ones that fail at command time. So, figuring out which branch you want to run isn't always easy. Thats probably a lot to unpack in there... I probably didn't help much to distill it. You can also use Feature API's JSON policy format to handle all of this for you a bit simpler. [1] Old policies are still valid unless you take other steps like adding in something like policynv against a counter you increment and that it's eq to the current value. Also has some of the issue of [2]. Compromising the nv index here means you can only reuse old policies. [2] The authvalue protecting the nvindex is very important, if that nv index is compromised your whole policy is compromised. [1] would require the signing key to get full control. ________________________________ From: michael.g.millsap(a)intel.com <michael.g.millsap(a)intel.com> Sent: Thursday, October 28, 2021 6:17 PM To: tpm2(a)lists.01.org <tpm2(a)lists.01.org> Subject: [tpm2] Help implementing "OR" PCR policy using C lib I'm implementing the sealing of a LUKS key against secure boot PCRs and am trying to enable firmware updates using Esys_PolicyOR(). I can't find any example code. I am currently doing an Esys_PolicyPCR(), followed by Esys_PolicyGetDigest() and then I seal against that digest. How would I add the PolicyOR step? Would I do an Esys_PolicyPCR() & Esys_PolicyGetDigest() for each set of PCR values, followed by a Esys_PolicyOR() and then another Esys_PolicyGetDigest() to get the final digest to seal against? What would the unseal process look like? Thanks, Mike _______________________________________________ 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
attachment.htm
(text/html, 5.6 KB)
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
The best way to enable firmware updates is to use a mutable policy, either through policy signed (ie trust any policy signed with this key[1]) or through policyauthorizenv (Allows for mutable policies by referencing an NV Index [2]). The tpm2-tools have full
examples in the man pages, and you can just play with the tools and then port it to ESYS. The tests in tpm2-tss also have examples of all the ESYS calls, but they are often times a bit contrived.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
When trying to create an OR policy, you essentially have:<br>
<br>
session A --> Policy X --> Policy Y .... --> Get Digest = Digest A<br>
<br>
session B --> Policy Q --> Policy W .... --> Get Digest = Digest B<br>
<br>
PolicyOR (Digest A, Digest B) = Final Digest</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Every policy event you run a session is an AND operation. So a policy can have 1 or more statements. You then take the digests of all those and feed it to the policy OR</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
command which gives you the final digest that's used for policy value for an object.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
To satisfy the policy, you must run the commands on at least one branch that evaluates to true and pass all the same hashes back to policy OR to satisfy the policy. Its a bit awkward. So generally, you want to retain the policy hashes for each or branch, and
then know which one you want to try or compute the hashes without using</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
the TPM and only use the TPM for the branch that is going to be true... But it also depends on commands that are deferred evaluation (ie you don't know that fail until you try and auth with the policy) or ones that fail at command time. So, figuring out which
branch you want to run isn't always easy.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thats probably a lot to unpack in there... I probably didn't help much to distill it. </div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
You can also use Feature API's JSON policy format to handle all of this for you a bit simpler.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
[1] Old policies are still valid unless you take other steps like adding in something like policynv against a counter you increment and that it's eq to the current value. Also has some of the issue of [2]. Compromising the nv index here means you can only reuse
old policies.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
[2] The authvalue protecting the nvindex is very important, if that nv index is compromised your whole policy is compromised. [1] would require the signing key to get full control.</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> [email protected] <[email protected]><br>
<b>Sent:</b> Thursday, October 28, 2021 6:17 PM<br>
<b>To:</b> [email protected] <[email protected]><br>
<b>Subject:</b> [tpm2] Help implementing "OR" PCR policy using C lib</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">I'm implementing the sealing of a LUKS key against secure boot PCRs and am trying to enable firmware updates using Esys_PolicyOR(). I can't find any example code. I am currently doing an Esys_PolicyPCR(), followed by Esys_PolicyGetDigest()
and then I seal against that digest. How would I add the PolicyOR step? Would I do an Esys_PolicyPCR() & Esys_PolicyGetDigest() for each set of PCR values, followed by a Esys_PolicyOR() and then another Esys_PolicyGetDigest() to get the final digest to seal
against? What would the unseal process look like?<br>
<br>
Thanks,<br>
Mike<br>
_______________________________________________<br>
tpm2 mailing list -- [email protected]<br>
To unsubscribe send an email to [email protected]<br>
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s<br>
</div>
</span></font></div>
</body>
</html>