← 메인으로

⌨️ 전자금융 보안 모의해킹 · 이용자 입력정보 보호 (키보드 보안)

Target: 거래 입력 폼(비밀번호 등)
평가기준: 위험도 4 WEB-FIN 입력정보 보호
💡 쉽게 말하면
비밀번호를 누를 때 누군가 어깨너머로 키보드를 그대로 베껴 적는 상황입니다. 화면에 뒤죽박죽 섞인 보안 키패드로 누르고 곧바로 암호로 잠가야 베껴도 소용이 없습니다.
🔓 공격 시뮬레이션 (Red Team)
🛡️ 대응 방안 (Blue Team)
거래 비밀번호 입력🔒 Secured Channel
거래 입력값(계좌 비밀번호·OTP 등)이 키보드 보안(보안 키패드)·종단 암호화 없이 평문으로 처리되면, 단말에 설치된 키로깅/메모리 후킹 악성코드가 입력 즉시 평문을 탈취할 수 있습니다.
⚡ 키로깅 + 메모리 후킹
평문 입력값을 입력 시점/메모리에서 탈취
OFF
🖥️ 금융 시스템 처리 로그
[SYSTEM] Core Banking Channel ready.
[INFO] 거래 요청 대기 중...
⚖️ 컴플라이언스 위반 분석
공격 실행 후 분석 결과가 표시됩니다.
[심각] 전자금융 보안 기준 위반 감지
  • 평가기준 WEB-FIN [전자금융] 이용자 입력정보 보호(위험도 4)
  • 키보드 보안·종단 암호화 미적용으로 입력정보 노출
  • 전자금융감독규정 제34조: 이용자 정보 보호대책 미흡
🛡️ 대응 코드/설정 실습

클라이언트는 보안 키패드로 입력을 받고, 입력 즉시 종단 암호화(E2E)하여 평문이 메모리/전송 구간에 노출되지 않도록 해야 합니다. 아래 코드를 보완하세요.

📚 금융보안원 평가기준 / 조치 가이드

1. 점검 항목

이용자 정보 보호 > 입력정보 보호(키보드 보안)

2. 위험 분석

  • 키로깅으로 키 입력 평문 탈취
  • 메모리 후킹으로 폼 내 평문 추출

3. 조치 방법

  • 보안 키패드(가상·난수 배열) 적용
  • 입력 즉시 종단 암호화(E2E) 후 처리
  • 평문 메모리 버퍼 즉시 제거
🏗️ 현대 금융 IT 환경에서의 변형
OS 보안 키보드접근성 오용한국 특수성

어디가 달라졌나

국내 금융앱의 자체 보안 키보드는 글로벌 관행과 다른 한국 특유의 통제입니다. 현재 Android·iOS 는 OS 차원에서 비밀번호 입력 시 서드파티 키보드를 차단하는 수단을 제공하므로, 자체 구현의 상대적 이점이 줄었고 접근성·사용성 문제가 부각되고 있습니다.

현대 스택에서의 조치

  • Android android:inputType="textPassword" + imeOptions="flagNoPersonalizedLearning", iOS isSecureTextEntry 로 OS 보호를 먼저 받습니다.
  • 실제 위협은 키로깅보다 접근성 서비스 오용입니다 — 악성 앱이 접근성 권한으로 화면을 읽고 입력을 대신합니다. 비정상 접근성 서비스 탐지가 더 실효적입니다.
  • 궁극적으로는 생체인증·패스키로 입력 자체를 없애는 방향입니다.
놓치기 쉬운 곳 — 자체 보안 키보드는 스크린리더 사용자를 배제하는 경우가 많습니다. 장애인차별금지법상 접근성 의무와 충돌할 수 있으므로, 대체 입력 수단을 함께 제공해야 합니다.