들어가며
최근 SKT의 해킹 사건으로 유심에 대해 관심이 생겨서 찾아보았습니다.
유심(USIM)은 단순한 칩이 아니다
대부분의 사람들은 유심을 단순히 전화번호 저장용 칩 정도로 생각하지만, 실제로는 통신망 인증, 암호화, 위치 정보, 인증 수단 등 다방면에 관여하는 보안 디바이스입니다.
유심에는 뭐가 들어있지?
유심 내부에는 가입자 정보를 인증하고 통신을 가능하게 하는 핵심 데이터가 저장돼 있습니다.
- IMSI (국제 이동 가입자 식별번호): 가입자를 식별하는 고유 번호. (유저 ID 역할)
- Ki (개인 인증키): 이동통신사만 알고 있는 비밀 키로, IMSI와 함께 기지국에서 인증에 사용됨.
- 전화번호, 통신사 정보
- SMS/MMS 설정 정보, 일부 주소록
- eSIM은 동일한 개념을 칩 내장형 소프트웨어 형태로 구현한 것.
이 정보들은 통신사 인증뿐 아니라, 위치 추적, 통화 기록 추적, 2단계 인증까지도 가능하게 만듭니다.
유심의 인증 흐름 – 우리가 ‘정상 사용자’임을 증명하는 절차
스마트폰을 켜면 즉시 통신이 가능해지는 듯 보이지만, 실제로는 아주 정교한 인증 절차가 뒤에서 작동합니다. 이것이 바로 AKA(Authentication and Key Agreement) 프로토콜입니다.
유심 인증 흐름
- IMSI 전송
스마트폰은 유심에 저장된 IMSI를 기지국에 전송함
→ 이 단계는 암호화되지 않아 노출될 수 있음 - RAND + AUTN 생성 (도전값 + 인증값)
통신사는 해당 사용자의 Ki를 이용해
- 무작위 난수(RAND)
- 인증 토큰(AUTN)을 생성하여 사용자에게 전송함 - USIM 검증
유심은 자신의 Ki로 이 AUTN이 유효한지 검증
→ 인증 실패 시 통신 차단됨 - RES 생성 및 전송
유심은 자신만의 계산 방식으로 응답값(RES)을 생성하고 통신사에 보냄 - 통신사 검증
통신사가 예상한 RES와 비교 → 일치하면 정상 인증 - 세션 키 생성
이후 암호화된 통화/데이터 전송을 위한 키가 자동 생성됨
이 과정은 eSIM에서도 동일하게 적용되며, 다만 물리적 칩이 아닌 디지털 프로파일 형태로 저장되어 작동합니다.
이 흐름이 보안에 중요한 이유
- Ki는 절대 유출되지 않음
- 매번 다른 난수(RAND) 사용 → 재전송 방지
- 상호 인증(Mutual Authentication) → 사용자도 통신사도 서로 신원 검증
- 세션 키 기반의 데이터 암호화 → 도청 방지
이제 해커가 할 수 있는 일
유심이 뚫리거나 스와핑되면 해커는 다음을 할 수 있습니다.
- 내 전화번호로 인증 문자 수신 → SNS, 은행, 이메일 계정 탈취
- 실시간 위치 추적
- 통화 감청, SMS 복호화
- 스마트폰 백그라운드 조작 (특수 케이스에서 가능)
그래서 지금 당장 우리가 할 수 있는 추가적인 보안 조치
- 유심 PIN 설정: 유심 자체에 비밀번호를 설정하여 보안 강화
- 2단계 인증 강화: 주요 서비스(네이버, 카카오, 금융앱 등)에 2단계 인증 설정
- 수상한 문자/통화 차단: 알 수 없는 발신번호의 전화나 문자 무시, 이상 징후 발생 시 SKT 고객센터에 신고
- 명의도용방지 서비스 가입: PASS 앱에서 명의도용방지 서비스 가입으로 무단 번호 개통 차단
- 개인 정보 보호: SNS에 개인 정보 최소화, 피싱 주의
- 통신 서비스 중단 주의: 갑자기 통화나 데이터 서비스가 중단되면 즉시 통신사에 연락
- eSIM 고려: 물리적 탈취가 어려운 eSIM 사용 고려
유심 인증 흐름은 우리가 잘 아는 인증 로직과 닮아 있다?
이 글을 작성하며 유심 인증 구조를 처음 알게 되었는데 꽤 복잡하게 느껴지다가 이 흐름이 어디서 많이 본 구조라는 느낌을 받았습니다.
바로 웹 인증 로직(로그인, 토큰 인증 등)과 유사한 점이 많았습니다.
사실 유심의 AKA 인증 프로토콜도 결국 "도전값 → 응답값 검증 → 세션 키 생성"이라는 전형적인 인증 패턴을 따릅니다. 이 구조는 OAuth, JWT, HMAC 기반 인증 방식과 같은 웹 보안 모델과 거의 동일한 로직을 공유합니다.
개념 | 유심 인증구조 | 웹 인증구조 |
클라이언트 | 스마트폰 + 유심 | 브라우저 + 클라이언트 앱 |
서버 | 통신사 인증 서버 (HLR/HSS) | 백엔드 서버 (Auth API) |
사용자 식별 정보 | IMSI (국제 가입자 식별자) | ID (email/username) |
비밀 키 | Ki (유심에만 존재) | 비밀번호/비밀키 or JWT Secret |
랜덤 도전 값 | RAND | nonce or CSRF token |
응답값 | RES | HMAC, JWT, signed token |
세션키 생성 | 통신사 ↔ 유심 암호화 키 공유 | JWT/세션토큰 기반 통신 유지 |
구조적 유사성의 핵심 포인트
- Challenge-Response 방식:
둘 다 ‘정적인 정보(ID)’만으로는 인증이 되지 않고, ‘서버가 생성한 랜덤 값(RAND, nonce)’에 대한 응답값(RES, HMAC 등)이 정확해야 인증됨. - 양방향 신뢰 기반:
USIM은 서버(AUTN)를 검증하고, 서버는 클라이언트(RES)를 검증한다.
→ 이것은 OAuth2에서 access_token + refresh_token 검증 또는 Mutual TLS와도 유사함. - 비밀 키는 유출되지 않음:
Ki는 절대 유출되지 않고, 유심 내에서만 연산에 사용됨.
→ 이것은클라이언트가 서명만 보내고, 비밀번호는 서버에 저장하지 않는 구조
와 같다.
"Ki는 유심 안에만 존재하는 클라이언트 사이드의 비밀 서명 키다. IMSI는 클라이언트 ID고, RAND는 서버가 주는 nonce다. RES는 HMAC-SHA256(RAND, Ki) 같은 응답 서명값이고, 통신사는 백엔드에서 이걸 검증한다. 그 결과로 연결 세션이 열리는 거지."
마치며
모두 피해없이 이번 사건이 잘 마무리 되었으면 좋겠습니다.