Results - ChairImpSec/PROLEAD GitHub Wiki
Console Output
PROLEAD continuously displays the current evaluation results on the console. Below is an example of the console output during an evaluation of first-order security under the robust probing model in normal mode:
-------------------------------------------------------------------------------------------------------------------------------------
| #Standard Probes | #Extended Probes | #Probing Sets | Minimum #Probes per Set | Maximum #Probes per Set | Average #Probes per Set |
-------------------------------------------------------------------------------------------------------------------------------------
| 63 | 75 | 63 | 4 | 9 | 6.142857 |
-------------------------------------------------------------------------------------------------------------------------------------
Evaluate security under the robust probing model!
----------------------------------------------------------------------------------------------------------------------------------------
| Elapsed Time | Required Ram | Processed Simulations | Probing Set with highest Information Leakage | -log10(p) | Status |
----------------------------------------------------------------------------------------------------------------------------------------
| 0.024586s | 3.792712GB | 3200 / 20325 | [share2[3](2)] | 16.714087 | LEAKAGE |
| 0.029380s | 3.792844GB | 6400 / 20325 | [share2[3](2)] | 34.191856 | LEAKAGE |
| 0.034193s | 3.792844GB | 9600 / 20325 | [share2[3](2)] | 47.404428 | LEAKAGE |
| 0.038922s | 3.792844GB | 12800 / 20325 | [share2[3](2)] | 71.011855 | LEAKAGE |
| 0.042672s | 3.792844GB | 16000 / 20325 | [share2[3](2)] | 89.630361 | LEAKAGE |
| 0.047150s | 3.792844GB | 19200 / 20325 | [share2[3](2)] | 111.988367 | LEAKAGE |
| 0.051861s | 3.792844GB | 22400 / 20325 | [share2[3](2)] | 131.447051 | LEAKAGE |
| 0.056635s | 3.792844GB | 25600 / 20325 | [share2[3](2)] | 142.839991 | LEAKAGE |
| 0.061358s | 3.792844GB | 28800 / 20325 | [share2[3](2)] | 169.059104 | LEAKAGE |
| 0.064959s | 3.792844GB | 32000 / 20325 | [share2[3](2)] | 186.577086 | LEAKAGE |
----------------------------------------------------------------------------------------------------------------------------------------
Evaluation done in 0.06564 seconds!
Initial Evaluation Overview
The first table provides preliminary information about the evaluation process. This information can be used to estimate the required evaluation time and memory usage, allowing the user to adjust settings before the evaluation begins. The parameters listed in the table are explained below:
Output Parameter | Description |
---|---|
#Standard Probes |
The total number of different standard probes. |
#Extended Probes |
The total number of probes resulting from the probe extension procedure. |
#Probing Sets |
The total number of different probing sets considered by PROLEAD. |
Minimum #Probes per Set |
The minimum number of probes in a single probing set. |
Maximum #Probes per Set |
The maximum number of probes in a single probing set. |
Average #Probes per Set |
The average number of probes over all probing sets. |
Ongoing Evaluation Results
The second table continuously updates to show the progress of the evaluation. This includes information about the simulation time, memory usage, and potential information leakage. Each parameter in this table is defined below::
Output Parameter | Description |
---|---|
Elapsed Time |
The total time elapsed since the evaluation began. |
Required Ram |
The amount of RAM used by PROLEAD up to the current point in the evaluation. |
Processed Simulations |
The number of simulations processed so far. If evaluating in normal mode, the total number of simulations required to achieve the predefined statistical power is shown after a backslash. For example, 3200/ 20325 indicates that 3,200 simulations have been processed, while only 20,325 were necessary for the desired statistical power. |
Probing Set with highest Information Leakage |
The probing set that exhibits the highest information leakage. Standard probes are identified by their signal names and the corresponding clock cycle (in parentheses). For instance, share2[3](2) indicates a probe on the share2[3] wire during clock cycle 2. |
-log10(p) |
The smallest p-value from the g-test in logarithmic form, showing the highest -log10(p) value observed. |
Status |
The interpretation of the -log10(p) value. Typically, a status of OKAY indicates that -log10(p) is less than 5, meaning no significant leakage has been detected. If -log10(p) is 5 or higher, the status changes to LEAKAGE , indicating detected information leakage. |
Reports
In addition to console output, PROLEAD can generate detailed reports after each simulation step. Below is an example report:
Report file after 32000 simulations:
1.) Summary of most leaking (and still active) probing sets per clock cycle:
Clock cycle 1: @[y3_n12(0)] ==> [g3Reg[2](0), en(0), sboxIn1[1](0), sboxIn1[2](0)] -log10(p) = 1.67424 --> OKAY
Clock cycle 2: @[share2[3](1)] ==> [g1Reg[0](1), g1Reg[3](1), g3Reg[0](1), g3Reg[1](1), g3Reg[2](1), g3Reg[3](1)] -log10(p) = 186.577 --> LEAKAGE
Clock cycle 3: @[share2[3](2)] ==> [g1Reg[0](2), g1Reg[3](2), g3Reg[0](2), g3Reg[1](2), g3Reg[2](2), g3Reg[3](2)] -log10(p) = 186.577 --> LEAKAGE
2.) Summary of the most leakging (and still active) probing sets:
1: @[share2[3](2)] ==> [g1Reg[0](2), g1Reg[3](2), g3Reg[0](2), g3Reg[1](2), g3Reg[2](2), g3Reg[3](2)] -log10(p) = 186.577 --> LEAKAGE
2: @[share2[3](1)] ==> [g1Reg[0](1), g1Reg[3](1), g3Reg[0](1), g3Reg[1](1), g3Reg[2](1), g3Reg[3](1)] -log10(p) = 186.577 --> LEAKAGE
3: @[share3[2](1)] ==> [g1Reg[0](1), g1Reg[1](1), g1Reg[3](1), g2Reg[0](1), g2Reg[1](1)] -log10(p) = 108.937 --> LEAKAGE
4: @[share3[2](2)] ==> [g1Reg[0](2), g1Reg[1](2), g1Reg[3](2), g2Reg[0](2), g2Reg[1](2)] -log10(p) = 108.937 --> LEAKAGE
5: @[share1[3](2)] ==> [g2Reg[0](2), g2Reg[1](2), g2Reg[2](2), g2Reg[3](2), g3Reg[0](2), g3Reg[3](2)] -log10(p) = 32.2514 --> LEAKAGE
6: @[share1[3](1)] ==> [g2Reg[0](1), g2Reg[1](1), g2Reg[2](1), g2Reg[3](1), g3Reg[0](1), g3Reg[3](1)] -log10(p) = 32.2514 --> LEAKAGE
7: @[share3[3](2)] ==> [g1Reg[0](2), g1Reg[1](2), g1Reg[2](2), g1Reg[3](2), g2Reg[0](2), g2Reg[3](2)] -log10(p) = 2.04167 --> OKAY
8: @[share3[3](1)] ==> [g1Reg[0](1), g1Reg[1](1), g1Reg[2](1), g1Reg[3](1), g2Reg[0](1), g2Reg[3](1)] -log10(p) = 2.04167 --> OKAY
9: @[y3_n12(0)] ==> [g3Reg[2](0), en(0), sboxIn1[1](0), sboxIn1[2](0)] -log10(p) = 1.67424 --> OKAY
10: @[y3_n12(1)] ==> [g3Reg[2](1), en(1), sboxIn1[1](1), sboxIn1[2](1)] -log10(p) = 1.67424 --> OKAY
The report is divided into two sections. Each probing set is formatted as follows:
@[standard probes] ==> [extended probes] -log10(p) = ... --> OKAY/LEAKAGE
Most Leaking Probing Sets per Clock Cycle
This section lists the probing set with the highest information leakage for each clock cycle. If a probing set contains probes from different clock cycles, the highest clock cycle is used.
Most Leaking Probing Sets of the Entire Evaluation
This section summarizes the probing sets with the most significant information leakage across the entire evaluation.
Interpretation
At the conclusion of the evaluation, the critical question is whether the design is secure under the evaluated model. Since PROLEAD is not a formal verification tool, interpreting the results may involve some uncertainty. Below, we discuss potential issues related to false positives and false negatives.
False Positives
PROLEAD reports a design as insecure if the -log10(p) value of any probing set exceeds 5.0, which corresponds to a false-positive probability of 0.00001. However, as the number of probing sets increases, so does the likelihood of encountering false positives. Therefore, exceeding the 5.0 threshold should not be considered a definitive indicator of an insecure design. If PROLEAD reports LEAKAGE
, it is advisable to continue the evaluation and monitor the -log10(p) values over time. If these values do not increase with additional simulations, the detected leakage may be a false positive.
False Negatives
Since PROLEAD simulates random inputs rather than considering all possible circuit states, there is a risk that some leakage may go undetected, particularly if too few simulations are run. To minimize the chance of false negatives and obtain reliable results, we recommend the following:
- Consider at least 100 million simulations for any hardware evaluation in the compact mode.
- Consider at least 1 million simulations for any software evaluation in the compact mode.
- Consider enough traces to detect any leakage with an effect size of 0.1 or larger for any evaluation in the normal mode.