MCUs
Standard for IoT Platforms (SESIP). This is published and promoted now by GlobalPlatform alliance, and defines a standard for trustworthy assessment of the security of the IoT platforms. The final purpose is to reuse it to fulfill the requirements of different product areas. As a matter of fact the common functional requirements are consolidated into SESIP “profiles”, such as Arm PSA L1 for the chip. Additional mappings for IEC 62443 and other standards are being developed.
Figure 2:
NIST framework core for improving critical infrastructure cybersecurity
can be found on the site
psacertified.org. Another well-known certification is related to the National Institute of Standards and Technology. NIST defines technologies, measurements, and standards which get specified into documents published by the Information Technology Laboratory of NIST, and collected within the Federal Information Processing Standards (FIPS). Such specifications include aspects related to various cryptographic algorithms, protocols, and functions, as deemed necessary for United States business purposes. According to those standards, the Cryptographic Algorithm Verification Program provides validation testing of Approved (i.e., FIPS-approved and NIST- recommended) cryptographic algorithms and their individual components. Algorithms that successfully pass the tests are added to a published validation list.
This certification guarantees functional correctness and interoperability, is not limited to US business but has a world-wide recognition, and is required or desired by various industry segments. If the final equipment needs to undergo certification, having a CAVP certificate on the cryptographic implementation can speed up significantly the process.
Therefore, Renesas is committed to validate the cryptographic functionality included in its SCE according to the CAVP program. Many implemented cryptographic blocks have already undergone certification; AES, SHA, and the DRBG portion of the true random number generator are all already CAVP certified. Both RSA and ECC are offered for asymmetric encryption, and are currently in in the process of obtaining CAVP certification. NIST publishes a list of the certified modules on its website. Lastly, let’s look at the Security Evaluation
MAY 2021 | ELECTRONICS TODAY 57
SESIP defines five assurance Levels, with increasing level of scrutiny. It starts with a self-assessment-based level, going to black-box penetration testing (for a closed-source platform), to a white-box vulnerability analysis (with a time-limited source code analysis combined with a time-limited penetration testing effort), up to higher levels which can be used to complement a SOG-IS certification, the latter including some standard common criteria assurance components and specific mappings. SESIP kind of has its roots within the common criteria certification program, which has a similar construct.
Lastly, many certifications have a common requirement to provide evidence about the development flow for the security related functionality. This implies that typically, during design phase, a security plan must be formulated, which establishes a framework for the successive phases. In close loop with the necessary threat analysis and security objectives specification, the security functionality (software or hardware) is defined, the secure design is performed, an implementation is created, then reviewed and unit tested. The characteristics of the implementation get finally evaluated before releasing the security related documentation and performing a final security audit. All of these steps must be properly documented
Figure 3: IEC62443 specification items
and logged.
Therefore, the vendor must undergo a significant amount of internal auditing and logging, while deploying internal guidelines and standards which fulfill the specification requirements. This evidence will be assessed by the certification agency in
correspondence to the evaluation assurance level to be targeted.
After a certain product has been developed and is available in mass production, the vendor has to take care of its lifecycle including defect management. Like for any general functional defect that might be discovered, there is the need to monitor and manage also any security related issues, as part of the product development lifecycle. A vulnerability might be defined as a weakness or defect within a product or system, which is exploitable (can be maliciously used) to compromise the product or system’s confidentiality, integrity, and/or availability.
The vendor must be committed to address any vulnerability found in the products, by analyzing them, disclosing them responsibly and performing the necessary and appropriate corrective actions as countermeasures. Many security related issues are found by external parties during evaluation of the product, therefore there is the need to put in place a point of contact to make sure those problems can be reported easily and confidentially for further analysis. For this purpose, Renesas has created a Product Security Incident Response Team (PSIRT) whose mission is to address any incident or security related issues in a timely manner. The website can be accessed via an easy to remember link:
www.renesas.com/psirt.
Over this portal and point of contact, customers and third parties can interact with Renesas to address their findings, and at the end help making better products for everyone.
Renesas Electronics
https://www.renesas.com/psirt
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68 |
Page 69 |
Page 70 |
Page 71 |
Page 72 |
Page 73 |
Page 74
