The use of a hardware-protected hash is an acceptable method of verifying the integrity of executable code post-kernel, but not pre-kernel. Thus FPT_TST_EXT.2.1 was iterated to differentiate between selectable methods pre-kernel and post-kernel.

Section 5.7.6

FPT_TST_EXT.2.1(1) The TSF shall verify the integrity of the bootchain up through the Application Processor OS kernel stored in mutable media prior to its execution through the use of [selection: a digital signature using an immutable hardware asymmetric key, an immutable hardware hash of an asymmetric key, an immutable hardware hash, a digital signature using a hardware-protected asymmetric key].

Application Note: The bootchain of the TSF is the sequence of firmware and software, including ROM, bootloader(s), and kernel, which ultimately result in loading the kernel on the Application Processor, regardless of which processor executes that code. Executable code that would be loaded after the kernel is covered in FPT_TST_EXT.2(2).

In order to meet this requirement, the hardware protection may be transitive in nature: a hardware-protected public key, hash of an asymmetric key, or hash may be used to verify the mutable bootloader code which contains a key or hash used by the bootloader to verify the mutable OS kernel code, which contains a key or hash to verify the next layer of executable code, and so on.

The cryptographic mechanism used to verify the (initial) mutable executable code must be protected, such as being implemented in hardware or in read-only memory (ROM).

Assurance Activity:

The evaluator shall verify that the TSS section of the ST includes a description of the boot procedures, including a description of the entire bootchain, of the software for the TSF’s Application Processor. The evaluator shall ensure that before loading the bootloader(s) for the operating system and the kernel, all bootloaders and the kernel software itself is cryptographically verified. For each additional category of executable code verified before execution, the evaluator shall verify that the description in the TSS describes how that software is cryptographically verified.

The evaluator shall verify that the TSS contains a justification for the protection of the cryptographic key or hash, preventing it from being modified by unverified or unauthenticated software. The evaluator shall verify that the TSS contains a description of the protection afforded to the mechanism performing the cryptographic verification.

The evaluator shall verify that the TSS describes each auxiliary boot mode available on the TOE during the boot procedures. The evaluator shall verify that, for each auxiliary boot mode, a description of the cryptographic integrity of the executed code through the kernel is verified before each execution.

The evaluator shall perform the following tests:

Test 1: The evaluator shall perform actions to cause TSF software to load and observe that the integrity mechanism does not flag any executables as containing integrity errors and that the TOE properly boots.

Assurance Activity Note: The following tests require the vendor to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products.

Test 2: The evaluator shall modify a TSF executable that is integrity protected and cause that executable to be successfully loaded by the TSF. The evaluator observes that an integrity violation is triggered and the TOE does not boot. (Care must be taken so that the integrity violation is determined to be the cause of the failure to load the module, and not the fact that the module was modified so that it was rendered unable to run because its format was corrupt).

Test 3: [conditional] If the ST author indicates that the integrity verification is performed using a public key, the evaluator shall verify that the update mechanism includes a certificate validation according to FIA_X509_EXT.1. The evaluator shall digitally sign the TSF executable with a certificate that does not have the Code Signing purpose in the extendedKeyUsage field and verify that an integrity violation is triggered. The evaluator shall repeat the test using a certificate that contains the Code Signing purpose and verify that the integrity verification succeeds. Ideally, the two certificates should be identical except for the extendedKeyUsage field.

Section D.6.5 (Objective)

*Note FTP_TUD becomes D.6.6

FPT_TST_EXT.2.1(2) The TSF shall verify the integrity of [selection: all executable code stored in mutable media, [assignment: list of other executable code]], stored in mutable media prior to its execution through the use of [selection: a digital signature using an immutable hardware asymmetric key, an immutable hardware hash of an asymmetric key, an immutable hardware hash, a digital signature using a hardware-protected asymmetric key, hardware-protected hash].

Application Note: All executable code covered in this requirement is executed after the kernel is loaded.

If “all executable code in mutable media” is verified, implementation in hardware or in read-only memory is a natural logical consequence.

At this time, the verification of software executed on other processors stored in mutable media is not required; however, it may be added in the first assignment. 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.

Assurance Activity

The assurance activity shall be completed in conjunction with FPT_TST_EXT.2(1) for all executable code specified.

The use of a hardware-protected hash is an acceptable method of verifying the integrity of executable code post-kernel. Since at this time, verifying the integrity of executable code post-kernel is not required, FPT_TST_EXT.2(2) is objective.