About this document¶
Release information¶
The change history table lists the changes that have been made to this document.
Date |
Version |
Confidentiality |
Change |
|---|---|---|---|
January 2019 |
1.0 Beta 1 |
Non-confidential |
First public beta release. |
February 2019 |
1.0 Beta 2 |
Non-confidential |
Update for release with other PSA Certified API specifications. |
May 2019 |
1.0 Beta 3 |
Non-confidential |
Update for release with other PSA Certified API specifications. |
February 2020 |
1.0 Final |
Non-confidential |
1.0 API finalized. |
August 2020 |
1.0.1 Final |
Non-confidential |
Update to fix errors and provide clarifications. |
February 2022 |
1.1.0 Final |
Non-confidential |
New API for EdDSA, password hashing and key stretching. Many significant clarifications and improvements across the documentation. |
October 2022 |
1.1.1 Final |
Non-confidential |
Relicensed as open source under CC BY-SA 4.0. Improve support for TLS. |
March 2023 |
1.1.2 Final |
Non-confidential |
Clarifications and fixes |
The detailed changes in each release are described in Document change history.
PSA Certified Crypto API
Copyright © 2018-2023 Arm Limited and/or its affiliates. The copyright statement reflects the fact that some draft issues of this document have been released, to a limited circulation.
License¶
Text and illustrations
Text and illustrations in this work are licensed under Attribution-ShareAlike 4.0 International (CC BY-SA 4.0). To view a copy of the license, visit creativecommons.org/licenses/by-sa/4.0.
Grant of patent license. Subject to the terms and conditions of this license (both the CC BY-SA 4.0 Public License and this Patent License), each Licensor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Licensed Material, where such license applies only to those patent claims licensable by such Licensor that are necessarily infringed by their contribution(s) alone or by combination of their contribution(s) with the Licensed Material to which such contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Licensed Material or a contribution incorporated within the Licensed Material constitutes direct or contributory patent infringement, then any licenses granted to You under this license for that Licensed Material shall terminate as of the date such litigation is filed.
The Arm trademarks featured here are registered trademarks or trademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere. All rights reserved. Please visit arm.com/company/policies/trademarks for more information about Arm’s trademarks.
About the license
The language in the additional patent license is largely identical to that in section 3 of the Apache License, Version 2.0 (Apache 2.0), with two exceptions:
Changes are made related to the defined terms, to align those defined terms with the terminology in CC BY-SA 4.0 rather than Apache 2.0 (for example, changing “Work” to “Licensed Material”).
The scope of the defensive termination clause is changed from “any patent licenses granted to You” to “any licenses granted to You”. This change is intended to help maintain a healthy ecosystem by providing additional protection to the community against patent litigation claims.
To view the full text of the Apache 2.0 license, visit apache.org/licenses/LICENSE-2.0.
Source code
Source code samples in this work are licensed under the Apache License, Version 2.0 (the “License”); you may not use such samples except in compliance with the License. You may obtain a copy of the License at apache.org/licenses/LICENSE-2.0.
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and limitations under the License.
References¶
This document refers to the following documents.
Ref |
Document Number |
Title |
|---|---|---|
[PSA-PAKE] |
ARM AES 0058 |
PSA Certified Crypto API 1.1 PAKE Extension. arm-software.github.io/psa-api/crypto |
[PSM] |
ARM DEN 0128 |
Platform Security Model. developer.arm.com/documentation/den0128 |
[PSA-FFM] |
ARM DEN 0063 |
Arm® Platform Security Architecture Firmware Framework. pages.arm.com/psa-apis |
[PSA-STAT] |
ARM IHI 0097 |
PSA Certified Status code API. arm-software.github.io/psa-api/status-code |
Ref |
Title |
|---|---|
[C99] |
ISO/IEC, ISO/IEC 9899:1999 — Programming Languages — C, December 1999. www.iso.org/standard/29237.html |
[CHACHA20] |
Bernstein, D., ChaCha, a variant of Salsa20, January 2008. http://cr.yp.to/chacha/chacha-20080128.pdf |
[CLULOW] |
Clulow, Jolyon, On the Security of PKCS #11, 2003. link.springer.com/chapter/10.1007/978-3-540-45238-6_32 |
[CSTC0002] |
Cryptography Standardization Technical Committee, GM/T 0002-2012: SM4 block cipher algorithm, March 2012. |
[CSTC0004] |
Cryptography Standardization Technical Committee, GM/T 0004-2012: SM3 cryptographic hash algorithm, March 2012. |
[Curve25519] |
Bernstein et al., Curve25519: new Diffie-Hellman speed records, LNCS 3958, 2006. www.iacr.org/archive/pkc2006/39580209/39580209.pdf |
[Curve448] |
Hamburg, Ed448-Goldilocks, a new elliptic curve, NIST ECC Workshop, 2015. eprint.iacr.org/2015/625.pdf |
[Ed25519] |
Bernstein et al., Twisted Edwards curves, Africacrypt, 2008. eprint.iacr.org/2008/013.pdf |
[Ed448] |
Hamburg, Ed448-Goldilocks, a new elliptic curve, NIST ECC Workshop, 2015. eprint.iacr.org/2015/625.pdf |
[FIPS180-4] |
NIST, FIPS Publication 180-4: Secure Hash Standard (SHS), August 2015. doi.org/10.6028/NIST.FIPS.180-4 |
[FIPS186-4] |
NIST, FIPS Publication 186-4: Digital Signature Standard (DSS), July 2013. doi.org/10.6028/NIST.FIPS.186-4 |
[FIPS197] |
NIST, FIPS Publication 197: Advanced Encryption Standard (AES), November 2001. doi.org/10.6028/NIST.FIPS.197 |
[FIPS202] |
NIST, FIPS Publication 202: SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, August 2015. doi.org/10.6028/NIST.FIPS.202 |
[FRP] |
Agence nationale de la sécurité des systèmes d’information, Publication d’un paramétrage de courbe elliptique visant des applications de passeport électronique et de l’administration électronique française, 21 November 2011. www.ssi.gouv.fr/agence/rayonnement-scientifique/publications-scientifiques/articles-ouvrages-actes |
[IEEE-XTS] |
IEEE, 1619-2018 — IEEE Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices, January 2019. ieeexplore.ieee.org/servlet/opac?punumber=8637986 |
[ISO10118] |
ISO/IEC, ISO/IEC 10118-3:2018 IT Security techniques — Hash-functions — Part 3: Dedicated hash-functions, October 2018. www.iso.org/standard/67116.html |
[ISO9797] |
ISO/IEC, ISO/IEC 9797-1:2011 Information technology — Security techniques — Message Authentication Codes (MACs) — Part 1: Mechanisms using a block cipher, March 2011. www.iso.org/standard/50375.html |
[NTT-CAM] |
NTT Corporation and Mitsubishi Electric Corporation, Specification of Camellia — a 128-bit Block Cipher, September 2001. info.isl.ntt.co.jp/crypt/eng/camellia/specifications |
[RFC1319] |
IETF, The MD2 Message-Digest Algorithm, April 1992. tools.ietf.org/html/rfc1319.html |
[RFC1320] |
IETF, The MD4 Message-Digest Algorithm, April 1992. tools.ietf.org/html/rfc1320.html |
[RFC1321] |
IETF, The MD5 Message-Digest Algorithm, April 1992. tools.ietf.org/html/rfc1321.html |
[RFC2104] |
IETF, HMAC: Keyed-Hashing for Message Authentication, February 1997. tools.ietf.org/html/rfc2104.html |
[RFC2315] |
IETF, PKCS #7: Cryptographic Message Syntax Version 1.5, March 1998. tools.ietf.org/html/rfc2315.html |
[RFC3279] |
IETF, Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002. tools.ietf.org/html/rfc3279.html |
[RFC3610] |
IETF, Counter with CBC-MAC (CCM), September 2003. tools.ietf.org/html/rfc3610 |
[RFC3713] |
IETF, A Description of the Camellia Encryption Algorithm, April 2004. tools.ietf.org/html/rfc3713 |
[RFC4279] |
IETF, Pre-Shared Key Ciphersuites for Transport Layer Security (TLS), December 2005. tools.ietf.org/html/rfc4279.html |
[RFC4615] |
IETF, The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE), August 2006. tools.ietf.org/html/rfc4615.html |
[RFC5116] |
IETF, An Interface and Algorithms for Authenticated Encryption, January 2008. tools.ietf.org/html/rfc5116.html |
[RFC5246] |
IETF, The Transport Layer Security (TLS) Protocol Version 1.2, August 2008. tools.ietf.org/html/rfc5246.html |
[RFC5489] |
IETF, ECDHE_PSK Cipher Suites for Transport Layer Security (TLS), March 2009. tools.ietf.org/html/rfc5489.html |
[RFC5639] |
IETF, Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation, March 2010. tools.ietf.org/html/rfc5639.html |
[RFC5794] |
IETF, A Description of the ARIA Encryption Algorithm, March 2010. datatracker.ietf.org/doc/html/rfc5794 |
[RFC5869] |
IETF, HMAC-based Extract-and-Expand Key Derivation Function (HKDF), May 2010. tools.ietf.org/html/rfc5869.html |
[RFC5915] |
IETF, Elliptic Curve Private Key Structure, June 2010. tools.ietf.org/html/rfc5915.html |
[RFC6979] |
IETF, Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA), August 2013. tools.ietf.org/html/rfc6979.html |
[RFC7539] |
IETF, ChaCha20 and Poly1305 for IETF Protocols, May 2015. tools.ietf.org/html/rfc7539.html |
[RFC7748] |
IETF, Elliptic Curves for Security, January 2016. tools.ietf.org/html/rfc7748.html |
[RFC7919] |
IETF, Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS), August 2016. tools.ietf.org/html/rfc7919.html |
[RFC8017] |
IETF, PKCS #1: RSA Cryptography Specifications Version 2.2, November 2016. tools.ietf.org/html/rfc8017.html |
[RFC8018] |
IETF, PKCS #5: Password-Based Cryptography Specification Version 2.1, January 2017. tools.ietf.org/html/rfc8018.html |
[RFC8032] |
IRTF, Edwards-Curve Digital Signature Algorithm (EdDSA), January 2017. tools.ietf.org/html/rfc8032.html |
[RIPEMD] |
Dobbertin, Bosselaers and Preneel, RIPEMD-160: A Strengthened Version of RIPEMD, April 1996. homes.esat.kuleuven.be/~bosselae/ripemd160.html |
[SEC1] |
Standards for Efficient Cryptography, SEC 1: Elliptic Curve Cryptography, May 2009. www.secg.org/sec1-v2.pdf |
[SEC2] |
Standards for Efficient Cryptography, SEC 2: Recommended Elliptic Curve Domain Parameters, January 2010. www.secg.org/sec2-v2.pdf |
[SEC2v1] |
Standards for Efficient Cryptography, SEC 2: Recommended Elliptic Curve Domain Parameters, Version 1.0, September 2000. www.secg.org/SEC2-Ver-1.0.pdf |
[SP800-30] |
NIST, NIST Special Publication 800-30 Revision 1: Guide for Conducting Risk Assessments, September 2012. doi.org/10.6028/NIST.SP.800-30r1 |
[SP800-38A] |
NIST, NIST Special Publication 800-38A: Recommendation for Block Cipher Modes of Operation: Methods and Techniques, December 2001. doi.org/10.6028/NIST.SP.800-38A |
[SP800-38B] |
NIST, NIST Special Publication 800-38B: Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication, May 2005. doi.org/10.6028/NIST.SP.800-38B |
[SP800-38D] |
NIST, NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, November 2007. doi.org/10.6028/NIST.SP.800-38D |
[SP800-56A] |
NIST, NIST Special Publication 800-56A: Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography, April 2018. doi.org/10.6028/NIST.SP.800-56Ar3 |
[SP800-67] |
NIST, NIST Special Publication 800-67: Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, November 2017. doi.org/10.6028/NIST.SP.800-67r2 |
[X9-62] |
ANSI, Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA). standards.globalspec.com/std/1955141/ANSI%20X9.62 |
Terms and abbreviations¶
This document uses the following terms and abbreviations.
Term |
Meaning |
|---|---|
| AEAD | See Authenticated Encryption with Associated Data. |
| Algorithm | A finite sequence of steps to perform a particular operation. In this specification, an algorithm is a cipher or a related function. Other texts call this a cryptographic mechanism. |
| API | Application Programming Interface. |
| Asymmetric | |
| Authenticated Encryption with Associated Data (AEAD) | A type of encryption that provides confidentiality and authenticity of data using symmetric keys. |
| Byte | In this specification, a unit of storage comprising eight bits, also called an octet. |
| Caller isolation | Property of an implementation in which there are multiple application instances, with a security boundary between the application instances, as well as between the cryptoprocessor and the application instances. See Optional isolation. |
| Cipher | An algorithm used for encryption or decryption with a symmetric key. |
| Cryptoprocessor | The component that performs cryptographic operations. A cryptoprocessor might contain a keystore and countermeasures against a range of physical and timing attacks. |
| Cryptoprocessor isolation | Property of an implementation in which there is a security boundary between the application and the cryptoprocessor, but the cryptoprocessor does not communicate with other applications. See Optional isolation. |
| Hash | A cryptographic hash function, or the value returned by such a function. |
| HMAC | A type of MAC that uses a cryptographic key with a hash function. |
| Implementation defined | Behavior that is not defined by the architecture, but is defined and documented by individual implementations. |
| Initialization vector (IV) | An additional input that is not part of the message. It is used to prevent an attacker from making any correlation between cipher text and plain text. This specification uses the term for such initial inputs in all contexts. For example, the initial counter in CTR mode is called the IV. |
| Isolation | Property of an implementation in which there is a security boundary between the application and the cryptoprocessor. See Optional isolation. |
| IV | See Initialization vector. |
| KDF | See Key Derivation Function. |
| Key agreement | An algorithm for two or more parties to establish a common secret key. |
| Key Derivation Function (KDF) | Key Derivation Function. An algorithm for deriving keys from secret material. |
| Key identifier | A reference to a cryptographic key. Key identifiers in the Crypto API are 32-bit integers. |
| Key policy | Key metadata that describes and restricts what a key can be used for. |
| Key size | The size of a key as defined by common conventions for each key type. For keys that are built from several numbers of strings, this is the size of a particular one of these numbers or strings. This specification expresses key sizes in bits. |
| Key type | Key metadata that describes the structure and content of a key. |
| Keystore | A hardware or software component that protects, stores, and manages cryptographic keys. |
| Lifetime | Key metadata that describes when a key is destroyed. |
| MAC | See Message Authentication Code. |
| Message Authentication Code (MAC) | A short piece of information used to authenticate a message. It is created and verified using a symmetric key. |
| Message digest | A hash of a message. Used to determine if a message has been tampered. |
| Multi-part operation | An API which splits a single cryptographic operation into a sequence of separate steps. |
| No isolation | Property of an implementation in which there is no security boundary between the application and the cryptoprocessor. See Optional isolation. |
| Non-extractable key | A key with a key policy that prevents it from being read by ordinary means. |
| Nonce | Used as an input for certain AEAD algorithms. Nonces must not be reused with the same key because this can break a cryptographic protocol. |
| Persistent key | A key that is stored in protected non-volatile memory. See Key lifetimes. |
| PSA | Platform Security Architecture |
| Public-key cryptography | A type of cryptographic system that uses key pairs. A keypair consists of a (secret) private key and a public key (not secret). A public key cryptographic algorithm can be used for key distribution and for digital signatures. |
| Salt | Used as an input for certain algorithms, such as key derivations. |
| Signature | The output of a digital signature scheme that uses an asymmetric keypair. Used to establish who produced a message. |
| Single-part function | An API that implements the cryptographic operation in a single function call. |
| Specification defined | Behavior that is defined by this specification. |
| Symmetric | A type of cryptographic algorithm that uses a single key. A symmetric key can be used with a block cipher or a stream cipher. |
| Volatile key | A key that has a short lifespan and is guaranteed not to exist after a restart of an application instance. See Key lifetimes. |
Potential for change¶
The contents of this specification are stable for version 1.1.
The following may change in updates to the version 1.1 specification:
Small optional feature additions.
Clarifications.
Significant additions, or any changes that affect the compatibility of the interfaces defined in this specification will only be included in a new major or minor version of the specification.
Conventions¶
Typographical conventions¶
The typographical conventions are:
- italic
Introduces special terminology, and denotes citations.
monospaceUsed for assembler syntax descriptions, pseudocode, and source code examples.
Also used in the main text for instruction mnemonics and for references to other items appearing in assembler syntax descriptions, pseudocode, and source code examples.
- small capitals
Used for some common terms such as implementation defined.
Used for a few terms that have specific technical meanings, and are included in the Terms and abbreviations.
- Red text
Indicates an open issue.
- Blue text
Indicates a link. This can be
A cross-reference to another location within the document
A URL, for example example.com
Numbers¶
Numbers are normally written in decimal. Binary numbers are preceded by 0b, and
hexadecimal numbers by 0x.
In both cases, the prefix and the associated value are written in a monospace
font, for example 0xFFFF0000. To improve readability, long numbers can be
written with an underscore separator between every four characters, for example
0xFFFF_0000_0000_0000. Ignore any underscores when interpreting the value of
a number.
Feedback¶
We welcome feedback on the PSA Certified API documentation.
If you have comments on the content of this book, visit github.com/arm-software/psa-api/issues to create a new issue at the PSA Certified API GitHub project. Give:
The title (Crypto API).
The number and issue (IHI 0086 1.1.2).
The location in the document to which your comments apply.
A concise explanation of your comments.
We also welcome general suggestions for additions and improvements.
