본문 바로가기

이동통신관련

5G SA 보안 핵심기술 SUCI 완벽 분석: IMSI 프라이버시 보호의 혁신

반응형
🔐 기술 개요
SUCI (Subscription Concealed Identifier) - 5G 사용자 프라이버시 보호 메커니즘
📊 적용 Release: 3GPP Release 15+ (SA Architecture)
🎯 타겟 레벨: 🔧중급 - 🏗️고급 보안 엔지니어
💡 핵심 가치: IMSI 노출 방지를 통한 5G 네트워크 사용자 프라이버시 보호 및 암호화 기반 식별자 전송으로 위치 추적 차단

🚀 5G Standalone(SA) 네트워크의 보안 혁신 중 가장 중요한 기술 중 하나가 바로 SUCI입니다. 기존 LTE 네트워크에서 사용자 식별을 위해 평문으로 전송되던 IMSI(International Mobile Subscriber Identity)의 보안 취약점을 해결하기 위해 개발된 SUCI는 암호화된 사용자 식별자를 통해 근본적인 프라이버시 보호를 제공합니다. 본 기술 분석에서는 3GPP TS 33.501 규격을 기반으로 SUCI의 암호화 메커니즘, 구현 방법, 그리고 실제 네트워크 운영에서의 보안 고려사항을 심층적으로 다룹니다.

🏗️ 기술 배경 및 표준화

🔰 초급자 핵심 포인트
SUCI란 '숨겨진 가입자 식별자'로, 기존의 IMSI를 암호화하여 무선 구간에서 전송하는 5G 보안 기술입니다. 마치 편지봉투에 수신자 주소를 암호화해서 쓰는 것과 같이, 사용자의 실제 식별정보를 숨겨서 프라이버시를 보호합니다.

📜 IMSI 보안 문제의 역사

모바일 통신 네트워크의 발전 과정에서 사용자 식별은 항상 중요한 이슈였습니다. IMSI는 2G GSM 시대부터 사용되어 온 글로벌 고유 식별자로, 15자리 숫자로 구성되어 MCC(Mobile Country Code), MNC(Mobile Network Code), MSIN(Mobile Subscriber Identification Number)을 포함합니다. 그러나 기존 네트워크에서는 다음과 같은 보안 취약점이 존재했습니다.

🔍 기존 IMSI 전송의 보안 위험
  • 평문 전송: Initial Attach 과정에서 IMSI가 암호화되지 않은 상태로 전송
  • 위치 추적 가능: IMSI Catcher를 통한 사용자 위치 및 이동 패턴 추적
  • 신원 노출: 무선 구간 모니터링을 통한 가입자 정보 탈취
  • 스푸핑 공격: 위조된 기지국을 통한 IMSI 수집 및 악용

📋 3GPP 표준화 과정

SUCI의 개발은 3GPP SA3(Security) 워킹 그룹에서 시작되었으며, 2017년 Release 15 규격 개발 과정에서 사용자 프라이버시 보호가 핵심 요구사항으로 대두되었습니다. 특히 유럽의 GDPR(General Data Protection Regulation) 시행과 함께 개인정보 보호에 대한 요구가 강화되면서, 통신 네트워크 차원에서의 프라이버시 보호 기술 개발이 필수가 되었습니다.

🔧 중급자 기술 포인트
SUCI는 ECIES(Elliptic Curve Integrated Encryption Scheme) 기반의 공개키 암호화를 사용합니다. Home Network의 공개키로 SUPI를 암호화하여 SUCI를 생성하며, 복호화는 Home Network에서만 가능합니다. 이는 Zero-Knowledge Privacy 개념을 통신 네트워크에 적용한 혁신적 접근입니다.

🔧 주요 설계 원칙

SUCI 설계 시 다음과 같은 핵심 원칙들이 적용되었습니다. 첫째, Forward Secrecy 원칙에 따라 매번 다른 SUCI 값이 생성되어 동일한 사용자라도 식별이 불가능하도록 설계되었습니다. 둘째, End-to-End Privacy 보장을 위해 오직 Home Network에서만 복호화가 가능하며, Visited Network를 포함한 중간 네트워크 요소들은 사용자의 실제 식별정보에 접근할 수 없습니다. 셋째, Backward Compatibility를 위해 기존 IMSI 구조와 호환되는 형태로 설계되어 네트워크 업그레이드 시 호환성 문제를 최소화했습니다.

🏛️ SUCI 시스템 아키텍처

📋 SUCI 전체 시스템 아키텍처
flowchart TD UE[UE Device] --> gNB[gNB Base Station] gNB --> AMF[AMF Core] AMF --> AUSF[AUSF Security] AUSF --> UDM[UDM Management] UDM --> SIDF[SIDF Function] UE -.->|SUCI Generation| EncryptModule[Encryption Module] EncryptModule -.->|Home Network Public Key| PublicKey[HN Public Key] SIDF -.->|SUCI Decryption| DecryptModule[Decryption Module] DecryptModule -.->|Home Network Private Key| PrivateKey[HN Private Key] classDef ueClass fill:#fbe9e7,stroke:#d84315,stroke-width:2px classDef coreClass fill:#f5f5f5,stroke:#757575,stroke-width:2px classDef securityClass fill:#fce4ec,stroke:#e91e63,stroke-width:2px class UE,EncryptModule ueClass class AMF,UDM coreClass class AUSF,SIDF,DecryptModule,PublicKey,PrivateKey securityClass
SUCI 아키텍처 구성요소: UE에서 Home Network 공개키로 SUPI를 암호화하여 SUCI 생성, AMF를 거쳐 AUSF/UDM으로 전달, SIDF에서 개인키로 복호화하여 SUPI 복원. 전체 과정에서 Visited Network는 평문 SUPI에 접근 불가능.

🔑 핵심 구성 요소 분석

🏠 Home Network Public Key Infrastructure

Home Network는 SUCI 암호화를 위한 공개키-개인키 쌍을 관리합니다. 공개키는 UE에 사전 프로비저닝되거나 OTA(Over-The-Air) 방식으로 배포되며, 개인키는 Home Network의 SIDF(Subscription Identifier De-concealing Function)에서 안전하게 보관됩니다. 키 관리에는 NIST P-256 또는 X25519 타원곡선이 사용됩니다.

📱 UE SUCI Generation Engine

UE 내부의 SUCI 생성 엔진은 ME(Mobile Equipment)와 USIM 간 협력으로 동작합니다. USIM에는 Home Network 공개키와 Protection Scheme 정보가 저장되어 있으며, ME의 암호화 모듈이 실제 SUCI 생성 작업을 수행합니다. 생성 과정에서 Ephemeral Key가 사용되어 매번 다른 SUCI 값이 생성됩니다.

🔐 SIDF (Subscription Identifier De-concealing Function)

SIDF는 Home Network에 위치한 SUCI 복호화 전용 기능으로, UDM과 연동되어 동작합니다. 수신된 SUCI를 개인키로 복호화하여 원본 SUPI를 복원하며, 복호화 과정에서 무결성 검증도 동시에 수행합니다. SIDF는 HSM(Hardware Security Module) 기반으로 구현되어 높은 수준의 보안을 제공합니다.

🔐 SUCI 암호화 메커니즘 심화 분석

🏗️ 고급자 심화 포인트
SUCI는 Profile A(ECIES with P-256 curve)와 Profile B(ECIES with X25519 curve) 두 가지 암호화 프로파일을 지원합니다. ECIES는 KEM(Key Encapsulation Mechanism) + DEM(Data Encapsulation Mechanism) 구조로, 하이브리드 암호화의 장점을 활용합니다. MAC(Message Authentication Code)를 통한 무결성 보장도 필수 요소입니다.

🎯 Protection Scheme 상세 분석

Protection Scheme 암호화 알고리즘 키 길이 보안 수준 적용 시나리오
Null Scheme (0) 암호화 없음 - 낮음 테스트/레거시
Profile A (1) ECIES P-256 256 bit 높음 상용 네트워크
Profile B (2) ECIES X25519 255 bit 매우 높음 고보안 요구
Vendor Specific (3-4) 벤더 정의 가변 벤더 의존 특수 요구사항

⚙️ ECIES 암호화 과정 상세

ECIES(Elliptic Curve Integrated Encryption Scheme) 기반 SUCI 생성은 다음과 같은 단계로 진행됩니다. 첫 번째 단계에서 UE는 임시 키 쌍 (ephemeral key pair)을 생성하고, 두 번째 단계에서 Home Network 공개키와 임시 개인키를 사용하여 공유 비밀(shared secret)을 계산합니다. 세 번째 단계에서는 KDF(Key Derivation Function)를 통해 암호화키와 MAC키를 도출하며, 네 번째 단계에서 AES-CTR 모드로 SUPI를 암호화합니다. 마지막으로 HMAC-SHA256을 사용하여 무결성 태그를 생성하고, 임시 공개키, 암호문, MAC 태그를 결합하여 최종 SUCI를 생성합니다.

🔬 ECIES 암호화 파라미터 (3GPP TS 33.501)
타원곡선 (Profile A):
NIST P-256 (secp256r1), Prime field p = 2^256 - 2^224 + 2^192 + 2^96 - 1
타원곡선 (Profile B):
Curve25519, Montgomery curve y^2 = x^3 + 486662x^2 + x over prime field 2^255 - 19
KDF 함수:
ANSI X9.63 KDF with SHA-256, Counter mode with 32-bit counter
대칭 암호화:
AES-128-CTR mode, 128-bit key, 128-bit counter/IV
메시지 인증:
HMAC-SHA-256, 256-bit authentication tag

🛡️ 보안 속성 및 공격 저항성

SUCI 암호화 메커니즘은 다양한 암호학적 공격에 대한 저항성을 제공합니다. IND-CCA2(Indistinguishability under Chosen Ciphertext Attack) 보안을 만족하여 공격자가 선택한 암호문에 대한 복호화 쿼리를 수행해도 원본 메시지를 구별할 수 없습니다. Forward Secrecy를 통해 과거 통신의 기밀성을 보장하며, 개인키가 노출되어도 이전에 생성된 SUCI로부터 SUPI를 복원할 수 없습니다. 또한 Unlinkability 속성으로 동일한 사용자가 생성한 서로 다른 SUCI 간의 연관성을 찾을 수 없도록 설계되었습니다.

🔄 SUPI-SUCI 변환 프로세스

📊 SUPI 구조 분석

SUPI(Subscription Permanent Identifier)는 5G에서 사용자를 영구적으로 식별하는 식별자로, 일반적으로 IMSI 형태를 가집니다. SUPI는 "imsi-[15자리 숫자]" 또는 NAI(Network Access Identifier) 형태인 "[username]@[realm]" 구조를 가질 수 있습니다. IMSI 형태의 SUPI는 MCC(3자리) + MNC(2-3자리) + MSIN(9-10자리)로 구성되며, 예를 들어 "imsi-450080123456789"와 같은 형태입니다.

📋 SUPI to SUCI 변환 프로세스
flowchart TD SUPI[SUPI Input] --> Parse[Parse SUPI] Parse --> MCCMNC[Extract MCC MNC] Parse --> MSIN[Extract MSIN] MSIN --> Encrypt[ECIES Encryption] PublicKey[HN Public Key] --> Encrypt Encrypt --> CipherText[Encrypted MSIN] MCCMNC --> Combine[Combine Components] CipherText --> Combine Scheme[Protection Scheme] --> Combine Combine --> SUCI[SUCI Output] classDef inputClass fill:#fbe9e7,stroke:#d84315,stroke-width:2px classDef processClass fill:#f5f5f5,stroke:#757575,stroke-width:2px classDef outputClass fill:#fce4ec,stroke:#e91e63,stroke-width:2px class SUPI,PublicKey,Scheme inputClass class Parse,MCCMNC,MSIN,Encrypt,CipherText,Combine processClass class SUCI outputClass
변환 과정: SUPI에서 MCC/MNC는 평문으로 유지하고 MSIN 부분만 암호화. Home Network 공개키와 선택된 Protection Scheme을 사용하여 ECIES 암호화 수행 후 최종 SUCI 생성.

🎨 SUCI 구조 및 인코딩

생성된 SUCI는 다음과 같은 구조를 가집니다. Type 필드(4 bit)는 항상 '0001'로 설정되어 SUCI 임을 나타내며, Protection Scheme ID(4 bit)는 사용된 암호화 방식을 표시합니다. Home Network Identifier는 MCC(12 bit) + MNC(12 bit)로 구성되어 평문으로 전송되며, 이를 통해 라우팅이 가능합니다. 가장 중요한 부분인 Encrypted Identifier는 암호화된 MSIN으로, 길이는 Protection Scheme에 따라 달라집니다.

필드명 길이 (bit) 값/설명 암호화 여부
Type 4 0001 (SUCI) 평문
Protection Scheme 4 0-4 (암호화 방식) 평문
Home Network ID 24 MCC + MNC 평문
Routing Indicator 16 네트워크별 정의 평문
Encrypted Identifier 가변 암호화된 MSIN 암호화
🔧 실무 구현 팁
SUCI 인코딩 시 Encrypted Identifier 길이는 Protection Scheme에 따라 달라집니다. Profile A 사용 시 약 270-300 바이트, Profile B 사용 시 약 260-290 바이트 정도 소요됩니다. 이는 원본 IMSI(15자리, 약 8바이트)보다 훨씬 크므로 네트워크 메시지 크기 증가를 고려해야 합니다.

📞 SUCI 기반 Registration 프로시저

📋 Initial Registration with SUCI Call Flow
sequenceDiagram participant UE as UE Device participant gNB as gNB Base Station participant AMF as AMF Core participant AUSF as AUSF Security participant UDM as UDM Management participant SIDF as SIDF Function UE->>UE: Generate SUCI from SUPI UE->>gNB: Registration Request with SUCI gNB->>AMF: N2 Registration Request AMF->>AUSF: Authentication Request with SUCI AUSF->>UDM: Authentication Info Request UDM->>SIDF: SUCI Decryption Request SIDF->>UDM: Return SUPI UDM->>AUSF: Authentication Vector AUSF->>AMF: Authentication Response AMF->>UE: Authentication Request via gNB UE->>AMF: Authentication Response via gNB AMF->>UE: Registration Accept via gNB
Call Flow 단계: UE에서 SUCI 생성 후 Registration 요청, AMF를 통해 AUSF로 전달, UDM에서 SIDF를 호출하여 SUCI 복호화 및 SUPI 복원, 이후 정상적인 5G AKA 인증 절차 진행.

🔄 상세 Call Flow 분석

Step 1:
UE SUCI Generation
UE는 등록 과정 시작 전에 USIM에 저장된 SUPI와 Home Network 공개키를 사용하여 SUCI를 생성합니다. 이 과정에서 난수 생성기를 통해 임시 키를 생성하고, ECIES 암호화를 수행하여 매번 다른 SUCI 값을 만들어냅니다.
Step 2:
Registration Request Transmission
생성된 SUCI는 NAS Registration Request 메시지에 포함되어 gNB를 통해 AMF로 전송됩니다. 이때 5G-GUTI가 없는 경우이므로 반드시 SUCI가 사용되며, 무선 구간에서도 암호화된 상태로 전송됩니다.
Step 3:
AMF Processing and Routing
AMF는 수신된 SUCI의 MCC/MNC 정보를 바탕으로 적절한 Home Network의 AUSF를 식별하고, Nausf_UEAuthentication 서비스를 통해 인증 요청을 전달합니다. 이때 SUCI는 암호화된 상태로 유지됩니다.
Step 4:
SUCI Decryption at SIDF
UDM은 수신된 SUCI를 SIDF로 전달하여 복호화를 요청합니다. SIDF는 Home Network의 개인키를 사용하여 ECIES 복호화를 수행하고, 무결성 검증을 통과한 경우에만 원본 SUPI를 반환합니다.
Step 5:
Authentication Vector Generation
복원된 SUPI를 사용하여 UDM에서 해당 가입자의 인증 벡터를 생성하고, 5G AKA 인증 절차가 정상적으로 진행됩니다. 이후 과정은 일반적인 5G 등록 절차와 동일합니다.

🔗 SUCI 관련 인터페이스 분석

📡 NAS 계층 SUCI 처리

NAS(Non-Access Stratum) 계층에서 SUCI는 Registration Request, Service Request 등의 메시지에서 사용자 식별자로 활용됩니다. 5GS Mobile Identity 타입으로 인코딩되며, Type 4 IE(Information Element) 형태로 전송됩니다. SUCI의 최대 길이는 Protection Scheme에 따라 달라지지만, 일반적으로 300바이트 이내로 제한됩니다.

NAS 메시지 내 SUCI 인코딩 구조
• IEI (Information Element Identifier): 0x77
• Length: SUCI 전체 길이 (바이트)
• Type of Identity: 0x01 (SUCI)
• SUCI Content: Protection Scheme + MCC/MNC + Encrypted Data

🌐 SBI 인터페이스에서의 SUCI

5G Core의 SBI(Service Based Interface)에서 SUCI는 JSON 형태로 표현됩니다. Nausf_UEAuthentication, Nudm_UEAuthentication 등의 서비스에서 "suci" 필드로 전달되며, Base64 인코딩된 형태로 HTTP 메시지에 포함됩니다. RESTful API 특성상 URL path parameter로도 사용될 수 있으나, 길이 제한으로 인해 주로 message body에 포함됩니다.

🔍 SBI SUCI JSON Schema 예시

{

  "suci": "suci-0-450-08-0123456789abcdef...",

  "servingNetworkName": "5G:mnc008.mcc450.3gppnetwork.org",

  "resynchronizationInfo": {

    "rand": "...",

    "auts": "..."

  }

}

        

⚙️ SUCI 실무 구현 및 운영 고려사항

🔧 UE 구현 요구사항

UE에서 SUCI 구현 시 다음 사항들을 고려해야 합니다. 첫째, 암호화 성능 최적화가 중요합니다. ECIES 연산은 CPU 집약적이므로 하드웨어 가속기 활용이나 효율적인 소프트웨어 구현이 필요합니다. 일반적으로 SUCI 생성에는 10-50ms 정도 소요되므로 등록 지연에 미치는 영향을 최소화해야 합니다. 둘째, 키 관리 보안을 위해 Home Network 공개키는 USIM에 안전하게 저장되어야 하며, 키 업데이트 메커니즘도 구현되어야 합니다. 셋째, 에러 처리 로직이 필요합니다. 암호화 실패 시 fallback 메커니즘이나 재시도 로직을 구현해야 하며, Protection Scheme 협상 기능도 고려해야 합니다.

🏗️ UE 구현 성능 최적화
ECIES 연산 최적화를 위해 Montgomery Ladder 알고리즘 사용, Windowed NAF 방식의 스칼라 곱셈, 그리고 Precomputed Table 활용을 권장합니다. 또한 TrustZone이나 Secure Element를 활용한 키 보호도 중요한 고려사항입니다.

🏠 Home Network 구현 요구사항

Home Network에서는 SIDF 구현이 핵심입니다. 개인키 보호를 위해 HSM(Hardware Security Module) 사용이 강력히 권장되며, FIPS 140-2 Level 3 이상의 보안 수준을 만족해야 합니다. 성능 확장성 측면에서는 대용량 SUCI 복호화 요청을 처리할 수 있는 아키텍처가 필요하며, 일반적으로 초당 수만 건의 복호화 요청을 처리할 수 있어야 합니다. 가용성 보장을 위해 이중화 구성과 부하 분산 메커니즘이 필수적이며, SIDF 장애 시 서비스 중단을 방지할 수 있는 백업 시스템도 구축해야 합니다.

🌐 네트워크 운영 고려사항

실제 네트워크 운영에서는 다음과 같은 사항들이 중요합니다. 메시지 크기 증가로 인한 영향을 분석해야 합니다. SUCI는 IMSI보다 약 30-40배 크므로 NAS 메시지 오버헤드가 증가하며, 특히 무선 구간에서의 전송 효율성을 고려해야 합니다. 로깅 및 모니터링 시에는 SUCI 값 자체는 로그에 기록해도 되지만, 복호화된 SUPI는 개인정보이므로 별도의 보안 조치가 필요합니다. 상호 운용성 측면에서는 다양한 벤더 장비 간 SUCI 처리 호환성을 검증해야 하며, 표준 준수 여부를 지속적으로 확인해야 합니다.

📊 SUCI 운영 메트릭 모니터링
  • SUCI 생성 성공률: UE에서의 암호화 성공/실패 비율
  • SIDF 복호화 성능: 평균 복호화 시간 및 처리량
  • 인증 지연 영향: SUCI 사용 시 추가되는 등록 지연 시간
  • 에러율 모니터링: 복호화 실패, 무결성 검증 실패 비율
  • 키 관리 상태: 공개키 배포 상태 및 갱신 필요성

🛡️ SUCI 보안 심화 분석 및 위협 모델

⚔️ 주요 공격 시나리오

SUCI에 대한 주요 보안 위협을 분석하면 다음과 같습니다. IMSI Catcher 공격에 대해서는 SUCI가 강력한 보호를 제공합니다. 공격자가 위조 기지국을 운영하더라도 암호화된 SUCI만 획득할 수 있으며, Home Network 개인키 없이는 사용자 신원을 파악할 수 없습니다. 트래픽 분석 공격의 경우, 동일 사용자의 여러 SUCI 간 연관성을 찾으려는 시도가 있을 수 있으나, 매번 다른 임시 키 사용으로 인해 통계적 연관성 분석이 거의 불가능합니다. 암호화 강도 공격에서는 ECIES의 기반인 ECDH 문제의 계산 복잡도가 보안 강도를 결정하며, 현재 P-256과 X25519는 양자 컴퓨터가 아닌 이상 충분한 보안 강도를 제공합니다.

🏗️ 양자 저항성 고려사항
현재 SUCI에 사용되는 ECIES는 양자 컴퓨터 공격에 취약합니다. NIST PQC(Post-Quantum Cryptography) 표준화가 완료되면 CRYSTALS-Kyber 같은 격자 기반 암호화나 SIKE 같은 동종사상 기반 암호화로의 전환이 필요할 것으로 예상됩니다.

🔍 프라이버시 분석

SUCI의 프라이버시 보호 수준을 정량적으로 분석해보면, Anonymity Set 크기는 이론적으로 Home Network의 전체 가입자 수와 동일합니다. 즉, 공격자가 특정 SUCI를 관찰하더라도 해당 가입자를 식별할 확률은 1/N(N: 총 가입자 수)입니다. Linkability Resistance 측면에서는 동일 사용자의 연속된 SUCI 간 연관성을 찾을 확률이 무시할 만한 수준이며, 이는 암호학적으로 증명 가능한 수준입니다. Location Privacy는 기존 IMSI 기반 시스템 대비 획기적으로 개선되어, 사용자의 위치 이동 패턴을 추적하는 것이 거의 불가능해졌습니다.

🎯 SUCI 기술 핵심 요약

🔐 핵심 기술:
ECIES 기반 공개키 암호화를 통한 IMSI 보호, 매번 다른 암호화 결과로 추적 방지
🛡️ 보안 강도:
P-256 curve: 128-bit 보안 강도, X25519 curve: 128-bit 보안 강도, 양자 공격 전까지 안전
📊 성능 영향:
UE 암호화: 10-50ms, 메시지 크기: 30-40배 증가, SIDF 복호화: 1-5ms
🌐 표준 규격:
3GPP TS 33.501 (보안), TS 23.003 (식별자), TS 24.501 (NAS)
⚙️ 구현 요구사항:
UE: 암호화 엔진, USIM 공개키 저장, HN: SIDF/HSM, 키 관리 시스템

❓ SUCI 기술 FAQ

Q1: SUCI 사용 시 모든 등록에서 암호화 연산이 필요한가요?

아닙니다. SUCI는 주로 Initial Registration이나 5G-GUTI가 없는 상황에서만 사용됩니다. 정상적인 등록 후에는 AMF가 할당한 5G-GUTI를 사용하므로 SUCI 생성 부하는 제한적입니다. 또한 네트워크 정책에 따라 주기적으로만 SUCI를 사용하도록 설정할 수도 있습니다.

Q2: Visited Network에서 SUCI를 복호화할 수 없나요?

기술적으로 불가능합니다. SUCI는 Home Network의 공개키로 암호화되므로 오직 Home Network의 개인키만으로 복호화가 가능합니다. 이는 설계상 의도된 것으로, Visited Network가 사용자의 실제 신원을 알 필요가 없도록 하여 프라이버시를 보호합니다.

Q3: SUCI 길이가 너무 크면 NAS 메시지 제한에 걸리지 않나요?

일반적으로 문제없습니다. SUCI 최대 길이는 약 300바이트 정도이며, NAS 메시지 최대 크기는 수 KB입니다. 다만 SMS나 일부 제한된 환경에서는 고려가 필요할 수 있으며, 이런 경우 Protection Scheme을 조정하거나 압축 기법을 사용할 수 있습니다.

Q4: Home Network 개인키가 노출되면 모든 SUCI가 위험한가요?

과거에 생성된 SUCI에 대해서는 위험하지만, Forward Secrecy 속성으로 인해 키 교체 후 생성되는 새로운 SUCI는 안전합니다. 또한 키 노출 시 즉시 새로운 키 쌍을 생성하고 UE에 배포하는 긴급 절차가 필요하며, HSM 사용으로 키 노출 위험을 최소화해야 합니다.

Q5: 로밍 환경에서 SUCI 처리는 어떻게 이루어지나요?

로밍 시에도 SUCI의 MCC/MNC 정보를 통해 정확한 Home Network로 라우팅됩니다. Visited Network의 AMF는 암호화된 SUCI를 그대로 Home Network의 AUSF로 전달하며, 복호화는 여전히 Home Network의 SIDF에서만 수행됩니다. 이를 통해 로밍 중에도 동일한 수준의 프라이버시 보호가 제공됩니다.

📚 관련 규격 및 참고 자료

🔐 핵심 3GPP 규격
🔬 암호화 표준 참고
📖 추가 참고 자료
반응형