Раздел: Документация
0 ... 97 98 99 100 101 102 103 ... 117 Selection: In FPR PSE.3.3 the PP/ST author should specify whether the user alias is generated by the TSF, or supplied by the user. Assignment: In FPR PSE.3.3 the PP/ST author should identify the metric to which the TSF- generated or user-generated alias should conform. In FPRPSE.3.4 the PP/ST author should identify the list of conditions that indicate when the used reference for the real user name shall be identical and when it shall be different, for example, "when the user logs on to the same host" it will use a unique alias. I.3 Unlinkability (FPR UNL) Unlinkability ensures that a user may make multiple uses of resources or services without others being able to link these uses together. Unlinkability differs from pseudonymity that, although in pseudonymity the user is also not known, relations between different actions can be provided. User notes The requirements for unlinkability are intended to protect the user identity against the use of profiling of the operations. For example, when a telephone smart card is employed with a unique number, the telephone company can determine the behaviour of the user of this telephone card. When a telephone profile of the users is known, the card can be linked to a specific user. Hiding the relationship between different invocations of a service or access of a resource will prevent this kind of information gathering. As a result, a requirement for unlinkability could imply that the subject and user identity of an operation must be protected. Otherwise this information might be used to link operations together. Unlinkability requires that different operations cannot be related. This relationship can take several forms. For example, the user associated with the operation, or the terminal which initiated the action, or the time the action was executed. The PP/ST author can specify what kind of relationships are present that must be countered. Possible applications include the ability to make multiple use of a pseudonym without creating a usage pattern that might disclose the users identity. Examples for potential hostile subjects and users are providers, system operators, communication partners and users, who smuggle malicious parts, (e.g. Trojan Horses) into systems, they do not operate but want to get information about. All of these attackers can investigate (e.g. which users used which services) and misuse this information. Unlinkability protects users from linkages, which could be drawn between several actions of a customer. An example is a series of phone calls made by an anonymous customer to different partners, where the combination of the partners identities might disclose the identity of the customer. FPRUNL.1 Unlinkability User application notes This component ensures that users cannot link different operations in the system and thereby obtain information. Operations Assignment: In FPRUNL.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 FPRUNL.1.1 the PP/ST author should identify the list of operations which should be subjected to the unlinkability requirement, for example, "sending email". Selection: In FPRUNL.1.1 the PP/ST author should select the relationships that should be obscured. The selection allows either the user identity or an assignment of relations to be specified. Assignment: In FPRUNL.1.1 the PP/ST author should identify the list of relations which should be protected against, for example, "originate from the same terminal". 0 ... 97 98 99 100 101 102 103 ... 117
|
