Liveness detection — одна из тех технологий, вокруг которых накопилось больше мифов, чем точных формулировок: её путают с распознаванием лица, ей приписывают стопроцентную защиту от подделок и иногда называют обязательным требованием закона, которым она не является. При этом сама технология описана в международном стандарте достаточно точно, чтобы развести эти представления без лишних споров.
Что такое liveness detection простыми словами
Liveness (лайвнес), или проверка живости (иногда — витальности), — технология, которая помогает определить, находится ли перед камерой живой человек, а не фотография, видеозапись, маска или другой способ имитации. Технология работает в момент биометрической съёмки: система оценивает не то, кто перед камерой, а то, живой ли это человек, присутствующий в точке съёмки, а не запись, фотография или воспроизведение.
Что говорит стандарт: живость и проверка живости
Точные формулировки задаёт ISO/IEC 30107-1:2023 — международный стандарт, определяющий рамку для обнаружения атак предъявления. Стандарт вводит два связанных, но разных понятия. Живость (liveness) — «свойство или состояние быть живым, которое проявляется через анатомические характеристики, непроизвольные реакции, физиологические функции, произвольные реакции и поведение субъекта». Проверка живости (liveness detection) — «измерение и анализ анатомических характеристик либо непроизвольных или произвольных реакций, чтобы определить, снимается ли биометрический образец с живого человека, присутствующего в точке съёмки».
Рядом стандарт вводит ещё два термина, которые понадобятся дальше: добросовестное предъявление (bona-fide presentation) — предъявление биометрии без цели вмешаться в работу системы, и атака предъявления (biometric presentation attack) — предъявление с прямо противоположной целью.
Почему проверка живости — часть более широкой задачи
Примечание 1 к пункту 3.3 стандарта гласит дословно: «Liveness detection methods are a subset of presentation attack detection methods» — методы проверки живости являются подмножеством методов обнаружения атак предъявления. Проверка живости — не синоним обнаружения атак предъявления (presentation attack detection, PAD), а его часть: PAD шире и включает работу с предъявлениями, которые не сводятся к вопросу «жив ли субъект», — например, с изменёнными или искусственно сконструированными биометрическими характеристиками.
В большинстве материалов на русском языке, включая страницы поставщиков решений, liveness и PAD используются как взаимозаменяемые понятия. Это упрощение, а не ошибка в быту, но для точного разговора о технологии разница важна: там, где речь идёт конкретно о выявлении живого присутствия, корректно говорить о liveness detection; там, где о выявлении любых атак предъявления в целом, включая случаи, не сводящиеся к живости, — о PAD.
Чем проверка живости отличается от распознавания лица
Это второе разграничение, без которого разговор о liveness detection быстро превращается в путаницу. Задачи разные, хотя и не независимые.
| Задача | Отвечает на вопрос | Что сравнивает |
|---|---|---|
| Обнаружение лица (face detection) | есть ли лицо в кадре и где оно | ничего, только находит область |
| Проверка живости (liveness detection) | перед камерой живой человек или его изображение | сам образец, без обращения к эталону |
| Верификация лица (face verification, 1:1) | это тот же человек, что на документе или в профиле | два образца между собой |
| Идентификация лица (face identification, 1:N) | кто этот человек среди многих | образец с базой |
Короткая формула: распознавание отвечает на вопрос «кто это», проверка живости — на вопрос «настоящий ли это человек». При подтверждении личности эти задачи обычно дополняют друг друга: система верификации лица без механизмов проверки живости или PAD может оказаться уязвимой для предъявления фотографии или другого артефакта, а проверка живости без распознавания подтвердит присутствие живого человека, но не то, за кого он себя выдаёт.
Здесь важна оговорка, без которой формула станет неточной: на практике обе задачи часто решаются в одном модуле на одном и том же кадре, а часть сигналов — текстура кожи, глубина, освещение — используется в обеих. Называть их полностью независимыми технологиями было бы неточно. Подробно о том, как устроено распознавание лиц, как оно достигает точности и в чём разница верификации и идентификации, — в статье «Система распознавания лиц: как работает, точность и где применяется».
Как работает проверка живости: какие сигналы анализирует система
Опираясь на определение стандарта, признаки живости группируются в несколько категорий:
- анатомические характеристики — текстура кожи, отражение и поглощение света кожей и кровью, объём и рельеф лица
- непроизвольные реакции и физиологические функции — моргание, микродвижения мимических мышц, реакция зрачка на свет, признаки сердечной активности
- произвольные реакции и поведение — движение по запросу системы, если сценарий предполагает такой запрос
- геометрия и глубина сцены — плоский объект перед камерой ведёт себя иначе, чем объёмное лицо; на обычной камере глубина оценивается косвенно, по параллаксу и освещению
- свойства самого изображения — артефакты печати, муар экрана, следы перепаковки видео
Стоит уточнить формулировку, которая иначе выглядит противоречиво: если решение работает в пассивном режиме без инструкций пользователю, это не значит, что оно игнорирует моргание или повороты головы как признаки — оно анализирует их как естественные микродвижения, которые происходят сами по себе, а не как действия, выполненные по запросу. Разница между «система смотрит на моргание» и «система просит моргнуть» — это и есть разница между пассивным и активным режимом, о которой дальше в статье.
Активная и пассивная проверка живости
| Режим | Что делает пользователь | Типичный сценарий |
|---|---|---|
| Активный (active liveness) | выполняет действие по запросу — поворачивает голову, моргает, произносит цифры, следит за точкой на экране | сценарии с запросом-откликом, где пользователь выполняет конкретное действие по инструкции системы |
| Пассивный (passive liveness) | ничего не делает специально, смотрит в камеру как при обычной съёмке | быстрый онбординг, минимизация трения для пользователя |
Разница между режимами — прежде всего в пользовательском опыте и требованиях к сценарию съёмки, а не в том, какой из них «сильнее» против конкретных типов подделок: устойчивость активного и пассивного режима к отдельным типам атак — тема отдельного разбора, а не этой статьи.
Что видит пользователь в каждом режиме
В активном режиме пользователь получает инструкцию и видит, что система ждёт от него действия — это делает процесс нагляднее, но добавляет шаг и требует времени. В пассивном режиме процесс не требует от пользователя ничего, кроме того, чтобы смотреть в камеру, и обычно занимает меньше времени, чем активный, — конкретная скорость зависит от решения, — за счёт этого меньше трения для пользователя, но он не видит явного подтверждения того, что проверка вообще происходит.
По данным продуктовой страницы и документации, NeuroVision заявляет и пассивный, и активный сценарий. В пассивном пользователю достаточно смотреть в камеру. В активном документация описывает три режима заданий: простые команды вроде поворота головы или моргания, усложнённые комбинации в быстрой последовательности и круговое движение головой — по аналогии с первичной настройкой Face ID. Какой сценарий включён, зависит от настройки проверки.
Почему стандарт делит методы иначе
Важно не путать эту отраслевую классификацию со структурой самого стандарта. ISO/IEC 30107-1:2023 не делит методы проверки живости на активные и пассивные: там, где стандарт разбирает роль запроса-отклика (раздел 5.2), он различает: проверка живости, связанная с запросом-откликом; проверка живости, не связанная с запросом-откликом; и запрос-отклик, не относящийся собственно к биометрии. В отрасли эти категории закрепились в бытовом делении на активный и пассивный liveness, но это классификация продуктов, а не формулировка стандарта.
Где проверка живости стоит в процессе проверки клиента
Проверка живости — не самостоятельная процедура, а один из шагов в процессе подтверждения личности — чаще всего в цепочке KYC: после того как система обнаружила лицо в кадре, но до того, как результат съёмки сравнивается с документом или базой. По данным продуктовой страницы, проверку живости можно подключать как отдельный модуль — независимо от сверки с документом и распознавания данных, — что позволяет встраивать её в уже существующий процесс, а не перестраивать его целиком. Подробно о том, как устроена полноценная проверка клиента от загрузки документа до решения, — в статье «KYC шаг за шагом: как устроена полноценная проверка клиента в онлайн-сервисах».
Как именно устроена эта последовательность, зависит от конкретного продукта. По документации NeuroVision сценарий проверки клиента выглядит так: пользователь начинает со вступительного экрана или перехода по QR-коду, затем фотографирует документ, делает селфи, проходит проверку живости, после чего система сравнивает лицо с фотографией в документе и выносит решение по сессии. Это устройство сценария конкретно у NeuroVision, а не универсальная архитектура отрасли — у других вендоров порядок шагов может отличаться.
В этой цепочке решаются разные вопросы, и их стоит не путать: проверка живости отвечает на вопрос «перед камерой живой человек?», сверка лица с документом (face matching) — «совпадает ли лицо с фото в документе?», проверка документа — «корректен ли документ и что из него извлечено?», а антифрод-проверки — «есть ли признаки манипуляции или повторного предъявления?». По документации NeuroVision задача сверки лиц появляется в сессии только тогда, когда есть и документ, и селфи.
Какие атаки пытается обнаружить проверка живости
Смысл проверки живости — отличить добросовестное предъявление от атаки предъявления: попытки представить системе не самого человека, а артефакт. У атаки предъявления может быть одна из двух целей, которые редко разводят: выдать себя за другого человека (impersonation) — самый очевидный сценарий, и избежать собственного узнавания (evasion) — например, чтобы не быть привязанным к уже существующему аккаунту при попытке завести второй. Оба сценария входят в задачу PAD, хотя обсуждают обычно только первый.
Атаки предъявления
Атака предъявления — это попытка показать системе артефакт вместо живого человека. На практике это: распечатанная фотография или другой бумажный носитель; изображение, показанное с монитора или другого дисплея; фотография или видео на экране смартфона; replay — воспроизведение заранее записанного видео; маски, включая объёмные и силиконовые; ксерокопия или обрезанный фрагмент изображения. Именно на этот класс атак рассчитан PAD — обнаружение атак предъявления. Классы атак предъявления, их уровни сложности и то, какими методами их обнаруживают, подробно разобраны в статье «Как обходят проверку витальности» — здесь они не пересказываются.
Цифровые подделки: дипфейк и генеративный монтаж
Отдельно стоит развести два понятия, которые часто путают с самой атакой предъявления. Дипфейк — это способ изготовления артефакта, а не отдельный класс атаки: один и тот же синтезированный образ может быть показан камере с экрана (тогда это обычная атака предъявления) или подан прямо в видеопоток в обход камеры (тогда это уже инжекционная атака — о ней ниже). Сюда же относят face swap — перенос лица другого человека на изображение, и полностью сгенерированные нейросетью лица. О том, как устроены такие подделки и как их выявляют в контексте видеоверификации, — в статье «Дипфейк в KYC: детекция подмены лица».
Инжекционные атаки — отдельный класс вне PAD
Подача заранее подготовленного видеопотока в обход камеры — уже не атака предъявления, а инжекционная атака: она подменяет саму подсистему захвата или канал между ней и алгоритмом и находится вне области классического PAD, который оценивает только то, что предъявлено исправному датчику. PAD-тестирование по стандартам вроде ISO/IEC 30107-3 не подтверждает устойчивость к инжекции — это отдельная задача, для которой нужны дополнительные механизмы защиты канала захвата и видеопотока. Подробнее — в статье «Как подменяют видеопоток в KYC».
Есть и смежные сценарии, которые внешне похожи на обман проверки живости, но решаются другими механизмами. Если лицо в кадре не совпадает с фотографией в документе, если предъявлен чужой документ или если пол или возраст на селфи не соответствуют данным документа — это уже не задача liveness, а задача сверки лица с документом (face matching) и других антифрод-проверок селфи. Как эти механизмы устроены и что из них умеет NeuroVision — ниже.
Что выявляет проверка живости NeuroVision
По документации продукта разные типы подделок распределены между разными механизмами проверки — не только между алгоритмом проверки живости:
| Сценарий атаки | Что пытается сделать злоумышленник | Какой слой проверки NeuroVision |
|---|---|---|
| Фотография, экран, видеозапись (replay), маска | представить артефакт вместо живого человека | проверка живости (Liveness Check) — код 44 «is not alive» |
| Дипфейк, face swap, полностью сгенерированное лицо | подделать изображение лица нейросетью | проверка селфи на признаки генерации — флаг isFaceDeepFake, код 43 |
| Изображение с экрана или мобильного устройства, ксерокопия, обрезанный кадр | подменить исходный кадр | антифрод-проверки селфи — isDisplaySelfie, isMobile, isXerocopy, isCropped |
| Чужое лицо на селфи | выдать себя за другого человека | сверка лица с документом (face matching) — код 19 «bad face matching» |
| Несоответствие пола или возраста документу | использовать чужие данные | проверки соответствия — isGenderMismatch, isAgeMismatch |
В NeuroVision эти проверки работают как части единого процесса верификации, но решают разные задачи. Liveness определяет, находится ли перед камерой живой человек, антифрод-механизмы анализируют селфи на признаки подделки или манипуляции, а Face Matching сравнивает лицо пользователя с фотографией в документе. Это разные уровни защиты, которые дополняют друг друга: успешное прохождение одной проверки не заменяет остальные.
Ниже показано, как этап проверки живости выглядит для пользователя в интерфейсе NeuroVision.
Как отрасль проверяет качество решений
ISO/IEC 30107 и независимые лаборатории
Методологию оценки задаёт ISO/IEC 30107-3:2023 «Testing and reporting» — часть стандарта, которая устанавливает принципы и методы тестирования механизмов PAD, порядок отчётности и классификацию известных типов атак. Метрики, которыми измеряют качество (APCER и BPCER), и уровни сложности атак, которые использует эта методология, подробно разобраны в статье «Как обходят проверку витальности» — здесь достаточно знать, что такая методология существует и стандартизована.
Устойчивость конкретных решений к известным типам атак подтверждают испытания в независимых аккредитованных лабораториях — например, iBeta, Ingenium, BixeLab. Лабораторное тестирование на соответствие ISO/IEC 30107-3 (по его итогам лаборатория выдаёт письмо-подтверждение результатов, а не сертификат) показывает устойчивость к известным типам атак в контролируемых условиях, но не заменяет мониторинга на реальных данных после внедрения.
Что тестирует NIST и почему это не FRTE
У NIST есть отдельный трек именно для проверки живости — Face Analysis Technology Evaluation, FATE PAD. Это не тот же трек, что FRTE, который используется для оценки точности распознавания лиц: 18 августа 2023 года NIST разделил прежнюю программу FRVT на два самостоятельных направления — FRTE для распознавания и FATE для анализа лица, включая PAD.
На сентябрь 2026 года приём заявок в трек временно приостановлен: NIST не принимает алгоритмы на оценку PAD и сообщит об открытии трека на своём сайте и в рассылке. Последний публичный отчёт трека — NISTIR 8491, «Face Analysis Technology Evaluation (FATE) Part 10: Performance of Passive, Software-based Presentation Attack Detection (PAD) Algorithms», вышел в сентябре 2023 года и охватывает 82 пассивных программных алгоритма на обычных двумерных изображениях. Практический вывод: постоянного публичного бенчмарка для проверки живости, аналогичного FRTE для распознавания лиц, на сегодня нет, и ссылка поставщика на «тестирование NIST» требует уточнения, о каком именно треке и годе отчёта идёт речь.
Ограничения технологии и на что смотреть при выборе решения
Стандарт прямо оговаривает границы того, что умеет PAD: «PAD cannot infer the biometric capture subject’s intent» — система не определяет намерение человека, она различает добросовестное предъявление и атаку по измеримым признакам, но не читает мотив. Отдельное примечание к стандарту указывает, что система может быть не в состоянии отличить атаку от просто неудачного предъявления. На практике это значит, что часть отказов — не попытки обмана, а следствие условий съёмки: контровой свет, блики на очках, дрожание камеры, слабая матрица устройства.
Из этого вытекает практический компромисс: чем строже настроен порог проверки, тем меньше пропущенных атак, но тем больше отклонённых реальных пользователей, — и наоборот. Качество работы зависит от устройства, освещения и сценария съёмки. Проверка живости отвечает только на вопрос о живом присутствии человека и не подтверждает личность — для этого нужен отдельный шаг сверки с документом или базой. Методы, устойчивые к известным сегодня типам подделок, не дают гарантии против новых методов, которые появятся позже. И отдельно: проверка живости не закрывает риски подмены самого источника кадров — камеры или канала между камерой и алгоритмом, — такие как подмена видеопотока, разобранная в статье выше.
При выборе решения имеет смысл смотреть на несколько практических параметров:
- подходит ли режим — активный или пассивный — сценарию и ожидаемой пользовательской нагрузке
- какие требования к камере и устройству предъявляет решение — работает ли оно на обычной фронтальной камере смартфона или ноутбука без специального оборудования
- скорость получения результата и то, как она соотносится с остальным временем прохождения проверки
- варианты развёртывания — облако или собственная инфраструктура — и доступность SDK и API для нужных платформ
- возможность подключить проверку живости отдельным модулем к уже существующему процессу распознавания документов и данных
- наличие независимого тестирования устойчивости к известным типам атак как ориентира, а не гарантии
По данным продуктовой страницы, решение NeuroVision для проверки живости поддерживает и пассивный, и активный сценарий на обычной фронтальной камере и возвращает результат через REST API в виде решения pass/fail. Серверная обработка занимает доли секунды, а полный сценарий с активной проверкой, по документации NeuroVision, может занимать до минуты. По продуктовой странице решение предлагается как SDK для Web, iOS и Android и подключается отдельным модулем к распознаванию документов, сверке лиц и AML-проверке.
Пассивный и активный сценарии, обычная камера смартфона, готовые SDK и REST API — подключается отдельным модулем к существующему процессу проверки клиента
Liveness detection — понятие, определённое стандартом ISO/IEC 30107, которое описывает проверку того, снимается ли биометрический образец с живого человека, присутствующего в точке съёмки. Это подмножество более широкой задачи обнаружения атак предъявления, а не её синоним, и отдельная задача по отношению к распознаванию лица — обе решают разные вопросы и вместе образуют полноценную проверку клиента. Деление на активный и пассивный режим — практика отрасли, а не структура самого стандарта, который для проверки живости использует не «режимы», а понятие запроса-отклика. У технологии есть чётко описанные границы: она не читает намерение человека, может ошибаться на неудачных кадрах и не закрывает риски подмены источника видеопотока в обход камеры. Выбор режима и решения зависит от сценария: пассивный режим снижает трение при онбординге, активный подходит там, где нужен запрос-отклик с конкретным действием пользователя, а независимое тестирование помогает оценить устойчивость к известным типам атак, не превращаясь при этом в гарантию защиты от новых.
FAQ
