FPT_TST_EXT.1.1 requires the use of a digital signature using a hardware-protected asymmetric key, or a hardware-protected hash, to verify the integrity of the bootchain. Test 3 states that the “update mechanism includes a certificate validation according to FIA_X509_EXT.1” if a public key is used. This appears to be in error since Test 3 mentions “update” and Test 3 is the only mention of X.509 in the SFR, Application Note, and Evaluation Activity.

FPT_TST_EXT.1.1 and its application note are modified as follows, with strikethroughs denoting deletions and underlines denoting additions:

FPT_TST_EXT.1.1 The OS shall verify the integrity of the bootchain up through the OS kernel and [selection:

- all executable code stored in mutable media ,

- [assignment: list of other executable code ],

- no other executable code

] prior to its execution through the use of [selection:

·         a digital signature using a hardware-protected asymmetric key,

·         a digital signature using an X509 certificate with hardware-based protection,

·         a hardware-protected hash

] .

Application Note: The bootchain of the OS is the sequence of software, to include the OS loader, the kernel, system drivers or modules, and system files, which ultimately result in loading the OS. The first part of the OS, usually referred to as the first-stage bootloader, must be loaded by the platform. Assessing its integrity, while critical, is the platform's responsibility; and therefore outside the scope of this PP. All software loaded after this stage is potentially within the control of the OS and is in scope.

The verification may be transitive in nature: a hardware-protected public key, X509 certificate or hash may be used to verify the mutable bootloader code which contains a key, certificate or hash used by the bootloader to verify the mutable OS kernel code, which contains a key, certificate or hash to verify the next layer of executable code, and so on. However, the way in which the hardware stores and protects these keys is out of scope.

If all executable code (including bootloader(s), kernel, device drivers, pre-loaded applications, user-loaded applications, and libraries) is verified, "all executable code stored in mutable media" should be selected.

If certificates are used, they can be hardware protected trust store elements or a leaf certificate in a certificate chain that terminates in a root CA which is an element of a hardware protected trust store. If the certificates themselves are not trust store elements, revocation information is expected to be available for each CA certificate in the chain that is not a trust element, in accordance to FIA_X509_EXT.1.

Test 3 is modified as follows, with strikethroughs denoting deletions and underlines denoting additions:

Test 3[conditional]: If the ST author indicates that the integrity verification is performed using a public key in an X509 certificate, the evaluator will verify that the update boot integrity mechanism includes a certificate validation according to FIA_X509_EXT.1 for all certificates in the chain from the certificate used for boot integrity to a certificate in the trust store that are not themselves in the trust store. This means that, for each X509 certificate in this chain that is not a trust store element, the evaluator must ensure that revocation information is available to the TOE during the bootstrap mechanism (before the TOE becomes fully operational).

See issue description.