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