Presentation Attack Detection (PAD)
Presentation Attack Detection (PAD) is an opt-in anti-spoof check that runs
passively during the normal scan flow. When a presentation attack is detected,
the scan terminates with the PAD_DETECTED error.
Enabling PAD
PAD is disabled by default. Enable it by setting isPadCheckEnabled to true
on your BcmScanConfig:
Swift:
let scanConfig = BcmScanConfig(
// ...,
isPadCheckEnabled: true
)
When enabled, PAD evaluation runs alongside the regular finger capture. No additional user interaction is required.
What PAD Detects
PAD targets two attack vectors that are common against camera-based finger capture:
Glare attacks
Flat presentations (a screen or a printed photo) reflect the device torch
unevenly across fingers compared to real skin. Each captured finger image is
analyzed for the proportion of highly luminant pixels — pixels whose luminance
exceeds a fixed threshold under the standard Rec. 709 luma weighting
(0.2126·R + 0.7152·G + 0.0722·B).
If the spread (standard deviation) of glare ratios across the fingers in the hand exceeds an internal threshold, the frame is treated as a glare attack. Glare evaluation only runs when the torch is on, since glare is a torch-induced signal.
Parallax attacks
A flat 2D spoof — a photo or a screen — moves as a single rigid plane. Real 3D fingers exhibit subtle, independent motion that produces nonlinear bounding-box trajectories.
PAD tracks each finger's bounding box across frames (a minimum window of frames is required before a verdict is produced). For each finger it fits a linear motion model and measures the residual deviation from that linear path. If every finger's trajectory stays within a small residual — i.e. the whole hand moves rigidly with no per-finger parallax — the frame is treated as a parallax attack.
How PAD Is Wired Into the Scan Flow
PAD evaluation happens at three points during a scan:
- On every bounding-box frame — parallax is checked as soon as enough frames have accumulated.
- On extracted finger images — glare is checked while frames are being collected, when the torch is on.
- At the final scan result — glare is re-checked on the final images, and any latched detection from earlier in the scan is enforced.
The scan does not abort the moment a single suspicious frame is observed.
Instead, the flow latches a "PAD triggered" flag together with the trigger
reason (P for parallax, G for glare). The scan continues to its natural
end, and at the final result step the flow delegate is notified via
PBcmFlowDelegate:
bcmUnrecoverableError(errorCode: .PAD_DETECTED, message: "Presentation attack detected (P|G)")
The trigger reason is appended to the error message so it can be surfaced in logs or telemetry.
Behavior Notes
- Torch dependency — glare detection is meaningful only with the torch on. When the torch is off, glare evaluation is skipped; parallax is still evaluated.
- Frame budget — parallax requires a small history of frames before it can produce a verdict. Very short scans may complete before enough history accumulates to evaluate parallax.
- Hand-level decision — both checks operate on the set of fingers in a hand, not on individual fingers in isolation. Glare uses the spread across fingers; parallax requires all fingers to look rigid.
- Algorithm parity — the iOS and Android implementations share the same algorithms and thresholds; integration semantics are identical across platforms.
- Hardcoded thresholds — internal thresholds (luminance cutoff, glare spread, parallax residual, minimum frame count) are not exposed through the public API.
Handling PAD_DETECTED
Treat PAD_DETECTED as an unrecoverable scan error. A typical handler will:
- Cancel the current scan session and return the user to your application's pre-scan screen.
- Show a user-facing message that the scan could not be completed and ask the user to retry with their real fingers in good lighting.
- Optionally log the trigger reason for fraud analysis.
Do not automatically retry the scan in the same session — the trigger reason is part of the security signal you may want to preserve for downstream review.