Security Evaluation approach
A security evaluation typically consists of a Vulnerability Analysis and a Penetration Testing phase. Both phases have their benefits, and often both of them are executed to evaluate the security of a product.
The Vulnerability Analysis is used to study the product and its context. The study is documentation based, so a physical product is not needed. A review of the design and code is in scope if the evaluation is done ‘white box’ style. The vulnerability analysis results in a report describing theoretical strengths and weaknesses of the product, within its context. The context is very important as this may amplify or mitigate potential weaknesses. As this phase does not include testing, it may not yet be possible to claim that a weakness can be exploited (and will become a problem in practice). Often the vulnerability analysis report includes a proposal for tests to be executed that should verify the exploitability of identified vulnerabilities. When only software security is in scope, and code review findings are conclusive, there is no need for additional testing. Otherwise, Penetration Testing is a valuable next step.
Security weaknesses can relate to the design, implementation, or configuration of a device. A Vulnerability Analysis is a white box review to identify those weaknesses. This evaluation phase is relevant for all vendors who wish to efficiently identify risks for their product. A Vulnerability Analysis can include:
The Penetration Testing focuses on physical products. It is meant to verify if potential weaknesses exist, and that known weaknesses can be exploited. Testing can be done on hardware and software. Products that reside in a secure environment may need only software testing (which can typically be executed remotely), but products that operate in a potentially hostile environment (as most consumer products do) will need local tests that require physical access. This includes Hardware Testing, Side Channel Testing, and Fault Testing. Penetration Testing results in a report detailing test results, including a rating per exploitable vulnerability. This can be used by the customer to prioritize resolving issues.
Device Level Hardware Testing
We test hardware at chip and device level. This is a physical activity that requires local access, and can be destructive. It is a relevant activity for products that rely on the strength of their hardware. Device level tests have medium complexity and are typically in scope for consumer products. At device level this includes:
Chip Level Hardware Testing
Chip level tests have high complexity and are typically not scalable. An attacker would use these methods to extract global information, such as sensitive code or keys. The tests are typically relevant for high-value products. Chip Level testing includes:
Side Channel Testing
These tests verify that confidential information is well protected by software and hardware in a chip, and exploit information leakage through channels not meant for communication. Attackers use these methods to extract secrets with medium effort, but this does almost always require physical access. We collect side channel information to retrieve secrets (keys and pass codes) from chips. We use the following side channels to collect data:
We measure power consumed by a chip by observing current consumption;
We measure EM radiation emitted by a chip by using sensitive probes that cover part of a chip and zoom in to leakage from specific chip functions;
We measure infra-red light radiated by a chip using cameras and other optical measurement devices to identify the location of sensitive functions, and extract secrets;
We measure execution time of chips and devices to extract passwords and secret keys.
We use a variety of analysis methods to extract secrets from measurement data:
- Simple Analysis
A method where observation of a side channel directly reveals secrets due to observable variations;
- Correlation Analysis
By repeating a sensitive process many times and correlating measurements we use statistical methods to extract secrets;
- Template Analysis
We use a large measurement set to learn about expected behavior for specific confidential information and build corresponding templates. Next we use a single measurement, or small set thereof, to match with the established templates and retrieve the secret information.
With our tests a customer learns about the strength of their product, and how hard it is for an attacker to extract secrets.
These tests use excessive environmental conditions to manipulate the behavior of a chip. These tests have medium complexity and are powerful tools for attackers who wish to gain control of a device. Such attacks can also be used to extract binary code and attempt to find scalable software vulnerabilities.
We introduce faults in the processing of a chip in order to change its behavior and extract sensitive information. We use the following perturbation mechanisms:
- Voltage perturbation
By creating a brief glitch in the power supply we corrupt intermediate data during processing, resulting in a wrong decision or output;
- Electro-Magnetic perturbation
A strong EM pulse creates an internal spike on chip data lines resulting in a fault;
- Optical perturbation
Laser pulses on and exposed chip surface forces individual transistors, or groups thereof to switch and trigger a fault.
Faults can be exploited for the following goals:
- Extract secret information directly by comparing correct and faulty results using Differential Fault Analysis;
- Privilege escalation by bypassing a security check;
- Data dump when an I/O routine is affected leading to extraction of code or sensitive data.
With our tests a customer learns about the robustness of their product and how hard it is for an attacker to take control.
We evaluate software security by:
We exhaust communication variations to identify unspecified behavior;
- Model Based Testing
We use malicious test cases to explore corner cases in device communication and expose confidential information. These tests are based on product security requirements, or on tester assumptions on the implementation of the product;
- Reverse Engineering
We use binary code dumps and analyze this to reconstruct the software structure, and identify weaknesses;
We use identified weaknesses (through code review or reverse engineering) to demonstrate that these can be used to attack the product.