SFR Proposal

[woodbe]

This is my proposal for SFRs in the overview for next week.

[gregott]

3.2.1. Cryptographic Operations (FCS): Consider the case of an external sensor sending encrypted data to the TOE or a sensor sending signals to the TOE with source authentication and data integrity protections that are cryptographically based. Does the data/signal go to the platform to handle those cryptographic functions? Once the platform is finished the data/signal is it then routed to the TOE? If so, is the diagram in Figure 1 missing this data path into the TOE? Or is this scenario covered in the CMFA Signal Verification block? If it is in the Signal Verification block, then the TOE will have cryptographic requirements.

3.2.2.3. FDP_RIP.1 Subset residual information protection, FDP_RIP.1.1: When an object is no longer needed, it would be good to overwrite the memory that contained that object with a fixed pattern, or otherwise destroy the data, before releasing that part of memory/object to other uses. This would be a layer of security to augment that of the restricted environment. If this active overwriting does not excessively impact performance and battery, it would be good to have.

FIA_CMV_EXT.1.2: Assessing the “goodness” of CMFA performance is based on how good the input signals are and how the overall score is calculated at any moment in time. (This, of course assumes a “good” template is available.) This covers the suitability of a given input, i.e., is barometric pressure suitable for CMFA in a given use case? This also considers how the inputs are mathematically combined. Is too much weight given to a certain signal or too little? Is the speed with which the Trust Score decays in a given situation fast enough or too fast? This gets very complicated and very subjective. I do not think we will be able to define what is good enough. We should require the vendor describe these details so the user can understand, to some extent, how the CMFA decisions are being made.

We may want to limit how much influence an untrusted input or input that is easily spoofed has on the performance, such as no more than 30% of the Trust Score can be attributed to untrusted input signals or no more than 1/3 of the input signals used in a Trust Score calculation can be from untrusted sources.

This could easily be its own SFR.

3.2.3.3. Template Quality: This gets back to some of the same issues as with accuracy. How good the template is depends on how good the inputs are that were used to make up the template. I like the notion of separate enrollment and verification requirements tuned to each input type. For example, the biometric part of the template must meet a given quality standard. This was already addressed in the biometric enrollment, so we could just require that it be the same or better for CMFA. A given radio signal must be above xx dBm of received power or yy dB above the noise floor to be used for CMFA signal.

3.2.3.4. CMFA Signal Verification: The time period for performing Trust Score calculations and comparing them to the threshold, may be fixed or variable and adjusted by the environment the TOE perceives itself to be in. Whether or not it is fixed or adjustable is determined by the Admin.

3.2.3.5. CMFA Score: Some of the same thoughts apply here as mentioned above in the performance section. The score must be calculated in a way that makes sense. There are likely similar considerations when combining scores from different biometrics, i.e., biometric fusion.

FTP_TRP.1.3: Another reason for using trusted path is to provide more integrity to the input signals. If we assume the source of the input signal is good, and the path taken by the data from that source is trusted, we can have a higher confidence in that data.

[woodbe]

3.2.1. Cryptographic Operations (FCS): Consider the case of an external sensor sending encrypted data to the TOE or a sensor sending signals to the TOE with source authentication and data integrity protections that are cryptographically based. Does the data/signal go to the platform to handle those cryptographic functions? Once the platform is finished the data/signal is it then routed to the TOE? If so, is the diagram in Figure 1 missing this data path into the TOE? Or is this scenario covered in the CMFA Signal Verification block? If it is in the Signal Verification block, then the TOE will have cryptographic requirements.

So in this case, the external sensor would have say a BT connection to the device. This connection would be covered by BT encryption and handled on the connection itself, which would not be to the CMFA system. How the data is transferred to the CMFA is a different question, but ideally this data would be passed to the SEE once received from the sensor and then is passed to the verification system.

The end result is that there is not an encrypted connection between CMFA and the external component. In the future that could be possible, but even there I would expect the CMFA to use crypto from the SEE (i.e. a TEE or SE or whatever that environment is) as opposed to rolling its own.

[woodbe]

3.2.2.3. FDP_RIP.1 Subset residual information protection, FDP_RIP.1.1: When an object is no longer needed, it would be good to overwrite the memory that contained that object with a fixed pattern, or otherwise destroy the data, before releasing that part of memory/object to other uses. This would be a layer of security to augment that of the restricted environment. If this active overwriting does not excessively impact performance and battery, it would be good to have.

I agree that this is useful, but it isn't clear of the necessity or usefulness (at least at this time), which is why I note it as optional at this time. We did the same for biometrics; we initially planned to have it in but later removed it to rely on the base-PP instead to enforce the protections.

[woodbe]

FIA_CMV_EXT.1.2: Assessing the “goodness” of CMFA performance is based on how good the input signals are and how the overall score is calculated at any moment in time. (This, of course assumes a “good” template is available.) This covers the suitability of a given input, i.e., is barometric pressure suitable for CMFA in a given use case? This also considers how the inputs are mathematically combined. Is too much weight given to a certain signal or too little? Is the speed with which the Trust Score decays in a given situation fast enough or too fast? This gets very complicated and very subjective. I do not think we will be able to define what is good enough. We should require the vendor describe these details so the user can understand, to some extent, how the CMFA decisions are being made.

Yeah, I am not sure how to measure this. The real point I think is that there needs to be some sort of statement about the confidence of the determination. It doesn't mean we have to have a FAR/FRR value, but there needs to be some sort of claim here I think otherwise you have no idea how to measure the "quality" of the system.

We may want to limit how much influence an untrusted input or input that is easily spoofed has on the performance, such as no more than 30% of the Trust Score can be attributed to untrusted input signals or no more than 1/3 of the input signals used in a Trust Score calculation can be from untrusted sources.

This could easily be its own SFR.

So I agree with this (or at least a broad definition for it). I created a new grouping called template configuration and added this there. This would be where the management pieces (the ability to select inputs and weight them) would come together.

[woodbe]

3.2.3.3. Template Quality: This gets back to some of the same issues as with accuracy. How good the template is depends on how good the inputs are that were used to make up the template. I like the notion of separate enrollment and verification requirements tuned to each input type. For example, the biometric part of the template must meet a given quality standard. This was already addressed in the biometric enrollment, so we could just require that it be the same or better for CMFA. A given radio signal must be above xx dBm of received power or yy dB above the noise floor to be used for CMFA signal.

Yes, I would agree. I have added some more text around this as well as a new requirement under the template configuration about specifying the inputs that can be used and the constraints on them.

[woodbe]

3.2.3.4. CMFA Signal Verification: The time period for performing Trust Score calculations and comparing them to the threshold, may be fixed or variable and adjusted by the environment the TOE perceives itself to be in. Whether or not it is fixed or adjustable is determined by the Admin.

I added some more information about this in the FMT listing that provided a place for the admin to define the frequency.

[woodbe]

FTP_TRP.1.3: Another reason for using trusted path is to provide more integrity to the input signals. If we assume the source of the input signal is good, and the path taken by the data from that source is trusted, we can have a higher confidence in that data.

I added a description for this in the INFO.

[ccparran]

Probably not as critical as the other SFRs being discussed, but we might want to think about adding/extending an auditing requirement to audit some of the CMFA activity? Such as when the trust score falls below the threshold, when an admin makes configuration changes, etc. Is this possible? Just a thought.