Update PSA API specification to 1.0.0

Generated from the PSA Crypto API Dockerfile at tag psa-crypto-api-1.0.0
diff --git a/docs/html/overview/sample-arch.html b/docs/html/overview/sample-arch.html
new file mode 100644
index 0000000..855382d
--- /dev/null
+++ b/docs/html/overview/sample-arch.html
@@ -0,0 +1,212 @@
+
+<!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/html; charset=utf-8" />
+    <title>Sample architectures &#8212; PSA Crypto API 1.0.0 documentation</title>
+    <link rel="stylesheet" href="../_static/alabaster.css" type="text/css" />
+    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '../',
+        VERSION:     '1.0.0',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  true,
+        SOURCELINK_SUFFIX: '.txt'
+      };
+    </script>
+    <script type="text/javascript" src="../_static/jquery.js"></script>
+    <script type="text/javascript" src="../_static/underscore.js"></script>
+    <script type="text/javascript" src="../_static/doctools.js"></script>
+    <link rel="index" title="Index" href="../genindex.html" />
+    <link rel="search" title="Search" href="../search.html" />
+    <link rel="next" title="Library conventions" href="conventions.html" />
+    <link rel="prev" title="Functionality overview" href="functionality.html" />
+   
+  <link rel="stylesheet" href="../_static/custom.css" type="text/css" />
+  
+  <meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
+
+  </head>
+  <body>
+  
+
+    <div class="document">
+      <div class="documentwrapper">
+        <div class="bodywrapper">
+          <div class="body" role="main">
+            
+  <div class="section" id="sample-architectures">
+<span id="architectures"></span><h1>Sample architectures</h1>
+<p>This section describes some example architectures that can be used for
+implementations of the interface described in this specification. This list is
+not exhaustive and the section is entirely non-normative.</p>
+<div class="section" id="single-partition-architecture">
+<h2>Single-partition architecture</h2>
+<p>In the single-partition architecture, there is no security boundary inside the system. The
+application code can access all the system memory, including the memory used by
+the cryptographic services described in this specification. Thus, the
+architecture provides <a class="reference internal" href="goals.html#isolation"><span class="std std-ref">no isolation</span></a>.</p>
+<p>This architecture does not conform to the Arm <em>Platform Security Architecture
+Security Model</em>. However, it is useful for providing cryptographic services
+that use the same interface, even on devices that cannot support any security
+boundary. So, while this architecture is not the primary design goal of the API
+defined in the present specification, it is supported.</p>
+<p>The functions in this specification simply execute the underlying algorithmic
+code. Security checks can be kept to a minimum, since the cryptoprocessor cannot
+defend against a malicious application. Key import and export copy data inside
+the same memory space.</p>
+<p>This architecture also describes a subset of some larger systems, where the
+cryptographic services are implemented inside a high-security partition,
+separate from the code of the main application, though it shares this
+high-security partition with other platform security services.</p>
+</div>
+<div class="section" id="cryptographic-token-and-single-application-processor">
+<span id="isolated-cryptoprocessor"></span><h2>Cryptographic token and single-application processor</h2>
+<p>This system is composed of two partitions: one is a cryptoprocessor and the
+other partition runs an application. There is a security boundary between the
+two partitions, so that the application cannot access the cryptoprocessor,
+except through its public interface. Thus, the architecture provides
+<a class="reference internal" href="goals.html#isolation"><span class="std std-ref">cryptoprocessor isolation</span></a>. The cryptoprocessor has
+some non-volatile storage, a TRNG, and possibly, some cryptographic accelerators.</p>
+<p>There are a number of potential physical realizations: the cryptoprocessor might
+be a separate chip, a separate processor on the same chip, or a logical
+partition using a combination of hardware and software to provide the isolation.
+These realizations are functionally equivalent in terms of the offered software
+interface, but they would typically offer different levels of security
+guarantees.</p>
+<p>The PSA crypto API in the application processor consists of a thin layer of code
+that translates function calls to remote procedure calls in the cryptoprocessor.
+All cryptographic computations are, therefore, performed inside the
+cryptoprocessor. Non-volatile keys are stored inside the cryptoprocessor.</p>
+</div>
+<div class="section" id="cryptoprocessor-with-no-key-storage">
+<h2>Cryptoprocessor with no key storage</h2>
+<p>As in the <em><a class="reference internal" href="#isolated-cryptoprocessor"><span class="std std-ref">Cryptographic token and single-application processor</span></a></em> architecture, this system
+is also composed of two partitions separated by a security boundary and also
+provides <a class="reference internal" href="goals.html#isolation"><span class="std std-ref">cryptoprocessor isolation</span></a>.
+However, unlike the previous architecture, in this system, the cryptoprocessor
+does not have any secure, persistent storage that could be used to store
+application keys.</p>
+<p>If the cryptoprocessor is not capable of storing cryptographic material, then
+there is little use for a separate cryptoprocessor, since all data would have to
+be imported by the application.</p>
+<p>The cryptoprocessor can provide useful services if it is able to store at least
+one key. This might be a hardware unique key that is burnt to one-time
+programmable memory during the manufacturing of the device. This key can be used
+for one or more purposes:</p>
+<ul class="simple">
+<li>Encrypt and authenticate data stored in the application processor.</li>
+<li>Communicate with a paired device.</li>
+<li>Allow the application to perform operations with keys that are derived from
+the hardware unique key.</li>
+</ul>
+</div>
+<div class="section" id="multi-client-cryptoprocessor">
+<h2>Multi-client cryptoprocessor</h2>
+<p>This is an expanded variant of the <a class="reference internal" href="#isolated-cryptoprocessor"><span class="std std-ref">cryptographic token plus application
+architecture</span></a>. In this
+variant, the cryptoprocessor serves multiple applications that are mutually
+untrustworthy. This architecture provides <a class="reference internal" href="goals.html#isolation"><span class="std std-ref">caller
+isolation</span></a>.</p>
+<p>In this architecture, API calls are translated to remote procedure calls, which
+encode the identity of the client application. The cryptoprocessor carefully
+segments its internal storage to ensure that a client’s data is never leaked to
+another client.</p>
+</div>
+<div class="section" id="multi-cryptoprocessor-architecture">
+<h2>Multi-cryptoprocessor architecture</h2>
+<p>This system includes multiple cryptoprocessors. There are several reasons to
+have multiple cryptoprocessors:</p>
+<ul class="simple">
+<li>Different compromises between security and performance for different keys.
+Typically, this means a cryptoprocessor that runs on the same hardware as the
+main application and processes short-term secrets, a secure element or a
+similar separate chip that retains long-term secrets.</li>
+<li>Independent provisioning of certain secrets.</li>
+<li>A combination of a non-removable cryptoprocessor and removable ones, for
+example, a smartcard or HSM.</li>
+<li>Cryptoprocessors managed by different stakeholders who do not trust each
+other.</li>
+</ul>
+<p>The keystore implementation needs to dispatch each request to the correct
+processor. For example:</p>
+<ul class="simple">
+<li>All requests involving a non-extractable key must be processed in the
+cryptoprocessor that holds that key.</li>
+<li>Requests involving a persistent key must be processed in the cryptoprocessor
+that corresponds to the key’s lifetime value.</li>
+<li>Requests involving a volatile key might target a cryptoprocessor based on
+parameters supplied by the application, or based on considerations such as
+performance inside the implementation.</li>
+</ul>
+</div>
+</div>
+
+
+          </div>
+        </div>
+      </div>
+      <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
+        <div class="sphinxsidebarwrapper">
+  <h3><a href="../index.html">Table Of Contents</a></h3>
+  <ul>
+<li><a class="reference internal" href="#">Sample architectures</a><ul>
+<li><a class="reference internal" href="#single-partition-architecture">Single-partition architecture</a></li>
+<li><a class="reference internal" href="#cryptographic-token-and-single-application-processor">Cryptographic token and single-application processor</a></li>
+<li><a class="reference internal" href="#cryptoprocessor-with-no-key-storage">Cryptoprocessor with no key storage</a></li>
+<li><a class="reference internal" href="#multi-client-cryptoprocessor">Multi-client cryptoprocessor</a></li>
+<li><a class="reference internal" href="#multi-cryptoprocessor-architecture">Multi-cryptoprocessor architecture</a></li>
+</ul>
+</li>
+</ul>
+<div class="relations">
+<h3>Related Topics</h3>
+<ul>
+  <li><a href="../index.html">Documentation overview</a><ul>
+      <li>Previous: <a href="functionality.html" title="previous chapter">Functionality overview</a></li>
+      <li>Next: <a href="conventions.html" title="next chapter">Library conventions</a></li>
+  </ul></li>
+</ul>
+</div>
+  <div role="note" aria-label="source link">
+    <h3>This Page</h3>
+    <ul class="this-page-menu">
+      <li><a href="../_sources/overview/sample-arch.rst.txt"
+            rel="nofollow">Show Source</a></li>
+    </ul>
+   </div>
+<div id="searchbox" style="display: none" role="search">
+  <h3>Quick search</h3>
+    <form class="search" action="../search.html" method="get">
+      <div><input type="text" name="q" /></div>
+      <div><input type="submit" value="Go" /></div>
+      <input type="hidden" name="check_keywords" value="yes" />
+      <input type="hidden" name="area" value="default" />
+    </form>
+</div>
+<script type="text/javascript">$('#searchbox').show(0);</script>
+        </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="footer">
+      &copy; 2019-2020, Arm Limited or its affiliates. All rights reserved.
+      
+      |
+      Powered by <a href="http://sphinx-doc.org/">Sphinx 1.6.7</a>
+      &amp; <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.8</a>
+      
+      |
+      <a href="../_sources/overview/sample-arch.rst.txt"
+          rel="nofollow">Page source</a>
+    </div>
+
+    
+
+    
+  </body>
+</html>
\ No newline at end of file