Signing code provides a method to both verify that your code has not been altered or corrupted as well as authenticating the code is from a known source. In the past is was common to use a CRC or simple checksum, but these methods at most will only check for code corruption.
A cryptographic hash is a mathematical function that takes a file of any size and returns a unique fixed length string, which is commonly referred as the hash value or digest. The hash function replaces the checksum or CRC to verify the code. The 256-bit SHA-2 (Secure Hash Algorithm-2) or SHA-256, is used to generate the digest from the application bundle. The application bundle includes a header, a CM0+ project binary, and optionally a CM4 project binary depending on the application. The digital signature is then added to the end of the application bundle. Modus Toolbox takes care of calculating the digest, creating the digital signature and appending it to the application bundle. It is important to note that only the digest is encrypted not the code binary itself.
The RSA keys used to encrypt the digest is what is known as an asymmetric key. This means that the key has two parts, a public key and a private key. The private key is used to encrypt the digest and should be stored as securely as possible. If anyone were to see the private key, then they could sign code for your product as well and the device would not know the difference.
The other half of the asymmetric key is known as the “Public Key”. This public key can be exposed to the public without harm. The only issue is that the public key must be either authenticated, or ensured that it hasn’t changed. When the PSoC™ 6 was moved to the Secure lifecycle stage, a hash was created that included the OEM public key and placed into immutable eFuse.
When the PSoC™ 6 boots in the Secure lifecycle stage, it calculates the digest of the application bundle, not including the digital signature, just as the build process did using the SHA-256 function. The digital signature is then decrypted using the OEM public key. The calculated digest and decrypted digest are then compared to authenticate the OEM application code. If the digests match, the application code is executed. If the digests don’t match, the PSoC™ 6 enters the Dead protection state. See the diagram below for the code authentication flow.
This flow is only valid for the first OEM code that is executed. In many applications, the first code is a bootloader supplied by the OEM. It is recommended to have this bootloader to authenticated the code it boots with a similar system just discussed. Infineon supplies a common open source bootloader called MCUBoot. It supports code authentication, but uses ECC asymmetric keys to authenticate. This process is almost identical to the way the PSoC™ 6 boot process works. Since the ECC public key is part of the MCUBoot bootloader, the key has already been validated and therefor the chain of trust is complete from the PSoC™ 6 ROM code to the OEM application code.