This class describes the requirements that could be levied to satisfy the users' privacy needs, while still allowing the system flexibility as far as possible to maintain sufficient control over the operation of the system.
In the components of this class there is flexibility as to whether or not authorised users are covered by the required security functions. For example, a PP/ST author might consider it appropriate not to require protection of the privacy of users against a suitably authorised user.
Figure I.1 - Privacy class decomposition
This class, together with other classes (such as those concerned with audit, access control, trusted path, and non-repudiation) provides the flexibility to specify the desired privacy behaviour. On the other hand, the requirements in this class might impose limitations on the use of the components of other classes, such as FIA or FAU. For example, if authorised users are not allowed to see the user identity (e.g. Anonymity or Pseudonymity), it will obviously not be possible to hold individual users accountable for any security relevant actions they perform that are covered by the privacy requirements. However, it may still be possible to include audit requirements in a PP/ST, where the fact that a particular security relevant event has occurred is more important than knowing who was responsible for it.
Additional information is provided in the application notes for class FAU, where it is explained that the definition of `identity' in the context of auditing can also be an alias or other information that could identify a user.
This class describes four families: Anonymity, Pseudonymity, Unlinkability and Unobservability. Anonymity, Pseudonymity and Unlinkability have a complex interrelationship. When choosing a family, the choice should depend on the threats identified. For some types of privacy threats, pseudonymity will be more appropriate than anonymity (e.g. if there is a requirement for auditing). In addition, some types of privacy threats are best countered by a combination of components from several families.
All families assume that a user does not explicitly perform an action that discloses the user's own identity. For example, the TSF is not expected to screen the user name in electronic messages or databases.
All families in this class have components that can be scoped through operations. These operations allow the PP/ST author to state the cooperating users/subjects to which the TSF must be resistant. An example of an instantiation of anonymity could be: "The TSF shall ensure that the users and/or subjects are unable to determine the user identity bound to the teleconsulting application".
It is noted that the TSF should not only provide this protection against individual users, but also against users cooperating to obtain the information. The strength of the protection provided by this class should be described as strength of function as specified in part 1 Annex B and part 1 Annex C.
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 user's identity. However, there is no specific requirement that an authorised user must be able to have the capability to determine the user's 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.
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 FPR_ANO.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 FPR_ANO.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".
FPR_ANO.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 FPR_ANO.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 FPR_ANO.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.
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 user's identity is maintained for accountability or other purposes.
The component FPR_PSE.1 does not specify the requirements on the reference to the user's identity. For the purpose of specifying requirements on this reference two sets of requirements are presented: FPR_PSE.2 and FPR_PSE.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 user's identity when a check has been issued multiple times (i.e. fraud). In general, the user's 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 user's identity (for example, statistical operations on use of the system). In this case, the PP/ST author might wish to incorporate FPR_PSE.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, FPR_PSE.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 user's behalf. The information that is considered to be sensitive depends on the effort an attacker is capable of spending. Therefore, the FPR_PSE 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.
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 FPR_PSE.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 FPR_PSE.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 FPR_PSE.1.2 the PP/ST author should identify the (one or more) number of aliases the TSF is able to provide.
In FPR_PSE.1.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.1.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.1.3 the PP/ST author should identify the metric to which the TSF-generated or user-generated alias should conform.
FPR_PSE.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 FPR_PSE.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 FPR_PSE.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 FPR_PSE.2.2 the PP/ST author should identify the (one or more) number of aliases the TSF, is able to provide.
In FPR_PSE.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 FPR_PSE.2.3 the PP/ST author should identify the metric to which the TSF-generated or user-generated alias should conform.
Selection:
In FPR_PSE.2.4 the PP/ST author should select whether the authorised user and/or trusted subjects can determine the real user name.
Assignment:
In FPR_PSE.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 FPR_PSE.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.
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 FPR_PSE.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 FPR_PSE.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 FPR_PSE.3.2 the PP/ST author should identify the (one or more) number of aliases the TSF is able to provide.
In FPR_PSE.3.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.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 FPR_PSE.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./p>
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 user's 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 partner's identities might disclose the identity of the customer.
User application notes
This component ensures that users cannot link different operations in the system and thereby obtain information.
Operations
Assignment:
In FPR_UNL.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 FPR_UNL.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 FPR_UNL.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 FPR_UNL.1.1 the PP/ST author should identify the list of relations which should be protected against, for example, "originate from the same terminal".
Unobservability ensures that a user may use a resource or service without others, especially third parties, being able to observe that the resource or service is being used.
User notes
Unobservability approaches the user identity from a different direction than the previous families Anonymity, Pseudonymity and Unlinkability. In this case, the intent is to hide the use of a resource or service, rather than to hide the user's identity.
A number of techniques can be applied to implement unobservability. Examples of techniques to provide unobservability are:
a) Allocation of information impacting unobservability: Unobservability relevant information (e.g. information that describes that an operation occurred) can be allocated in several locations within the TOE. The information might be allocated to a single randomly chosen part of the TOE such that an attacker does not know which part of the TOE should be attacked. An alternative system might distribute the information such that no single part of the TOE has sufficient information that, if circumvented, the privacy of the user would be compromised. This technique is explicitly addressed in FPR_UNO.2 Allocation of information impacting unobservability .
b) Broadcast: When information is broadcast (e.g. ethernet, radio), users cannot determine who actually received and used that information. This technique is especially useful when information should reach receivers which have to fear a stigma for being interested in that information (e.g. sensitive medical information).
c) Cryptographic protection and message padding: People observing a message stream might obtain information from the fact that a message is transferred and from attributes on that message. By traffic padding, message padding and encrypting the message stream, the transmission of a message and its attributes can be protected.
Sometimes, users should not see the use of a resource, but an authorised user must be allowed to see the use of the resource in order to perform his duties. In such cases, the FPR_UNO.4 Authorised user observability could be used, which provides the capability for one or more authorised users to see the usage.
This family makes use of the concept "parts of the TOE". This is considered any part of the TOE that is either physically or logically separated from other parts of the TOE. In the case of logical separation FPT_SEP may be relevant.
Unobservability of communications may be an important factor in many areas, such as the enforcement of constitutional rights, organisational policies, or in defence related applications.
User application notes
This component requires that the use of a function or resource cannot be observed by unauthorised users. In addition to this component, a PP/ST author might want to incorporate Covert Channel Analysis.
Operations
Assignment:
In FPR_UNO.1.1 the PP/ST author should specify the list 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).
For FPR_UNO.1.1 the PP/ST author should identify the list of operations that are subjected to the unobservability requirement. Other users/subjects will then not be able to observe the operations on a covered object in the specified list (e.g. reading and writing to the object).
For FPR_UNO.1.1 the PP/ST author should identify the list of objects which are covered by the unobservability requirement. An example could be a specific mail server or ftp site.
In FPR_UNO.1.1 the PP/ST author should specify the set of protected users and/or subjects whose unobservability information will be protected. An example could be: "users accessing the system through the internet".
FPR_UNO.2 Allocation of information impacting unobservability
User application notes
This component requires that the use of a function or resource cannot be observed by specified users or subjects. Furthermore this component specifies that information related to the privacy of the user is distributed within the TOE such that attackers might not know which part of the TOE to target, or they need to attack multiple parts of the TOE.
An example of the use of this component is the use of a randomly allocated node to provide a function. In such a case the component might require that the privacy related information shall only be available to one identified part of the TOE, and will not be communicated outside this part of the TOE.
A more complex example can be found in some `voting algorithms'. Several parts of the TOE will be involved in the service, but no individual part of the TOE will be able to violate the policy. So a person may cast a vote (or not) without the TOE being able to determine whether a vote has been cast and what the vote happened to be (unless the vote was unanimous).
In addition to this component, a PP/ST author might want to incorporate Covert Channel Analysis.
Operations
Assignment:
In FPR_UNO.2.1 the PP/ST author should specify the list 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).
For FPR_UNO.2.1 the PP/ST author should identify the list of operations that are subjected to the unobservability requirement. Other users/subjects will then not be able to observe the operations on a covered object in the specified list (e.g. reading and writing to the object).
For FPR_UNO.2.1 the PP/ST author should identify the list of objects which are covered by the unobservability requirement. An example could be a specific mail server or ftp site.
In FPR_UNO.2.1 the PP/ST author should specify the set of protected users and/or subjects whose unobservability information will be protected. An example could be: "users accessing the system through the internet".
For FPR_UNO.2.2 the PP/ST author should identify which privacy related information should be distributed in a controlled manner. Examples of this information could be: IP address of subject, IP address of object, time, used encryption keys.
For FPR_UNO.2.2 the PP/ST author should specify the conditions to which the dissemination of the information should adhere. These conditions should be maintained throughout the lifetime of the privacy related information of each instance. Examples of these conditions could be: "the information shall only be present at a single separated part of the TOE and shall not be communicated outside this part of the TOE.", "the information shall only reside in a single separated part of the TOE, but shall be moved to another part of the TOE periodically", "the information shall be distributed between the different parts of the TOE such that compromise of any 5 separated parts of the TOE will not compromise the security policy".
FPR_UNO.3 Unobservability without soliciting information
User application notes
This component is used to require that the TSF does not try to obtain information that might compromise unobservability when provided specific services. Therefore the TSF will not solicit (i.e. try to obtain from other entities) any information that might be used to compromise unobservability.
Operations
Assignment:
In FPR_UNO.3.1 the PP/ST author should identify the list of services which are subject to the unobservability requirement, for example, "the accessing of job descriptions".
For FPR_UNO.3.1 the PP/ST author should identify the list of subjects from which privacy related information should be protected when the specified services are provided.
In FPR_UNO.3.1 the PP/ST author should specify the privacy related information that will be protected from the specified subjects. Examples include the identity of the subject that used a service and the quantity of a service that has been used such as memory resource utilisation.
FPR_UNO.4 Authorised user observability
User application notes
This component is used to require that there will be one or more authorised users with the rights to view the resource utilisation. Without this component, this review is allowed, but not mandated.
Operations
Assignment:
In FPR_UNO.4.1 the PP/ST author should specify the set of authorised users for which the TSF must provide the capability to observe the resource utilisation. A set of authorised users, for example, could be a group of authorised users which can operate under the same role or can all use the same process(es).
In FPR_UNO.4.1 the PP/ST author should specify the set of resources and/or services that the authorised user must be able to observe.