SIST-TS CEN/TS 18099:2025

SLOVENSKI STANDARD
01-februar-2025
Odkrivanje napadov z vnašanjem biometričnih podatkov
Biometric data injection attack detection
Digitale Präsentationsangriffe in biometrischen Systemen
Détection d’attaques par injection de données biométriques
Ta slovenski standard je istoveten z: CEN/TS 18099:2024
ICS:
35.030 Informacijska varnost IT Security
35.240.15 Identifikacijske kartice. Čipne Identification cards. Chip
kartice. Biometrija cards. Biometrics
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

CEN/TS 18099
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
November 2024
TECHNISCHE SPEZIFIKATION
ICS 35.030
English Version
Biometric data injection attack detection
Détection d'attaques par injection de données Detektion von Injektionsangriffen mit biometrischen
biométriques Daten
This Technical Specification (CEN/TS) was approved by CEN on 13 October 2024 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to
submit their comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS
available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in
parallel to the CEN/TS) until the final decision about the possible conversion of the CEN/TS into an EN is reached.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2024 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 18099:2024 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
Introduction . 5
1 Scope . 7
2 Normative references . 7
3 Terms and definitions . 8
4 Symbols and abbreviations . 10
5 Conformance . 11
6 Characterization of biometric data injection attacks . 11
6.1 Injection Attack Methods . 11
6.2 Injection Attack Instruments . 13
7 Framework for injection attack detection mechanisms . 14
7.1 Overview of different types of injection attack detection . 14
7.2 Injection Attack Method Defence Mechanisms . 15
7.3 Injection Attack Instrument Defence Mechanisms . 16
7.4 Combination of different types of IAD . 17
7.5 Security vs general public use . 17
8 Evaluation of IAD systems . 18
8.1 Overview . 18
8.2 General principle of evaluation . 18
8.3 Injection attack methods . 20
8.4 Injection attack instruments . 20
8.5 Personal Data Protection of volunteers in IAD Assessments . 21
8.6 Levels of difficulty of the evaluations . 21
9 Metrics for IAD evaluations . 23
9.1 General. 23
9.2 Metrics for IAD subsystem evaluation . 23
9.3 Metrics for full system evaluation . 23
10 Attacks rating methodology . 24
10.1 General. 24
10.2 Identification and exploitation phases . 25
10.3 Time effort . 25
10.4 Expertise . 26
10.5 Knowledge of the product under evaluation . 26
10.6 Equipment . 27
10.7 Access to TOE . 28
10.8 Access to biometric characteristics . 29
10.9 Degree of scrutiny . 29
11 Report . 30
Annex A (normative) Evaluation success decision based on vulnerability identification and
exploitation and attack rating . 32
Annex B (informative) Different examples of injection attacks and injection attack
instruments in the literature. 33
B.1 Injection attacks . 33
B.2 Injection attack instruments . 33
Annex C (informative) Obstacles to biometric data injection attack in a biometric system . 34
C.1 Biometric data injection attack at enrolment . 34
C.2 Biometric data injection attack at verification . 34
Bibliography . 36
European foreword
This document (CEN/TS 18099:2024) has been prepared by Technical Committee CEN/TC 224 “Personal
identification and related personal devices with secure element, systems, operations and privacy in a
multi sectorial environment”, the secretariat of which is held by AFNOR.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN/CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the
United Kingdom.
Introduction
Biometric technology is used to identify or verify individuals thanks to their physiological or behavioural
characteristics. Therefore, biometric technologies are often used nowadays as component of a security
system. In a security system, biometrics is usually used to recognize people in order to check if they are
known or not to the system.
From the very beginning in the use of biometrics, potential attacks against such recognition systems were
widely acknowledged by the community. This has given rise to the development of attack detection
solutions, to defeat subversive recognition attempts.
ISO/IEC 30107-1 describes nine points of attacks onto a biometric system, as shown in Figure 1. But, the
ISO/IEC 30107 series deals only with Type 1 attacks, i.e. presentations to the biometric data capture
subsystem with the goal of interfering with the operation of the biometric system. The ISO/IEC 30107
series does not consider within its scope those attacks that are applied outside the front end of the
acquisition system, i.e. those attacks which are not physically presented to the embedded capture device.

Figure 1 — Examples of points of attack in a biometric system [5]
The emergence of remote identity verification solutions based on biometric (such as facial) recognition
and the use of mobile applications or web browser applications could provide new means of attacking
the recognition process. One of these attacks is the Type 2 attack (see Figure 1), which is based on the
attacker modifying the data flow.
This document is focused on such Type 2 attacks, called Biometric Data Injection Attacks. Such an
injection attack consists in the action of interfering with the biometric system by replacing the original
data sample provided by the user at the biometric data capture device, with another biometric sample,
before the execution of the feature extraction process.
EXAMPLE An injection attack can be the injection of fingerprint image/video in a fingerprint contactless
system.
The feasibility of such digital attacks has been identified by several agencies such as:
— French ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information) in remote identity
verification referential called P.V.I.D. [1],
— European Standards Organization ETSI (European Telecommunications Standards Institute) in their
TS 119 461 which deals with remote identity verification [2],
— European Union Agency for Cybesecurity (ENISA) in “Remote Identity Proofing: Attacks and
Countermeasures” report [3],
— German BSI (Bundesamt für Sicherheit in der Informationstechnik) in the Technical Guideline TR-
03147 Assurance Level Assessment of Procedures for Identity Verification of Natural Persons [4],
— Spanish CCN Security Guide for ITC products – Annex F.11: Videoidentification tools [12].
Yet, there is no national or international standard for biometric data injection attacks as there is for
presentation attacks with the already available ISO/IEC 30107 standards or for generic biometric
systems with the ISO/IEC 19792 standard [22].
This standard activity could be a common base for the work undertaken by French ANSSI, Spanish CCN
and ETSI. This standardization gap has also been identified by ENISA (European Network and
Information Security Agency) which has written a report on the vulnerability landscape of the remote
digital identity service providers using biometrics [3].
Thus, this document will provide a foundation for Injection Attack Detection through defining terms and
establishing a framework through which biometric data injection attack events can be specified and
detected so that they can be categorized, detailed and communicated for subsequent biometric system
decision making and performance assessment activities.
Secure elements and any other cryptographic security features are not covered by this document.
1 Scope
This document provides an overview on:
• Definitions on Biometric Data Injection Attack,
• Biometric Data Injection Attack use case on main biometric system hardware for enrolment and
verification,
• Injection Attack Instruments on systems using one or several biometric modalities.
This document provides guidance on:
• System for the detection of Injection Attack Instruments (defined in 3.12),
• Appropriate mitigation risk of Injection Attack Instruments,
• Creation of test plan for the evaluation of Injection Attack Detection system (defined in 3.9).
If presentation attacks testing is out of scope of this document, note that these two characteristics are in
the scope of this document:
• Presentation Attack Detection systems which can be used as injection attack instrument defence
mechanism and/or injection attack method defence mechanism. Yet, no presentation attack testing
will be performed by the laboratory to be compliant with this document (out of scope).
• Bona Fide Presentation testing in order to test the ability of the Target Of Evaluation to correctly
classify legitimate users.
The following aspects are out of scope:
• Presentation Attack testing (as they are covered in ISO/IEC 30107 standards),
• Biometric attacks which are not classified as Type 2 attacks (see Figure 1),
• Evaluation of implementation of cryptographic mechanisms like secure elements,
• Injection Attack Instruments rejected due to quality issues.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
EN ISO/IEC 2382-37, Information technology — Vocabulary — Part 37: Biometrics (ISO/IEC 2382-37)
ISO/IEC 19795-1, Information technology — Biometric performance testing and reporting — Part 1:
Principles and framework
ISO/IEC 30107-1, Information technology — Biometric presentation attack detection — Part 1:
Framework
ISO/IEC 30107-3, Information technology — Biometric presentation attack detection — Part 3: Testing
and reporting
3 Terms and definitions
For the purposes of this document, the terms and definitions given in EN ISO/IEC 2382-37,
ISO/IEC 19795-1, ISO/IEC 30107-1 and ISO/IEC 30107-3, and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
• ISO Online browsing platform: available at https://www.iso.org/obp
• IEC Electropedia: available at https://www.electropedia.org/
3.1
attack type
combination of injection attack method and injection attack instrument species
3.2
biometric data injection
replacement of a biometric sample
3.3
biometric data injection attack
action of using an injection attack method (3.15) to interfere with the biometric system by replacing the
original data sample captured by the data capture component by an injection attack instrument (3.12),
before the execution of the feature extraction process
Note 1 to entry: To avoid too long sentences in the rest of this document, we will use the term “injection attacks” to
talk about “biometric data injection attacks”.
EXAMPLE An injection attack can be the injection through a virtual (fake) webcam of a deepfake video
representing the face of a victim onto the head of an attacker in order to impersonate the identity of a victim during
a remote identity verification transaction using face recognition [1,7].
3.4
enrolment evaluation
measuring of the ability of a biometric system to correctly detect injection attacks and classify bona fide
presentations at enrolment phase
3.5
full system
system which includes both biometric comparison and Injection Attack Detection (IAD) subsystems
3.6
full system evaluation
measuring of the ability of the full system to correctly detect injection attacks and classify bona fide
presentations
3.7
hook
operation where function calls are intercepted by a program to modify their behaviour
3.8
injection
modification of a data flow by modifying the data source or overwriting the data
3.9
injection attack detection
IAD
automated determination of a biometric data injection attack
Note 1 to entry IAD can include injection attack method defence mechanisms (3.16) and injection attack
instrument defence mechanism (3.13).
3.10
injection attack detection subsystem
IAD subsystem
hardware and/or software that implements an IAD mechanism and makes an explicit declaration
regarding the detection of injection attacks
3.11
injection attack detection subsystem evaluation
IAD subsystem evaluation
measuring of the ability of the IAD subsystem to correctly classify both injection attacks and bona fide
presentations
3.12
injection attack instrument
IAI
biometric sample, which may be a modified biometric sample (3.17), used in a biometric data injection
attack
3.13
injection attack instrument defence mechanism
IAIDM
biometric defence mechanisms aiming at making a biometric system resistant to injection attack
instruments
3.14
IAI species
class of injection attack instruments created using a common production method and based on different
biometric characteristics
EXAMPLE A set of face deepfakes videos made with the same software.
3.15
injection attack method
IAM
methodology to interfere with the biometric system in order to replace the original data sample captured
by the data capture component
3.16
injection attack method defence mechanism
IAMDM
biometric defence mechanisms aiming at making a biometric system resistant to injection attack methods
3.17
modified biometric sample
biometric sample modified, through edition or alteration, by an attacker in order to impersonate a
victim’s identity or to hide original biometric sample characteristics
3.18
read-only memory
ROM
type of computer storage containing non-volatile, permanent data that, normally, can only be read, not
written to
Note 1 to entry: ROM contains the programming that allows a computer to start up or regenerate each time it is
turned on.
3.19
operating system read-only memory
OS ROM
ROM which contains the Operating System of the device, which are all the programs which manage
resources of the device
3.20
security target
document which defines the assets protected by the Target Of Evaluation (TOE), the threats which will
be taken into account during the evaluation and the security functions implemented by the TOE to
prevent the threats
3.21
target of evaluation
TOE
product that is the subject of the evaluation
3.22
threat
injection attack scenario used by the attacker to bypass the IAD mechanism
Note 1 to entry: For the other terms not defined here, see their definition in the normative references.
4 Symbols and abbreviations
For the purposes of this document, the symbols and abbreviations given in EN ISO/IEC 2382-37,
ISO/IEC 19795-1, ISO/IEC 30107-1 and ISO/IEC 30107-3, and the following apply:
AI Artificial Intelligence
API Application Programming Interface
BPCER Bona fide Presentation Classification Error Rate
FNMR False Non-Match Rate
IAD Injection Attack Detection
IAI Injection Attack Instrument
IAIDM Injection Attack Instrument Defence Mechanism
IAM Injection Attack Method
IAMDM Injection Attack Method Defence Mechanism
IT Information Technology
PAD Presentation Attack Detection
ROM Read-Only Memory
TOE Target Of Evaluation
5 Conformance
To conform to this document, an evaluation of IAD mechanisms shall be planned, executed and reported
in accordance with the mandatory requirements as follows:
• Clauses 8 to 11,
• Annex A.
6 Characterization of biometric data injection attacks
6.1 Injection Attack Methods
Although attacks on a biometric system can occur anywhere and be instantiated by any actor, as
described in [5], this document only focuses on biometric-based attacks after the data capture subsystem
by replacing the captured biometric sample. Attacks at other points of the system are out of scope of this
document.
Figure 1 (see Introduction) illustrates several generic attacks against a biometric system. This document
only focuses on Type 2 attacks.
Injection attacks are usually carried out by biometric impostors who intend to be recognized as a specific
individual known to the system.
In order to achieve a biometric data injection attack, the attacker needs to have a partial control over the
device to perform the replacement, as the replacement may need to prepare the device or to use specific
software installed on the device. This means that the device used to perform the attack is (most of the
time) unsupervised.
Thus, there are different types of devices on which a biometric data injection attack is possible:
• a computer,
• a mobile device,
• other smart devices (e.g. IoT device equipped with a camera).
Figure 2 shows how injection attacks are done on a biometric system used via a web app or a computer
app. Figure 3 gives an illustration of an attack performed through a hooking process.

Figure 2 — Principle of a biometric data injection attack through virtual sensor used in a
standard device [7]
Figure 3 — Biometric Data Injection Attack made with hooking process [14]
Of course, the difficulty to achieve the attack will depend on the device that is used to perform the attack,
but also on the way the device is used. Because using a computer can give access to plenty of different
software that will give to the impostor the possibility to mimic the biometric capture device (as a virtual
camera for face recognition or virtual microphone for voice recognition for instance) or to intercept data
sent by the capture device.
Nevertheless, for instance, as of today it is more difficult, but not impossible, to install a virtual capture
device on a mobile device. Thus, it means that the injection attack may require the use of a rooted device
and requires the attacker to have expertise in mobile application reverse engineering and penetration
testing in order to make a hook of the biometric capture device API called by the mobile application and
replace the data taken by the capture device with malicious data.
NOTE For specific devices, it might be possible for attackers to find a custom ROM with a virtual camera on the
internet and thus, the attacker only needs to root their phone and then to install the custom ROM.
Figure 4 gives an illustration of what the hooking process looks like.

Figure 4 — Hooking process [14]
Moreover, note that the environment and the context of the attack can affect its feasibility. Indeed, if the
TOE is supervised or attended, it may be more difficult for the attacker to achieve the attack.
Eventually, the success of a biometric data injection attack is highly related to the IAI that is used by the
attacker. It is important to notice that creating a high quality IAI can rely on the expertise of the attacker
and/or the quality of the biometric source.
6.2 Injection Attack Instruments
An Injection Attack Instrument is a fully synthetic, a modified or unmodified biometric sample used by
an attacker to replace the genuine biometric sample in a biometric security solution in order to fool it.
Data used for attacks just after the capture device falls into three distinct categories: unmodified data,
modified data and artificial data.

Figure 5 — Types of injection attack instruments
Figure 5 gives a detailed description of these categories. Table 1 gives examples of each specific IAI type
in the bottom tier of Figure 5.
Table 1 — Examples of biometric samples used during a biometric data injection attack
Category Type Examples
Unmodified biometric raw data video of a face, photo of an iris
sample
combined raw combination of videos, combination of voice records
data
Modified biometric prepared deepfake video, synthetized voice record, or a
sample combination of both.
live live deepfake video, live synthesized voice, or a
combination of both.
Artificial biometric generated face image generated with AI, fingerprint image
sample artificial data generated with AI
7 Framework for injection attack detection mechanisms
7.1 Overview of different types of injection attack detection
The biometric data injection method is neither dependent on the integrated capture device nor on an
external capture device (e.g. integrated webcam or USB webcam on a computer), which means that an
injection attack can be performed on both architectures.
There are different types of Injection Attack Detection (IAD) mechanisms:
— IAMDM designed to counter an IAM,
— IAIDM designed to classify IAI as artefacts.
It is recommended that systems implement both types of IAD mechanisms so that the attacker has to
identify an effective injection method and to build injection instruments able to not be classified as such.
Yet, some systems can choose to implement only one type of IAD mechanisms.
As there is no way possible to be sure that data received by the application device (whether it is a mobile
or computer application) is from the trusted biometric capture device, mechanisms countering an IAM
usually depend on cryptographic security solutions, while mechanisms concerned with IAI may be similar
to PAD mechanisms or introduce randomness during data capture (see subclauses 7.3.1 and 7.3.2).
For Injection Attack Method Defence Mechanisms, the techniques can be based on system changes
detection, injection detection, IT countermeasures or device authentication. On the other hand, the
techniques for Injection Attack Instrument Defence Mechanisms can be based on challenge-response or
artefact detection.
Table 2 proposes different methods for detecting biometric data injection attacks and gives different
implementation’s examples.
Table 2 — Examples of methods for detecting or countering biometric data injection attacks
Category Type Examples
Injection attack System changes detection Detection of changes from normal use by the
method defence attacker. For example, it can be a proxy
mechanism detection, a root detection or an emulator
detection for mobile devices.
Injection detection Detection of a data injection during the usage of
the device. For example, it can be a virtual
camera detection system.
IT countermeasures Security implemented by the developer to waste
the attacker's time or hide sensitive information.
For example, it can be the use of counters or
code obfuscation.
Device authentication and The biometric sample transferred to the signal-
secure messaging processing subsystem is protected with respect
to authenticity and integrity by applying
appropriate cryptographic primitives [13].
Category Type Examples
Injection attack Challenge-response Detection of expected response after a specific
instrument challenge has been requested by the IAD system.
defence Challenges can be performed by the users
mechanism themselves or executed by the capture device,
and they can then be observable on the sample.
For instance, the IAD system may ask the users
to perform specific actions (active challenge-
response), such as moving their head in facial
biometrics systems or reading some random
code for voice biometric ones. Or it may
command the capture device system to execute
certain instructions (passive challenge-
response).
Other useful information can be used, directly
extracted from the capture device and captured
data to detect normal usage. For instance, using
the mobile's accelerometer to check if the device
is moving.
Artefact detection Detection of features that are indicative of an
artefact. For example, detection of abnormal
cuts in the voice flow in a synthetic voice made
of copy-and-paste or speech concatenation;
detection of an abnormal blur around the mouth
or the eyes in synthetic videos…
7.2 Injection Attack Method Defence Mechanisms
7.2.1 Virtual sensor detection
As noted in 6.1, an attacker can use a virtual webcam, which can be configured to display real pre-
recorded videos or a video stream and which will have similar behaviour than a real camera. Similarly,
using a smartphone simulator or emulator permits an attacker to use a desktop environment and
simulate or emulate a smartphone device. The simulated smartphone camera can for example be fed with
a real pre-recorded video or dynamic deep fake.
Mechanisms that mitigate the presence of such virtual sensors shall be in place.
7.2.2 Secure channel mechanisms
An attacker shall not be able to intercept and modify the images / video / liveness answer or any
instruction during their transit. Cryptographic mechanisms shall be used to protect the whole digital
channel between the capture device and the biometric system against injection. It can include digital
encryption, digital signature or any mechanisms to ensure integrity and authenticity.
7.3 Injection Attack Instrument Defence Mechanisms
7.3.1 Challenge-response
The concept of challenge-response is widely used in authentication schemes, some of which include
biometric aspects and others with no biometric contribution. This part will focus in more detail on the
implementation of challenge-response into biometric systems.
The framework for categorizing all aspects of challenge-response related to liveness is shown in Table 3.
Table 3 — Injection Attack Detection utilizing challenge-response as tool
Passive response Active response
Challenge Specific commands to the data Cues (verbal, visual…) asking for a specific
capture subsystem, whose impact action to be made by the user, that will be
can be observed on the biometric captured by the biometric system
data sample.
Response Natural, involuntary, not controllable Based on alive human cognition and
by the subject voluntarily controlled action
Examples Expect to detect a changing focus Cue to turn head right → head pitch angle
during face capture → the focus on changes in the correct direction
face change according to the pattern
Cue to read a specific word → word
given by the system
recognized by the system
The use of challenge-response for IAD can reduce the risk of attacks created from unmodified biometric
samples. Indeed, depending on what is being asked as the challenge, unmodified data meeting that exact
challenge may be hard (and sometimes impossible) to obtain for the attacker. The more unexpected the
type of challenge requested, the harder it is to obtain an unmodified biometric sample meeting this
specific challenge. Challenge-response for IAD can also make attacks based on modified data harder to
create, in particular if the challenges required from the device or the user are based on “extreme data”
(e.g. data that are harder to synthetize) such as unusual angles of the face or invented words. Moreover,
if the challenge focuses on known attack flaws, it can increase the time spent and/or the attacker’s
expertise required to make an attack of sufficient quality.
Challenges, both based on active and passive responses, are particularly interesting in the case of IAD if
they are linked to a random factor of challenge appearance, as they make the preparation of the attack
more complex to create (need to create data samples for all possible variations and to inject them at the
correct moment) - see Clause 7.3.2 for more details.
7.3.2 Randomness
The following paragraph only concerns systems based on server-client architecture. To be efficient for
preventing injection attacks, it is better that systems perform the analysis of the various challenges on
the server side. As the client side is required to capture the necessary information from the user, any
challenge request sent to the system or to the user shall be cyphered to prevent the attacker from
knowing the challenges in advance.
Incorporating random factors in challenge-response IAD systems to prevent biometric data injection can
further increase the difficulty, for an attacker, to fool the system. Random challenge-response systems
are based on a set of different challenges or a set of different challenge orders that can be asked at each
time to any user. The higher the number of possible challenges or challenge orders, the more robust the
system. For instance, on a facial biometric system with active response, the IAD can ask the user to turn
their head right then left, or left then right: this would make two possible variations that can be randomly
chosen for each verification. The greater the entropy, the greater the time required to create the different
orders of challenges to carry out an attack. It means that having a large entropy (for instance more than
a hundred challenge orders possible) can prevent the injection attacks prepared in advance, which are
the attacks with the highest level of quality as the attacker has all the time they want to remove or at least
to reduce the flaws of their attack.
It is important to notice that if the system is built on client-server architecture, the creation of the
challenge order shall be done on server side to prevent against challenge order modification from the
attacker. In addition, the confidentiality of instructions containing the challenge order shall be protected
in the channel between the server and the client, see also Clause 7.2.2.
Eventually, it is important to notice that the nature of the device will affect the field of possibilities for the
developer. Indeed, the developer would have access to more parameters to control the camera in a mobile
application compared to the parameters available for a webcam on a web app.
EXAMPLE 1 On a mobile device, the developer can have access to raw images (without any algorithms from
Image Signal Processor applied).
EXAMPLE 2 On a mobile device, it is possible to get access to data from other sensors like the accelerometer for
instance.
7.3.3 Artefact detection
IAIDM implementing artefact detection contribute to prevent deepfake attacks and face re-enactment
attacks (giving movement to a face photograph according to a specific source video) used against face
recognition or robotic voice synthetisation attacks used against voice recognition, for example.
EXAMPLE 1 Receiving something with a resolution different than the expected can be evidence of an injection
attack, depending on the application.
This kind of automatic attack detection methods are particularly interesting to protect biometric systems
against biometric data injection attacks realized in live as this kind of attack usually presents lots of
defects which would be detectable by such solutions.
EXAMPLE 2 A challenge requesting to move an object in front of the biometric source can be used to increase
the probability of artefacts.
7.4 Combination of different types of IAD
As each method deals with a specific attack against a specific kind of biometric data injection attack, the
best way to guard a biometric system is to combine different types of IAD subsystems. For instance,
having an IAD solution which combines Injection Attack Method Detection Mechanism (e.g. log-in attempt
counters) with Injection Attack Instrument Defence Mechanisms (e.g. challenge-response and artefact
detection) will help to detect most of injection attacks.
7.5 Security vs user convenience
The combination of different security solutions is interesting if such solutions are simple and easily
understandable by the user. Enforcing a high level of security can impact the user convenience of the
system.
Thus, it is important to test the system and report the different performances to be sure that the security
level does not reduce the usability of the solution (trade-off between the false acceptance rate, i.e.
representing the security level, and the false rejection rate).
8 Evaluation of IAD systems
8.1 Overview
The system which is evaluated in conformance with this document is called Target Of Evaluation (TOE).
The evaluation of the TOE consists of assessing the resistance of the security functions established by the
TOE against injection attacks. These security functions will be described in a document called security
target (the security target structure is defined in Clause 8.2.2). The security target contains the
description of threats taken into account by the evaluator to develop its injection attacks. The threat
model corresponds to the risk analysis performed by the TOE developer. The TOE can be evaluated
according to two different types of evaluation:
— IAD subsystem evaluation,
— Full system evaluation.
Evaluations of IAD mechanisms that are part of the TOE and resulting evaluation reports shall specify the
applicable evaluation level, whether IAD subsystem or full system.
This document does not cover the PAD testing. However, it is recommended to carry out, in addition to a
conformity assessment with this document, a conformity assessment with ISO/IEC 30107-3 if the TOE is
a full-system product to identify all possible existing vulnerabilities of the TOE.
8.2 General principle of evaluation
8.2.1 General principles
First of all, the evaluator shall validate the security target in order to ensure that it takes into account all
existing threats against the product under evaluation.
The evaluation of the TOE shall cover a defined variety of threats which will be defined in the security
target. The threats will be covered by the evaluator thanks to a representative set of IAI species.
Moreover, the evaluator shall use a representative set of bona fide capture subjects in order to ensure the
proper functioning of the TOE. With this set of bona fide capture subjects, the evaluator shall realize
legitimate transactions in order to ensure that the bona fide presentation rate (BPCER for IAD subsystem
evaluation and FNMR for full system evaluation) is close to the one given by the TOE developer in the
security target.
Once the threats are defined in the security target document, the number of injection attack instruments
species and injection attack methods used by the evaluator to set up the threat should be specified in the
report. Establishing whether a specific IAI species reproducibly succeeds does not require a very large
number of injections or subjects. The evaluator will be able to identify a vulnerability once an attack has
bypassed the system once (identification phase, see Clause 10) and to exploit the vulnerability when the
attack has been reproduced at least once (exploitation phase, see Clause 10).
A representative set of bona fide capture subjects is required to determine the frequency with which the
TOE incorrectly classifies bona fide presentations. This is a critical part of the TOE testing since an IAD
mechanism could erroneously classify bona fide presentations as injection attacks. A high classification
error rate for bona fide capture subjects would reduce system usability and would not allow the evaluator
to give a positive result in the report if the BPCER (or FNMR) is too high (for instance if it exceeds 15 %).
It needs to be clarified in the ST document.
8.2.2 Evaluation framework
At the beginning of the assessment, the evaluator needs to have access to the security target of the TOE.
The security target is a document in which the evaluator describes the TOE and the perimeter of the
evaluation: the assets protected by the TOE, the threats taken into account during evaluation and the
security functions implemented by the developer to prevent the threats. The security target will give
information about the TOE to the evaluator and will influence the attack rating if an attack bypasses the
TOE (see Clause 10). The security target shall have this structure:
1. Synthesis
Identification of the product to be evaluated
2. Description
General description of the product to be evaluated
Description of the use of the product to be evaluated
Description of the intended use environment
Description of dependencies
Description of typical users
Description of the TOE
3. Description of the technical operating environment
4. Asset to protect by the TOE
5. Description of threats
6. Description of the security functions of the TOE
7. Threats coverage
The security target can be written by the evaluator with the support of the developer, or can be provided
...