[Public Interpretations Database]

PD-0093: Questions Concerning the Peripheral Sharing Switch PP

This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.

Effective Date: 2003-05-23
Last Modified 2006-08-02

Issue

In the course of using performing an evaluation against the Peripheral Sharing Switch (PSS) for Human Interface Devices Protection Profile (version 1.0, 8 August 2000), several questions arose:

  1. The first section of Section 2, Paragraph 3: "In operation, the TOE will be CONNECTED to only one computer at a time." This sentence when taken literally, defeats the purpose of the device. A correctly written PP would not have statements that require inference that the author meant this in a logical manner versus a physical requirement statement.

  2. The assumption A.PHYSICAL (Section 3.1) and the threat T.PHYSICAL contradict each other. This is further confusing by the environmental objective OE.PHYSICAL. NOTE: the whole section of environmental objectives mirrors that of assumptions and makes the objectives those of the TOW. Additionally, the lead in paragraph contradicts some of the objectives (e.g., the intro paragraph states, "These objectives are to be satisfied without imposing technical requirements…" yet there is OE.EMISSION: "The TOE shall…"

  3. The assumption A.ISOLATE (Section 3.1) is a partial assumption of the Data Separation Flow Policy - any issues regarding this channel and this SFP are assumed.

  4. The assumption A.MANAGE (Section 3.1) along with the assumption A.NOEVIL, clearly contradict the threat T.INSTALL.

  5. The assumption A.SCENARIO appears to contradict T.SPOOF.

  6. The threat T.BYPASS can be taken to read that the threat is really a matter of physical connections - e.g., the TOE is disconnected.

  7. The threat T.SPOOF is worded such that it can be taken to mean that the TOE can determine what is at the end of the physical connection.

  8. The security objective O.INVOKE - "Upon switch selection, the TOE is invoked." - is a ludicrous statement (the first paragraph of Section 2 says (paraphrasing) "the TOE is the switch" how can a device be invoked.

  9. The last statement in O.SELECT - ref. Automatic scanning - contradicts the TOE description given in Section 2, paragraph 8.

  10. The objectives O.NOPROG and O.ROM say basically the same thing - this is either redundant objectives, or the point of the objectives is obscured.

  11. The SFR FDP_IFF.1-1 (Section 5.1.1.3) is an incorrect assignment.

  12. The SFR FMT_MSA.3 (Section 5.1.2.2), obviously used because of the dependency required by FDP_ITC.1, makes no sense, especially with the application note. NOTE: if an application note is required, then the requirement is flawed. The authors should have used an explicitly stated requirement.

  13. The rationale section has numerous logic flaws:

    • It is illogical that O.CONF can counter a physical threat to the TOE;

    • O.INVOKE states that the TOE must be invoked … This contradicts the first sentence of the TOE description, Section 2, where it states that the TOE is a device;

    • It is not clear that O.NOPROG can counter a physical attack to the TOE - a physical attack can circumvent programmed chips;

    • It is not clear that O.ROM can counter a physical attack to the TOE - a physical attack can circumvent programmed chips;

    • It is illogical that O.SELECT can counter T.SPOOF;

    • The rationale provided for the Security Requirements Rationale, Section 6.2 has logic flaws, (e.g., FPT_RVM.1 and FPT_SEP.1) in spite of the argument that there are "no untrusted processes."

  14. There are no SOF claims - ratings or otherwise (requirements).

Resolution

After consulting with the authors of the PP to understand their intent, the CCEVS has decided upon a way forward for each of these questions. These are to be used for all future evaluation against this Protection Profile.

  1. Page 38 of the PP defines "connected" and "connection" in terms of logical pathways, rather than the physical pathways that, we agree, would make no sense in the context of this TOE. Given these definitions, there is nothing in need of correction in the PP.

  2. There seems to be a misunderstanding about the interrelationships among threats and assumptions, undoubtedly due the lack of clarity in the CC. The following explanation is therefore provided:

    Threats may be two types: those to be addressed by the TOE (either completely or partially), or those to be addressed by the environment. These are the topic of ASE_ENV1.2C. (In theory, there might be a third type of threat - residual threats not expected to be addressed at all - but for the purposes of a TOE evaluation, these would be included as threats to be addressed by the environment.)

    Assumptions might also be of two types: assumptions made about the TOE, and assumptions made by the TOE (about its environment). The CC does not make any such distinction, but PP and ST writers often do.

    Objectives are divided by the CC into those for the TOE and those for the environment. Environment objectives are acknowledged, but then they are not used again in the CC. The TOE objectives, on the other hand, are used as the basis for the Security Requirements: meeting the objectives is the goal of the selected requirements (i.e., if all of the requirements are met, then all of the objectives will be met.)

    Objectives for the TOE are derived directly from OSPs (which state what the TOE must do), and indirectly from the Threats to be addressed by the TOE (in terms of providing what the TOE must protect against).

    It is worth pointing out that, although they are not mentioned again, the Objectives for the environment are derived not only from the Threats to be addressed by the environment (as one would expect), but also from the Assumptions made by the TOE on its environment. The TOE's assumption of the presence of something in its environment implies that there is an implicit objective on that environment.

    As was said earlier, a lot of the confusion comes about because the CC provides no guidance on how Threats, Objectives, Assumptions, or OSPs are to be written (any one of them could be recast into the form of any other one). Likewise there is no guidance on what constitutes a good or worthwhile assumption, etc. The result of this lack of guidance is that sometimes a PP writer can create an assumption made by the TOE, which corresponds to a threat to be countered by the environment. Sometimes (e.g., a threat that users will gain access to the underlying environment without being authenticated and an assumption that the environment will provide all necessary user authentication), such a combination results in an objective for the environment (i.e., the environment must authenticate all of its users). Other times, however, the assumption made by the TOE and the corresponding threat to be countered by the environment cancel out each other (e.g., an assumption that the TOE will be physically protected and a threat that unauthorized physical access can corrupt the TOE). In such cases, there would be no resulting objectives for the environment; the threat and assumption could both be deleted and nothing else would change. While there is nothing erroneous in including both of them, it does lead to potential confusion and misunderstanding.

  3. The wording of A.ISOLATE ("Only the selected computer's video channel will be visible on the shared monitor") is not appropriate for an assumption. It is written more like an Objective statement or an OSP. This should be clarified in an update to the PP. However, the PP needs not be corrected in order for it to be used in an evaluation.

  4. As was discussed in issue 2, the situation is not one of contradiction, but rather a case where the two assumptions mitigate the expressed threat. This should be clarified in an update to the PP. However, the PP needs not be corrected in order for it to be used in an evaluation.

  5. As was discussed in issue 2, the situation is not one of contradiction, but rather a case where the assumption mitigates the expressed threat; both could be omitted from the ST and deleted from the PP with no residual effect. This should be clarified in an update to the PP. However, the PP needs not be corrected in order for it to be used in an evaluation.

  6. This is an example of a threat to be addressed by the environment: if the environment is not set up correctly, the TOE might be excluded from the whole picture; this is not a concern for the TOE. This should be clarified in an update to the PP. However, the PP needs not be corrected in order for it to be used in an evaluation.

  7. T.SPOOF ("Via intentional or unintentional actions, a user may think the set of shared peripherals are connected to one computer when in fact they are connected to a different one") is a threat to be addressed by the environment. As was discussed under issue 2, it is acceptable to include such threats, despite the fact that the TOE will not be completely addressing them. This should be clarified in an update to the PP. However, the PP needs not be corrected in order for it to be used in an evaluation.

  8. This Objective statement ("Upon switch selection, the TOE is invoked") is poorly worded. It should be understood as, "Upon switch selection, the indicated output port will be the only connection from the input port". The PP authors make a distinction between the TOE and the physical switch, which (along with the indicator lights, etc.) is a part of the TOE. The path to the device (i.e., the connection) is what is invoked by the physical switch.

  9. The general description of switches on page 6 should include a note that says which of the possibilities just outlined are outside the scope of the PP. However, the statement in O.SELECT makes it clear that automatic scanning is such a case. This should be clarified in an update to the PP. However, the PP needs not be corrected in order for it to be used in an evaluation.

  10. These two Objective statements seem to say the same thing. They even map to the same set of requirements, but the differences depend upon the TOE implementation. O.NOPROG applies to TOEs that use programmable logic arrays or hardware-only TOEs; O.ROM applies to TOEs with microprocessors. The difference between these two objectives can be clarified in a future version of this PP.

  11. The explanations in parenthesis indicate which parts of the assignments are being fulfilled. A clearer articulation of the rules being enforced can be found in FDP_IFC.1. The rules that the PP authors are conveying are:

    The TOE shall enforce a transmission flow with the following properties:

    1. Data shall flow only between the input port and the indicated output port.

    2. There shall be sufficient electrical and physical isolation between the multiple output ports to ensure that only the indicated output port is connected to the input port.

  12. FMT_MSA.3 makes sense in a software implementation because PPs should be implementation independent. The authors could not presume that the TOE would be a hardware-only solution therefore, the application note was provided.

  13. The relationship between threats and objectives is being misunderstood here; these are cases of threats to be countered by the environment being mapped to Objectives for the TOE (see Issue 2).

    • The objective for confidentiality will not completely counter the physical threat; if the physical threat is realized, then the output ports could be tied together thereby breaking confidentiality.

    • O.NOPROG and O.ROM (see also issue 10) are likewise objectives that will not be completely met if the physical security threat is realized. The environmental threat of T.SPOOF is not addressed by the TOE objective O.SELECT. It is useful to note how the TOE contributes towards mitigating the threats.

    • The O.INVOKE problems cited (the contradiction with the TOE description and the mapping to FPT_RVM) result from the unclear objective statement (see Issue 8).

    • As for the comment on the mapping of FPT_SEP and O.NOPROG/O.ROM: the need for the separation requirement seems to be a straightforward consequence of objectives dealing with protecting the logic from unauthorized modification.

    • The rationale section currently is sufficient.

  14. PD-0048 (dated July 17, 2000) notes that when there are no permutational or combinational mechanisms, AVA_SOF.1 is satisfied vacuously. (This is relevant only when an EAL is being claimed, because SOF is included in EALs.) Section 6.2 of the PP explicitly states no SOF claim is being made. However, if the ST would like to make an SOF claim (although it's not clear on what mechanisms this claim would be made), there is nothing to prohibit them from doing so and thereby exceed the PP.

Modification History:

2004-08-12
Updated effective date to reflect the date the PD was issued. (August 2004 NIB 6.c.xiv)

References:

  • None

Related NIs:

  • None

Related CCIMB-INTERPs:

  • None

Source OD: 0209