메인 콘텐츠로 건너뛰기

개요

라이브니스 보고서의 경고는 Didit이 라이브니스 확인을 실행하는 동안 감지한 모든 조건을 표시합니다. 경고는 feature가 "LIVENESS"로 설정된 상태로 liveness_checks[]의 각 항목 내 warnings[] 배열에 포함됩니다(라이브니스 보고서 참조). 각 항목은 공통 경고 객체 형태(feature, risk, additional_data, log_type, short_description, long_description, node_id)를 따릅니다. 모든 경고에는 세 가지 계층이 있습니다.
  1. risk 코드 — 코드에서 일치 여부를 확인할 수 있는 고유 식별자(아래 나열된 코드).
  2. log_type — information, warning, error 중 하나입니다. 자동 거부 위험에는 항상 error가 부여됩니다. 구성 가능한 위험의 경우 설정된 작업에 따라 결정됩니다. 작업 없음 → information, 검토 → warning, 거부 → error. 임계값 기반 위험(LOW_LIVENESS_SCORE, LOW_FACE_QUALITY)의 경우 값이 거부 임계값 이하이면 error, 검토 임계값 이하에만 해당하면 warning이 됩니다.
  3. 결정 영향 — 동일한 라우팅이 라이브니스 보고서의 status를 결정합니다. 검토 작업은 In Review로, 거부 작업(또는 모든 자동 거부 위험)은 Declined로 변경하며, 작업 없음은 상태를 그대로 유지합니다.
일부 위험은 라이브니스 방식이 PASSIVE일 때만 발생합니다(다중 얼굴, 품질 및 휘도 확인). 아래 표에는 전체 라이브니스 위험 코드와 해당 심각도가 나열되어 있으며, 여기에 없는 다른 라이브니스 위험 코드는 존재하지 않습니다.

자동 거부 조건

다음 위험은 항상 log_type: "error"와 함께 라이브니스 보고서(및 세션)를 Declined 상태로 강제 변경합니다. NO_FACE_DETECTED가 발생하면 LOW_LIVENESS_SCORE는 생략됩니다(점수를 산정할 얼굴이 없기 때문입니다).

구성 가능한 인증 설정

Didit 콘솔에서 라이브니스 위험은 다음과 같은 워크플로 설정으로 그룹화됩니다.

생성되는 경고

핵심 라이브니스

캡처 채널 무결성

캡처 시 클라이언트에서 보고하는 인젝션 공격 신호입니다. 프레젠테이션 공격(실제 카메라 앞에 인공물을 가져다 대는 행위)과 달리, 카메라 피드 자체가 대체되거나 가로채이는 상황을 나타냅니다. 각 항목은 워크플로별로 설정할 수 있으며 기본값은 작업 없음이므로, 직접 활성화하기 전까지는 이 기능을 켜도 결정이 변경되지 않습니다.
브라우저는 어떤 벤더에게도 OS 수준의 카메라 소스 증명을 제공하지 않으므로, 웹에서 이러한 신호는 직접적인 증거라기보다는 뒷받침하는 정황 증거입니다. 웹에서 null 판정은 판정 불가(카메라 권한이 부여될 때까지 기기 라벨을 사용할 수 없음)를 의미하며 절대 위험을 발생시키지 않습니다.
가상 카메라는 기기 이름으로 식별되므로, 운영체제에서 일반적인 이름으로 표시하는 카메라는 이러한 방식으로 인식되지 않습니다. Android 에뮬레이터 내부에서는 재매핑된 카메라가 일반 내장 카메라처럼 라벨링되므로, 에뮬레이트된 하드웨어 케이스는 대신 FRAME_INJECTION_SUSPECTED를 통해 보고됩니다. 즉, 카메라 이름이 아니라 기기 환경(렌더링 스택 및 사용자 에이전트에 보고된 기기 모델)을 통해 감지됩니다. 기기 환경에서 발생한 탐지 결과에는 additional_data.reason: "emulated_capture_device"가 포함되어 라이브니스 모델 자체의 프레임 분석과 구별됩니다.
브라우저를 통해 머신을 감지하는 것은 정황 증거일 뿐 공식적인 증명이 아니며, 작정한 공격자라면 이를 방해할 수 있습니다. 네이티브 모바일 SDK는 브라우저에서는 볼 수 없는 더 강력한 운영체제 수준의 무결성 신호(에뮬레이터, 루팅 또는 탈옥 기기, 런타임 후킹, 연결된 디버거)를 보고하며, 각각 기기 및 런타임 무결성에서 자체적으로 구성 가능한 작업이 있습니다. 이러한 신호는 공격자의 비용을 상당히 증가시키지만, 단독으로는 캡처가 실제 기기에서 생성되었음을 증명하지 못합니다. 기기 무결성 신호는 라이브니스 방식과 무관하므로 Passive, 3D Flash 또는 3D Action & Flash 중 어느 방식과도 함께 사용할 수 있습니다.

녹화본 이상 여부 포렌식

LIVENESS_VIDEO_ANOMALY는 라이브니스 모델과 독립적으로 저장된 라이브니스 녹화본에 대해 서버 측에서 계산됩니다. 루프 피드와 일치하는 여러 주기에 걸쳐 반복되는 움직임 시퀀스를 감지합니다. 라이브니스 또는 연령 추정 노드에서 작업을 설정하십시오. NO_ACTION은 정보 탐지 결과를 기록하고, REVIEW는 이미 결정된 인증의 상태를 검토 중으로 격상할 수 있으며, DECLINE은 거부됨으로 격상할 수 있습니다. 검사는 비동기식으로 실행되므로 초기 결과가 전달된 후에 상태가 격상될 수 있습니다. 기존의 더 심각한 결정은 하향 조정되지 않으며, 수동 검토 결정은 유지됩니다. 버전 2 탐지 결과에는 forensics_version: 2, repeated_sequence 증거 및 anomaly_reasons의 repeated_moving_sequence가 포함됩니다. unique_frame_ratio, static_pair_ratio, decoded_fps_ratio, max_frame_gap_seconds와 같은 전송 측정값은 진단용으로 유지되며, 단독으로 재생 공격을 입증할 수는 없습니다. 이전 탐지 결과는 당시 사용된 탐지기 버전을 나타내며 소급하여 재분류되지 않습니다.
이것은 보수적인 추가 신호이며, 합성 미디어 또는 인젝션된 동영상에 대한 완벽한 탐지는 아닙니다. 이상 징후가 없는 녹화본이라고 해서 라이브니스를 증명하는 것은 아닙니다. 짧거나 모호한 캡처 및 유효한 재생 증거가 없는 캡처는 이 검사에서 플래그가 지정되지 않습니다. 누락되었거나 읽을 수 없는 녹화본은 이 검사에서 탐지 결과를 생성하지 않으며, 다른 인증 검사는 여전히 적용됩니다.

세션 간 얼굴 대조

가져온 얼굴 또는 목록 항목 얼굴(세션이 없음)과의 일치 항목에 대해 additional_data의 *_session_id, *_session_number, api_service 값은 null입니다. 동일한 사용자(동일한 vendor_data 또는 사용 가능한 경우 동일한 벤더 사용자)에 속한 얼굴은 중복 감지 및 차단 목록 스크리닝을 포함한 전체 인덱스 검색에서 제외됩니다. 일치 우선순위는 다음과 같습니다: 차단 목록 정확 일치 → 허용 목록 정확 일치 → 중복 정확 일치 → 차단 목록 가능성 → 허용 목록 가능성 → 중복 가능성. 상호 배타적인 이 6개 코드 중 보고서당 하나만 표시됩니다. DUPLICATED_FACE_NAME_MISMATCH는 이 우선순위 그룹에 속하지 않습니다. 이는 신원 확인도 실패했을 때 기존 코드를 대체하는 것이 아니라 DUPLICATED_FACE에 추가되어 생성되는 코드입니다. additional_data.name_match_score에는 비교 대상 성명이 포함되지 않으며 ID와 점수만 포함되므로 경고 payload에 PII가 유입되지 않습니다. 각 문서에 서로 다른 문자 체계로 작성된 성명(예: 한 문서에는 히브리어, 다른 문서에는 라틴 문자)은 두 세션이 동일인에게 속한 경우에도 임계값 미만의 점수를 받을 수 있습니다. 이러한 특수한 경우, 두 세션의 신분증 문서가 다음 항목 모두에서 서로 일치하면 DUPLICATED_FACE_NAME_MISMATCH가 발생하지 않습니다:
  • 두 문서의 발급 국가가 동일합니다.
  • 두 문서 간에 식별자가 정확히 일치합니다. 문서 유형에 따라 동일한 국민 식별 번호가 두 필드 중 하나에 위치할 수 있으므로 document_number와 personal_number는 상호 호환되어 인정됩니다.
  • 두 문서 모두에 생년월일이 기재되어 있는 경우 동일한 날짜여야 합니다.
성명이 동일한 문자 체계로 작성되었거나, 식별자 또는 발급 국가가 다르거나 누락된 경우, 또는 생년월일이 서로 일치하지 않는 경우에는 위에서 설명한 대로 경고가 계속 발생합니다.

패시브 라이브니스 품질(method = "PASSIVE"인 경우에만 해당)

LOW_FACE_LUMINANCE와 HIGH_FACE_LUMINANCE는 상호 배타적입니다. 조도는 최소값 미만이거나 최대값 초과 중 하나이며, 둘 다 해당할 수는 없습니다.

연령 추정(어댑티브 워크플로 및 AGE_ESTIMATION 노드)

정확한 설명 문자열

API는 각 위험에 대해 다음과 같은 정확한 short_description 및 long_description 문자열을 반환합니다.

독립형 패시브 라이브니스 API

독립형 Liveness API는 몇 가지 동작상의 차이점을 제외하고 동일한 위험 코드를 재사용합니다.
  • NO_FACE_DETECTED와 LOW_LIVENESS_SCORE는 상호 배타적입니다. 점수 확인은 얼굴이 발견된 경우에만 실행됩니다. LOW_LIVENESS_SCORE는 요청의 face_liveness_score_decline_threshold(기본값 30)를 기준으로 발생하며 항상 log_type: "error"를 전달합니다.
  • POSSIBLE_FACE_IN_BLOCKLIST는 검토 대신 거부(log_type: "error")로 처리됩니다.
  • MULTIPLE_FACES_DETECTED는 log_type: "warning"을 전달하는 반면, 중복 얼굴 위험은 정보 제공 수준으로 유지됩니다. error 수준의 경고만 독립형 응답의 status를 Declined로 전환합니다.
  • 독립형 경고 항목에는 feature가 포함되지만 node_id는 포함되지 않습니다.

예시

공격 감지 시 자동 거부

패시브 캡처 시 설정 가능한 경고

payload를 포함한 중복 얼굴

여기서는 중복 얼굴 작업이 Review로 설정되어 있으므로 경고에 log_type: "warning"이 포함되고 라이브니스 보고서의 상태는 In Review가 됩니다. 기본값(No action)으로 설정된 경우 대신 log_type: "information"이 포함됩니다. 일치하는 얼굴이 독립형 API 호출이 아닌 워크플로 세션에서 비롯되었으므로 api_service는 null입니다.

다른 이름의 중복 얼굴

DUPLICATED_FACE는 자체 구성된 작업(여기서는 No action — log_type: "information")을 유지하는 반면, DUPLICATED_FACE_NAME_MISMATCH는 기본값이 Review(log_type: "warning")인 자체 작업을 수행합니다. 일반 중복 얼굴 설정 자체만으로는 플래그가 지정되지 않았더라도, 라이브니스 보고서의 상태는 둘 중 더 심각한 수준을 따르므로 여기서는 In Review가 됩니다.

측정값이 포함된 녹화 무결성 이상

이 예시는 움직이는 시퀀스의 사본 3개가 포함된 녹화본의 재생 증거를 보여줍니다. 구성된 작업이 NO_ACTION이므로 log_type은 information입니다. 간결성을 위해 이 예시에서 생략된 프레임 전송 진단은 해당 탐지 결과를 유발하지 않습니다.

경고 유형

각 위험에는 애플리케이션 설정에 따라 심각도가 할당됩니다. 세 가지 심각도는 다음과 같습니다.

관련 문서

마지막 수정일 2026년 11월 7일