SKT 사태로 회고해보는 보안, 개인정보 암호화

SKT 사용자로써, 종종 올라오는 SKT 관련 뉴스를 관심있게 보다가 흥미로운 부분이 있어 가져와봤다.

"기술이 뚫려도 제도가 막았어야"...유심 해킹 민낯

기술적 조치 수준에서도 통신 3사 간 격차가 존재한다. KT는 2021년부터 IMSI 암호화 기능이 적용된 5G USIM을 도입했고, LG유플러스는 PUF(물리적 복제 불가능 함수) 기반의 고보안 유심을 상용화했다. 반면 SK텔레콤은 이번 사고 시점까지 암호화 조치를 적용하지 않았고, 사건 이후에야 관련 체계 강화에 착수했다.

국제 표준도 이와 관련한 최소한의 보안을 요구하고 있다. 5G SA 환경에서는 가입자 식별정보(SUPI)를 암호화된 형태(SUCI)로 전송해야 한다는 규정이 3GPP TS 33.501 표준에 명시돼 있다. 이는 LTE 시절 IMSI가 평문으로 전송되던 보안 취약점을 개선하기 위한 조치다.

"기술이 뚫려도 제도가 막았어야"...유심 해킹 민낯 - [이슈진단+] 이용자 피해 방지가 기본값...CISO 내실화 제도개선 필요
최이담 기자 (입력 :2025/05/21 09:24 | 수정: 2025/05/22 12:46)

IMSI 암호화? 대칭키 암호화 알고리즘, 비대칭키 암호화 알고리즘 같은 암호화 방식인가? 아 근데 'IMSI가 평문으로...' 부분이 있는 것 보니 정보값인가 본데. 그걸 LTE 때는 암호화하지 않았다가 5G로 바뀌면서 암호화했다고?

SKT 보안체계, 'LTE→5G' 넘어왔나…IMSI 암호화의 진실 [IT클로즈업]

오... 정보도 암호화하지 않고 인증키도 암호화하지 않다니 거의 뭐 내 정보 가져가슈 같기는 한데, SKT의 변명이 웃기다. 보안이 권장사항이 아니라서 안했다니. '특정 보안절차가 있을 경우 문제의 소지가 있어 사용하지 않기를 권함' 같은 것도 아니고 암호화하라는 권장사항이 없어서 안했다는게 웬말이야...

...라고 생각했지만 사실 내가 과거에 이랬던 적이 있다. 정확하게는, 스프링 처음 배우고 프로젝트할 당시에 이런 부분을 전혀 생각하지 못했다. 배운 게 있으니 Spring Security로 당연히 기본적인 송수신 보안은 설정했지만, DB 저장에 있어서는 암호화할 생각도 못했다. 대학에서 기본적인 보안 수업은 들었지만, 송수신 과정에서의 탈취만 생각한 나머지 DB(혹은 DB와 서버 간 송수신 과정)에서 정보가 유출될 수 있다는 것을 예상하지 못한 것이다. 다행히 소셜 로그인을 기본으로 하는데다가 결제도 없고 실명이 불필요한 프로덕트여서 DB에 별다른 사용자 개인 정보는 기록되지 않았다. 연습 겸 배포하긴 했으나 사용자가 하나도 없으므로 걱정할 필요는 없겠다.

그 다음 프로젝트에서도 상황이 비슷했다. 마찬가지로 소셜 로그인을 기본으로 해서 비밀번호가 존재하지 않는데다, PG 서비스가 붙지도 않았고, 그 외의 민감할 수 있는 정보는 서비스 특성 상 저장할 이유가 없어서 송수신 외의 보안에는 신경쓰지 않았다. 소셜 로그인에서 카카오/애플을 통해 받는 사용자 정보가 있었는데, 애초에 베타테스트 용의 프로덕트라서 사용자 개인정보는 최대한 저장하지 않는 방향으로 팀 내부 논의를 마친터라, 앱단에서 정보를 받은 뒤 로그인용 기기id 정도만 백엔드 서버에 넘겨서 냅다 로그인(인증)하고 해당 정보는 저장하지 않는 흐름으로 구현했다. 이후에는 JWT 토큰을 통해 인가 처리 및 로그인 유지를 수행해서 그러한 정보가 필요하지 않았던 것도 있다. 해당 작업 이후에도 정보 암호화를 고민했으나, 시간상의 이유와 저장된 정보가 민감하지 않다고 판단해 보류하는 것으로 결론을 내렸다.

그러다가 가장 최근 프로젝트에서는 다른 개발자가 하던 일을 이어서 맡게 되었는데, 로그인 관련 인증인가 처리를 대부분 작업해 둔 뒤라서 그 코드를 훑어보면서 많이 배울 수 있었다. 그전까지 정보 암호화는 이론적으로만 배운 상태라, 비밀번호 암호화를 제외하고는 별 생각이 없었다. 그런데 Spring이 제공하는 User 클래스를 활용, UserDetails 인터페이스를 구현(implements)하여 암호화된 정보를 통해 사용자를 인증하고 작업을 인가받는 정석적인 방식을 하나씩 뜯어보게 되면서 DB에 저장되는 개인정보도 이정도의 암호화는 거쳐야하는구나 새삼 깨닫게 된 것이다.

그러고나서 보니 더더욱 SKT 사태가 흥미롭다. 나야... 현업에 발도 못 디뎌 본 아마추어라지만... 당신들은 뭔데... ㅋㅋㅋㅋㅋㅋ

아무튼, 이참에 새롭게 나의 어리석었던 허점투성이 보안 작업을 되짚어볼 수 있었으니, 배운 게 하나라도 있어 다행인지.. 아, 참고로 첫 번째 기사에서 언급한 PUF는, Physical unclonable function의 약자로, IoT등 임베디드 / HW 기술에서 사용되는 키 은닉 기술이라고 한다. 암호키로 난수 값을 지정해서 주입하는 일반적인 방식과 달리, 제조공정에서 물리적으로 발생하는 미세구조의 편차를 기반으로 고유한 개인(비공개) 키를 생성하는 기술이라고 하는데, 그렇다면 해당 미세구조에는 작업자의 의도나 규칙성이 들어가지 않을테니 해킹 불가, 복호화 및 복제 불가라고 표현한 것이 이해가 간다. '실리콘 지문'이라는 표현도 쓰는 거 보니 같은 키가 나올 확률이 0에 가까운 모양이다.

비공개 키(private key)라는 표현을 보니 비대칭 암호화 알고리즘의 키로 쓰는 것 같은데, 그러면 확실히 속도가 좀 느리기는 하겠다 싶다. 그래도 안전한 게 낫지... 궁금한 건, 유심 확인시에 같은 쌍의 공개 키(public key)로 암호화된 정보를 비공개 키(private key)로 복호화하는 걸까, 아님 모든 정보는 공개 키로 암호화되어 있는데 각 유심(을 가진 디바이스?)에서 그걸 비공개 키로 복호화해서 내부 데이터로 인증하게 되는 건가, 아님 아예 다른 방법인가 하는 것인데, 잠깐 찾아보는 걸로는 나오지 않아서 논문 정도는 뒤져야 나오지 않을까 싶다. 자세히는 모르겠지만, 우연히 발생하는 물리적인 미세편차를 키로 사용한다는 게 정말 신기하고, 하드웨어와 소프트웨어 융합적인 유연한 생각의 발로인 것 같아 한 층 식견이 넓어진 기분이 든다.

// 기사, 위키를 보면서 개인적인 회고 목적으로 쓴 포스트입니다. 부정확한 정보를 담고 있을 수 있으므로 주의하시고, 문제의 소지가 있다면 따로 연락주세요.