1
|
The set of relevant device components undergoing self-tests.
|
2
|
All self-tests performed by the relevant device components, including validation of any register settings relied upon for the security of the device.
|
3
|
How initial machine code is loaded and executed by the processing elements, and how any subsequent firmware modules are loaded and executed, up to and including software modules used.
|
4
|
The algorithms and key sizes used to perform self-test functions.
|
5
|
The methods implemented to authenticate the cryptographic keys to ensure they have not been modified after loading.
|
6
|
Any self-test functions implemented by the built-in functions of the security processing elements and what sources of information and testing have been used to validate that these processes are in place.
|
7
|
The response of the device to a self-test failure for each type of component.
|
8
|
The types of events that initiate self-tests for each type of test.
|
9
|
The types of events that initiate a device reset, including elapsed time.
|
10
|
In detail, each self-test performed by the device on power-up and periodically during operation. Which of the techniques are consistent with FIPS PUB 140-2?
|
11
|
How the self tests are performed, either how periodic tests are induced or how continuous testing is implemented.
|
12
|
If applicable, how frequently the periodic self-tests are executed.
|
13
|
The conditional tests performed by the device. Which of the techniques is consistent with FIPS PUB 140-2?
|
14
|
How the conditional self-tests are induced.
|
15
|
The status provided by the device when power-up, periodic, and conditional self-tests execute successfully.
|
16
|
The actions of the device on a failure of each self-test
|
17
|
The algorithms used to perform the power-on firmware authenticity and integrity test. If the device supports firmware load, describe the firmware-load test, including the algorithms used.
|
Comments:
|