Реализация AI-Liveness Detection (проверка живости) при верификации
Фотография с телефона, маска, видео с YouTube — всё это попытки обойти биометрическую верификацию. Liveness Detection решает одну задачу: убедиться, что перед камерой — живой человек, а не артефакт. Но за этой задачей стоит нетривиальный выбор между активной и пассивной проверкой, уровнями атак ISO 30107 и latency, с которой пользователь готов мириться.
Активная vs пассивная проверка живости
Активная liveness — пользователь выполняет действие: поворачивает голову, моргает, произносит код. Плюс — высокая устойчивость к photo spoofing. Минус — UX: 15–20% пользователей не проходят с первой попытки, конверсия падает. Также уязвима к deepfake-видео, где движение синтезируется под команду.
Пассивная liveness — анализ одного кадра или короткой последовательности без инструкций. Пользователь просто смотрит в камеру. Хуже справляется с 2D-атаками (высококачественные фото), лучше по UX. Современные пассивные модели класса ISO 30107-3 Level 2 выдерживают атаки с печатными фотографиями и 2D-экранами.
Для KYC-приложений с требованием iBeta PAD Level 2 (ISO 30107-3) нужна комбинация: пассивная проверка + depth analysis через ARKit/ARCore.
Реализация на iOS через ARKit
ARKit на iPhone X+ и iPad Pro с TrueDepth-камерой даёт доступ к depth map в реальном времени. ARFaceTrackingConfiguration создаёт ARFaceAnchor с 52 blend shapes — включая eyeBlinkLeft, eyeBlinkRight, jawOpen. Это уже полноценный активный liveness без сторонних SDK.
let config = ARFaceTrackingConfiguration()
config.maximumNumberOfTrackedFaces = 1
session.run(config)
// В ARSCNViewDelegate
func renderer(_ renderer: SCNSceneRenderer, didUpdate node: SCNNode, for anchor: ARAnchor) {
guard let faceAnchor = anchor as? ARFaceAnchor else { return }
let eyeBlink = faceAnchor.blendShapes[.eyeBlinkLeft]?.floatValue ?? 0
if eyeBlink > 0.7 { livenessDetector.recordBlink() }
}
Depth map из depthData на AVCapturePhotoOutput позволяет отклонить плоское изображение: если stddev глубины лица <5mm — перед камерой плоская поверхность.
Ограничение: ARKit FaceTracking работает только на устройствах с TrueDepth (фронтальная True Depth камера). iPhone SE, iPad mini — не поддерживаются. Для этих устройств fallback — RGB-only модель на CoreML.
Реализация на Android через ML Kit Face Mesh
com.google.mlkit:face-mesh-detection (ML Kit 18.0+) даёт 468 3D-точек сетки лица из монокамеры. Это не настоящий depth, а 3D-реконструкция из 2D — точнее, чем ничего, но слабее ARKit TrueDepth.
val options = FaceMeshDetectorOptions.Builder()
.setUseCase(FaceMeshDetectorOptions.FACE_MESH)
.build()
val detector = FaceMeshDetection.getClient(options)
detector.process(inputImage)
.addOnSuccessListener { faces ->
faces.firstOrNull()?.let { face ->
val zVariance = face.allPoints.map { it.position.z }.variance()
if (zVariance < FLAT_THRESHOLD) rejectAsFlatImage()
}
}
На Android 10+ с ARCore-совместимым устройством лучше использовать ArCoreApk + AugmentedFace — получаем настоящий depth через structured light или ToF (устройства с такими сенсорами: Pixel 6+, Samsung S21+).
Сторонние SDK: когда это оправдано
Iproov, Jumio, Onfido, Sumsub — готовые liveness SDK с сертификацией ISO 30107-3 Level 2. Сертификация сама по себе стоит сотни тысяч долларов и занимает месяцы. Если продукт работает в регуляторной среде, где требуется именно сертифицированное решение — собственная реализация нецелесообразна.
Если регулятор не требует сертификата, а задача — защита от бытовых атак (photo spoofing, видео с телефона) — кастомная реализация на ARKit + CoreML / ML Kit + TFLite справляется и обходится дешевле лицензий.
Типичные ошибки
Порог без контекста. livenessScore > 0.85 в коде без объяснения — через месяц никто не помнит, откуда цифра и как она менялась. Нужен конфигурируемый threshold с A/B тестированием и метриками FRR/FAR.
Игнорирование атак с deepfake. Пассивная liveness без depth уязвима к GAN-генерированным лицам. Если это в threat model — нужен анализ texture inconsistency (GAN-артефакты в frequency domain через FFT) или серверный inference на более тяжёлой модели.
Этапы внедрения
Анализ threat model → выбор активная/пассивная/гибридная liveness → выбор SDK или кастомная разработка → интеграция с камерой и биометрическим потоком → тестирование атак (фото, экран, маска, deepfake) → настройка threshold → интеграция с IDV-пайплайном → публикация.
Сроки: интеграция готового SDK — 2–4 недели. Кастомная реализация на ARKit/ML Kit с обучением модели — 8–14 недель. Стоимость рассчитывается индивидуально.