/***************************************************************************//** * \file cy_crypto.h * \version 2.120 * * \brief * This file provides the public interface for the Crypto driver. * ******************************************************************************** * \copyright * Copyright (c) (2020-2022), Cypress Semiconductor Corporation (an Infineon company) or * an affiliate of Cypress Semiconductor Corporation. * SPDX-License-Identifier: Apache-2.0 * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.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. *******************************************************************************/ /** * \addtogroup group_crypto * \{ * \note IP Supported: CRYPTO * \note Device Categories: CAT1A & CAT1C. Please refer Device Catalog. * * The Crypto driver provides a public API to perform cryptographic and hash * operations, as well as generate both true and pseudo random numbers. * * It uses a hardware IP block to accelerate operations. * * The functions and other declarations used in this driver are in cy_crypto.h, * cy_crypto_core.h, and cy_crypto_server.h. You can also include cy_pdl.h * to get access to all functions and declarations in the PDL. * * The driver implements two usage models: * * \ref group_crypto_cli_srv * * \ref group_crypto_lld_api * * Mixing these usage models will result in undefined behaviour. * * The Crypto driver supports these standards: DES, TDES, AES (128, 192, 256 bits), CMAC-AES, SHA, * HMAC, PRNG, TRNG, CRC, RSA, ECP, and ECDSA. * \note ECP and ECDSA are only implemented for the \ref group_crypto_lld_api model. * * \section group_crypto_configuration_considerations Configuration Considerations * * User can enable/disable cryptographic functionality based on the project * requirements. To do so, create a configuration header file to configure cryptographic * functionalities and define a macro CY_CRYPTO_USER_CONFIG_FILE with configuration * header file name and add to project environment. If CY_CRYPTO_USER_CONFIG_FILE macro * is not defined in project environment, firmware will enable all available * cryptographic functionalities. * * Firmware sets up a cryptographic operation by passing in the required data as * parameters in the function calls. * * All Crypto functions require a context. A context is a data * structure that the driver uses for its operations. Firmware declares a * context (allocates memory) but does not write or read the values in that * context. In effect, the context is a scratch pad you provide to the driver. * The driver uses the context to store and manipulate data during cryptographic * operations. * * Several methods require an additional context unique to the particular * cryptographic technique. * The Crypto driver header files declare all the required structures for both * configuration and context. * * Some encryption techniques require additional initialization specific to the * technique. If there is an Init function, you must call it before using any * other function for that technique, and re-initialize after you use a different * encryption technique. * * For example, use \ref Cy_Crypto_Aes_Init to configure an AES encryption * operation with the encryption key, and key length. * Provide pointers to two context structures. You can then call the AES Run functions. * If you use DES after that, you must re-initialize the AES encryption before using * it again. * * \section group_crypto_definitions Definitions * *
| Term | *Definition | *
|---|---|
| Plaintext | *An unencrypted message | *
| Ciphertext | *An encrypted message | *
| Block Cipher | *An encryption function for fixed-size blocks of data. * This function takes a fixed-size key and a block of plaintext data from * the message and encrypts it to generate ciphertext. Block ciphers are * reversible. The function performed on a block of encrypted data will * decrypt that data. | *
| Block Cipher Mode | *A mode of encrypting a message using block ciphers for messages of an * arbitrary length. The message is padded so that its length is an integer * multiple of the block size. ECB (Electronic Code Book), CBC (Cipher Block * Chaining), and CFB (Cipher Feedback) are all modes of using block ciphers * to create an encrypted message of an arbitrary length. * | *
| Data Encryption Standard (DES) | *The [DES standard] * (https://csrc.nist.gov/csrc/media/publications/fips/46/3/archive/1999-10-25/documents/fips46-3.pdf) * specifies a symmetric-key algorithm for encryption of electronic data. * It uses a 56-bit key. The block size is 64-bits. * | *
| Triple DES (3DES or TDES) | *The [TDES standard] * (https://csrc.nist.gov/csrc/media/publications/fips/46/3/archive/1999-10-25/documents/fips46-3.pdf) * specifies a symmetric-key block cipher that applies the Data Encryption * Standard (DES) cipher algorithm three times to each data block. * It uses three 56-bit keys. The block size is 64-bits. * | *
| Advanced Encryption Standard (AES) | *The [AES standard] (https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.197.pdf) * specifies the Rijndael algorithm, a symmetric block * cipher that can process 128-bit data blocks, using cipher keys with * 128-, 192-, and 256-bit lengths. Rijndael was designed to handle * additional block sizes and key lengths. However, they are not adopted in * this standard. AES is also used for message authentication. * | *
| Secure Hash Algorithm (SHA) | *A cryptographic hash function. * This function takes a message of an arbitrary length and reduces it to a * fixed-length residue or message digest after performing a series of * mathematically defined operations that practically guarantee that any * change in the message will change the hash value. It is used for message * authentication by transmitting a message with a hash value appended to it * and recalculating the message hash value using the same algorithm at the * recipient's end. If the hashes differ, then the message is corrupted. * For more information see [Secure Hash standard description] * (https://csrc.nist.gov/csrc/media/publications/fips/180/2/archive/2002-08-01/documents/fips180-2.pdf). * | *
| Message Authentication Code (MAC) | *MACs are used to verify that a received message has not been altered. * This is done by first computing a MAC value at the sender's end and * appending it to the transmitted message. When the message is received, * the MAC is computed again and checked against the MAC value transmitted * with the message. If they do not match, the message has been altered. * Either a Hash algorithm (such as SHA) or a block cipher (such as AES) can * be used to produce the MAC value. Keyed MAC schemes use a Secret Key * along with the message, thus the Key value must be known to be able to * compute the MAC value. | *
| Cipher-based Message Authentication Code (CMAC) | *A block cipher-based message authentication code algorithm. * It computes the MAC value using the AES block cipher algorithm. | * For more information see [Recommendation for Block Cipher Modes of Operation] * (https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-38b.pdf). *
| Hash Message Authentication Code (HMAC) | *A specific type of message authentication code (MAC) that involves a * cryptographic hash function and a secret cryptographic key. * It computes the MAC value using a Hash algorithm. * For more information see [The Keyed-Hash Message Authentication Code standard] * (https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.198-1.pdf) * | *
| Pseudo Random Number Generator (PRNG) | *A Linear Feedback Shift Registers-based algorithm for generating a * sequence of numbers starting from a non-zero seed. | *
| True Random Number Generator (TRNG) | *A block that generates a number that is statistically random and based * on some physical random variation. The number cannot be duplicated by * running the process again. | *
| Symmetric Key Cryptography | *Uses a common, known key to encrypt and decrypt messages (a shared * secret between sender and receiver). An efficient method used for * encrypting and decrypting messages after the authenticity of the other * party has been established. DES (now obsolete), 3DES, and AES (currently * used) are well-known symmetric cryptography methods. | *
| Asymmetric Key Cryptography | *Also referred to as Public Key encryption. To receive a message, * you publish a very large public key (up to 4096 bits currently). The * public key is described by the pair (n, e) where n is a product of * two randomly chosen primes p and q. The exponent e is a random integer * 1 < e < Q where Q = (p-1) (q-1). The private key d is uniquely defined * by the integer 1 < d < Q so that ed congruent with 1 (mod Q ). To send * a message to the publisher of the public key, you encrypt the message * with the public key. This message can now be decrypted only with the * private key. The message is now sent over any channel to the recipient * who can decrypt it with the private (secret) key. The same process is * used to send messages to the sender of the original message. The * asymmetric cryptography relies on the mathematical impracticality * (usually related to the processing power available at any given time) * of factoring the keys. * | *
| Version | Changes | Reason for Change |
|---|---|---|
| 2.120 | *
*
|
*
* Added EDDSA Hardware acceleration for CAT1A and CAT1C MCUs. | *
| Updated structures \ref cy_stc_crypto_aes_buffers_t, \ref cy_stc_crypto_aes_state_t, \ref cy_stc_crypto_aes_ccm_buffers_t * \ref cy_stc_crypto_aes_gcm_buffers_t, \ref cy_stc_crypto_aes_gcm_state_t, \ref cy_stc_crypto_sha_state_t. | *Fixed AES CCM, GCM and SHA algorithm issues with DCache enablement on CAT1C device. | *|
| 2.110 | *Fixed data synchronization barrier issue in AES | ** |
| 2.100 | *Added SHA3, HKDF, AES multistage support for modes ECB, CBC, CFB CTR added | ** |
| 2.90 | *Updated internal APIs and bug fixes. | *Fixed GCM initialization and coverity bugs. | *
| 2.80 | *Added AES GCM support. | *Driver enhancement. | *
| 2.70 | *Added TRNG enhancements to support health monitor check. | *Driver enhancement and new feature addition. | *
| 2.60 | *
*
|
*
* Driver enhancement and new feature addition. | *
| 2.50 | *Fixed the Cy_Crypto_Core_ECC_VerifyHash() and an internal function behaviour * to support 0 hash message. Resolved MISRA 2012 standard defects. | *Defect fixing and MISRA 2012 compliance. | *
| 2.40 | ** Resolve MISRA 2012 standard defects. * | ** MISRA 2012 compliance. * | *
| 2.30.4 | ** Updated code snippets for client-server usage model. * | ** Documentation enhancement. * | *
| 2.30.3 | ** Minor documentation updates. * | ** Documentation enhancement. * | *
| 2.30.2 | ** Code formatting cleanup, updated copyright date. * | ** PDL project update. * | *
| 2.30.1 | ** Added a C++ namespace guards. * | ** Make a driver code to be compatible with C++. * | *
| 2.30 | *
*
|
* Integration with mbedOS/mbedTLS, restructured the implementation of * AES and SHA for the Crypto ALT interface. * | *
| 2.20 | *
*
|
* ECC support added. * Integration with mbedOS/mbedTLS, restructured the implementation of * SHA and CRC for the Crypto ALT interface. * |
*
| 2.11b | *The same as production 2.10; only the newly-added Elliptic Curve point * multiplication functionality (NIST P256) is pre-production. * Open source under Apache version 2.0 license. | ** |
| 2.11 | *Based on pre-production 2.10, except the newly-added Elliptic Curve point * multiplication functionality (NIST P256). * Does not incorporate the production level documentation. * Open source under Apache version 2.0 license. | *ECC support. | *
| 2.10b | *The same as production 2.10. Open source under Apache version 2.0 license. | ** |
| 2.10 | *Flattened the organization of the driver source code into the single * source directory and the single include directory. * | *Driver library directory-structure simplification. | *
| Removed files with the default driver configuration. \n * Added API functions to start different server functionality: * - Cy_Crypto_Server_Start_Base * - Cy_Crypto_Server_Start_Extra * - Cy_Crypto_Server_Start_Full * | ** | |
| Added the register access layer. Use register access macros instead * of direct register access using dereferenced pointers. | *Makes register access device-independent, so that the PDL does * not need to be recompiled for each supported part number. | *|
| Added precompiled libraries for the IAR toolchain. | *IAR toolchain support in ModusToolbox. | *|
| 2.0b | *The same as production 2.0. Open source under Apache version 2.0 license. | ** |
| 2.0 | *Clarified what parameters must be 4-byte aligned for the functions: * \ref Cy_Crypto_Aes_Cmac_Run, \ref Cy_Crypto_Sha_Run, * \ref Cy_Crypto_Hmac_Run, \ref Cy_Crypto_Str_MemCmp, * \ref Cy_Crypto_Trng_Generate, \ref Cy_Crypto_Des_Run, * \ref Cy_Crypto_Tdes_Run, \ref Cy_Crypto_Rsa_Proc * | *Documentation update and clarification. | *
|
* Changed crypto IP power control. * Enhanced Vector Unit functionality for RSA crypto algorithm. * Added support of the single-core devices. * |
* New device support. | *|
| 1.0 | *Initial version | ** |
| Field | Which | Description | Notes |
|---|---|---|---|
| \link cy_stc_crypto_config_t::ipcChannel ipcChannel\endlink | *Server and Client | *IPC channel for communication between client and server | *IPC Channel, same for both | *
| \link cy_stc_crypto_config_t::acquireNotifierChannel acquireNotifierChannel\endlink | *Server and Client | *IPC interrupt structure used for the new request notifications | *Notify interrupt number, for Server side only | *
| \link cy_stc_crypto_config_t::releaseNotifierChannel releaseNotifierChannel\endlink | *Server and Client | *IPC interrupt structure used for data ready notifications. Used to call * userCompleteCallback handler function. | *Release interrupt number, for Client side only | *
| \link cy_stc_crypto_config_t::userCompleteCallback userCompleteCallback\endlink | *Client | *User-defined callback for the Release interrupt handler; can be NULL | *See Implementing Crypto Interrupts | *
| \link cy_stc_crypto_config_t::releaseNotifierConfig releaseNotifierConfig \endlink | *Client | *IRQ handler settings for data ready notifications. This interrupt occurs * when server completely processed all input data and released an IPC * communication channel. | *configuration for the interrupt | *
| \link cy_stc_crypto_config_t::userGetDataHandler userGetDataHandler\endlink | *Server | *User-defined function to override default interrupt handler; NULL = use default | *ISR for the Notify interrupt | *
| \link cy_stc_crypto_config_t::acquireNotifierConfig acquireNotifierConfig\endlink | *Server | *IRQ handler settings for new request notifications. This interrupt occurs * when client sent a new request for processing. | *configuration for the interrupt | *
| \link cy_stc_crypto_config_t::userErrorHandler userErrorHandler\endlink | *Server | *User-defined function to override default interrupt handler; NULL = use default | *ISR for a server error | *
| \link cy_stc_crypto_config_t::cryptoErrorIntrConfig cryptoErrorIntrConfig\endlink | *Server | *IRQ handler settings for hardware error events | *configuration for the interrupt | *