[tpm2] Re: Help implementing "OR" PCR policy using C lib

David Challener <david.c.challener at gmail.com>
Newsgroups dev.linux.lists.tpm2
Message-ID <CAAeabfah72=Xg-tHyuSfE_kYwMHNH8R=6SFhzh3hdkdVGYMOQA@mail.gmail.com>
PolicyauthorizeNV is orobably a better way to change an authorization. A
policy is place in an NV index. Then policyauthorizeNV points to that
index. Only the person with authorization to write the index can change it.
Caution: writing the NV index should requure a policysign to avoid the
remove index recreate index attack.

On Fri, Oct 29, 2021, 2:06 PM Roberts, William C <
william.c.roberts(a)intel.com> wrote:

> 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
> _______________________________________________
> 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, 6.7 KB)
<div dir="auto">PolicyauthorizeNV is orobably a better way to change an authorization. A policy is place in an NV index. Then policyauthorizeNV points to that index. Only the person with authorization to write the index can change it. Caution: writing the NV index should requure a policysign to avoid the remove index recreate index attack.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 29, 2021, 2:06 PM Roberts, William C &lt;<a href="mailto:[email protected]">[email protected]</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div 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 --&gt; Policy X --&gt; Policy Y .... --&gt; Get Digest = Digest A<br>
<br>
session B --&gt; Policy Q --&gt; Policy W .... --&gt; 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&#39;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&#39;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&#39;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&#39;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&#39;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&#39;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="m_652579158680338919appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="m_652579158680338919divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> <a href="mailto:[email protected]" target="_blank" rel="noreferrer">[email protected]</a> &lt;<a href="mailto:[email protected]" target="_blank" rel="noreferrer">[email protected]</a>&gt;<br>
<b>Sent:</b> Thursday, October 28, 2021 6:17 PM<br>
<b>To:</b> <a href="mailto:[email protected]" target="_blank" rel="noreferrer">[email protected]</a> &lt;<a href="mailto:[email protected]" target="_blank" rel="noreferrer">[email protected]</a>&gt;<br>
<b>Subject:</b> [tpm2] Help implementing &quot;OR&quot; PCR policy using C lib</font>
<div> </div>
</div>
<div><font size="2"><span style="font-size:11pt">
<div>I&#39;m implementing the sealing of a LUKS key against secure boot PCRs and am trying to enable firmware updates using Esys_PolicyOR(). I can&#39;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() &amp; 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 -- <a href="mailto:[email protected]" target="_blank" rel="noreferrer">[email protected]</a><br>
To unsubscribe send an email to <a href="mailto:[email protected]" target="_blank" rel="noreferrer">[email protected]</a><br>
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s<br>
</div>
</span></font></div>
</div>

_______________________________________________<br>
tpm2 mailing list -- <a href="mailto:[email protected]" target="_blank" rel="noreferrer">[email protected]</a><br>
To unsubscribe send an email to <a href="mailto:[email protected]" target="_blank" rel="noreferrer">[email protected]</a><br>
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s</blockquote></div>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.