Running the Suites
The suites are broken down into TLS handshakes, synthetic secure boots, and verification. The verification suite tests each primitive to make sure they were ported correctly.
The different strengths refer to the primitives selected for the suite. The user can also switch between GCM or CCM for the AEAD, and between RSA and ECC for secure boot. The following matrix illustrates what strengths and primitives are used for the suites:
In the screenshot below the result area shows the scores computed for the TLSv1.2 handshake, the TLSv1.3-Heavy handshake, and the heavy synthetic secure boot. Note that they user can select CCM or GCM for the handshake, and RSA or ECC for the synthetic secure boot. Had there been any errors with the implementation of the crypto layer, the “Validation” suite would have thrown an error and pointed to the bad primitive.
After each run, a “session” is created that contains all of the commands to the DUT, the transcript between the Host and the DUT (and IO Manager and EMON), the score table, and if used, the EMON trace. These are stored in $HOME/eembc or %USER%/eembc on Windows. These can be reloaded by clicking the upper left three-bar icon and reloading the session.
The option to select GCM or CCM is provided since not all accelerator hardware support both, typically it is one or the other. Changing this option will only impact the TLSv1.3 and Validation suites, and only Medium and Heavy strengths. TLSv12 did not offer GCM, and allowing it would make the results not comparable to historical scores.
Similarly to GCM vs CCM above, hardware may choose between implementing RSA or ECC for signature verification. Changing this option only impacts the Medium and Heavy strengths of the synthetic secure boot suite.