Biometric device Common Criteria Protection Profile

Biometric Device Protection Profile D R A F T Biometric Device Protection Profile (BDPP) UK Government Biometrics Working Group Draft Issue 0.82 - 5 September 2001 © 2001 Crown Copyright September 6, 2001 Page 1 of 72 Biometric Device Protection Profile D R A F T This Page Intentionally Left Blank Page 2 of 72 September 6, 2001 Biometric Device Protection Profile D R A F T CONTENTS 1 INTRODUCTION ................................................................................................. 5 1.1 Identification ......................................................................................................................... 5 1.2 Protection Profile overview .................................................................................................. 5 1.3 CC Conformance .................................................................................................................. 6 1.4 Related Protection Profiles ................................................................................................... 6 1.5 Document Organisation ........................................................................................................ 7 1.6 Definitions and Conventions ................................................................................................ 8 1.6.1 Conventions ................................................................................................................. 8 1.6.2 Abbreviations ............................................................................................................... 8 1.6.3 Glossary of CC-Specific and PP-Specific Terms ........................................................ 9 1.6.4 Glossary of Biometric Terms ..................................................................................... 11 1.7 References ........................................................................................................................... 14 2 TOE DESCRIPTION.......................................................................................... 15 3 TOE SECURITY ENVIRONMENT................................................................. 18 3.1 Assumptions ........................................................................................................................ 18 3.1.1 Assumptions about the intended usage of the TOE ................................................... 18 3.1.2 Assumptions about the TOE operating environment ................................................. 18 3.1.3 Connectivity assumptions .......................................................................................... 19 3.2 Threats ................................................................................................................................ 19 3.2.1 Impersonation ............................................................................................................ 20 3.2.2 Threats posed by authorised users ............................................................................. 24 3.2.3 Threats based on exploitation of vulnerabilities or flaws in the TOE ....................... 25 3.2.4 Threats based on physical attacks .............................................................................. 28 3.3 Organisational security policies .......................................................................................... 29 4 SECURITY OBJECTIVES................................................................................ 31 4.1 Security objectives for the TOE .......................................................................................... 31 4.2 Security objectives for the environment ............................................................................. 33 5 IT SECURITY REQUIREMENTS ................................................................... 36 5.1 TOE security functional requirements ................................................................................ 36 5.1.1 Identification and Authentication .............................................................................. 38 5.1.2 Security Management Requirements ......................................................................... 42 5.1.3 Security Audit Requirements ..................................................................................... 44 5.1.4 Protection of the TOE Security Functions ................................................................. 47 5.2 TOE security assurance requirements ................................................................................. 50 5.3 Strength of TOE Security Function Requirements ............................................................. 51 5.3.1 Minimum Strength of Function (SOF) Rating ........................................................... 51 5.3.2 Explicit SOF Metrics ................................................................................................. 52 5.4 Security Requirements for the IT Environment .................................................................. 52 September 6, 2001 Page 3 of 72 Biometric Device Protection Profile D R A F T 6 RATIONALE ...................................................................................................... 53 6.1 Security objectives rationale ............................................................................................... 53 6.1.1 Threats are countered by the security objectives ....................................................... 54 6.1.2 Organisation security policies are met by the security objectives ............................. 61 6.1.3 Assumptions are upheld by the security objectives ................................................... 62 6.2 Security Requirements Rationale ....................................................................................... 62 6.2.1 Suitability of security requirements ........................................................................... 63 6.2.2 Mutually supportive security requirements ............................................................... 68 6.2.3 Assurance security requirements rationale ................................................................ 70 6.2.4 Strength of TOE Security Functions Rationale ......................................................... 72 6.2.5 Refinement of CC Functional Components .............................................................. 72 Page 4 of 72 September 6, 2001 Biometric Device Protection Profile D R A F T Biometric Device Protection Profile 1. 1.1 1 2 3 Introduction Identification Title: Biometric Device Protection Profile (BDPP) September 6, 2001 Registration: Keywords: Biometric Device, Identification, Authentication, Verification 1.2 4 5 Protection Profile overview The Target of Evaluation (TOE) for this Protection Profile (PP) is a Biometric Device. A Biometric Device identifies an individual by examining a unique physical or behavioural characteristic such as the individual’s fingerprints, hand geometry, eye patterns, voice, or dynamic signature. At the application level, biometric systems may provide answers to various questions related to identification and authentication. At the device level, however, Biometric Devices typically answer two types of question: “who is the individual?” or “is the individual who they say they are?” (these questions are of course only answerable in respect of individuals known to the system). 6 The first type compares a live individual’s biometric characteristic against a database of enrolled characteristics, in order to find out who that individual is. This is termed identification in biometric terminology. The second type compares a live individual’s biometric characteristic with a previously enrolled characteristic pertaining to that individual. This is termed verification in biometric terminology. It should be noted that these terms may take on different meanings outside the biometrics context. The intent of this PP is to specify functional and assurance requirements applicable to commercially available Biometric Devices that are used to identify or verify previously enrolled individuals for entry to a portal. A Biometric Device is a simple device, its only function being the identification or verification of an individual’s identity. The portal protects assets such as data, equipment, people, etc. 7 September 6, 2001 Page 5 of 72 Biometric Device Protection Profile D R A F T 8 The Biometric Device Protection Profile (BDPP) supports policies for identification, verification, auditing, and integrity. The BDPP includes requirements concerning the connection between the individual and the Biometric Device, and the connection between the Biometric Device and the portal. It does not, however, specifically address requirements levied upon the assets. In other words, once the individual enters the portal, any additional protection of the assets must be provided by means other than the Biometric Device, and those requirements are not addressed here. A particular Biometric Device is not assumed; the choice being left to the writer of the Security Target (ST). Different Biometric Devices that meet the requirements of this PP are interchangeable in the operating environment from the perspective of these requirements. Throughout this PP it is assumed that the Biometric Device performs identification or verification based on a single biometric characteristic. Whilst the BDPP does not preclude the use of multiple types of biometric characteristics, its requirements will need to be interpreted appropriately for such systems. The BDPP identifies four possible assurance levels ranging from EAL1 augmented (EAL1+) to EAL4. An ST claiming conformance with this PP shall clearly indicate which assurance level is selected, for example by including a statement such as This ST claims conformance with the BDPP at assurance level EAL1+ 9 10 11 12 This approach has been taken within the PP for the following reasons: a) To avoid the maintainability problems associated with defining four separate PP documents that differ only in respect of the assurance requirements and associated rationale. In one sense, this (single) PP document can be regarded as containing the specifications for a family of four very closely related PPs. A minimum assurance requirement of EAL1+ has been identified so as to encourage the evaluation of Biometric Devices against this PP. At the same time, it was considered desirable to give recognition (through PP conformance claims) to those Biometric Devices that are evaluated at a higher assurance level, for which the risk of obvious flaws remaining in the TOE is accordingly reduced. b) 1.3 13 CC Conformance This PP is Part 2 conformant and Part 3 conformant for EAL4. 1.4 14 Related Protection Profiles This PP contains references to general aspects of access control and the use of smartcards or other tokens to store biometric templates. For information on relevant security Page 6 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T standards, see the Common Criteria web site: www.commoncriteria.org. A number of Smart Card Protection Profiles already exist (for example, the Smart Card Security User’s Group Smart Card Protection Profile [SCSUGPP]) which may be relevant where a biometric device is used in conjunction with a smart card for identification and authentication. 1.5 15 16 Document Organisation The structure of this document is as defined by [CC] Part 1 Annex C. Section 2 contains the TOE Description. This provides background information on the TOE type, as an aid to the understanding of its security requirements and its intended usage. Section 3 contains the statement of TOE security environment, which defines the security needs to be addressed by the TOE and its environment. This comprises a specification of: a) b) c) assumptions about the environment (which scope the security needs); threats to the assets which require protection; organisational security policies to be satisfied. 17 18 Section 4 contains the statement of security objectives. Security objectives define what the TOE and its environment must do in order to address the identified security needs, but not how they are to be achieved. The main purpose of this section is to provide a clear division of responsibilities between the TOE and its environment for addressing the security needs. Section 5 contains the statement of IT security requirements. This defines the functional and assurance requirements that are necessary to ensure that the security objectives for the TOE and its IT environment are met. Such requirements are specified using the standard functional and assurance components defined in [CC2] and [CC3]. Section 6 contains the PP rationale which demonstrates that: a) b) the identified security objectives are suitable to address the security needs as defined by the statement of TOE security environment; the specified security requirements are suitable to satisfy all security objectives for the TOE and its IT environment, and that they collectively form a mutually supportive and consistent whole. 19 20 September 6, 2001 Page 7 of 72 Biometric Device Protection Profile D R A F T 1.6 1.6.1 21 Definitions and Conventions Conventions References in this PP to are stated in the form: [,

] where is the unique mnemonic as defined in section 1.7. 22 Individual threats, assumptions, organisational security policies and security objectives are each assigned a unique label for ease of reference, as follows: A.XXX denotes an assumption about the TOE security environment T.XXX denotes a threat to the assets P.XXX denotes an organisational security policy (OSP) O.XXX denotes a security objective for the TOE or its environment. 1.6.2 23 Abbreviations The following standard Common Criteria abbreviations are used in this PP (reproduced for convenience from [CC, 2.1]): CC EAL OSP PP SOF ST TOE TSC TSF TSP Common Criteria Evaluation Assurance Level Organisational Security Policy Protection Profile Strength of Function Security Target Target of Evaluation TSF Scope of Control TOE Security Functions TOE Security Policy 24 Additionally, the abbreviation CEM refers to the Common Evaluation Methodology used for evaluation against the CC. The following abbreviations are used for biometric terms in this PP: FAR FRR VIP False Acceptance Rate False Rejection Rate Very Important Person 25 Page 8 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T 1.6.3 26 27 Glossary of CC-Specific and PP-Specific Terms The following terms are specific to this PP: Administrator — Person appointed by the “owner” of the biometric system to manage the security functionality and security relevant data used by the biometric system. Administrator functions include the enrolment and de-enrolment of users, and the assignment of individuals to the role of operator and administrator of the biometric system. The administrator role also includes monitoring and adjustment of security parameters controlling the performance of the biometric system, and the audit of security events and performance in accordance with the system security policy. In addition, administrators may act in the role of an operator and perform functions normally assigned to operators of the biometric system. Administrators are assumed to be non-hostile and trustworthy. Operator — Person appointed by the “owner” of the biometric system to provide operational support to the system. Such support may include assistance to and supervision of users, starting up and shutting down the biometric system, checking and monitoring the correct operation of the system, and operation of any backup authentication system provided in the case of non- availability of the biometric system. Operators are not authorised to access security functionality or security relevant data provided for administrators of the biometric system. User — Person who requires access to the assets through the portal protected by the biometric system. Users are not authorised to access security relevant data used by the biometric system, or security or other functionality provided for operators and administrators of the biometric system. Additionally, the following CC-specific terms are used in this PP, with their definitions reproduced from [CC1, 2.2] for convenience: Assets — Information or resources to be protected by the countermeasures of a TOE. Assignment — The specification of an identified parameter in a component. Assurance — Grounds for confidence that an entity meets its security objectives. Attack potential — The perceived potential for success of an attack, should an attack be launched, expressed in terms of an attacker’s expertise, resources and motivation. Augmentation — The addition of one or more assurance component(s) from Part 3 to an EAL or assurance package. Authentication data — Information used to verify the claimed identity of a user. 28 29 30 31 32 33 34 35 36 September 6, 2001 Page 9 of 72 Biometric Device Protection Profile D R A F T 37 Authorised user — A user who may, in accordance with the TSP, perform an operation. Component — The smallest selectable set of elements that may be included in a PP, an ST, or a package. Dependency — A relationship between requirements such that the requirement that is depended upon must normally be satisfied for the other requirements to be able to meet their objectives. Element — An indivisible security requirement. Evaluation — Assessment of a PP, an ST or a TOE, against defined criteria. Evaluation Assurance Level (EAL) — A package consisting of assurance components from Part 3 that represents a point on the CC predefined assurance scale. Iteration — The use of a component more than once with varying operations. Organisational security policies — One or more security rules, procedures, practices, or guidelines imposed by an organisation upon its operations. Protection Profile (PP) — An implementation-independent set of security requirements for a category of TOEs that meet specific consumer needs. Refinement — The addition of details to a component. Role — A predefined set of rules establishing the allowed interactions between a user and the TOE. Security attribute — Information associated with subjects, users and/or objects that is used for the enforcement of the TSP. Security objective — A statement of intent to counter identified threats and/or satisfy identified organisation security policies and assumptions. Security Target (ST) — A set of security requirements and specifications to be used as the basis for evaluation of an identified TOE. Selection — The specification of one or more items from a list in a component. Strength of Function (SOF) — A qualification of a TOE security function expressing the minimum efforts assumed necessary to defeat its expected security behaviour by directly attacking its underlying security mechanisms. 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 Page 10 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T 53 SOF-basic — A level of the TOE strength of function where analysis shows that the function provides adequate protection against casual breach of TOE security by attackers possessing a low attack potential. SOF-medium — A level of the TOE strength of function where analysis shows that the function provides adequate protection against straightforward or intentional breach of TOE security by attackers possessing a moderate attack potential. SOF-high — A level of the TOE strength of function where analysis shows that the function provides adequate protection against deliberately planned or organised breach of TOE security by attackers possessing a high attack potential. Target of Evaluation (TOE) — An IT product or system and its associated administrator and user guidance documentation that is the subject of an evaluation. TOE Security Functions (TSF) — A set consisting of all hardware, software, and firmware of the TOE that must be relied upon for the correct enforcement of the TSP. TOE Security Policy (TSP) — A set of rules that regulate how assets are managed, protected and distributed within a TOE. TSF data — Data created by and for the TOE, that might affect the operation of the TOE. TSF Scope of Control (TSC) — The set of interactions that can occur with or within a TOE and are subject to the rules of the TSP. Glossary of Biometric Terms Biometric terms used in this PP are as defined in the 1998 Glossary of Biometric Terms produced by the Association for Biometrics (AfB) and the International Computer Security Association (ICSA)1. The relevant definitions are reproduced here for convenience. Attempt — The submission of a biometric sample to a biometric system for identification or verification. A biometric system may allow more than one attempt to identify or verify. Behavioural Biometric — A biometric which is characterised by a behavioural trait that is learnt and acquired over time rather than a physiological characteristic. Biometric — A measurable, physical characteristic or personal behavioural trait used to recognise the identity, or verify the claimed identity, of an enrolee. 54 55 56 57 58 59 60 1.6.4 61 62 63 64 1. See http://www.afb.org.uk/public/glossuk1.html September 6, 2001 Page 11 of 72 Biometric Device Protection Profile D R A F T 65 66 Biometric Application — The use to which a biometric system is put. Biometric Data — The extracted information taken from the biometric sample and used either to build a reference template or to compare against a previously created reference template. Biometric Sample — Data representing a biometric characteristic of an end-user as captured by a biometric system. Biometric System — An automated system capable of: 1) capturing a biometric sample from an end user; 2) extracting biometric data from that sample; 3) comparing the biometric data with that contained in one or more reference templates; 4) deciding how well they match; and 5) indicating whether or not an identification or verification of identity has been achieved. Capture — The method of taking a biometric sample from the end user. Comparison — The process of comparing a biometric sample with a previously stored reference template or templates. Enrolee — A person who has a biometric reference template on file. Enrolment — The process of collecting biometric samples from a person and the subsequent preparation and storage of biometric reference templates representing that person’s identity. Equal Error Rate — When the decision threshold of a system is set so that the proportion of false rejections will be approximately equal to the proportion of false acceptances. False Acceptance — When a biometric system incorrectly identifies an individual or incorrectly verifies an impostor against a claimed identity. False Acceptance Rate/FAR — The probability that a biometric system will incorrectly identify an individual or will fail to reject an impostor. It is stated as follows: FAR = NFA / NIIA or FAR = NFA / NIVA where FAR is the false acceptance rate NFA is the number of false acceptances NIIA is the number of impostor identification attempts NIVA is the number of impostor verification attempts 67 68 69 70 71 72 73 74 75 Page 12 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T 76 False Rejection — When a biometric system fails to identify an enrolee or fails to verify the legitimate claimed identity of an enrolee. False Rejection Rate/FRR — The probability that a biometric system will fail to identify an enrolee, or verify the legitimate claimed identity of an enrolee. It is stated as follows: FRR = NFR / NEIA or FRR = NFR / NEVA where FRR is the false rejection rate NFR is the number of false rejections NEIA is the number of enrolee identification attempts NEVA is the number of enrolee legitimate verification attempts Goats — Biometric system enrolled end users whose pattern of activity when interfacing with the system varies beyond the specified range allowed by the system, and who consequently may be falsely rejected by the system. Identification/Identify — The one-to-many process of comparing a submitted biometric sample against all of the enrolled users on the system to determine whether it matches any of the templates and, if so, the identity of the enrolee whose template was matched. The biometric system using the one-to-many approach is seeking to find an identity amongst a rather than verify a claimed identity. Contrast with Verification. Impostor — A person who submits a biometric sample in either an intentional or inadvertent attempt to pass him/herself off as another person who is an enrolee. Physical/Physiological Biometric — A biometric which is characterised by a physical characteristic rather than a behavioural trait. Template — Data which represents the biometric measurement of an enrolee used by a biometric system for comparison against subsequently submitted biometric samples. Threshold — The acceptance or rejection of biometric data is dependent on the match score falling above or below the threshold. The threshold is adjustable so that the biometric system can be more or less strict, depending on the requirements of any given biometric application. Verification/Verify — The process of comparing a submitted biometric sample against the biometric reference template of a single enrolee whose identity is being claimed, to determine whether it matches the enrolee’s template. Contrast with Identification. Zero Effort Forgery — An arbitrary attack on a specific enrolee identity in which the impostor masquerades as the claimed enrolee using his or her own biometric sample. 77 78 79 80 81 82 83 84 85 September 6, 2001 Page 13 of 72 Biometric Device Protection Profile D R A F T 1.7 [CC] [CC1] [CC2] [CC3] [CEM] [SCSUGPP] References Common Criteria for Information Technology Security Evaluation, Version 2.1, August 1999 CC Part 1: Introduction and general model Version 2.1, CCIB-99-031, August 1999 CC Part 2: Security functional requirements Version 2.1, CCIB-99-032, August 1999 CC Part 3: Security assurance requirements Version 2.1, CCIB-99-033, August 1999 Common Evaluation Methodology (CEM) Part 2 Version 1.0, CEM-99/045, August 1999 Smart Card Security User’s Group - Smart Card Protection Profile (SCSUG-SCPP) Version 2.1d, 21 March 2001 Page 14 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T 2. 86 TOE description An example configuration for TOEs that comply with this PP is shown in Figure 1. In the figure, the Biometric Device is a face recognition system which controls the door to a facility in which a variety of assets are contained. Note that the Biometric Device could be a fingerprint reader, voice recognition system, or any other currently available Biometric Device. Also note that the portal is not limited to a door. A successful verification might unlock a keyboard, a file cabinet, or other entity which contains assets to be protected. Figure 1. An example Biometric Device in an operating environment Biometric Device Assets Portal 87 The Security Target (ST) for a conformant TOE must specify the Biometric Device and the feature or features used (e.g. finger, face etc.), and the intended environment of use for the Biometric Device. The evaluation and certification will be valid for that device and environment only. It may be necessary for some operating environments to include a manual fall-back system which would be used in the event of failure of the Biometric Device, or where individual users are unable to use the biometric system, e.g. because they lack the biometric feature used, or have a disability which prevents successful use, or are temporarily unable to use the system. For the purposes of the BDPP, such fall-back 88 September 6, 2001 Page 15 of 72 Biometric Device Protection Profile D R A F T systems are considered to be outside the scope of the TOE, and no assumptions are made in the PP regarding the use of any fall-back systems. This is because they will be specific to the target operating environment; any such assumptions must be enumerated in the ST. 89 A Biometric Device has three basic components. The first component captures the live individual’s physical or behavioural characteristic; this includes both the identity claim and the biometric feature, which may be integrated together into one device or separated. The second component handles image compression, storage, verification, and administrative functions. The third component interfaces with application systems such as the opening of the portal. Typically, the capture device is located outside the portal while the other components are physically protected, perhaps located inside the portal. Figure 2. Biometric Verification Device - High-Level Architecture User Input of physical or behavioural characteristic Claimed Identity Capture Device Scan Live Image Portal Portal Signal Generator Keyboard or card-reader Comparator Image Compression Verification (Image Comparison) Administrative Functions Enrolled Templates Database Protected 90 Figure 2 shows a typical high-level overview of the architectural components of a Biometric Device used for verification of identity. (Note that this is illustrative and is Page 16 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T not intended to constrain the TOE design or its applicability in any way.) The logical boundary of the TOE for the purposes of the BDPP includes the connection between the capture device and the comparator component as well as the connection between the comparator component and the portal. These connections must be correct and tamperproof and are discussed in the BDPP. Note that the capture device is shown as comprising the claim of identity and the biometric scanner. In practice these functions may be performed by separate items of hardware. Also the use of the term “image” is generic; it does not imply that the biometric characteristic is limited to graphic images only. 91 Note that in some cases the biometric templates may be user-held (e.g. stored on a smartcard); in this event the biometric templates might also be stored on the system in order to provide a fall-back system (e.g. in the event that users lose their token), or they might not be stored on the system at all. In such cases there will be a need to ensure the authenticity and integrity of the user-held templates, so as to provide assurance in the binding between the template and the individual. A smartcard may also perform the comparison function (with the capture device being external), or may even incorporate its own biometric sensor. In the latter case, the smartcard will provide the external system with the result of the process. 92 September 6, 2001 Page 17 of 72 Biometric Device Protection Profile D R A F T 3. 93 TOE Security environment This section identifies the specific security needs which motivated the choice of BDPP requirements. Section 3.1 addresses assumptions concerning the operating environment. Threats to the security of the assets requiring protection by the Biometric Device are described in section 3.2. Organisational security policies are identified in section 3.3. 3.1 94 Assumptions This section discusses the scope of intended usage of the TOE as well as assumptions about the operating environment including physical, personnel, and connectivity issues. Assumptions about the intended usage of the TOE The Biometric Device is intended to be used for identifying, or verifying the identity of, regular users for entry to a portal. Once inside the portal, assets are not protected by the Biometric Device. 3.1.1 A.PORTAL 95 The portal may either be physical (e.g. door, safe) or logical (e.g. operating system or application authentication). There may be other logical measures (e.g. access control) to protect the assets once the user has gained entry to the portal, but these are not within the scope of the TOE. Assumptions about the TOE operating environment 3.1.2 A.FALLBACK It is assumed that any alternative or fallback verification/identification system, used when the biometric system is not in operation, offers adequate protection of the assets. The security of the fallback system is outside the scope of the evaluation. A.ROLES Administrator, operator, and regular user roles are defined in this Protection Profile. Depending on the application, 2 or more individuals may fulfil a single role; alternately, 2 or more roles may be fulfilled by a single individual. In each case the characteristics applicable to roles are assumed to be transferred to the individual or individuals filling the roles. 96 See section 1.6.3 for a definition of the administrator, operator and user roles. Administrators are assumed to be non-hostile and trusted to perform all their duties in a competent manner. A.NO_EVIL Page 18 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T 97 The effect of this assumption is to rule out of scope any threats that may be posed by hostile or incompetent administrators. This does not, of course, mean that administrators are assumed to be incapable of human error. Connectivity assumptions 3.1.3 A.USERTMPL It is assumed that, if users supply their own biometric template (e.g. stored on a smartcard), measures exist to protect the authenticity and integrity of the template. 98 For example, a smart card that is conformant to [SCSUGPP] would provide suitable protection for the stored biometric template (see also section 1.4). 3.2 99 Threats The threats listed here are addressed by BDPP compliant TOEs. The primary assets requiring protection by the Biometric Device are not stored in the TOE itself; rather, the assets comprise such things as information, equipment, people, and so on, that may be accessed through entry to the portal. While the threat agent and attack vary for different threats, the motivation is generally the same - to gain illegal entry to the portal controlled by the Biometric Device, and in turn the assets contained therein, or to deny entry to legitimate users (e.g. a denial of service attack). Note that in some threat statements secondary assets may be identified which, if compromised, could leave the primary assets vulnerable to attack. The most significant secondary assets are the biometric templates of authorised users, the integrity and authenticity of which needs to be assured. In other words, these assets will be compromised if the binding between the template and the individual is undermined. In contrast, the security of the primary assets cannot (given the nature of biometric characteristics, and the possibility of access by an impostor to a similar but unprotected biometric system) rely on the confidentiality of the biometric template data; that said, in some cases an impostor’s opportunities for attack can be constrained by controlling access to stored templates. The threat agents may either be authorised users (whether regular users, operators or administrators) or unauthorised users. The following general terms are used, in a number of the threat descriptions which follow, to identify the threat agent: a) An impostor is any individual (authorised or unauthorised user) who is either intentionally or inadvertently attempting to pass him/herself off as another person who is an enrolee. An attacker is any individual who is attempting to subvert the operation of the Biometric Device. The intention may be either to subsequently gain illegal entry to the portal (or enable other individuals to do so), or to deny entry to legitimate users. 100 101 b) September 6, 2001 Page 19 of 72 Biometric Device Protection Profile D R A F T 102 Note, however, that it is assumed (A.NO_EVIL) that administrators are not hostile, and hence such individuals are considered to be threat agents only to the extent that vulnerabilities could arise in the event of administrator error. Impersonation The main threat to the assets requiring protection by the Biometric Device and its environment is that of impersonation, that is to say of an impostor masquerading as another person who is an enrolee, and gaining access to the assets protected by the portal. There are a number of forms that the impersonation may take and these are listed as separate threats in this section. They all, however, relate to the following general threat: An unauthorized individual may enter the portal. 3.2.1 103 104 There are a number of instantiations of this general threat which are described here. Broadly speaking, they can be categorised as follows: a) An impostor attempts to defeat the biometric verification or identification either by a zero-effort forgery attempt (T.CASUAL), or through mimicry (T.MIMIC), or by use of an artifact (T.ARTIFACT). The attack by the impostor is directed at some known or suspected weakness (T.WEAKID, T.EVILTWIN, T.RESIDUAL, T.POORIMG). Such threats may help realise attacks based on zero-effort forgery, mimicry or use of an artifact (and thus overlap to some extent with T.CASUAL, T.MIMIC or T.ARTIFACT). The attack by the impostor attempts to subvert the identification or verification process, by undermining the integrity of biometric templates (T.FAKETEMPL, T.ILLENROL). b) c) 105 As can be seen, there is significant inter-dependency between the threats, and some attacks could be considered to be within the scope of more than one threat (e.g. the distinction between mimicry and the use of an artifact is not necessarily clear-cut in all cases). What matters, however, is that the attack is considered and addressed, rather than the precise categorisation. An impostor may make a zero-effort forgery attempt to impersonate an authorised user. T.CASUAL 106 The attacked identity is randomly chosen and the impostor makes no attempt to modify his/her own biometric characteristics to appear closer to the attacked identity. If the system is an identification system where the impostor does not claim any particular ID, all IDs are attacked in a single attempt. The chance of such an attack being successful is measured by the False Acceptance Rate (FAR) of the device. The level of threat will Page 20 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T be dependent on the residual FAR after the thresholds which control the balance between the FAR and FRR (False Rejection Rate) have been set by the administrator. 107 Such an attempt may be successful if: • • • The system has too high a FAR (the system may be incapable of a low enough FAR or it may be set incorrectly allowing too high a FAR). The impostor has, by chance, a sufficiently close biometric similarity to an authorised user to be able to fool the system. The impostor is able to make many unchallenged attempts to gain access. Such attempts may be on a single ID or a range of IDs. Note that, for an identification system, the impostor is effectively attacking all user IDs at once. This will have an impact on the FAR necessary to achieve the required protection of the assets. 108 A sufficiently low FAR value means that this kind of attack is likely to be caught if the system has the appropriate alarms to prevent several unchallenged attempts. The chance of getting caught may be sufficient deterrent to an impostor relying on chance alone. Note that in the case of an identification system the FAR may be affected by the size of the database and also, potentially, the demographics of the database population. An impostor may be able to reproduce the biometric characteristics for the ID under attack by mimicry, e.g. changing his/her voice, forging a signature or hand contortions. T.MIMIC 109 This threat represents an attack which is mounted at the position of the biometric capture device. It covers cases where the impostor is not using a tool or artifact but is changing his/her own appearance or behaviour to more closely resemble a user. The impostor may be able to capture the biometric feature used by the system (e.g. record voice, photograph face, video signature etc.) or gain access to the template stored on the biometric system. The impostor may then practice mimicry of the biometric feature to give an “accepted” biometric sample. Many biometrics are “public”, i.e. the impostor can find out what needs to be copied from recording speech, or observing a live signature, etc. Moreover, if someone has been enrolled with the same biometric on several systems, the information may be accessed on the least secure system. In practice, there is little that can be done to reduce the risk that an impostor could obtain this information. Mimicry is potentially more applicable to behavioural biometrics than for physical, though even physical biometrics may have a behavioural component, e.g. one can adjust ones apparent height by stooping or stretching. In a supervised system, or systems using dual biometrics (e.g. two finger verification, fingerprint plus iris, etc.), the level of difficulty in successfully mimicking an enrolee undetected may be much greater. 110 111 112 113 September 6, 2001 Page 21 of 72 Biometric Device Protection Profile D R A F T T.ARTIFACT An impostor may use an artificial biometric characteristic (e.g. artificial hand/ fingerprint, life-size photograph, etc.) to gain access. 114 If an impostor can access a biometric image or template, he/she may be able to produce an artifact with an equivalent biometric template. Biometric systems unable to detect the difference between a live sample and an artifact may be fooled by the use of such an artifact. As for the case of mimicry above, many biometrics are “public”, i.e. the impostor can find out what needs to be copied from recording speech, or observing a live signature, etc. Moreover, if someone has been enrolled with the same biometric on several systems, the information may be accessed on the least secure system. In practice, there is little that can be done to reduce the risk that an impostor could obtain this information. Fingerprint and hand geometry systems are known to be vulnerable to artifacts. The setup costs are often low making the production of artifacts worthwhile for impostors for biometric technologies in common use. The risk is reduced for systems which make some check for liveness and also for supervised systems but may not be eliminated in either case. For example, supervision may not spot all attempts to use an artifact. Note that an attack may simultaneously involve the use of mimicry and an artifact. For example, in a face recognition biometric, an impostor may both distort his/her face (mimicry) and wear spectacles (artifact) to appear more like a user. An impostor may direct an attack against a weak ID. 115 116 117 118 T.WEAKID 119 An impostor may attack a specific ID which is known or assumed to be weaker than others. A poor enrolment can result in a bad or noisy image and an insecure template with wide thresholds, effectively increasing the FAR for the individual. If an impostor can identify such a user, an attack could be directed against the weak ID. Such an attempt may succeed if: • • The FAR is much higher for some IDs than for others, either naturally or through enrolee collusion (see below). A poor enrolment image has resulted in the construction of an insecure template. For example, in the case of signature verification device, the enrolee might provide a set of signatures with much greater variation than normal. (See also T.POORIMG for the effect of noise on enrolment.) An impostor can discover which are the weak IDs. This may happen through collusion, or through finding which IDs have the loosest threshold settings in the database. It is also possible that the decision threshold has been relaxed for 120 • Page 22 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T some (easily identified) individuals who would otherwise have problems in using the system (e.g. because of spectacles for a face-recognition system). 121 The risk will depend on the device and the biometric technology used. It may be mitigated if weak IDs can be identified and eliminated, perhaps by re-enrolling weak IDs. This may happen at the time of enrolment or later, perhaps by analysis of intertemplate comparisons. Relaxing the decision thresholds to allow “goats” to use the system more easily, or to prevent VIPs from false rejection, will increase the risk. T.EVILTWIN An impostor may attack a similar or twinned biometric template. 122 In some cases an impostor may know that his/her biometric characteristics are very similar to those of an enrolee, and attack that identity. This includes physical twins but is not confined to this case. The greater the number of enrolees the more likely it is that the impostor resembles one of them. Where the biometric device may confuse two individuals, an impostor may know which enrolee(s) they best match (and, for example, which finger to use). The risk is not confined to identical twins. As a result of FAR limitations, there may be pairs of unrelated individuals within relatively small samples who can be reliably identified as each other. The administrator can find out which pairs of individuals cannot easily be distinguished by the device (by performing inter-template comparisons). Such information should be kept confidential. However, an impostor may discover this information from a similar system elsewhere if the indistinguishable individuals are enrolled on both systems. Also when an administrator leaves, he/she may take away knowledge of similar IDs and, unlike password based authentication, it is not possible to change the biometric templates if the knowledge of similarities is seen to present a security risk. In practice, there is little that can be done to reduce the risk that an impostor would be able to acquire such knowledge. 123 T.RESIDUAL The residual biometric image from a previous user may be sufficient to allow access to an impostor. 124 Some biometric systems may be vulnerable to residual images. These are likely to be limited to cases where physical contact with the biometric capture device is involved, the obvious case being fingerprints. If an enrolled user leaves a residual fingerprint on a fingerprint capture device, an impostor may be able to gain access subsequently. This vulnerability may be exploited separately or in conjunction with another vulnerability such as the use of an artifact. For example, this effect has been observed during enrolment on some fingerprint systems. Potential exists when in verification, if the system detects the presence of a finger without the residual fingerprint image being obliterated. It is unlikely to be a risk on systems where no physical contact is involved in the capture of the biometric image. 125 T.POORIMG An impostor may direct attack against a noisy or null image. September 6, 2001 Page 23 of 72 Biometric Device Protection Profile D R A F T 126 Biometric systems may be vulnerable to attack if a noisy image is generated at enrolment (unintentionally) or at the time of verification (intentionally). This threat is concerned with the former case (the latter case is addressed by T.NOISE in section 3.2.4 below). An impostor may also be able to gain illegal entry to the portal if the system accepts a null image at the time of enrolment. For example, some fingerprint systems may treat noise in the image as if it were minutiae points, and a noisy image may then produce sufficient agreements with the reference template to pass the verification. With such systems an impostor may be able to greatly increase the chance of acceptance through the generation of a noisy fingerprint image, or through the construction of an artificial fingerprint exploiting this weakness. Similarly, voice recognition systems may be vulnerable if the system accepts a sample that is ‘too quiet’, e.g. if the enrolee pauses too long before starting to speak, the sample may consist almost entirely of noise. Even if the system implements a ‘too quiet’ threshold for sample acceptance, it may still be vulnerable if the background noise exceeds this threshold. The risk depends on the system. With well developed technologies the possible pitfalls are known (to the industry), and checks can be made that the system avoids these errors. 127 128 129 T.FAKETMPL If a user supplies his/her own biometric template (e.g. stored in a smart-card), such a card may be forged, containing the biometric template of an impostor. 130 This threat applies where the template is held by the user, and consequently there is no access control by the system to ensure the authenticity and integrity of the template. Therefore alternative means will be needed to safeguard its security, for example template signing by a trusted third party. T.ILLENROL An impostor may become illegally enrolled on the biometric system. 131 It may be possible for an impostor to be added to the database of enrolled templates, perhaps through security procedure error or by failure to remove trial templates or templates of former staff. It may be possible for impostors to add illegal enrolment templates directly, e.g. through unauthorised access to the template database itself or to its backups. The effect of this threat is therefore to undermine the integrity of enrolment templates. Threats posed by authorised users This section details threats posed by authorised users, operators and administrators of the Biometric Device. Such attacks may have the intent or effect of allowing illegal entry to the portal, or of denying entry to legitimate users (i.e. denial of service). 132 3.2.2 133 Page 24 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T T.BADUSER A user attempts to exceed their authority. 134 Three types of individuals access the Biometric Device: administrators, operators, and regular users. Regular users with no special privileges may attempt to modify their individual parameters, such as the time of day they may enter, the particular portal they may use, etc. Alternatively, if administrators or operators can gain access to the administrator or operator functions through biometric authentication, regular users may attempt to gain special privileges by impersonating an administrator or operator thereby assuming the privileges that are associated with those roles. Only administrators have access to functions that would allow individual parameters to be modified. If administrator or operator access is granted through biometric authentication, a regular user would need to impersonate an administrator or operator for this attack to succeed (see the threats of impersonation above). If administrators and operators cannot gain access through the biometric authentication, this risk is eliminated. However, the risk that a regular user could gain access to the administrator or operator functions through the non-biometric interface provided will need to be assessed separately. A legitimate administrator may unintentionally misuse their authority. 135 136 T.BADADM 137 An administrator has additional authority over a regular user. An administrator might inadvertently use this authority to erroneously allow/disallow entry to the portal. (Note that the assumption A.NO_EVIL states that administrators will not misuse their authority intentionally). The risk of this vulnerability occurring is high, especially without proper security awareness training. 138 T.BADOPER A legitimate operator may intentionally or unintentionally compromise the security of the Biometric Device during routine maintenance. 139 The operator is responsible for non-security maintenance of the Biometric Device. However, it may be possible to compromise the device during such maintenance. The risk of this vulnerability being exploited is moderate to high. An operator does have privileged access, particularly to hardware, and could take advantage of that privilege to launch an attack. Threats based on exploitation of vulnerabilities or flaws in the TOE This section describes a collection of threats where the threat agent is attempting to exploit vulnerabilities in the design, implementation or operation of the Biometric Device in order to circumvent the TOE’s security functions. Such attacks may have the 140 3.2.3 141 September 6, 2001 Page 25 of 72 Biometric Device Protection Profile D R A F T intent or effect of allowing illegal entry to the portal, or of denying entry to legitimate users (i.e. denial of service). T.BYPASS 142 An impostor may bypass the capture device or other parts of the biometric system. A bypass attack could be mounted against various parts of the biometric system with the aim of bypassing one or more components of the system to effect entry by an impostor. The attack may involve hardware and software elements or compromise of the security policy. An impostor may bypass the capture device and present a biometric image directly to the system algorithms, e.g. by a replay attack. An impostor could bypass one or more components of the biometric system software, preventing it from fulfilling its normal security functionality (see also the related threat T.CORRUPT). An impostor may bypass the whole biometric system to gain access to the portal together with an authorised user. An impostor may also be substituted for an authorised user after the authorisation operation. This could occur with the collusion of an authorised user or inadvertently, due to distraction. Alternatively an authorised user may be kidnapped and forced to invoke the authorisation process or an impostor may force his/her way through the portal. The risk here is likely to be reduced if the system is supervised or if it is physically designed to allow access to only one person per authorisation operation. 143 144 145 T.CORRUPT An attacker may modify the security-relevant system configuration data, or other security-relevant data such as enrolled user templates, or program executables of the Biometric Device. 146 Such an attack could compromise the integrity of the user security attributes (e.g enrolled user templates) or the executables of the Biometric Device, resulting in an incorrect result which may afford illegal access to the portal. This threat covers a number of distinct types of attack. An attacker may attempt to modify the threshold level used by the Biometric Device to authenticate users. If the attacker is able to change the threshold (for one or more authorised users), the ability of the device to identify or verify the user(s) will be compromised, and an impostor may succeed in gaining entry to the portal, or an authorised user may be denied entry to the portal. An attacker may attempt to modify the access rights of an authorised user. If the attack succeeds, an authorised user may be able to gain access rights that he/she is not entitled to have, or an authorised user may be denied legitimate rights. 147 148 Page 26 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T 149 An attacker may attempt to modify the biometric authentication data (the biometric template) of an authorised user with the aim of enabling an impostor to masquerade as the authorised user and gain access to the portal. Alternatively, an authorised user may be denied access to the portal. The attacker may be able to insert a new biometric template, containing biometric data belonging to an impostor, with the aim of enabling the impostor to gain entry to the portal. An attacker may attempt to modify or replace programs used by the biometric device with the aim of changing its behaviour so as to allow entry to the portal to impostors, or to deny entry to authorised users. The risk of these vulnerabilities being exploited depends on the resources of the adversaries and how valuable the assets protected by the Biometric Device are to the adversaries. 150 151 T.UNDETECT An undetected attack against the TOE security functions is mounted by an attacker, which eventually succeeds in either allowing illegal access to the portal, or denying access to authorised users. 152 Such an attack may succeed as a result of: a) b) c) repeated attempts to defeat the biometric verification or identification functions; identification and exploitation of vulnerabilities in the implementation of the Biometric Device; identification and exploitation of vulnerabilities in the operational use of the Biometric Device, e.g. insecure configuration. 153 Whilst the attack is most likely to be launched with the intent of gaining illegal access, it may also be with the intent of creating denial of service, e.g. depending on how the TOE or its environment addresses the organisational security policy P.USERLIMIT (see section 3.3). Proper management and monitoring of the Biometric Device depends on the ability to detect and report the occurrence of security relevant events, to determine the identity of those responsible for such events, and to protect the event records from unauthorized access, modification, or destruction. An undetected attack, leading to exploitation of vulnerabilities in the Biometric Device, may occur as a result of weaknesses in the detection mechanism, for example: • inadequate collection of audit data, e.g. the audit parameters might be inadequately set or the audit mechanism may not be strong enough for the intended purpose; 154 155 September 6, 2001 Page 27 of 72 Biometric Device Protection Profile D R A F T • • unauthorized modification of the audit trail, which an attacker may exploit to cover his or her tracks; failure of an administrator to properly peruse the audit trail and take appropriate action when necessary. 156 One of the motivations for attack is a low probability of being caught. The audit trail serves the purpose of catching attacks after-the-fact and may serve as a deterrent. A power loss results in failure of the Biometric Device. T.POWER 157 If the power fails and the Biometric Device becomes inoperable, it may be possible for unauthorized individuals to enter the portal, either through being able to exploit vulnerabilities in the fallback system, or if the Biometric Device fails in an unsafe (i.e. insecure) manner. Threats based on physical attacks This section details threats which are based on deliberate physical attack against the Biometric Device. Such attacks may have the intent or effect of allowing illegal entry to the portal, or of denying entry to legitimate users (i.e. denial of service). The Biometric Device or its connections are flooded with noise data causing improper functioning of the capture device or comparator, causing an individual to be erroneously allowed or denied entry to the portal. 3.2.4 158 T.NOISE 159 This type of attack could either allow impostors to enter the portal or result in a denial of service to authorized users. The particular form of noise which would pose a threat would depend on the biometric. The main types are electro-magnetic flooding (at wavelengths from radio frequency through light to gamma rays) and acoustic noise. Note that the threat only relates to flooding attacks that occur at the time of identification or verification. Noise may also affect the quality of the enrolled template; however, such problems are within the scope of threats T.WEAKID and T.POORIMG. An attacker may modify or otherwise alter the hardware components or the connections between them, or between the Biometric Device and the portal, thereby causing an individual to be erroneously allowed or denied entry to the portal. 160 T.TAMPER 161 This threat includes tampering attacks against the following: • • the hardware components, e.g. the capture device or comparator; the connection between the capture device and the comparator to insert a forged or copied physical or behavioural characteristic; Page 28 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T • the connection(s) between the comparator and the portal, such that the result of verification is not securely relayed, or an access allowed/denied result is submitted to the connection by means other than the Biometric Device. 3.3 P.FARFRR Organisational security policies The Biometric Device must meet a recognised national or international standard for false acceptance and false rejection rates, as appropriate for the required level of assurance. 162 National Authorities or international standards bodies will be responsible for specifying standards for false acceptance and false rejection appropriate to the assurance level required. The ST (and certification report for the TOE) shall indicate the standard (or standards) to which conformance is required or claimed. In general, it is expected that the higher the level of assurance required, the more demanding will be the requirements of the national or international standards in respect of the FAR and FRR. Different requirements may apply to identification and to verification. If the TOE implements multiple biometric authentication mechanisms, the ST writer should consult with the appropriate authorities to determine how the FAR and FRR requirements apply in such cases. All individuals who access any security-related device must receive training on the proper use of the device as well as security issues and vulnerabilities that arise from its improper use. 163 164 P.TRAIN P.USERLIMIT Impostors must be prevented from gaining access to the portal by making repeated verification attempts using one or more claimed IDs. 165 There are a number of ways in which repeated attempts by unauthorised users can be countered. One is to set a limit set on the number of unsuccessful attempts allowed. Once this limit is reached, further attempts will not be accepted, even if the identification matches an authorised user. Other possibilities include the temporary increase in security through requiring a PIN or a supervised access. Note the need to guard against repeated attempts using different claimed IDs. In satisfying P.USERLIMIT, the potential denial of service implications described in the description of threat T.UNDETECTED should also be addressed (see section section 3.2.3). In the case of an identification system (where no prior claim of identity is made), a single identification attempt by an impostor simultaneously attacks all enrolled IDs. If the impostor makes a zero-effort attempt then the identification result will be the same 166 167 September 6, 2001 Page 29 of 72 Biometric Device Protection Profile D R A F T for subsequent attacks (at least until the enrolled templates database is updated). If the impostor attempts to modify their biometric characteristic (e.g. through mimicry) the TOE will not be able to detect that it is the same individual involved in the attack. Therefore, P.USERLIMIT does not apply to identification systems (although if this is considered to be a risk in a specific system, it can be addressed by measures taken within the environment; such measures should be described in the ST for the system). Page 30 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T 4. 168 Security Objectives This section describes the security objectives for the TOE and those for the environment. Section 4.1 delineates security objectives for the TOE which will be addressed by TOE security functional requirements in Section 5.1. Section 4.2 discusses security objectives for the environment which will be implemented within the Information Technology (IT) domain by non-technical or procedural means. These objectives and their realization within the TOE environment are not discussed further in this PP. 4.1 O.FARFRR Security objectives for the TOE The TOE shall meet specified national or international standards for false acceptance and false rejection rates in accordance with P.FARFRR. 169 This is the principal objective of the TOE, which is to authenticate all authorised users while denying authentication to impostors. The identifying power of a Biometric Device is defined by its FAR and FRR, which are inter-dependent. The desired balance between FRR and FAR can normally be controlled administratively through threshold adjustments, but it is generally not possible to set to zero either parameter singly or together. The thresholds must be set to meet the specified protective security requirements of the assets under threat. Limits for false acceptance and false rejection rates will be determined and specified by the relevant national or international standards. The current figures should be referenced and stated in the ST. Note that as a minimum, biometric authentication applies to regular users: as noted under O.ADMIN and O.OPER below, different authentication mechanisms may be used for administrators and operators. The ST must clearly identify which roles are subject to biometric authentication. in gaining access to the assets requiring protection. 170 O.FEEDBACK The TOE shall not provide feedback information to users which may assist an impostor 171 It is often useful for a biometric system to provide feedback to legitimate users in order to help them to be identified reliably by the system. For example, a fingerprint biometric may provide an image of the captured fingerprint to the user, to facilitate the correct positioning of the finger and the generation of a good image. This feedback should not be such, however, as to help impostors to gain unauthorised access; for example by providing “scores” which might allow impostors to train themselves on the system and observe how close they are to being identified or verified by the system. The TOE shall limit TOE administrative functions to those verified as administrators by the TOE. The TOE shall provide all the administrative functions necessary to support the management of TOE security and shall include functions to: 1) tune the performance of the biometric system to meet the requirements of the system security O.ADMIN September 6, 2001 Page 31 of 72 Biometric Device Protection Profile D R A F T policy; 2) maintain the security attributes associated with users (e.g. enrolled templates database); 3) manage auditing (including accessing or modifying the audit trail); 4) restore the Biometric Device to a secure state in the event of failure or interruption; 5) verify secure operation of the TOE. 172 Note that in order to achieve this objective the TOE will need to identify and authenticate administrators of the TOE, but this need not be by means of the TOE’s biometric authentication mechanism. As noted in paragraph 136, there are risks associated with using the same authentication mechanism to authenticate administrators as that used for regular users; but equally, the risk of using alternative mechanisms may be greater. It is for the ST to justify the choice of mechanism for authentication of administrators. This security objective means that the modification of security-relevant data, configuration items, audit parameters, and the audit trail has to be restricted to an authorized administrator. An important purpose of the audit data is to enable the monitoring of secure operation of the TOE. This includes the provision of means to detect impostor attempts and other attempts to undermine TOE security. The ST shall specify how this is achieved in the statement of TOE security functional requirements, including the use of automated tools or other diagnostic procedures and training. 173 174 O.ENROL.TOE The TOE shall enforce minimum standards on the quality of enrolment templates. 175 An insecure enrolment could facilitate an attack on a weak enrolment template. Good quality enrolments will also allow decision thresholds to be adjusted so as to provide better discrimination between false match and false non-match rates. The TOE shall prevent illicit individuals or errant software from bypassing TOE security policy enforcement, including by means of ‘piggy-back’ attacks. O.BYPASS 176 The preservation of template integrity is a defence against a bypass attack. For example, encryption and time-stamping of the signal between the capture device and the rest of the system may help to overcome a capture/replay attack. The TOE shall provide the means of detecting and rejecting forged authentication data. This includes forgery of biometric templates. The TOE shall limit TOE operator functions to those verified as operators by the TOE and shall provide functions for routine maintenance and emergency start-up/ shutdown. O.NOFORGE O.OPER Page 32 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T 177 Note that in order to achieve this objective the TOE will need to identify and authenticate operators of the TOE, but this need not be by means of the TOE’s biometric authentication mechanism. See also the note at paragraph 172 above. The TOE shall resist physical attack against those parts of the TOE that are critical to security. This shall include the following attacks (where not precluded by the TOE environment): a) b) c) physical modification or replacement of TOE components or connections between them, and surveillance of physical connections, and optical, acoustic, electromagnetic or other relevant noise flooding attacks. O.PHYS.TOE 178 This objective acts in conjunction with O.PHYS.ENV to provide an appropriate level of protection against physical attacks. In particular, O.PHYS.ENV may preclude or counter certain physical attacks from occurring, in which case there is no need for the TOE to defend itself against such attacks. The ST shall clarify the division of responsibility between the TOE and its environment for addressing physical attacks. Some flooding attacks will be dependent on the biometric type used, e.g. changing lighting for optical-based systems, or noise attacks against voice recognition systems. Other attacks will be independent of the biometric type, e.g. electromagnetic attacks or interruptions to the supply voltage. The TOE shall record necessary events to ensure that the information exists to support effective security management and shall ensure that all TOE users can subsequently be held accountable for their security relevant actions. 179 O.RECORD O.USERLIMIT The TOE and/or its environment shall prevent an unauthorised user from gaining access to the portal by making repeated attempts using one or more claimed IDs. 180 Identical objectives are defined for the TOE and its environment, in accordance with [CC1, B.2.5]. If the TOE does not provide this capability, measures must be taken in the environment to ensure this objective is met, e.g. by means of supervised access. The ST shall clarify the division of responsibility between the TOE and its environment for meeting this objective. 4.2 Security objectives for the environment O.ENROL.ENVThose responsible for the TOE shall ensure that enrolment is supervised by trained personnel capable of ensuring that the enrolment is of sufficient quality to maintain security. September 6, 2001 Page 33 of 72 Biometric Device Protection Profile D R A F T 181 Supervision of enrolment serves to reduce the risk of an insecure enrolment which could facilitate an easy attack on a weak enrolment template. Good quality enrolments will also allow decision thresholds to be adjusted so as to provide better discrimination between false match and false non-match rates. This objective also identifies the need for appropriate measures to be taken to authenticate the identity claimed by the enrolee, otherwise security will not be maintained. O.PHYS.ENV The environment for the TOE shall be such as to ensure that those parts of the TOE critical to security policy are protected from physical attack which might compromise IT security. 182 This security objective should be elaborated in the ST so that it is clear whether the environment precludes or counters any types of physical attack, or whether it is for the TOE to resist such attacks. The BDPP permits either possibility. Those responsible for the TOE shall ensure that the TOE is delivered, installed, managed, and operated in a manner which maintains IT security. In particular: a) b) c) d) Audit trails shall be examined regularly to identify unsuccessful impostor attempts. Acceptance thresholds should be checked regularly to ensure that the system is optimally tuned to maintain the required security levels. Backups of the database containing user security attributes (e.g. the enrolled templates database) shall be protected against unauthorised access. Entry to the portal shall be supervised where necessary. O.SECOP 183 If audit trails are not checked on a regular basis, impostors may be able to improve their attempts or find an ID for which they are accepted. Procedures for checking the appropriateness of decision thresholds governing false acceptance and false rejection will help to reduce the risk of casual impostor attack on weak IDs, and help to identify when it is necessary to re-enrol users. For example, checking the matching results of inter-template comparisons for enrolled users will give some indication of the false accept rate in the application. The mapping from threshold setting to false accept and false reject rates can vary considerably according to the user and impostor populations. Backups of the user security attributes database need protection so as to prevent attackers from circumventing the controls provided by the Biometric Device, e.g. by modifying the content of the database. Supervision of entry to the portal may be required to help prevent ‘piggy-back’ attacks. 184 185 186 Page 34 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T O.TRAIN Those responsible for the security of the organization shall provide initial and ongoing training for all individuals, not just administrators. This training should include security awareness of vulnerabilities. 187 Incompetence or inadequate training of administrative personnel could, for example, easily result in improperly set FAR/FRR values. O.USERLIMIT The TOE and/or its environment shall prevent an unauthorised user from gaining access to the portal by making repeated attempts using one or more claimed IDs. 188 Identical objectives are defined for both the TOE and its environment, in accordance with [CC1, B.2.5]. If the TOE does not provide this capability, measures must be taken in the environment to ensure this objective is met, e.g. by means of supervised access. The ST shall clarify the division of responsibility between the TOE and its environment for meeting this objective. O.USERTMPLIf biometric templates are supplied by the user (e.g. stored on a smartcard) then measures shall exist to provide the means to protect the integrity and guarantee the authenticity of the template. 189 This objective is needed to uphold the assumption A.USERTMPL as well as support O.NOFORGE by providing a means by which the Biometric Device can detect forgery of user-held biometric templates. Note that this objective also covers the need to protect the delivery path from enrolment to the end-user, for example covering: • • • delivery of the enrolment template (and other relevant user identification information) to the card production facility, maintenance of the integrity of the template and associated user information during card production, and delivery of the card to the end-user. September 6, 2001 Page 35 of 72 Biometric Device Protection Profile D R A F T 5. 190 IT security requirements This section identifies the Security Functional Requirements (SFRs) (Section 5.1) and the Security Assurance Requirements (SARs) (Section 5.2). 5.1 191 TOE security functional requirements This section identifies the SFRs for the TOE, i.e. requirements that will be realised by functions implemented in the TOE. These requirements are summarised in Table 1 (see [CC2]). Note that the term TSF (TOE Security Functions) used within this section refers to the trusted part of the TOE (see also section 1.6.3). Table 1. Biometric Device Functional Components Short Name FIA_AFL.1 FIA_ATD.1 FIA_UAU.2 FIA_UAU.3 FIA_UAU.7 FIA_UID.2 FMT_MOF.1 FMT_MTD.1 FMT_MTD.3 FMT_SMR.1 FAU_GEN.1 FAU_GEN.2 FAU_SAR.1 FAU_SAR.2 FAU_STG.2 FPT_AMT.1 FPT_ITT.1 FPT_ITT.3 FPT_PHP.3 Descriptive Name Multiple unsuccessful authentications User attribute definition User authentication before any action Unforgeable authentication Protected authentication feedback User identification before any action Class FMT: Security Management Management of security functions behaviour Management of TSF Data Secure TSF data Security Roles Class FAU: Security Audit Audit data generation User identity association Audit review Restricted audit review Guarantee of audit data availability Abstract machine testing Basic internal TSF data transfer protection TSF data integrity monitoring Resistance to physical attack Dependencies FIA_UAU.2 None FIA_UID.2 None FIA_UAU.2 None FMT_SMR.1 FMT_SMR.1 ADV_SPM.1, FMT_MTD.1 FIA_UID.1 FPT_STM.1 FAU_GEN.1, FIA_UID.1 FAU_GEN.1 FAU_SAR.1 FAU_GEN.1 None None FPT_ITT.1 None Class FIA: Identification and Authentication Class FPT: Protection of the TOE Security Functions Page 36 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T Table 1. Biometric Device Functional Components Short Name FPT_RCV.1 FPT_RPL.1 FPT_RVM.1 FPT_STM.1 FPT_TST.1 192 Descriptive Name Manual recovery Replay detection Reliable time stamps TSF testing Dependencies FPT_TST.1, AGD_ADM.1, ADV_SPM.1 None None FPT_AMT.1 Non-bypassability of the TOE Security Policy (TSP) None All SFRs are drawn from the standard set of functional components listed in CC Part 2 [CC2]. In certain cases these need interpretation to deal with particular characteristics of Biometric Devices and systems. Advice on interpretation is provided in the form of application notes where necessary. In cases where there are no application notes, the normal interpretation appropriate to IT system security functionality may be assumed. Application notes are aimed primarily at ST writers and TOE developers. The following types of operation (as explained in [CC2, 2.1.4]) are used in this PP to tailor the [CC2] functional components to express the SFRs: a) The assignment operation is used to assign a specific value to an unspecified parameter. Uncompleted assignment operations on functional components are indicated using the same notation as in [CC2], i.e. “[assignment: ... ]” indicates an assignment to be completed by the ST author. Completed assignment operations are indicated by italicised text. In some cases, an assignment operation has been partially completed within this PP: in these cases the completed parts are indicated by italicised text whilst the aspects requiring completion by the ST author are indicated using the notation for uncompleted operations. The selection operation is used to select one or more options permitted by [CC2]. Uncompleted selection operations are indicated using the same notation as in [CC2], i.e. “[selection: ... ]” indicates a selection to be completed by the ST author. Completed selection operations are indicated by italicised text. The refinement operation is used to add detail to a requirement, thereby restricting the set of possible implementation solutions. Refinement may also be used to add specific meaning or clarity to a [CC2] requirement. Refinement of a component is indicated by emboldened text. The iteration operation refers to the multiple use of the same [CC2] component to express different requirements, through the use of other operations to tailor it in different ways. Iteration of a component is indicated by the use of numbers in parentheses appended to the CC Part 2 component labels, e.g. FMT_MOF.1(2) indicates the second iteration of the FMT_MOF.1 component. 193 b) c) d) September 6, 2001 Page 37 of 72 Biometric Device Protection Profile D R A F T 5.1.1 194 Identification and Authentication The SFRs in this section address the primary objective of the Biometric Device, namely to authenticate the identity of an individual. Note that the term authentication applies to both identification and verification systems. The following SFRs are specified: a) b) c) d) e) identification and authentication of users (FIA_UID.2 and FIA_UAU.2) detection and prevention of forgery of biometric authentication data (FIA_UAU.3) limitations on the feedback provided to users whilst they are being authenticated (FIA_UAU.7) handling of successive authentication failures (FIA_AFL.1) definition of user security attributes (FIA_ATD.1). Authentication failures FIA_AFL.1.1 The TSF shall detect when [assignment: number specified by the ST writer] unsuccessful authentication attempts occur related to [assignment: biometric authentication events specified by the ST writer]. Application Notes 1 The threshold number of unsuccessful authentication attempts allowed before the TOE takes action shall be specified in the ST (details of what action the TOE takes are specified in FIA_AFL.1.2). It is permissible for the TOE to make no check for multiple attempts, provided this is clearly stated in the ST, which must also justify that the O.USERLIMIT security objective is met by the environment. In this case the first assignment may be set to “any” (i.e. the TOE detects single failures), and FIA_AFL.1.2 completed so as to state that the TOE takes no additional action on detecting a single failure (other than rejecting the authentication attempt, as it must in any case do in order to satisfy FIA_UAU.2). This will have the effect of reducing FIA_AFL.1 to a null requirement on the TOE. If the TOE is an identification system, the ST writer should complete the assignments so as to reduce the SFR to a null requirement on the TOE, as described above. For a verification system, there are a number of different circumstances which may constitute multiple unsuccessful authentication attempts. Firstly, when the same biometric template (as determined by the TOE within its threshold settings) is used to successively attack a single user identification. Secondly, when different biometric templates (as determined by the TOE within its threshold settings) are successively used to attack a single user identification. Thirdly, when the same biometric template (as determined by the TOE within its threshold settings) is successively used to attack different user identifications. Each or any of these conditions may be detected by the TOE and the number of unsuccessful authentication attempts allowed may be different for each circumstance. Not all TOEs may be able to distinguish or detect all the different circumstances listed. The ST shall state the conditions detected by the TOE in the second assignment. If the number of unsuccessful authentication attempts allowed varies according to each circumstance detected, it will be 2 3 4 Page 38 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T necessary to iterate FIA_AFL.1 in the ST for each such event. FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met or surpassed, the TSF shall block any further authentication attempts related to that user [assignment: until a defined time period has elapsed as specified by the ST writer]; and [assignment: perform any additional measures as specified by the ST writer]. Application Notes 1 This security functional requirement needs to be interpreted in the light of the circumstances which apply to FIA_AFL.1.1 previously. If the TOE does not detect multiple unsuccessful authentication attempts, then this should be indicated by completing the first assignment with “until the next authentication attempt”. This effectively reduces the SFR to a null requirement on the TOE. As with FIA_AFL.1.1 this should be clearly explained in the ST. If the TOE is an identification system, the ST writer should complete the assignments so as to reduce the SFR to a null requirement on the TOE, as described above. For a verification system, the various circumstances delineated previously need further clarification, possibly by iteration of FIA_AFL.1.2. In the circumstance that a single user identification is subject to repeated unsuccessful authentication attempts (using the same or different biometric templates), further attempts to authenticate against that user shall be blocked. In the case when the same biometric template (as determined by the TOE within its threshold settings) is presented for authentication against more than one user, that “rogue” biometric template should be blocked from further authentication attempts. The ST shall state the behaviour of the TOE under all relevant circumstances. The time period referred to in the first assignment will need clarification in the ST in the event that the TOE implements a more complex time-out scheme for the blocking of unsuccessful authentication attempts. The TOE may take additional measures when repeated unsuccessful authentication attempts occur, e.g. raising an alarm to an authorised administrator. These measures should be stated in the ST by completing the second assignment. If no additional measures are taken then an assignment of “none” should be indicated by deleting the second assignment and the preceding “and”. Under all circumstances auditing is to be performed in accordance with FAU requirements. If the TOE does not check for multiple authentication failures then the auditing requirement reduces to the need to record unsuccessful authentication attempts. Clarification may be required in the ST to specify the criteria for time-outs and blocking or reenabling of authentication attempts against users. 2 3 4 5 6 7 User attribute definition FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users: a) b) c) identifying name or number unique physical or behavioural characteristic role September 6, 2001 Page 39 of 72 Biometric Device Protection Profile D R A F T d) [assignment: any other attributes specific to the particular Biometric Device to be defined by the ST writer]. Application Notes 1 2 It is permissible for an assignment of “none” to be made to complete the assignment. In this case list item d) may be omitted for clarity in the ST. Note that this SFR only requires the TOE to be able to recognise the above security attributes and associate them with individual users. It does not mandate that the TOE stores these attributes. User authentication FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. Application Notes 1 Typically, authentication is a function provided by a TOE whose main purpose is some entirely different one (e.g. an office automation network, a numerical analysis system etc.). In this case however, authentication is assumed to be the prime purpose of the TOE. It is therefore conceivable that there are no functions provided for the user other than authentication, or the single function of controlling access to a facility which does not form part of the TOE itself. This SFR therefore expresses the prime objective of the TOE. This SFR applies to authentication of regular users, operators and administrators. If the TOE provides different or additional authentication mechanisms for operators and administrators, then the ST should additionally include FIA_UAU.5 to identify the different authentication mechanisms implemented by the TOE, and to specify the rules governing the use of these mechanisms. In a similar way, it may be necessary to include FIA_UAU.5 if multiple biometric authentication mechanisms are included in the TOE. 2 3 FIA_UAU.3.1 The TSF shall detect and prevent use of biometric authentication data that has been forged by any user of the TSF. Application Notes 1 In this context, forgery generally refers to the use of an artifact such that the biometric system is spoofed into accepting the artifact as coming from a live human being. It is not possible to make definitive statements on the potential for forging of biometric characteristics. Most biometric characteristics could, in principle, be forged given sufficient resources and justification. The ease or otherwise will depend on the nature of the biometric, the inherent characteristics of the biometric capture device and intentional countermeasures implemented in the TOE. For example, in a fingerprint biometric system, there may be some inherent rejection of an inanimate artifact due to the mode of operation of the finger reader (use of total internal reflection and the 3 dimensional property of a real finger pattern together with natural skin oil). The developer could also include measurements of temperature, surface conductivity and/or pulse to provide additional countermeasures to a fake (or disembodied) finger. All these would make it harder to produce a viable artifact but would not eliminate the possibility. The developer will need to provide information on countermeasures (inherent and intentional) to Page 40 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T forgery. The term ‘biometric authentication data’ also includes the biometric template, which may be supplied by the user, e.g. stored on a smartcard. In such cases the TOE is required to detect and prevent the use of a template forged by an impostor. This SFR does not explicitly require the ability to detect mimicry by an impostor, i.e. such attacks are not considered as ‘forgery’ of authentication data. Rather, these attacks are countered by the TOE meeting the FAR requirements in accordance with O.FARFRR. Evaluators should check with the appropriate evaluation authority for information on forgery vulnerabilities affecting specific biometric technologies and systems. 2 3 4 FIA_UAU.3.2 The TSF shall detect and prevent use of biometric authentication data that has been copied from any other user of the TSF. Application Notes 1 This SFR may overlap in some instances with FIA_UAU.3.1 in the case of biometric systems. The production of a forgery may also involve copying the biometric characteristics of an authorised user of a system (for example, lifting a latent fingerprint from a glass). Most biometric characteristics are not secret and may therefore be vulnerable to being copied. There will be varying degrees of difficulty involved. For example it may be hard to copy a retinal pattern. This form of copying requires the use of a forgery to exploit the copy. Replay attacks are not covered by this SFR: FPT_RPL.1 addresses this form of attack. This SFR does not explicitly require the ability to detect mimicry by an impostor, i.e. such attacks are not considered as ‘copying’ of authentication data. Rather, these attacks are countered by the TOE meeting the FAR requirements in accordance with O.FARFRR. 2 3 FIA_UAU.7.1 The TSF shall provide only [assignment: feedback which does not assist an impostor in making subsequent verification attempts] to the user while the biometric authentication is in progress. Application Notes 1 This SFR means that the Biometric Device must not inform the user of any “score” against the threshold that might help the attacker to fool the device in subsequent verification attempts. Notification of the result of the attempt, or presenting the supplied biometric image to the user, is considered to be permitted feedback. User identification FIA_UID.2.1 The TSF shall require each user to identify itself before allowing any other TSFmediated actions on behalf of that user. Application Notes 1 This SFR is one that needs special interpretation in the context of biometric systems. For this consideration, biometric systems can be considered to divide into 2 broad categories, identification and verification. Verification is where a user makes a claim to be a specific individual and the system authenticates the claimant against the claim. This is analogous to the userid/password authentication in an IT system. Identification is where a user makes no September 6, 2001 Page 41 of 72 Biometric Device Protection Profile D R A F T specific claim of identity and the system has to determine who the individual is, or more generally whether the individual is known to the system. Verification systems are more common than identification systems but both types are used. If the TOE is of the verification type, then this SFR has the standard interpretation as for an IT password system. A specific claim of identity must be made before any further action is taken by the TOE (probably the next action after the user provides identification will be authentication). Note that this SFR applies to regular users, operators and administrators. See also application note 2 under FIA_UAU.2 above. If the TOE is of the identification type, then this SFR has no real meaning in the normal sense. The “identification” action by the user is reduced to presenting the user’s biometric to the TOE. The TOE is responsible for the identification and authentication activities in this case. 2 3 5.1.2 195 Security Management Requirements The SFRs in this section identify requirements for the management of the security of the Biometric Device by authorised administrators and operators. These cover the following aspects: a) b) c) d) e) configuration of the security parameters which affect the operation of the Biometric Device (FMT_MTD.1(1)) management of the enrolment of users (FMT_MTD.3) and user security attributes, including biometric templates (FMT_MTD.1(2)) management of the audit functions (FMT_MOF.1(1)) and audit trail (FMT_MTD.1(3)) management of maintenance and recovery functions (FMT_MOF.1(2) and FMT_MOF.1(3)) maintenance of the roles of administrator, operator and regular user (FMT_SMR.1). 196 Note that the term TSF Data refers to data used by the TOE Security Functions to enforce security. This includes such data as security parameters, biometric templates, and other user security attributes. Management of functions in TSF FMT_MOF.1.1(1) The TSF shall restrict the ability to determine the behaviour of, disable, enable, or modify the behaviour of the audit mechanism to administrators. Application Notes 1 FMT_MOF.1.1(2) This is the same requirement as for normal IT system audit logs and trails. The TSF shall restrict the ability to enable and disable the functions to perform routine maintenance and emergency start-up/shutdown to operators. Page 42 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T FMT_MOF.1.1(3) The TSF shall restrict the ability to enable the functions to restore the TOE to a secure state from maintenance mode to administrators and operators. Application Notes 1 This SFR refers to the functions covered by FPT_RCV.2.1. Management of TSF data FMT_MTD.1.1(1) The TSF shall restrict the ability to modify the [assignment: list of security parameters which control the performance of the biometric system] to administrators. Application Notes 1 The performance of a biometric system, in particular its security performance, is critically dependent of the adjustment of system parameters, typically threshold values for acceptance or rejection of user authentication attempts. The activity must be restricted to trusted staff (denoted as administrators here) and the TOE must enforce this restriction. Otherwise the system security will be compromised. FMT_MTD.1.1(2) The TSF shall restrict the ability to initialize, query, modify, delete, or clear the user security attributes, i.e., identifying name or number, role, [selection: unique physical or behavioural characteristic, [assignment: any other user security attributes specific to the particular Biometric Device to be defined by the ST writer]] to administrators. Application Notes 1 Administering the enrolled user database is analogous with administering the user account information in a conventional IT system. In a biometric system, in addition to standard information on users, there will be processes which enrol users on the system and remove them from the system as required by the system security policy and, possibly, a database of biometric images for enrolled users. Users must not be allowed to enrol themselves on the system since the system security is totally dependent on the integrity of the enrolment data. These activities must be restricted to authorised administrators and the TOE must impose the restriction. Note that there may be more than one type of administrator, e.g. template administration might be restricted to a subset of administrators. The (partially completed) operations are to be completed in the ST. Firstly, the assignment must be completed to list any additional user security attributes included under FIA_ATD.1.1 (“none” is a valid assignment here). Then the selection must be completed as follows: the first item must be selected if biometric templates are stored within the TOE; and the second item must be selected if additional user security attributes have been listed, or if biometric templates are not stored by the TOE (note that both items may be selected if appropriate). 2 FMT_MTD.1.1(3) The TSF shall restrict the ability to initialize, query, modify, delete, or clear the audit trail to administrators. The TSF shall ensure that only secure values are accepted for enrolled biometric templates. FMT_MTD.3.1 September 6, 2001 Page 43 of 72 Biometric Device Protection Profile D R A F T Application Notes 1 In a biometric system, the level of security achieved is known to be dependent on the quality of the enrolled biometric templates. If a poor enrolment is allowed (typically one with few or poorly defined features or out of focus), then that user may be open to easy attack by an impostor. In this context a “secure value” for an enrolled biometric template means “an acceptable level of quality”. It is not generally possible for the administrator to make a human judgement of the quality of an enrolment. Therefore the TOE must be able to assess the quality of the enrolment template and provide means by which poor enrolments can be eliminated. This may be an automatic function of the TOE in rejecting poor quality enrolments; alternatively the TOE may provide an indication of enrolment quality to the administrator, allowing the administrator to reject the enrolment. In this case “secure value” is interpreted to mean “a level of enrolment quality explicitly accepted by an administrator for the individual in question”. The role of the administrator in this regard must be clearly stated in the ST. There may be a trade-off between enrolment quality and other factors such as usability. For example, enforcement of a high enrolment quality may exclude certain individuals from enrolment on a system. Therefore enrolment quality standards should be commensurate with the security requirements for the application. This means that there will generally be a requirement that the TOE allows adjustment by the administrator of the acceptance level standard for user enrolment. The system security policy may specify system-wide standards for enrolment quality but might allow deviations to accommodate individual cases of difficulty (i.e. where it is deemed necessary to enrol an individual who is unable to satisfy the normal acceptance standard for enrolment quality). Note however that this would introduce a potential vulnerability in the security of the system. 2 3 Security management roles FMT_SMR.1.1 The TSF shall maintain the roles: regular users, administrators, operators. Application Notes 1 See section 1.6.3 for a definition of the three roles. Note that it is permissible for a TOE to maintain more than one type of administrator role, e.g. to separate the template administration function from general system administration functions. FMT_SMR.1.2 The TSF shall be able to associate users with roles. 5.1.3 197 Security Audit Requirements This section specifies requirements for the auditing of security relevant events, covering the: a) b) c) specification of events that are to be auditable (FAU_GEN.1) association of events with the user responsible (FAU_GEN.2) review and protection of the audit trail (FAU_SAR.1, FAU_SAR.2 and FAU_STG.2). Page 44 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T Security audit data generation FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: a) Start-up and shutdown of the audit functions. b) c) All auditable events as defined in Table 2; and [assignment: other auditable events specific to the particular Biometric Device]. Table 2. Biometric Device Auditable Events Component FIA_AFL.1 Auditable event Class FIA: Identification and Authentication The reaching of the threshold for the unsuccessful authen- tication attempts and the actions (e.g. disabling of a terminal) taken and the subsequent, if appropriate, restoration to the normal state (e.g. re-enabling of a terminal). All use of the authentication mechanism All immediate measures taken All use of the user identification mechanism - Additional information FIA_UAU.2 FIA_UAU.3 FIA_UID.2 FMT_MOF.1 FMT_MTD.1 FMT_MTD.3 FMT_SMR.1 FPT_AMT.1 FPT_ITT.3 FPT_RCV.1 Results of checks on the fraudulent data User identity provided Results of the tests Type of failure or service discontinuity Results of the tests Class FMT: Security Management All modifications in the behaviour of the functions in the TSF All modifications to the values of TSF data All rejected values of enrolled biometric templates Modifications to the group of users that are part of a role Execution of the tests of the underlying machine The action taken following detection of an integrity error The fact that a failure or service discontinuity occurred Resumption of regular operation FPT_RPL.1 FPT_STM.1 FPT_TST.1 Detected replay attacks Changes to the time Execution of the TSF self tests Application Notes 1 A list of any additional auditable events shall be stated in the ST by completing the assignment. An assignment of “none” is permissible, in which case paragraph c) should be omitted for the purposes of clarity. Class FPT: Protection of the Trusted Security Functions September 6, 2001 Page 45 of 72 Biometric Device Protection Profile D R A F T 2 For FMT_MTD.3, the interpretation of the audit requirement is that the audit record must indicate the reason for rejection of a template. Note that successful enrolment is covered by the audit requirement for FMT_MTD.1. The level of audit selected is “not specified” (see the definition of FAU_GEN.1 in [CC2]). 3 FAU_GEN.1.2 The TSF shall record within each audit record at least the following information: a) b) Date and time of the event, type of event, individual identity, and outcome (success or failure) of the event; and For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, additional information as defined in Table 2 and [assignment: other audit relevant information specific to the particular Biometric Device]. Application Notes 1 In some cases, the TOE may not be able to identify the individual identity associated with an event. For example, if the individual is not enrolled in the system, then the TOE can only record the event with an “unknown” identification. Therefore this requirement should be interpreted as “when the individual is known to the TOE”. Any additional audit relevant information shall be stated in the ST by completing the assignment. An assignment of “none” is permissible. 2 FAU_GEN.2.1 The TSF shall be able to associate each auditable event with the identity of the user that caused the event. Security audit review FAU_SAR.1.1 The TSF shall provide authorised administrators with the capability to read audit information from the audit records. The TSF shall provide the audit records in a manner suitable for the user to interpret the information. The TSF shall prohibit all users read access to the audit records, except those users that have been granted explicit read-access. FAU_SAR.1.2 FAU_SAR.2.1 Security audit event storage FAU_STG.2.1 FAU_STG.2.2 FAU_STG.2.3 The TSF shall protect the stored audit records from unauthorised deletion. The TSF shall be able to prevent modifications to the audit records. The TSF shall ensure that [assignment: metric for saving audit records] audit records will be maintained when the following conditions occur: audit storage exhaustion, failure or attack. Page 46 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T Application Notes 1 The metric for saving audit records shall be stated in the ST by completing the assignment. No minimum value is mandated by this PP (except that “none” is not a valid assignment), providing the metric specified can be justified as sufficient to satisfy the O.RECORD security objective. 5.1.4 198 Protection of the TOE Security Functions This section specifies requirements to protect the integrity and availability of the Biometric Device security functions and the data on which they rely. These cover the following aspects: a) b) c) d) e) f) g) provision of diagnostic test facilities for the Biometric Device software and data (FPT_TST.1) and for the underlying hardware or firmware (FPT_AMT.1). protection of the confidentiality and integrity of data transmitted between different parts of the Biometric Device (FPT_ITT.1 and FPT_ITT.3) tamper resistance (FPT_PHP.3) trusted recovery (FPT_RCV.1) prevention of replay attacks (FPT_RPL.1) prevention of bypass attacks (FPT_RVM.1) provision of trusted time stamps in support of auditing (FPT_STM.1). Underlying abstract machine test FPT_AMT.1.1 The TSF shall run a suite of tests at the request of an administrator or operator to demonstrate the correct operation of the security assumptions provided by the abstract machine that underlies the TSF. Application Notes 1 The term “underlying abstract machine” typically refers to the hardware components upon which the TSF has been implemented. However, the phrase can also be used to refer to an underlying, previously evaluated hardware and software combination behaving as a virtual machine upon which the TSF relies [CC2, J.1]. Internal TOE TSF data transfer FPT_ITT.1.1 The TSF shall protect TSF data from disclosure when it is transmitted between separate parts of the TOE. September 6, 2001 Page 47 of 72 Biometric Device Protection Profile D R A F T Application Notes 1 In a biometric system, data flow security includes issues of confidentiality, integrity and availability. A breach of data flow security could lead to unauthorised individuals being authenticated or authorised users failing to be authenticated. This SFR deals with the confidentiality issues of data flow. One major transmission of data in a biometrics system takes place between the biometric capture device and the recognition component. These components may be separated by an physically open channel in the form of a cable or possibly a remote network connection. The possibility of monitoring the data flow between the capture device and the recognition component must be considered as a potential area of vulnerability and the evaluators will be concerned to assess the means by which the TOE protects the data. Protective measures might include physical protection of the data path, detection of attempted monitoring and data encryption. A second major data flow comprises the communication of the result of the authentication process to the component which actions the result. An attack mounted on this path could bypass the authentication process altogether. The ST will specify the scope of the TOE and will determine whether and how much of this path is included in the TOE. A third major data flow occurs between the activating component and the component being activated. This marks the final stage in the access control process (for example in a door entry system it would correspond to the signal which opens or locks the door). This path is likely to be within the scope of the ST for a system evaluation but may not be for a product evaluation. Other, internal, data flows will likely exist and should be considered as potential points of vulnerability which should be considered in the same way as for any IT system handling sensitive data. 2 3 4 5 FPT_ITT.3.1 The TSF shall be able to detect modification of data for TSF data transmitted between separate parts of the TOE. Application Notes 1 2 This SFR deals with the integrity issues of data flow between components of the TOE. The notes addressing confidentiality previously are also applicable to the data integrity issues. The aspect of data integrity covered here seems to be directed towards compromise caused by deliberate attack. However, other forms of integrity compromise may occur, for example through hardware malfunction, or by external sources of signal interference. Biometric capture devices are well known to be sensitive to environmental conditions. Typically, stray light or noise (depending on the technology involved) can have a major effect on system performance. This is a data quality issue which impacts on data integrity at the source, i.e. in the path between the user and the capture device. Typically, the TOE will not be able to detect data integrity problems on this path caused by stray illumination or noise and this SFR will need further exploration through functional testing. Stray light or noise can also have an adverse impact on the quality of enrolment. 3 FPT_ITT.3.2 Upon detection of a data integrity error, the TSF shall take the following actions: notify operators and audit event. Page 48 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T TSF physical protection FPT_PHP.3.1(1) The TSF shall resist physical modification, alteration, replacement or other physical attack to the [assignment: elements of the Biometric Device not protected by physical measures deployed in the TOE environment] by responding automatically such that the TSP is not violated. Application Notes 1 The assignment is to be completed by listing those parts of the Biometric Device not protected by the TOE environment (in accordance with O.PHYS.TOE), such as the capture device, the comparator, the connection between the capture device and the comparator, and the connection between the comparator and the portal. FPT_PHP.3.1(2) The TSF shall resist [assignment: list of electromagnetic or other relevant noise flooding attacks that may be mounted within the TOE environment] to the Biometric Device or its connections by responding automatically such that the TSP is not violated. Application Notes 1 It is acceptable for the TOE not to include functionality to resist such physical attacks, provided such attacks are prevented by measures taken within the TOE environment (this is the intention of the qualification ‘that may be mounted within the TOE environment’). This must be made clear in the ST by listing the relevant attacks that the TOE must resist. Trusted recovery FPT_RCV.1.1 After a failure or service discontinuity, the TSF shall enter a maintenance mode where the ability to return the TOE to a secure state is provided. Application Notes 1 If the TOE provides automated recovery procedures for certain types of failures or service discontinuities then FPT_RCV.2 (or FPT_RCV.3) should be specified in the ST. A TOE that meets FPT_RCV.2 or FPT_RCV.3 also satisfies the FPT_RCV.1 requirements and hence is conformant with the BDPP. Replay detection FPT_RPL.1.1 The TSF shall detect replay for the following entities: biometric authentication data. Application Notes 1 If the connection between the biometric capture device and the authentication component can be intercepted, it may be possible to capture the data produced by the capture device and to later replay the data to the authentication component to effect a breach of security. The developer will need to indicate the countermeasures implemented by the TOE to resist this type of attack. September 6, 2001 Page 49 of 72 Biometric Device Protection Profile D R A F T FPT_RPL.1.2 The TSF shall ignore the replayed authentication data when replay is detected. Reference mediation FPT_RVM.1.1 The TSF shall ensure that TSP enforcement functions are invoked and succeed before each function within the TSC is allowed to proceed. Application Notes 1 Only one individual at a time can be verified for a single characteristic scan, i.e., two or more individuals cannot gain entry to the portal from a single input. The interval between input for two individuals must be sufficiently small that it is not possible for two individuals to enter on one scan. For example, a face recognition system might be used to verify that the individual using a keyboard remains the same person who was originally verified. The scanning device might be mounted on the monitor and will scan the individual’s face periodically. If the scan interval is too large, it would be possible for an illicit individual, in concert with the verified individual, to access the keyboard. The portal must close after a single individual enters and before the next input is accepted for verification; only one individual may enter at a time. 2 Time stamps FPT_STM.1.1 The TSF shall be able to provide reliable time stamps for its own use. TSF self-test FPT_TST.1.1 The TSF shall run a suite of self tests at the request of the authorized administrator or operator to demonstrate the correct operation of the TSF. The TSF shall provide authorised administrators with the capability to verify the integrity of TSF data. The TSF shall provide authorised administrators with the capability to verify the integrity of stored TSF executable code. FPT_TST.1.2 FPT_TST.1.3 5.2 199 TOE security assurance requirements This PP is intended for use with commercial Biometric Devices which are deemed certifiable within the range of assurance levels from EAL1+ (EAL1 augmented) to EAL4. Intending users of certified biometric products must ensure that the assurance level achieved meets the requirements of their system security policies and/or accreditation standards. For example, in some cases it may be necessary to augment EAL4 with either AVA_VLA.3 or AVA_VLA.4 if there is a requirement for protection against attacks who have either a moderate or high attack potential. Page 50 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T 200 For convenience, the table below summarises the assurance components for the evaluation assurance levels covered by this PP. Table 3. Evaluation Assurance Levels Assurance Class Assurance Components ACM_CAP Configuration management capabilities ACM_SCP Configuration management scope EAL1+ EAL 2 EAL 3 EAL4 1 1 2 1 1 1 1 1 1 3 1 1 1 1 2 4 2 2 1 2 2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 1 1 2 1 1 2 1 1 1 2 1 1 2 2 1 2 Configuration Management ACM_AUT Configuration management automation Delivery and Operation Development ADO_DEL Delivery ADO_IGS Installation, generation, and start-up ADV_FSP Functional specification ADV_HLD High-level design ADV_IMP Implementation representation ADV_LLD Low-level design ADV_RCR Representation correspondence ADV_SPM Security policy modelling Guidance documents Life cycle support AGD_ADM Administrator guidance AGD_USR User guidance ALC_DVS Development security ALC_LCD Life-cycle definition ALC_TAT Tools and techniques Tests ATE_COV Coverage ATE_DPT Depth ATE_FUN Functional tests ATE_IND Independent testing Vulnerability Assessment AVA_MSU Misuse AVA_SOF Strength of TOE security functions AVA_VLA Vulnerability analysis 5.3 5.3.1 201 Strength of TOE Security Function Requirements Minimum Strength of Function (SOF) Rating The minimum SOF rating shall be in accordance with the specified national or international standards for the specified assurance level, and shall be at least: a) b) SOF-basic at EAL1+ to EAL3; SOF-medium at EAL4. September 6, 2001 Page 51 of 72 Biometric Device Protection Profile D R A F T 202 In the event that the TOE provides multiple authentication mechanisms, the minimum SOF rating shall apply to all such mechanisms. Explicit SOF Metrics The following requirements only apply to the biometric authentication mechanism(s) implemented by the TOE. The biometric authentication mechanism, which implements the FIA_UAU.2 requirement, shall satisfy the relevant national or international standards for False Acceptance Rates and False Rejection Rates for the required assurance level (in accordance with the OSP P.FARFRR and the corresponding security objective O.FARFRR). The SOF analysis will need to be based mainly on a statistical testing approach to confirm that the FAR and FRR requirements are met by the biometric authentication mechanism. 5.3.2 203 204 205 5.4 206 207 Security Requirements for the IT Environment There are no security requirements that must be satisfied by the IT environment. However, this does not preclude such security requirements being identified in the ST, in particular to satisfy O.USERTMPL in the event that biometric templates are provided by the user. For example, FDP_DAU.2 together with FCS_COP.1 may need to be defined as requirements on the IT environment to mandate digital signature functionality to sign user templates on enrolment. In such cases the security assurance requirements shall be at least equal to the security assurance requirements for the TOE. Additionally, in such cases there will be a need to establish assurance in the delivery path by which the enrolment template is delivered to the end-user, by inclusion of an assurance component from the ADO_DEL family in the set of security assurance requirements. (Note that ADO_DEL components are included in EAL2 to EAL4, but not in EAL1+.) 208 Page 52 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T 6. 6.1 209 Rationale Security objectives rationale This section demonstrates that the security objectives identified in Section 4 are traceable to all aspects of the TOE security environment described in Section 3. These objectives are suitable to cover all aspects of the identified environment. Table 4 below summarises the mapping from the security objectives to each of the identified threats, OSPs and assumptions, in tabular form. This is then followed by a rationale which justifies the suitability of the security objectives. Table 4. Mapping of security objectives to the TOE security environment Security Environment Threats T.CASUAL TOE Security Objectives O.FARFRR, O.FEEDBACK, O.ADMIN, O.ENROL.TOE, O.USERLIMIT O.FARFRR, O.FEEDBACK, O.ADMIN, O.ENROL.TOE O.FARFRR, O.FEEDBACK, O.NOFORGE, O.ADMIN, O.ENROL.TOE O.FARFRR, O.FEEDBACK, O.ADMIN, O.ENROL.TOE O.FARFRR, O.FEEDBACK, O.ADMIN, O.ENROL.TOE O.FARFRR, O.FEEDBACK, O.NOFORGE O.FARFRR, O.FEEDBACK, O.ENROL.TOE O.NOFORGE O.ADMIN O.ADMIN, O.OPER O.RECORD O.ADMIN, O.RECORD O.BYPASS, O.NOFORGE O.ADMIN O.RECORD, O.ADMIN O.ADMIN, O.OPER Environment Security Objectives O.SECOP, O.ENROL.ENV, O.USERLIMIT O.SECOP, O.USERTMPL, O.ENROL.ENV O.SECOP, O.USERTMPL, O.ENROL.ENV O.TRAIN, O.ENROL.ENV O.SECOP, O.USERTMPL, O.ENROL.ENV O.SECOP, O.ENROL.ENV O.ENROL.ENV O.USERTMPL O.SECOP, O.TRAIN, O.ENROL.ENV O.SECOP, O.TRAIN O.SECOP, O.TRAIN O.SECOP, O.TRAIN O.SECOP, O.TRAIN O.SECOP, O.TRAIN O.SECOP T.MIMIC T.ARTIFACT T.WEAKID T.EVILTWIN T.RESIDUAL T.POORIMG T.FAKETMPL T.ILLENROL T.BADUSER T.BADADM T.BADOPER T.BYPASS T.CORRUPT T.UNDETECT T.POWER September 6, 2001 Page 53 of 72 Biometric Device Protection Profile D R A F T Table 4. Mapping of security objectives to the TOE security environment Security Environment T.NOISE T.TAMPER P.FARFRR P.TRAIN P.USERLIMIT Assumptions A.PORTAL A.ROLES A.NO_EVIL A.USERTMPL O.ADMIN, O.OPER O.TRAIN O.TRAIN O.USERTMPL TOE Security Objectives O.PHYS.TOE O.PHYS.TOE O.FARFRR, O.ENROL.TOE O.USERLIMIT Environment Security Objectives O.PHYS.ENV O.PHYS.ENV O.ENROL.ENV O.TRAIN O.USERLIMIT Organisational Security Policies 6.1.1 210 Threats are countered by the security objectives It should be noted that, in addition to the mappings provided above, it may be considered that O.RECORD helps to counter the threat of impersonation attacks such as T.CASUAL, T.MIMIC, and so on (see section 3.2.1). This is because O.RECORD provides a deterrent to attackers by recording security relevant events, thereby increasing the likelihood that an attacker will be caught. O.RECORD is supported in this by O.SECOP, which ensures that the audit trail will be analysed on a regular basis. However, O.RECORD has not been mapped to all of the impersonation threats, firstly to simplify the rationale, and secondly because the issue of repeated attack is the subject of a separate threat, namely T.UNDETECTED. T.CASUAL rationale 211 The threat of a zero-effort attempt is countered by the following security objectives: a) O.FARFRR ensures that the risk of an impostor making a successful zero-effort attempt is set to an appropriate level as determined by the relevant national or international standards for false acceptance rates. This limits the chance of successful attack. O.FEEDBACK supports O.FARFRR by ensuring that any feedback provided to the user cannot be exploited by an impostor to defeat the biometric authentication mechanism. O.ENROL.TOE and O.ENROL.ENV reduce the risk of a successful zero-effort attempt by upholding the quality of enrolment templates. O.ADMIN supports the TOE security objectives by ensuring that the TOE is in a secure state. b) c) Page 54 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T d) e) O.SECOP reduces the risk of successful attack by ensuring that administrators will regularly check threshold settings which govern the FAR. O.USERLIMIT limits the ability of impostors to make repeated unchallenged attempts to gain access to the portal. This reduces the chance that a zero-effort attempt will be successful. This objective is achieved by the TOE and/or its environment. T.MIMIC rationale 212 The threat of an impostor reproducing biometric characteristics by mimicry is countered by the following security objectives: a) O.FARFRR addresses the threat that an impostor will be able to successfully reproduce the biometric characteristics of an authorised user through mimicry, by ensuring that the TOE complies with the appropriate national or international standards for false acceptance rates. A TOE that meets the O.FARFRR objective will thus reduce, to an acceptable level, the risk that an impostor will be able to achieve sufficient similarity to the biometric characteristics of an authorised user. O.FEEDBACK supports O.FARFRR by ensuring that any feedback provided to the user cannot be exploited by an impostor to defeat the biometric authentication mechanism. O.ENROL.TOE and O.ENROL.ENV reduce the risk of a successful attack by mimicry by upholding the quality of enrolment templates. O.ADMIN prevents impostors from gaining access to biometric templates stored on the system, and thus reduces the risk that impostors will be able to practice mimicry of the biometric characteristic. In a similar way, O.SECOP and O.USERTMPL reduce the risk of an attacker gaining access to biometric templates that are not stored on the biometric system, with a view to executing a successful mimicry attack. O.SECOP ensures that impostors cannot access any backups of the enrolled templates database. O.USERTMPL ensures that there are appropriate measures to control access to biometric templates that are user-held, e.g. stored on a smartcard. b) c) d) T.ARTIFACT rationale 213 The threat of use of an artifact is countered by the following security objectives: a) O.NOFORGE reduces the risk of successful attack based on the use of an artifact, by ensuring that the TOE can detect and prevent the use of forged authentication data, such as an artifact with an equivalent biometric template to that of an authorised user. O.FARFRR ensures that the FAR and FRR are appropriate, thus reducing the risk of successful attack by use of an artifact. O.FEEDBACK supports b) September 6, 2001 Page 55 of 72 Biometric Device Protection Profile D R A F T O.FARFRR by ensuring that any feedback provided to the user cannot be exploited by an impostor to defeat the biometric authentication mechanism. c) d) O.ENROL.TOE and O.ENROL.ENV reduce the risk of a successful attack by use of an artifact by upholding the quality of enrolment templates. O.ADMIN prevents impostors from gaining access to biometric templates stored on the system, and thus reduces the risk that impostors will be able to produce an artifact with an equivalent biometric template. In a similar way, O.SECOP and O.USERTMPL reduce the risk of an attacker being able to access biometric templates that are not stored on the biometric system, with the intent of producing an artifact with an equivalent biometric template. O.SECOP ensures that impostors cannot access any backups of the enrolled templates database. O.USERTMPL ensures that there are appropriate measures to control access to biometric templates that are user-held, e.g. stored on a smartcard. e) T.WEAKID rationale 214 The threat of attack against a weak ID is countered by the following security objectives: a) O.FARFRR reduces the general risk of weak IDs, by ensuring that the TOE complies with the appropriate national or international standards for false acceptance rates. However, this does not remove entirely the possibility that there will be individuals that have a high FAR. O.FEEDBACK supports O.FARFRR by ensuring that any feedback provided to the user cannot be exploited by an impostor to defeat the biometric authentication mechanism. O.ADMIN reduces the risk that an impostor will be able to discover weak IDs, by restricting the ability to access the relevant information (e.g. as stored in the enrolled templates database) to administrators. O.ENROL.TOE and O.ENROL.ENV reduce the risk of an insecure enrolment which might facilitate attack against weak enrolment templates. O.TRAIN reduces the risk of enrolee collusion that might enable an impostor to discover which are the weak IDs, by providing for appropriate security awareness training. b) c) d) T.EVILTWIN rationale 215 The threat of attack against a similar or twinned ID is countered by the following security objectives: a) O.FARFRR reduces the risk that the TOE will confuse two individuals, by ensuring that the TOE complies with the appropriate national or international standards for false acceptance rates. A TOE that meets the O.FARFRR objective will thus limit the number of pairs of individuals that are Page 56 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T indistinguishable by the TOE to an acceptable level, and thereby limit the scope for successful attack by an impostor. O.FEEDBACK supports O.FARFRR by ensuring that any feedback provided to the user cannot be exploited by an impostor to defeat the biometric authentication mechanism. b) O.ADMIN reduces the risk that an impostor will be able to discover which enrolee(s) they best match by restricting the ability to access the relevant information (e.g. as stored in the enrolled templates database) to administrators. This will prevent an impostor from being able to performing inter-template comparisons. In a similar way, O.SECOP and O.USERTMPL reduce the risk of an attacker discovering which enrolee(s) they best match as a result of being able to access biometric templates that are not stored on the biometric system. O.SECOP ensures that impostors cannot access any backups of the enrolled templates database. O.USERTMPL ensures that there are appropriate measures to control access to biometric templates that are user-held, e.g. stored on a smartcard. O.ENROL.TOE and O.ENROL.ENV uphold the quality of enrolled templates, and hence support the TOE in differentiating similar templates. c) d) T.RESIDUAL rationale 216 The threat of use of a residual image is countered by the following security objectives: a) O.FARFRR reduces the risk that the TOE contains flaws in its design, implementation or operation that would make it vulnerable to exploitation of residual images, thus affording illegal entry to the portal. O.FEEDBACK supports O.FARFRR by ensuring that any feedback provided to the user cannot be exploited by an impostor to defeat the biometric authentication mechanism. O.NOFORGE reduces the risk of successful use of biometric templates based on a residual image. O.SECOP reduces the risk of residual biometric templates through requiring procedures governing secure operation of the TOE, which should include regular cleaning of the capture device/sensor. O.ENROL.ENV upholds the quality of enrolled templates, and hence supports the TOE in differentiating similar templates. b) c) d) T.POORIMG rationale 217 The threat of attack directed against a noisy or null image is countered by the following security objectives: a) O.FARFRR ensures that the TOE complies with the appropriate national or international standards for false acceptance rates. A TOE that meets the O.FARFRR objective is less likely to have such weaknesses than one that does September 6, 2001 Page 57 of 72 Biometric Device Protection Profile D R A F T not meet the objective. O.FEEDBACK supports O.FARFRR by ensuring that any feedback provided to the user cannot be exploited by an impostor to defeat the biometric authentication mechanism. b) O.ENROL.TOE and O.ENROL.ENV uphold the quality of enrolled templates, and thereby reduce the risk of noisy or null images being accepted during enrolment. T.FAKETMPL rationale 218 The threat of forgery of a user-held template is countered by the following security objectives: a) b) O.NOFORGE ensures that the TOE has the capability to detect (and thus prevent) use of a forged biometric template. O.USERTMPL ensures that measures exist to provide the means of verifying the authenticity and integrity of user-held templates. T.ILLENROL rationale 219 The threat of illegal enrollment of an impostor is countered by the following security objectives: a) O.ADMIN and O.SECOP prevent impostors from illegally adding their own biometric templates to the enrolled templates database if stored on the system. O.ADMIN ensures that only administrators are able to modify the enrolled templates database stored on the system. O.SECOP similarly prevents impostors from gaining unauthorised access to backups of the enrolled templates database. O.ENROL.ENV and O.TRAIN reduce the risk of security procedure error that might lead to illegal enrolment, by ensuring that enrolment is supervised by appropriately trained staff. (According to A.NO_EVIL there is no threat of administrators illegally enrolling an impostor deliberately.) O.ENROL.ENV includes the need to establish the credentials of users who are to be enrolled in the biometric system. b) T.BADUSER rationale 220 The threat of a user attempting to exceed their authority is countered by the following security objectives: a) b) O.ADMIN prevents regular users from performing administrative functions, such as modifying the parameters of individual users. O.OPER prevents regular users from performing privileged operator functions that could compromise the Biometric Device. Page 58 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T c) d) O.SECOP reduces the risk that a regular user will be incorrectly granted administrative rights. O.TRAIN reduces the risk that users will attempt to exceed their authority by providing regular users with security awareness training. T.BADADM rationale 221 The threat of an administrator unintentionally misusing their authority is countered by the following security objectives: a) O.RECORD, which records security relevant events that might indicate unintentional misuse of authority by an administrator. This is supported by O.SECOP which ensures that the audit trail is analysed on a regular basis, and hence that such instances of misuse can be detected. O.TRAIN, which provides administrators with appropriate security awareness training. b) 222 It should be noted that, according to A.NO_EVIL, there is no threat of administrators deliberately misusing their authority. The security objectives described above would not prove effective against such threats, since hostile administrators can always ‘cover their tracks’, and cannot (by definition) be relied upon to follow defined security procedures. T.BADOPER rationale 223 The threat of an operator compromising the Biometric Device is countered by the following security objectives: a) b) c) d) O.ADMIN prevents operators from performing administrative functions, and thus limit the ability of operators to compromise the Biometric Device. O.RECORD provides the capability to record security relevant events that might indicate potential compromise of the Biometric Device. O.SECOP reduces the risk that an operator will be incorrectly granted administrative rights. O.TRAIN reduces the risk that operators will intentionally or unintentionally compromise the Biometric Device by providing such individuals with appropriate security awareness training. September 6, 2001 Page 59 of 72 Biometric Device Protection Profile D R A F T T.BYPASS rationale 224 The threat of bypass of the biometric capture device is countered by O.BYPASS which prevents such bypassing attacks from being successful. a) b) c) d) O.BYPASS prevents bypass of the TOE authentication function by an impostor, including by means of a ‘piggy-back’ attack. O.NOFORGE prevents attempted replay attacks which are intended to bypass the capture device. O.SECOP provides for supervision of entry to the portal where necessary, so as to help prevent ‘piggy-back’ attacks. O.TRAIN reduces the risk of enrolee collusion or security procedure error that might lead to illegal access to the portal, either through a ‘piggy-back’ attack or by substitution following authentication of an authorized user. T.CORRUPT rationale 225 The threat of unauthorised modification of security-relevant data is countered by O.ADMIN, which restricts the ability to modify the user security attributes and other security relevant data such as the audit trail and configuration parameters to administrators. T.UNDETECT rationale 226 The threat of undetected attack is countered by O.RECORD which provides the means to record events which may indicate attack against the TOE’s security functions, and also to provide the capability to hold individual users accountable for their security relevant actions. Auditing addresses after-the-fact attacks; however, knowledge that an attacker might be discovered is often one of the best deterrents. This is supported by: a) O.SECOP, which ensures that audit trails are examined on a regular basis. This reduces the risk of undetected impostor attempts and impedes repeated attempts by impostors. O.ADMIN, which ensures that only administrators have the ability to manage the audit functions and access the audit trail. This reduces the risk of undetected attack arising from a failure to collect sufficient audit data, or from loss of the availability or integrity of audit data. (According to A.NO_EVIL there is no threat of administrators deliberately modifying or deleting audit data so as to cover up their tracks.) O.TRAIN, which will provide administrators with the security awareness training needed in order to be able to identify attempted or actual security breaches from the events recorded in the audit trail. b) c) Page 60 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T T.POWER rationale 227 The threat of power loss causing a failure in the Biometric Device is countered by O.ADMIN and O.OPER, which provide administrators and operators with the capability of restoring the Biometric Device to a secure state in the event of failure or interruption. These are supported by O.SECOP, which requires secure operating procedures which may help prevent power loss. T.NOISE rationale 228 The threat of flooding with noise data is countered by O.PHYS.TOE and O.PHYS.ENV. O.PHYS.TOE ensures that the TOE is resistant to electromagnetic and other relevant noise flooding attacks, where such attacks are not precluded by the protection afforded against physical attack within the TOE environment by O.PHYS.ENV. T.TAMPER rationale 229 The threat of modification or altering of the hardware components or of physical connection between the components or between the Biometric Device and the portal is countered by O.PHYS.TOE and O.PHYS.ENV. O.PHYS.ENV provides for an appropriate level of physical protection within the TOE environment, whilst O.PHYS.TOE ensures that the TOE is resistant to any physical attacks that are not precluded by the environment. Organisation security policies are met by the security objectives P.FARFRR rationale 6.1.2 230 The OSP requirement that recognised national or international standards be satisfied in respect of the FAR and FRR is met directly by O.FARFRR. This is supported by O.ENROL.TOE and O.ENROL.ENV which ensure that biometric templates meet the required enrolment quality standards. P.TRAIN rationale 231 The OSP requirement that individuals receive appropriate security awareness training is met directly by O.TRAIN. P.USERLIMIT rationale 232 The OSP requirement that repeated attempts to gain access to the portal be prevented is met by O.USERLIMIT which is an objective to be satisfied either by the TOE limiting unsuccessful attempts or by environmental measures (e.g. a supervised system). September 6, 2001 Page 61 of 72 Biometric Device Protection Profile D R A F T 6.1.3 Assumptions are upheld by the security objectives A.PORTAL rationale 233 Table 4 does not map any security objectives explicitly to this assumption, since it is a general assumption regarding the intended method of use of the Biometric Device. All security objectives for the TOE and for the environment are based on, and thus can be regarded as being consistent with or upholding, the A.PORTAL assumption. A.ROLES rationale 234 This assumption is upheld principally by O.TRAIN which provides for security awareness training for personnel in each of the roles, thus covering their security responsibilities. It is supported by the TOE objectives O.ADMIN and O.OPER which reflect this separation of roles. A.NO_EVIL rationale 235 This assumption is upheld by O.TRAIN which is the objective for appropriate security awareness training of individuals. A.USERTMPL rationale 236 This assumption is upheld by O.USERTMPL which is the objective for the protection of the authenticity and integrity of user-held templates. 6.2 237 Security Requirements Rationale This section demonstrates that the set of security requirements identified in Section 5 is suitable to meet the security objectives identified in Section 4. The following is demonstrated: a) that the combination of the individual functional and assurance requirements components for the TOE and its IT environment together meet the security objectives This part of the rationale is provided in section 6.2.1. b) that the set of security requirements together forms a mutually supportive and internally consistent whole; This part of the rationale is provided in section 6.2.2. c) that the choice of security assurance requirements is justified; Page 62 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T This part of the rationale is provided in section 6.2.3. d) that the selected strength of function level for the PP, together with any explicit strength of function claim, is consistent with the security objectives for the TOE. This part of the rationale is provided in section 6.2.4. 238 Additionally, section 6.2.5 explains the use of the refinement operation on [CC2] functional components included in this PP. Suitability of security requirements Table 5 maps the SFRs for the TOE to the security objectives identified in Section 4. (Note that the BDPP specifies no objectives or requirements for the IT environment.) Table 5. Functional Component to Security Objective Mapping Security Objective O.FARFRR Functional Component FIA_UID.2 FIA_UAU.2 FIA_ATD.1 FMT_MTD.3 FIA_UAU.7 FIA_UID.2 FIA_UAU.2 FMT_SMR.1 FMT_MOF.1(1), (3) FMT_MTD.1(1), (2), (3) FPT_RCV.1 FPT_AMT.1 FPT_TST.1 FPT_RVM.1 FIA_UID.2 FIA_UAU.2 FPT_ITT.1 FPT_ITT.3 FMT_MTD.3 FIA_UAU.3 FPT_ITT.1 FPT_ITT.3 FPT_RPL.1 6.2.1 239 O.FEEDBACK O.ADMIN O.BYPASS O.ENROL.TOE O.NOFORGE September 6, 2001 Page 63 of 72 Biometric Device Protection Profile D R A F T Table 5. Functional Component to Security Objective Mapping Security Objective O.OPER Functional Component FIA_UID.2 FIA_UAU.2 FMT_SMR.1 FMT_MOF.1(2), (3) FPT_RCV.1 FPT_PHP.3(1), (2) FAU_GEN.1 FAU_GEN.2 FAU_SAR.1 FAU_SAR.2 FAU_STG.2 FMT_MOF.1(1) FMT_MTD.1(3) FPT_STM.1 FIA_AFL.1 O.PHYS.TOE O.RECORD O.USERLIMIT 240 The following rationale shows, for each TOE security objective in turn, why the security requirements are suitable to meet them. This discussion focuses naturally on the role of the SFRs, although the role of specific security assurance requirements is also discussed where they have direct relevance to a security objective. O.FARFRR rationale 241 The objective to meet the specified national or international standards for the FAR and FRR is met by the following SFRs: a) FIA_UID.2 and FIA_UAU.2 provide support to the achievement of the mandated FAR and FRR by requiring identification and authentication of the users such that access to the portal is permitted to authorised users but denied to all other individuals. FIA_ATD.1 provides support to TOE security policy enforcement by requiring that relevant user security attributes be recognised by the TOE and associated with users, including the identifying name or number, and unique physical or behavioural characteristic. FMT_MTD.3 requires the TOE to ensure that the quality of enrolment templates is upheld, thereby helping to achieve the mandated FAR. b) c) 242 Additionally, the security assurance requirement AVA_SOF.1 ensures the requirement is met since it requires validation that the explicit strength metric indicated by the required FAR and FRR values is met by the TOE. Page 64 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T O.FEEDBACK rationale 243 This objective is directly met by FIA_UAU.7, which ensures that no feedback is provided to an impostor that could be exploited in subsequent attacks to defeat the biometric authentication mechanism. O.ADMIN rationale 244 The objective to provide administrative functions that are limited to administrators is met by the following SFRs: a) b) c) d) e) f) FIA_UID.2 and FIA_UAU.2 provide support to the achievement of this objective by requiring identification and authentication of administrators. FMT_SMR.1 requires the TOE to be able to recognise the administrator role, and to be able to associate users with that role. FMT_MTD.1(1) requires that the ability to tune the performance of the biometric system be restricted to administrators. FMT_MTD.1(2) requires that the ability to maintain the user security attributes is restricted to administrators. FMT_MOF.1(1) and FMT_MTD.1(3) require that the ability to manage the auditing functions is restricted to administrators. FPT_RCV.1 requires the provision of the capability to restore the TOE to a secure state in the event of a failure or service interruption, entering the TOE into a maintenance mode where the capability to return the TOE to a secure state is provided. FMT_MOF.1(3) requires that the capability to perform such restoration from maintenance mode is restricted to administrators and operators. FPT_TST.1 and FPT_AMT.1 require the TOE to provide administrators and operators with the capability to periodically validate the correct operation of, respectively, the TSF and its underlying abstract machine. g) O.BYPASS rationale 245 The objective to prevent bypass of TOE security policy enforcement is met by the following SFRs: a) FPT_RVM.1 prevents bypass of the TSP enforcement functions by requiring that they are invoked and succeed before each function within the TOE’s scope of control is allowed to proceed. FIA_UID.2 and FIA_UAU.2 require users to be successfully identified and their claimed identity authenticated prior to entry through the portal, in b) September 6, 2001 Page 65 of 72 Biometric Device Protection Profile D R A F T particular preventing access to any functionality prior to user identification and authentication that might be exploited to bypass TSP enforcement. c) FPT_ITT.1 prevents bypassing attacks based on attempting to intercept confidential TSF data when it is transmitted between separate parts of the TOE, e.g. between the biometric capture device and the recognition component. FPT_ITT.3 prevents bypassing attacks based on attempts to compromise the integrity of TSF data when it is transmitted between separate parts of the TOE. d) O.ENROL.TOE rationale 246 The objective to ensure that enrolment templates satisfy minimum quality standards is met directly by FMT_MTD.3. O.NOFORGE rationale 247 The objective to detect and prevent forgery of authentication data is met by the following SFRs: a) FIA_UAU.3 states that the Biometric Device must distinguish between forgeries of any kind, particularly live from non-live input. FIA_UAU.3.2 requires that one individual cannot use the enrolled image data for another user. For example, the Biometric Device should be able to detect a attempted use of a voice recording. FPT_ITT.1 prevents attempts to intercept confidential TSF data when it is transmitted between separate parts of the TOE, e.g. between the biometric capture device and the recognition component. Such attempts may be made with the intent of copying authentication data, and using this data to perform a forgery attack. FPT_ITT.3 requires the TOE to detect attempts to compromise the integrity of TSF data when it is transmitted between separate parts of the TOE, thereby helping to prevent attempted forgery attacks. FPT_RPL.1 requires the TOE to block attacks based on the capture and replay of biometric authentication data. b) c) d) Page 66 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T O.OPER rationale 248 The objective to provide operator functions that are restricted to operators of the TOE is met by the following SFRs: a) b) c) d) FIA_UID.2 and FIA_UAU.2 provide support to the achievement of this objective by requiring identification and authentication of operators. FMT_SMR.1 requires the TOE to be able to recognise the operator role, and to be able to associate users with that role. FMT_MOF.1(2) requires that the ability to perform routine maintenance and emergency start-up and shut-down is restricted to operators. FPT_RCV.1 requires provision of the capability to restore the TOE to a secure state in the event of a failure or service interruption, entering the TOE into a maintenance mode where the capability to return the TOE to a secure state is provided. FMT_MOF.1(3) requires that the capability to perform such restoration from maintenance mode is restricted to operators and administrators. O.PHYS.TOE rationale 249 The objective to prevent physical attacks on the TOE is met by the following SFRs: a) FPT_PHP.3(1) requires the TOE to resist physical attacks such as physical alteration, modification or replacement of its components or of the connections between those components, where these are not precluded by the TOE environment. FPT_PHP.3(2) requires the TOE to resist electromagnetic or other relevant noise flooding attacks, where these are not precluded by the TOE environment. b) O.RECORD rationale 250 The objective to provide the means of detecting and recording security relevant events is met by the following SFRs: a) FAU_GEN.1 requires the capability to generate records of security relevant events; FAU_GEN.2 requires the capability of identifying the user responsible for the event in order to be able to hold users accountable for their actions. FAU_SAR.1 requires the TOE to provide administrators with the ability to review the audit data so as to be able to identify security relevant events and b) September 6, 2001 Page 67 of 72 Biometric Device Protection Profile D R A F T assess their impact. FAU_SAR.2 requires that the ability to read the audit records be restricted to the administrator. c) FAU_STG.2 requires the TOE to minimise potential loss of audit data in the event of audit storage exhaustion, failure or attack, and to prevent compromise of the integrity of the collected data through unauthorised modification or deletion. FPT_STM.1 requires the provision of reliable timestamps in support of the auditing function. FMT_MOF.1(1) and FMT_MTD.1(3) require that the ability to manage the auditing functions and the audit trail be restricted to administrators. These SFRs thus help to ensure that the appropriate audit data is collected and maintained by the TOE. d) e) O.USERLIMIT rationale 251 The objective to limit user authentication attempts is met by FIA_AFL.1. Note however, that it is permissible for the TOE not to provide such functionality, providing this is clearly stated in the ST. In such cases the objective is to be satisfied by the environment, as stated in section 4. Mutually supportive security requirements Table 1 lists the dependencies of each CC Part 2 functional component included in this PP. It can be readily seen by inspection that all dependencies on other functional components are satisfied within the set of SFRs mandated by the BDPP. Two functional components (namely FPT_RCV.1 and FMT_MTD.3) have identified dependencies on assurance components. The following dependencies are not satisfied: a) The dependency of FPT_RCV.1 and FMT_MTD.3 on ADV_SPM.1 is not satisfied at the EAL1+, EAL2 and EAL3 assurance levels. The intent of this dependency is that an informal TSP model may be needed to define what is a ‘secure state’ (FPT_RCV.1) or what are ‘secure values’ for TSF data (FMT_MTD.3). However, the meaning of ‘secure’ in the context of a Biometric Device is clearly defined within this PP, and does not require further elaboration by means of an informal TSP model. Therefore ADV_SPM.1 is not a necessary assurance requirement. 6.2.2 252 253 254 All dependencies between assurance components are satisfied for the assurance levels EAL2, EAL3 and EAL4, as these are defined in CC to be self-contained assurance packages. The EAL1+ assurance level is defined as EAL1 augmented with AVA_SOF.1. The dependency of AVA_SOF.1 on ADV_FSP.1 is satisfied by EAL1; however, the dependency on ADV_HLD.1 is not. The intent of this dependency is to ensure 255 Page 68 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T sufficient design information is provided to be confident that all probabilistic or permutational mechanisms are identified, together with the information needed on which to base the SOF analysis. In the case of Biometric Devices, such information is not necessary2 since: a) The mechanisms implementing FIA_UAU.1 and FIA_UAU.2 are known from the outset to be probabilistic and permutational in nature. The Biometric Device is a simple device whose only function is the verification of an individual’s identity; therefore, there will be no other such mechanisms within the TOE (since cryptographic mechanisms are not within the scope of AVA_SOF.1). The SOF analysis will be based mainly on a statistical testing approach to confirm that the FAR and FRR requirements are met. Therefore, design information is not needed to perform the analysis. b) 256 In addition to the dependencies between functional and assurance components discussed above, there are additional instances of support between SFRs in particular that exist to ensure that the set of requirements form a mutually supportive and cohesive whole. The primary function of the Biometric Device, namely identification or verification of users, is provided by SFRs from the FIA class. The SFRs selected from the FAU class provide auditing functions in support of the FIA requirements by detecting security relevant events that might indicate a potential compromise of those functions. These are in turn supported by SFRs from the FMT and FPT classes as follows: a) SFRs from the FMT class provide administrator and operator functions to support secure management of the security functions and of TSF data such as the user security attributes and the audit trail, on which the FIA and FAU SFRs depend; SFRs from the FPT class provide appropriate protection of the TSF, preventing bypass of the security functions (FPT_RVM.1), protecting TSF data (FPT_ITT.1, FPT_ITT.3, FPT_TST.1), blocking replay attacks (FPT_RPL.1), resisting physical attacks against the Biometric Device (FPT_PHP.3), and validating correct operation of the TSF (FPT_AMT.1, FPT_TST.1). 257 b) 258 (Note that requirements from the FPT_SEP family3 are not relevant to a Biometric Device since there is no requirement for separation of users or for protection against untrusted subjects within the TOE.) 2. Note this argument only applies to the SOF analysis. Provision of high-level design information is an intrinsic part of the higher assurance levels (EAL2, EAL3, and EAL4). 3. See [CEM] Annex B.7 which effectively mandates FPT_RVM, FPT_SEP and FPT_PHP requirements in PPs and STs where there is an implicit or explicit threat of bypass or tampering. September 6, 2001 Page 69 of 72 Biometric Device Protection Profile D R A F T 259 Finally, the security assurance requirements are by definition supportive of the SFRs. Section 6.2.1 above cites specific cases where individual assurance requirements help to achieve the security objectives (and thus support the relevant SFRs in so doing). Assurance security requirements rationale Assurance is that property of the Biometric Device that gives confidence that the security functions work as stated, i.e., that they are effective and are implemented correctly. This information comes from an understanding of how the Biometric Device is defined, constructed, maintained, and operated. The first factor considered in the selection of the assurance level was the value of the assets to be protected by the Biometric Device and the risk should those assets be compromised. The higher the value of the assets to be protected, and the greater the risk to those assets, the higher the assurance level that is needed. However, this PP makes no assumptions about the value of the assets to be protected by the Biometric Device, and hence there is a range of assurance levels that will be appropriate to meet the general security needs articulated in this PP. (More specific needs will be articulated in the ST, e.g. details of assets requiring protection.) A second consideration in the selection of the assurance level was the current state of practice in the definition and construction of commercially available Biometric Devices. Higher assurance levels have more stringent requirements and at some point, the assurance level requirements exceed the current state of practice. However, it was determined that an assurance level of EAL4 would be within the reach of commercially available Biometric Devices: to meet higher assurance levels a TOE would have to be designed and implemented with the specific assurance requirements in mind (e.g. for modular or semiformal design). EAL4 therefore represents an appropriate upper bound on the range of assurance levels covered by this PP. The third factor considered in the selection of the assurance level was the cost. Development costs, evaluation costs, and maintenance costs must be addressed. Embedded in these cost issues is the time factor. If the required assurance level is too demanding, the associated costs may be prohibitively high for some vendors of Biometric Devices (or at least the costs may significantly outweigh the benefits). Also, the time required to achieve certification may be so great that the evaluated version is not the latest release of the product. This does not, ultimately, serve the needs of the user who wishes to have some level of independent assurance in the validity of a vendors claims in respect of the FAR and FRR: if the assurance requirement is too high the end result may be that the user’s choice of evaluated Biometric Devices is too restrictive. Therefore, it is necessary to define a minimum assurance level that will minimise costs (development, evaluation and maintenance) and the time to certification. In defining the lower bound for the assurance level range, it was necessary to choose the minimum level that achieved the defined security objectives for the TOE. The 6.2.3 260 261 262 263 264 Page 70 of 72 72 September 6, 2001 Biometric Device Protection Profile D R A F T following security objective in particular has a direct bearing on the assurance requirement: a) O.FARFRR states that the TOE shall comply with specified national or international standards with respect to the FAR and FRR. In order to confirm that this objective is satisfied, it is necessary for the minimum assurance level to include a strength of TOE security function analysis, i.e. AVA_SOF.1 must be included. Since this assurance requirement does not feature in EAL1, it is necessary for the minimum assurance requirement to be EAL1 augmented with AVA_SOF.1 (see also section 6.2.2 which considers the dependencies introduced by the inclusion of AVA_SOF.1). 265 The lowest level mandated by this PP, namely EAL1+, therefore represents the minimum assurance requirement that is suitable to achieve the security objectives for the TOE. Clearly, the risk that flaws remain in the TOE is reduced at higher assurance levels. For example, at EAL2 there is additionally a requirement for a developer (and evaluator) search for obvious vulnerabilities. At EAL3 and EAL4 assurance increases through greater knowledge and understanding of the TOE design and implementation. It was felt that a vendor seeking evaluation at a higher assurance level - possibly with a view to selling into organisations that mandate higher assurance requirements - should be able to gain recognition through the claim of conformance with this PP. Therefore, the BDPP mandates a range of assurance levels that is appropriate to meet the security objectives. As such, it can be viewed, not as a single PP, but rather as a family of hierarchically related PPs that differ only in respect of the assurance requirement4. 266 4. In theory, PPs that differ in respect of the assurance requirements should also (at the very least) differ in respect of their security objectives. However, in practice this presupposes that the primary assets to be protected, and their value, can be defined to a sufficient level of detail that will naturally lead to TOE security objectives from which a specific assurance requirement can be determined. In the case of a TOE such as a Biometric Device, where the primary assets to be protected are not actually stored within the TOE, such detail cannot necessarily be given. It was considered that it would be inappropriate for the BDPP to assume that the assets had a particular value merely to ensure that a specific assurance requirement could be determined. September 6, 2001 Page 71 of 72 Biometric Device Protection Profile D R A F T 6.2.4 267 Strength of TOE Security Functions Rationale Both the minimum SOF rating and the explicit strength metrics in the form of required FAR and FRR are determined by the specified national or international standards, in accordance with the P.FARFRR OSP. Since P.FARFRR is satisfied directly by the security objective O.FARFRR, it follows from this that the SOF requirements are consistent with the security objectives for the TOE. Refinement of CC Functional Components FIA_UAU.3 6.2.5 268 Both elements (FIA_UAU.3.1 and FIA_UAU.3.2) have been refined to clarify that the requirements apply only to biometric authentication data. The BDPP does not mandate equivalent protection of any other types of authentication data managed by the TOE. FIA_UAU.7 269 The element FIA_UAU.7.1 has been refined to clarify that the requirements apply only to biometric authentication data. The BDPP does not mandate equivalent protection of any other types of authentication data managed by the TOE. FMT_MTD.3 270 The element FMT_MTD.3.1 has been refined to clarify the scope of the requirement. This has been done by replacing the generic CC term “TSF data” with the more specific term “enrolled biometric templates”. FAU_GEN.1 271 The element FAU_GEN.1.2 has been refined for clarity, by replacing the term “subject identity” with the more meaningful term “individual identity”. FPT_TST.1 272 The elements FPT_TST.1.2 and FPT_TST.1.3 have been refined for clarity, by replacing the term “authorised users” with “authorised administrators”. Page 72 of 72 72 September 6, 2001