Раздел: Документация
0 ... 95 96 97 98 99 100 101 ... 117 I.1 Anonymity (FPR ANO) Anonymity ensures that a subject may use a resource or service without disclosing its user identity. User notes The intention of this family is to specify that a user or subject might take action without releasing its user identity to others such as users, subjects, or objects. The family provides the PP/ST author with a means to identify the set of users that cannot see the identity of someone performing certain actions. Therefore if a subject, using anonymity, performs an action, another subject will not be able to determine either the identity or even a reference to the identity of the user employing the subject. The focus of the anonymity is on the protection of the users identity, not on the protection of the subject identity; hence, the identity of the subject is not protected from disclosure. Although the identity of the subject is not released to other subjects or users, the TSF is not explicitly prohibited from obtaining the users identity. In case the TSF is not allowed to know the identity of the user, FPR ANO.2 could be invoked. In that case the TSF should not request the user information. The interpretation of "determine" should be taken in the broadest sense of the word. The PP/ST author might want to use a Strength of Function to indicate how much rigour should be applied. The component levelling distinguishes between the users and an authorised user. An authorised user is often excluded from the component, and therefore allowed to retrieve a users identity. However, there is no specific requirement that an authorised user must be able to have the capability to determine the users identity. For ultimate privacy the components would be used to say that no user or authorised user can see the identity of anyone performing any action. Although some systems will provide anonymity for all services that are provided, other systems provide anonymity for certain subjects/operations. To provide this flexibility, an operation is included where the scope of the requirement is defined. If the PP/ST author wants to address all subjects/operations, the words "all subjects and all operations" could be provided. Possible applications include the ability to make enquiries of a confidential nature to public databases, respond to electronic polls, or make anonymous payments or donations. Examples of potential hostile users or subjects are providers, system operators, communication partners and users, who smuggle malicious parts (e.g. Trojan Horses) into systems. All of these users can investigate usage patterns (e.g. which users used which services) and misuse this information. FPRANO.1 Anonymity User application notes This component ensures that the identity of a user is protected from disclosure. There may be instances, however, that a given authorised user can determine who performed certain actions. This component gives the flexibility to capture either a limited or total privacy policy. Operations Assignment: In FPRANO.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 FPRANO.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 voting application". FPRANO.2 Anonymity without soliciting information User application notes This component is used to ensure that the TSF is not allowed to know the identity of the user. Operations Assignment: In FPRANO.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 FPRANO.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 voting application". In FPR ANO.2.2 the PP/ST author should identify the list of services which are subject to the anonymity requirement, for example, "the accessing of job descriptions". For FPR ANO.2.2 the PP/ST author should identify the list of subjects from which the real user name of the subject should be protected when the specified services are provided. I.2 Pseudonymity (FPR PSE) Pseudonymity ensures that a user may use a resource or service without disclosing its identity, but can still be accountable for that use. The user can be accountable by directly being related to a reference (alias) held by the TSF, or by providing an alias that will be used for processing purposes, such as an account number. User notes In several respects, pseudonymity resembles anonymity. Both pseudonymity and anonymity protect the identity of the user, but in pseudonymity a reference to the users identity is maintained for accountability or other purposes. The component FPRPSE.1 does not specify the requirements on the reference to the users identity. For the purpose of specifying requirements on this reference two sets of requirements are presented: FPRPSE.2 and FPRPSE.3. A way to use the reference is by being able to obtain the original user identifier. For example, in a digital cash environment it would be advantageous to be able to trace the users identity when a check has been issued multiple times (i.e. fraud). In general, the users identity needs to be retrieved under specific conditions. The PP/ST author might want to incorporate FPR PSE.2 Reversible pseudonymity to describe those services. Another usage of the reference is as an alias for a user. For example, a user who does not wish to be identified, can provide an account to which the resource utilisation should be charged. In such cases, the reference to the user identity is an alias for the user, where other users or subjects can use the alias for performing their functions without ever obtaining the users identity (for example, statistical operations on use of the system). In this case, the PP/ST author might wish to incorporate FPRPSE.3 Alias pseudonymity to specify the rules to which the reference must conform. Using these constructs above, digital money can be created using FPR PSE.2 Reversible pseudonymity specifying that the user identity will be protected and, if so specified in the condition, that there be a requirement to trace the user identity if the digital money is spent twice. When the user is honest, the user identity is protected; if the user tries to cheat, the user identity can be traced. A different kind of system could be a digital credit card, where the user will provide a pseudonym that indicates an account from which the cash can be subtracted. In such cases, for example, FPRPSE.3 Alias pseudonymity could be used. This component would specify that the user identity will be protected and, furthermore, that the same user will only get assigned values for which he/she has provided money (if so specified in the conditions). It should be realised that the more stringent components potentially cannot be combined with other requirements, such as identification and authentication or audit. The interpretation of "determine the identity" should be taken in the broadest sense of the word. The information is not provided by the TSF during the operation, nor can the entity determine the subject or the owner of the subject that invoked the operation, nor will the TSF record information, available to the users or subjects, which might release the user identity in the future. The intent is that the TSF not reveal any information that would compromise the identity of the user, e.g. the identity of subjects acting on the users behalf. The information that is considered to 0 ... 95 96 97 98 99 100 101 ... 117
|
