+
+
+
+
+
+
+
+
+
Protection Profiles
+
+
+
+
+
+
Protection Profiles List CSV file generated
+
+
+Search:
+
+
+
+
+
+Filter by:
+
+
+
+
+
+
+
+
+
+
+Number of results:
+
+
+
+
+
+
+| Protection Profile |
+Version |
+Assurance Level |
+Issued |
+Scheme |
+Certified |
+Categories |
+
+
+
+
+
+
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/tests/data/protection_profiles/pps/pdf/b02ed76d2545326a.pdf b/tests/data/protection_profiles/pps/pdf/b02ed76d2545326a.pdf
new file mode 100644
index 00000000..9d986ad1
Binary files /dev/null and b/tests/data/protection_profiles/pps/pdf/b02ed76d2545326a.pdf differ
diff --git a/tests/data/protection_profiles/pps/txt/b02ed76d2545326a.txt b/tests/data/protection_profiles/pps/txt/b02ed76d2545326a.txt
new file mode 100644
index 00000000..4b575e23
--- /dev/null
+++ b/tests/data/protection_profiles/pps/txt/b02ed76d2545326a.txt
@@ -0,0 +1,944 @@
+Fingerprint Spoof Detection Protection Profile
+based on Organisational Security Policies
+FSDPP_OSP
+v1.7
+Bundesamt für Sicherheit in der Informationstechnik
+Postfach 20 03 63
+53133 Bonn
+Tel.: +49 228 99 9582-0
+E-Mail: bsi@bsi.bund.de
+Internet: https://www.bsi.bund.de
+© Bundesamt für Sicherheit in der Informationstechnik 2009
+ FSDPP_OSP
+Table of content
+1. PP introduction..................................................................................................................................4
+1.1 PP Reference.................................................................................................................................4
+1.2 PP Overview..................................................................................................................................4
+2. TOE Description................................................................................................................................5
+2.1 Protection of biometric systems.....................................................................................................5
+2.2 TOE configuration and TOE environment.....................................................................................6
+2.3 TOE boundary...............................................................................................................................6
+2.3.1 Physical boundary.....................................................................................................................7
+2.3.2 Logical boundary......................................................................................................................7
+3. Conformance Claims.........................................................................................................................9
+3.1 Conformance statement.................................................................................................................9
+3.2 CC Conformance Claims...............................................................................................................9
+3.3 PP Claim........................................................................................................................................9
+3.4 Package Claim...............................................................................................................................9
+4. Security Problem Definition ...........................................................................................................10
+4.1 External entities...........................................................................................................................10
+4.2 Assets..........................................................................................................................................10
+4.3 Assumptions................................................................................................................................11
+4.4 Threats.........................................................................................................................................11
+4.5 Organizational Security Policies..................................................................................................11
+5. Security Objectives..........................................................................................................................12
+5.1 Security Objectives for the TOE..................................................................................................12
+5.2 Security objectives for the operational environment....................................................................12
+5.3 Security Objectives rationale.......................................................................................................13
+5.3.1 Overview................................................................................................................................13
+5.3.2 Justification for coverage of assumptions...............................................................................14
+5.3.3 Justification for the coverage of organizational security policies............................................14
+6. Extended Component definition......................................................................................................16
+6.1 FPT_SPOD Biometric Spoof Detection......................................................................................16
+6.1.1 Biometric Spoof Detection (FPT_SPOD.1)............................................................................17
+6.1.2 Justification for the definition of functional family FPT_SPOD.............................................17
+7. Security Requirements.....................................................................................................................18
+7.1 Security Functional Requirements for the TOE...........................................................................18
+7.1.1 Security audit (FAU)..............................................................................................................19
+2 Bundesamt für Sicherheit in der Informationstechnik
+ FPSDPP_OSP
+7.1.2 User data protection (FDP).....................................................................................................19
+7.1.3 Security management (FMT)..................................................................................................20
+7.1.4 Protection of the TSF (FPT)...................................................................................................21
+7.2 Security Assurance Requirements for the TOE...........................................................................22
+7.3 Security Requirements rationale..................................................................................................23
+7.3.1 Security Functional Requirements rationale...........................................................................23
+7.3.2 Security Assurance Requirements rationale............................................................................24
+8. Appendix.........................................................................................................................................26
+8.1 Glossary.......................................................................................................................................26
+8.2 References...................................................................................................................................27
+Bundesamt für Sicherheit in der Informationstechnik 3
+ FSDPP_OSP
+1. PP introduction
+1.1 PP Reference
+Title: Fingerprint Spoof Detection Protection Profile based on OSP (FSDPP_OSP)
+Version 1.7
+Date November, 27th
+2009
+Author Boris Leidner, Nils Tekampe, TÜV Informationstechnik GmbH
+Registration Bundesamt für Sicherheit in der Informationstechnik (BSI)
+Federal Office for Information Security Germany
+Certification-ID BSI-CC-PP-0062
+CC-Version 3.1 Revision 3
+Keywords biometric; fingerprint-recognition; Protection Profile; spoof detection
+1.2 PP Overview
+Biometric systems that work based on fingerprints are often subject to a well known and easy kind of
+attack: Attackers can use faked fingerprints (e.g. built out of gummy or silicone) that carry the
+characteristics of a known user in order to get recognized by a biometric system. As an alternative a
+user of a biometric system may use a faked finger in order to disguise their identity. Countermeasures
+against those attacks may be implemented by a set of dedicated hardware and software, the so called
+biometric spoof detection system.
+In order to facilitate new mechanisms for spoof detection in fingerprint recognition systems and
+thereby advancing innovative technologies in the area of security the project “LifeFinger I” has been
+initiated by the Federal Office for Information Security. This Protection Profile forms part of this
+project that has been conducted by the Bundesdruckerei GmbH.
+The scope of this Protection Profile is to describe the functionality of a biometric spoof detection
+system in terms of [CC] and to define functional and assurance requirements for the evaluation of such
+systems. Chapter 2 gives a more detailed overview about the design of the TOE and its boundaries.
+This Protection Profile thereby focuses on application cases for which it is sufficient to determine
+whether the security functionality claimed by a TOE is working correctly without performing a
+dedicated vulnerability assessment. Therefore, this PP is solely based on organizational security
+policies and threats are completely omitted. The explicit assurance package for an evaluation without a
+vulnerability assessment is defined in chapter 3.4.
+When planning an evaluation according to this PP the ST author should also consider the Fingerprint
+Spoof Detection Protection Profile [FSDPP] which is based on threats and not organizational security
+policies only. In general, the use of the [FSDPP] should be the preferred option.
+4 Bundesamt für Sicherheit in der Informationstechnik
+ FSDPP_OSP
+2. TOE Description
+The Target of Evaluation (TOE) described in this PP is a system that provides fingerprint spoof
+detection either as part of, or in front of a biometric system for fingerprint recognition.
+The TOE determines whether a fingerprint presented to the biometric system is genuine or spoofed.
+The term spoofed biometric characteristics hereby refers to artificially created fake fingers which are
+currently known to circumvent fingerprint recognition systems.
+For this purpose the spoof detection system acquires spoofing evidences for a presented fingerprint
+using a sensor device. This sensor can either be part of the capture device that is used to capture the
+biometric sample of the fingerprint (or even be identical to it) or be a separate sensor device (or more
+than one) that is completely dedicated to spoof detection.
+Beside the fingerprint spoof detection functionality every TOE that claims conformance to this PP
+shall implement:
+• Management functionality to modify security relevant parameters
+• Quality control for management parameters
+• Audit functionality for security relevant events
+• Protection of residual and security relevant data.
+2.1 Protection of biometric systems
+Systems claiming compliance to this Protection Profile are developed to protect biometric systems for
+fingerprint recognition against one specific kind of attacks: The use of well known faked
+finger(prints). The following paragraphs introduce the core biometric processes of a biometric system
+in order to improve the understanding of the direct environment of the TOE and to explain the
+motivation of an attacker.
+● Enrollment:
+Often, the enrollment process is the first contact of a user with a biometric system. This
+process is necessary because a biometric system has to be trained in order to verify the identity
+of each user based on their fingerprint.
+During the enrollment process the system captures the fingerprint image of a user and extracts
+the features it is working with. These features are then combined with the identity of the user
+to a biometric reference and stored as template in a database.
+During enrollment an attacker could try to present faked finger(prints) to the capture device in
+order to get enrolled with another biometric characteristic. When having success the attackers
+identity would be associated with the fake fingerprint. The important thing to notice in this
+context is that an attacker must not necessarily have to have any knowledge about the
+biometric characteristic of another user to perform this attack.
+● Biometric verification:
+The objective of a verification process is to verify or refuse the claimed identity of a user
+based on their fingerprint. Therefore the user has to claim an identity to the system. The
+system retrieves the fingerprint reference record associated with this identity from the
+database and captures the live fingerprint. If the fingerprint features that are extracted from the
+live fingerprint image and the fingerprint reference from the database are similar enough, the
+claimed identity of the user is considered to be verified.
+During biometric verification an attacker could try to use a faked finger to get recognized by
+the system as another user (this kind of attack is often referred to as impersonation). For such
+an attack however, the attacker will have to know about the biometric characteristic of the
+attacked user.
+Bundesamt für Sicherheit in der Informationstechnik 5
+ FSDPP_OSP
+Another specific aspect for a spoof detection system that is used to protect a biometric
+verification process is that a claimed identity is available.
+● Biometric identification:
+The objective of a biometric identification process is similar to a verification process.
+However, in contrast to a verification process there is no claimed identity for the user. The
+system directly captures the fingerprint of a user and compares it to all fingerprint references
+in the database. If at least one reference is found to be similar enough according to the relevant
+threshold settings, the system returns this as the found identity of the user.
+In the identification scenario an attacker can have multiple aims:
+○ An attacker could try to get identified as a specific enrolled user (i.e. using a fake finger of
+that specific user). The reason for doing so may be that this attacked user has a specific
+credential that the attacker is after.
+○ An attacker could try to get identified as any enrolled user (i.e. using a faked fingerprint of
+any enrolled user). This can be relevant for cases where all enrolled users for a system
+have similar permissions.
+○ An attacker who is enrolled in the system could try avoid identification (i.e. disguise their
+identity) For such an attack the attacker may not need any knowledge about the biometric
+characteristic of another user.
+More information on how the environment contributes to the security problem addressed by the TOE
+can be found in the Fingerprint Spoof Detection Evaluation Guidance [FSDEG].
+2.2 TOE configuration and TOE environment
+A biometric spoof detection system in general could be realized in two major configurations:
+● An integrated solution: All relevant parts of the TOE are integrated into one physical unit.
+● A distributed solution: Relevant parts of the TOE are implemented in physically separated
+parts.
+This PP describes a biometric spoof detection system for fingerprints as an integrated solution but
+should be applicable to distributed solutions as well. However, if applied to a distributed TOE
+additional aspects of security shall be considered by the author of the Security Target in form of:
+1. Assumptions for the TOE environment
+2. Requirements for additional functionality: e. g. encrypted transmission
+It is known that environmental factors may influence the performance and therewith the protection
+provided by a spoof detection system. Therefore the author of a Security Target claiming compliance
+to this PP shall clearly identify the relevant environmental factors and their acceptable range for the
+operation of the TOE. More information about influencing factors can be found in [FSDEG].
+In general it should be noted that the TOE should not impact the functionality of the protected
+biometric system (e.g. by a deterioration of image quality) beyond what is necessary for the desired
+application. If a negative impact cannot be completely avoided this shall be clearly pointed out by the
+ST author.
+2.3 TOE boundary
+A simplified model of a biometric spoof detection system and its boundaries is shown in Figure 1.The
+following chapters provide more details about the physical and logical boundaries of the TOE.
+6 Bundesamt für Sicherheit in der Informationstechnik
+ FSDPP_OSP
+2.3.1 Physical boundary
+Figure 1: TOE demarcation
+Spoof
+Detection
+Biometric
+System
+Biometric
+Sample
+(fingerprint
+image)
+TOE
+Spoof Detection
+parameters
+Audit log
+Audit data
+Biometric sample
+(fingerprint image),
+Spoofing evidence
+Add. sensors
+Administrator
+User
+Capture
+Device
+Finger
+Fingerprint
+Other attributes
+The TOE defined in this PP is limited to the biometric spoof detection system. This system shall
+decide whether a provided fingerprint is spoofed or genuine. The TOE shall comprise all parts of a
+product (hardware and software) that contribute to this functionality or any of the additional
+functionality outlined in chapter 2.3.2. In particular these are:
+• the capture device for capturing of fingerprint images
+• additional sensor devices for acquisition of spoofing evidences (if applicable)
+• necessary software (if applicable)
+The spoofing evidences for a fingerprint can either be captured by the same sensor device being also
+used for the biometric system (capture process) or using separate sensor devices. If separate sensor
+devices are used, it has to be ensured that the same fingerprint is used for both processes.
+The biometric system that is protected by the TOE resides in the environment. It can be, e. g., a
+biometric identification system, a biometric verification system, or an enrollment system as described
+in chapter 2.1. This means that all aspects about the security of the biometric systems (e.g. questions
+about the error rates of this system) are out of scope for the evaluation of the TOE.
+The TOE shall be able to generate audit data. This audit data can be used for quality assurance or
+statistics. However, functionality for storage, protection and review of audit records is assumed to be
+provided by the environment of the TOE.
+Further the TOE may rely on access control mechanisms of the environment for its own protection and
+the restriction of access to management functions offered by the TOE (e.g. for adjustment of important
+parameters). Also for the implementation of management functions the TOE may partly rely on
+functions of the environment (i.e. in form of a file import that involves the Operating System).
+2.3.2 Logical boundary
+The logical boundaries of the TOE can be defined by the functionality that it provides:
+● Spoof detection: the TOE detects whether a presented fingerprint is spoofed or genuine. It
+shall perform appropriate actions in case of a spoofed and in case of a genuine biometric
+Bundesamt für Sicherheit in der Informationstechnik 7
+ FSDPP_OSP
+characteristic. It should be clearly mentioned that in the context of this PP a TOE is always
+required to decide about the presented fingerprint in form of a yes/no decision. It is not
+considered to be sufficient if a TOE would return a confidence value that would need further
+interpretation by the environment.
+● Management: the TOE provides functionality to manage its relevant parameters. This
+specifically (but not only) refers to the parameters that are involved in the spoof detection
+process (e.g. a threshold). The TOE ensures that only secure values for spoof detection
+parameters are accepted to ensure the constant operation of the primary functionality.
+● Residual Information Protection: in order to prevent the leakage of information the TOE
+deletes relevant information if not longer in use.
+● Audit: the TOE produces audit events for security relevant events.
+The following functionality on the other hand may be provided by the environment to support the
+operation of the TOE:
+● Access control: the environment provides access control for the spoof detection parameters,
+the life record, audit data and any software parts of the TOE. To perform access control, the
+environment maintains roles for users and ensures their identification and authentication.
+● Transmission / Storage: the environment provides a secure communication and storage for
+data where security relevant data is transferred to or from the TOE.
+● Auditing: the environment may provide additional audit functionality. In any case it will
+provide reliable time stamps for auditing, storage for the audit records that are produced by the
+TOE and mechanisms for review of audit logs. The developer will probably have to consider
+privacy concerns (in case that personal information is part of the audit logs). Applicable data
+protection laws and protection mechanisms might have to be considered.
+●
+Application Note:
+To allow the application of this PP to a wide range of systems, several
+functions are stated to be implemented in the environment. However, if a TOE
+is able to provide those functions on its own the ST author should consider to
+define those functions as part of the TOE.
+8 Bundesamt für Sicherheit in der Informationstechnik
+ FSDPP_OSP
+3. Conformance Claims
+3.1 Conformance statement
+The PP requires strict conformance of any PPs/STs to this PP. A demonstrable conformance is not
+allowed.
+3.2 CC Conformance Claims
+• This PP has been developed using Version 3.1 R3 of Common Criteria [CC].
+• The conformance of this Protection Profile is Common Criteria [CC] Part II extended (due
+to the use of FPT_SPOD.1)
+• The conformance of this Protection Profile is Common Criteria [CC] Part III conformant.
+3.3 PP Claim
+• This PP does not claim conformance to any other Protection Profile.
+3.4 Package Claim
+This PP does not claim conformance to any assurance package (i.e. EAL) as defined in Common
+Criteria Part III. Instead, this PP defines an explicit assurance package that bases on EAL 2. However,
+in contrast to EAL 2 as defined in part III of [CC], the assurance package in this PP does not contain
+any AVA_VAN component. It further includes the assurance component ALC_FLR.1.
+The reason for this explicit assurance level is to allow a purely functional evaluation of the
+performance of a system for spoof detection. Such an evaluation will allow to determine whether the
+functionality of a system for spoof detection is sufficient to recognize spoofed biometric
+characteristics that are know for a certain biometric modality.
+An evaluation using this explicit assurance level is deliberately ignoring the fact that an attacker could
+try to circumvent the functionality of the TOE (e.g. by using different/innovative spoofed
+characteristics) and focuses on the basic functionality of the TOE. A system claiming compliance to
+this Protection Profile is therefore suitable for the use in application cases in which an assurance about
+the basic functionality of a system is sufficient. To emphasize that this PP only deals with the pure
+functionality of spoof detection, the definition of threats has been omitted and the PP is completely
+based on organizational security policies.
+The complete list of the assurance components of the explicit assurance package can be found in
+chapter 7.2.
+Bundesamt für Sicherheit in der Informationstechnik 9
+ FSDPP_OSP
+4. Security Problem Definition
+4.1 External entities
+The following external entities interact with the TOE:
+TOE administrator: The TOE administrator is authorized to perform administrative TOE
+operations and able to use the administrative functions of the TOE.
+The administrator is also responsible for the installation and maintenance of
+the TOE.
+Depending on the concrete implementation of a TOE there may be more than
+one administrator and consequently also more than one administrative role.
+User: A person who uses a biometric system that is protected by the TOE to get
+enrolled, identified or verified and is therefore checked by the biometric spoof
+detection system.
+4.2 Assets
+The following assets are defined in the context of this Protection Profile.
+Primary assets: The primary assets do not belong to the TOE itself. The primary scope of the
+biometric spoof detection system is the protection of the biometric system
+behind it. As such any asset that is protected by the biometric system can be
+considered being a primary asset for the TOE.
+Formally, the decision that is taken by the TOE (fake/no fake) can be
+considered being the primary asset.
+Secondary assets: Secondary assets (i.e. TSF data) are information which are used by the TOE to
+provide its core services and which consequently will need to be protected. The
+following assets should be explicitly mentioned for the TOE:
+● Spoof detection parameters (SDP): These (configuration) data
+include the settings necessary to detect a spoofed biometric
+characteristic, e. g., temperature limits, general threshold settings,
+typical movement patterns. These parameters may be specific for a
+claimed identity. The parameters are partly produced during
+development of the TOE but may be adjusted during installation,
+maintenance and enrollment. The integrity and confidentiality of these
+parameters will have to be protected.
+● Spoofing evidence (SE): This data is acquired by the capture device
+and/or separated dedicated sensor devices for the purpose of spoof
+detection. The TOE decides about a finger being a fake or not based on
+this data. The integrity and confidentiality of this data have to be
+protected.
+● Audit data (AD): This data comprises the audit information that is
+generated by the TOE. The integrity, confidentiality and authenticity of
+the information has to be protected.
+10 Bundesamt für Sicherheit in der Informationstechnik
+ FSDPP_OSP
+4.3 Assumptions
+A.BIO The spoof detection system addressed in this Protection Profile is a protection
+mechanism against spoofing attacks.
+The biometric system that is protected by the TOE therefore ensures that all
+threats that are not related to spoof detection are appropriately handled.
+Further, the biometric system ensures that the functionality of the TOE is
+invoked/used in order to protected the biometric system against spoof attacks.
+It is also assumed that the fingerprint sample that is acquired by the capture
+devices belongs to the fingerprint that is used for spoof detection.
+4.4 Threats
+No threats have been defined in the Security Problem Definition of this PP as it is solely based on
+organizational security policies.
+4.5 Organizational Security Policies
+OSP.SPOOF_DETECTION The TOE shall be able to detect whether a presented fingerprint is
+spoofed or genuine. The spoof detection shall be adequate to detect
+all artificial biometric characteristics listed and described in
+[Toolbox].
+OSP.RESIDUAL The TOE shall ensure that no residual or unprotected security
+relevant data remain in memory after operations are completed.
+OSP.MANAGEMENT The TOE shall provide the necessary management functionality
+for the modification of security relevant parameters for TOE
+administrators. Only secure values shall be used for such
+parameters.
+OSP.AUDIT In order to
+● generate statistics that can be used to adjust the parameters
+for better quality (maintenance),
+● trace modification, and
+● trace possible attacks,
+the TOE shall record security-relevant events.
+Bundesamt für Sicherheit in der Informationstechnik 11
+ FSDPP_OSP
+5. Security Objectives
+5.1 Security Objectives for the TOE
+O.SPOOF_DETECTION The TOE shall be able to detect whether a presented fingerprint is
+spoofed or genuine.
+The spoofing evidence may be extracted from the data provided by the
+same sensor that is used to acquire the biometric characteristic for
+recognition (by the biometric system in the environment), or it may be
+retrieved using sensors which are solely dedicated to spoof detection.
+O.AUDIT The TOE shall produce audit records at least for the following security
+relevant events:
+● A use of the TOE where a faked fingerprint has been detected
+● A use of the TOE where a genuine fingerprint has been
+detected
+● Every use of a management function
+● All parameters modified by the management functions
+O.RESIDUAL The TOE shall ensure that no residual or unprotected security relevant
+data remain in memory after operations are completed.
+O.MANAGEMENT The TOE shall provide the necessary management functionality for the
+modification of security relevant parameters to TOE administrators
+only.
+As part of this management functionality the TOE shall only accept
+secure values for security relevant parameters to ensure the correct
+operation of the TOE.
+5.2 Security objectives for the operational environment
+OE.ADMINISTRATION The TOE administrator is well trained and non hostile. They read the
+guidance documentation carefully, completely understands and
+applies it.
+The TOE administrator is responsible for the secure installation and
+maintenance of the TOE and its platform and oversees the biometric
+spoof detection system requirements. In particular, the administrator
+shall ensure that all environmental factors (e. g., lighting,
+electromagnetic fields) are within an acceptable range with respect to
+the used capture and sensor devices.
+The administrator assures that audit records of the TOE are regularly
+reviewed in order to detect and prevent attacks being performed
+against the TOE.
+OE.PHYSICAL It shall be ensured that the TOE and its components are physically
+protected against unauthorized access or modification. Physical
+access to the hardware that is used by the TOE is only allowed for
+authorized administrators.
+This does not have to cover the capture device that has to be
+accessible for every user.
+12 Bundesamt für Sicherheit in der Informationstechnik
+ FSDPP_OSP
+OE.PLATFORM The platform the TOE runs on shall provide the TOE with services
+necessary for its correct operation. Specifically the platform shall
+• identify and authenticate TOE administrators,
+• restrict to use the management functions of the TOE in order
+to query, modify, delete, and clear security parameters which
+are important for the operation of the TOE to TOE
+administrators,
+• provide access control for all secondary assets (spoof
+detection parameters, spoofing evidence, and audit data) and
+the software parts of the TOE,
+• provide a secure communication and storage of information
+where security relevant data is transferred to or from the
+TOE,
+• provide functionality for storage and review of audit
+information and ensure that only authorized administrators
+have access to the audit logs,
+• provide reliable time stamps that can be used by the TOE,
+and
+• be free of malware like viruses, trojan horses, and other
+malicious software.
+OE.BIO The spoof detection system described in this Protection Profile is a
+protection mechanism which ensures that spoofed fingerprints are
+rejected by the TOE. The TOE only addresses the detection of spoof
+attacks.
+The biometric system that is protected by the TOE shall therefore
+ensure that all threats that are not related to spoof detection are
+appropriately handled.
+Further, the biometric system shall ensure that the functionality of the
+TOE is invoked/used in order to protected the biometric system
+against spoof attacks.
+5.3 Security Objectives rationale
+5.3.1 Overview
+The following table gives an overview of how the assumptions, threats, and organizational security
+policies are addressed by the security objectives of the TOE. The text of the following sections
+justifies this in more detail. Aspects of the TOE operational environment are marked grey.
+Bundesamt für Sicherheit in der Informationstechnik 13
+ FSDPP_OSP
+O.SPOOF_DETECTION
+O.AUDIT
+O.RESIDUAL
+O.MANAGEMENT
+OE.ADMINISTRATION
+OE.PHYSICAL
+OE.PLATFORM
+OE.BIO
+OSP.SPOOF_DETECTION X X X X X
+OSP.MANAGEMENT X X X X
+OSP.RESIDUAL X X X X
+OSP.AUDIT X X
+A.BIO X
+Table 1: Security Objectives Rationale
+5.3.2 Justification for coverage of assumptions
+The only assumption A.BIO is covered by security objective OE.BIO as directly follows.
+5.3.3 Justification for the coverage of organizational security policies
+5.3.3.1 OSP.SPOOF_DETECTION
+The organisational security policy OSP.SPOOF_DETECTION is covered by the security objective
+O.SPOOF_DETECTION which is supported by O.MANAGEMENT, OE.ADMINISTRATION,
+OE.PHYSICAL, and OE.PLATFORM..
+O.SPOOF_DETECTION detects whether a presented fingerprint is spoofed or genuine, and
+performs appropriate actions in case of a spoofed and in case of a genuine fingerprint. Therefore, a
+spoofed fingerprint will not be used by the Biometric System being behind the TOE. This objective
+covers the main part of the OSP.
+O.MANAGEMENT provides necessary management functionality for the modification of security
+relevant parameters to TOE administrators which are authenticated and authorized by the TOE
+platform as stated in OE.PLATFORM. TOE administrators are well-trained and non-hostile
+according to OE.ADMINISTRATION and will therefore unlikely misconfigure the spoof detection
+functionality. All three objectives ensure that the spoof detection is securely managed and therefore
+support that spoof detection performs as intended.
+OE.PHYSICAL ensures that the TOE is physically protected against manipulation so that the spoof
+detection functionality can not be compromised using physically means.
+OE.PLATFORM further ensures that the platform for the TOE provides secure communication and
+storage of data and ensures that the TOE is free of malware which could otherwise compromise the
+spoof detection.
+OE.ADMINISTRATION further ensures that environmental factors which influence the capture and
+sensor devices are within acceptable ranges. It therefore supports that the spoof detection functionality
+is not compromised by environmental conditions.
+14 Bundesamt für Sicherheit in der Informationstechnik
+ FSDPP_OSP
+5.3.3.2 OSP.MANAGEMENT
+OSP.MANAGEMENT is covered by the security objectives O.MANAGEMENT which is supported
+by OE.ADMINISTRATION, OE.PHYSICAL, and OE.PLATFORM..
+O.MANAGEMENT provides the necessary management functionality to securely modify security
+parameters. It comprises the main part to cover the OSP. It is supported by OE.PLATFORM which
+ensures that only authenticated TOE administrators are authorized to manage the TOE.
+OE.ADMINISTRATION thereby ensures that these TOE administrators are well-trained and non-
+hostile so that misconfiguration is unlikely.
+OE.PHYSICAL ensures that the TOE is physically protected against manipulation so that
+management functionality can not be altered by physically means.
+OE.PLATFORM further ensures that the platform for the TOE provides secure communication and
+storage of data and ensures that the TOE is free of malware which could otherwise compromise the
+management functionality.
+5.3.3.3 OSP.RESIDUAL
+OSP.RESIDUAL is covered by security objective O.RESIDUAL which is supported by
+OE.ADMINISTRATION, OE.PHYSICAL, and OE.PLATFORM..
+O.RESIDUAL ensures that no residual or unprotected security relevant data remains after operations
+are completed and therefore residual security relevant data from a previous usage of the TOE can not
+be used by an attacker. It comprises the main part to cover the OSP. It is supported by
+OE.PHYSICAL which ensures that the TOE is physically protected against manipulation and
+therefore residual information can not be obtained via physical attacks.
+OE.PLATFORM ensures that the TOE platform is free of malware and therefore does not
+compromise functionality for residual information protection. OE.ADMINISTRATION supports that
+as it ensures that the platform is securely installed by the TOE administrator.
+5.3.3.4 OSP.AUDIT
+The organizational security policy OSP.AUDIT is covered by O.AUDIT which is supported by
+OE.PLATFORM..
+O.AUDIT ensures that the TOE generates audit records for security relevant events and therefore
+comprises the main part to cover the OSP.
+OE.PLATFROM ensures that the environment provides the time stamps necessary for audit, the
+secure storage for audit data, and mechanisms for review of audit data. It therefore supports the task of
+O.AUDIT.
+Bundesamt für Sicherheit in der Informationstechnik 15
+ FSDPP_OSP
+6. Extended Component definition
+The extended functional family FPT_SPOD (Biometric Spoof Detection) of the Class FPT (Protection
+of the TSF) has been defined here to describe the core security function as provided by the TOE
+described in this PP: The TOE shall prevent that a spoofed biometric characteristics can be used with a
+biometric system that is protected by the TOE. The class FPT (Protection of the TSF) as defined in
+part II of Common Criteria has been selected even if the functionality to be protected is not part of the
+TOE. The following chapter contains the detailed definition.
+6.1 FPT_SPOD Biometric Spoof Detection
+Family behavior
+This family defines functional requirements to detect spoofed biometric characteristics.
+Component leveling:
+FPT_SPOD Biometric Spoof Detection 1
+FPT_SPOD.1 Biometric Spoof Detection has four elements:
+FPT_SPOD.1.1 FPT_SPOD.1.1 requires to provide spoof detection functionality for a specific
+biometric characteristic.
+FPT_SPOD.1.2 FPT_SPOD.1.2 defines actions to be performed if a spoofed biometric
+characteristic is detected.
+FPT_SPOD.1.3 FPT_SPOD.1.3 defines actions to be performed if a genuine biometric
+characteristic is detected.
+FPT_SPOD.1.4 FPT_SPOD.1.4 defines additional information returned with the feedback about
+spoof status.
+Management: FPT_SPOD.1
+The following actions could be considered for the management functions in FMT:
+a) Management of the parameters used for spoofed detection.
+Audit: FPT_SPOD.1
+The following actions should be auditable if FAU_GEN Security audit data generation is included in
+the PP/ST:
+a) Basic: spoof detected
+b) Basic: no spoof detected
+16 Bundesamt für Sicherheit in der Informationstechnik
+ FSDPP_OSP
+6.1.1 Biometric Spoof Detection (FPT_SPOD.1)
+FPT_SPOD.1 Biometric Spoof Detection
+FPT_SPOD.1.1 The TSF shall be able to detect whether a presented [assignment: biometric
+characteristic] is spoofed or genuine.
+FPT_SPOD.1.2 If a spoofed biometric characteristic is detected, the following action(s) shall be
+performed:
+● [assignment: list of actions]
+FPT_SPOD.1.3 If a genuine biometric characteristic is detected, the following action(s) shall be
+performed:
+● [assignment: list of actions]
+FPT_SPOD.1.4 Along with the feedback about the spoof status of the presented biometric
+characteristic the TOE shall deliver the following information:
+● [assignment: list of information]
+Hierarchical to: No other components
+Dependencies: FMT_MTD.3 Secure TSF data
+FMT_SMF.1 Specification of Management Functions
+6.1.2 Justification for the definition of functional family FPT_SPOD
+Spoof detection functionality describes mechanisms that protect biometric systems like fingerprint
+verification systems against threats of non-genuine biometric characteristics like fake fingers. It
+therefore provides protection of the TSF which is subject of the functional class FPT.
+There is no family in FPT that deals with detection of spoofing attacks or biometric functionality at all,
+therefore a new family has been defined.
+Bundesamt für Sicherheit in der Informationstechnik 17
+ FSDPP_OSP
+7. Security Requirements
+This chapter describes the security functional and the assurance requirements which have to be
+fulfilled by the TOE.
+Those requirements comprise functional components from part II of [CC] and assurance components
+from part III of [CC]. Further the extended requirement FPT_SPOD.1 as defined in chapter 6 is used.
+The following notations are used to mark operations that have been performed:
+● Selection operations (used to select one or more options provided by the [CC] in stating a
+requirement.) are denoted by underlined text
+● Assignment operation (used to assign a specific value to an unspecified parameter, such as the
+length of a password) are denoted by italicized text.
+● No Refinements have been performed
+● No Iterations have been performed.
+7.1 Security Functional Requirements for the TOE
+The following table summarizes all security functional requirements of this PP:
+Class FAU: Security Audit
+FAU_GEN.1 Audit Data Generation
+Class FDP: User Data Protection
+FDP_RIP.2 Full residual information protection
+Class FMT: Security Management
+FMT_MTD.3 Secure TSF data
+FMT_SMF.1 Specification of Management Functions
+Class FPT: Protection of the TSF
+FPT_SPOD.1 Spoof Detection
+Table 2: Security Functional Requirements
+18 Bundesamt für Sicherheit in der Informationstechnik
+ FSDPP_OSP
+7.1.1 Security audit (FAU)
+7.1.1.1 Security audit data generation (FAU_GEN)
+FAU_GEN.1 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) All auditable events for the [basic] level of audit; and
+c) [modification of Spoof Detection Parameters, and
+d) [assignment: other specifically defined auditable events]].
+FAU_GEN.1.2 The TSF shall record within each audit record at least the following information:
+a) Date and time of the event, type of event, subject identity (if applicable), and the
+outcome (success or failure) of the event; and
+b) For each audit event type, based on the auditable event definitions of the
+functional components included in the PP/ST, [assignment: other audit relevant
+information].
+Hierarchical to: No other components
+Dependencies: FPT_STM.1
+Application Note: According to the chosen level of audit and the SFRs contained in this PP the
+TOE has to audit the following event per minimum:
+● A use of the TOE where a faked fingerprint has been detected
+(FPT_SPOD.1)
+● A use of the TOE where a genuine fingerprint has been detected
+(FPT_SPOD.1)
+● Every use of a management function (FMT_SMF.1)
+● All parameters rejected by the management functions (FMT_SMF.3)
+If useful in the context of a concrete technology the ST author should consider
+to audit additional information (e.g. a score or a claimed identity) together with
+the first two events.
+7.1.2 User data protection (FDP)
+7.1.2.1 Residual information protection (FDP_RIP)
+FDP_RIP.2 Full residual information protection
+FDP_RIP.2.1 The TSF shall ensure that any previous information content of a resource is made
+unavailable upon the [deallocation of the resource from] all objects.
+Hierarchical to: FDP_RIP.1
+Dependencies: No dependencies
+Bundesamt für Sicherheit in der Informationstechnik 19
+ FSDPP_OSP
+7.1.3 Security management (FMT)
+7.1.3.1 Management of TSF data (FMT_MTD)
+FMT_MTD.3 Secure TSF data
+FMT_MTD.3.1 The TSF shall ensure that only secure values are accepted for [
+● [assignment: list of all spoof detection parameters]
+● [assignment: list of other TSF data or none]
+]
+Hierarchical to: No other components
+Dependencies: FMT_MTD.1
+Application Note: The assignment in FMT_MTD.3.1 (list of all spoof detection parameters)
+represents the minimum of parameters for which the TOE has to ensure
+secure settings. The objective O.MANAGEMENT however requires that the
+TOE has to ensure secure values for all security relevant parameters.
+As the list of those parameters depends on the concrete technology the ST
+author shall add all security relevant parameters to this assignment.
+7.1.3.2 Specification of Management Functions (FMT_SMF.1)
+FMT_SMF.1 Specification of Management Functions
+FMT_SMF.1.1 The TSF shall be capable of performing the following management
+functions: [assignment: list of management functions to be provided by the
+TSF].
+Hierarchical to: No other components
+Dependencies: No dependencies
+Application Note: The necessary management functions are highly depending on the necessary
+information for the core functionality as defined in FPT_SPOD.1. The ST
+author shall consider all relevant parameters and decide whether a
+management function will be necessary for each.
+20 Bundesamt für Sicherheit in der Informationstechnik
+ FSDPP_OSP
+7.1.4 Protection of the TSF (FPT)
+7.1.4.1 Biometric Spoof Detection (FPT_SPOD.1)
+FPT_SPOD.1 Biometric Spoof Detection
+FPT_SPOD.1.1 The TSF shall be able to detect whether a presented [fingerprint] is spoofed or
+genuine.
+FPT_SPOD.1.2 If a spoofed biometric characteristic is detected, the following action(s) shall be
+performed:
+● [assignment: list of actions]
+FPT_SPOD.1.3 If a genuine biometric characteristic is detected, the following action(s) shall be
+performed:
+● [assignment: list of actions]
+FPT_SPOD.1.4 Along with the feedback about spoof status of the presented biometric
+characteristic the TOE shall deliver the following information:
+● [assignment: list of information]
+Hierarchical to: No other components
+Dependencies: FMT_MTD.3 Secure TSF data
+FMT_SMF.1 Specification of Management Functions
+Application Note: FPT_SPOD.1 represents the core functionality to be provided by the TOE.
+Due to the special character of this technology additional guidance for
+evaluation is provided in form of [FSDEG]. This guidance shall be applied
+during evaluation.
+Application Note: Please note that any use of residual information that remains on a sensor
+device is considered being a spoofed characteristic in the context of this
+SFR.
+Application Note: In FPT_SPOD.1.4, the ST author should list all additional information that
+shall be delivered by the spoof detection functionality to the integrating
+biometric system. Such information could be an additional score value that
+represents the likelihood that the presented biometric characteristic is
+spoofed. However, the ST author should understand that such information is
+sensitive as an attacker could use it to improve his attacks. Such information
+shall not be visible to the user of the biometric system.
+Bundesamt für Sicherheit in der Informationstechnik 21
+ FSDPP_OSP
+7.2 Security Assurance Requirements for the TOE
+Due to the special character of the technology described in this PP, the following explicit assurance
+package has been defined for the TOE based on EAL 2. In contrast to EAL 2, it does not contain
+AVA_VAN.2 but is augmented by ALC_FLR.1.
+The following table lists the assurance components which are chosen for this PP.
+Assurance Class Assurance Component Title
+Development ADV_ARC.1 Security architecture description
+ADV_FSP.2 Security-enforcing functional specification
+ADV_TDS.1 Basic Design
+Guidance documents AGD_OPE.1 Operational User Guidance
+AGD_PRE.1 Preparative Procedures
+Life-cycle support ALC_CMC.2 Use of a CM system
+ALC_CMS.2 Parts of the TOE CM coverage
+ALC_DEL.1 Delivery procedures
+ALC_FLR.1 Basic flaw remediation
+Security Target Evaluation ASE_CCL.1 Conformance claims
+ASE_ECD.1 Extended component definition
+ASE_INT.1 ST introduction
+ASE_OBJ.2 Security Objectives
+ASE_REQ.2 Derived Security Requirements
+ASE_SPD.1 Security problem definition
+ASE_TSS.1 TOE summary specification
+Tests ATE_COV.1 Evidence of coverage
+ATE_FUN.1 Functional testing
+ATE_IND.2 Independent testing - sample
+Table 3: Assurance Requirements
+Due to the special character of the technology described in this PP, the Spoof Detection Evaluation
+Methodology [FSDEG] shall be applied during evaluation. This methodology will provide the
+evaluator with additional information and guidance for some assurance requirements.
+22 Bundesamt für Sicherheit in der Informationstechnik
+ FSDPP_OSP
+7.3 Security Requirements rationale
+7.3.1 Security Functional Requirements rationale
+7.3.1.1 Fulfillment of the Security Objectives
+This chapter proves that the set of security requirements (TOE) is suited to fulfill the security
+objectives described in chapter 4 and that each SFR can be traced back to the security objectives. At
+least one security objective exists for each security requirement.
+O.AUDIT
+O.
+RESIDUAL
+O.MANAGEMENT
+O.SPOOF_DETECTION
+FAU_GEN.1 X
+FDP_RIP.2 X
+FMT_MTD.3 X
+FMT_SMF.1 X
+FPT_SPOD.1 X
+Table 4:Fulfillment of Security Objectives
+The following paragraphs contain more details on this mapping.
+O.AUDIT
+● FAU_GEN.1 defines that the TOE has to capture all the events as required by O.AUDIT.
+O.RESIDUAL
+● This objective is completely covered by FDP_RIP.2 as directly follows.
+O.MANAGEMENT
+● FMT_MTD.1 defines that the TOE only accepts secure values for spoof detection parameters
+so that the spoof detection works correctly.
+● FMT_SMF.1 ensures that the TOE provides the necessary management functionality
+O.SPOOF_DETECTION
+● FPT_SPOD.1 defines that the TOE is able to detect whether a presented fingerprint is
+spoofed or genuine and therewith directly addresses this objective.
+7.3.1.2 Fulfillment of the dependencies
+The following table summarizes all TOE functional requirements dependencies of this PP and
+demonstrates that they are fulfilled.
+Bundesamt für Sicherheit in der Informationstechnik 23
+ FSDPP_OSP
+SFR Dependencies Fulfilled by
+FAU_GEN.1 FPT_STM.1 See chapter 7.3.1.3
+FDP_RIP.2 - -
+FMT_MTD.3 FMT_MTD.1 See chapter 7.3.1.3
+FMT_SMF.1 - -
+FPT_SPOD.1 FMT_MTD.3
+FMT_SMF.1
+FMT_MTD.3
+FMT_SMF.1
+Table 5: Security Functional Requirements
+7.3.1.3 Justification for missing dependencies
+The functional component FAU_GEN.1 has an identified dependency on FPT_STM.1. This
+dependency is not satisfied by any TOE functional requirement as the functionality of reliable time
+stamps is provided by the TOE environment (OE.PLATFORM).
+The functional component FMT_MTD.3 has an identified dependency on FMT_MTD.1. This
+dependency is not satisfied by any TOE functional requirement as the functionality of restricting the
+ability to query, modify, delete, and clear security parameters to TOE administrators is provided by the
+TOE environment (see OE.PLATFORM).
+7.3.2 Security Assurance Requirements rationale
+Due to the special character of the technology described in this PP, an explicit assurance package has
+been defined for the TOE. It has been chosen for this Protection Profile as it should focus on
+application cases for which it is sufficient to determine whether the security functionality claimed by a
+TOE is working correctly without performing a dedicated vulnerability assessment.
+The defined assurance package has been developed based on EAL 2. In contrast to EAL 2, it does not
+contain AVA_VAN.2 but has been augmented by the assurance component ALC_FLR.1. ALC_FLR.1
+has been included as spoof detection systems are supposed to have flaws that will be found in future
+and that will then have to be addressed.
+Additional guidance has been provided for some of the assurance components due to the special nature
+of the biometric technology in form of [FSDEG].
+7.3.2.1 Dependencies of assurance components
+The dependencies of the assurance requirements are fulfilled as shown in Table 6:
+Assurance Class Assurance
+Component
+Dependencies Fulfillment
+Development ADV_ARC.1 ADV_FSP.1,
+ADV_TDS.1
+ADV_FSP.2,
+ADV_TDS.1
+ADV_FSP.2 ADV_TDS.1 ADV_TDS.1
+ADV_TDS.1 ADV_FSP.2 ADV_FSP.2
+Guidance documents AGD_OPE.1 ADV_FSP.1 ADV_FSP.2
+AGD_PRE.1 No dependencies -
+Life-cycle support ALC_CMC.2 ALC_CMS.1 ALC_CMS.2
+24 Bundesamt für Sicherheit in der Informationstechnik
+ FSDPP_OSP
+Assurance Class Assurance
+Component
+Dependencies Fulfillment
+ALC_CMS.2 No dependencies -
+ALC_DEL.1 No dependencies -
+ALC_FLR.1 No dependencies -
+Security Target
+Evaluation
+ASE_CCL.1 ASE_INT.1,
+ASE_ECD.1,
+ASE_REQ.1
+ASE_INT.1,
+ASE_ECD.1,
+ASE_REQ.2
+ASE_ECD.1 No dependencies -
+ASE_INT.1 No dependencies -
+ASE_OBJ.2 ASE_SPD.1 ASE_SPD.1
+ASE_REQ.2 ASE_OBJ.2,
+ASE_ECD.1
+ASE_OBJ.2,
+ASE_ECD.1
+ASE_SPD.1 No dependencies -
+ASE_TSS.1 ASE_INT.1,
+ASE_REQ.1
+ADV_FSP.1
+ASE_INT.1,
+ASE_REQ.2
+ADV_FSP.2
+Tests ATE_COV.1 ADV_FSP.2,
+ATE_FUN.1
+ADV_FSP.2,
+ATE_FUN.1
+ATE_FUN.1 ATE_COV.1 ATE_COV.1
+ATE_IND.2 ADV_FSP.2,
+AGD_OPE.1,
+AGD_PRE.1,
+ATE_COV.1,
+ATE_FUN.1
+ADV_FSP.2,
+AGD_OPE.1,
+AGD_PRE.1,
+ATE_COV.1,
+ATE_FUN.1
+Table 6: Dependencies of assurance components
+Bundesamt für Sicherheit in der Informationstechnik 25
+ FSDPP_OSP
+8. Appendix
+8.1 Glossary
+Term Description
+AD Audit data
+Audit data Content of the audit trace generated by the TOE.
+Attacker An attacker in the context of this PP is any individual who is attempting to
+subvert the operation of the biometric system protected by the TOE using a
+faked fingerprint.
+This does explicitly included cases in which users try to subvert the operation
+of the TOE directly but in any case it is the final focus of an attacker to
+subvert the operation of the protected biometric system using a faked
+fingerprint.
+Biometric A measurable physical characteristic or personal behavioral trait used to
+recognize the identity of a user or verify a claimed identity.
+Biometric
+identification
+Application in which a search of the enrolled database is performed, and a
+candidate list of 0, 1 or more identifiers is returned.
+Biometric system An automated system capable of capturing a biometric sample from a user,
+extracting biometric data from the sample, comparing the data with one or
+more biometric references, deciding on how well they match, and indicating
+whether or not an identification or verification of identity has been achieved.
+Note that in [CC] evaluation terms, a biometric system may be a product or
+part of a system.
+Biometric verification The objective of a verification process is to verify or refuse the claimed
+identity of a user based on their biometric characteristic.
+CC Common Criteria - Common Criteria for Information Technology Security
+Evaluation
+CEM Common Evaluation Methodology
+EAL Evaluation Assurance Level
+FAU Class of functional requirements for audit
+FDP Class of functional requirements for data protection
+FMT Class of functional requirements for management
+FPT Class of functional requirements for TSF protection
+Identification system Biometric system that provides an identification function (see also biometric
+identification)
+I&A Identification and authentication
+LAN Local Area Network
+OS Operating system
+26 Bundesamt für Sicherheit in der Informationstechnik
+ FSDPP_OSP
+Term Description
+PP Protection Profile - An implementation-independent set of security
+requirements for a category of TOEs that meet specific consumer needs.
+SDP Spoof detection parameters
+Sensor The physical hardware device used for biometric capture. Also called capture
+device
+SFR Security Functional Requirement
+ST Security Target – A set of implementation-dependent security requirements
+for a specific TOE.
+Spoof detection
+parameters
+Settings (configuration data) necessary to detect a spoofed biometric
+characteristic, e. g., temperature limits, thresholds, typical movement
+patterns.
+Spoofing evidence Information that is acquired from a biometric characteristic to decide whether
+it is spoofed or genuine.
+Threshold A parametric value used to convert a matching score to a decision.
+TOE Target of Evaluation
+TSF TOE Security Functionality.
+Verification system A biometric system that provides verification functionality.
+WAN Wide Area Network
+WLAN Wireless Local Area Network
+8.2 References
+[FSDPP] Fingerprint Spoof Detection Protection Profile, version 1.8, November 2009
+[Toolbox] Standard Fake Finger Toolbox for Common Criteria evaluations of Spoof
+Detection systems, as referenced in [FSDEG]
+[FSDEG] Fingerprint Spoof Detection Evaluation Guidance, version 2.0 (or a more recent
+version)
+[CC] Common Criteria for Information Technology Security Evaluation –
+● Part 1: Introduction and general model, dated
+July 2009, version 3.1 R3
+● Part 2: Security functional requirements, dated July 2009, version 3.1,
+R3
+● Part 3: Security assurance requirements, dated July 2009, version 3.1,
+R3
+[CEM] Common Evaluation Methodology for Information Technology Security –
+Evaluation Methodology, dated July 2009, version 3.1 R3
+Bundesamt für Sicherheit in der Informationstechnik 27
+
diff --git a/tests/data/protection_profiles/reports/pdf/b02ed76d2545326a.pdf b/tests/data/protection_profiles/reports/pdf/b02ed76d2545326a.pdf
new file mode 100644
index 00000000..9afbdc2a
Binary files /dev/null and b/tests/data/protection_profiles/reports/pdf/b02ed76d2545326a.pdf differ
diff --git a/tests/data/protection_profiles/reports/txt/b02ed76d2545326a.txt b/tests/data/protection_profiles/reports/txt/b02ed76d2545326a.txt
new file mode 100644
index 00000000..81796a86
--- /dev/null
+++ b/tests/data/protection_profiles/reports/txt/b02ed76d2545326a.txt
@@ -0,0 +1,701 @@
+BSI-CC-PP-0062-2010
+for
+Fingerprint Spoof Detection Protection Profile
+based on Organisational Security Policies
+(FSDPP_OSP), Version 1.7
+from
+German Federal Office for
+Information Security (BSI)
+ BSI - Bundesamt für Sicherheit in der Informationstechnik, Postfach 20 03 63, D-53133 Bonn
+Phone +49 (0)228 99 9582-0, Fax +49 (0)228 9582-5477, Infoline +49 (0)228 99 9582-111
+Certification Report V1.0 ZS-01-01-F-414 V1.40
+ BSI-CC-PP-0062-2010
+Common Criteria Protection Profile
+Fingerprint Spoof Detection Protection Profile based on
+Organisational Security Policies (FSDPP_OSP),
+Version 1.7
+developed by the German Federal Office for Information Security (BSI)
+Assurance Package claimed in the Protection Profile:
+Common Criteria Part 3 conformant
+ADV_ARC.1, ADV_FSP.2, ADV_TDS.1, AGD_OPE.1,
+AGD_PRE.1, ALC_CMC.2, ALC_CMS.2, ALC_DEL.1,
+ALC_FLR.1, ASE_CCL.1, ASE_ECD.1, ASE_INT.1,
+ASE_OBJ.2, ASE_REQ.2, ASE_SPD.1, ASE_TSS.1,
+ATE_COV.1, ATE_FUN.1, ATE_IND.2
+Common Criteria
+Recognition
+Arrangement
+The Protection Profile identified in this certificate has been evaluated at an approved evaluation facility using
+the Common Methodology for IT Security Evaluation (CEM), Version 3.1 for conformance to the Common
+Criteria for IT Security Evaluation (CC), Version 3.1.
+This certificate applies only to the specific version and release of the Protection Profile and in conjunction
+with the complete Certification Report.
+The evaluation has been conducted in accordance with the provisions of the certification scheme of the
+German Federal Office for Information Security (BSI) and the conclusions of the evaluation facility in the
+evaluation technical report are consistent with the evidence adduced.
+This certificate is not an endorsement of the Protection Profile by the Federal Office for Information Security
+or any other organisation that recognises or gives effect to this certificate, and no warranty of the Protection
+Profile by the Federal Office for Information Security or any other organisation that recognises or gives effect
+to this certificate, is either expressed or implied.
+Bonn, 25. February 2010
+For the Federal Office for Information Security
+Bernd Kowalski L.S.
+Head of Department
+Bundesamt für Sicherheit in der Informationstechnik
+Godesberger Allee 185-189 - D-53175 Bonn - Postfach 20 03 63 - D-53133 Bonn
+Phone +49 (0)228 99 9582-0 - Fax +49 (0)228 9582-5477 - Infoline +49 (0)228 99 9582-111
+ Certification Report BSI-CC-PP-0062-2010
+This page is intentionally left blank.
+4 / 28
+ BSI-CC-PP-0062-2010 Certification Report
+Preliminary Remarks
+Under the BSIG1
+Act, the Federal Office for Information Security (BSI) has the task of
+issuing certificates for information technology products as well as for Protection Profiles
+(PP).
+A PP defines an implementation-independent set of IT security requirements for a
+category of products which are intended to meet common consumer needs for IT security.
+The development and certification of a PP or the reference to an existent one gives
+consumers the possibility to express their IT security needs without referring to a special
+product. Product or system certifications can be based on Protection Profiles. For products
+which have been certified based on a Protection Profile an individual certificate will be
+issued.
+Certification of the Protection Profile is carried out on the instigation of the BSI or a
+sponsor.
+A part of the procedure is the technical examination (evaluation) of the Protection Profile
+according to Common Criteria [1].
+The evaluation is normally carried out by an evaluation facility recognised by the BSI or by
+BSI itself.
+The result of the certification procedure is the present Certification Report. This report
+contains among others the certificate (summarised assessment) and the detailed
+Certification Results.
+1
+Act on the Federal Office for Information Security (BSI-Gesetz - BSIG) of 14 August 2009,
+Bundesgesetzblatt I p. 2821
+5 / 28
+ Certification Report BSI-CC-PP-0062-2010
+Contents
+A Certification........................................................................................................................7
+1 Specifications of the Certification Procedure.................................................................7
+2 Recognition Agreements................................................................................................7
+2.1 International Recognition of CC - Certificates.........................................................8
+3 Performance of Evaluation and Certification..................................................................8
+4 Validity of the certification result.....................................................................................9
+5 Publication......................................................................................................................9
+B Certification Results.........................................................................................................11
+1 Protection Profile Overview..........................................................................................12
+2 Security Functional Requirements...............................................................................12
+3 Security Assurance Requirements...............................................................................13
+4 Results of the PP-Evaluation........................................................................................13
+5 Obligations and notes for the usage............................................................................14
+6 Protection Profile Document.........................................................................................14
+7 Definitions.....................................................................................................................14
+7.1 Acronyms...............................................................................................................14
+7.2 Glossary.................................................................................................................14
+8 Bibliography..................................................................................................................15
+C Excerpts from the Criteria................................................................................................17
+D Annexes...........................................................................................................................27
+6 / 28
+ BSI-CC-PP-0062-2010 Certification Report
+A Certification
+1 Specifications of the Certification Procedure
+The certification body conducts the procedure according to the criteria laid down in the
+following:
+● BSIG2
+● BSI Certification Ordinance3
+● BSI Schedule of Costs4
+● Special decrees issued by the Bundesministerium des Innern (Federal Ministry
+of the Interior)
+● DIN EN 45011 standard
+● BSI certification: Procedural Description (BSI 7125) [3]
+● Common Criteria for IT Security Evaluation (CC), Version 3.15
+[1]
+● Common Methodology for IT Security Evaluation, Version 3.1[2]
+● BSI certification: Application Notes and Interpretation of the Scheme (AIS) [7]
+● Procedure for the Issuance of a PP certificate by the BSI
+2 Recognition Agreements
+In order to avoid multiple certification of the same Protection Profile in different countries a
+mutual recognition of IT security certificates - as far as such certificates are based on CC -
+under certain conditions was agreed.
+2
+Act on the Federal Office for Information Security (BSI-Gesetz - BSIG) of 14 August 2009,
+Bundesgesetzblatt I p. 2821
+3
+Ordinance on the Procedure for Issuance of a Certificate by the Federal Office for Information Security
+(BSI-Zertifizierungsverordnung, BSIZertV) of 07 July 1992, Bundesgesetzblatt I p. 1230
+4
+Schedule of Cost for Official Procedures of the Bundesamt für Sicherheit in der Informationstechnik
+(BSI-Kostenverordnung, BSI-KostV) of 03 March 2005, Bundesgesetzblatt I p. 519
+5
+Proclamation of the Bundesministerium des Innern of 12 February 2007 in the Bundesanzeiger dated
+23 February 2007
+7 / 28
+ Certification Report BSI-CC-PP-0062-2010
+2.1 International Recognition of CC - Certificates
+An arrangement (Common Criteria Arrangement) on the mutual recognition of certificates
+based on the CC evaluation assurance levels up to and including EAL 4 has been signed
+in May 2000 (CCRA). It includes also the recognition of Protection Profiles based on the
+CC.
+As of January 2009 the arrangement has been signed by the national bodies of: Australia,
+Austria, Canada, Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary,
+India, Israel, Italy, Japan, Republic of Korea, Malaysia, The Netherlands, New Zealand,
+Norway, Pakistan, Republic of Singapore, Spain, Sweden, Turkey, United Kingdom,
+United States of America. The current list of signatory nations resp. approved certification
+schemes can be seen on the web site: http://www.commoncriteriaportal.org
+The Common Criteria Arrangement logo printed on the certificate indicates that this
+certification is recognised under the terms of this agreement.
+3 Performance of Evaluation and Certification
+The certification body monitors each individual evaluation to ensure a uniform procedure, a
+uniform interpretation of the criteria and uniform ratings.
+The Fingerprint Spoof Detection Protection Profile based on Organisational Security
+Policies (FSDPP_OSP), Version 1.7 has undergone the certification procedure at BSI.
+The evaluation of the Fingerprint Spoof Detection Protection Profile based on
+Organisational Security Policies (FSDPP_OSP), Version 1.7 was conducted by the ITSEF
+SRC Security Research & Consulting GmbH. The evaluation was completed on
+10 December 2009. The ITSEF SRC Security Research & Consulting GmbH is an
+evaluation facility (ITSEF)6
+recognised by the certification body of BSI.
+For this certification procedure the sponsor and applicant is: German Federal Office for
+Information Security (BSI)
+The PP was developed by: TÜV Informationstechnik GmbH
+The certification is concluded with the comparability check and the production of this
+Certification Report. This work was completed by the BSI.
+6
+Information Technology Security Evaluation Facility
+8 / 28
+ BSI-CC-PP-0062-2010 Certification Report
+4 Validity of the certification result
+This Certification Report only applies to the version of the Protection Profile as indicated.
+In case of changes to the certified version of the Protection Profile, the validity can be
+extended to the new versions and releases, provided the sponsor applies for assurance
+continuity (i.e. re-certification or maintenance) of the modified Protection Profile, in
+accordance with the procedural requirements, and the evaluation does not reveal any
+security deficiencies.
+For the meaning of the assurance levels please refer to the excerpts from the criteria at
+the end of the Certification Report.
+5 Publication
+The Fingerprint Spoof Detection Protection Profile based on Organisational Security
+Policies (FSDPP_OSP), Version 1.7 has been included in the BSI list of the certified
+Protection Profiles, which is published regularly (see also Internet: https://www.bsi.bund.de
+and [4]). Further information can be obtained from BSI-Infoline +49 228 9582-111.
+Further copies of this Certification Report can be requested from the sponsor7
+of the
+Protection Profile. The Certification Report may also be obtained in electronic form at the
+internet address stated above.
+7
+Federal Office for Information Security (BSI)
+Godesberger Allee 185-189
+53175 Bonn
+9 / 28
+ Certification Report BSI-CC-PP-0062-2010
+This page is intentionally left blank.
+10 / 28
+ BSI-CC-PP-0062-2010 Certification Report
+B Certification Results
+The following results represent a summary of
+● the certified Protection Profile,
+● the relevant evaluation results from the evaluation facility, and
+● complementary notes and stipulations of the certification body.
+11 / 28
+ Certification Report BSI-CC-PP-0062-2010
+1 Protection Profile Overview
+The Fingerprint Spoof Detection Protection Profile based on Organisational Security
+Policies (FSDPP_OSP), Version 1.7 [6] is established by the German Federal Office for
+Information Security (BSI) as a basis for the development of Security Targets in order to
+perform a certification of an IT-product (TOE).
+The Target of Evaluation (TOE) described in the Protection Profile (PP) is a system that
+provides fingerprint spoof detection either as part of or in front of a biometric system for
+fingerprint recognition.
+The TOE determines whether a fingerprint presented to the biometric system is genuine or
+spoofed. The term spoofed biometric characteristics hereby refers to artificially created
+fake fingers which are currently known to circumvent fingerprint recognition systems.
+For this purpose the spoof detection system acquires spoofing evidences for a presented
+fingerprint using a sensor device. This sensor can either be part of the capture device that
+is used to capture the biometric sample of the fingerprint (or even be identical to it) or be a
+separate sensor device (or more than one) that is completely dedicated to spoof detection.
+Beside the fingerprint spoof detection functionality every TOE that claims conformance to
+the PP shall implement:
+● Management functionality to modify security relevant parameters
+● Quality control for management parameters
+● Audit functionality for security relevant events
+● Protection of residual and security relevant data
+The assets to be protected by a TOE claiming conformance to this PP are defined in the
+Protection Profile [6], chapter 4.2. Based on these assets the Security Problem Definition
+is defined in terms of Assumptions and Organisational Security Policies. This is outlined in
+the Protection Profile [6], chapters 4.3 to 4.5.
+These Assumptions and Organisational Security Policies are split into Security Objectives
+to be fulfilled by a TOE claiming conformance to this PP and Security Objectives to be
+fulfilled by the operational environment of a TOE claiming conformance to this PP. These
+Security Objectives are outlined in the PP [6], chapter 5.
+The Protection Profile [6] requires a Security Target based on this PP or another PP
+claiming this PP, to fulfil the CC requirements for strict conformance.
+2 Security Functional Requirements
+Based on the Security Objectives to be fulfilled by a TOE claiming conformance to this PP
+the security policy is expressed by the set of Security Functional Requirements to be
+implemented by a TOE. It covers the following issues: Biometric spoof detection, security
+audit, residual information protection and TOE security management.
+These TOE Security Functional Requirements (SFR) are outlined in the PP [6], chapter
+7.1. They are selected from Common Criteria Part 2 and one of them is newly defined.
+Thus the SFR claim is called:
+Common Criteria Part 2 extended
+12 / 28
+ BSI-CC-PP-0062-2010 Certification Report
+3 Security Assurance Requirements
+Due to the special character of the technology described in this PP, an explicit assurance
+package has been defined for the TOE. It has been chosen for this Protection Profile as
+the PP should focus on application cases for which it is sufficient to determine whether the
+Security Functionality claimed by a TOE is working correctly without performing a
+dedicated vulnerability assessment.
+The TOE security assurance package claimed in the Protection Profile is based entirely on
+the assurance components defined in part 3 of the Common Criteria. Thus, this assurance
+package is called:
+Common Criteria Part 3 conformant
+This explicit assurance package is based on EAL 2 and consists of the following
+Assurance Families:
+ADV_ARC.1, ADV_FSP.2, ADV_TDS.1, AGD_OPE.1, AGD_PRE.1,
+ALC_CMC.2, ALC_CMS.2, ALC_DEL.1, ALC_FLR.1, ASE_CCL.1,
+ASE_ECD.1, ASE_INT.1, ASE_OBJ.2, ASE_REQ.2, ASE_SPD.1,
+ASE_TSS.1, ATE_COV.1, ATE_FUN.1, ATE_IND.2
+(for the definition and scope of assurance packages according to CC see part C or [1],
+part 3 for details).
+The only differences compared to EAL 2 are the omitted AVA_VAN.2 assurance
+component and the added ALC_FLR.1 assurance component.
+Additional guidance in form of the Fingerprint Spoof Detection Evaluation Guidance [8]
+has been provided for some of the assurance components due to the special nature of
+the biometric technology.
+4 Results of the PP-Evaluation
+The Evaluation Technical Report (ETR) [5] was provided by the ITSEF according to the
+Common Criteria [1], the Methodology [2], the requirements of the Scheme [3] and all
+interpretations and guidelines of the Scheme (AIS) [7] as relevant for the TOE.
+As a result of the evaluation the verdict PASS is confirmed for the assurance components
+of the class APE.
+The following assurance components were used:
+APE_INT.1 PP introduction
+APE_CCL.1 Conformance claims
+APE_SPD.1 Security problem definition
+APE_OBJ.2 Security objectives
+APE_ECD.1 Extended components definition
+APE_REQ.2 Derived security requirements
+The results of the evaluation are only applicable to the Protection Profile as defined in
+chapter 1.
+13 / 28
+ Certification Report BSI-CC-PP-0062-2010
+5 Obligations and notes for the usage
+The following aspects need to be fulfilled when using the Protection Profile:
+Due to the special character of the technology described in this PP, the Fingerprint Spoof
+Detection Evaluation Guidance [8] shall be applied during evaluation. This document will
+provide the evaluator with additional information and guidance for some assurance
+requirements.
+6 Protection Profile Document
+The Fingerprint Spoof Detection Protection Profile based on Organisational Security
+Policies (FSDPP_OSP), Version 1.7 [6] is being provided within a separate document as
+Annex A of this report.
+7 Definitions
+7.1 Acronyms
+BSI Bundesamt für Sicherheit in der Informationstechnik / Federal Office for
+Information Security, Bonn, Germany
+CCRA Common Criteria Recognition Arrangement
+CC Common Criteria for IT Security Evaluation
+EAL Evaluation Assurance Level
+FSDPP Fingerprint Spoof Detection Protection Profile
+IT Information Technology
+ITSEF Information Technology Security Evaluation Facility
+OSP Organisational Security Policy
+PP Protection Profile
+SF Security Function
+SFP Security Function Policy
+ST Security Target
+TOE Target of Evaluation
+TSF TOE Security Functions
+7.2 Glossary
+Augmentation - The addition of one or more requirement(s) to a package.
+Extension - The addition to an ST or PP of functional requirements not contained in part 2
+and/or assurance requirements not contained in part 3 of the CC.
+Formal - Expressed in a restricted syntax language with defined semantics based on well-
+established mathematical concepts.
+Informal - Expressed in natural language.
+14 / 28
+ BSI-CC-PP-0062-2010 Certification Report
+Object - An passive entity in the TOE, that contains or receives information, and upon
+which subjects perform operations.
+Protection Profile - An implementation-independent statement of security needs for a
+TOE type.
+Security Target - An implementation-dependent statement of security needs for a specific
+identified TOE.
+Semiformal - Expressed in a restricted syntax language with defined semantics.
+Subject - An active entity in the TOE that performs operations on objects.
+Target of Evaluation - A set of software, firmware and/or hardware possibly accompanied
+by guidance.
+TOE Security Functionality - A set consisting of all hardware, software, and firmware of
+the TOE that must be relied upon for the correct enforcement of the SFRs.
+8 Bibliography
+[1] Common Criteria for Information Technology Security Evaluation, Version 3.1,
+Part 1: Introduction and general model, Revision 3, July 2009
+Part 2: Security functional components, Revision 3, July 2009
+Part 3: Security assurance components, Revision 3, July 2009
+[2] Common Methodology for Information Technology Security Evaluation (CEM),
+Evaluation Methodology, Version 3.1, Revision 3, July 2009
+[3] BSI certification: Procedural Description (BSI 7125)
+[4] German IT Security Certificates (BSI 7148, BSI 7149), periodically updated list
+published also on the BSI Website
+[5] Evaluation Technical Report, Version 1.2, 09 December 2009, Evaluation Technical
+Report (ETR) for a PP evaluation, Certification ID: BSI-CC-PP-0062, SRC Security
+Research & Consulting GmbH (confidential document)
+[6] Fingerprint Spoof Detection Protection Profile based on Organisational Security
+Policies (FSDPP_OSP), BSI-CC-PP-0062, Version 1.7, 27 November 2009, Federal
+Office for Information Security (BSI)
+[7] Application Notes and Interpretations of the Scheme (AIS) as relevant for the TOE.
+[8] Fingerprint Spoof Detection Evaluation Guidance, Version 2.0 (or a more recent
+version), Federal Office for Information Security (BSI)
+15 / 28
+ Certification Report BSI-CC-PP-0062-2010
+This page is intentionally left blank.
+16 / 28
+ BSI-CC-PP-0062-2010 Certification Report
+C Excerpts from the Criteria
+CC Part1:
+Conformance Claim (chapter 10.4)
+„The conformance claim indicates the source of the collection of requirements that is met
+by a PP or ST that passes its evaluation. This conformance claim contains a CC
+conformance claim that:
+● describes the version of the CC to which the PP or ST claims conformance.
+● describes the conformance to CC Part 2 (security functional requirements) as either:
+– CC Part 2 conformant - A PP or ST is CC Part 2 conformant if all SFRs in that
+PP or ST are based only upon functional components in CC Part 2, or
+– CC Part 2 extended - A PP or ST is CC Part 2 extended if at least one SFR in
+that PP or ST is not based upon functional components in CC Part 2.
+● describes the conformance to CC Part 3 (security assurance requirements) as either:
+– CC Part 3 conformant - A PP or ST is CC Part 3 conformant if all SARs in that
+PP or ST are based only upon assurance components in CC Part 3, or
+– CC Part 3 extended - A PP or ST is CC Part 3 extended if at least one SAR in
+that PP or ST is not based upon assurance components in CC Part 3.
+Additionally, the conformance claim may include a statement made with respect to
+packages, in which case it consists of one of the following:
+● Package name Conformant - A PP or ST is conformant to a pre-defined package
+(e.g. EAL) if:
+– the SFRs of that PP or ST are identical to the SFRs in the package, or
+– the SARs of that PP or ST are identical to the SARs in the package.
+● Package name Augmented - A PP or ST is an augmentation of a predefined package
+if:
+– the SFRs of that PP or ST contain all SFRs in the package, but have at least
+one additional SFR or one SFR that is hierarchically higher than an SFR in the
+package.
+– the SARs of that PP or ST contain all SARs in the package, but have at least
+one additional SAR or one SAR that is hierarchically higher than an SAR in the
+package.
+Note that when a TOE is successfully evaluated to a given ST, any conformance claims of
+the ST also hold for the TOE. A TOE can therefore also be e.g. CC Part 2 conformant.
+Finally, the conformance claim may also include two statements with respect to Protection
+Profiles:
+● PP Conformant - A PP or TOE meets specific PP(s), which are listed as part of the
+conformance result.
+● Conformance Statement (Only for PPs) - This statement describes the manner in
+which PPs or STs must conform to this PP: strict or demonstrable. For more
+information on this Conformance Statement, see Annex D.
+17 / 28
+ Certification Report BSI-CC-PP-0062-2010
+CC Part 3:
+Class APE: Protection Profile evaluation (chapter 10)
+“Evaluating a PP is required to demonstrate that the PP is sound and internally consistent,
+and, if the PP is based on one or more other PPs or on packages, that the PP is a correct
+instantiation of these PPs and packages. These properties are necessary for the PP to be
+suitable for use as the basis for writing an ST or another PP.”
+Assurance Class Assurance Components
+Class APE: Protection
+Profile evaluation
+APE_INT.1 PP introduction
+APE_CCL.1 Conformance claims
+APE_SPD.1 Security problem definition
+APE_OBJ.1 Security objectives for the operational environment
+APE_OBJ.2 Security objectives
+APE_ECD.1 Extended components definition
+APE_REQ.1 Stated security requirements
+APE_REQ.2 Derived security requirements
+APE: Protection Profile evaluation class decomposition
+Class ASE: Security Target evaluation (chapter 11)
+“Evaluating an ST is required to demonstrate that the ST is sound and internally
+consistent, and, if the ST is based on one or more PPs or packages, that the ST is a
+correct instantiation of these PPs and packages. These properties are necessary for the
+ST to be suitable for use as the basis for a TOE evaluation.”
+Assurance Class Assurance Components
+Class ASE: Security
+Target evaluation
+ASE_INT.1 ST introduction
+ASE_CCL.1 Conformance claims
+ASE_SPD.1 Security problem definition
+ASE_OBJ.1 Security objectives for the operational environment
+ASE_OBJ.2 Security objectives
+ASE_ECD.1 Extended components definition
+ASE_REQ.1 Stated security requirements
+ASE_REQ.2 Derived security requirements
+ASE_TSS.1 TOE summary specification
+ASE_TSS.2 TOE summary specification with architectural design
+summary
+ASE: Security Target evaluation class decomposition
+18 / 28
+ BSI-CC-PP-0062-2010 Certification Report
+Security assurance components (chapter 7)
+“The following sections describe the constructs used in representing the assurance
+classes, families, and components.“
+“Each assurance class contains at least one assurance family.”
+“Each assurance family contains one or more assurance components.”
+The following table shows the assurance class decomposition.
+Assurance Class Assurance Components
+ADV: Development
+ADV_ARC.1 Security architecture description
+ADV_FSP.1 Basic functional specification
+ADV_FSP.2 Security-enforcing functional specification
+ADV_FSP.3 Functional specification with complete summary
+ADV_FSP.4 Complete functional specification
+ADV_FSP.5 Complete semi-formal functional specification with
+additional error information
+ADV_FSP.6 Complete semi-formal functional specification with
+additional formal specification
+ADV_IMP.1 Implementation representation of the TSF
+ADV_IMP.2 Implementation of the TSF
+ADV_INT.1 Well-structured subset of TSF internals
+ADV_INT.2 Well-structured internals
+ADV_INT.3 Minimally complex internals
+ADV_SPM.1 Formal TOE security policy model
+ADV_TDS.1 Basic design
+ADV_TDS.2 Architectural design
+ADV_TDS.3 Basic modular design
+ADV_TDS.4 Semiformal modular design
+ADV_TDS.5 Complete semiformal modular design
+ADV_TDS.6 Complete semiformal modular design with formal high-
+level design presentation
+AGD:
+Guidance documents
+AGD_OPE.1 Operational user guidance
+AGD_PRE.1 Preparative procedures
+ALC: Life cycle support
+ALC_CMC.1 Labelling of the TOE
+ALC_CMC.2 Use of a CM system
+ALC_CMC.3 Authorisation controls
+ALC_CMC.4 Production support, acceptance procedures and
+automation
+ALC_CMC.5 Advanced support
+ALC_CMS.1 TOE CM coverage
+ALC_CMS.2 Parts of the TOE CM coverage
+ALC_CMS.3 Implementation representation CM coverage
+ALC_CMS.4 Problem tracking CM coverage
+ALC_CMS.5 Development tools CM coverage
+ALC_DEL.1 Delivery procedures
+ALC_DVS.1 Identification of security measures
+ALC_DVS.2 Sufficiency of security measures
+19 / 28
+ Certification Report BSI-CC-PP-0062-2010
+Assurance Class Assurance Components
+ALC_FLR.1 Basic flaw remediation
+ALC_FLR.2 Flaw reporting procedures
+ALC_FLR.3 Systematic flaw remediation
+ALC_LCD.1 Developer defined life-cycle model
+ALC_LCD.2 Measurable life-cycle model
+ALC_TAT.1 Well-defined development tools
+ALC_TAT.2 Compliance with implementation standards
+ALC_TAT.3 Compliance with implementation standards - all parts
+ATE: Tests
+ATE_COV.1 Evidence of coverage
+ATE_COV.2 Analysis of coverage
+ATE_COV.3 Rigorous analysis of coverage
+ATE_DPT.1 Testing: basic design
+ATE_DPT.2 Testing: security enforcing modules
+ATE_DPT.3 Testing: modular design
+ATE_DPT.4 Testing: implementation representation
+ATE_FUN.1 Functional testing
+ATE_FUN.2 Ordered functional testing
+ATE_IND.1 Independent testing – conformance
+ATE_IND.2 Independent testing – sample
+ATE_IND.3 Independent testing – complete
+AVA: Vulnerability
+assessment
+AVA_VAN.1 Vulnerability survey
+AVA_VAN.2 Vulnerability analysis
+AVA_VAN.3 Focused vulnerability analysis
+AVA_VAN.4 Methodical vulnerability analysis
+AVA_VAN.5 Advanced methodical vulnerability analysis
+Assurance class decomposition
+20 / 28
+ BSI-CC-PP-0062-2010 Certification Report
+Evaluation assurance levels (chapter 8)
+“The Evaluation Assurance Levels (EALs) provide an increasing scale that balances the
+level of assurance obtained with the cost and feasibility of acquiring that degree of
+assurance. The CC approach identifies the separate concepts of assurance in a TOE at
+the end of the evaluation, and of maintenance of that assurance during the operational use
+of the TOE.
+It is important to note that not all families and components from CC Part 3 are included in
+the EALs. This is not to say that these do not provide meaningful and desirable
+assurances. Instead, it is expected that these families and components will be considered
+for augmentation of an EAL in those PPs and STs for which they provide utility.”
+Evaluation assurance level (EAL) overview (chapter 8.1)
+“Table 1 represents a summary of the EALs. The columns represent a hierarchically
+ordered set of EALs, while the rows represent assurance families. Each number in the
+resulting matrix identifies a specific assurance component where applicable.
+As outlined in the next Section, seven hierarchically ordered evaluation assurance levels
+are defined in the CC for the rating of a TOE's assurance. They are hierarchically ordered
+inasmuch as each EAL represents more assurance than all lower EALs. The increase in
+assurance from EAL to EAL is accomplished by substitution of a hierarchically higher
+assurance component from the same assurance family (i.e. increasing rigour, scope,
+and/or depth) and from the addition of assurance components from other assurance
+families (i.e. adding new requirements).
+These EALs consist of an appropriate combination of assurance components as described
+in chapter 7 of this CC Part 3. More precisely, each EAL includes no more than one
+component of each assurance family and all assurance dependencies of every component
+are addressed.
+While the EALs are defined in the CC, it is possible to represent other combinations of
+assurance. Specifically, the notion of “augmentation” allows the addition of assurance
+components (from assurance families not already included in the EAL) or the substitution
+of assurance components (with another hierarchically higher assurance component in the
+same assurance family) to an EAL. Of the assurance constructs defined in the CC, only
+EALs may be augmented. The notion of an “EAL minus a constituent assurance
+component” is not recognised by the standard as a valid claim. Augmentation carries with
+it the obligation on the part of the claimant to justify the utility and added value of the
+added assurance component to the EAL. An EAL may also be augmented with extended
+assurance requirements.
+21 / 28
+ Certification Report BSI-CC-PP-0062-2010
+Assurance
+Class
+Assurance
+Family
+Assurance Components by
+Evaluation Assurance Level
+EAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7
+Development ADV_ARC 1 1 1 1 1 1
+ADV_FSP 1 2 3 4 5 5 6
+ADV_IMP 1 1 2 2
+ADV_INT 2 3 3
+ADV_SPM 1 1
+ADV_TDS 1 2 3 4 5 6
+Guidance AGD_OPE 1 1 1 1 1 1 1
+Documents AGD_PRE 1 1 1 1 1 1 1
+Life cycle
+Support
+ALC_CMC 1 2 3 4 4 5 5
+ALC_CMS 1 2 3 4 5 5 5
+ALC_DEL 1 1 1 1 1 1
+ALC_DVS 1 1 1 2 2
+ALC_FLR
+ALC_LCD 1 1 1 1 2
+ALC_TAT 1 2 3 3
+Security Target
+Evaluation
+ASE_CCL 1 1 1 1 1 1 1
+ASE_ECD 1 1 1 1 1 1 1
+ASE_INT 1 1 1 1 1 1 1
+ASE_OBJ 1 2 2 2 2 2 2
+ASR_REQ 1 2 2 2 2 2 2
+ASE_SPD 1 1 1 1 1 1
+ASE_TSS 1 1 1 1 1 1 1
+Tests ATE_COV 1 2 2 2 3 3
+ATE_DPT 1 1 3 3 4
+ATE_FUN 1 1 1 1 2 2
+ATE_IND 1 2 2 2 2 2 3
+Vulnerability
+assessment
+AVA_VAN 1 2 2 3 4 5 5
+Table 1: Evaluation assurance level summary”
+22 / 28
+ BSI-CC-PP-0062-2010 Certification Report
+Evaluation assurance level 1 (EAL1) - functionally tested (chapter 8.3)
+“Objectives
+EAL1 is applicable where some confidence in correct operation is required, but the threats
+to security are not viewed as serious. It will be of value where independent assurance is
+required to support the contention that due care has been exercised with respect to the
+protection of personal or similar information.
+EAL1 requires only a limited security target. It is sufficient to simply state the SFRs that the
+TOE must meet, rather than deriving them from threats, OSPs and assumptions through
+security objectives.
+EAL1 provides an evaluation of the TOE as made available to the customer, including
+independent testing against a specification, and an examination of the guidance
+documentation provided. It is intended that an EAL1 evaluation could be successfully
+conducted without assistance from the developer of the TOE, and for minimal outlay.
+An evaluation at this level should provide evidence that the TOE functions in a manner
+consistent with its documentation.”
+Evaluation assurance level 2 (EAL2) - structurally tested (chapter 8.4)
+“Objectives
+EAL2 requires the co-operation of the developer in terms of the delivery of design
+information and test results, but should not demand more effort on the part of the
+developer than is consistent with good commercial practise. As such it should not require a
+substantially increased investment of cost or time.
+EAL2 is therefore applicable in those circumstances where developers or users require a
+low to moderate level of independently assured security in the absence of ready
+availability of the complete development record. Such a situation may arise when securing
+legacy systems, or where access to the developer may be limited.”
+Evaluation assurance level 3 (EAL3) - methodically tested and checked (chapter 8.5)
+“Objectives
+EAL3 permits a conscientious developer to gain maximum assurance from positive
+security engineering at the design stage without substantial alteration of existing sound
+development practises.
+EAL3 is applicable in those circumstances where developers or users require a moderate
+level of independently assured security, and require a thorough investigation of the TOE
+and its development without substantial re-engineering.”
+23 / 28
+ Certification Report BSI-CC-PP-0062-2010
+Evaluation assurance level 4 (EAL4) - methodically designed, tested, and reviewed
+(chapter 8.6)
+“Objectives
+EAL4 permits a developer to gain maximum assurance from positive security engineering
+based on good commercial development practises which, though rigorous, do not require
+substantial specialist knowledge, skills, and other resources. EAL4 is the highest level at
+which it is likely to be economically feasible to retrofit to an existing product line.
+EAL4 is therefore applicable in those circumstances where developers or users require a
+moderate to high level of independently assured security in conventional commodity TOEs
+and are prepared to incur additional security-specific engineering costs.”
+Evaluation assurance level 5 (EAL5) - semiformally designed and tested (chapter 8.7)
+“Objectives
+EAL5 permits a developer to gain maximum assurance from security engineering based
+upon rigorous commercial development practises supported by moderate application of
+specialist security engineering techniques. Such a TOE will probably be designed and
+developed with the intent of achieving EAL5 assurance. It is likely that the additional costs
+attributable to the EAL5 requirements, relative to rigorous development without the
+application of specialised techniques, will not be large.
+EAL5 is therefore applicable in those circumstances where developers or users require a
+high level of independently assured security in a planned development and require a
+rigorous development approach without incurring unreasonable costs attributable to
+specialist security engineering techniques.”
+Evaluation assurance level 6 (EAL6) - semiformally verified design and tested
+(chapter 8.8)
+“Objectives
+EAL6 permits developers to gain high assurance from application of security engineering
+techniques to a rigorous development environment in order to produce a premium TOE for
+protecting high value assets against significant risks.
+EAL6 is therefore applicable to the development of security TOEs for application in high
+risk situations where the value of the protected assets justifies the additional costs.”
+Evaluation assurance level 7 (EAL7) - formally verified design and tested
+(chapter 8.9)
+“Objectives
+EAL7 is applicable to the development of security TOEs for application in extremely high
+risk situations and/or where the high value of the assets justifies the higher costs. Practical
+application of EAL7 is currently limited to TOEs with tightly focused security functionality
+that is amenable to extensive formal analysis.”
+Class AVA: Vulnerability assessment (chapter 16)
+“The AVA: Vulnerability assessment class addresses the possibility of exploitable
+vulnerabilities introduced in the development or the operation of the TOE.”
+24 / 28
+ BSI-CC-PP-0062-2010 Certification Report
+Vulnerability analysis (AVA_VAN) (chapter 16.1)
+"Objectives
+Vulnerability analysis is an assessment to determine whether potential vulnerabilities
+identified, during the evaluation of the development and anticipated operation of the TOE
+or by other methods (e.g. by flaw hypotheses or quantitative or statistical analysis of the
+security behaviour of the underlying security mechanisms), could allow attackers to violate
+the SFRs.
+Vulnerability analysis deals with the threats that an attacker will be able to discover flaws
+that will allow unauthorised access to data and functionality, allow the ability to interfere
+with or alter the TSF, or interfere with the authorised capabilities of other users.”
+25 / 28
+ Certification Report BSI-CC-PP-0062-2010
+This page is intentionally left blank.
+26 / 28
+ BSI-CC-PP-0062-2010 Certification Report
+D Annexes
+List of annexes of this certification report
+Annex A: Fingerprint Spoof Detection Protection Profile based on Organisational
+Security Policies (FSDPP_OSP), Version 1.7 [6] provided within a separate
+document.
+27 / 28
+ Certification Report BSI-CC-PP-0062-2010
+This page is intentionally left blank.
+28 / 28
+
--
cgit v1.3.1
Download CSV
+
Access Control Devices and Systems – 7 Protection Profiles
+
