라이브니스 검출과 인도네시아 디지털 신원: 사기 방지를 위한 기술적 접근법
Engineering Team
라이브니스 검출이란 무엇이며 인도네시아에 왜 필요한가?
라이브니스 검출은 생체인식 샘플(예: 안면 이미지)이 인쇄 사진, 화면 재생, 실리콘 마스크, 딥페이크 동영상과 같은 위조 수단이 아닌 실제 살아있는 사람으로부터 취득된 것인지를 판별하는 기술입니다. 인도네시아 KOMDIGI 2026년 규정 제7호의 맥락에서, 라이브니스 검출은 모든 생체인식 SIM 카드 인증 시스템의 필수 구성 요소입니다.
그 위험은 막대합니다. **국가사이버암호청(BSSN)**의 데이터에 따르면, 인도네시아는 2025년 사이버 범죄로 약 **7조 루피아(4억 700만 달러)**의 손실을 입었습니다. SIM 스왑 사기만으로도 **1.2조 루피아(7,000만 달러)**의 피해가 발생했습니다. 견고한 라이브니스 검출 없이는 생체인식 인증 시스템은 보안 쇼에 불과합니다 — 공격자가 피해자의 고해상도 사진이나 동영상을 제시하여 안면 인식 검사를 통과할 수 있습니다.
위협 환경: 프레젠테이션 공격
안면 인식 시스템에 대한 프레젠테이션 공격(스푸핑 공격이라고도 함)은 여러 범주로 분류되며, 각각 다른 검출 전략이 필요합니다:
레벨 1: 인쇄 공격
가장 단순한 공격은 대상의 인쇄 사진을 사용합니다. 라이브니스 검출이 없는 기본적인 안면 인식 시스템에 놀라울 정도로 효과적입니다. 공격자는 광택 용지에 고해상도 사진을 인쇄하여 카메라 앞에 들이댑니다.
검출 방법:
- 텍스처 분석(인쇄 패턴, 무아레 효과 검출)
- 에지 검출(종이 가장자리가 프레임 내에 보임)
- 반사 분석(종이는 피부와 다르게 빛을 반사)
- 모션 분석(2D 표면의 움직임 패턴은 3D 얼굴과 다름)
레벨 2: 화면 재생 공격
공격자가 스마트폰, 태블릿 또는 노트북 화면에 대상의 동영상을 표시합니다. 눈 깜빡임이나 머리 움직임과 같은 얼굴 동작을 시뮬레이션할 수 있어 인쇄 공격보다 더 정교합니다.
검출 방법:
- 화면 검출(픽셀 그리드 패턴, 화면 베젤 식별)
- 무아레 패턴 분석(화면에 표시된 픽셀이 간섭 패턴 생성)
- 플래시 반사 테스트(디바이스 플래시를 사용하여 화면 반사의 균일성 검출)
- 옵티컬 플로우 분석(화면의 동영상은 다른 광학적 특성을 가짐)
레벨 3: 3D 마스크 공격
가장 정교한 공격은 대상의 얼굴을 복제한 3D 프린트 또는 실리콘 마스크를 사용합니다. 이 마스크에는 사실적인 피부 질감, 눈 구멍, 입 개구부가 포함될 수 있습니다.
검출 방법:
- 깊이 센싱(구조광 또는 ToF 센서로 평탄한 영역 검출)
- 피부 스펙트럼 분석(실제 피부는 근적외선 스펙트럼에서 고유한 반사 특성을 가짐)
- 미세 동작 분석(미세 표정과 맥박으로 인한 미세 피부 움직임은 마스크에 존재하지 않음)
- 온도 검출(열화상 카메라 필요 — 마스크는 얼굴과 다른 온도를 나타냄)
레벨 4: 딥페이크와 디지털 인젝션
가장 첨단의 공격은 AI 생성 딥페이크 동영상을 사용하거나 합성 프레임을 카메라 파이프라인에 직접 인젝션합니다. 공격자는 카메라 드라이버를 하이재킹하거나 가상 카메라 소프트웨어를 사용할 수 있습니다.
검출 방법:
- 디바이스 무결성 검사(카메라 하드웨어가 변조되지 않았는지 확인)
- 인젝션 검출(가상 카메라 드라이버나 프레임 인젝션 검출)
- GAN 아티팩트 분석(딥페이크는 보통 에지, 머리카락, 치아에 아티팩트가 있음)
- 챌린지-리스폰스 테스트(사용자에게 랜덤 동작 시퀀스 수행 요구 — 실시간 딥페이크는 정확한 재현이 어려움)
ISO/IEC 30107-3: 프레젠테이션 공격 검출 표준
ISO/IEC 30107-3은 생체인식 시스템의 프레젠테이션 공격 검출(PAD) 능력을 평가하는 국제 표준입니다. KOMDIGI 규정은 모든 생체인식 SDK 제공업체에게 레벨 2 이상의 PAD 테스트 통과를 요구합니다.
이 표준은 두 가지 핵심 지표를 정의합니다:
- APCER(공격 프레젠테이션 분류 오류율): 공격이 잘못 수락되는 비율
- BPCER(정상 프레젠테이션 분류 오류율): 실제 사용자가 잘못 거부되는 비율
| PAD 레벨 | APCER 요구 사항 | 공격 유형 |
|---|---|---|
| 레벨 1 | ≤ 5% | 인쇄 사진, 화면 재생 |
| 레벨 2 | ≤ 2.5% | 레벨 1 + 종이 마스크, 2D 곡면 공격 |
| 레벨 3 | ≤ 1% | 레벨 2 + 3D 마스크, 부분 공격 |
인도네시아 SIM 인증에서는 레벨 2 준수가 최소 요구 사항입니다. 금융 서비스(OJK 규제 하)에서는 더 높은 보안 수준을 위해 레벨 3 준수가 필요할 수 있습니다.
라이브니스 검출 기술 아키텍처
패시브 라이브니스 검출 vs 액티브 라이브니스 검출
라이브니스 검출의 두 가지 주요 접근 방식에는 각각 장단점이 있습니다:
패시브 라이브니스 검출은 사용자 인지 없이 단일 이미지 또는 짧은 동영상을 분석하여 진위를 판별합니다. 사용자 경험은 매끄럽습니다 — 카메라를 보기만 하면 됩니다.
- 장점: 우수한 UX, 빠른 속도, 접근성
- 단점: 고급 공격에 대한 저항력이 약함
액티브 라이브니스 검출은 실제 사람임을 증명하기 위해 특정 동작(고개 돌리기, 눈 깜빡이기, 미소 짓기 등)의 수행을 사용자에게 요구합니다.
- 장점: 위조 공격에 대한 저항력이 더 강함
- 단점: UX가 떨어짐, 장애인에게 접근 제한 가능, 소요 시간이 더 김
권장 하이브리드 접근법
인도네시아의 SIM 인증 시나리오에서는 두 기술의 장점을 결합한 하이브리드 접근법을 권장합니다:
- 초기 패시브 검사: 캡처 시 패시브 라이브니스 검출 실행(<500ms)
- 리스크 스코어링: 패시브 검출의 신뢰도가 임계값 미만(예: <0.85)이면 액티브 챌린지 트리거
- 액티브 챌린지: 사용자에게 간단한 랜덤 동작 수행 요구(예: 왼쪽으로 고개 돌리기)
- 최종 판정: 패시브와 액티브 점수를 결합하여 최종 결정
Rust에서의 라이브니스 검출 파이프라인
use serde::{Deserialize, Serialize};
#[derive(Debug, Serialize, Deserialize)]
pub struct LivenessResult {
pub is_live: bool,
pub confidence: f64,
pub method: LivenessMethod,
pub attack_scores: AttackScores,
}
#[derive(Debug, Serialize, Deserialize)]
pub enum LivenessMethod {
Passive,
Active,
Hybrid,
}
#[derive(Debug, Serialize, Deserialize)]
pub struct AttackScores {
pub print_attack: f64,
pub screen_replay: f64,
pub mask_3d: f64,
pub deepfake: f64,
}
pub struct LivenessDetector {
passive_model: OnnxModel,
active_model: OnnxModel,
threshold_passive: f64,
threshold_active: f64,
}
impl LivenessDetector {
pub async fn check_passive(
&self,
frame: &CaptureFrame,
) -> Result<LivenessResult, LivenessError> {
let features = self.passive_model
.extract_features(&frame.image_data)?;
let scores = AttackScores {
print_attack: features[0] as f64,
screen_replay: features[1] as f64,
mask_3d: features[2] as f64,
deepfake: features[3] as f64,
};
let max_attack = scores.print_attack
.max(scores.screen_replay)
.max(scores.mask_3d)
.max(scores.deepfake);
Ok(LivenessResult {
is_live: max_attack < self.threshold_passive,
confidence: 1.0 - max_attack,
method: LivenessMethod::Passive,
attack_scores: scores,
})
}
pub async fn check_hybrid(
&self,
frames: &[CaptureFrame],
challenge: &Challenge,
) -> Result<LivenessResult, LivenessError> {
// 1. 먼저 패시브 검사
let passive = self.check_passive(&frames[0]).await?;
if passive.confidence >= 0.95 {
return Ok(passive);
}
// 2. 패시브 점수가 부족하면 액티브 검사
let active_features = self.active_model
.analyze_sequence(frames, challenge)?;
let combined_confidence =
passive.confidence * 0.4 + active_features.confidence * 0.6;
Ok(LivenessResult {
is_live: combined_confidence >= self.threshold_active,
confidence: combined_confidence,
method: LivenessMethod::Hybrid,
attack_scores: passive.attack_scores,
})
}
}
모델 배포와 최적화
인도네시아에서의 라이브니스 검출 배포에는 여러 실제적인 요소를 고려해야 합니다:
디바이스 다양성
인도네시아는 매우 다양한 스마트폰 생태계를 보유하고 있습니다. 3억 4,500만 장의 활성 SIM 카드 중 상당수가 저가형에서 중가형 Android 폰입니다. 라이브니스 검출 솔루션은 다음 디바이스에서 안정적으로 작동해야 합니다:
- 저가형: 2GB RAM, 쿼드코어 프로세서, VGA 전면 카메라
- 중가형: 4-6GB RAM, 옥타코어 프로세서, 8MP 전면 카메라
- 고가형: 8GB+ RAM, 플래그십 프로세서, 깊이 센싱 지원 전면 카메라
모델 크기와 추론 시간
| 배포 방식 | 모델 크기 | 추론 시간 | 정확도 |
|---|---|---|---|
| 기기 내(TensorFlow Lite) | 5-15 MB | 50-200ms | 92-96% |
| 기기 내(ONNX Runtime) | 10-25 MB | 30-150ms | 93-97% |
| 서버 측(TensorRT) | 50-200 MB | 10-50ms | 97-99% |
| 하이브리드 | 10 MB(기기 내) + 100 MB(서버 측) | 합계 100-250ms | 96-99% |
네트워크 조건
인도네시아의 네트워크 조건은 크게 다릅니다. 자카르타와 수라바야 같은 주요 도시에서는 4G 커버리지가 양호하며 평균 레이턴시는 30-50밀리초입니다. 그러나 농촌 지역에서는 3G 또는 2G로, 레이턴시는 200-500밀리초, 패킷 손실률은 5-10%에 달할 수 있습니다.
라이브니스 검출 아키텍처는 이러한 조건에 우아하게 대응해야 합니다:
- 네트워크 의존성을 줄이기 위해 기기 내에서 초기 라이브니스 검사 수행
- 전송 크기를 최소화하기 위해 생체인식 템플릿 압축(목표 <50KB)
- 지수 백오프를 포함한 재시도 로직 구현
- 네트워크 없는 시나리오를 위한 오프라인 큐잉 메커니즘 제공
자주 묻는 질문
라이브니스 검출을 우회할 수 있습니까?
완벽한 라이브니스 검출 시스템은 존재하지 않습니다. 가장 첨단의 공격(특히 레벨 4 디지털 인젝션 공격)은 현재 기술을 우회할 수 있습니다. 이것이 다층적 접근이 필수적인 이유입니다 — 패시브 검출, 액티브 챌린지, 디바이스 무결성 검사, 행동 분석을 결합합니다. 보안 목표는 100% 방어가 아니라 공격 비용을 충분히 높여 대다수 공격자를 억제하는 것입니다.
라이브니스 검출 시스템의 정확도는?
현대 라이브니스 검출 시스템은 표준 조건에서 97-99%의 정확도를 달성할 수 있습니다. 그러나 정확도는 조명 조건, 카메라 품질, 사용자 협조도에 영향을 받습니다. KOMDIGI 규정은 최소 95%의 정확도를 요구하며, 5%의 오거부율(FRR) 여유를 두고 있습니다.
라이브니스 검출 SDK 선택 방법은?
SDK 선택 시 다음을 고려하세요: KOMDIGI 인증 상태, ISO/IEC 30107-3 준수 레벨, 디바이스 호환성 범위, 오프라인 기능, SDK 크기가 앱 용량에 미치는 영향, 가격 모델, 기술 지원 품질. 선택 전에 자체 데이터셋으로 후보 SDK의 벤치마크 테스트를 수행하는 것을 권장합니다.