Реализация AI-Liveness Detection (проверка живости) при верификации

Реализация AI-Liveness Detection (проверка живости) при верификации

Атаки с фото, видео и масками — реальность для любого сервиса с удалённой верификацией. Liveness Detection различает живого человека и артефакт, но выбор между активной и пассивной проверкой критичен. Активная требует действий (поворот головы, моргание) — это даёт высокую защиту от photo spoofing, но снижает конверсию на 15–20%. Пассивная анализирует один кадр или короткое видео, не требуя действий, но хуже справляется с 2D-атаками без depth анализа.

Мы интегрируем liveness-решения под ключ: от выбора стратегии до публикации в сторах. За 5 лет реализовали 20+ проектов для финтеха, EdTech и госсектора. Стек — ARKit (iOS), ML Kit + ARCore (Android), CoreML/TFLite, и готовые сертифицированные SDK (Iproov, Jumio, Onfido, Sumsub). Для каждого проекта строим threat model и подбираем оптимальный баланс между безопасностью и UX.

Один из кейсов — банковское приложение: после внедрения пассивной проверки с depth map время верификации сократилось до 3 секунд (с 12 секунд активной), а конверсия выросла на 12%. Такие результаты подтверждают, что правильный выбор liveness напрямую влияет на бизнес-метрики.

Как выбрать между активной и пассивной liveness?

Активная liveness — пользователь выполняет действие: поворачивает голову, моргает, произносит код. Плюс — высокая устойчивость к photo spoofing. Минус — UX: 15–20% пользователей не проходят с первой попытки, конверсия падает. Также уязвима к deepfake-видео, где движение синтезируется под команду.

Пассивная liveness — анализ одного кадра или короткой последовательности без инструкций. Пользователь просто смотрит в камеру. Хуже справляется с 2D-атаками (высококачественные фото), лучше по UX. Современные пассивные модели класса ISO 30107-3 Level 2 выдерживают атаки с печатными фотографиями и 2D-экранами.

Если вы не уверены, какая стратегия подходит вашему сценарию, получите консультацию — мы проанализируем вашу threat model и предложим оптимальное решение.

Реализация на 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 на более тяжёлой модели.

Что входит в работу

1. Анализ threat model и выбор активная/пассивная/гибридная liveness.
2. Интеграция SDK или кастомная разработка на ARKit/ML Kit/CoreML/TFLite.
3. Настройка threshold с A/B тестированием и метриками FAR/FRR.
4. Тестирование атак (фото, экран, маска, deepfake).
5. Интеграция с IDV-пайплайном и бэкендом.
6. Публикация в App Store / Google Play с соблюдением гайдлайнов.
7. Документация и обучение команды.

Сроки: интеграция готового SDK — 2–4 недели. Кастомная реализация с обучением модели — 8–14 недель. Стоимость рассчитывается индивидуально.

Оценим ваш проект — свяжитесь с нами для консультации. Получите предварительную оценку сроков и стоимости за один рабочий день.