Common Criteria Protection Profile. Strong Privacy Protection Mechanisms for the Survey System

Transcription

1 Common Criteria Protection Profile Strong Privacy Protection Mechanisms for the Survey System working draft, version: 1.0 Anna Lauks-Dutka Wroc law,

2 Contents 1 PP Introduction The Target of Evaluation Overview TOE type TOE usage and major security features Required non-toe hardware/software/firmware Conformance Claims CC Conformance Claim PP Claim Package Claim Conformance Statement TOE description TOE description TOE description - physical scope TOE description - logical scope Security Problem Definition Assets Roles/Subjects Assumptions Threads Organizational Security Policies Security Objectives Security Objectives for the TOE Security Objectives for the Operational Environment Security Objective Rationale Extended Component Definition Definition of the Family FCS RNG Security Requirements Security Functional Requirements Class FCS: Cryptographic support Class FDP: User Data Protection Class FPR: Privacy Class FPT: Protection of the TSF Security Requirements Rationale

3 7.2.1 Security Functional Requirements Rationale Security Assurance Requirements

4 Chapter 1 PP Introduction 1.1 The Target of Evaluation Overview TOE type The Target of Evaluation (TOE) is a set of cryptographic algorithms dedicated for the survey system that preserves strong privacy of users filling the questionnaires stored in the system. Cryptographic security functions of TOE protect the integrity of questionnaires, ensure the authenticity of stored data and unlinkability of users that fill particular questionnaires TOE usage and major security features The TOE needs the following input data: questionnaires, for each questionnaire a set of public keys of users that are rightful to fill it. From a technical point of view the system that implements the algorithms of TOE should be integrated with some other existing system that operates the same set of users and is among others responsible for: user s public key registration, public key management, deciding which questionnaires a particular user is rightful to upload. The basic security features provided by TOE are: 1. Only authorized users can upload a valid questionnaires. 2. Integrity and authenticity of the questionnaire is preserved due to the signature of the questionnaire created by the user who fill it. 3. Verification of the signature is possible using pseudonyms. 4. Pseudonyms are generated in cooperation with two special Certification Authorities - CA1 and CA2. 3

5 5. The questionnaires are singed in such a way that the anonymity of the user is preserved i.e. that having a signed questionnaire, there is no possibility of connecting the personal data of a particular user with the pseudonym used for signing until CA1 cooperates with CA2. 6. The user does not have to remember or store any of his pseudonyms. 7. In order to sign in anonymous way user needs only to have one private, public key pair and get some public data related to a particular questionnaire computed by CA1 and CA2. 8. One authorized user can upload a questionnaire many times. Each time using the same pseudonym. 9. One authorized user can upload different questionnaires, using different pseudonyms in such a way that the linkability of his pseudonyms is not possible until CA1 cooperates with CA In case of dispute, when both Certification Authorities cooperates they may perform the deanonymization procedure Required non-toe hardware/software/firmware A part of the TOE that supports users in creating an anonymous signature of a given message is intended to be implemented as a stand alone application and used as an IT product on a user personal computer. The secure private, public key pair generation and preserving the physical security of the secret key of the user is out of the scope of the TOE. The IT-environment should support protection of the application and the private key used by it during the signature creation against unauthorized usage and modification by suitable protection mechanisms. A part of the TOE that supports pseudonyms generation needs to be implemented in the IT-environment that supports physical protection of the private values used by it against unauthorized usage and modification. Moreover it is assumed that these components as well as a web-server that implements algorithms for the signed questionnaires verification should be located within controlled access facilities which will prevent unauthorized physical access. 4

6 Chapter 2 Conformance Claims 2.1 CC Conformance Claim This protection profile claims conformance to: Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and General Model; CCMB , Version 3.1, Revision 3, July 2009 [1] Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional Components; CCMB , Version 3.1, Revision 3, July 2009 [2] Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance Requirements; CCMB , Version 3.1, Revision 3, July 2009 [3] as follows Part 2 conformant Part 3 conformant 2.2 PP Claim This PP does not claim conformance with any other PP. 2.3 Package Claim The current PP does not claim conformance with any security requirements package. 2.4 Conformance Statement This PP requires strict conformance of any ST or PP claiming to this PP. 5

7 Chapter 3 TOE description 3.1 TOE description This section discusses the physical and logical scope of the TOE in detail. 3.2 TOE description - physical scope The Target Of Evaluation is composed of multiple algorithms and procedures dedicated for the survey system that support strong privacy protection of users that fill the questionnaires. It allows authorized users to upload questionnaires signed in anonymous way. As an authorized user we mean a registered user of the system, that is rightful to upload a particular questionnaire. TOE is distributed product which consists internally of the following separates parts: application for users, two independent Certification Authorities - CA1 and CA2, survey server. The application for users supports users in creating an anonymous signature of a given message. The private and public key pair for questionnaire signing is generated for each user (on PC, smart card etc.) according to delivered algorithm. The secure key pair generation and preserving the physical security of the secret key of the user is outside of the scope of the TOE. Moreover, it is assumed that outside of the scope of the TOE is deciding who and which questionnaire is rightful to fill. Thus the following data are the input of the TOE: questionnaires, for each questionnaire a set of public keys of users that are rightful to fill it. To get these data TOE cooperates or is partially integrated with another existing system - S1, which operates the same set of users and is among others responsible for: 6

8 user s public key registration, public key management, deciding which questionnaires a particular user is rightful to upload. It is important to ensure totally (physical and administrative) independence of the component that implements algorithms of the first Certification Authority - CA1 from the component that implements algorithms for the second Certification Authority - CA2. However ensuring independence of these parties (including independence staff administration) is out of the scope of the TOE. The first Certification Authority is responsible for the first step in the anonymization process. It performs some computation on the subset of public keys of legitimate users and transmits output to the second Certification Authority. The second independent Certification Authority also performs some computation in order to compute final list of pseudonyms of legitimate users rightful to upload a particular questionnaire. Preserving the physical security of the private values stored by the real components that implement CA1 and CA2 against unauthorized usage and modification is out of the scope of the TOE. The final list of pseudonyms of legitimate users rightful to upload a particular questionnaire list is then transmitted to the survey server. From the survey server legitimate users can download a particular questionnaire together with additional parameters necessary for signing a questionnaire in anonymous way. The signed questionnaire can be afterwards by the user uploaded to the server. The survey server checks the validity of the signature and informs the user about the result of the verification. CA1 and CA2 as well as a surveys server that implements algorithms for the signed questionnaires verification should be located within controlled access facilities which will prevent unauthorized physical access. Moreover, it is assumed that finally, if the verification of the signature is correct, the signed questionnaires are stored at the surveys database. Preserving the physical security of this database is also out of the scope of the TOE. The physical scope and the physical boundary of the overall solution is presented on the figure TOE description - logical scope For the user TOE allows to: generate a private, public key pair, sign a questionnaire downloaded from the survey server in anonymous way, upload a valid questionnaire to the survey server if the user is rightful to do that. For the CA1 the TOE allows to: generate lists of anonymized public keys (pseudonyms) for a particular questionnaire (having the public keys of the legitimate users), check the integrity of the final list of pseudonyms, 7

9 S1 CA1 CA2 Survey-server User's API Surveydatabase TOE User Figure 3.1: Illustration of the TOE boundaries. deanonymize questionnaires of users stored by the survey server in cooperation with CA2. For the CA2 the TOE allows to: perform the second phase of the anonymization of pseudonyms for a particular questionnaire, check the integrity of the final list of pseudonyms, prove the survey server that it performed computation on the lists of pseudonyms for a particular questionnaires properly, deanonymize questionnaires of users in cooperation with CA1. For the survey server TOE allows to: check if lists of anonymized public keys (pseudonyms) for a particular questionnaires were anonymized by CA2 properly, check if the questionnaires were uploaded by the legitimate users. The main security feature provided by TOE is to ensure strong and verifiable integrity and authenticity of the questionnaires stored by the survey server achieving the anonymity of users that filled them at the same time. This goal is achieved by: signing the questionnaires by the user who filled them, verifying the signatures of the questionnaires, two-step anonymization of the public key used for signature verification, 8

10 co-verification of the anonymization performed by CA1 and CA2. Two components of the TOE - CA1 and survey server can be integrated with external system S1 who controls privileges of users. To achieve full anonymity of signed questionnaires the TOE uses second Certification Authority CA2 (independent of CA1). The TOE ensures also that this second Certification Authority behaves properly with high probability. The anonymity of signed questionnaires denotes that: 1. Having a signed questionnaire, there is no possibility of connecting the personal data of a particular user with the pseudonym used for signing until CA1 cooperates with CA2. 2. One authorized user can upload different questionnaires, using different pseudonyms in such a way that the linkability of his pseudonyms is not possible until CA1 cooperates with CA2. However in case of dispute, when both Certification Authorities cooperates they may perform controlled the deanonymization procedure and find out the public key of the user that corresponds to the pseudonym used for signing. From the user s application point of view important security features are: the user does not have to remember or store any of his pseudonyms, in order to sign in anonymous way user needs only to have one private, public key pair and get some public data related to a particular questionnaire computed by CA1 and CA2. 9

11 Chapter 4 Security Problem Definition The following chapter describes the threats, organizational policies and assumptions for the TOE addressed within this protection profile. 4.1 Assets The TOE shall protect the following IT assets: 1. Users private key User s private key used for signing. Protection goal: confidentiality. 2. Users main identity User s main public key that corresponds with the private signing key. Protection goal: unlinkability of main identity and each pseudonym of the same user. 3. Pseudonyms Pseudonym i.e. anonymized public key of the user. Protection goal: integrity and unlinkability of all pseudonyms of the same user. 4. Certification Authorities Private Values Certification Authorities Private Values i.e. the values generated by the Certification Authorities CA1 and CA2 for the anonymization/deanonymization process. Protection goal: confidentiality and integrity. 5. List of pseudonyms List of anonymized public keys of legitimate users stored together with questionnaires in order to determine if the surveys were uploaded by the rightful users. Protection goal: authenticity and integrity. 10

12 4.2 Roles/Subjects This PP considers the following subjects: 1. First Certification Authority - CA1 CA1 is one of the two certification authorities, which participates in the anonymization process. It gets the list of public keys connected with a particular questionnaire from the trusted source, perform some computation and sends the output to CA2. 2. Second Certification Authority - CA2 CA2 is the second certification authority, which participates in the anonymization process. It gets the list of pseudonyms from CA1, perform some computation and sends the output to the survey server. 3. Survey Server A web-server that allows users to fill and upload the questionnaires. The server is also responsible for checking if the list of pseudonyms it gets for a particular questionnaire from CA2 was created properly. 4. Legitimate User The holder of a private key related to a public key of registered user that is rightful to upload a questionnaire. 4.3 Assumptions This section describes the security aspects of the intended environment for the evaluated TOE. The operational environment must be managed in accordance with assurance requirement documentation for delivery, operation, and user guidance. The following specific conditions are required to ensure the security of the TOE and are as assumed to exist in an environment where this TOE is employed. A.PHYSICAL Components CA1 and CA2 and survey server will be located within controlled access facilities which will prevent unauthorized physical access. A.USER Legitimate users are trustworthy. They generate private-public key pair according to the delivered guidance and store the private signing key in a secure manner. A.PLATFORM The TOE is installed on a personal computer supervised by the legitimate user. It is assumed that those resources the TOE is relying on can not be manipulated without user notification. The legitimate user is supposed to protect the underlying platform against logical attacks by Malware. 11

13 A.INPUT For a particular questionnaire the TOE shall be given (from the trusted source) a proper input, i.e. the list of the public keys of users who are rightful to upload a signed questionnaire. 4.4 Threads This section describes the threads to be averted by the TOE independently or in collaboration with its IT environment. These threads result from the TOE method of the use in operational environment and the assets stored in or protected by the TOE. The following threads are applicable: T.UNUSER The attacker may attempt to upload a questionnaire as an unauthorized user (whose pseudonym is not in the list of pseudonyms) for this questionnaire. Security goal: to detect and block of uploading a questionnaire by an unauthorized user. T.FAKEDID The attacker may try to create a faked identity (for a user who is not rightful to fill, sign and upload a particular questionnaire) and influence on the white list (list of pseudonyms) for a particular questionnaire in such a way that the signature uploaded using this faked user will be valid. In this kind of threats the attacker may even control CA2 (but not CA1 - this one is assume to be trusted in this context) Security goal: integrity of white lists on which operation performs CA2. T.FORGE On the basis of any set of pseudonyms and signed questionnaires, the attacker may attempt to upload a valid questionnaire on behalf of a legitimate user. Security goal: confidentiality of the user s secret key. T.LINK The Attacker on the basis of any set of pseudonyms and signed questionnaires may attempt to link two questionnaires uploaded and signed by the same user i.e. to be able to guess that two pseudonyms refer to the same public key. This kind of attack may be performed even by someone who controls CA1 or CA2 (but not both of them). Security goal: unlinkability of the pseudonyms used by the same user. 12

14 T.DEANONYM The attacker may attempt to deanonymize a signed questionnaire i.e. to link a pseudonym with the main identity of a user (a public key of the particular user). This kind of attack may be performed even by someone who controls CA1 or CA2. It is assumed that TOE allows to perform controlled deanonymization process of a particular signed questionnaire only if CA1 and CA2 collaborate. Security goal: unlinkability of the public key and pseudonyms used by the same user. T.BREAKCA1 The Attacker on the basis of any set of outputs of the anonymization procedure performed by the CA1 and CA2 may attempt to get the private values that CA1 is using during the anonymization procedure in order to compromise it. This kind of attack may be performed even by someone who controls CA2. Security goal: confidentiality of the CA1 private values. T.BREAKCA2 The Attacker on the basis of any set of outputs of the anonymization procedure performed by the CA1 and CA2 may attempt to get the private values that CA2 is using during the anonymization procedure in order to compromise it. This kind of attack may be performed even by someone who controls CA1. Security goal: confidentiality of the CA2 private values. T.CAEXCLUDE The Attacker may attempt to exclude one or both Certification Authorities from the anonymization process. Security goal: authenticity and integrity of the list of pseudonyms 4.5 Organizational Security Policies There are no Organizational Security Policies. 13

15 Chapter 5 Security Objectives This chapter describes the security objectives for the TOE and the security objectives for the TOE environment. 5.1 Security Objectives for the TOE This section describes the security objectives for the TOE. They address the aspects of the threads identified in the previous chapter. OT.SIGN The TOE shall provide methods for a secure signing questionnaires by the legitimate users. The signature should ensure that the signature is created only by the owner of an appropriate private key but the signature itself should not reveal the main identity of the user. It should enable to cerate signature using not only private key but also some additional input values that enable to verify the signature using not the public key of the user but the anonymized public key (pseudonym). OT.SIGCHECK The TOE shall verify the signatures of the questionnaires in order to check if questionnaires were uploaded only by the legitimate users. It should block adding a signed questionnaire if verification of the signature fails. The verification of the signature should not reveal the main identity of the user. The TOE should ensure the verification of the signature to be performed using the anonymized public key. OT.UNLINKINOUT The TOE shall ensure unlinkability of inputs and outputs of CA1 as well as CA2. 14

16 OT.UNLINKPSEUDO The TOE shall ensure that if CA1 gets the same public key in two different inputs or CA2 gets the same anonymized public key in two different inputs the outputs computed on these inputs are unlikable. OT.CAPRIV The TOE shall ensure the confidentiality of the private values used by the CA1 and CA2. OT.CA2VERIFY The TOE shall ensure verifiability of the anonymization procedures performed by CA2.The verifiability procedure should with high probability ensure that the output generated by the CA2 corresponds to a proper input. OT.LISTINTEGRITY The TOE shall ensure integrity and authenticity of the lists of pseudonyms for a particular questionnaire at each step of processing. 5.2 Security Objectives for the Operational Environment This section describes the security objectives for the TOE s operational environment. OE.PHYSICAL Components CA1 and CA2 will be located within controlled access facilities which will prevent unauthorized physical access. OE.USER Legitimate users are trustworthy. They generate private-public key pair according to the delivered guidance and store the private signing key in a secure manner. OE.PLATFORM Part of the TOE responsible form signature creation is installed on a personal computer supervised by the legitimate user. It is assumed that those resources the TOE is relying on can not be manipulated without user notification. The legitimate user is supposed to protect the underlying platform against logical attacks by Malware. 15

17 OT.SIGN OT.SIGCHECK OT.UNLINKINOUT OT.UNLINKPSEUDO OT.CAPRIV OT.CA2VERIFY OT.LISTINTEGRITY OE.PHYSICAL OE.USER OE.PLATFORM OE.INPUT T.UNUSER X T.FAKEDID X T.FORGE X X X T.DEANONYM X X X X T.LINK X X T.BREAKCA1 X T.BREAKCA2 X T.CAEXCLUDE X A.PHYSICAL X A.USER X A.PLATFORM X A.INPUT X Table 5.1: Security Objective Rationale OE.INPUT For a particular questionnaire the TOE shall be given (from the trusted source) a proper input, i.e. the list of the public keys of users who are rightful to upload a signed questionnaire. 5.3 Security Objective Rationale The table 5.1 provides an overview for security objectives coverage. The threat T.UNUSER is directly addressed by the objective OT.SIGCHECK requiring the TOE to verify the signatures of the questionnaires in order to check if questionnaires were uploaded by the user, whose pseudonym is on a proper white list and block adding a signed questionnaire if verification of the signature fails. The threat T.FAKEDID is directly addressed by the objective OT.CA2VERIFY requiring the TOE to ensure verifiability of the anonymization procedures performed by CA2. The verifiability procedure should with high probability ensure that the output generated by the CA2 corresponds to a proper input. Thus the integrity of a particular list of pseudonyms while processing by CA2 is preserved. The threat T.FORGE is addressed by the objective OT.SIGN and and the objectives for the environment OE.USER and OE.PLATFORM. The objective OT.SIGN requires the TOE to implement methods for a secure signing of questionnaires. The signature scheme used should ensure that the signature 16

18 is created only by the owner of an appropriate private key. On the other hand OE.USER and OE.PLATFORM require the legitimate user to keep the private signing key in a secure manner and to protect the underlying platform against logical attacks by Malware. The threat T.DEANONYM is addressed by the objectives OT.SIGN, OT.SIGCHECK, OT.UNLINKINOUT and OT.CAPRIV. The objective OT.SIGN requires the TOE to implement methods for a secure signing of questionnaires in such a way that the signature itself should not reveal the main identity of the user. The objective OT.SIGCHECK requires the TOE to use signature scheme for which the verification procedure does not reveal the main identity of the user (by performing the verification of the signature using the anonymized public key). The objective OT.UNLINKINOUT requires the TOE to ensure unlinkability of all inputs and outputs of CA1 and CA2. Thus, if CA1 is honest, even CA2 is not able to link any public key with any final pseudonym. If CA2 is honest, even CA1 is not able to link any public key with any final pseudonym. Finally the objective OT.CAPRIV requires the TOE to ensure confidentiality of the private values used by the CA1 and CA2 that are necessary for performing the controlled deanonymization procedure. The threat T.LINK is addressed by the objectives OT.UNLINKPSEUDO and OT.CAPRIV The objective OT.UNLINKPSEUDO requires the TOE to ensure that if CA1 gets the same public key in two different inputs or CA2 gets the same anonymized public key in two different inputs the outputs computed on these inputs are unlikable. Thus, if CA1 is honest, even CA2 is not able to link any public key with any final pseudonym. If CA2 is honest, even CA1 is not able to link the any public key with any final pseudonym. Finally the objective OT.CAPRIV requires the TOE to ensure confidentiality of the private values used by the CA1 and CA2 that are necessary for performing the controlled deanonymization procedure. The threat T.BREAKCA1 is addressed directly by the objectives OT.CAPRIV requiring the TOE to ensure confidentiality of the private values used by the CA1. The threat T.BREAKCA2 is addressed directly by the objectives OT.CAPRIV requiring the TOE to ensure confidentiality of the private values used by the CA2. The threat T.CAEXCLUDE is addressed directly by the objective OT.LISTINTEGRITY requiring the TOE to ensure integrity and authenticity of the list of pseudonyms at each step of processing. The assumption A.PHYSICAL is addressed directly by the objective for the environment OE.PHYSICAL requiring of locating the components CA1 and CA2 within controlled access facilities which will prevent unauthorized physical access. The assumption A.USER is addressed directly by the objective for the environment OE.USER claiming that the legitimate users are trustworthy and that they generate private-public key pair according to the delivered guidance and store the private signing key in a secure manner. The assumption A.PLATFORM is addressed directly by the objective for the environment OE.PLATFORM claiming that legitimate user is supposed to protect the underlying platform against logical attacks by Malware. 17

19 Chapter 6 Extended Component Definition 6.1 Definition of the Family FCS RNG This section describes the functional requirements for the generation of random number used as a secret for cryptographic operations. The IT security functional requirements for a TOE are defined in an additional family (FCS RNG) of the class FCS (Cryptographic support). The family Random number generation (FCS RNG) is specified as follows: FCS RNG Random number generation Family behaviour The family defines quality requirements for the generation of random numbers, which are intended to be used as secrets for cryptographic operations. Component leveling FCS RNG: Random number generation 1 FCS RNG.1 Generation of random numbers requires that the random number generator implements defined security capabilities and the random numbers meet a defined quality metrics. Management: FCS RNG.1 There are no management activities foreseen. Audit: FCS RNG.1 There are no auditable events foreseen. 18

20 FCS RNG.1 Random number generation Hierarchical to: Dependencies: No other components. No dependencies. FCS RNG.1.1 FCS RNG.1.2 The TSF shall provide a [selection: non-physical true, deterministic, physical hybrid, deterministic hybrid] random number generator, which implements: [assignment: list of security capabilities]. The TSF shall provide random numbers that meet [assignment: defined quality metrics]. 19

21 Chapter 7 Security Requirements 7.1 Security Functional Requirements Class FCS: Cryptographic support The TOE shall meet the requirements from class FCS Cryptographic support as specified below FCS CKM FCS CKM.1 Cryptographic Key Generation The TOE shall meet requirement Cryptographic key generation (FCS CKM.1) as specified below (CC Part 2). The iterations are caused by different cryptographic keys to be generated by the TOE. Hierarchical to: Dependencies: No other components. [FCS CKM.2 Cryptographic key distribution, or FCS COP.1 Cryptographic operation] FCS CKM.4 Cryptographic key destruction FCS CKM.1/CA1 Cryptographic key generation - CA1 FCS CKM.1.1/CA1 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [assignment: cryptographic key generation algorithm] and specified cryptographic key sizes of at least 256 bit that meet the following: [assignment: list of standards]. Application Note 1 This SFR requires the TOE to generate the key used as an entropy input for the random number generator utilized by CA1 FCS CKM.1/CA2 Cryptographic key generation - CA2 20

22 FCS CKM.1.1/CA2 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [assignment: cryptographic key generation algorithm] and specified cryptographic key sizes of at least 256 bit that meet the following: [assignment: list of standards]. Application Note 2 This SFR requires the TOE to generate the key used as an entropy input for the random number generator utilized by CA2 FCS CKM.1/SIG Cryptographic key generation - Signature FCS CKM.1.1/SIG The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm DSA, ECDSA and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [4] Application Note 3 This SFR requires the TOE to generate the private, public key pair for DSA or ECDSA used for questionnaires signing FCS COP FCS COP.1 Cryptographic Operation The TOE shall meet requirement Cryptographic operation (FCS COP.1) as specified below (CC Part 2). The iterations are caused by different cryptographic algorithms to be implemented by the TOE. Hierarchical to: Dependencies: No other components. [FDP ITC.1 Import of user data without security attributes, or FDP ITC.2 Import of user data wit security attributes, or FCS CKM.1 Cryptographic key generation] FCS CKM.4 Cryptographic key destruction FCS COP.1/SIG Cryptographic operation - Signature creation FCS COP.1.1/SIG The TSF shall perform digital signature creation in accordance with a specified cryptographic algorithm DSA, ECDSA [assignment: cryptographic algorithm] and cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards]. Application Note 4 This SFR requires the TOE to create the signature of questionnaires according to DSA or ECDSA algorithm. 21

23 FCS COP.1/VER Cryptographic operation-signature verification FCS COP.1.1/VER The TSF shall perform digital signature verification in accordance with a specified cryptographic algorithm DSA, ECDSA [assignment: cryptographic algorithm] and cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards]. Application Note 5 This SFR requires the TOE to verify the signature of questionnaires according to DSA or ECDSA algorithm. FCS COP.1.1/PKA FCS COP.1/PKA Cryptographic operation-public key anonymization The TSF shall perform the anonymization of the public key in accordance with a specified cryptographic algorithm [assignment: cryptographic algorithm] and cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards]. Application Note 6 The ST writer shall perform the missing cryptographic algorithm in the element FCS COP.1.1/PKA FCS RNG FCS RNG.1 Random number generation The TOE shall meet requirement Random number generation (FCS RNG.1) as specified below (CC Part 2 extended, cf. sec. 6.1). The iterations are caused by different cryptographic random values to be generated by the TOE. Hierarchical to: Dependencies: No other components. No dependencies. FCS RNG.1/CA1 Random number generation - random number generator - CA1 FCS RNG.1.1/CA1 The TSF shall provide a deterministic random number generator, which implements: capabilities of the user to specify a personalization string for initialization Application Note 7 This SFR requires the TOE to generate random numbers used by CA1 for the anonymization of the public key operation. 22

24 FCS RNG.1/CA2 Random number generation - random number generator - CA2 FCS RNG.1.1/CA2 The TSF shall provide a deterministic random number generator, which implements: NIST SP A [5] Application Note 8 This SFR requires the TOE to generate random numbers used by CA2 for the anonymization of the public key operation Class FDP: User Data Protection The TOE shall meet the requirements from class FDP User data protection as specified below FDP DAU FDP DAU.1 Basic Data Authentication Hierarchical to: Dependencies: No other components. No dependencies. FDP DAU.1.1 The TSF shall provide a capability to generate evidence that can be used as guarantee of the validity of stored questionnaires Class FPR: Privacy The TOE shall meet the requirements from class FPR Privacy as specified below FPR PSE FPR PSE.1 Pseudonymity The TOE shall meet requirement Pseudonymity (FPR PSE.1) as specified below (CC Part 2). Hierarchical to: No other components. Dependencies: No dependencies. FPR PSE.1.1 The TSF shall ensure that any user and CA1 and CA2 and survey server and any external observer of the TSF are unable to determine the real user name bound to the signature creation operation and the signature verification operation. 23

25 FPR UNL FPR UNL.1 Unlinkability The TOE shall meet requirement Unlinkability (FPR UNL.1) as specified below (CC Part 2). The iterations are caused by unlinkability of different cryptographic primitives generated by the TOE. Hierarchical to: No other components. Dependencies: No dependencies. FPR UNL.1/CA1 Unlinkability - input and output of CA1 FPR UNL.1.1/CA1 The TSF shall ensure that any subjects but CA1 are unable to determine whether particular input of CA1 is related to a particular output of CA1. FPR UNL.1/CA2 Unlinkability - input and output of CA2 FPR UNL.1.1/CA2 The TSF shall ensure that any subjects but CA2 are unable to determine wheter particular input of CA2 is related to a particular output of CA2. FPR UNL.1/PSE Unlinkability - pseudonyms of the same user FPR UNL.1.1/PSE The TSF shall ensure that CA1 and CA2 and survey server are unable to determine wheter two different pseudonyms generated are related as follows: they refer to the same user Class FPT: Protection of the TSF The TOE shall meet the requirements from class FPT Protection of the TSF as specified below FPT TST FPT TST.1 TSF selftest The TOE shall meet requirement TSF selftest (FPT TST.1) as specified below (CC Part 2). Hierarchical to: No other components. Dependencies: No dependencies. 24

26 OT.SIGN OT.SIGCHECK OT.UNLINKINOUT OT.UNLINKPSEUDO OT.CAPRIV OT.CA2VERIFY OT.LISTINTEGRITY FCS CKM.1/CA1 X X FCS CKM.1/CA2 X X FCS CKM.1/SIG FCS COP.1/SIG X FCS COP.1/VER X FCS COP.1/PKA X X X FCS RNG.1/CA1 X X X FCS RNG.1/CA2 X X X FDP DAU.1 X FPR PSE.1 X X FPR UNL.1/CA1 X FPR UNL.1/CA2 X FPR UNL.1/PSE X FPT TST.1 X X Table 7.1: Coverage of Security Objective for the TOE by SFR FPT TST.1.1 FPT TST.1.2 The TSF shall run a suite of self tests periodically during normal operation to demonstrate the correct operation of the CA2. The TSF shall shall provide authorized users with the capability to verify the integrity of the lists of generated psedunyms. 7.2 Security Requirements Rationale Security Functional Requirements Rationale The table 7.1 provides an overview for security requirements coverage The security objective OT.SIGN is provided by the following SFRs: - FCS COP.1/SIG requires DSA or ECDSA signature creation algorithm to be used in order to sign questionnaires, - FCS COP.1/PKA requires the public key anonymization algorithm to be used, - FPR PSE.1 ensures that the signature is created in such a way that any observer is unable to determine the public key of the signer, 25

27 - FDP DAU.1 requires capability to generate evidence that can be used as guarantee of the validity of stored questionnaires. The security objective OT.SIGCHECK is provided by the following SFRs: - FCS COP.1/VER requires DSA or ECDSA signature verification algorithm to be used in order to verify signed questionnaires and - FPR PSE.1 ensures that any observer is unable to determine the real user name bound to the signature verification operation, The security objective OT.UNLINKINOUT is directly enforced by FPR UNL.1/CA1 and FPR UNL.1/CA2. They enforce that any subjects but CA1 and CA2 respectively are unable to determine wheter particular input this part is related to a particular output. Moreover, using the random values generated in accordance to the FCS RNG.1/CA1 and FCS RNG.1/CA2 is required. Each random number generator is deterministic and uses secret key of CA1 and CA2 respectively generated in accordance to FCS CKM.1/CA1 and FCS CKM.1/CA2 respectively. The security objective OT.UNLINKPSEUDO is directly enforced by FPR UNL.1/PSE which ensures that any subject is unable to determine wheter two different pseudonyms generated refers to the same user. Moreover, using the random values generated in accordance to the FCS RNG.1/CA1 and FCS RNG.1/CA2 requires the random number generator to be deterministic and implement capability to specify a personalization string for initialization. Different personalization string for initialization should be used for different pseudonyms of the same user. The security objective OT.CAPRIV is provided by using the key generated in accordance to FCS CKM.1/CA1 and FCS CKM.1/CA2 only for generation of random private values in accordance to FCS RNG.1/CA1 and FCS RNG.1/CA2. The random private values are used according to FCS COP.1/PKA. The security objective OT.CA2VERIFY is directly enforced by FPT TST.1 that requires periodically during normal operation to run a suite of self tests to check the correct operation of the CA2. The security objective OT.LISTINTEGRITY is enforced by FPT TST.1 that requires authorized users with the capability to verify the integrity of the lists of generated psedunyms according to FCS COP.1/PKA. 7.3 Security Assurance Requirements Developement activities (class ADV): ADV ARC.1 Security architecture description ADV FSP.4 Functional specification ADV IMP.2 Implementation representation ADV TDS.3 TOE design Guidance documents activities (class AGD): AGD OPE.1 Operational user guidance 26

28 AGD PRE.1 Preparative procedures Security Target evaluation (class ASE): ASE CCL.1 Conformance claims ASE ECD.1 Extended components definition ASE INT.1 ST introduction ASE OBJ.2 Security objectives ASE REQ.2 Derived security requirements ASE SPD.1 Security problem definition ASE TSS.1 TOE summary specification Tests activities (class ATE): ATE COV.2 Analysis of coverage ATE DPT.1 Testing: basic design ATE FUN.1 Functional testing ATE IND.2 Independent testing - sample Vulnerability assessment (class AVA): AVA VAN.5 Vulnerability analysis 27

29 Bibliography [1] Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general model. (July 2009) 5 [2] Common Criteria for Information Technology Security Evaluation Part 2: Security functional components. (July 2009) 5 [3] Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components. (July 2009) 5 [4] BSI: Algorithms for qualified electronic signatures (2014) 21 [5] Barker, E., Kelsey, J.: Recommendation for random number generation using deterministic random bit generators (revised). NIST Special Publication A (2012) 23 28