Mission Impossible: Prove Security
Ron Keidar, Rambus, March 2020
The ever-growing need for security is a well-established fact in today’s SoC and Systems design world; every day we hear about a new attack that gains glory overnight – this glory usually connected to a very significant damage that was inflicted to something or someone, somewhere in the globe.
Thus, together with the need for security, comes the need to prove that your design is secure. Which is easier said than done. A design is thought to be secure until a vulnerability is uncovered and exploited. What seemed to be rock solid just a moment ago, becomes suddenly a darn dangerous product to be even considered in your system.
In this paper, some historical perspective is given about a couple of infamous security breaches from the past, the roles of the FIPS criteria and SCA avoidance on making your design more secure, and how (and why) to progress from FIPS 140-2 to FIPS 140-3 as we move on and make our designs more secure
Security is an SoC Commitment! Rambus Security is here to help.
The Meltdown and Spectre attacks
Meltdown and Spectre destabilized a safe ground when they exposed a vulnerability in mainstream CPUs that the entire world trusted and used for more than 20 years.
Moreover, they were innovative on not trying to crack down the security, root an OS, or bypass a privilege mode; instead, they traced a minor leak of information in observing line changes in the CPU cache: by measuring memory ready times, they revealed cache hits and misses and through them, exploited key extraction!
Such attacks in which, rather than attempting to crack the security mechanism itself, leaked information is observed and used to uncover secrets in the implementation, are called Side Channel Analysis (SCA) Attacks.
SCA goes back a long time. Maybe the best-known old-school SCA attack is simply listening to the mechanism of an old safe. By identifying the ‘clicks’ when a right number is locked, the attacker can easily identify a hit and move to the next number.
In 1995, Paul Kocher founded Cryptography Research Inc (CRI). In 1996, he published a breakthrough article on timing attacks in all major cryptography research news magazines of that time.
In 1999, he published yet another major research, this time defining for the first time Differential Power Analysis (DPA). And finally, in 2018, Spectre was discovered by two researchers, one of them Paul Kocher.
In 2011 CRI was acquired by Rambus – creating the initial operations of what is known today as Rambus Security – the Security IP Business Unit of Rambus Inc.
How much Leakage is a Leak?!?!
Rambus invested a lot and became a world leader in solutions that do not leak, with the help of Cryptography IP cores and Cryptography SW libraries that would squash the leaks.
Rambus has also developed a unique workstation to detect and analyze leakage: as it turns out, leakage is very complex to detect and avoid, and the Rambus workstation is a unique tool to enable this analysis.
For standards and certification, leakage needed to be metered and so the Test Vector Leakage Assessment (TVLA) was defined. Rather than mounting a time-consuming attack to recover secret key information, TVLA seeks to detect and analyze leakage directly in a device under test, making the process convenient for certification efforts.
At the same time….
Back in 2001 NIST (the US National Institute of Standards and Technology) published a criteria for evaluating Security Modules known as FIPS 140-2. FIPS 140-2 sets levels of protection and detection and requires all Federal Agencies in the US and Canada to use only FIPS 140-2 certified products. However, it does not address the “new” discoveries around SCA Attacks, thus there is space for more in terms of coverage and legislation.
FIPS 140-2 became a differentiator and a must for any silicon vendor that considers or may consider in the future to sell to any US Federal Entity, or any governmental agencies, world-wide.
FIPS 140-2 is dead! Long live FIPS 140-3!
Not so fast, but soon! Following FIPS 140-2, NIST is now publishing FIPS 140-3, this time endorsing multiple ISO standards, hence creating a certification that has a more global value. The timeline for FIPS 140-3 is:
FIPS 140-3 was approved on 22nd March 2019.
FIPS 140-3 CMVP (Cryptographic Module Validation Program) testing begins on September 22, 2020.
After FIPS 140-3 testing begins, FIPS 140-2 testing will end on 22nd September 2021
Connecting all dots - like a good old Agatha Christie thriller!
FIPS 140-3 uses ISO 19790 for Cryptographic Modules
ISO 19790: 2012 “Security requirements for cryptographic modules” uses two other standards:
ISO/IEC 24759:2017 “Test requirements for cryptographic modules”
ISO/IEC 17825:2016 “Testing methods for the mitigation of non-invasive attack classes against cryptographic modules” - uses TVLA to define leakage
For FIPS 140-3 Level 3 or 4 certification - a security module is required to prove good TVLA
Remember: what is in it for you
FIPS 140-3 certification increases your market directly or indirectly
You are likely to need resistance against SCA whether you decide to certify or not.
If you already have a good cryptographic module, remember you can measure its TVLA with Rambus DPA Workstation (DPAWS)
If you build a new cryptographic module, ask about Rambus DPA resistant IP cores
If you build security in software, do ask about Rambus DPA resistant library.
For managing your Root of Trust in a DPA resistant environment, ask about Rambus CMRT Crypto Manager Root of Trust.