← 메인으로

🧠 전자금융 보안 모의해킹 · 메모리 내 중요정보 노출 방지

Target: 거래 처리 중 프로세스 메모리
평가기준: 위험도 4 MOB-SER 메모리 노출 방지
💡 쉽게 말하면
비밀번호를 화이트보드에 썼다가 지우지 않고 자리를 뜨면 누구나 읽습니다. 다 쓰면 즉시 깨끗이 지워야 사진(메모리 덤프)에 안 찍힙니다.
🔓 공격 시뮬레이션 (Red Team)
🛡️ 대응 방안 (Blue Team)
런타임 메모리 덤프🔒 Secured Channel
거래 처리 중 비밀번호·세션키를 String으로 두고 사용 후 비우지 않으면, 메모리에 평문 잔존하여 Frida·gdb 덤프로 그대로 추출됩니다.
⚡ Frida 메모리 덤프
런타임 프로세스 메모리에서 평문 비밀번호 스캔
OFF
🖥️ 금융 시스템 처리 로그
[SYSTEM] Core Banking Channel ready.
[INFO] 거래 요청 대기 중...
⚖️ 컴플라이언스 위반 분석
공격 실행 후 분석 결과가 표시됩니다.
[심각] 전자금융 보안 기준 위반 감지
  • 평가기준 [전자금융] 메모리 내 중요정보 노출(위험도 4) 위반
  • 전자금융감독규정 제37조의2 단말기 정보보호 미흡
  • 개인정보보호법 제29조 안전성 확보조치 위반
🛡️ 대응 코드/설정 실습

비밀번호·세션키는 불변 String 대신 char[]로 다루고, 사용 직후 fill()로 즉시 덮어써 메모리 잔존을 제거해야 합니다. 아래 코드를 보완하세요.

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

1. 점검 항목

모바일 단말 보호 > 메모리 내 중요정보 노출 방지

2. 위험 분석

  • 불변 String은 GC 전까지 평문 잔존
  • Frida·gdb 메모리 덤프로 비밀번호·세션키 추출

3. 조치 방법

  • 중요정보를 char[]로 처리
  • 사용 직후 Arrays.fill()로 소거
  • 가능 시 보안 키 저장소 활용
🏗️ 현대 금융 IT 환경에서의 변형
Keystore/EnclaveGC 언어 한계TEE

어디가 달라졌나

Java·Kotlin·Swift 같은 GC 언어에서는 메모리를 확실히 지울 수 없습니다. String 은 불변이고 GC 가 언제 회수할지 모릅니다. 그래서 “사용 후 즉시 삭제”라는 조치는 구현 가능한 범위를 정확히 알고 접근해야 합니다.

현대 스택에서의 조치

  • 비밀값은 char[]·ByteArray 로 다루고 사용 후 명시적으로 0 으로 채웁니다. String 은 피합니다.
  • 가장 좋은 방법은 평문을 앱 메모리에 올리지 않는 것입니다 — Android Keystore / iOS Secure Enclave 안에서 서명·복호화를 수행하고 결과만 받습니다. 키는 하드웨어 밖으로 나오지 않습니다.
  • 생체인증 연동 시 setUserAuthenticationRequired(true) 로 키 사용 자체를 인증에 묶습니다.
// 키가 앱 메모리에 존재하지 않는 구조
KeyGenParameterSpec spec = new KeyGenParameterSpec.Builder("txn-sign",
        KeyProperties.PURPOSE_SIGN)
    .setUserAuthenticationRequired(true)       // 생체인증 후에만 사용
    .setIsStrongBoxBacked(true)                // 하드웨어 보안 모듈
    .build();
놓치기 쉬운 곳 — 크래시 덤프와 힙 스냅샷에 비밀값이 그대로 담깁니다. Firebase Crashlytics 같은 도구가 덤프를 외부로 보내므로, 수집 범위를 확인해야 합니다.