miti
/
linux-sgx-trts-modified


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142
							<!-- HTML header for doxygen 1.8.10-->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen 1.8.11"/>
<title>Intel&reg; Enhanced Privacy ID SDK: In-Depth Explanation of Revocation</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="navtree.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="resize.js"></script>
<script type="text/javascript" src="navtreedata.js"></script>
<script type="text/javascript" src="navtree.js"></script>
<script type="text/javascript">
  $(document).ready(initResizable);
  $(window).load(resizeHeight);
</script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
<link href="epidstyle.css" rel="stylesheet" type="text/css"/>
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
 <tbody>
 <tr style="height: 56px;">
  <td id="projectalign" style="padding-left: 0.5em;">
   <div id="projectname"><a 
                            onclick="storeLink('index.html')"
                            id="projectlink" 
                            class="index.html" 
                            href="index.html">Intel&reg; Enhanced Privacy ID SDK</a>
&#160;<span id="projectnumber">3.0.0</span>
</div>
  </td>
 </tr>
 </tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.8.11 -->
</div><!-- top -->
<div id="side-nav" class="ui-resizable side-nav-resizable">
  <div id="nav-tree">
    <div id="nav-tree-contents">
      <div id="nav-sync" class="sync"></div>
    </div>
  </div>
  <div id="splitbar" style="-moz-user-select:none;" 
       class="ui-resizable-handle">
  </div>
</div>
<script type="text/javascript">
$(document).ready(function(){initNavTree('Revocation.html','');});
</script>
<div id="doc-content">
<div class="header">
  <div class="headertitle">
<div class="title">In-Depth Explanation of Revocation </div>  </div>
</div><!--header-->
<div class="contents">
<div class="textblock"><p>This in-depth explanation covers the available options to revoke members in the Intel&reg; EPID scheme. It also provides details on how and why each type of revocation is used.</p>
<p><br />
</p>
<h1><a class="anchor" id="revocation_hierarchy"></a>
Revocation Hierarchy</h1>
<p>The verifier only checks the revocation lists if the message was signed with a member private key that corresponds with the correct group public key.</p>
<p>After concluding that the signer is a member of a group, the verifier proceeds to check for group based revocation, then member private key based revocation, then signature based revocation, then verifier blacklist revocation.</p>
<p>If the group is revoked, the verifier stops and reports it.</p>
<p>If the member private key is revoked, the verifier does not check the signature based revocation list.</p>
<h1><a class="anchor" id="revocation_versions"></a>
Revocation List Versions</h1>
<p>The verifier should periodically download the revocation lists (GroupRL, PrivRL, and SigRL) from the issuer and should use the latest revocation list during signature verification. The verifier should make sure that it gets the newest version of the revocation list during the update by checking RLver, the revocation list version number.</p>
<h1><a class="anchor" id="group_revocation"></a>
Group Based Revocation</h1>
<p>The group based revocation list, also called the GroupRL, has a list of revoked groups.</p>
<p>The issuer revokes the entire Intel&reg; EPID group by revoking the group public key. This results in the revocation of all members of a group.</p>
<h2><a class="anchor" id="group_revocation_reasons"></a>
Reasons the Issuer Might Revoke a Group</h2>
<p>Group revocation is expected to be a rare event and would only happen under limited criteria.</p>
<p>Reasons to revoke a group might include:</p>
<ul>
<li>A manufacturing defect causes the devices in the group to malfunction.</li>
<li>A subscriber terminates or violates the service agreement.</li>
<li>The Intel&reg; EPID issuing private key is exposed.</li>
<li>A critical vulnerability in a member implementation is identified.</li>
<li>Performance problems arise due to the expensive calculation of non-revoked proofs in signature based revocation, and a replacement group needs to be provisioned.</li>
</ul>
<h1><a class="anchor" id="private_key_revocation"></a>
Private Key Based Revocation</h1>
<p>Private key based revocation is used to revoke a compromised member. For example, the issuer can revoke a member if the member private key is exposed. When a compromised member private key is identified, it needs to be communicated to the issuer so that the issuer can revoke the member private key.</p>
<p>The issuer manages and publishes the member private key revocation list, also called the PrivRL, which contains member private keys that can no longer be used.</p>
<h2><a class="anchor" id="private_key_revocation_reasons"></a>
Reasons the Issuer Might Revoke a Member Private Key</h2>
<p>Depending on the use case, these member private keys could belong to members whose identity was compromised. For example, if a member private key is exposed online, allowing group members to be impersonated, then the compromised member private key is known, and the issuer revokes the member private key.</p>
<h1><a class="anchor" id="signature_revocation"></a>
Signature Based Revocation</h1>
<p>In signature based revocation, the issuer revokes a member based on the signature generated by the member. This revocation method is used when a member becomes subject to revocation criteria, but the issuer does not know the member's member private key.</p>
<p>The issuer manages and publishes the signature based revocation list, also called SigRL.</p>
<p>Entries in the SigRL cause signing to take longer for all members of the group. Therefore, when an issuer receives a signature revocation request, it first checks the signature against all entries in the private key based revocation list. If the signature was generated by a revoked private key, then it is not placed in the SigRL.</p>
<p>For the same reason, if the issuer were requested to revoke a private key, and the current SigRL had entries that corresponded to that private key, then the issuer would remove those entries from the SigRL.</p>
<h2><a class="anchor" id="revoked_proofs"></a>
Signing with Non-Revoked Proofs</h2>
<p>The verifier and the member both use the SigRL managed by the issuer (the method of obtaining the SigRL is outside the scope of the SDK). The member sends the verifier an Intel&reg; EPID signature that includes a number of non-revoked proofs that correspond to each revoked member in the SigRL.</p>
<p>In other words, the member mathematically proves that it is not any of the members who created the entries on the SigRL. One proof of non-revocation is generated by the member per entry in the SigRL. A single proof indicates the member in question cannot be the one who generated that signature in the SigRL.</p>
<p>For privacy, Intel&reg; EPID signatures that are generated by the same member are unlinkable by default. This means that the verifier cannot recognize if two Intel&reg; EPID signatures are from the same device. Therefore, multiple Intel&reg; EPID signatures on the SigRL could be from the same member.</p>
<h2><a class="anchor" id="signature_revocation_reasons"></a>
Reasons the Issuer Might Revoke an Intel® EPID Signature</h2>
<p>Reasons for revoking a signature might include the following:</p>
<ul>
<li>A member's signature is connected to an aspect of its behavior that indicates that the member is compromised.</li>
<li>A member repeatedly generates a constant signature for the same message. Per the Intel&reg; EPID algorithm, multiple signatures generated for the same challenge must be different.</li>
</ul>
<h1><a class="anchor" id="verifier_blacklist"></a>
Verifier Blacklist Revocation</h1>
<p>Verifier blacklist revocation is similar to signature based revocation in that it can be used to revoke a member using only a signature from a compromised member. Unlike the procedure for the signature based revocation list, members do not have to create non-revoked proofs for each entry on the verifier blacklist. Instead, the verifier relies on the member to use a basename when creating the signature (in other words, to use a name based signature) in order to determine if the same member created any of the signatures on the verifier blacklist.</p>
<p>For the verifier to determine that a member created an entry on the verifier blacklist, the member and verifier must use the same basename. The mechanism that allows them to agree on a basename is outside the scope of the SDK.</p>
<p>For more information on basenames, refer to <a class="el" href="Basenames.html#name_based">Name Based Signatures</a>.</p>
<p>The verifier adds a signature to a blacklist when the verifier does not want to trust the signer, but the verifier does not have enough reason to send a request to the issuer to revoke the member's signature.</p>
<p>When the verifier tracks a member using a basename, and decides the member is not trustworthy, the verifier can add the member's signature to the verifier blacklist.</p>
<h2><a class="anchor" id="verifier_blacklist_reasons"></a>
Reasons the Verifier Might Revoke an Intel® EPID Signature</h2>
<p>Reasons a verifier might revoke a member based on its tracked signatures include the following:</p>
<ul>
<li>A service provider receives a complaint about a customer. In this case, even though the verifier no longer trusts that customer to use the service, the verifier does not have a case to petition the issuer to revoke the member.</li>
<li>A service provider detects suspicious behavior that might indicate illegal activity or another violation of the service provider's policy. </li>
</ul>
</div></div><!-- contents -->
</div><!-- doc-content -->
<!-- HTML footer for doxygen 1.8.10-->
<!-- start footer part -->
<div id="nav-path" class="navpath"><!-- id is needed for treeview function! -->
  <ul>
    <li class="footer">
      &copy; 2016 Intel Corporation
    </li>
  </ul>
</div>
</body>
</html>