Liveness Check

The Liveness Check is a process of determining whether the presented face or palm is a real person, or if the presented face or palm has been faked during some kind of so-called spoof attack. This process is sometimes also called a Spoof Check.

We recognize two approaches to a Liveness Check:

• Active Liveness is where the person needs to perform an extra action to prove genuineness and liveness
• Passive Liveness is proving genuineness and liveness without requiring the user to perform any additional action

The SmartFace currently supports Passive Liveness only, which is recommended for applications where the user’s experience and seamless app flow are paramount.

Neural Networks have been trained to detect real faces and palms and various kinds of spoof attacks. Such spoof attacks include:

• Faces and palms displayed on electronic screens
• Printed faces and palms
• 2D masks
• 3D masks

The example of a presentation attack performed by the printed image.

Supported Passive Liveness Types#

There are two passive liveness types available in the SmartFace Platform. They are optimized for different usage and use cases:

• distant passive liveness – suggested to be used on wild images (not recommended for selfies)
• nearby passive liveness – suggested to be used on selfie/enrollment images
• palm liveness - used for palm images

Passive Liveness Inputs#

The SmartFace Platform provides the passive liveness detection in :

• in real-time video processing, configurable at a camera level
• by a direct passive liveness REST API call
• integrated in the watchlist search process REST API call
• integrated in the search by palm REST API call

A common rule “the better input the better result” applies to the Liveness Check even more. When designing an Access Control solution, some rules need to be followed to have a successful Liveness Check.

The recommended minimum requirements for the input are:

1. Consider a camera placement and position - take the most frontal face image as possible
2. A facial image with sufficient background must be submitted for evaluation
3. A face should not be near the side of the image
4. Not too strong backlight or sidelight
5. No overexposed or underexposed images - mind a constant artificial light
6. An image should not be cropped or compressed between the capture and processing step

Evaluating liveness explained#

Liveness Check flow#

Depending on the input for the liveness the evaluation flow is slightly different

1. In real-time video processing only matched faces are evaluated for the liveness. If the detected face is not matched then no Liveness Check is performed. Keep in mind this condition while testing and configuring liveness during deploymnent.
2. During direct API call, no matching is performed and Liveness Check is performed always.
3. For the Watchlist Search API call same rule as for realtime video processing applies. Please see the flow chart.

Passive liveness conditions#

When evaluating a liveness for provided image you can adjust Liveness Conditions in the spoofCheckConfig. There are two sets of Liveness Conditions. One set is for the nearby Liveness Check, the other one is for the distant Liveness Check.

"spoofCheckConfig": {
    "distantLivenessScoreThreshold": 90,
    "nearbyLivenessScoreThreshold": 90,
    "distantLivenessConditions": "default",
    "nearbyLivenessConditions": "default",
    "keepEvaluatingConditionsAfterFirstFail": false
  }

The default values can be adjusted as needed however the default sets are recommended unless the environmental conditions of the image request it.

Default conditions to start distant passive liveness evaluation#

Example for distant Liveness Condition string:

 FACE_CONFIDENCE: [1000; 10000]

You can set additional attributes according to your use case.

Example for distant Liveness Condition string with additional attributes:

 FACE_CONFIDENCE: [1000; 10000] && FACE_SIZE: [30; inf] && FACE_RELATIVE_AREA: [0.009; inf] && FACE_RELATIVE_AREA_IN_IMAGE: [0.9; inf] && YAW_ANGLE: [-20; 20] && PITCH_ANGLE: [-20; 20] && SHARPNESS_RAW: [5000; 70000] && BRIGHTNESS_RAW: [40000; 230000] && CONTRAST_RAW: [10000; 90000] && SPECULARITY_RAW: [5000; 80000]

Tables below list the additional parameters, description and their possible values.

Default conditions to start nearby passive liveness evaluation#

Example for nearby Liveness Condition string:

FACE_CONFIDENCE: [1000; 10000]

You can set additional attributes according to your use case.

Example for nearby Liveness Condition string with additional attributes:

FACE_CONFIDENCE: [1000; 10000] && FACE_SIZE: [60; inf] && FACE_RELATIVE_AREA: [0.25; inf] && YAW_ANGLE: [-20; 20] && PITCH_ANGLE: [-20; 20] && BRIGHTNESS: [-7800; 5000] && CONTRAST: [-5000; 6000] && SHARPNESS_RAW: [4000; inf] && UNIQUE_INTENSITY_LEVELS: [500; 10000]

Passive liveness thresholds#

This section defines the passive liveness thresholds, which determine how strictly the system distinguishes between real and spoof faces based on the liveness score. Each threshold value represents a different balance between security (resistance to spoofing) and convenience (tolerance for genuine user variation).

For details on how these thresholds influence overall system performance metrics, refer to the [Accuracy](https://developers.innovatrics.com/smartface/docs/manuals/accuracy/#passive-liveness) section.

Parameters for the Liveness call#

When setting up a call to the POST /api/v1/Faces/SpoofCheck endpoint the parameter spoofDetectorResourceIds represents an array of liveness detectors what should be run during the spoof check.

"spoofDetectorResourceIds": [
    "none"
  ],

Possible values are liveness_distant_any_remote or liveness_distant_cpu_remote or liveness_distant_gpu_remote for a distant passive Liveness Check and liveness_nearby_any_remote or liveness_nearby_cpu_remote or liveness_nearby_gpu_remote for a nearby passive Liveness Check.

You can set thresholds for the Liveness Checks, ie. the number your Liveness score is compared against to decide whether the Liveness Check has passed. The threshold for the distant Liveness Check is set as distantLivenessScoreThreshold and the threshold for a nearby Liveness Check is set as nearbyLivenessScoreThreshold.

The value of keepEvaluatingConditionsAfterFirstFail allows you to have full information about the reasons why the Liveness Check was not performed instead of only providing information about the first reason why it is not being performed.

"spoofCheckConfig": {
    "distantLivenessScoreThreshold": 90,
    "nearbyLivenessScoreThreshold": 90,
    "distantLivenessConditions": "default",
    "nearbyLivenessConditions": "default",
    "keepEvaluatingConditionsAfterFirstFail": false
  }

Responses of the Liveness call#

The POST /api/v1/Faces/SpoofCheck endpoint responds with information about whether the Liveness Check was performed and whether it has succeeded. If it has succeeded the Liveness Check score is provided. The first level of information is an aggregation of both nearby and distant Liveness Checks. Then each check provides its information.

If the face is detected but the Liveness Check is not done due to the condition string not being fulfilled then the notPerformedReasons.reasonMessage provides information about what condition(s) was/were not fulfilled.

{
  "performed": true,
  "passed": true,
  "distantLivenessSpoofCheck": {
    "performed": true,
    "passed": true,
    "score": 0,
    "notPerformedReasons": [
      {
        "reasonMessage": "string"
      }
    ]
  },
  "nearbyLivenessSpoofCheck": {
    "performed": true,
    "passed": true,
    "score": 0,
    "notPerformedReasons": [
      {
        "reasonMessage": "string"
      }
    ]
  }
}

Terms explained:
performed is true, if Liveness Checks fulfilled all the conditions.
passed is true, if Liveness Checks passed the Liveness Check.

Liveness Call Flow Chart#

SpoofCheck response flowchart