Многие решения для удалённой идентификации строят итоговый вердикт на косвенных признаках: окружении браузера, сетевом отпечатке, телеметрии камеры и статистике изображения. Эти данные полезны для оценки риска, но становятся слабой основой защиты, если система принимает их за независимое подтверждение подлинности. С развитием генеративного ИИ и атак с подменой медиапотока различие между правдоподобным и подтверждённым документом стало принципиальным. Эту угрозу отдельно рассматривают NIST и ENISA.[1][2]

Что на самом деле должна подтверждать проверка

Надёжный процесс разделяет три независимых вопроса:

  1. Подлинность документа: соответствует ли предъявленный носитель или цифровое свидетельство документу, выпущенному уполномоченным источником?
  2. Действительность сведений: подтверждаются ли реквизиты, факт выдачи и, когда это доступно, актуальный статус документа доверенным источником?
  3. Принадлежность предъявителю: есть ли достаточные основания считать, что проверку проходит именно лицо, которому документ выдан?

Совпадение полей или отсутствие признаков редактирования изображения закрывает лишь часть первого вопроса. NIST SP 800-63A-4 прямо разделяет установление личности, проверку достоверности свидетельств и подтверждение связи предъявителя с заявленной личностью.[1]

Восемь слабых мест распространённых подходов

1. Доверие к JavaScript и окружению браузера

Некоторые системы делают вывод о типе устройства и «естественности» сессии по User-Agent, navigator.platform, языку, часовому поясу, сенсорному вводу, параметрам экрана, Canvas/WebGL-отпечаткам и другим данным JavaScript.

Проблема — источник доверия. Браузерная среда контролируется стороной, инициирующей запрос. Поэтому её заявления нельзя приравнивать к аппаратно подтверждённым фактам. Проверка JavaScript годится для поиска несоответствий и повышения оценки риска, но не должна самостоятельно решать, является ли устройство настоящим и допустима ли идентификация. OWASP отдельно требует повторной проверки значимых условий на сервере.[3]

2. Статические списки proxy/VPN и единственный сетевой отпечаток p0f

IP-репутация, списки дата-центров, известных VPN, proxy и анонимизаторов дают полезные сигналы, но не доказывают происхождение документа. Статические списки не охватывают все возможные маршруты трафика, а использование или отсутствие proxy само по себе не определяет добросовестность пользователя.

p0f анализирует пассивные признаки TCP/IP-стека. Это не механизм аттестации физического устройства. При работе через прикладной proxy сетевой отпечаток может относиться к промежуточному узлу, а не к исходному клиенту. Разработчики p0f также рекомендуют трактовать результат как вспомогательный сигнал.[4] Проверка только по IP или p0f не способна достоверно установить, что за запросом стоит конкретный мобильный телефон.

3. Запись параметров камеры и телеметрии по N кадрам

В процессе съёмки сервис может собирать имя камеры (label), deviceId, groupId, разрешение, частоту кадров, ориентацию камеры, временные метки и последовательность изображений. Из самих кадров дополнительно рассчитывают яркость (luminance), размытость (blur), резкость, контраст, экспозиционные изменения, блики, движение, межкадровую согласованность и пропуски кадров. Доступность конкретных параметров зависит от браузера, устройства и разрешений.[5][6]

Такая телеметрия описывает полученный поток, но сама по себе не удостоверяет его физический источник. Если злоумышленник контролирует входящее медиа, он может пытаться воспроизвести ожидаемую динамику показателей. Захват нескольких кадров, анализ освещения и запросы на движение усложняют атаку, однако не заменяют проверку происхождения сигнала и защиту от цифровой инъекции.[2]

4. Статический анализ изображения: heat map, шум и артефакты

Алгоритмы анализируют карты аномалий (heat maps), Error Level Analysis, шумовые остатки, признаки PRNU, JPEG-квантование, DCT-коэффициенты, границы вставок, локальные изменения резкости, неоднородность освещения, геометрию символов и совпадение с шаблоном документа.

Эти методы обнаруживают статистические отклонения, а не факт государственной выдачи. Результат зависит от кодирования, повторной съёмки, качества сенсора и распределения обучающих данных. Отсутствие заметных артефактов не доказывает подлинность, а обнаруженная аномалия не всегда означает подделку. NIST требует проверять такие алгоритмы на подлинных и атакующих образцах и учитывать ложные срабатывания и пропуски.[2]

5. Формальное соответствие MRZ, штрихкода и печатных данных

Сравнение визуальной зоны (VIZ) с машиночитаемой зоной (MRZ), проверка контрольных цифр, дат и структуры двумерных кодов необходимы. Но корректная контрольная цифра подтверждает согласованность данных, а не то, что государственный орган когда-либо выпускал документ с этими реквизитами.

Обратная ошибка ещё опаснее: система замечает расхождение между MRZ и лицевой стороной, но не блокирует положительный вердикт. В NIST SP 800-63A-4 сравнение MRZ или штрихкода с напечатанными данными прямо включено в требования к автоматизированной оптической проверке.[2]

6. «Динамические» токены без защиты от повторного использования

nonce, идентификатор операции и одноразовый challenge полезны только тогда, когда сервер проверяет их срок действия, привязку к сессии и этапу процесса, а также факт предыдущего использования. Случайно сгенерированная строка не является защитой, если её можно многократно предъявлять для разных проверок.

Антиповтор должен обеспечиваться серверной логикой и, где применимо, криптографической привязкой результата к конкретной операции. OWASP рассматривает повторное использование токенов и пропуск этапов процесса как риски бизнес-логики API.[7]

7. Liveness и распознавание лица как замена проверке документа

Проверка присутствия человека (liveness / PAD) и сравнение лица с фотографией решают важные, но ограниченные задачи. Даже успешное биометрическое сопоставление не устанавливает факт выдачи документа или что человек чье лицо на документе является тем за кого он себя выдает. Кроме того, тестирование PAD и устойчивость всей цепочки к цифровой подмене — разные виды оценки. ISO/IEC 30107-3:2023 посвящён испытаниям PAD, но не заявляет оценку безопасности всей системы удалённой идентификации.[8]

8. Самообучающиеся модели без защиты от отравления данных

Особый риск возникает, когда система автоматически использует результаты пользовательских загрузок или слабо проверенную обратную связь для изменения весов модели. Без доверенной разметки, карантина новых примеров, контроля версий и независимой валидации злоумышленник получает возможность влиять на будущие решения.

Такой класс угроз известен как data poisoning и подробно рассматривается NIST в таксономии атак на системы машинного обучения.[9]

Почему проблема обострилась в эпоху генеративного ИИ

Защита, основанная только на ожидаемой последовательности наблюдений, уязвима к воспроизведению: если сервер получает уже сформированный поток, он не может автоматически считать измеренные blur, luminance, движение и задержки независимыми свидетельствами реальной съёмки. Детерминированные клиентские проверки при достаточном контроле входных данных в ряде сценариев можно повторить с высокой точностью.

Это не означает, что любой алгоритм обходится гарантированно или что все liveness-механизмы бесполезны. Защита становится сильнее при непредсказуемых проверках, подтверждении подлинности сенсора, серверной привязке сессии, независимых источниках данных и криптографической проверке. Однако ни один из этих факторов в одиночку не равен доказательству реальной личности. ENISA выделяет атаки с цифровой инъекцией и поддельными медиа как значимые угрозы удалённой идентификации.[10]

Что мы обнаруживали в проверках с разрешения заказчиков

В рамках согласованных с владельцами систем исследований наша команда фиксировала следующие классы ошибок:

  1. Доверие к User-Agent. Часть реализаций принимала заявление о мобильном браузере без достаточной независимой проверки характеристик соединения и устройства.
  2. Повторное использование защитных параметров. Параметры, заявленные как «динамические», принимались сервером повторно без надлежащего контроля жизненного цикла.
  3. Отравление live-learning. В одной самописной системе загружаемые поддельные документы влияли на обучающий контур, и признаки таких образцов начали получать преимущество перед ранее зафиксированными эталонными критериями.
  4. Игнорирование противоречий. В одной из реализаций несоответствие между данными машиночитаемой зоны и визуальной частью документа не препятствовало положительному решению.

О выявленных недостатках ответственные стороны и производители были уведомлены. Приведённые случаи — результаты наших частных аудитов, а не публичный статистический срез рынка: названия систем, объём выборки и воспроизводимые материалы здесь не раскрываются. Они иллюстрируют конкретные ошибки проектирования и не означают, что все поставщики допускают такие же уязвимости.

Главная граница доверия — источник выдачи, а не изображение

Документ может идеально выглядеть и внутренне согласовываться, но содержать реквизиты несуществующей или не подтверждённой уполномоченным источником личности. Поэтому вердикт «признаков монтажа не выявлено» нельзя подменять вердиктом «личность установлена».

При наличии законного и технического доступа проверка должна сопоставлять ключевые атрибуты и статус документа с государственным реестром, источником выдачи или иным авторитетным либо проверяемо достоверным источником. Для электронных паспортов существует отдельный криптографический путь: проверка цифровой подписи данных чипа и цепочки доверия DSC → CSCA, описанная ICAO. Она подтверждает происхождение и целостность подписанных данных, но сама по себе не заменяет проверку актуального статуса документа и связи с предъявителем.[1][11]

Если доступ к надёжному источнику отсутствует, корректный результат — «подлинность выдачи или актуальный статус не подтверждены», а не безусловное «документ подлинный». Отсутствие ответа реестра при этом не доказывает подделку: система должна различать отрицательную проверку и отсутствие возможности проверить.

Какой вывод позволяют сделать разные уровни проверки
УровеньЧто он показываетЧего он не доказывает
Окружение браузера и сетьНаличие рисковых признаков соединения и сессииПодлинность устройства, документа или личности
Камера, liveness и медиаанализСогласованность наблюдаемого потока и признаки подменыФакт государственной выдачи документа
OCR, MRZ, коды и шаблоныФормат и внутреннюю согласованность реквизитовСуществование записи у эмитента
Цифровая подпись и доверенная цепочкаПроисхождение и целостность подписанных данных при корректной валидацииТекущий статус и законность использования предъявителем
Авторитетный источник и проверка предъявителяПодтверждение доступных атрибутов, статуса и связи с личностьюАбсолютное отсутствие мошенничества в любом дальнейшем сценарии

Наш подход: проверка реальных оснований доверия, а не только косвенных признаков

Мы оцениваем систему не по числу датчиков, сигнатур и алгоритмов в презентации, а по тому, какое конкретно утверждение способна доказать каждая проверка и как она ведёт себя при целенаправленной атаке. Для заказчика выстраиваем модель защиты под документы, юрисдикции, сценарий использования и допустимый уровень риска.

  • Независимые уровни контроля. Браузерные, сетевые и визуальные признаки учитываются как дополнительные сигналы риска, а не как самостоятельное доказательство.
  • Защищённый процесс проверки. Серверный контроль этапов, одноразовость и привязка challenge, обнаружение повторов и защита от цифровой подмены потока.
  • Верификация происхождения документа. Проверка допустимых криптографических свидетельств и интеграция с официальными либо иными авторитетными источниками там, где это юридически и технически возможно.
  • Защита обучающего контура. Раздельное хранение пользовательских загрузок и эталонной разметки, контролируемое обновление моделей, проверка смещения качества и возможность отката.
  • Измеримая устойчивость. Оценка ложных допусков и отклонений (включая DFAR/DFRR для анализа документов), испытания на подмену потока, повторы, противоречивые поля и новые типы синтетических изображений.

Для нас сильная проверка — это не обещание «100% защиты», а воспроизводимая процедура с понятными источниками доверия, проверяемыми метриками и явным разделением состояний «подтверждено», «не подтверждено» и «обнаружено противоречие».

Нужна защита от поддельных документов под вашу задачу?

Универсального фильтра, одинаково надёжного для всех документов и каналов проверки, не существует. Если ваша цель — сократить злоупотребления с фальшивыми документами, проверить устойчивость действующего KYC-процесса или построить частное решение под конкретную юрисдикцию и модель угроз, обращайтесь к нам.

Мы поможем выявить, где система полагается на имитируемые сигналы, определить необходимые источники доверия и спроектировать проверку, устойчивость которой можно подтвердить техническим испытанием, а не маркетинговым обещанием.

Технические источники

Источники подтверждают общие технические свойства, модели угроз и стандарты. Частные результаты наших аудитов выше описаны отдельно.

  1. NIST SP 800-63A-4 — Identity Proofing Overview. Разделение установления личности, проверки свидетельств и верификации предъявителя; авторитетные и достоверные источники.
  2. NIST SP 800-63A-4 — Identity Proofing Requirements. Оптический анализ, MRZ, подмена медиапотока, атаки с использованием генеративного ИИ и требования к тестированию.
  3. OWASP — Input Validation Cheat Sheet. Недоверие к клиентской проверке и обязательная валидация сервером.
  4. p0f — документация проекта. Назначение пассивного TCP/IP-фингерпринтинга и ограничения метода.
  5. MDN — MediaDevices.enumerateDevices(). Перечень медиоустройств и ограничения доступа к их метаданным.
  6. MDN — MediaStreamTrack.getSettings(). Доступные параметры медиапотока.
  7. OWASP — REST Security Cheat Sheet. Защита состояния API, порядка шагов и токенов от повторного использования.
  8. ISO/IEC 30107-3:2023. Методы испытаний и отчётности для биометрического обнаружения атак предъявления (PAD).
  9. NIST AI 100-2e2025 — Adversarial Machine Learning. Классификация атак, включая отравление данных и моделей.
  10. ENISA — Remote ID Proofing: Good Practices (2024). Угрозы удалённой идентификации, включая атаки предъявления и цифровую инъекцию.
  11. ICAO — ePassport Basics. Цифровые подписи электронных паспортов и цепочка доверия DSC/CSCA.