v4 - FPT_TST.1 mismatch between SFR and normal expected usage of 1.2/1.3?

[woodbe]

FPT_TST.1.2 states that the users SHALL have a way to verify the integrity of the DRBG data. In use with this in similar situations, 1.2 and 1.3 are interpreted as REQUIRING the user be able to do this on their own. Basically the interpretation of this requirement was requiring a reboot to get this to be done was not considered acceptable, because that isn't a dynamic check.

So basically the idea that the user would have to reboot the device to check for the integrity of the 1.2 and 1.3 requirements is normally seen as not being correct.

It would seem like this could be handled with an app note specifying that reboot is an acceptable method for the user doing this.

Of course if I'm not interpreting the intent for 1.2 and 1.3, then maybe this is OK, if the expectation here is that the "user" is able to verify the data via the APIs that may be available to the DRBG, that also isn't clear. If the expectation is that the EA for this check is handled under one of the FCS_RBG requirements, that is also fine, but then this should be defined that the actual test is done there, but the "timing" of the test is covered here (and anything that isn't the DRBG is covered here).

[crpezol]

I think the interpretation of this requirement depends on if "verifying the integrity" is the same action as a "self-test" or a completely different action. Even reading the CC catalogue description of this SFR I don't think it makes it clear that these are either the same thing or different things, so I'm going to interpret these as the same thing all falling under the title of "self-testing".

To me this means that 1.1 specifies when the "self-test" happens, and 1.2 and 1.3 specify what should be tested and that an authorized user can see the results. If "at the request of the authorized user" is not selected in 1.1 then I don't think the testing has to be "dynamic" such that the authorized user can perform this test whenever they want, otherwise it would have been included in the selection. If only "during initial start-up" is included then the testing only has to happen after a reboot so I think that would be acceptable. I'll have to think up an app note to try and clarify this. Let me know if you agree.

[woodbe]

So I guess that could work, the follow-on question is what does it mean to verify the integrity? In most cases I'm familiar with of mobile devices, the "verification" is that the system actually boots. If the DRBG health check for the hardware fails, the device reboots. If it fails in a software component it likely throws a kernel panic (in user space it may attempt a restart before doing the panic). So the verification is implicit in that the device works, while negative verification is usually a reboot.

Is that a sufficient verification?

[crpezol]

Ultimately what I believe we want is for a malfunctioning/compromised DRGB to not be able to be used by the TOE. I would think that a vendor saying that if any of the self-tests fail then the TOE reboots or shuts down would be acceptable as it cant be used in the bad state. This is from FPT_TST_EXT and could probably also be included in the base FPT_TST as well "The TSS must include any error states that the TSF may enter when self-tests fail, and the conditions and actions necessary to exit the error states and resume normal operation."

[woodbe]

Yeah, as long as it is clear that it is acceptable. Probably fine in the app note, it's just that actual "verification" would normally imply that I get to see something. I don't think anyone really expects to see something for something like this, but on the EU PP I was working on, we were doing some adjustments around just this issue, and from someone else in the group, I got major pushback when I wrote the assignments like you are, and that's why I'm raising it. We ended up with the 1.2 and 1.3 just saying "none" and leaving the requirement to just the 1.1 (we also left it so it was just an integrity test because for a consumer device, the necessity of forcing the DRBG health check is obviously not a great, and we need to support devices that don't have the ability to support these requirements, but still, similar outcome).

[jfisherbah]

I don't think the FPT_TST_EXT note needs to be added because the "error states and conditions needed to resolve them" part is covered by FPT_FLS.1, which is the "what happens if a FPT_TST.1 failure is triggered." It says that in the app note for FPT_FLS.1 but it doesn't do the opposite so I think just calling that out in the FPT_TST.1 app note to nudge the reader over to that is sufficient.

[crpezol]

@jfisherbah I see you changed the app note of FPT_TST_EXT.1 to include " DRBG self-test functionality is specifically addressed by FCS_RBG.1.". Should that be changed to FPT_TST.1?

[jfisherbah]

yes - fixed

[crpezol]

@woodbe is this issue resolved? FPT_TST.1 also has the audit requirement of a failure of the self test. It seems like if the self test fails you were saying the TOE just reboots or shuts down, so an audit record might not be generated?

[woodbe]

So the table as it lists at the moment lists the "execution of the test" for FPT_TST.1. To me that is the start of the test, which may be OK, since it doesn't say anything about what happens in the case of a failure.

For FPT_TST_EXT.1 though, where it does explicitly list the failure event, yes, what I'm saying is that in many cases, a failure is catastrophic. Most (if not all, some of the hardware things may be a little different) of the modules throw a kernel panic if an algorithm test fails. That means nothing is recorded because there is no way to write once that happens. As a secondary issue, persistence of logs on some devices is related to "until the device reboots" so is the device has a kernel panic, not only does it not write the log, but by virtue of the reboot, logs are wiped.

Failures for the core crypto are basically extremely difficult to actually catch in any normal sense given we treat the event itself as something that has to be recovered immediately, forcing a restart.

[crpezol]

From the app note for table 2 under FAU_GEN.1:

[FPT_TST_EXT.1]) – Audit of self-tests is required only at initial start-up. Since the [TOE] "transitions to non-operational mode" upon failure of a self-test, per [FPT_NOT_EXT.1], this is considered equivalent evidence to audit data for the failure of a self-test.

I'm assuming that sufficiently covers the lack of a failure audit.

[woodbe]

In one way yes, in another no. I mean if the device reboots you would, you have a visual notice that something happens, but from an auditing standpoint you would probably have nothing, because the reboot would have happened prior to the audit records being recorded (since the device would still be starting up), so from a "I have the device in my hand and see the reboot" yes, but from a strict audit record/event standpoint, no. That's the issue with this requirement for this scenario. The place where the checks occur, and that the failure mode isn't "we'll leave the device running in a degraded condition" means that you have no insight into what happens, if you are fixated on having logs.

Really this is probably OK at the moment in that it is what we have had for some time, but this is a larger issue with mobile devices and auditing because in general they don't boot in some sort of degraded state when this type of test fails, so you basically have this whole class of possible events you have no way to get to because they will never be propagated to the point where you could actually get them into the SIEM for review.