[Protocol] 5G NR Fundamental - Part 13: 5G Security, NAS/AS 보안과 키 계층
Part 12에서 RRC Idle, RRC Inactive, Paging, RRC Resume을 봤다면 이제 자연스럽게 이런 질문이 남습니다.
“UE가 다시 네트워크와 연결될 때, 그 연결은 언제부터 안전하다고 볼 수 있을까?” 5G에서는 단순히 접속이 됐다고 끝이 아닙니다. 인증, NAS 보안, AS 보안, 사용자 평면 보안이 단계별로 걸리고, 각 단계마다 사용하는 키와 알고리즘이 다릅니다.
이번 글에서는 표준 문서의 딱딱한 키 이름을 외우기보다, 실제 로그를 볼 때 흐름이 잡히도록 5G Security를 풀어보겠습니다.
| 이전 시리즈 흐름 Part 1: 5G NR 전체 개요 → Part 2: NR 프로토콜 스택 → Part 3: Initial Access → Part 4: RACH 절차 → Part 5: RRC Setup과 5G Registration → Part 6: PDU Session Establishment → Part 7: User Plane, GTP-U, QoS Flow와 DRB 매핑 → Part 8: 5G QoS, 5QI, GBR/Non-GBR → Part 9: RRC Reconfiguration과 DRB 설정 → Part 10: Measurement Report와 Handover → Part 11: RLM, RLF, RRC Re-establishment → Part 12: RRC State, Inactive, Paging, Resume → Part 13: 5G Security |
핵심 요약
1. 5G Security가 필요한 이유
무선 구간은 유선망처럼 물리적으로 닫힌 경로가 아닙니다.
UE와 gNB 사이의 신호는 공중으로 전달되기 때문에, 누군가가 신호를 수신하거나 위조 메시지를 시도할 가능성을 항상 전제로 봐야 합니다.
그래서 5G는 접속 절차 안에 인증, 키 생성, 알고리즘 선택, 무결성 검증, 암호화 적용 절차를 넣어 둡니다.
실무에서 중요한 포인트는 “보안은 한 번에 켜지는 기능이 아니라 단계별로 활성화된다”는 점입니다.
RRC Setup이 끝났다고 해서 모든 메시지가 바로 암호화되는 것은 아닙니다.
NAS Security가 먼저 잡히고, 이후 gNB 쪽 AS Security가 활성화되며, DRB가 만들어진 뒤 사용자 데이터에도 보안 처리가 적용됩니다.
| 로그를 볼 때 기억할 한 문장 Registration 흐름에서 보안 관련 문제를 볼 때는 Authentication → NAS Security Mode → Initial Context Setup → RRC Security Mode → DRB Setup 순서로 끊어 보면 원인 범위가 빠르게 줄어듭니다. |
2. NAS Security와 AS Security의 큰 그림
5G Security를 처음 볼 때 헷갈리는 지점은 NAS와 AS가 모두 “보안”이라는 이름을 쓰기 때문입니다.
하지만 보호하는 구간이 다릅니다.
NAS는 UE와 5GC의 AMF 사이에서 오가는 Mobility Management, Session Management 관련 메시지를 보호합니다.
반면 AS는 UE와 gNB 사이의 무선 접속 구간을 보호합니다. RRC 메시지와 DRB 사용자 데이터가 여기에 들어갑니다.
| 구분 | 보호 구간 | 대표 메시지/데이터 | 주요 키 | 실무 확인 포인트 |
| NAS Security | UE ↔ AMF | Registration, Service Request, PDU Session NAS 메시지 | KAMF, KNASenc, KNASint | NAS Security Mode Command/Complete, selected NAS algorithm |
| AS Security | UE ↔ gNB | RRC 메시지, SRB, DRB 사용자 데이터 | KgNB, KRRCenc, KRRCint, KUPenc, KUPint | RRC SecurityModeCommand/Complete, PDCP ciphering/integrity |
| Authentication | UE ↔ Core 인증 기능 | 5G-AKA, EAP-AKA′ 기반 인증 절차 | KSEAF, KAMF 등 상위 보안 컨텍스트 | Authentication Request/Response, Authentication Failure 원인 |
3. Registration 중 보안 활성화 흐름
전체 흐름을 로그처럼 보면 아래 순서가 가장 이해하기 쉽습니다.
먼저 UE는 RRC Setup을 통해 gNB와 기본 연결을 만들고, NAS Registration Request를 AMF로 전달합니다.
그 뒤 AMF는 인증을 수행하고, 인증이 성공하면 NAS Security Mode Command로 NAS 메시지 보호를 활성화합니다.
이후 AMF가 gNB에게 UE 보안 컨텍스트를 내려주면, gNB는 RRC SecurityModeCommand를 보내 AS 보안을 켭니다.
실무적으로 많이 헷갈리는 부분
gNB는 NAS 메시지의 최종 수신자가 아닙니다.
Registration Request 같은 NAS 메시지는 RRC 메시지 안에 실려 gNB를 지나 AMF로 전달됩니다.
그래서 NAS Security 자체는 UE와 AMF가 맞춰야 하고, gNB는 이후 AMF로부터 받은 보안 컨텍스트를 바탕으로 AS Security를 설정합니다.
- RRC Setup
- NAS Registration
- Authentication
- NAS Security
- Initial Context Setup
- AS Security
- DRB Setup
4. 5G 키 계층: KAMF, KgNB, NH, NCC
5G 보안 키 이름은 처음 보면 외울 것이 많아 보입니다.
하지만 구조는 “상위 키에서 하위 키를 파생한다”는 한 가지 원리로 보면 됩니다.
가입자 인증을 통해 상위 보안 컨텍스트가 만들어지고, AMF 기준의 KAMF에서 NAS용 키가 나오며, 무선 접속망에서는 gNB가 사용할 KgNB와 RRC/UP용 키가 파생됩니다.
| 키/컨텍스트 | 역할 | 주로 관련된 절차 |
| KAMF | AMF 기준의 핵심 보안 컨텍스트. NAS 보안 키와 AS 보안 컨텍스트 파생의 기준이 된다. | Registration, NAS Security |
| KNASenc / KNASint | NAS 메시지 암호화 및 무결성 보호에 사용된다. | NAS Security Mode Command |
| KgNB | gNB가 AS 보안을 설정할 때 사용하는 기준 키다. | Initial Context Setup, AS Security |
| KRRCenc / KRRCint | RRC 메시지의 ciphering 및 integrity protection에 사용된다. | RRC Security Mode Command 이후 SRB 보호 |
| KUPenc / KUPint | 사용자 평면 데이터의 ciphering 및 integrity protection에 사용된다. | DRB 설정 이후 PDCP 처리 |
| NH / NCC | Handover 시 다음 gNB 키를 안전하게 이어가기 위한 key chaining에 사용된다. | Handover, Re-establishment |
5. NAS Security Mode Command
NAS Security Mode Command는 AMF가 UE에게 “앞으로 NAS 메시지는 이 알고리즘과 키를 기준으로 보호하자”고 알려주는 절차입니다.
여기서 선택되는 항목은 NAS ciphering algorithm과 NAS integrity algorithm입니다.
UE는 자신의 security capability를 이미 네트워크에 알렸고, AMF는 그 중 네트워크 정책에 맞는 알고리즘을 선택합니다.
NAS Security Mode Complete가 정상적으로 올라오면, 이후 NAS 메시지는 설정된 보안 컨텍스트에 따라 보호됩니다.
만약 이 단계에서 실패하면, RRC나 DRB 쪽을 보기 전에 인증 결과, UE security capability, NAS 알고리즘 선택, MAC 검증 실패 여부를 먼저 확인하는 편이 빠릅니다.
| NAS Security 로그 체크 Authentication 성공 여부 / UE security capability / Selected NAS algorithms / NAS MAC verification / Security Mode Reject cause |
6. AS Security Mode Command와 PDCP 보안
AS Security는 gNB와 UE 사이의 RRC 및 사용자 평면을 보호합니다.
이때 gNB는 AMF로부터 받은 보안 컨텍스트를 기반으로 AS 알고리즘을 선택하고, UE에게 RRC SecurityModeCommand를 보냅니다.
UE가 SecurityModeComplete를 보내면 AS 보안이 활성화됩니다.
실제 ciphering과 integrity protection은 PDCP 계층에서 처리됩니다.
그래서 보안 문제를 분석할 때 PDCP COUNT, bearer ID, direction, algorithm, key가 서로 맞아야 합니다.
한쪽은 암호화를 적용했는데 다른 쪽은 아직 적용하지 않았거나, COUNT 값이 어긋나면 패킷이 정상 복호화되지 않거나 무결성 검증에 실패할 수 있습니다.
| 항목 | 설명 | 주의점 |
| Ciphering | 메시지나 사용자 데이터를 제3자가 읽기 어렵도록 암호화한다. | RRC/DRB별 적용 시점과 알고리즘 일치 여부를 확인한다. |
| Integrity Protection | 메시지가 중간에 변조되지 않았는지 검증한다. | RRC signaling은 특히 무결성 보호가 중요하다. |
| PDCP COUNT | PDCP SN과 HFN 기반으로 보안 처리에 사용되는 카운터 개념이다. | 재전송, 재수립, Handover 상황에서 mismatch가 발생하면 복호화 문제가 생길 수 있다. |
| Bearer별 키 적용 | SRB/DRB에 따라 RRC 키 또는 UP 키가 사용된다. | SRB와 DRB를 같은 관점으로 보면 로그 해석이 꼬일 수 있다. |
NEA와 NIA 알고리즘
5G에서는 암호화 계열을 NEA, 무결성 계열을 NIA로 부릅니다.
예를 들어 128-NEA1, 128-NEA2, 128-NEA3는 ciphering 알고리즘 계열이고, 128-NIA1, 128-NIA2, 128-NIA3는 integrity 알고리즘 계열입니다.
실제 사용 알고리즘은 UE capability와 네트워크 정책에 따라 선택됩니다.
| 구분 | 대표 알고리즘 | 의미 |
| Encryption | 128-NEA1 / 128-NEA2 / 128-NEA3 | NAS, RRC, UP 데이터의 암호화에 사용되는 계열 |
| Integrity | 128-NIA1 / 128-NIA2 / 128-NIA3 | 메시지 변조 여부를 검증하는 무결성 보호 계열 |
| Null algorithm | NEA0 / NIA0 | 암호화 또는 무결성 보호를 적용하지 않는 특수 케이스. 실제망에서는 정책과 절차에 따라 매우 제한적으로 봐야 한다. |
| 경험 기반으로 보면 보안 실패 로그는 메시지 이름만 보면 단순해 보이지만, 원인은 UE capability, AMF 정책, gNB 설정, PDCP COUNT, Handover 키 파생까지 넓게 퍼질 수 있습니다. 그래서 “어느 구간 보안이 실패했는가”를 먼저 나누는 것이 중요합니다. NAS 실패인지, AS Security 활성화 실패인지, 활성화 이후 PDCP 처리 실패인지부터 구분해야 합니다. |
7. Handover와 Re-establishment에서의 보안
Part 10과 Part 11에서 본 Handover, RLF, RRC Re-establishment는 보안과도 깊게 연결됩니다.
UE가 Source gNB에서 Target gNB로 이동할 때 기존 보안 컨텍스트를 그대로 복사하듯 쓰면 위험할 수 있습니다.
그래서 5G는 Handover 과정에서 새로운 gNB 쪽 키를 파생하거나, NH/NCC 기반의 key chaining을 사용하여 보안 컨텍스트를 이어갑니다.
Re-establishment 상황에서도 UE와 네트워크가 같은 보안 컨텍스트를 보고 있는지가 중요합니다.
UE는 자신이 알고 있는 Cell ID, shortMAC-I, re-establishment cause 등을 이용해 복구를 시도하고, 네트워크는 해당 UE의 보안 컨텍스트를 확인해야 합니다.
이 과정이 맞지 않으면 RRC Reestablishment Reject, 재접속, 또는 Registration 재시도로 이어질 수 있습니다.
| 상황 | 보안 관점 | 로그 확인 포인트 |
| Intra-gNB mobility | 동일 gNB 내부 이동이면 보안 컨텍스트 변화가 상대적으로 작다. | RRC Reconfiguration, SpCell 변경, bearer 유지 여부 |
| Inter-gNB Handover | Target gNB에서 사용할 키 파생 및 컨텍스트 전달이 중요하다. | Handover Command, NCC, target cell RACH, Security context |
| RRC Re-establishment | 기존 보안 컨텍스트를 재사용할 수 있는지 확인해야 한다. | shortMAC-I, re-establishment cause, selected cell, reject 여부 |
| Resume from Inactive | 저장된 UE context와 security context가 유효해야 빠른 복귀가 가능하다. | I-RNTI, Resume ID, RRCResume, fallback to RRC Setup 여부 |
8. 실패 원인과 로그 분석 포인트
보안 관련 실패는 단말 로그에서는 SecurityModeReject, Authentication Failure, RRC Reestablishment Failure, Integrity check failure처럼 보일 수 있습니다.
하지만 현상 이름만 보고 원인을 단정하면 위험합니다. 아래처럼 절차별로 나눠 보는 것이 좋습니다.
자주 보이는 실패 원인
| 구간 | 가능한 원인 | 확인 방법 |
| Authentication | USIM/가입자 정보 불일치, 인증 벡터 문제, SQN 관련 문제 | Authentication Failure cause, AMF/AUSF/UDM 로그 확인 |
| NAS Security | UE capability와 AMF 선택 알고리즘 불일치, NAS MAC 검증 실패 | NAS Security Mode Command/Reject, selected algorithm 확인 |
| AS Security | gNB securityAlgorithmConfig 오류, KgNB 전달 문제, UE capability mismatch | RRC SecurityModeCommand, SecurityModeFailure, Initial Context Setup 확인 |
| PDCP | COUNT mismatch, bearer 설정 불일치, 재수립 과정의 상태 불일치 | PDCP SN/HFN, SRB/DRB별 ciphering 적용 시점 확인 |
| Handover | Target gNB 보안 컨텍스트 누락, NCC 불일치, Handover Command 이후 RACH 실패 | HO preparation, HO command, target RACH, RRCReconfigurationComplete 확인 |
로그 분석 시 체크 포인트
- Registration 단계: Authentication Request/Response가 정상적으로 끝났는지 확인합니다.
- NAS 보안: NAS Security Mode Command에서 선택된 ciphering/integrity 알고리즘을 봅니다.
- UE Capability: UE가 지원한다고 보고한 security capability와 네트워크가 선택한 알고리즘이 맞는지 확인합니다.
- AS 보안: RRC SecurityModeCommand 이후 SecurityModeComplete가 정상적으로 올라오는지 확인합니다.
- PDCP: 보안 활성화 이후 SRB/DRB의 COUNT, SN, HFN, direction이 어긋나지 않았는지 봅니다.
- Handover: Source/Target gNB 사이 보안 컨텍스트 전달과 Target Cell RACH 성공 여부를 함께 봅니다.
- Re-establishment: shortMAC-I, re-establishment cause, selected cell, reject 원인을 확인합니다.
| 주의할 점 보안 로그는 일부 필드가 암호화되거나 마스킹되어 보일 수 있습니다. 따라서 단말 로그 하나만으로 단정하기보다, 가능하면 UE 로그, gNB 로그, AMF 로그를 같은 시간축에 맞춰 비교하는 것이 좋습니다. |
9. 실무 관점으로 보는 전체 흐름
Part 5에서 본 Registration, Part 6의 PDU Session, Part 9의 DRB 설정을 보안 관점으로 다시 이어보면 아래처럼 정리됩니다. RRC Setup은 출입문을 여는 단계에 가깝고, Registration과 Authentication은 신분 확인, NAS Security는 코어망과의 제어 메시지 보호, AS Security는 무선 접속 구간 보호, DRB Setup은 실제 데이터 통로 개통이라고 볼 수 있습니다.
RRC Setup
↓
NAS Registration Request
↓
Authentication
↓
NAS Security Mode Command / Complete
↓
Initial Context Setup with UE Security Context
↓
RRC SecurityModeCommand / Complete
↓
RRC Reconfiguration with SRB/DRB configuration
↓
PDCP ciphering/integrity applied
↓
PDU Session user data transfer10. 3GPP 공식 참고자료
아래 문서는 3GPP 공식 사이트에서 확인할 수 있는 규격입니다.
- 3GPP TS 33.501 - Security architecture and procedures for 5G System
- 3GPP TS 24.501 - Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3
- 3GPP TS 38.331 - NR; Radio Resource Control (RRC); Protocol specification
- 3GPP TS 38.323 - NR; Packet Data Convergence Protocol (PDCP) specification
- 3GPP TS 38.300 - NR; NR and NG-RAN Overall description; Stage 2
11. FAQ
일반적인 Registration 흐름에서는 인증 이후 NAS Security가 먼저 활성화되고, 그 다음 AMF가 gNB에 보안 컨텍스트를 전달한 뒤 AS Security가 활성화됩니다.
Q2. RRC Setup 메시지는 암호화되어 있나요?
초기 RRC Setup 단계는 아직 AS Security가 활성화되기 전입니다. 이후 RRC SecurityModeCommand/Complete가 끝난 뒤 RRC signaling 보호가 본격적으로 적용됩니다.
Q3. PDCP는 왜 보안 설명에서 자주 나오나요?
PDCP가 RRC signaling과 user plane 데이터에 대해 ciphering과 integrity protection을 실제로 적용하는 계층이기 때문입니다.
Q4. Handover 실패가 보안 문제일 수도 있나요?
가능합니다. Target gNB의 보안 컨텍스트, key derivation, NCC, PDCP 상태가 맞지 않으면 Handover 이후 메시지 처리나 데이터 복호화에서 문제가 생길 수 있습니다.
Q5. NEA0이나 NIA0은 항상 문제인가요?
이름 그대로 null 알고리즘이므로 실제망에서는 정책과 절차를 매우 신중하게 봐야 합니다. 테스트 환경에서는 보일 수 있지만, 상용망 분석에서는 왜 선택되었는지 반드시 확인해야 합니다.
Q6. Security Mode Failure가 보이면 어디부터 봐야 하나요?
NAS인지 AS인지 먼저 나누고, 그 다음 UE security capability, 선택 알고리즘, 키 컨텍스트, MAC 검증 실패 여부를 순서대로 확인하는 것이 좋습니다.
| 다음 Part 예고 Part 14에서는 보안이 적용된 이후 실제 사용자 데이터가 어떻게 흐르는지 더 깊게 들어가, PDCP, RLC, MAC 계층의 데이터 처리와 재전송/분할/스케줄링 관계를 정리하면 자연스럽게 이어집니다. |
'Wireless > Protocol' 카테고리의 다른 글
| [Protocol] 5G NR Fundamental - Part 15 (0) | 2026.05.28 |
|---|---|
| [Protocol] 5G NR Fundamental - Part 14 (1) | 2026.05.27 |
| [Protocol] 5G NR Fundamental - Part 12 (0) | 2026.05.25 |
| [Protocol] 5G NR Fundamental - Part 11 (0) | 2026.05.24 |
| [Protocol] 5G NR Fundamental - Part 10 (0) | 2026.05.21 |