From firmware updates to internet communication, security is an ever-increasing concern for embedded devices. The mathematics behind the cryptography used to implement these solutions is incredibly complex and one mistake can result in a catastrophic interoperability failure. How can embedded developers be assured that the heart of their product’s security works correctly?
Certifications are intended to simplify the identification of products that are fit for a specific purpose. For example, if you see a CE mark on the pint of beer you are served at a pub, you can be confident that you have indeed received a full pint of beer. If the mark is not present, you might still have received a full pint, but questions of non-compliance can be difficult to resolve with the bartender. The world of embedded electronic devices is very similar. For example, only USB devices that carry the USB logo must be certified, but a large number of perfectly functional USB devices that do not carry the USB logo are available. If you purchase a USB mouse that doesn’t function because of a poor USB implementation, it’s not a huge problem – you can very quickly see that the mouse does not function properly, and you can return it to the retailer. But what about functionality that isn’t so easy to see? And wouldn’t you rather avoid having to return the mouse in the first place?
Security certifications intended to simplify the design and implementation of secure embedded products are orders of magnitude more complex than our pint glass. Everyone agrees that something is necessary, but it seems that no one can agree on what that “something” is. One mapping of global IoT standards and recommendations has over 450 individual entities, including governments, standards associations, and universities. Something that is interesting to observe from this particular mapping is that many of these standards and guidelines reference standards created by the United States National Institute of Standards and Technology, or NIST.
NIST was established to improve the competitiveness of US businesses by correcting a second-rate measurement infrastructure. Since the main priority is interoperability, much of NIST’s security focus has been around identifying standard security algorithms and creating tests to ensure the operational correctness of those algorithms. Documents published by the Information Technology Laboratory of NIST are typically published as Federal Information Processing Standard (FIPS), Special Publications (SP), or Internal or Interagency Reports (IR). Some of these publications have associated tests and NIST certification, some have tests that implementers can execute, and some are informative guidelines.
At Renesas, we realize that it is important for embedded developers to have confidence that the underlying security algorithms in their product function correctly. A benchtop prototype that does not work when connected to the outside world is every engineer’s worst nightmare! The recent NIST Cryptographic Algorithm Verification Program (CAVP) certifications of the RA Family’s SCE9 Secure Crypto Engine demonstrate independent testing and verification of the cryptographic algorithms that form the heart of all security solutions, including secure Internet communications, where interoperability is vital. Combined with RA Family MCU Group declarations of passing NIST’s Statistical Test Suite for Random and Pseudorandom Number Generators (SP800-22), which are available on the Renesas website, you can be confident that RA Family MCUs provide a strong foundation for your secure product.
To learn more, including where to find software and solutions for Renesas MCUs and MPUs, visit our MCU IoT Security landing page.
You can get more information on the RA MCU family at renesas.com/ra, including app notes, security videos and downloads.
