![]() ![]() ![]() ![]() ![]()
Раздел: Документация
0 ... 103 104 105 106 107 108 109 ... 117 The desired strength of modification detection is based upon a specified modification metric that is a function of the algorithm used, which may range from a checksum and parity mechanisms that may fail to detect multiple bit changes, to more complicated cryptographic checksum approaches. The metric that needs to be defined can either refer to the attacks it will resist (e.g. only 1 in a 1000 random messages will be accepted), or to mechanisms that are well known in the public literature (e.g. the strength must be conformant to the strength offered by Secure Hash Algorithm). The approach taken to correct modification might be done through some form of error correcting checksum. Evaluator Notes Some possible means of satisfying this requirement involves the use of cryptographic functions or some form of checksum. Operations Assignment: For FPTITI.2.1, the PP/ST should specify the modification metric that the detection mechanism must satisfy. This modification metric shall specify the desired strength of the modification detection. For FPTITT.2.2, the PP/ST should specify the actions to be taken if a modification of TSF data has been detected. An example of an action is: "ignore the TSF data, and request the originating trusted product to send the TSF data again". For FPTITI.2.3, the PP/ST author should define the types of modification from which the TSF should be capable of recovering. J.6 Internal TOE TSF data transfer (FPT ITT) This family provides requirements that address protection of TSF data when it is transferred between separate parts of a TOE across an internal channel. User notes The determination of the degree of separation (i.e., physical or logical) that would make application of this family useful depends on the intended environment of use. In a hostile environment, there may be risks arising from transfers between parts of the TOE separated by only a system bus or an inter-process communications channel. In more benign environments, the transfers may be across more traditional network media. Evaluator Notes One practical mechanism available to a TSF to provide this protection is cryptographically-based. FPTITT.1 Basic internal TSF data transfer protection Operations Selection: In FPTITT.1.1, the PP/ST author should specify the desired type of protection to be provided from the choices: disclosure, modification. FPTITT.2 TSF data transfer separation User application notes One of the ways to achieve separation of TSF data based on SFP-relevant attributes is through the use of separate logical or physical channels. Operations Selection: In FPTITT.1.1, the PP/ST author should specify the desired type of protection to be provided from the choices: disclosure, modification. FPTITT.3 TSF data integrity monitoring Operations Selection: In FPTITT.3.1, the PP/ST author should specify the desired type of modification that the TSF shall be able to detect. The PP/ST author should select from: modification of data, substitution of data, re-ordering of data, deletion of data, or any other integrity errors. Assignment: In FPT ITT.3.1, if the PP/ST author chooses the latter selection noted in the preceding paragraph, then the author should also specify what those other integrity errors are that the TSF should be capable ofdetecting. In FPTITT.3.2, the PP/ST author should specify the action to be taken when an integrity error is identified. 0 ... 103 104 105 106 107 108 109 ... 117 |