.svg)
AI 솔루션 문의하기
딥페이크 얼굴인증 우회 공격을 점검할 때는 가짜 얼굴 영상의 품질뿐 아니라 그 영상이 인증 시스템에 들어오는 경로를 구분해야 합니다. 카메라 앞에 사진이나 재생 영상을 보여주는 공격과, 가상 카메라로 촬영 영상을 대체하는 공격은 노리는 지점이 다릅니다. 전자는 주로 프레젠테이션 공격 탐지(PAD)가 담당하고, 후자는 입력 경로와 기기 상태를 별도로 확인해야 합니다.
프레젠테이션 공격(Presentation Attack)은 카메라나 생체 센서에 가짜 대상을 직접 제시하는 방식입니다. 예를 들어 타인의 얼굴 사진을 인쇄해 들이대거나, 다른 화면에 재생한 얼굴 영상 또는 마스크를 카메라에 보여주는 경우가 있습니다. 카메라는 실제로 어떤 대상을 촬영하지만, 그 대상이 계정 소유자 본인은 아닐 수 있습니다.
PAD는 이런 유형의 위조 시도를 탐지하도록 설계됩니다. 다만 탐지 성능은 공격물 종류와 촬영 조건, 평가 범위에 따라 달라지므로, 특정 인증을 획득했다는 사실만으로 모든 공격을 막는다고 해석해서는 안 됩니다.
디지털 인젝션 공격(Digital Injection Attack)은 카메라가 촬영한 데이터를 애플리케이션이나 서버로 보내는 과정에서 다른 이미지·영상으로 입력을 바꾸는 방식입니다. 대표적으로 가상 카메라가 미리 준비된 영상을 정상 카메라 입력처럼 전달하거나, 변조된 실행 환경에서 센서 입력값을 조작하는 시나리오를 생각할 수 있습니다.
중요한 점은 딥페이크 영상 자체가 곧 인젝션 공격은 아니라는 것입니다. 딥페이크를 화면에 띄워 실제 카메라로 촬영하면 프레젠테이션 공격이 될 수 있고, 같은 영상을 입력 경로에 직접 삽입하면 인젝션 공격에 해당할 수 있습니다. 콘텐츠의 위조 여부와 영상이 유입되는 경로를 서로 다른 기준으로 평가해야 합니다.
얼굴 합성 기술과 일반적인 우회 수법은 기존 딥페이크 얼굴인식 우회 공격 대응 글에서, 얼굴 영상의 실시간 분석 관점은 실시간 딥페이크 얼굴인증 공격 탐지 글에서 확인할 수 있습니다. 이 글은 두 주제와 구분해 인젝션 공격 방어 설계와 검수 항목에 집중합니다.
가상 카메라와 에뮬레이터는 모두 인젝션 공격에 악용될 수 있지만, 같은 방식으로 취급해서는 안 됩니다. 가상 카메라는 영상 입력 장치를 대체하는 데, 에뮬레이터는 모바일 기기와 센서가 작동하는 환경을 모사하는 데 초점이 있습니다. 두 환경 모두 정상적인 개발·접근성·화상회의 용도로 쓰일 수 있으므로, 존재 자체만으로 공격을 확정하지 않는 정책이 필요합니다.
가상 카메라는 파일 또는 소프트웨어에서 생성한 영상을 실제 카메라 스트림처럼 앱에 제공할 수 있습니다. 위험은 얼굴이 자연스럽게 보이는지보다 서버가 받은 영상이 신뢰할 수 있는 촬영 경로에서 나왔는지 확인하기 어렵다는 데 있습니다. 라이브니스 검사를 통과한 것처럼 보이는 영상이라도 입력 경로까지 정상이라는 뜻은 아닙니다.
서비스 개발자는 앱이 허용하는 카메라 입력 방식을 파악하고, 지원하지 않는 영상 소스나 캡처 경로의 이상 신호를 어떻게 처리할지 정해야 합니다. 정상적인 외부 카메라 사용과 부정 입력을 구분하지 못한다면, 경고 후 재촬영 또는 별도 인증 경로를 제공하는 방식이 적절할 수 있습니다.
에뮬레이터는 모바일 운영체제와 카메라 등의 동작을 가상으로 구현합니다. 루팅·탈옥 등으로 보안 통제가 약화된 기기나 앱 후킹 환경에서도 영상과 기기 상태 정보의 신뢰도가 낮아질 수 있습니다. 따라서 단말기 종류 표시만 보는 것이 아니라 앱 실행 무결성, 센서 출처, 디버깅·변조 징후 등을 함께 평가하는 설계가 필요합니다.
단, 기기 무결성 점검은 인젝션의 모든 변형을 검출하지 못하고, 안전한 기기로 판정됐다는 사실도 촬영물의 진위를 보증하지 않습니다. 기기 검사 결과는 PAD 및 서버 검증과 함께 사용해야 합니다.
고객사가 자체 촬영 화면과 인증 API를 연동할 때는 업로드된 영상이 어느 사용자·어느 인증 요청·어느 시점의 것인지 서버가 확인할 수 있어야 합니다. 예컨대 과거에 정상적으로 촬영한 결과를 다른 요청에 다시 제출하는 경우를 구분하려면, 인증 요청별 식별자와 짧은 유효기간, 중복 제출 여부를 서버에서 점검하는 방식을 검토할 수 있습니다.
이 단계는 얼굴 분석 모델의 성능과 별개의 애플리케이션·서버 구현 책임입니다. 공격자가 영상 입력을 바꾸더라도 이전 세션의 인증 결과가 새 거래 승인에 그대로 쓰이지 않도록 경계를 설정해야 합니다
얼굴인증 인젝션 공격 방어는 한 가지 탐지 기술로 끝나지 않습니다. 어떤 방어 장치가 영상의 어떤 부분을 검증하는지 정리해야 중복 도입이나 검증 누락을 줄일 수 있습니다. 다음 세 단계는 서로 대체재가 아니라 보완 관계입니다.
PAD(Presentation Attack Detection)는 카메라 앞에 제시된 사진·영상·가면 등 공격물을 탐지하도록 설계된 기술입니다. 얼굴 매칭이 등록된 사람과 같은 얼굴인지 확인한다면, PAD는 촬영된 얼굴이 위조 수단으로 제시된 것은 아닌지 판단하는 역할을 맡습니다.
인젝션 탐지는 카메라에서 앱으로 전달된 영상이 중간에 치환되거나 조작된 징후가 있는지 확인하는 영역입니다. 가상 카메라 사용 여부, 입력 소스 변화, 캡처 경로의 비정상적인 특성 등을 위험 신호로 활용할 수 있습니다. 구현 기술과 탐지 범위는 제공사와 운영체제에 따라 다르므로 실제 지원 여부를 별도 확인해야 합니다.
기기 무결성은 루팅·탈옥, 변조 앱, 에뮬레이터 등 실행 환경의 위험을 평가하는 영역입니다. 서버는 이 결과를 PAD·인젝션 검사 결과와 조합하고, 인증 요청의 유효시간·재사용 여부·계정 위험도를 확인한 다음 승인 또는 보류를 결정할 수 있습니다.
카메라 입력 경로를 점검하는 체계를 설계하더라도, 카메라 앞에 실제 사람이 있는지 확인하는 PAD는 별도로 필요합니다. 알체라 eKYC의 얼굴 위변조 판별(PAD)과 얼굴 매칭을 연계하면 비대면 본인확인 과정에서 위조 얼굴 탐지와 동일인 확인을 담당하도록 구성할 수 있습니다. 알체라 공식 eKYC 페이지에는 RGB 기반 PAD의 iBeta 평가 통과 사실이 안내돼 있습니다.
다만 PAD 평가 통과가 가상 카메라·에뮬레이터 인젝션 방어까지 인증한다는 의미는 아닙니다. 인젝션 탐지와 기기 무결성, 서버의 인증 승인 정책은 고객사 환경에서 적용 범위와 연동 방법을 따로 확인해야 합니다.
인젝션 공격 체크리스트는 기능이 있는지를 묻는 데서 끝내지 않고 공격을 재현했을 때 어떤 결과가 나오는지 확인할 수 있도록 작성해야 합니다. 공급사 데모나 사내 보안성 검토에서 아래 질문을 그대로 사용할 수 있습니다.
특히 지원 기능의 이름과 실제 테스트 범위가 일치하는지 확인해야 합니다. '라이브니스 제공'만으로 가상 카메라까지 탐지한다고 판단하거나, '기기 위변조 탐지'만으로 모든 영상 주입을 막는다고 가정하면 검증하지 않은 경로가 남습니다.
인젝션 공격 방어 기능을 구매 요건에 넣었다면, 보안 담당자와 서비스 개발자가 실제 서비스와 유사한 환경에서 방어 동작과 실패 처리를 함께 확인해야 합니다. 기능 설명서의 지원 항목과 자사 운영체제·브라우저·인증 SDK 버전에서 확인된 결과가 다를 수 있기 때문입니다. 테스트는 허가된 검증 환경과 테스트 계정에서 진행하고, 정상 사용자가 의도치 않게 차단되는 경우도 기록합니다.
모든 실패를 동일한 오류 메시지와 자동 재시도로 처리하면 공격 의심 상황을 별도 관리하기 어렵습니다. 반대로 카메라 권한이 없거나 촬영 환경이 좋지 않은 정상 고객을 즉시 영구 차단하면 불필요한 이탈이 생길 수 있습니다. 따라서 촬영 품질 문제는 재촬영, 입력 경로·기기 무결성 의심은 인증 보류와 추가 확인, 반복된 비정상 시도는 횟수 제한과 담당자 검토 등으로 정책을 구분하는 편이 합리적입니다.
대체 인증을 제공하는 경우에도 공격자가 더 쉬운 경로로 우회하지 않도록 신원 확인 수준을 유지해야 합니다. 또한 각 인증 결과에는 어떤 검사에서 어떤 이유로 보류됐는지 기록해 재검토할 수 있어야 합니다. 원본 얼굴 영상이나 생체정보를 얼마나 보관할지는 업무상 필요성과 개인정보 처리 요건을 따로 검토해야 합니다.
얼굴인증 인젝션 공격 방어의 출발점은 가짜 얼굴을 탐지하는 기술과 가짜 영상이 들어오는 경로를 점검하는 기술을 구분하는 것입니다. 프레젠테이션 공격에는 PAD·라이브니스, 영상 입력 치환에는 인젝션 탐지, 변조된 실행 환경에는 기기 무결성 검증을 대응시켜야 합니다. 마지막으로 서버가 각 결과를 결합해 인증 승인·보류·재검증을 결정하도록 설계해야 합니다.
도입 검토에서는 공급사가 보유한 평가·인증 범위를 확인하고, 자사 앱·웹 환경에서 가상 카메라·에뮬레이터·세션 재사용 시나리오를 실제로 테스트하는 것이 좋습니다. 얼굴 분석 기능과 별개로 고객사가 책임질 촬영 경로 통제·서버 권한 정책·예외 처리·개인정보 관리 범위도 문서화해야 운영 중 혼선을 줄일 수 있습니다.
.png)
.svg)
.svg)
