[SiVal/cryptotest] Common crypto test framework

[moidx]

Description

Overview

Cryptolib verification and silicon validation are activities that will take place in parallel. In both cases we want to have the ability to inject test vectors to verify functionality, perform compliance testing against NIST test vectors, test against known attacks (e.g. wycheproof), as well to enable instrumentation for penetration testing. This issue tracks the implementation of an unified framework to meet the testing goals listed above.

Implementation Proposal

1. Implement a device target program providing access to the cryptolib API via a serial interface. Having a single binary will simplify code signing and test deployments.
2. Design a serial interface allowing injection of crypto commands / test vectors. Use the JSON transport layer currently employed in ROM E2E and manufacturing testing. This will simplify integration into all existing test environments.
3. The serial interface should also take into account testing at the cryptolib TockOS wrapper level. The implementation of a TockOS application to enable testing using this interface should be consider as a follow up of this initial proposal, but it is not necessarily required to enable silicon validation activities.
4. Host side infrastructure should be implemented on top of opentitanlib and exposed in opentitantool to maintain a common host-side test stack.

Silicon Validation (SiVal) Considerations

SiVal test plans will focus on:

1. Stress testing on the cryptolib interface, which only exposes a subset of the functionality available in hardware.
2. DIF driven testing to cover functionality not exposed in the cryptolib API.

Compliance Testing Considerations

Decided on either:

a. Implement opentitanlib support for various test vector formats (e.g. NIST, wycheproof) b. Implement an utility to convert various test vector formats into the JSON format supported by the test framework.

Penetration Testing Considerations

Consult with penetration testing lead potential use cases and document requirements. Ideally, the implementation should not preclude future support for enabling the following features:

1. Sample configuration, including but not limited to, clock injection via clk_ext on test samples.
2. Trigger configuration via IO.
3. Support for single and stream captures. Where stream captures are synchronized.

Since Python is better suited for penetration testing, we may end up deciding to maintain the pentesting tooling separate from opentitantool. In this case it is still worth discussing whether it makes sense to align on a common serial protocol.

[moidx]

CC @jadephilipoom, @johannheyszl, @vogelpi, @timothytrippel

[johannheyszl]

cc @bilgiday

[johannheyszl]

Discussed in Sec WG 2023-10-12: There seems to be good alignment on this b/w people involved. A design doc exists. Moving forward.

[moidx]

Marking as completed. Thanks @milesdai, @RyanTorok, @nasahlpa, @jadephilipoom, @johannheyszl for all your contributions enabling this test framework!

cryptotest test vector implementation to be tracked via cryptolib test plan.