没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
1 Introduction
Public Key Cryptography is a solid tool which ensures the transfer of
confidential data upon insecure channels. Digital signature as one of the
applications of public key cryptography ensures the identity of the signer and
integrity of the signed data, hence the security of the private key is crucial.
In this work, we consider a scenario in which the software environment gets
compromised due to attacks leading to the possibility of leaking the private key.
We consider also the situation where the user does not simply want to make
the key visible to software but rather keep it only known to hardware. The
scheme we propose is based on a feature provided by the i.MX application
processors called Black Key.
2 References
• i.MX Security Reference Manual, downloadable from nxp.com portal
•
i.MX Yocto Project User's Guide
(document IMXLXYOCTOUG)
• Linux mainline kernel archive, 2018 https://kernel.org
3 Overview
Cryptographic Accelerator and Assurance Module (CAAM) is a hardware module built-in i.MX SoCs which implements secure
RAM and a dedicated public-key hardware accelerator (PKHA). It supports ECDSA signature generation and verification
operations and elliptic curve key-pair generation. It also supports RSA encryption and decryption operations and key-pair
generation.
A device specific random 256-bit One Time Programmable Master Key (OTPMK) key is fused in each i.MX processor at
manufacturing time, this key is unreadable and can only be used by the CAAM for AES encryption/decryption of user data, through
the Secure Non-Volatile Storage (SNVS) companion block. This mechanism can be used to encrypt the ECC and RSA private
keys and turn them into a data structure called a Black Key.
As defined in the SRM, the black key scheme is intended for protection of user keys against bus snooping while the keys are
being written to or read from memory external to the SoC. The keys are automatically encapsulated and decapsulated on-the-
fly. The scheme also prevents key cloning, a black key generated on a specific device can only be used in the device where the
key has been generated.
CAAM supports two different black key encapsulation schemes which are AES-ECB and AES-CCM. While AES-ECB encryption
is intended for quick decryption, AES-CCM encryption is intended for high assurance. Regarding AES-ECB encryption, data is
a multiple of 16 bytes long. If the private key is a multiple of 128-bit, as it will be if we use P-256 or P-384 curve for ECC, or 2048-
bit RSA private key, then the AES-ECB encrypted private key would fit in the same buffer as the original unencrypted private key.
If the private key is not a multiple of 16 bytes long, as it will be if we use P-521 for ECC, then it is padded before being encrypted.
A CCM-encrypted black key is always at least 12 bytes longer than the encapsulated private key (the 12 bytes are for the storage
of the nonce and of the IV and in addition as the CCM mode is an authenticated encryption mode, additional bytes are to be
foreseen to store the authentication tag for the verification of the integrity and the authenticity of the encrypted data). CCM-
Contents
1 Introduction............................................ 1
2 References............................................ 1
3 Overview................................................1
4 Implementation...................................... 3
4.1 RSA.............................. 3
4.2 ECDSA......................... 5
5 Hands-on............................................... 7
5.1 Build..............................7
5.2 Usage........................... 8
6 Conclusion........................................... 10
AN12838
Strengthening Public Key Cryptography using CAAM Secure Key
Rev. 0 — June 2020
Application Note
encrypted keys are preferred, unless we need the encrypted key to fit in the same space as the unencrypted key. Figure 1
illustrates the black key encapsulation and decapsulation mechanisms.
Figure 1. Encapsulating and decapsulating CAAM black keys
Black keys are loaded using CAAM’s KEY command with ENC flag set.
The EKT bit defines the black key encapsulation scheme. If it is set, then AES-CCM is used to decrypt the black key otherwise
AES-ECB is used.
A plaintext key can be converted to a black key, assume that we generated an RSA key and we want to turn the private key in
the format (n, d) to a black key. Then, the private exponent d is loaded to CAAM PKHA E register, writing it back to memory will
be in an encrypted form.
Black keys are session keys thus, are not power-cycles safe. CAAM's blob mechanism provides a method for protecting user-
defined data across system power cycles. The black private key to be protected, is re-encrypted so that it can be safely placed
into non-volatile storage before the SoC is powered down. The mechanism provides both confidentiality and integrity protection.
Figure 2 illustrates the CAAM blob mechanism.
NXP Semiconductors
Overview
Strengthening Public Key Cryptography using CAAM Secure Key, Rev. 0, June 2020
Application Note 2 / 11
Figure 2. CAAM blob mechanism
CAAM implements operations that converts between blob encapsulation and black-key encapsulation without exposing the key
in plaintext.
Finally, the CAAM Secure Memory can be used as confidentiality-preserving memory that protects the private key. We could
imagine a scenario in which, a user wants to generate a black RSA key. First, two primes should be generating then the CAAM
RSA finalize key generation function is called to perform primality checks and compute the private exponent, modulus and
remaining CRT values. This flow involves having the primes visible even for a short time for the software. To protect any
intermediate value against malicious software, secure memory can be used to store these values until the final black key is
generated.
4 Implementation
The software presented in this work, utilizes all CAAM features described in the previous section by building a descriptor and
then adding this descriptor to a Job Ring. The following sections illustrates the job descriptors used for various operation such
as private decryption using black key (RSA signing), ECDSA signing using black key, ECC key-pair generation with blackened
private key and converting a plain RSA key to a black key.
4.1 RSA
For RSA we provide job descriptors to perform decryption using private key which could be used also for signing data, exporting
a black key into a blob and import a blob into a black key.
Regarding RSA key generation, a job descriptor which converts a plain key to a black key is illustrated.
In ECC a black key is generated directly on hardware. The same of RSA could be achieved by replacing the RSA Finalize Key
Generation (RFKG) but it is no implemented in this work.
NXP Semiconductors
Implementation
Strengthening Public Key Cryptography using CAAM Secure Key, Rev. 0, June 2020
Application Note 3 / 11
剩余10页未读,继续阅读
资源评论
embeddedman
- 粉丝: 17
- 资源: 109
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功