Впровадження 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 тижнів. Вартість розраховується індивідуально.

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