default banner
Go back to Blog posts

Side-Channel Attacks (SCA) are attacks that do not target the algorithms themselves, but rather their implementation. Standardized cryptographic algorithms such as AES, SM4, HMAC, SM2, etc. are mathematically secure but their implementation can feature some vulnerabilities which may allow an attacker to recover the sensitive assets that are manipulated by these algorithms. These vulnerabilities can be related with various kinds of side-channel information leakage, such as computation time, power consumption, electromagnetic emanation, etc.

These attacks, originally used in wartime by government agencies on opposing systems, are now becoming increasingly popular and easy to implement. Indeed, with a few thousands euros and little technical knowledge, it is possible to implement Side-Channel Attacks on different types of systems. For this reason, various standards organizations impose one or more Side-Channel protection(s) in their standards. For example, resilience to Side-Channel Attacks is explicitly stated as mandatory to target the enhanced profile of ChinaDRM certification (mandatory in China for content protection security evaluation) as well as many Protection Profiles (PP) defined in the Common Criteria framework.

The most powerful Side-Channel countermeasures are based on algorithms masking and/or randomization, but these types of countermeasures can be quite difficult to implement for non-security specialists. Poor or incomplete implementation of SCA countermeasures when discovered after manufacture can lead to significant cost issues by requiring the generation of new mask sets.

It is therefore important to validate the Side-Channel protections of a design as early as possible in the product life cycle and if possible during the design phase. Verification at a pre-silicon stage enables a high level of compliance to be achieved and therefore avoids additional expenses and delays in the chip’s time-to-market due to possible vulnerabilities that could be discovered post-silicon.

A classical method to check the resistance to Side-Channel Attacks is to use SPICE simulation results of the protected design. SPICE is a framework from University of California at Berkeley, which can be leveraged to produce the simulated power consumption trace. It is repeated several times to obtain a set of traces called a measurement campaign and subsequently referred to as a “dataset”. This dataset can then be analyzed like a real dataset (obtained by a hacker or an evaluator) to validate the resilience of the system. This pre-silicon verification method based on SPICE simulation allows a very accurate verification but has three main drawbacks:

  • The time required to generate the simulated dataset can be very long in case of complex design (up to several days),
  • The methodology requires the completion of all final phases to detect whether the system contains residual vulnerability or not,
  • It is very difficult to match problems to the faulty parts of the code (for example, the line of code that causes the leak) and thus to solve vulnerabilities in a reasoned way.

 

How does Secure-IC help proving side-channel attack resilience at pre-silicon stage?

To address these issues, Secure-IC has developed a tool called VirtualyzrTM which aims at detecting SCA vulnerabilities in RTL code and mapping these vulnerabilities to the RTL code to allow the designer to easily resolve them.

With VirtualyzrTM, the design is simulated using a COTS HDL simulator (VirtualyzrTM is compatible with all major commercial HDL simulators: ModelSim, NCSim, VCS, etc. as well as the open-source Verilator simulator). Based on this HDL simulation, a virtual trace is generated. The simulation is repeated as many times as necessary to obtain a dataset. This dataset is then analyzed using the same attack methods (SPA, DPA, DEMA, CPA, LRA, stochastic / template analysis, etc.) to validate the resilience of the design.

The methodology used by the tool is fully compliant with the methodology of ISO/IEC 17825:2016. Once the dataset is obtained, VirtualyzrTM starts by identifying vulnerabilities. These vulnerabilities are identified using statistical “leak detection” methods such as NICV, T-test or TVLA. Then, VirtualyzrTM checks whether these leaks are exploitable to recover sensitive assets. This step is ensured by mounting real key extraction attacks on the system under test: Simple Power Analysis (SPA), Differential Power Analysis (DPA), Correlation Power Analysis (CPA), Linear Regression Analysis (LRA), etc. Then as a final step, VirtualyzrTM maps the detected vulnerabilities to the design: VirtualyzrTM indicates the exact function of the design in which the vulnerabilities are present. VirtualyzrTM is also able to indicate which signal/cable is responsible for the leak, and when in time there is a leak of sensitive information.

 

VirtualyzrTM key advantages for proving Side-Channel Attack resilience:

  • Verification is done at a pre-silicon level and avoids going to the foundry with a poorly protected system;
  • Verification is performed on the RTL code, which avoids requiring a full back-end process in case of vulnerabilities—this does not prevent VirtualyzrTM from being used on the P&R netlist for a final sanity check;
  • HDL simulation reduces the time required to generate the dataset;
  • VirtualyzrTM helps the designer to easily solve vulnerabilities by indicating the lines of code, threads or signals to consider. In this respect, VirtualyzrTM is an essential non-regression assistant for the design team (and allows Design for Security (DFS) methodology implementation);
  • In particular, VirtualyzrTM has an extensive track record in detecting issues causes by protection mis-design, countermeasure incorrect implementation or mis-configuration, or countermeasure simplification by EDA tools.

Note that additionally to Side-Channel attack verification, VirtualyzrTM allows for Fault-Injection Attacks (FIA) vulnerability assessment at design stage. This is a worldwide unique feature.

 

Do you have questions on this topic and on our protection solutions? We are here to help.

Contact us

Go back to Blog posts
Contact