Раздел: Документация
0 ... 96 97 98 99 100 101 102 ... 117 be sensitive depends on the effort an attacker is capable of spending. Therefore, the FPRPSE Pseudonymity family is subject to Strength of Function requirements. Possible applications include the ability to charge a caller for premium rate telephone services without disclosing his or her identity, or to be charged for the anonymous use of an electronic payment system. Examples of potential hostile users are providers, system operators, communication partners and users, who smuggle malicious parts (e.g. Trojan Horses) into systems. All of these attackers can investigate which users used which services and misuse this information. Additionally to Anonymity services, Pseudonymity Services contains methods for authorisation without identification, especially for anonymous payment ("Digital Cash"). This helps providers to obtain their payment in a secure way while maintaining customer anonymity. FPRPSE.1 Pseudonymity User application notes This component provides the user protection against disclosure of identity to other users. The user will remain accountable for its actions. Operations Assignment: In FPRPSE.1.1 the PP/ST author should specify the set of users and/or subjects against which the TSF must provide protection. For example, even if the PP/ST author specifies a single user or subject role, the TSF must not only provide protection against each individual user or subject, but must protect with respect to cooperating users and/or subjects. A set of users, for example, could be a group of users which can operate under the same role or can all use the same process(es). In FPRPSE.1.1 the PP/ST author should identify the list of subjects and/or operations and/or objects where the real user name of the subject should be protected, for example, the accessing of job offers. Note that objects includes any other attributes that might enable another user or subject to derive the actual identity of the user. In FPRPSE.1.2 the PP/ST author should identify the (one or more) number of aliases the TSF is able to provide. In FPRPSE.1.2 the PP/ST author should identify the list of subjects to whom the TSF is able to provide an alias. Selection: In FPRPSE.1.3 the PP/ST author should specify whether the user alias is generated by the TSF, or supplied by the user. Assignment: In FPRPSE.1.3 the PP/ST author should identify the metric to which the TSF-generated or user-generated alias should conform. FPRPSE.2 Reversible pseudonymity User application notes In this component, the TSF shall ensure that under specified conditions the user identity related to a provided reference can be determined. In FPRPSE.1 the TSF shall provide an alias instead of the user identity. When the specified conditions are satisfied, the user identity to which the alias belong can be determined. An example of such a condition in an electronic cash environment is: "The TSF shall provide the notary a capability to determine the user identity based on the provided alias only under the conditions that a check has been issued twice.". Operations Assignment: In FPR PSE.2.1 the PP/ST author should specify the set of users and/or subjects against which the TSF must provide protection. For example, even if the PP/ST author specifies a single user or subject role, the TSF must not only provide protection against each individual user or subject, but must protect with respect to cooperating users and/ or subjects. A set of users, for example, could be a group of users which can operate under the same role or can all use the same process(es). In FPRPSE.2.1 the PP/ST author should identify the list of subjects and/or operations and/or objects where the real user name of the subject should be protected, for example, the accessing of job offers. Note that objects includes any other attributes that might enable another user or subject to derive the actual identity of the user. In FPRPSE.2.2 the PP/ST author should identify the (one or more) number of aliases the TSF, is able to provide. In FPRPSE.2.2 the PP/ST author should identify the list of subjects to whom the TSF is able to provide an alias. Selection: In FPR PSE.2.3 the PP/ST author should specify whether the user alias is generated by the TSF or supplied by the user. Assignment: In FPRPSE.2.3 the PP/ST author should identify the metric to which the TSF-generated or user-generated alias should conform. Selection: In FPRPSE.2.4 the PP/ST author should select whether the authorised user and/ or trusted subjects can determine the real user name. Assignment: In FPRPSE.2.4 the PP/ST author should identify the list of trusted subjects that can obtain the real user name under a specified condition, for example, a notary or special authorised user. In FPRPSE.2.4 the PP/ST author should identify the list of conditions under which the trusted subjects and authorised user can determine the real user name based on the provided reference. These conditions can be conditions such as time of day, or they can be administrative such as on a court order. FPRPSE.3 Alias pseudonymity User application notes In this component, the TSF shall ensure that the provided reference meets certain construction rules, and thereby can be used in a secure way by potentially insecure subjects. If a user wants to use disk resources without disclosing its identity, pseudonymity can be used. However, every time the user accesses the system, the same alias must be used. Such conditions can be specified in this component. Operations Assignment: In FPRPSE.3.1 the PP/ST author should specify the set of users and/or subjects against which the TSF must provide protection. For example, even if the PP/ST author specifies a single user or subject role, the TSF must not only provide protection against each individual user or subject, but must protect with respect to cooperating users and/ or subjects. A set of users, for example, could be a group of users which can operate under the same role or can all use the same process(es). In FPRPSE.3.1 the PP/ST author should identify the list of subjects and/or operations and/or objects where the real user name of the subject should be protected, for example, the accessing of job offers. Note that objects includes any other attributes which might enable another user or subject to derive the actual identity of the user. In FPRPSE.3.2 the PP/ST author should identify the (one or more) number of aliases the TSF is able to provide. In FPRPSE.3.2 the PP/ST author should identify the list of subjects to whom the TSF is able to provide an alias. 0 ... 96 97 98 99 100 101 102 ... 117
|
