As edge-based solutions are typically deployed remotely in applications where security is paramount, e.g. autonomous drones, vision guided robots, and remote IIoT sensors, a comprehensive security solution will be required to defeat external threats to the system and attackers. At a high level, these threats can be categorized in to one of three groups:
- Prevent unauthorized modification — anti-tamper / physical security
2. Protection of stored information — data security
3. Protection of transmissions to/from the unit — communication security
Across all three categories, cryptographic techniques in the form of encryption, hashes, and signatures play a significant role in the security solution.
These cryptographic techniques when combined with other techniques, e.g. monitoring the environment and protecting JTAG ports, prevent unauthorized parties from modifying, accessing stored information, or eaves dropping on the communications.
Of course, a fully secure system requires a threat analysis to be carried out to ensure each potential threat vector is mitigated, e.g. replay attacks.
When it comes to implementing secure solutions, the Zynq MPSoC offers several capabilities intended to help us secure our system, including secure boot, key management, and different power analysis side channel protection.
For the MPSoC, many of the security features fall within the remit of the Configuration Security Unit (CSU) for implementation.
The CSU like the Platform Management Unit (PMU) is also implemented using triplicated MicroBlaze processors.
Unlike the PMU, the CSU processor within the Security Processor Block is not accessible by the user. However, several acceleration functions within the Crypto Interface Block are accessible to the user.
The Crypto Interface Block provides user applications the ability to use the AES 256- GCM, 4096 RSA Multiplier, and SHA-384 engines within the CSU.
Many applications using these engines and associated DMAs present a better, more efficient solution than using a software library or creating our own accelerator within the PL.
We can access these acceleration functions from the APU or RPU in our SW application.
If we are using a bare metal approach, we use the XilSecure library. This library can be enabled within the BSP settings and provides a number of APIs, which allow access to the Crypto Interface Block.
Once the XilSecure Library is included within the projects BSP, to use a particular cryptographic engine we include the appropriate API for our applications needs in the source code.
For this example, we will be using the xsecure_aes API to perform a AES encryption.
The architecture of the code is very similar to most other peripherals in the PS or PL we wish to interface with from APU/RPU.
First, we need to initialise the CSU DMA, which is how we transfer plain and cipher text to and from the Crypto Interface Block.
Once this is completed, we need to define the AES encryption key and the initialization vector (IV).
If you are not familiar with the term initialization vector, the IV is a random string that prevents an attacker from inferring relationships between encrypted AES blocks using the same key.
We can then use the following API functions to perform an AES encryption. There is a similar set provided as well for decryption.
XSecure_AesInitialize() — initializes the AES accelerator with the key and initialization vector, and also provides the pointers to the CsuDMA and AES instance.
XSecure_AesEncryptInit() — initializes the AES accelerator with a pointer to the location the cipher text (encrypted output) is to be stored.
XSecure_AesEncryptUpdate() — performs the AES encryption and returns the cipher text and the GCM tag.
Once the AES EncryptUpdate completes, it will return the ciper text and GCM tag to the user.
Such built-in capabilities enable us to easily secure our systems, ensuring we can deploy our Zynq MPSoC and Ultra96-based systems at the edge.