Blame - docs/html/general.html - mirror/mbed-crypto

blob: 0a76f6dc8f32cb2e628e8b7c8f4ed2dd02e8eed0 [file] [log] [blame]

Gilles Peskine	06995ff	2019-05-21 19:50:19 +0200	[diff] [blame^]	1
				2	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
				3	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
				4
				5	<html xmlns="http://www.w3.org/1999/xhtml">
				6	<head>
				7	<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
				8	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
				9	<title>Introduction — psa_crypto_api 1.0 beta3 documentation</title>
				10	<link rel="stylesheet" href="_static/alabaster.css" type="text/css" />
				11	<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
				12	<script type="text/javascript" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></script>
				13	<script type="text/javascript" src="_static/jquery.js"></script>
				14	<script type="text/javascript" src="_static/underscore.js"></script>
				15	<script type="text/javascript" src="_static/doctools.js"></script>
				16	<script type="text/javascript" src="_static/language_data.js"></script>
				17	<link rel="index" title="Index" href="genindex.html" />
				18	<link rel="search" title="Search" href="search.html" />
				19	<link rel="next" title="Implementation-specific definitions" href="from_doxygen.html" />
				20	<link rel="prev" title="PSA Cryptography API Specification" href="index.html" />
				21
				22	<link rel="stylesheet" href="_static/custom.css" type="text/css" />
				23
				24
				25	<meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
				26
				27	</head><body>
				28
				29
				30	<div class="document">
				31	<div class="documentwrapper">
				32	<div class="bodywrapper">
				33
				34
				35	<div class="body" role="main">
				36
				37	<div class="section" id="introduction">
				38	<h1>Introduction</h1>
				39	<p>Arm’s Platform Security Architecture (PSA) is a holistic set of threat
				40	models, security analyses, hardware and firmware architecture
				41	specifications, and an open source firmware reference implementation.
				42	PSA provides a recipe, based on industry best practice, that allows
				43	security to be consistently designed in, at both a hardware and firmware
				44	level.</p>
				45	<p>The PSA Cryptographic API (Crypto API) described in this document is an
				46	important PSA component that provides an interface to modern
				47	cryptographic primitives on resource-constrained devices. The interface
				48	is user-friendly, while still providing access to the primitives used in
				49	modern cryptography. It does not require that the user have access to
				50	the key material. Instead, it uses opaque key handles.</p>
				51	<p>This document is part of the PSA family of specifications. It defines an
				52	interface for cryptographic services, including cryptography primitives
				53	and a key storage functionality.</p>
				54	<p>This document includes:</p>
				55	<ul class="simple">
				56	<li>A <a class="reference external" href="#design-goals">rationale</a> for the design.</li>
				57	<li>A <a class="reference external" href="#functionality-overview">high-level overview of the
				58	functionality</a> provided by the interface.</li>
				59	<li>A <a class="reference external" href="#sample-architectures">description of typical architectures</a> of
				60	implementations for this specification.</li>
				61	<li>General considerations <a class="reference external" href="#implementation-considerations">for
				62	implementers</a> of this
				63	specification and <a class="reference external" href="#usage-considerations">for applications</a> that
				64	use the interface defined in this specification.</li>
				65	<li>A detailed definition of the API.</li>
				66	</ul>
				67	<p>Companion documents will define <em>profiles</em> for this specification. A
				68	profile is a minimum mandatory subset of the interface that a compliant
				69	implementation must provide.</p>
				70	</div>
				71	<div class="section" id="design-goals">
				72	<h1>Design goals</h1>
				73	<div class="section" id="suitable-for-constrained-devices">
				74	<h2>Suitable for constrained devices</h2>
				75	<p>The interface is suitable for a vast range of devices: from
				76	special-purpose cryptographic processors that process data with a
				77	built-in key, to constrained devices running custom application code,
				78	such as microcontrollers, and multi-application devices, such as
				79	servers. Consequentially, the interface is scalable and modular.</p>
				80	<ul class="simple">
				81	<li><em>Scalable</em>: you shouldn’t pay for functionality that you don’t need.</li>
				82	<li><em>Modular</em>: larger devices implement larger subsets of the same
				83	interface, rather than different interfaces.</li>
				84	</ul>
				85	<p>Because this specification is suitable for very constrained devices,
				86	including those where memory is very limited, all operations on
				87	unbounded amounts of data allow <em>multipart</em> processing, as long as the
				88	calculations on the data are performed in a streaming manner. This means
				89	that the application does not need to store the whole message in memory
				90	at one time.</p>
				91	<p>Memory outside the keystore boundary is managed by the application. An
				92	implementation of the interface is not required to retain any state
				93	between function calls, apart from the content of the keystore and other
				94	data that must be kept inside the keystore security boundary.</p>
				95	<p>The interface does not expose the representation of keys and
				96	intermediate data, except when required for interchange. This allows
				97	each implementation to choose optimal data representations.
				98	Implementations with multiple components are also free to choose which
				99	memory area to use for internal data.</p>
				100	</div>
				101	<div class="section" id="a-keystore-interface">
				102	<h2>A keystore interface</h2>
				103	<p>The specification allows cryptographic operations to be performed on a
				104	key to which the application does not have direct access. Except where
				105	required for interchange, applications access all keys indirectly, by a
				106	handle. The key material corresponding to that handle can reside inside
				107	a security boundary that prevents it from being extracted, except as
				108	permitted by a policy that is defined when the key is created.</p>
				109	</div>
				110	<div class="section" id="optional-isolation">
				111	<h2>Optional isolation</h2>
				112	<p>Implementations can isolate the cryptoprocessor from the calling
				113	application, and can further isolate multiple calling applications. The
				114	interface allows the implementation to be separated between a frontend
				115	and a backend. In an isolated implementation, the frontend is the part
				116	of the implementation that is located in the same isolation boundary as
				117	the application, which the application accesses by function calls. The
				118	backend is the part of the implementation that is located in a different
				119	environment, which is protected from the frontend. Various technologies
				120	can provide protection, for example:</p>
				121	<ul class="simple">
				122	<li>Process isolation in an operating system.</li>
				123	<li>Partition isolation, either with a virtual machine or a partition
				124	manager.</li>
				125	<li>Physical separation between devices.</li>
				126	</ul>
				127	<p>Communication between the frontend and backend is beyond the scope of
				128	this specification.</p>
				129	<p>In an isolated implementation, the backend can serve more than one
				130	implementation instance. In this case, a single backend communicates
				131	with multiple instances of the frontend. The backend must enforce
				132	<strong>caller isolation</strong>: it must ensure that assets of one frontend are not
				133	visible to any other frontend. How callers are identified is beyond the
				134	scope of this specification. An implementation that provides caller
				135	isolation must document how callers are identified. An implementation
				136	that provides isolation must document any implementation-specific
				137	extension of the API that enables frontend instances to share data in
				138	any form.</p>
				139	<p>In summary, there are three types of implementations:</p>
				140	<ul class="simple">
				141	<li>No isolation: there is no security boundary between the application
				142	and the cryptoprocessor. For example, a statically or dynamically
				143	linked library is an implementation with no isolation.</li>
				144	<li>Cryptoprocessor isolation: there is a security boundary between the
				145	application and the cryptoprocessor, but the cryptoprocessor does not
				146	communicate with other applications. For example, a cryptoprocessor
				147	chip that is a companion to an application processor is an
				148	implementation with cryptoprocessor isolation.</li>
				149	<li>Caller isolation: there are multiple application instances, with a
				150	security boundary between the application instances among themselves,
				151	as well as between the cryptoprocessor and the application instances.
				152	For example, a cryptography service in a multiprocess environment is
				153	an implementation with caller and cryptoprocessor isolation.</li>
				154	</ul>
				155	</div>
				156	<div class="section" id="choice-of-algorithms">
				157	<h2>Choice of algorithms</h2>
				158	<p>The specification defines a low-level cryptographic interface, where the
				159	caller explicitly chooses which algorithm and which security parameters
				160	they use. This is necessary to implement protocols that are inescapable
				161	in various use cases. The design of the interface enables applications
				162	to implement widely-used protocols and data exchange formats, as well as
				163	custom ones.</p>
				164	<p>As a consequence, all cryptographic functionality operates according to
				165	the precise algorithm specified by the caller. However, this does not
				166	apply to device-internal functionality, which does not involve any form
				167	of interoperability, such as random number generation. The specification
				168	does not include generic higher-level interfaces, where the
				169	implementation chooses the best algorithm for a purpose. However,
				170	higher-level libraries can be built on top of the PSA Crypto API.</p>
				171	<p>Another consequence is that the specification permits the use of
				172	algorithms, key sizes and other parameters that, while known to be
				173	insecure, may be necessary to support legacy protocols or legacy data.
				174	Where major weaknesses are known, the algorithm description give
				175	applicable warnings. However, the lack of a warning does not and cannot
				176	indicate that an algorithm is secure in all circumstances. Application
				177	developers should research the security of the algorithms that they plan
				178	to use to determine if the algorithms meet their requirements.</p>
				179	<p>The interface facilitates algorithm agility. As a consequence,
				180	cryptographic primitives are presented through generic functions with a
				181	parameter indicating the specific choice of algorithm. For example,
				182	there is a single function to calculate a message digest, which takes a
				183	parameter that identifies the specific hash algorithm.</p>
				184	</div>
				185	<div class="section" id="ease-of-use">
				186	<h2>Ease of use</h2>
				187	<p>The interface is designed to be as user-friendly as possible, given the
				188	aforementioned constraints on suitability for various types of devices
				189	and on the freedom to choose algorithms.</p>
				190	<p>In particular, the code flows are designed to reduce the chance of
				191	dangerous misuse. The interface makes it harder to misuse than to use
				192	correctly, and typical mistakes result in test failures, rather than
				193	subtle security issues. Implementations avoid leaking data when a
				194	function is called with invalid parameters, to the extent allowed by the
				195	C language and by implementation size constraints.</p>
				196	</div>
				197	<div class="section" id="example-use-cases">
				198	<h2>Example use cases</h2>
				199	<p>This section lists some of the use cases that were considered while
				200	designing this API. This list is not exhaustive, nor are all
				201	implementations required to support all use cases.</p>
				202	<div class="section" id="network-security-tls">
				203	<h3>Network Security (TLS)</h3>
				204	<p>The API provides everything needed to establish TLS connections on the
				205	device side: asymmetric key management inside a key store, symmetric
				206	ciphers, MAC, HMAC, message digests, and AEAD.</p>
				207	</div>
				208	<div class="section" id="secure-storage">
				209	<h3>Secure Storage</h3>
				210	<p>The API provides all primitives related to storage encryption, block or
				211	file-based, with master encryption keys stored inside a key store.</p>
				212	</div>
				213	<div class="section" id="network-credentials">
				214	<h3>Network Credentials</h3>
				215	<p>The API provides network credential management inside a key store, for
				216	example, for X.509-based authentication or pre-shared keys on enterprise
				217	networks.</p>
				218	</div>
				219	<div class="section" id="device-pairing">
				220	<h3>Device Pairing</h3>
				221	<p>The API provides support for key agreement protocols that are often used
				222	for secure pairing of devices over wireless channels. For example, the
				223	pairing of an NFC token or a Bluetooth device could make use of key
				224	agreement protocols upon first use.</p>
				225	</div>
				226	<div class="section" id="secure-boot">
				227	<h3>Secure Boot</h3>
				228	<p>The API provides primitives for use during firmware integrity and
				229	authenticity validation, during a secure or trusted boot process.</p>
				230	</div>
				231	<div class="section" id="attestation">
				232	<h3>Attestation</h3>
				233	<p>The API provides primitives used in attestation activities. Attestation
				234	is the ability for a device to sign an array of bytes with a device
				235	private key and return the result to the caller. There are several use
				236	cases: from attestation of the device state to the ability to generate a
				237	key pair and prove that it has been generated inside a secure key store.
				238	The API provides access to the algorithms commonly used for attestation.</p>
				239	</div>
				240	<div class="section" id="factory-provisioning">
				241	<h3>Factory Provisioning</h3>
				242	<p>Most IoT devices receive a unique identity during the factory
				243	provisioning process, or once deployed to the field. This API provides
				244	the APIs necessary for populating a device with keys that represent that
				245	identity.</p>
				246	</div>
				247	</div>
				248	</div>
				249	<div class="section" id="functionality-overview">
				250	<h1>Functionality overview</h1>
				251	<p>This section provides a high-level overview of the functionality
				252	provided by the interface defined in this specification. Refer to the
				253	API definition for a detailed description.</p>
				254	<p>Due to the modularity of the interface, almost every part of the library
				255	is optional. The only mandatory function is <code class="docutils literal notranslate"><span class="pre">psa_crypto_init</span></code>.</p>
				256	<div class="section" id="library-management">
				257	<h2>Library management</h2>
				258	<p>Before any use, applications must call <code class="docutils literal notranslate"><span class="pre">psa_crypto_init</span></code> to initialize
				259	the library.</p>
				260	</div>
				261	<div class="section" id="key-management">
				262	<h2>Key management</h2>
				263	<p>Applications always access keys via a handle. This allows keys to be
				264	non-extractable, that is, an application can perform operations using a
				265	key without having access to the key material. Non-extractable keys are
				266	bound to the device, can be rate-limited and can have their usage
				267	restricted by policies.</p>
				268	<p>Each key has a set of attributes that describe the key and the policy
				269	for using the key. A <code class="docutils literal notranslate"><span class="pre">psa_key_attributes_t</span></code> object contains all of the
				270	attributes, which is used when creating a key and when querying key
				271	attibutes.</p>
				272	<p>Each key has a <em>lifetime</em> that determines when the key material is
				273	destroyed. There are two types of lifetimes:
				274	<a class="reference external" href="#volatile-keys">volatile</a> and <a class="reference external" href="#persistent-keys">persistent</a>.</p>
				275	<div class="section" id="volatile-keys">
				276	<h3>Volatile keys</h3>
				277	<p>A <em>volatile</em> key is destroyed as soon as the application closes the
				278	handle to the key. When the application terminates, it conceptually
				279	closes all of its key handles. Conceptually, a volatile key is stored in
				280	RAM. Volatile keys have the lifetime <code class="docutils literal notranslate"><span class="pre">PSA_KEY_LIFETIME_VOLATILE</span></code>.</p>
				281	<p>To create a volatile key:</p>
				282	<ol class="arabic simple">
				283	<li>Populate a <code class="docutils literal notranslate"><span class="pre">psa_key_attributes_t</span></code> object with the key’s type, size,
				284	policy and other attributes.</li>
				285	<li>Create the key with <code class="docutils literal notranslate"><span class="pre">psa_import_key</span></code>, <code class="docutils literal notranslate"><span class="pre">psa_generate_key</span></code>,
				286	<code class="docutils literal notranslate"><span class="pre">psa_key_derivation_output_key</span></code> or <code class="docutils literal notranslate"><span class="pre">psa_copy_key</span></code>.</li>
				287	</ol>
				288	<p>To destroy a volatile key, call <code class="docutils literal notranslate"><span class="pre">psa_close_key</span></code> or <code class="docutils literal notranslate"><span class="pre">psa_destroy_key</span></code>
				289	(these functions are equivalent when called on a volatile key).</p>
				290	</div>
				291	<div class="section" id="persistent-keys">
				292	<h3>Persistent keys</h3>
				293	<p>A <em>persistent</em> key exists until it explicitly destroyed with
				294	<code class="docutils literal notranslate"><span class="pre">psa_destroy_key</span></code> or until it is wiped by the reset or destruction of
				295	the device.</p>
				296	<p>Each persistent key has a key identifier, which acts as a name for the
				297	key. Within an application, the key identifier corresponds to a single
				298	key. The application specifies the key identifier when the key is
				299	created, and uses the key identifier to obtain a handle to a persistent
				300	key that has already been created. If the implementation provides
				301	<a class="reference external" href="#optional-isolation">caller isolation</a>, then key identifiers are
				302	local to each application: the same key identifier in two applications
				303	corresponds to different keys.</p>
				304	<p>Persistent keys may be stored in different storage areas; this is
				305	indicated through different lifetime values. This specification defines
				306	a single lifetime value <code class="docutils literal notranslate"><span class="pre">PSA_KEY_LIFETIME_PERSISTENT</span></code> which
				307	corresponds to a default storage area. Implementations may define
				308	alternative lifetime values corresponding to different storage areas
				309	with different retention policies, or to secure elements with different
				310	security characteristics.</p>
				311	<p>To create a persistent key:</p>
				312	<ol class="arabic simple">
				313	<li>Populate a <code class="docutils literal notranslate"><span class="pre">psa_key_attributes_t</span></code> object with the key’s type, size,
				314	policy and other attributes.</li>
				315	<li>In the attributes object, set the desired lifetime and persistent
				316	identifier for the key.</li>
				317	<li>Create the key with <code class="docutils literal notranslate"><span class="pre">psa_import_key</span></code>, <code class="docutils literal notranslate"><span class="pre">psa_generate_key</span></code>,
				318	<code class="docutils literal notranslate"><span class="pre">psa_key_derivation_output_key</span></code> or <code class="docutils literal notranslate"><span class="pre">psa_copy_key</span></code>.</li>
				319	</ol>
				320	<p>To release memory resources associated with a key but keep the key in
				321	storage, call <code class="docutils literal notranslate"><span class="pre">psa_close_key</span></code>. To access an existing persistent key,
				322	call <code class="docutils literal notranslate"><span class="pre">psa_open_key</span></code> with the same key identifier used when creating
				323	the key.</p>
				324	<p>To destroy a persistent key, open it (if it isn’t already open) and call
				325	<code class="docutils literal notranslate"><span class="pre">psa_destroy_key</span></code>.</p>
				326	<p>The key lifetime and identifier are set when the key is created and
				327	cannot be changed without destroying the key first. If the original key
				328	permits copying, then the application can specify a different lifetime
				329	for the copy of the key.</p>
				330	</div>
				331	<div class="section" id="recommendations-of-minimum-standards-for-key-management">
				332	<h3>Recommendations of minimum standards for key management</h3>
				333	<p>Most implementations provide the function <code class="docutils literal notranslate"><span class="pre">psa_import_key</span></code>. The only
				334	exceptions are implementations that only give access to a key or keys
				335	that are provisioned by proprietary means, and do not allow the main
				336	application to use its own cryptographic material.</p>
				337	<p>Most implementations provide <code class="docutils literal notranslate"><span class="pre">psa_get_key_attributes</span></code> and the
				338	<code class="docutils literal notranslate"><span class="pre">psa_get_key_xxx</span></code> accessor functions, as they are easy to implement,
				339	and it is difficult to write applications and to diagnose issues without
				340	being able to check the metadata.</p>
				341	<p>Most implementations also provide <code class="docutils literal notranslate"><span class="pre">psa_export_public_key</span></code> if they
				342	support any asymmetric algorithm, since public-key cryptography often
				343	requires the delivery of a public key that is associated with a
				344	protected private key.</p>
				345	<p>Most implementations provide <code class="docutils literal notranslate"><span class="pre">psa_export_key</span></code>. However, highly
				346	constrained implementations that are designed to work only with
				347	short-term keys (no non-volatile storage), or only with long-term
				348	non-extractable keys, may omit this function.</p>
				349	</div>
				350	</div>
				351	<div class="section" id="usage-policies">
				352	<h2>Usage policies</h2>
				353	<p>All keys have an associated policy that regulates which operations are
				354	permitted on the key. Each key policy is a set of usage flags and a
				355	specific algorithm that is permitted with the key. The policy is part of
				356	the key attributes that are managed by a <code class="docutils literal notranslate"><span class="pre">psa_key_attributes_t</span></code>
				357	object.</p>
				358	<p>The usage flags are encoded in a bitmask, which has the type
				359	<code class="docutils literal notranslate"><span class="pre">psa_key_usage_t</span></code>. Three kinds of usage flag can be specified: * The
				360	extractable flag <code class="docutils literal notranslate"><span class="pre">PSA_KEY_USAGE_EXPORT</span></code> determines whether the key
				361	material can be extracted. * The copyable flag <code class="docutils literal notranslate"><span class="pre">PSA_KEY_USAGE_COPY</span></code>
				362	determines whether the key material can be copied into a new key, which
				363	can have a different lifetime or a more restrictive policy. * The usage
				364	flags <code class="docutils literal notranslate"><span class="pre">PSA_KEY_USAGE_ENCRYPT</span></code>, <code class="docutils literal notranslate"><span class="pre">PSA_KEY_USAGE_SIGN</span></code>, and so on
				365	determine whether the corresponding operation is permitted on the key.</p>
				366	<p>In addition to the usage bitmask, a policy specifies which algorithm is
				367	permitted with the key. This specification only defines policies that
				368	restrict keys to a single algorithm, which is in keeping with common
				369	practice and with security good practice.</p>
				370	<p>A highly constrained implementation may not be able to support all the
				371	policies that can be expressed through this interface. If an
				372	implementation cannot create a key with the required policy, it must
				373	return an appropriate error code when the key is created.</p>
				374	</div>
				375	<div class="section" id="symmetric-cryptography">
				376	<h2>Symmetric cryptography</h2>
				377	<p>This specification defines interfaces for message digests (hash
				378	functions), MAC (message authentication codes), symmetric ciphers and
				379	authenticated encryption with associated data (AEAD). For each type of
				380	primitive, the API includes two standalone functions (compute and
				381	verify, or encrypt and decrypt) as well as a series of functions that
				382	permit <a class="reference external" href="#multipart-operations">multipart operations</a>.</p>
				383	<p>The standalone functions are:</p>
				384	<ul class="simple">
				385	<li><code class="docutils literal notranslate"><span class="pre">psa_hash_compute</span></code> and <code class="docutils literal notranslate"><span class="pre">psa_hash_compare</span></code> to calculate the hash
				386	of a message or compare the hash of a message with a reference value.</li>
				387	<li><code class="docutils literal notranslate"><span class="pre">psa_mac_compute</span></code> and <code class="docutils literal notranslate"><span class="pre">psa_mac_verify</span></code> to calculate the MAC of a
				388	message of compare the MAC with a reference value.</li>
				389	<li><code class="docutils literal notranslate"><span class="pre">psa_cipher_encrypt</span></code> and <code class="docutils literal notranslate"><span class="pre">psa_cipher_decrypt</span></code> to encrypt or
				390	decrypt a message using an unauthenticated symmetric cipher. The
				391	encryption function generates a random IV; to use a deterministic IV
				392	(which is not secure in general, but can be secure in some conditions
				393	that depend on the algorithm), use the multipart API.</li>
				394	<li><code class="docutils literal notranslate"><span class="pre">psa_aead_encrypt</span></code> and <code class="docutils literal notranslate"><span class="pre">psa_aead_decrypt</span></code> to encrypt/decrypt and
				395	authenticate a message using an AEAD algorithm. These functions
				396	follow the interface recommended by RFC 5116.</li>
				397	</ul>
				398	<div class="section" id="multipart-operations">
				399	<h3>Multipart operations</h3>
				400	<p>The API provides a multipart interface to hash, MAC, symmetric cipher
				401	and AEAD primitives. These interfaces process messages one chunk at a
				402	time, with the size of chunks determined by the caller. This allows the
				403	processing of messages that cannot be assembled in memory. To perform a
				404	multipart operation:</p>
				405	<ol class="arabic simple">
				406	<li>Allocate an operation object of the appropriate type. You can use any
				407	allocation strategy: stack, heap, static, etc.</li>
				408	<li>Initialize the operation object by one of the following methods:<ul>
				409	<li>Set it to all-bits-zero.</li>
				410	<li>Initialize it to logical zero.</li>
				411	<li>Assign the value of the associated macro <code class="docutils literal notranslate"><span class="pre">PSA_xxx_INIT</span></code>.</li>
				412	<li>Assign the result of calling the associated function
				413	<code class="docutils literal notranslate"><span class="pre">psa_xxx_init</span></code>.</li>
				414	</ul>
				415	</li>
				416	<li>Specify a key for the operation using the associated setup function:
				417	<code class="docutils literal notranslate"><span class="pre">psa_hash_setup</span></code>, <code class="docutils literal notranslate"><span class="pre">psa_mac_sign_setup</span></code>, <code class="docutils literal notranslate"><span class="pre">psa_mac_verify_setup</span></code>,
				418	<code class="docutils literal notranslate"><span class="pre">psa_cipher_encrypt_setup</span></code>, <code class="docutils literal notranslate"><span class="pre">psa_cipher_decrypt_setup</span></code>,
				419	<code class="docutils literal notranslate"><span class="pre">psa_aead_encrypt_setup</span></code> or <code class="docutils literal notranslate"><span class="pre">psa_aead_decrypt_setup</span></code>.</li>
				420	<li>Provide additional parameters:<ul>
				421	<li>When encrypting data, generate or set an initialization vector
				422	(IV), nonce, or similar initial value such as an initial counter
				423	value.</li>
				424	<li>When decrypting, set the IV or nonce.</li>
				425	<li>For a symmetric cipher, to generate a random IV, which is
				426	recommended in most protocols, call <code class="docutils literal notranslate"><span class="pre">psa_cipher_generate_iv</span></code>. To
				427	set the IV, call <code class="docutils literal notranslate"><span class="pre">psa_cipher_set_iv</span></code>.</li>
				428	<li>For AEAD, call <code class="docutils literal notranslate"><span class="pre">psa_aead_generate_nonce</span></code> or
				429	<code class="docutils literal notranslate"><span class="pre">psa_aead_set_nonce</span></code>.</li>
				430	</ul>
				431	</li>
				432	<li>Call the associated update function on successive chunks of the
				433	message: <code class="docutils literal notranslate"><span class="pre">psa_hash_update</span></code>, <code class="docutils literal notranslate"><span class="pre">psa_mac_update</span></code>,
				434	<code class="docutils literal notranslate"><span class="pre">psa_cipher_update</span></code>, <code class="docutils literal notranslate"><span class="pre">psa_aead_update_ad</span></code> or <code class="docutils literal notranslate"><span class="pre">psa_aead_update</span></code>.</li>
				435	<li>At the end of the message, call the applicable finishing function.
				436	There are three kinds of finishing function, depending on what to do
				437	with the verification tag.<ul>
				438	<li>Unauthenticated encryption and decryption does not involve a
				439	verification tag. Call <code class="docutils literal notranslate"><span class="pre">psa_cipher_finish</span></code>.</li>
				440	<li>To calculate the digest or MAC or authentication tag of a message,
				441	call the associated function to calculate and output the
				442	verification tag: <code class="docutils literal notranslate"><span class="pre">psa_hash_finish</span></code>, <code class="docutils literal notranslate"><span class="pre">psa_mac_sign_finish</span></code> or
				443	<code class="docutils literal notranslate"><span class="pre">psa_aead_finish</span></code>.</li>
				444	<li>To verify the digest or MAC of a message against a reference value
				445	or to verify the authentication tag at the end of AEAD decryption,
				446	call the associated function to compare the verification tag with
				447	the reference value: <code class="docutils literal notranslate"><span class="pre">psa_hash_verify</span></code>,
				448	<code class="docutils literal notranslate"><span class="pre">psa_mac_verify_finish</span></code> or <code class="docutils literal notranslate"><span class="pre">psa_aead_verify</span></code>.</li>
				449	</ul>
				450	</li>
				451	</ol>
				452	<p>Calling the setup function allocates resources inside the
				453	implementation. These resources are freed when calling the associated
				454	finishing function. In addition, each family of functions defines a
				455	function <code class="docutils literal notranslate"><span class="pre">psa_xxx_abort</span></code>, which can be called at any time to free the
				456	resources associated with an operation.</p>
				457	</div>
				458	<div class="section" id="authenticated-encryption">
				459	<h3>Authenticated encryption</h3>
				460	<p>Having a multipart interface to authenticated encryption raises specific
				461	issues.</p>
				462	<p>Multipart authenticated decryption produces partial results that are not
				463	authenticated. Applications must not use or expose partial results of
				464	authenticated decryption until <code class="docutils literal notranslate"><span class="pre">psa_aead_verify</span></code> has returned a
				465	success status, and must destroy all partial results without revealing
				466	them if <code class="docutils literal notranslate"><span class="pre">psa_aead_verify</span></code> returns a failure status. Revealing partial
				467	results (directly, or indirectly through the application’s behavior) can
				468	compromise the confidentiality of all inputs that are encrypted with the
				469	same key.</p>
				470	<p>For encryption, some common algorithms cannot be processed in a
				471	streaming fashion. For SIV mode, the whole plaintext must be known
				472	before the encryption can start; the multipart AEAD API is not meant to
				473	be usable with SIV mode. For CCM mode, the length of the plaintext must
				474	be known before the encryption can start; the application can call the
				475	function <code class="docutils literal notranslate"><span class="pre">psa_aead_set_lengths</span></code> to provide these lengths before
				476	providing input.</p>
				477	</div>
				478	</div>
				479	<div class="section" id="key-derivation">
				480	<h2>Key derivation</h2>
				481	<p>The specification defines a mechanism for key derivation that allows the
				482	output of the derivation to be split into multiple keys, as well as
				483	non-key outputs.</p>
				484	<p>In an implementation with <a class="reference external" href="#optional-isolation">isolation</a>, the
				485	intermediate state of the key derivation is not visible to the caller,
				486	and if an output of the derivation is a non-exportable key, then this
				487	output cannot be recovered outside the isolation boundary.</p>
				488	<div class="section" id="key-derivation-operations">
				489	<h3>Key derivation operations</h3>
				490	<p>A key derivation operation encodes a deterministic method to generate a
				491	finite stream of bytes. This data stream is computed by the
				492	cryptoprocessor and extracted in chunks. If two key derivation
				493	operations are constructed with the same parameters, then they should
				494	produce the same outputs.</p>
				495	<p>Some example uses of key derivation operations are:</p>
				496	<ul class="simple">
				497	<li>A key derivation function: initialized with a secret, a salt and
				498	other parameters.</li>
				499	<li>A key agreement function: initialized with a public key (peer key), a
				500	key pair (own key) and other parameters.</li>
				501	</ul>
				502	<p>Applications use the <code class="docutils literal notranslate"><span class="pre">psa_key_derivation_operation_t</span></code> type to create
				503	key derivation operations.</p>
				504	<p>The lifecycle of a key derivation operation is as follows:</p>
				505	<ol class="arabic simple">
				506	<li>Setup: construct a <code class="docutils literal notranslate"><span class="pre">psa_key_derivation_operation_t</span></code> object, and set
				507	its parameters and inputs. The setup phase determines the key
				508	derivation operation’s capacity, which is the maximum number of bytes
				509	that can be output from this key derivation operation.</li>
				510	<li>Output: read bytes from the stream defined by the key derivation
				511	operation. This can be done any number of times, until the stream is
				512	exhausted when its capacity has been reached. Each output step can
				513	either be used to populate a key object
				514	(<code class="docutils literal notranslate"><span class="pre">psa_key_derivation_output_key</span></code>), or to read some bytes and
				515	extract them as cleartext (<code class="docutils literal notranslate"><span class="pre">psa_key_derivation_output_bytes</span></code>).</li>
				516	<li>Terminate: clear the key derivation operation and release associated
				517	resources (<code class="docutils literal notranslate"><span class="pre">psa_key_derivation_abort</span></code>).</li>
				518	</ol>
				519	<p>A key derivation operation cannot be rewound. Once a part of the stream
				520	has been output, it cannot be output again. This ensures that the same
				521	part of the output will not be used for different purposes.</p>
				522	</div>
				523	<div class="section" id="key-derivation-function">
				524	<h3>Key derivation function</h3>
				525	<p>This specification defines functions to set up a key derivation. A key
				526	derivation consists of two parts:</p>
				527	<ol class="arabic simple">
				528	<li>Input collection. This is sometimes known as <em>extraction</em>: the
				529	operation “extracts” information from the inputs to generate a
				530	pseudorandom intermediate secret value.</li>
				531	<li>Output generation. This is sometimes known as <em>expansion</em>: the
				532	operation “expands” the intermediate secret value to the desired
				533	output length.</li>
				534	</ol>
				535	<p>To perform a key derivation:</p>
				536	<ol class="arabic simple">
				537	<li>Initialize a <code class="docutils literal notranslate"><span class="pre">psa_key_derivation_operation_t</span></code> object to zero or to
				538	<code class="docutils literal notranslate"><span class="pre">PSA_KEY_DERIVATION_OPERAITON_INIT</span></code>.</li>
				539	<li>Call <code class="docutils literal notranslate"><span class="pre">psa_key_derivation_setup</span></code> to select a key derivation
				540	algorithm.</li>
				541	<li>Call the functions <code class="docutils literal notranslate"><span class="pre">psa_key_derivation_input_bytes</span></code> and
				542	<code class="docutils literal notranslate"><span class="pre">psa_key_derivation_input_key</span></code>, or
				543	<code class="docutils literal notranslate"><span class="pre">psa_key_derivation_key_agreement</span></code> to provide the inputs to the key
				544	derivation algorithm. Many key derivation algorithms take multiple
				545	inputs; the “step” parameter to these functions indicates which input
				546	is being passed. The documentation for each key derivation algorithm
				547	describes the expected inputs for that algorithm.</li>
				548	<li>Call <code class="docutils literal notranslate"><span class="pre">psa_key_derivation_output_key</span></code> to create a derived key, or
				549	<code class="docutils literal notranslate"><span class="pre">psa_key_derivation_output_bytes</span></code> to export the derived data. These
				550	functions may be called multiple times to read successive output from
				551	the key derivation.</li>
				552	<li>Call <code class="docutils literal notranslate"><span class="pre">psa_key_derivation_abort</span></code> to release the key derivation
				553	operation memory.</li>
				554	</ol>
				555	<p>Here is an example of a use case where a master key is used to generate
				556	both a message encryption key and an IV for the encryption, and the
				557	derived key and IV are then used to encrypt a message.</p>
				558	<ol class="arabic simple">
				559	<li>Derive the message encryption material from the master key.<ol class="arabic">
				560	<li>Initialize a <code class="docutils literal notranslate"><span class="pre">psa_key_derivation_operation_t</span></code> object to zero or
				561	to <code class="docutils literal notranslate"><span class="pre">PSA_KEY_DERIVATION_OPERATION_INIT</span></code>.</li>
				562	<li>Call <code class="docutils literal notranslate"><span class="pre">psa_key_derivation_setup</span></code> with <code class="docutils literal notranslate"><span class="pre">PSA_ALG_HKDF</span></code> as the
				563	algorithm.</li>
				564	<li>Call <code class="docutils literal notranslate"><span class="pre">psa_key_derivation_input_key</span></code> with the step
				565	<code class="docutils literal notranslate"><span class="pre">PSA_KEY_DERIVATION_INPUT_SECRET</span></code> and the master key.</li>
				566	<li>Call <code class="docutils literal notranslate"><span class="pre">psa_key_derivation_input_bytes</span></code> with the step
				567	<code class="docutils literal notranslate"><span class="pre">PSA_KEY_DERIVATION_INPUT_INFO</span></code> and a public value that uniquely
				568	identifies the message.</li>
				569	<li>Populate a <code class="docutils literal notranslate"><span class="pre">psa_key_attributes_t</span></code> object with the derived
				570	message encryption key’s attributes.</li>
				571	<li>Call <code class="docutils literal notranslate"><span class="pre">psa_key_derivation_output_key</span></code> to create the derived
				572	message key.</li>
				573	<li>Call <code class="docutils literal notranslate"><span class="pre">psa_key_derivation_output_bytes</span></code> to generate the derived
				574	IV.</li>
				575	<li>Call <code class="docutils literal notranslate"><span class="pre">psa_key_derivation_abort</span></code> to release the key derivation
				576	operation memory.</li>
				577	</ol>
				578	</li>
				579	<li>Encrypt the message with the derived material.<ol class="arabic">
				580	<li>Initialize a <code class="docutils literal notranslate"><span class="pre">psa_cipher_operation_t</span></code> object to zero or to
				581	<code class="docutils literal notranslate"><span class="pre">PSA_CIPHER_OPERATION_INIT</span></code>.</li>
				582	<li>Call <code class="docutils literal notranslate"><span class="pre">psa_cipher_encrypt_setup</span></code> with the derived message
				583	encryption key.</li>
				584	<li>Call <code class="docutils literal notranslate"><span class="pre">psa_cipher_set_iv</span></code> using the derived IV retrieved above.</li>
				585	<li>Call <code class="docutils literal notranslate"><span class="pre">psa_cipher_update</span></code> one or more times to encrypt the
				586	message.</li>
				587	<li>Call <code class="docutils literal notranslate"><span class="pre">psa_cipher_finish</span></code> at the end of the message.</li>
				588	</ol>
				589	</li>
				590	<li>Call <code class="docutils literal notranslate"><span class="pre">psa_destroy_key</span></code> to clear the generated key.</li>
				591	</ol>
				592	</div>
				593	</div>
				594	<div class="section" id="asymmetric-cryptography">
				595	<h2>Asymmetric cryptography</h2>
				596	<p>The asymmetric cryptography part of this interface defines functions for
				597	asymmetric encryption, asymmetric signature and two-way key agreement.</p>
				598	<div class="section" id="asymmetric-encryption">
				599	<h3>Asymmetric encryption</h3>
				600	<p>Asymmetric encryption is provided through the functions
				601	<code class="docutils literal notranslate"><span class="pre">psa_asymmetric_encrypt</span></code> and <code class="docutils literal notranslate"><span class="pre">psa_asymmetric_decrypt</span></code>.</p>
				602	</div>
				603	<div class="section" id="hash-and-sign">
				604	<h3>Hash-and-sign</h3>
				605	<p>The signature and verification functions <code class="docutils literal notranslate"><span class="pre">psa_asymmetric_sign</span></code> and
				606	<code class="docutils literal notranslate"><span class="pre">psa_asymmetric_verify</span></code> take a hash as one of their inputs. This hash
				607	should be calculated with <code class="docutils literal notranslate"><span class="pre">psa_hash_setup</span></code>, <code class="docutils literal notranslate"><span class="pre">psa_hash_update</span></code> and
				608	<code class="docutils literal notranslate"><span class="pre">psa_hash_finish</span></code> before calling <code class="docutils literal notranslate"><span class="pre">psa_asymmetric_sign</span></code> or
				609	<code class="docutils literal notranslate"><span class="pre">psa_asymmetric_verify</span></code>. To determine which hash algorithm to use,
				610	call the macro <code class="docutils literal notranslate"><span class="pre">PSA_ALG_SIGN_GET_HASH</span></code> on the corresponding signature
				611	algorithm.</p>
				612	</div>
				613	<div class="section" id="key-agreement">
				614	<h3>Key agreement</h3>
				615	<p>This specification defines two functions for a Diffie-Hellman-style key
				616	agreement where each party combines its own private key with the peer’s
				617	public key.</p>
				618	<p>The recommended approach is to use a <a class="reference external" href="#key-derivation">key derivation
				619	operation</a> with the
				620	<code class="docutils literal notranslate"><span class="pre">psa_key_derivation_key_agreement</span></code> input function, which calculates a
				621	shared secret for the key derivation function.</p>
				622	<p>In case an application needs direct access to the shared secret, it can
				623	call <code class="docutils literal notranslate"><span class="pre">psa_raw_key_agreement</span></code> instead. Note that in general the shared
				624	secret is not directly suitable for use as a key because it is biased.</p>
				625	</div>
				626	</div>
				627	<div class="section" id="randomness-and-key-generation">
				628	<h2>Randomness and key generation</h2>
				629	<p>We strongly recommended that implementations include a random generator,
				630	consisting of a cryptographically secure pseudo-random generator
				631	(CSPRNG), which is adequately seeded with a cryptographic-quality
				632	hardware entropy source, commonly referred to as a true random number
				633	generator (TRNG). Constrained implementations may omit the random
				634	generation functionality if they do not implement any algorithm that
				635	requires randomness internally, and they do not provide a key generation
				636	functionality. For example, a special-purpose component for signature
				637	verification can omit this.</p>
				638	<p>Applications should use <code class="docutils literal notranslate"><span class="pre">psa_generate_key</span></code>,
				639	<code class="docutils literal notranslate"><span class="pre">psa_encrypt_generate_iv</span></code> or <code class="docutils literal notranslate"><span class="pre">psa_aead_generate_iv</span></code> to generate
				640	suitably-formatted random data, as applicable. In addition, the API
				641	includes a function <code class="docutils literal notranslate"><span class="pre">psa_generate_random</span></code> to generate and extract
				642	arbitrary random data.</p>
				643	</div>
				644	<div class="section" id="future-additions">
				645	<h2>Future additions</h2>
				646	<p>We plan to cover the following features in future drafts and editions of
				647	this specification:</p>
				648	<ul class="simple">
				649	<li>Single-shot functions for symmetric operations.</li>
				650	<li>Multi-part operations for hybrid cryptography. For example, this
				651	includes hash-and-sign for EdDSA, and hybrid encryption for ECIES.</li>
				652	<li>Key exchange and a more general interface to key derivation. This
				653	would enable an application to derive a non-extractable session key
				654	from non-extractable secrets, without leaking the intermediate
				655	material.</li>
				656	<li>Key wrapping mechanisms to extract and import keys in a protected
				657	form (encrypted and authenticated).</li>
				658	<li>Key discovery mechanisms. This would enable an application to locate
				659	a key by its name or attributes.</li>
				660	<li>Implementation capability description. This would enable an
				661	application to determine the algorithms, key types and storage
				662	lifetimes that the implementation provides.</li>
				663	<li>An ownership and access control mechanism allowing a multi-client
				664	implementation to have privileged clients that are able to manage
				665	keys of other clients.</li>
				666	</ul>
				667	</div>
				668	</div>
				669	<div class="section" id="sample-architectures">
				670	<h1>Sample architectures</h1>
				671	<p>This section describes some example architectures that can be used for
				672	implementations of the interface described in this specification. This
				673	list is not exhaustive and the section is entirely non-normative.</p>
				674	<div class="section" id="single-partition-architecture">
				675	<h2>Single-partition architecture</h2>
				676	<p>In this architecture, there is no security boundary inside the system.
				677	The application code may access all the system memory, including the
				678	memory used by the cryptographic services described in this
				679	specification. Thus, the architecture provides <a class="reference external" href="#optional-isolation">no
				680	isolation</a>.</p>
				681	<p>This architecture does not conform to the Arm <em>Platform Security
				682	Architecture Security Model</em>. However, it may be useful for providing
				683	cryptographic services that use the same interface, even on devices that
				684	cannot support any security boundary. So, while this architecture is not
				685	the primary design goal of the API defined in the present specification,
				686	it is supported.</p>
				687	<p>The functions in this specification simply execute the underlying
				688	algorithmic code. Security checks can be kept to a minimum, since the
				689	cryptoprocessor cannot defend against a malicious application. Key
				690	import and export copy data inside the same memory space.</p>
				691	<p>This architecture also describes a subset of some larger systems, where
				692	the cryptographic services are implemented inside a high-security
				693	partition, separate from the code of the main application, though it
				694	shares this high-security partition with other platform security
				695	services.</p>
				696	</div>
				697	<div class="section" id="cryptographic-token-and-single-application-processor">
				698	<h2>Cryptographic token and single-application processor</h2>
				699	<p>This system is composed of two partitions: one is a cryptoprocessor and
				700	the other partition runs an application. There is a security boundary
				701	between the two partitions, so that the application cannot access the
				702	cryptoprocessor, except through its public interface. Thus, the
				703	architecture provides <a class="reference external" href="#optional-isolation">cryptoprocessor
				704	isolation</a>. The cryptoprocessor has some
				705	nonvolatile storage, a TRNG, and possibly, some cryptographic
				706	accelerators.</p>
				707	<p>There are a number of potential physical realizations: the
				708	cryptoprocessor may be a separate chip, a separate processor on the same
				709	chip, or a logical partition using a combination of hardware and
				710	software to provide the isolation. These realizations are functionally
				711	equivalent in terms of the offered software interface, but they would
				712	typically offer different levels of security guarantees.</p>
				713	<p>The PSA crypto API in the application processor consists of a thin layer
				714	of code that translates function calls to remote procedure calls in the
				715	cryptoprocessor. All cryptographic computations are, therefore,
				716	performed inside the cryptoprocessor. Non-volatile keys are stored
				717	inside the cryptoprocessor.</p>
				718	</div>
				719	<div class="section" id="cryptoprocessor-with-no-key-storage">
				720	<h2>Cryptoprocessor with no key storage</h2>
				721	<p>As in the <a class="reference external" href="#cryptographic-token-and-single-application-processor">previous
				722	example</a>, this
				723	system is also composed of two partitions separated by a security
				724	boundary. Thus, this architecture also provides <a class="reference external" href="#optional-isolation">cryptoprocessor
				725	isolation</a>. However, unlike the previous
				726	architecture, in this system, the cryptoprocessor does not have any
				727	secure, persistent storage that could be used to store application keys.</p>
				728	<p>If the cryptoprocessor is not capable of storing cryptographic material,
				729	then there is little use for a separate cryptoprocessor, since all data
				730	would have to be imported by the application.</p>
				731	<p>The cryptoprocessor can provide useful services if it is able to store
				732	at least one key. This may be a hardware unique key that is burnt to
				733	one-time programmable memory during the manufacturing of the device.
				734	This key can be used for one or more purposes:</p>
				735	<ul class="simple">
				736	<li>Encrypt and authenticate data stored in the application processor.</li>
				737	<li>Communicate with a paired device.</li>
				738	<li>Allow the application to perform operations with keys that are
				739	derived from the hardware unique key.</li>
				740	</ul>
				741	</div>
				742	<div class="section" id="multi-client-cryptoprocessor">
				743	<h2>Multi-client cryptoprocessor</h2>
				744	<p>This is an expanded variant of the <a class="reference external" href="#cryptographic-token-and-single-application-processor">cryptographic token plus application
				745	architecture</a>.
				746	In this variant, the cryptoprocessor serves multiple applications that
				747	are mutually untrustworthy. This architecture provides <a class="reference external" href="#optional-isolation">caller
				748	isolation</a>.</p>
				749	<p>In this architecture, API calls are translated to remote procedure
				750	calls, which encode the identity of the client application. The
				751	cryptoprocessor carefully segments its internal storage to ensure that a
				752	client’s data is never leaked to another client.</p>
				753	</div>
				754	<div class="section" id="multi-cryptoprocessor-architecture">
				755	<h2>Multi-cryptoprocessor architecture</h2>
				756	<p>This system includes multiple cryptoprocessors. There are several
				757	reasons to have multiple cryptoprocessors:</p>
				758	<ul class="simple">
				759	<li>Different compromises between security and performance for different
				760	keys. Typically, this means a cryptoprocessor that runs on the same
				761	hardware as the main application and processes short-term secrets, a
				762	secure element or a similar separate chip that retains long-term
				763	secrets.</li>
				764	<li>Independent provisioning of certain secrets.</li>
				765	<li>A combination of a non-removable cryptoprocessor and removable ones,
				766	for example, a smartcard or HSM.</li>
				767	<li>Cryptoprocessors managed by different stakeholders who do not trust
				768	each other.</li>
				769	</ul>
				770	<p>The keystore implementation needs to dispatch each request to the
				771	correct processor. For example: * All requests involving a
				772	non-extractable key must be processed in the cryptoprocessor that holds
				773	that key. * Requests involving a persistent key must be processed in
				774	the cryptoprocessor that corresponds to the key’s lifetime value. *
				775	Requests involving a volatile key may target a cryptoprocessor based on
				776	parameters supplied by the application, or based on considerations such
				777	as performance inside the implementation.</p>
				778	</div>
				779	</div>
				780	<div class="section" id="library-conventions">
				781	<h1>Library conventions</h1>
				782	<div class="section" id="error-handling">
				783	<h2>Error handling</h2>
				784	<div class="section" id="return-status">
				785	<h3>Return status</h3>
				786	<p>Almost all functions return a status indication of type
				787	<code class="docutils literal notranslate"><span class="pre">psa_status_t</span></code>. This is an enumeration of integer values, with 0
				788	(<code class="docutils literal notranslate"><span class="pre">PSA_SUCCESS</span></code>) indicating successful operation and other values
				789	indicating errors. The exception is data structure accessor functions,
				790	which cannot fail. Such functions may return <code class="docutils literal notranslate"><span class="pre">void</span></code> or a data value.</p>
				791	<p>Unless specified otherwise, if multiple error conditions apply, an
				792	implementation is free to return any of the applicable error codes. The
				793	choice of error code is considered an implementation quality issue.
				794	Different implementations may make different choices, for example to
				795	favor code size over ease of debugging or vice versa.</p>
				796	<p>Note that if the behavior is undefined (for example, if a function
				797	receives an invalid pointer as a parameter), this specification makes no
				798	guarantee that the function will return an error. Implementations are
				799	encouraged to return an error or halt the application in a manner that
				800	is appropriate for the platform if the undefined behavior condition can
				801	be detected. However, application programmers should be aware that
				802	undefined behavior conditions cannot be detected in general.</p>
				803	</div>
				804	<div class="section" id="behavior-on-error">
				805	<h3>Behavior on error</h3>
				806	<p>All function calls must be implemented atomically:</p>
				807	<ul class="simple">
				808	<li>When a function returns a type other than <code class="docutils literal notranslate"><span class="pre">psa_status_t</span></code>, the
				809	requested action has been carried out.</li>
				810	<li>When a function returns the status <code class="docutils literal notranslate"><span class="pre">PSA_SUCCESS</span></code>, the requested
				811	action has been carried out.</li>
				812	<li>When a function returns another status of type <code class="docutils literal notranslate"><span class="pre">psa_status_t</span></code>, no
				813	action has been carried out. The content of the output parameters is
				814	undefined, but otherwise the state of the system has not changed,
				815	except as described below.</li>
				816	</ul>
				817	<p>In general, functions that modify the system state, for example,
				818	creating or destroying a key, must leave the system state unchanged if
				819	they return an error code. There are specific conditions that can result
				820	in different behavior:</p>
				821	<ul class="simple">
				822	<li>The status <code class="docutils literal notranslate"><span class="pre">PSA_ERROR_BAD_STATE</span></code> indicates that a parameter was not
				823	in a valid state for the requested action. This parameter may have
				824	been modified by the call and is now in an undefined state. The only
				825	valid action on an object in an undefined state is to abort it with
				826	the appropriate <code class="docutils literal notranslate"><span class="pre">psa_abort_xxx</span></code> function.</li>
				827	<li>The status <code class="docutils literal notranslate"><span class="pre">PSA_ERROR_INSUFFICIENT_CAPACITY</span></code> indicates that a key
				828	derivation object has reached its maximum capacity. The key
				829	derivation operation may have been modified by the call. Any further
				830	attempt to obtain output from the key derivation operation will
				831	return <code class="docutils literal notranslate"><span class="pre">PSA_ERROR_INSUFFICIENT_CAPACITY</span></code>.</li>
				832	<li>The status <code class="docutils literal notranslate"><span class="pre">PSA_ERROR_COMMUNICATION_FAILURE</span></code> indicates that the
				833	communication between the application and the cryptoprocessor has
				834	broken down. In this case, the cryptoprocessor must either finish the
				835	requested action successfully, or interrupt the action and roll back
				836	the system to its original state. Because it is often impossible to
				837	report the outcome to the application after a communication failure,
				838	this specification does not provide a way for the application to
				839	determine whether the action was successful.</li>
				840	<li>The statuses <code class="docutils literal notranslate"><span class="pre">PSA_ERROR_STORAGE_FAILURE</span></code>,
				841	<code class="docutils literal notranslate"><span class="pre">PSA_ERROR_HARDWARE_FAILURE</span></code> and <code class="docutils literal notranslate"><span class="pre">PSA_ERROR_TAMPERING_DETECTED</span></code>
				842	may indicate data corruption in the system state. When a function
				843	returns one of these statuses, the system state may have changed from
				844	its previous state before the function call, even though the function
				845	call failed.</li>
				846	<li>Some system states cannot be rolled back, for example, the internal
				847	state of the random number generator or the content of access logs.</li>
				848	</ul>
				849	<p>Unless otherwise documented, the content of output parameters is not
				850	defined when a function returns a status other than <code class="docutils literal notranslate"><span class="pre">PSA_SUCCESS</span></code>.
				851	Implementations should set output parameters to safe defaults to avoid
				852	leaking confidential data and limit risk, in case an application does
				853	not properly handle all errors.</p>
				854	</div>
				855	</div>
				856	<div class="section" id="parameter-conventions">
				857	<h2>Parameter conventions</h2>
				858	<div class="section" id="pointer-conventions">
				859	<h3>Pointer conventions</h3>
				860	<p>Unless explicitly stated in the documentation of a function, all
				861	pointers must be valid pointers to an object of the specified type.</p>
				862	<p>A parameter is considered a <strong>buffer</strong> if it points to an array of
				863	bytes. A buffer parameter always has the type <code class="docutils literal notranslate"><span class="pre">uint8_t</span> <span class="pre">*</span></code> or
				864	<code class="docutils literal notranslate"><span class="pre">const</span> <span class="pre">uint8_t</span> <span class="pre">*</span></code>, and always has an associated parameter indicating
				865	the size of the array. Note that a parameter of type <code class="docutils literal notranslate"><span class="pre">void</span> <span class="pre">*</span></code> is never
				866	considered a buffer.</p>
				867	<p>All parameters of pointer type must be valid non-null pointers, unless
				868	the pointer is to a buffer of length 0 or the function’s documentation
				869	explicitly describes the behavior when the pointer is null.
				870	Implementations where a null pointer dereference usually aborts the
				871	application, passing <code class="docutils literal notranslate"><span class="pre">NULL</span></code> as a function parameter where a null
				872	pointer is not allowed, should abort the caller in the habitual manner.</p>
				873	<p>Pointers to input parameters may be in read-only memory. Output
				874	parameters must be in writable memory. Output parameters that are not
				875	buffers must also be readable, and the implementation must be able to
				876	write to a non-buffer output parameter and read back the same value, as
				877	explained in the <a class="reference external" href="#stability-of-parameters">“Stability of
				878	parameters”</a> section.</p>
				879	</div>
				880	<div class="section" id="input-buffer-sizes">
				881	<h3>Input buffer sizes</h3>
				882	<p>For input buffers, the parameter convention is:</p>
				883	<ul class="simple">
				884	<li><code class="docutils literal notranslate"><span class="pre">const</span> <span class="pre">uint8_t</span> <span class="pre">*foo</span></code>: pointer to the first byte of the data. The
				885	pointer may be invalid if the buffer size is 0.</li>
				886	<li><code class="docutils literal notranslate"><span class="pre">size_t</span> <span class="pre">foo_length</span></code>: size of the buffer in bytes.</li>
				887	</ul>
				888	<p>The interface never uses input-output buffers.</p>
				889	</div>
				890	<div class="section" id="output-buffer-sizes">
				891	<h3>Output buffer sizes</h3>
				892	<p>For output buffers, the parameter convention is:</p>
				893	<ul class="simple">
				894	<li><code class="docutils literal notranslate"><span class="pre">uint8_t</span> <span class="pre">*foo</span></code>: pointer to the first byte of the data. The pointer
				895	may be invalid if the buffer size is 0.</li>
				896	<li><code class="docutils literal notranslate"><span class="pre">size_t</span> <span class="pre">foo_size</span></code>: the size of the buffer in bytes.</li>
				897	<li><code class="docutils literal notranslate"><span class="pre">size_t</span> <span class="pre">*foo_length</span></code>: on successful return, contains the length of
				898	the output in bytes.</li>
				899	</ul>
				900	<p>The content of the data buffer and of <code class="docutils literal notranslate"><span class="pre">*foo_length</span></code> on errors is
				901	unspecified, unless explicitly mentioned in the function description.
				902	They may be unmodified or set to a safe default. On successful
				903	completion, the content of the buffer between the offsets
				904	<code class="docutils literal notranslate"><span class="pre">*foo_length</span></code> and <code class="docutils literal notranslate"><span class="pre">foo_size</span></code> is also unspecified.</p>
				905	<p>Functions return <code class="docutils literal notranslate"><span class="pre">PSA_ERROR_BUFFER_TOO_SMALL</span></code> if the buffer size is
				906	insufficient to carry out the requested operation. The interface defines
				907	macros to calculate a sufficient buffer size for each operation that has
				908	an output buffer. These macros return compile-time constants if their
				909	arguments are compile-time constants, so they are suitable for static or
				910	stack allocation. Refer to an individual function’s documentation for
				911	the associated output size macro.</p>
				912	<p>Some functions always return exactly as much data as the size of the
				913	output buffer. In this case, the parameter convention changes to:</p>
				914	<ul class="simple">
				915	<li><code class="docutils literal notranslate"><span class="pre">uint8_t</span> <span class="pre">*foo</span></code>: pointer to the first byte of the output. The
				916	pointer may be invalid if the buffer size is 0.</li>
				917	<li><code class="docutils literal notranslate"><span class="pre">size_t</span> <span class="pre">foo_length</span></code>: the number of bytes to return in <code class="docutils literal notranslate"><span class="pre">foo</span></code> if
				918	successful.</li>
				919	</ul>
				920	</div>
				921	<div class="section" id="overlap-between-parameters">
				922	<h3>Overlap between parameters</h3>
				923	<p>Output parameters that are not buffers must not overlap with any input
				924	buffer or with any other output parameter. Otherwise, the behavior is
				925	undefined.</p>
				926	<p>Output buffers may overlap with input buffers. If this happens, the
				927	implementation must return the same result, as if the buffers did not
				928	overlap. In other words, the implementation must behave as if it had
				929	copied all the inputs into temporary memory, as far as the result is
				930	concerned. However, application developers should note that overlap
				931	between parameters may affect the performance of a function call.
				932	Overlap may also affect memory management security if the buffer is
				933	located in memory that the caller shares with another security context,
				934	as described in the <a class="reference external" href="#stability-of-parameters">“Stability of
				935	parameters”</a> section.</p>
				936	</div>
				937	<div class="section" id="stability-of-parameters">
				938	<h3>Stability of parameters</h3>
				939	<p>In some environments, it is possible for the content of a parameter to
				940	change while a function is executing. It may also be possible for the
				941	content of an output parameter to be read before the function
				942	terminates. This can happen if the application is multithreaded. In some
				943	implementations, memory can be shared between security contexts, for
				944	example, between tasks in a multitasking operating system, between a
				945	user land task and the kernel, or between the non-secure world and the
				946	secure world of a trusted execution environment. This section describes
				947	what implementations need or need not guarantee in such cases.</p>
				948	<p>Parameters that are not buffers are assumed to be under the caller’s
				949	full control. In a shared memory environment, this means that the
				950	parameter must be in memory that is exclusively accessible by the
				951	application. In a multithreaded environment, this means that the
				952	parameter may not be modified during the execution, and the value of an
				953	output parameter is undetermined until the function returns. The
				954	implementation may read an input parameter that is not a buffer multiple
				955	times and expect to read the same data. The implementation may write to
				956	an output parameter that is not a buffer and expect to read back the
				957	value that it last wrote. The implementation has the same permissions on
				958	buffers that overlap with a buffer in the opposite direction.</p>
				959	<p>In an environment with multiple threads or with shared memory, the
				960	implementation carefully accesses non-overlapping buffer parameters in
				961	order to prevent any security risk resulting from the content of the
				962	buffer being modified or observed during the execution of the function.
				963	In an input buffer that does not overlap with an output buffer, the
				964	implementation reads each byte of the input once, at most. The
				965	implementation does not read from an output buffer that does not overlap
				966	with an input buffer. Additionally, the implementation does not write
				967	data to a non-overlapping output buffer if this data is potentially
				968	confidential and the implementation has not yet verified that outputting
				969	this data is authorized.</p>
				970	</div>
				971	</div>
				972	<div class="section" id="key-types-and-algorithms">
				973	<h2>Key types and algorithms</h2>
				974	<p>Types of cryptographic keys and cryptographic algorithms are encoded
				975	separately. Each is encoded by using an integral type:
				976	<code class="docutils literal notranslate"><span class="pre">psa_key_type_t</span></code> and <code class="docutils literal notranslate"><span class="pre">psa_algorithm_t</span></code>, respectively.</p>
				977	<p>There is some overlap in the information conveyed by key types and
				978	algorithms. Both types contain enough information, so that the meaning
				979	of an algorithm type value does not depend on what type of key it is
				980	used with, and vice versa. However, the particular instance of an
				981	algorithm may depend on the key type. For example, the algorithm
				982	<code class="docutils literal notranslate"><span class="pre">PSA_ALG_GCM</span></code> can be instantiated as any AEAD algorithm using the GCM
				983	mode over a block cipher. The underlying block cipher is determined by
				984	the key type.</p>
				985	<p>Key types do not encode the key size. For example, AES-128, AES-192 and
				986	AES-256 share a key type <code class="docutils literal notranslate"><span class="pre">PSA_KEY_TYPE_AES</span></code>.</p>
				987	<div class="section" id="structure-of-key-and-algorithm-types">
				988	<h3>Structure of key and algorithm types</h3>
				989	<p>Both types use a partial bitmask structure, which allows the analysis
				990	and building of values from parts. However, the interface defines
				991	constants, so that applications do not need to depend on the encoding,
				992	and an implementation may only care about the encoding for code size
				993	optimization.</p>
				994	<p>The encodings follows a few conventions:</p>
				995	<ul class="simple">
				996	<li>The highest bit is a vendor flag. Current and future versions of this
				997	specification will only define values where this bit is clear.
				998	Implementations that wish to define additional
				999	implementation-specific values must use values where this bit is set,
				1000	to avoid conflicts with future versions of this specification.</li>
				1001	<li>The next few highest bits indicate the corresponding algorithm
				1002	category: hash, MAC, symmetric cipher, asymmetric encryption, and so
				1003	on.</li>
				1004	<li>The following bits identify a family of algorithms in a
				1005	category-dependent manner.</li>
				1006	<li>In some categories and algorithm families, the lowest-order bits
				1007	indicate a variant in a systematic way. For example, algorithm
				1008	families that are parametrized around a hash function encode the hash
				1009	in the 8 lowest bits.</li>
				1010	</ul>
				1011	</div>
				1012	</div>
				1013	<div class="section" id="concurrent-calls">
				1014	<h2>Concurrent calls</h2>
				1015	<p>In some environments, an application can make calls to the PSA crypto
				1016	API in separate threads. In such an environment, concurrent calls are
				1017	performed correctly, as if the calls were executed in sequence, provided
				1018	that they obey the following constraints:</p>
				1019	<ul class="simple">
				1020	<li>There is no overlap between an output parameter of one call and an
				1021	input or output parameter of another call. Overlap between input
				1022	parameters is permitted.</li>
				1023	<li>If a call modifies a key, then no other call must modify or use that
				1024	key. <em>Using</em>, in this context, includes all functions of multipart
				1025	operations using the key. Concurrent calls that merely use the same
				1026	key are permitted.</li>
				1027	<li>Concurrent calls must not use the same operation object.</li>
				1028	</ul>
				1029	<p>If any of these constraints are violated, the behavior is undefined.</p>
				1030	<p>Individual implementations may provide additional guarantees.</p>
				1031	</div>
				1032	</div>
				1033	<div class="section" id="implementation-considerations">
				1034	<h1>Implementation considerations</h1>
				1035	<div class="section" id="implementation-specific-aspects-of-the-interface">
				1036	<h2>Implementation-specific aspects of the interface</h2>
				1037	<div class="section" id="implementation-profile">
				1038	<h3>Implementation profile</h3>
				1039	<p>Implementations may implement a subset of the API and a subset of the
				1040	available algorithms. The implemented subset is known as the
				1041	implementation’s profile. The documentation for each implementation must
				1042	describe the profile that it implements. This specification’s companion
				1043	documents also define a number of standard profiles.</p>
				1044	</div>
				1045	<div class="section" id="implementation-specific-types">
				1046	<h3>Implementation-specific types</h3>
				1047	<p>This specification defines a number of platform-specific types, which
				1048	represent data structures whose content depends on the implementation.
				1049	These are C <code class="docutils literal notranslate"><span class="pre">struct</span></code> types. In the associated header files,
				1050	<code class="docutils literal notranslate"><span class="pre">crypto.h</span></code> declares the <code class="docutils literal notranslate"><span class="pre">struct</span></code> tags and <code class="docutils literal notranslate"><span class="pre">crypto_struct.h</span></code>
				1051	provides a definition for the structures.</p>
				1052	</div>
				1053	<div class="section" id="implementation-specific-macros">
				1054	<h3>Implementation-specific macros</h3>
				1055	<p>Some macros compute a result based on an algorithm or key type. This
				1056	specification provides a sample implementation of these macros, which
				1057	works for all standard types. If an implementation defines
				1058	vendor-specific algorithms or key types, then it must provide an
				1059	implementation for such macros that takes all relevant algorithms and
				1060	types into account. Conversely, an implementation that does not support
				1061	a certain algorithm or key type can define such macros in a simpler way
				1062	that does not take unsupported argument values into account.</p>
				1063	<p>Some macros define the minimum sufficient output buffer size for certain
				1064	functions. In some cases, an implementation is allowed to require a
				1065	buffer size that is larger than the theoretical minimum. An
				1066	implementation must define minimum-size macros in such a way that it
				1067	guarantees that the buffer of the resulting size is sufficient for the
				1068	output of the corresponding function. Refer to each macro’s
				1069	documentation for the applicable requirements.</p>
				1070	</div>
				1071	</div>
				1072	<div class="section" id="porting-to-a-platform">
				1073	<h2>Porting to a platform</h2>
				1074	<div class="section" id="platform-assumptions">
				1075	<h3>Platform assumptions</h3>
				1076	<p>This specification is designed for a C89 platform. The interface is
				1077	defined in terms of C macros, functions and objects.</p>
				1078	<p>The specification assumes 8-bit bytes, and “byte” and “octet” are used
				1079	synonymously.</p>
				1080	</div>
				1081	<div class="section" id="platform-specific-types">
				1082	<h3>Platform-specific types</h3>
				1083	<p>The specification makes use of some platform-specific types, which
				1084	should be defined in <code class="docutils literal notranslate"><span class="pre">crypto_platform.h</span></code> or by a header included in
				1085	this file. <code class="docutils literal notranslate"><span class="pre">crypto_platform.h</span></code> must define the following types:</p>
				1086	<ul class="simple">
				1087	<li><code class="docutils literal notranslate"><span class="pre">uint8_t</span></code>, <code class="docutils literal notranslate"><span class="pre">uint16_t</span></code>, <code class="docutils literal notranslate"><span class="pre">uint32_t</span></code>: unsigned integer types with
				1088	8, 16 and 32 value bits respectively. These may be the types defined
				1089	by the C99 header <code class="docutils literal notranslate"><span class="pre">stdint.h</span></code>.</li>
				1090	<li><code class="docutils literal notranslate"><span class="pre">psa_key_handle_t</span></code>: an unsigned integer type of the
				1091	implementation’s choice.</li>
				1092	</ul>
				1093	</div>
				1094	<div class="section" id="cryptographic-hardware-support">
				1095	<h3>Cryptographic hardware support</h3>
				1096	<p>Implementations are encouraged to make use of hardware accelerators
				1097	where available. A future version of this specification will define a
				1098	function interface that calls drivers for hardware accelerators and
				1099	external cryptographic hardware.</p>
				1100	</div>
				1101	</div>
				1102	<div class="section" id="security-requirements-and-recommendations">
				1103	<h2>Security requirements and recommendations</h2>
				1104	<div class="section" id="error-detection">
				1105	<h3>Error detection</h3>
				1106	<p>Implementations that provide isolation between the caller and the
				1107	cryptography processing environment must validate parameters to ensure
				1108	that the cryptography processing environment is protected from attacks
				1109	caused by passing invalid parameters.</p>
				1110	<p>Even implementations that do not provide isolation should strive to
				1111	detect bad parameters and fail-safe as much as possible.</p>
				1112	</div>
				1113	<div class="section" id="memory-cleanup">
				1114	<h3>Memory cleanup</h3>
				1115	<p>Implementations must wipe all sensitive data from memory when it is no
				1116	longer used. They should wipe this sensitive data as soon as possible.
				1117	In any case, all temporary data used during the execution of a function,
				1118	such as stack buffers, must be wiped before the function returns. All
				1119	data associated with an object, such as a multipart operation, must be
				1120	wiped, at the latest, when the object becomes inactive, for example,
				1121	when a multipart operation is aborted.</p>
				1122	<p>The rationale for this non-functional requirement is to minimize impact
				1123	if the system is compromised. If sensitive data is wiped immediately
				1124	after use, only data that is currently in use can be leaked. It does not
				1125	compromise past data.</p>
				1126	</div>
				1127	<div class="section" id="safe-outputs-on-error">
				1128	<h3>Safe outputs on error</h3>
				1129	<p>Implementations must ensure that confidential data is not written to
				1130	output parameters before validating that the disclosure of this
				1131	confidential data is authorized. This requirement is especially
				1132	important for implementations where the caller may share memory with
				1133	another security context, as described in the <a class="reference external" href="#stability-of-parameters">“Stability of
				1134	parameters”</a> section.</p>
				1135	<p>In most cases, the specification does not define the content of output
				1136	parameters when an error occurs. Implementations should try to ensure
				1137	that the content of output parameters is as safe as possible, in case an
				1138	application flaw or a data leak causes it to be used. In particular, Arm
				1139	recommends that implementations avoid placing partial output in output
				1140	buffers when an action is interrupted. The meaning of “safe as possible”
				1141	depends on the implementation, as different environments require
				1142	different compromises between implementation complexity, overall
				1143	robustness and performance. Some common strategies are to leave output
				1144	parameters unchanged, in case of errors, or zeroing them out.</p>
				1145	</div>
				1146	<div class="section" id="attack-resistance">
				1147	<h3>Attack resistance</h3>
				1148	<p>Cryptographic code tends to manipulate high-value secrets, from which
				1149	other secrets can be unlocked. As such, it is a high-value target for
				1150	attacks. There is a vast body of literature on attack types, such as
				1151	side channel attacks and glitch attacks. Typical side channels include
				1152	timing, cache access patterns, branch-prediction access patterns, power
				1153	consumption, radio emissions and more.</p>
				1154	<p>This specification does not specify particular requirements for attack
				1155	resistance. Therefore, implementers should consider the attack
				1156	resistance desired in each use case and design their implementation
				1157	accordingly. Security standards for attack resistance for particular
				1158	targets may be applicable in certain use cases.</p>
				1159	</div>
				1160	</div>
				1161	<div class="section" id="other-implementation-considerations">
				1162	<h2>Other implementation considerations</h2>
				1163	<div class="section" id="philosophy-of-resource-management">
				1164	<h3>Philosophy of resource management</h3>
				1165	<p>The specification allows most functions to return
				1166	<code class="docutils literal notranslate"><span class="pre">PSA_ERROR_INSUFFICIENT_MEMORY</span></code>. This gives implementations the
				1167	freedom to manage memory as they please.</p>
				1168	<p>Alternatively, the interface is also designed for conservative
				1169	strategies of memory management. An implementation may avoid dynamic
				1170	memory allocation altogether by obeying certain restrictions:</p>
				1171	<ul class="simple">
				1172	<li>Pre-allocate memory for a predefined number of keys, each with
				1173	sufficient memory for all key types that can be stored.</li>
				1174	<li>For multipart operations, in an implementation without isolation,
				1175	place all the data that needs to be carried over from one step to the
				1176	next in the operation object. The application is then fully in
				1177	control of how memory is allocated for the operation.</li>
				1178	<li>In an implementation with isolation, pre-allocate memory for a
				1179	predefined number of operations inside the cryptoprocessor.</li>
				1180	</ul>
				1181	<!--
				1182	#### Inclusion of algorithms
				1183
				1184	Inline algorithm-generic functions into specialized functions at compile/link time
				1185	--></div>
				1186	</div>
				1187	</div>
				1188	<div class="section" id="usage-considerations">
				1189	<h1>Usage considerations</h1>
				1190	<div class="section" id="security-recommendations">
				1191	<h2>Security recommendations</h2>
				1192	<div class="section" id="always-check-for-errors">
				1193	<h3>Always check for errors</h3>
				1194	<p>Most functions in this API can return errors. All functions that can
				1195	fail have the return type <code class="docutils literal notranslate"><span class="pre">psa_status_t</span></code>. A few functions cannot fail,
				1196	and thus, return <code class="docutils literal notranslate"><span class="pre">void</span></code> or some other type.</p>
				1197	<p>If an error occurs, unless otherwise specified, the content of the
				1198	output parameters is undefined and must not be used.</p>
				1199	<p>Some common causes of errors include:</p>
				1200	<ul class="simple">
				1201	<li>In implementations where the keys are stored and processed in a
				1202	separate environment from the application, all functions that need to
				1203	access the cryptography processing environment may fail due to an
				1204	error in the communication between the two environments.</li>
				1205	<li>If an algorithm is implemented with a hardware accelerator, which is
				1206	logically separate from the application processor, the accelerator
				1207	may fail, even when the application processor keeps running normally.</li>
				1208	<li>All functions may fail due to a lack of resources. However, some
				1209	implementations guarantee that certain functions always have
				1210	sufficient memory.</li>
				1211	<li>All functions that access persistent keys may fail due to a storage
				1212	failure.</li>
				1213	<li>All functions that require randomness may fail due to a lack of
				1214	entropy. Implementations are encouraged to seed the random generator
				1215	with sufficient entropy during the execution of <code class="docutils literal notranslate"><span class="pre">psa_crypto_init</span></code>.
				1216	However, some security standards require periodic reseeding from a
				1217	hardware random generator, which can fail.</li>
				1218	</ul>
				1219	</div>
				1220	<div class="section" id="shared-memory-and-concurrency">
				1221	<h3>Shared memory and concurrency</h3>
				1222	<p>Some environments allow applications to be multithreaded, while others
				1223	do not. In some environments, applications may share memory with a
				1224	different security context. In environments with multithreaded
				1225	applications or shared memory, applications must be written carefully to
				1226	avoid data corruption or leakage. This specification requires the
				1227	application to obey certain constraints.</p>
				1228	<p>In general, this API allows either one writer or any number of
				1229	simultaneous readers, on any given object. In other words, if two or
				1230	more calls access the same object concurrently, then the behavior is
				1231	only well-defined if all the calls are only reading from the object and
				1232	do not modify it. Read accesses include reading memory by input
				1233	parameters and reading keystore content by using a key. For more
				1234	details, refer to the <a class="reference external" href="#concurrent-calls">“Concurrent calls”</a>
				1235	section.</p>
				1236	<p>If an application shares memory with another security context, it may
				1237	pass shared memory blocks as input buffers or output buffers, but not as
				1238	non-buffer parameters. For more details, refer to the <a class="reference external" href="#stability-of-parameters">“Stability of
				1239	parameters”</a> section.</p>
				1240	</div>
				1241	<div class="section" id="cleaning-up-after-use">
				1242	<h3>Cleaning up after use</h3>
				1243	<p>To minimize impact if the system is compromised, applications should
				1244	wipe all sensitive data from memory when it is no longer used. That way,
				1245	only data that is currently in use may be leaked, and past data is not
				1246	compromised.</p>
				1247	<p>Wiping sensitive data includes:</p>
				1248	<ul class="simple">
				1249	<li>Clearing temporary buffers in the stack or on the heap.</li>
				1250	<li>Aborting operations if they will not be finished.</li>
				1251	<li>Destroying keys that are no longer used.</li>
				1252	</ul>
				1253	</div>
				1254	</div>
				1255	</div>
				1256
				1257
				1258	</div>
				1259
				1260	</div>
				1261	</div>
				1262	<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
				1263	<div class="sphinxsidebarwrapper">
				1264	<h1 class="logo"><a href="index.html">psa_crypto_api</a></h1>
				1265
				1266
				1267
				1268
				1269
				1270
				1271
				1272
				1273	<h3>Navigation</h3>
				1274	<ul class="current">
				1275	<li class="toctree-l1 current"><a class="current reference internal" href="#">Introduction</a></li>
				1276	<li class="toctree-l1"><a class="reference internal" href="#design-goals">Design goals</a><ul>
				1277	<li class="toctree-l2"><a class="reference internal" href="#suitable-for-constrained-devices">Suitable for constrained devices</a></li>
				1278	<li class="toctree-l2"><a class="reference internal" href="#a-keystore-interface">A keystore interface</a></li>
				1279	<li class="toctree-l2"><a class="reference internal" href="#optional-isolation">Optional isolation</a></li>
				1280	<li class="toctree-l2"><a class="reference internal" href="#choice-of-algorithms">Choice of algorithms</a></li>
				1281	<li class="toctree-l2"><a class="reference internal" href="#ease-of-use">Ease of use</a></li>
				1282	<li class="toctree-l2"><a class="reference internal" href="#example-use-cases">Example use cases</a><ul>
				1283	<li class="toctree-l3"><a class="reference internal" href="#network-security-tls">Network Security (TLS)</a></li>
				1284	<li class="toctree-l3"><a class="reference internal" href="#secure-storage">Secure Storage</a></li>
				1285	<li class="toctree-l3"><a class="reference internal" href="#network-credentials">Network Credentials</a></li>
				1286	<li class="toctree-l3"><a class="reference internal" href="#device-pairing">Device Pairing</a></li>
				1287	<li class="toctree-l3"><a class="reference internal" href="#secure-boot">Secure Boot</a></li>
				1288	<li class="toctree-l3"><a class="reference internal" href="#attestation">Attestation</a></li>
				1289	<li class="toctree-l3"><a class="reference internal" href="#factory-provisioning">Factory Provisioning</a></li>
				1290	</ul>
				1291	</li>
				1292	</ul>
				1293	</li>
				1294	<li class="toctree-l1"><a class="reference internal" href="#functionality-overview">Functionality overview</a><ul>
				1295	<li class="toctree-l2"><a class="reference internal" href="#library-management">Library management</a></li>
				1296	<li class="toctree-l2"><a class="reference internal" href="#key-management">Key management</a><ul>
				1297	<li class="toctree-l3"><a class="reference internal" href="#volatile-keys">Volatile keys</a></li>
				1298	<li class="toctree-l3"><a class="reference internal" href="#persistent-keys">Persistent keys</a></li>
				1299	<li class="toctree-l3"><a class="reference internal" href="#recommendations-of-minimum-standards-for-key-management">Recommendations of minimum standards for key management</a></li>
				1300	</ul>
				1301	</li>
				1302	<li class="toctree-l2"><a class="reference internal" href="#usage-policies">Usage policies</a></li>
				1303	<li class="toctree-l2"><a class="reference internal" href="#symmetric-cryptography">Symmetric cryptography</a><ul>
				1304	<li class="toctree-l3"><a class="reference internal" href="#multipart-operations">Multipart operations</a></li>
				1305	<li class="toctree-l3"><a class="reference internal" href="#authenticated-encryption">Authenticated encryption</a></li>
				1306	</ul>
				1307	</li>
				1308	<li class="toctree-l2"><a class="reference internal" href="#key-derivation">Key derivation</a><ul>
				1309	<li class="toctree-l3"><a class="reference internal" href="#key-derivation-operations">Key derivation operations</a></li>
				1310	<li class="toctree-l3"><a class="reference internal" href="#key-derivation-function">Key derivation function</a></li>
				1311	</ul>
				1312	</li>
				1313	<li class="toctree-l2"><a class="reference internal" href="#asymmetric-cryptography">Asymmetric cryptography</a><ul>
				1314	<li class="toctree-l3"><a class="reference internal" href="#asymmetric-encryption">Asymmetric encryption</a></li>
				1315	<li class="toctree-l3"><a class="reference internal" href="#hash-and-sign">Hash-and-sign</a></li>
				1316	<li class="toctree-l3"><a class="reference internal" href="#key-agreement">Key agreement</a></li>
				1317	</ul>
				1318	</li>
				1319	<li class="toctree-l2"><a class="reference internal" href="#randomness-and-key-generation">Randomness and key generation</a></li>
				1320	<li class="toctree-l2"><a class="reference internal" href="#future-additions">Future additions</a></li>
				1321	</ul>
				1322	</li>
				1323	<li class="toctree-l1"><a class="reference internal" href="#sample-architectures">Sample architectures</a><ul>
				1324	<li class="toctree-l2"><a class="reference internal" href="#single-partition-architecture">Single-partition architecture</a></li>
				1325	<li class="toctree-l2"><a class="reference internal" href="#cryptographic-token-and-single-application-processor">Cryptographic token and single-application processor</a></li>
				1326	<li class="toctree-l2"><a class="reference internal" href="#cryptoprocessor-with-no-key-storage">Cryptoprocessor with no key storage</a></li>
				1327	<li class="toctree-l2"><a class="reference internal" href="#multi-client-cryptoprocessor">Multi-client cryptoprocessor</a></li>
				1328	<li class="toctree-l2"><a class="reference internal" href="#multi-cryptoprocessor-architecture">Multi-cryptoprocessor architecture</a></li>
				1329	</ul>
				1330	</li>
				1331	<li class="toctree-l1"><a class="reference internal" href="#library-conventions">Library conventions</a><ul>
				1332	<li class="toctree-l2"><a class="reference internal" href="#error-handling">Error handling</a><ul>
				1333	<li class="toctree-l3"><a class="reference internal" href="#return-status">Return status</a></li>
				1334	<li class="toctree-l3"><a class="reference internal" href="#behavior-on-error">Behavior on error</a></li>
				1335	</ul>
				1336	</li>
				1337	<li class="toctree-l2"><a class="reference internal" href="#parameter-conventions">Parameter conventions</a><ul>
				1338	<li class="toctree-l3"><a class="reference internal" href="#pointer-conventions">Pointer conventions</a></li>
				1339	<li class="toctree-l3"><a class="reference internal" href="#input-buffer-sizes">Input buffer sizes</a></li>
				1340	<li class="toctree-l3"><a class="reference internal" href="#output-buffer-sizes">Output buffer sizes</a></li>
				1341	<li class="toctree-l3"><a class="reference internal" href="#overlap-between-parameters">Overlap between parameters</a></li>
				1342	<li class="toctree-l3"><a class="reference internal" href="#stability-of-parameters">Stability of parameters</a></li>
				1343	</ul>
				1344	</li>
				1345	<li class="toctree-l2"><a class="reference internal" href="#key-types-and-algorithms">Key types and algorithms</a><ul>
				1346	<li class="toctree-l3"><a class="reference internal" href="#structure-of-key-and-algorithm-types">Structure of key and algorithm types</a></li>
				1347	</ul>
				1348	</li>
				1349	<li class="toctree-l2"><a class="reference internal" href="#concurrent-calls">Concurrent calls</a></li>
				1350	</ul>
				1351	</li>
				1352	<li class="toctree-l1"><a class="reference internal" href="#implementation-considerations">Implementation considerations</a><ul>
				1353	<li class="toctree-l2"><a class="reference internal" href="#implementation-specific-aspects-of-the-interface">Implementation-specific aspects of the interface</a><ul>
				1354	<li class="toctree-l3"><a class="reference internal" href="#implementation-profile">Implementation profile</a></li>
				1355	<li class="toctree-l3"><a class="reference internal" href="#implementation-specific-types">Implementation-specific types</a></li>
				1356	<li class="toctree-l3"><a class="reference internal" href="#implementation-specific-macros">Implementation-specific macros</a></li>
				1357	</ul>
				1358	</li>
				1359	<li class="toctree-l2"><a class="reference internal" href="#porting-to-a-platform">Porting to a platform</a><ul>
				1360	<li class="toctree-l3"><a class="reference internal" href="#platform-assumptions">Platform assumptions</a></li>
				1361	<li class="toctree-l3"><a class="reference internal" href="#platform-specific-types">Platform-specific types</a></li>
				1362	<li class="toctree-l3"><a class="reference internal" href="#cryptographic-hardware-support">Cryptographic hardware support</a></li>
				1363	</ul>
				1364	</li>
				1365	<li class="toctree-l2"><a class="reference internal" href="#security-requirements-and-recommendations">Security requirements and recommendations</a><ul>
				1366	<li class="toctree-l3"><a class="reference internal" href="#error-detection">Error detection</a></li>
				1367	<li class="toctree-l3"><a class="reference internal" href="#memory-cleanup">Memory cleanup</a></li>
				1368	<li class="toctree-l3"><a class="reference internal" href="#safe-outputs-on-error">Safe outputs on error</a></li>
				1369	<li class="toctree-l3"><a class="reference internal" href="#attack-resistance">Attack resistance</a></li>
				1370	</ul>
				1371	</li>
				1372	<li class="toctree-l2"><a class="reference internal" href="#other-implementation-considerations">Other implementation considerations</a><ul>
				1373	<li class="toctree-l3"><a class="reference internal" href="#philosophy-of-resource-management">Philosophy of resource management</a></li>
				1374	</ul>
				1375	</li>
				1376	</ul>
				1377	</li>
				1378	<li class="toctree-l1"><a class="reference internal" href="#usage-considerations">Usage considerations</a><ul>
				1379	<li class="toctree-l2"><a class="reference internal" href="#security-recommendations">Security recommendations</a><ul>
				1380	<li class="toctree-l3"><a class="reference internal" href="#always-check-for-errors">Always check for errors</a></li>
				1381	<li class="toctree-l3"><a class="reference internal" href="#shared-memory-and-concurrency">Shared memory and concurrency</a></li>
				1382	<li class="toctree-l3"><a class="reference internal" href="#cleaning-up-after-use">Cleaning up after use</a></li>
				1383	</ul>
				1384	</li>
				1385	</ul>
				1386	</li>
				1387	<li class="toctree-l1"><a class="reference internal" href="from_doxygen.html">Implementation-specific definitions</a></li>
				1388	<li class="toctree-l1"><a class="reference internal" href="from_doxygen.html#library-initialization">Library initialization</a></li>
				1389	<li class="toctree-l1"><a class="reference internal" href="from_doxygen.html#key-attributes">Key attributes</a></li>
				1390	<li class="toctree-l1"><a class="reference internal" href="from_doxygen.html#key-management">Key management</a></li>
				1391	<li class="toctree-l1"><a class="reference internal" href="from_doxygen.html#key-import-and-export">Key import and export</a></li>
				1392	<li class="toctree-l1"><a class="reference internal" href="from_doxygen.html#message-digests">Message digests</a></li>
				1393	<li class="toctree-l1"><a class="reference internal" href="from_doxygen.html#message-authentication-codes">Message authentication codes</a></li>
				1394	<li class="toctree-l1"><a class="reference internal" href="from_doxygen.html#symmetric-ciphers">Symmetric ciphers</a></li>
				1395	<li class="toctree-l1"><a class="reference internal" href="from_doxygen.html#authenticated-encryption-with-associated-data-aead">Authenticated encryption with associated data (AEAD)</a></li>
				1396	<li class="toctree-l1"><a class="reference internal" href="from_doxygen.html#asymmetric-cryptography">Asymmetric cryptography</a></li>
				1397	<li class="toctree-l1"><a class="reference internal" href="from_doxygen.html#key-derivation-and-pseudorandom-generation">Key derivation and pseudorandom generation</a></li>
				1398	<li class="toctree-l1"><a class="reference internal" href="from_doxygen.html#random-generation">Random generation</a></li>
				1399	<li class="toctree-l1"><a class="reference internal" href="from_doxygen.html#error-codes">Error codes</a></li>
				1400	<li class="toctree-l1"><a class="reference internal" href="from_doxygen.html#key-and-algorithm-types">Key and algorithm types</a></li>
				1401	<li class="toctree-l1"><a class="reference internal" href="from_doxygen.html#key-lifetimes">Key lifetimes</a></li>
				1402	<li class="toctree-l1"><a class="reference internal" href="from_doxygen.html#key-policies">Key policies</a></li>
				1403	<li class="toctree-l1"><a class="reference internal" href="from_doxygen.html#key-derivation">Key derivation</a></li>
				1404	<li class="toctree-l1"><a class="reference internal" href="from_doxygen.html#other-definitions">Other definitions</a></li>
				1405	</ul>
				1406
				1407	<div class="relations">
				1408	<h3>Related Topics</h3>
				1409	<ul>
				1410	<li><a href="index.html">Documentation overview</a><ul>
				1411	<li>Previous: <a href="index.html" title="previous chapter">PSA Cryptography API Specification</a></li>
				1412	<li>Next: <a href="from_doxygen.html" title="next chapter">Implementation-specific definitions</a></li>
				1413	</ul></li>
				1414	</ul>
				1415	</div>
				1416	<div id="searchbox" style="display: none" role="search">
				1417	<h3>Quick search</h3>
				1418	<div class="searchformwrapper">
				1419	<form class="search" action="search.html" method="get">
				1420	<input type="text" name="q" />
				1421	<input type="submit" value="Go" />
				1422	<input type="hidden" name="check_keywords" value="yes" />
				1423	<input type="hidden" name="area" value="default" />
				1424	</form>
				1425	</div>
				1426	</div>
				1427	<script type="text/javascript">$('#searchbox').show(0);</script>
				1428
				1429
				1430
				1431
				1432
				1433
				1434
				1435
				1436	</div>
				1437	</div>
				1438	<div class="clearer"></div>
				1439	</div>
				1440	<div class="footer">
				1441	©2019, Arm.
				1442
				1443	\|
				1444	Powered by <a href="http://sphinx-doc.org/">Sphinx 1.8.5</a>
				1445	& <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.12</a>
				1446
				1447	\|
				1448	<a href="_sources/general.rst.txt"
				1449	rel="nofollow">Page source</a>
				1450	</div>
				1451
				1452
				1453
				1454
				1455	</body>
				1456	</html>