KR102544113B1

KR102544113B1 - 5g 코어 시스템의 네트워크 기능 인증 방법

Info

Publication number: KR102544113B1
Application number: KR1020200084906A
Authority: KR
Inventors: 정지영; 김세훈; 정성택; 조원창; 한기준
Original assignee: 주식회사 케이티
Priority date: 2020-07-09
Filing date: 2020-07-09
Publication date: 2023-06-14
Also published as: KR20220006908A

Abstract

5G 코어 시스템에서 네트워크 기능(Network Function, NF) 장치의 인증 방법이 제공된다. 이 방법은 통신 네트워크의 네트워크 기능(Network Function, NF) 장치에서 수행하는 인증 방법으로서, 공급자인 제1 NF 장치가 소비자인 제2 NF 장치로부터 서비스 요청 메시지를 수신하는 단계, 상기 서비스 요청 메시지로부터 상기 제2 NF 장치의 인증 토큰을 획득하는 단계, 상기 제2 NF 장치의 ID와 상기 인증 토큰을 포함하는 NF 검증 요청 메시지를 NF 인증 장치에게 전송하는 단계, 그리고 상기 NF 인증 장치로부터 NF 검증 성공 응답 메시지가 수신되면, 상기 제2 NF 장치에게 서비스 요청을 수락하는 서비스 응답 메시지를 전송하는 단계를 포함하고, 상기 NF 검증 성공 응답 메시지는, 상기 NF 인증 장치에 의해 상기 제2 NF 장치의 ID와 상기 인증 토큰이 맵핑 등록되어 있는 경우로 확인되면, 상기 NF 인증 장치로부터 상기 제1 NF 장치에게 전달된다.

Description

5G 코어 시스템의 네트워크 기능 인증 방법{AUTHENTICATION METHOD OF NETWORK FUNCTION IN 5G CORE SYSTEM}

본 발명은 5G 코어 시스템의 네트워크 기능 인증 방법에 관한 것이다.

LTE(Long Term Evolution) 코어 시스템과 5G NSA(Non Stand Alone) 코어 시스템은 RPA(Reference Point Architecture) 구조를 사용한다. RPA 구조는 코어 시스템을 구성하는 네트워크 장비 간에 고유의 인터페이스로 통신하도록 되어 있다.

LTE 코어 시스템을 구성하는 네트워크 장비는 NE(Network Entities)로 명명하며, 모든 NE 간에는 별도의 P2P(peer-to-peer network) 인터페이스로 통신하도록 되어 있다. 예를들어, LTE에서 PGW(PDN Gateway)-PCRF(Policy and Charging Rule Function) 간 통신을 위해서는 Diameter(Gx) 인터페이스가 정의되어 있다.

5G NSA 코어 시스템을 구성하는 네트워크 장비 역시 NE로 명명하며, 모든 NE 간에는 특정 프로토콜 기반의 독립된 인터페이스가 사용된다. 특정 프로토콜은 HTTPS(HyperText Transfer Protocol over Secure Socket Layer)가 사용된다. 예를들어, 5G SMF(Session Management Function)-PCF(Policy Control Function) 간에는 N7 인터페이스로 통신하도록 되어있다.

이처럼, RPA 구조는 특정 기능 제공을 위해 연동이 필요한 모든 GW(GateWay), NE간에 P2P 인터페이스를 정의해야 한다. 따라서, 신규 기능의 빠른 도입을 저해하고, 네트워크 관리의 효율성을 저하시키는 단점이 있다. 이러한 단점을 보완하고자 5G 표준에서는 SBA(Service-Based Architecture) 구조를 정의하였다.

SBA 구조를 사용하는 5G SA 코어 시스템의 네트워크 장비는 NF(Network Functions)로 명명하며, 모든 NF는 메시지 버스(Message Bus) 방식의 공통(또는 단일) 인터페이스로 통신한다. 각 NF는 서비스 제공자(Service Provider) 및 서비스 사용자(Service Consumer)로서 동작할 수 있다. 서비스 제공자로 동작하는 NF는 특정 서비스 제공을 위한 정보를 단일 인터페이스를 통해 서비스 사용자인 NF에게 제공하고, 서비스 사용자인 NF는 해당 정보를 통해 사용자가 특정 서비스를 사용할 수 있게 한다. 이러한 SBA 구조는 새로운 서비스 확장이 가능하고, 3rd party NF간 연동을 보다 편리하게 지원 가능하며, ICT(Information communication Technology) 시스템 및 Cloud 환경에서 소프트웨어 기술의 장점을 보다 효율적으로 활용 가능하다.

그런데, RPA 구조에서는 NE간 사전에 정의/협의된 인터페이스를 통해 통신을 하기 때문에 신규 NE의 악의적인 접속 시도를 원천 차단할 수 있어 보안 이슈가 없다. 즉, NE들은 상호 간에 다른 NE의 정보를 사전에 등록하고 사전 정의/협의된 인터페이스를 통해 서비스 요청(Service Request)을 전송하고 서비스 응답(Service Response)을 수신한다. 만약, 등록되지 않은 제1 NE가 악의적으로 제2 NE에 접속하려고 하더라도 제2 NE에 제1 NE는 등록되어 있지 않으므로, 통신이 불가능하다. 즉, 제1 NE의 악의적인 접속 시도를 원천적으로 차단할 수 있으므로, 보안 이슈가 없다.

그러나, SBA 구조에서는 NRF(Network Repository Function)가 제공하는 NF 정보를 기반으로 통신하기 때문에 특정 NF가 NRF로부터 제공받은 정보를 악의적인 NF가 절취하여 접속을 시도하더라도, 악의적인 NF의 요청인지 그 유효성을 판단할 수 없다. 따라서, NRF에 등록되지 않은 악의적 NF의 서비스 요청을 허용하게 되는 문제를 막을 수 없다.

본 발명이 해결하고자 하는 과제는 SBA(Service-Based Architecture) 구조를 사용하는 5G SA 코어 시스템에서 NRF와 독립된 별도의 NF 인증 장치가 인증 토큰을 이용하여 서비스를 요청한 NF의 무결성을 검증함으로써, NF 간 보안 통신을 보장할 수 있는 NF 인증 방법을 제공하는 것이다.

본 발명의 한 실시예에 따르면, 통신 네트워크의 네트워크 기능(Network Function, NF) 장치에서 수행하는 인증 방법으로서, 제1 NF 장치가 제2 NF 장치로부터 서비스 요청 메시지를 수신하는 단계, 상기 서비스 요청 메시지로부터 상기 제2 NF 장치의 인증 토큰을 획득하는 단계, 상기 제2 NF 장치의 ID와 상기 인증 토큰을 포함하는 NF 검증 요청 메시지를 NF 인증 장치에게 전송하는 단계, 그리고 상기 NF 인증 장치로부터 NF 검증 성공 응답 메시지가 수신되면, 상기 제2 NF 장치에게 서비스 요청을 수락하는 서비스 응답 메시지를 전송하는 단계를 포함하고, 상기 NF 검증 성공 응답 메시지는, 상기 NF 인증 장치에 의해 상기 제2 NF 장치의 ID와 상기 인증 토큰이 맵핑 등록되어 있는 경우로 확인되면, 상기 NF 인증 장치로부터 상기 제1 NF 장치에게 전달된다.

상기 NF 인증 장치에게 전송하는 단계 이후, 상기 NF 인증 장치로부터 NF 검증 실패 응답 메시지가 수신되면, 상기 제2 NF 장치에게 서비스 요청을 거절하는 서비스 응답 메시지를 전송하는 단계를 더 포함하고,

상기 NF 검증 실패 응답 메시지는, 상기 NF 인증 장치에 의해 상기 제2 NF 장치의 ID와 상기 인증 토큰이 맵핑 등록되어 있지 않은 경우로 확인되면, 상기 NF 인증 장치로부터 상기 제1 NF 장치에게 전달될 수 있다.

상기 제1 NF 장치 및 상기 제2 NF 장치는, 적어도 하나의 NF 서비스 절차를 수행하기 전에, 상기 NF 인증 장치에게 요청하여 인증 토큰을 발급받고,

상기 NF 서비스는, NF 프로파일 등록, NF 프로파일 갱신, NF 프로파일 등록 해지, NF 상태 가입, NF 상태 가입 해지 및 NF 디스커버리 중 적어도 하나를 포함할 수 있다.

상기 인증 토큰은, 상기 NF 인증 장치로부터 상기 제1 NF 장치 또는 상기 제2 NF 장치로 전송되고 동시에 네트워크 저장소 기능(Network Repository Function, NRF)으로 전송되며,

상기 NRF로 전송된 인증 토큰은, 상기 NRF에서 상기 제1 NF 장치 또는 상기 제2 NF 장치와 상기 NF 서비스 절차를 위한 NF 무결성 검증에 사용될 수 있다.

본 발명의 다른 특징에 따르면, 통신 네트워크의 네트워크 기능(Network Function, NF) 장치를 인증하는 방법으로서, NF 인증 장치가 공급자인 제1 NF 장치로부터 소비자인 제2 NF 장치의 인증 토큰이 포함된 NF 검증 요청 메시지를 수신하는 단계, 상기 제2 NF 장치의 인증 토큰이 상기 제2 NF 장치를 대상으로 발급된 인증 토큰인지 판단하는 NF 무결성 검증을 수행하는 단계, 그리고 상기 제2 NF 장치의 인증 토큰이 상기 제2 NF 장치를 대상으로 발급된 인증 토큰이면, NF 검증 성공 응답 메시지를 상기 제1 NF 장치에게 전송하는 단계를 포함하고, 상기 NF 검증 성공 응답 메시지는, 상기 제1 NF 장치가 상기 제2 NF 장치로부터 수신한 서비스 요청에 대하여 서비스 수락 응답 메시지를 전송하게 한다.

상기 NF 인증 장치는, NF 장치 들간에 공통의 통신 인터페이스로 통신하는 SBA(Service-Based Architecture) 기반의 5G 코어 시스템에서, 상기 공통의 통신 인터페이스에 연결될 수 있다.

상기 NF 검증 요청 메시지를 수신하는 단계 이전에, 상기 제2 NF 장치로부터 인증 토큰 발급 요청을 수신하는 단계, 상기 제2 NF 장치에게 인증 및 권한을 부여하는 인증 토큰을 발급하고, 발급한 인증 토큰을 상기 제2 NF 장치의 ID와 함께 맵핑하여 저장하는 단계, 그리고 상기 발급한 인증 토큰을 상기 제2 NF 장치에게 전송하는 단계를 더 포함하고, 상기 NF 무결성 검증은, 상기 NF 검증 요청 메시지에 포함된 인증 토큰이 유효한지와 상기 제2 NF 장치의 ID와 맵핑되는지 판단할 수 있다.

상기 제2 NF 장치에게 전송하는 단계 이후, 상기 발급한 인증 토큰을 네트워크 저장소 기능(Network Repository Function, NRF)에게 전송하는 단계를 더 포함하고, 상기 NRF로 전송된 인증 토큰은, 상기 제2 NF 장치의 요청에 따른 적어도 하나의 NF 서비스의 제공 여부를 결정하는데 사용될 수 있다.

상기 NRF에게 전송하는 단계는, 상기 제2 NF 장치의 ID 및 상기 발급한 인증 토큰을 포워딩하고, 상기 NRF는, 상기 제2 NF 장치로부터 상기 제2 NF 장치의 ID 및 상기 발급한 인증 토큰을 포함하는 NF 서비스 요청을 수신하고, 상기 제2 NF 장치의 ID 및 상기 발급한 인증 토큰이 상기 NF 인증 장치로부터 수신한 정보와 일치하는 경우, 상기 NF 서비스 요청을 처리할 수 있다.

실시예에 따르면, NF 인증을 통하여 NRF에 등록되지 않은 악의적 사용자의 서비스 요청을 차단할 수 있으므로, 보안 강화를 통해 네트워크의 안정적인 운영이 가능하다.

도 1은 SBA 구조를 사용하는 5G SA 코어 시스템을 나타낸다.
도 2는 도 1의 5G SA 코어 시스템에서의 NF 간 통신 절차를 나타낸다.
도 3은 본 발명의 실시예에 따른 NF 인증 시스템의 구조를 나타낸다.
도 4는 본 발명의 실시예에 따른 네트워크 기능 서비스 등록(NF service Registration) 절차를 나타낸다.
도 5는 본 발명의 실시예에 따른 네트워크 기능 서비스 업데이트(NF service update)를 나타낸다.
도 6은 본 발명의 실시예에 따른 네트워크 기능 등록 해제(NF service deregistration) 절차를 나타낸다.
도 7은 본 발명의 실시예에 따른 NFs 프로파일 상태 확인을 위한 가입(NF Status Subscribe) 절차를 나타낸다.
도 8은 본 발명의 실시예에 따른 NFs 프로파일 상태 확인 가입 해제(NF Status Unsubscribe) 절차를 나타낸다.
도 9는 본 발명의 실시예에 따른 NF 디스커버리(Discovery) 서비스 절차를 나타낸다.
도 10은 본 발명의 실시예에 따른 NF 간 상호 인증(Mutual Authentication between NFs) 절차를 나타낸다.
도 11은 본 발명의 한 실시예에 따른 NF의 인증 토큰 처리 동작을 나타낸 순서도이다.
도 12는 본 발명의 실시예에 따른 네트워크 장치의 하드웨어 구성을 나타낸 블록도이다.

아래에서는 첨부한 도면을 참고로 하여 본 발명의 실시예에 대하여 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나 본 발명은 여러가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시예에 한정되지 않는다. 그리고 도면에서 본 발명을 명확하게 설명하기 위해서 설명과 관계없는 부분은 생략하였으며, 명세서 전체를 통하여 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.

명세서 전체에서, 어떤 부분이 어떤 구성요소를 "포함" 한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있는 것을 의미한다.

또한, 명세서에 기재된 "…부", "…기", "…모듈" 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 이는 하드웨어나 소프트웨어 또는 하드웨어 및 소프트웨어의 결합으로 구현될 수 있다.

본 발명에서 설명하는 장치들은 적어도 하나의 프로세서, 메모리 장치, 통신 장치 등을 포함하는 하드웨어로 구성되고, 지정된 장소에 하드웨어와 결합되어 실행되는 프로그램이 저장된다. 하드웨어는 본 발명의 방법을 실행할 수 있는 구성과 성능을 가진다. 프로그램은 도면들을 참고로 설명한 본 발명의 동작 방법을 구현한 명령어(instructions)를 포함하고, 프로세서와 메모리 장치 등의 하드웨어와 결합하여 본 발명을 실행한다.

본 명세서에서 "전송 또는 제공" 은 직접적인 전송 또는 제공하는 것 뿐만 아니라 다른 장치를 통해 또는 우회 경로를 이용하여 간접적으로 전송 또는 제공도 포함할 수 있다.

본 명세서에서 단수로 기재된 표현은 "하나" 또는 "단일" 등의 명시적인 표현을 사용하지 않은 이상, 단수 또는 복수로 해석될 수 있다.

본 명세서에서 도면에 관계없이 동일한 도면번호는 동일한 구성요소를 지칭하며, "및/또는" 은 언급된 구성 요소들의 각각 및 하나 이상의 모든 조합을 포함한다.

본 명세서에서, 제1, 제2 등과 같이 서수를 포함하는 용어들은 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되지는 않는다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를들어, 본 개시의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다.

본 명세서에서 도면을 참고하여 설명한 흐름도에서, 동작 순서는 변경될 수 있고, 여러 동작들이 병합되거나, 어느 동작이 분할될 수 있고, 특정 동작은 수행되지 않을 수 있다.

명세서에서, 단말(User equipment, UE)은 접속망(Access Network)/무선 접속망(Radio Access network, RAN)의 기지국(gNB)에 접속하여 코어망(Core Network)의 네트워크 기능들(Network Functions, NFs)를 이용한다. 단말은 휴대 단말, IoT 단말, 차량 단말(vehicle), 디스플레이 단말, 방송 단말, 게임 단말 등 다양한 형태 및 용도의 단말일 수 있다. 네트워크를 구성하는 장치들은 하드웨어나 소프트웨어 또는 하드웨어 및 소프트웨어의 결합으로 구현될 수 있다. 네트워크 기능들 각각은 고유 기능을 수행하는 네트워크 장치/노드이고, 편의 상, "장치/노드"를 생략하여 부를 수 있다.

명세서에서 표준으로 정의된 네트워크 기능들에 대한 자세한 설명은 생략하고, 본 개시에 관련된 네트워크 기능들에 대해 자세히 설명한다.

도 1은 SBA(Service-Based Architecture) 구조를 사용하는 5G SA(Stand Alone) 코어 시스템을 나타낸다.

도 1을 참조하면, UE(10)는 RAN(Radio Access Network)(20)을 통하여 UPF(User Plane Function)(30)에 접속하고, UPF(30)를 통하여 DN(Data Network)(40)에 접속할 수 있다. RAN(20)은 무선 및 유선 액세스 네트워크를 나타낸다. UPF(30)는 DN(40)에 대한 패킷 데이터 유닛(Packet Data Unit, PDU) 세션의 접속, 패킷 라우팅과 포워딩, QoS(Quality of Service) 처리 등의 기능을 지원한다. DN(40)은 UE(10)가 접속하는 네트워크를 의미한다. PDU는 UE와 DN 사이에 교환되는 데이터를 의미한다.

UE(10)는 접속 및 이동성 관리 기능(Access and Mobility Management Function, AMF)과 N1 인터페이스로 연결된다. RAN(20)은 AMF와 N2 인터페이스로 연결되고, UPF(30)와 N3 인터페이스로 연결된다. UPF(30)는 세션 관리 기능(Session Management Function, SMF)와 N4 인터페이스로 연결되고 DN(40)과 N6 인터페이스로 연결된다.

5G SA 코어 시스템은 가상화 등을 고려하여 논리적인 기능 단위로 설계되어 있다. 5G SA 코어 시스템을 구성하는 네트워크 장치는 네트워크 기능(Network Functions, NF)으로 명명하며, 모든 NF(50)는 메시지 버스 기반의 공통 인터페이스로 통신한다. NF들 각각은 고유 기능을 수행하는 네트워크 장치/노드이고, 편의 상, "장치/노드"를 생략하여 부를 수 있다.

NF는 네트워크의 타입에 따라 상이한 네트워크 요소들을 포함할 수 있다. 5G 시스템의 NF는 AMF, SMF, 가입자 인증 기능(Authentication Server Function, AUSF), 통합 데이터 관리 기능(Unified Data Management, UDM), 정책 제어 기능(Policy Control Function, PCF), 응용 기능(Application Function, AF), 네트워크 노출 기능(Network Exposure function, NEF), 네트워크 저장소 기능(Network Repository Function, NRF) 및 네트워크 슬라이스 선택 기능(Network Slicing Selection Function, NSSF)을 포함할 수 있다.

AMF는 UE(10)가 DN(40)으로부터 서비스를 제공 받을 있도록 등록 관리, 연결관리 그리고 이동성 관리 기능 등을 지원한다. SMF는 세션 관리, IP(Internet Protocol) 주소 할당, UPF(User Plane Function) 선택 및 제어 등의 기능을 지원한다. AUSF는 인증 서버 기능을 지원한다. UDM은 사용자 식별 처리, 가입정보 관리 등의 기능을 지원한다. PCF는 통합 정책 프레임워크, 정책 규칙 제공 등의 기능을 지원한다. AF는 트래픽 라우팅 조정, NEF 액세스 등의 기능을 지원한다. NEF는 네트워크 기능을 외부에 개방하는 기능을 지원한다. NRF는 NF 인스턴스 검색 기능, NF 인스턴스의 프로파일 관리 기능 등을 지원한다. NSSF는 네트워크 슬라이스 인스턴스의 선택 기능과, AMF의 결정 기능 등을 지원한다.

각 NF는 상호 통신하는 관계에서, 서비스 제공자(Service Provider)와 서비스 사용자(Service Consumer)가 된다. 서비스 제공자는 특정 서비스 제공을 위한 정보를 단일 인터페이스를 통해 서비스 사용자(Service Consumer)에게 제공하고, 서비스 사용자는 해당 정보를 통해 사용자 단말을 위한 특정 서비스를 사용할 수 있게 한다.

AMF, SMF, PCF, AF, NSSF, AUSF, UDM, NEF는 서비스 사용자 또는 서비스 제공자로서 역할을 수행한다. NRF는 서비스 사용자로서 동작하는 NF의 요청에 따라 서비스 제공자로서 동작하는 NF를 찾아주는 디스커버리(Discovery) 역할을 수행한다. 예를들어, 세션 생성을 위한 절차에서 AMF는 UDM으로부터 가입자 프로파일을 가져와야 한다. 이때, AMF는 서비스 사용자로서 동작하고 UDM은 서비스 제공자로서 동작하며, NRF는 AMF에게 UDM의 정보를 제공하여 AMF와 UDM의 상호 통신할 수 있게 한다.

SBA에서 NF 간 인터페이스 또는 서비스-기반 인터페이스(SBI, Service-Based Interface)는 NF에 의해 제공되는/노출되는 서비스의 세트를 나타내며, 제어 평면 내에서 사용된다. 서비스-기반 인터페이스를 설명하면, 다음과 같다.

Namf: AMF에 의해 공개된(exhibited) 서비스-기반 인터페이스

Nsmf: SMF에 의해 공개된 서비스-기반 인터페이스

Nnef: NEF에 의해 공개된 서비스-기반 인터페이스

Npcf: PCF에 의해 공개된 서비스-기반 인터페이스

Nudm: UDM에 의해 공개된 서비스-기반 인터페이스

Naf: AF에 의해 공개된 서비스-기반 인터페이스

Nnrf: NRF에 의해 공개된 서비스-기반 인터페이스

Nausf: AUSF에 의해 공개된 서비스-기반 인터페이스

Nnssf: NSSF에 의해 공개된 서비스-기반 인터페이스

NF 서비스는 NF(즉, NF 서비스 공급자)에 의해 다른 NF(즉, NF 서비스 소비자)에게 서비스-기반 인터페이스를 통해 노출되는 능력의 일종이다. NF는 하나 이상의 NF 서비스(들)을 노출할 수 있다.

그런데, SBA 구조에서는 보안 이슈 문제가 있다. 이에 대해 설명하면, 도 2와 같다.

도 2는 도 1의 5G SA 코어 시스템에서의 NF 간 통신 절차를 나타낸다.

즉, 도 2는 3GPP(The 3rd Generation Partnership Project) 표준에 정의된 NF 간 통신 절차를 나타낸다.

도 2를 참조하면, SBA 시스템 구조에서 정상적인 NF들, 즉, NF #1, NF #2는 NRF에 사전 등록(S101, S103, S105)되어 있다.

소비자인 NF #1이 NRF로 NF 디스커버리 요청(NF Discovery Request)을 전송(S107)한다.

NRF는 서비스 제공자인 NF #2의 정보를 포함한 NF 디스커버리 응답(NF Discovery Response)을 NF #1에게 전송한다(S109).

NF #1은 NRF로부터 수신한 NF #2의 정보를 이용하여 NF #2에게 서비스 요청 메시지(Service Request Message)를 전송(S111)하고 서비스 응답 메시지(Service Response Message)를 수신한다(S113).

이때, 소비자인 NF #3, 즉, NRF에 등록되지 않은 악의적 사용자인 NF #3가 NF #1이 NRF로부터 제공받은 NF #2의 정보를 절취하여 NF #2에게 서비스 요청 메시지를 전송(S115)하더라도, NF #2는 NF #3가 악의적인 사용자인지를 판단할 수 없다. 그러므로 NF #2는 NF #1에게 전송한 것과 마찬가지로 서비스 응답 메시지를 NF #3에게 전송한다(S117).

이처럼, SBA 구조에서는 NF간 사전 정의/협의된 인터페이스가 아닌 NRF가 제공하는 NF 서비스 정보를 기반으로 통신하기 때문에 악의적인 접속 시도시 NF 요청에 대한 유효성을 판단할 수 없어 보안 이슈가 발생한다.

보안 이슈로는 NF의 가용성 손실이 있다. NF 공격자에 의해 SBI의 다중 인증 실패, 다중 도메인 네임 시스템(Domain Name System, DNS) 조회 등 특정 NF의 DOS(Denial of Service)를 초래할 수 있으며, 잘못된 형식의 패킷 전송으로 NF의 버퍼 오버플로우 문제가 발생할 수 있다.

보안 이슈로는 NF의 신뢰성 손실이 있다. NF 공격자에 의해 SBI의 민감한 데이터 도청이 가능하고, NF의 민감한 데이터에 무단 접속하여 고객 정보가 유출될 수 있다.

보안 이슈로는 NF의 무결성 손실이 있다. NF 공격자에 의해 NF간 통신 정보가 수정될 수 있고, NF에 무단으로 접속하여 악성 코드 설치가 가능하고, NF의 데이터 수정을 초래할 수 있으며, NF 공격자에 의해 OA&M(Operations, Administration, and Management) 인터페이스를 통해 NF를 손상시킬 수 있다.

이러한 보안 이슈를 해결하기 위하여, 본 발명의 실시예는 5G SBA 시스템에서 보안 강화를 위한 NF 인증 구조를 제시한다.

NF 인증 구조에서는 비표준 장비인 NF 인증 및 권한 기능(NF Authentication and Authorization Function, NAAF)을 사용하여 NF 통신의 보안을 강화함으로써, 네트워크의 안정적인 운영을 도모할 수 있다.

NRF(200)는 5G SA 코어 시스템의 모든 NF 간의 상호 연동을 지원하는 장비로 인증키 발급/관리 및 NF간 유효성 판단 기능 등이 수용되기에는 시스템의 복잡도 및 부하 문제 등이 발생할 수 있다. 따라서, NF 무결성 검증을 위한 전용 장비로서 NAAF(100)라는 5G 비표준 장비를 새로 정의하여 무결성 검증을 수행한다.

NAAF를 이용한 NF 인증 시스템에 대하여 설명하면, 다음과 같다.

도 3은 본 발명의 실시예에 따른 NF 인증 시스템의 구조를 나타낸다.

이때, 도 3은 도 1의 5G SA 코어 시스템에서, NF 인증 시스템에 포함되는 구성만을 간략히 도시하였다.

도 3을 참조하면, NF 인증 시스템은 메시지 버스로 통신하는 NAAF(100), NRF(200) 및 NF(300)을 포함한다. NF(300)는 NSSF, AUSF, UDM, NEF, NRF, AMF, SMF, PCF, AF를 포함한다. 물론, NAAF(100), NRF(200)도 NF(300)에 포함되는 것이 일반적이지만, 본 발명의 실시예에서 NF(300)는 NF 인증 대상으로 정의하고, NAAF(100)와 NRF(200)는 NF 인증 주체로 정의한다.

NAAF(100)는 NF 인증 장치라고 할 수 있으나, NAAF로 통칭하여 기재한다.

NAAF(100)는 NRF(200)와 독립된 별개의 장비로서, NF(300)의 요청에 따라 NF(300)에게 인증 토큰을 발급하고, NF 서비스 절차가 이루어질때마다 NF(300)가 제공한 인증 토큰을 기초로 NF(300)의 무결성을 검증한다.

NRF(200)는 네트워크 내 각 노드들에 대한 정보를 관리/제어하는 기능으로서, NF 서비스 관리와 NF 서비스 디스커버리 기능을 지원한다.

이때, NRF(200)는 NF(300)와 통신할 때, NF(300)가 제공한 인증 토큰을 이용하여 NF(300)의 무결성을 검증한 후, NF(300)가 요청한 NF 서비스를 제공할지 여부를 결정한다. 이에 대해서는 도 4 내지 도 9를 참고로 설명한다.

표 1은 3GPP TS(Technical Specifications) 23.502 문서에 정의된 NRF에 의해 제공되는 서비스들을 나타낸다.

서비스명(Service Name)	서비스 동작(Service Operations)	동작 시맨틱(Operation Semantics)	소비자 예시(Example Consumer(s))
NF 관리(Nnrf_NFManagement)	NFRegister	Request/Response	AMF, SMF, UDM, AUSF, NEF, PCF, SMSF, NSSF
	NFUpdate	Request/Response	AMF, SMF, UDM, AUSF, NEF, PCF, SMSF, NSSF
	NFDeregister	Request/Response	AMF, SMF, UDM, AUSF, NEF, PCF, SMSF, NSSF
	NFStatusSubscribe	Subscribe/Notify	AMF, SMF, PCF, NEF, NSSF, SMSF, AUSF
	NFStatusNotify		AMF, SMF, PCF, NEF, NSSF, SMSF, AUSF
	NFStatusUnSubscribe		AMF, SMF, PCF, NEF, NSSF, SMSF, AUSF
NF 디스커버리(Nnrf_NFDiscovery)	Request	Request/Response	AMF, SMF, PCF, NEF, NSSF, SMSF, AUSF

표 1의 NRF가 제공하는 NF 서비스들은 크게 NF 관리와 NF 디스커버리를 포함한다. 이러한 NF 서비스 절차에 대해 도면을 참고하여 설명한다.

이때, 도면에서는 기본적으로 표준에 정의된 NF 서비스 절차를 나타내나, "인증 토큰 발급 절차"와 "인증 토큰을 기초로 NF 서비스 제공 여부를 판단하는 절차"가 추가되었다.

도 4는 본 발명의 실시예에 따른 네트워크 기능 서비스 등록(NF service Registration) 절차를 나타낸다.

도 4를 참조하면, 소비자(Consumer)인 NF(300)는 NAAF(100)로 인증 토큰 발급 요청을 전송한다(S201).

NAAF(100)는 NF(300)에게 인증 및 권한을 부여하는 인증 토큰을 발급한다(S203). 이때, NAAF(100)는 NF(300)의 식별자(ID)와 발급한 인증 토큰들을 맵핑하여 저장한다.

NAAF(100)는 발급한 인증 토큰을 NF(300)에게 전송한다(S205). 그러면, NF(300)는 수신한 인증 토큰을 저장한다(S207).

NAAF(100)는 S205 단계에서 전송한 토큰들과 동일한 인증 토큰 및 그 인증 토큰을 발급받은 NR(300)의 식별자(ID)를 NRF(200)에게 포워딩한다(S209). NRF(200)는 NF의 식별자(ID)와 인증 토큰을 맵핑하여 등록한다(S211).

NF(300)는 NF 프로파일을 NRF(200)에 등록하기 위한 NF 서비스 등록 요청(Nnrf_NFManagement_NFRegister Request) 메시지를 NRF(200)로 전송한다(S213). 이때, NF 서비스 등록 요청 메시지는 NF 프로파일, NF 유형, NF ID, NF 서비스 등의 정보를 포함하고, 추가로 S207 단계에서 저장한 인증 토큰을 포함한다.

여기서, NF 프로파일은 NF 인스턴스 식별자(identifier)(ID), NF 타입, 공중 육상 이동 네트워크(Public Land Mobile Network)(PLMN) ID, 네트워크 슬라이스 관련 식별자(들), NF의 전체 자격 도메인 명칭(Fully Qualified Domain Name)(FQDN) 또는 IP 어드레스, NF 용량 정보, 지원된 서비스들의 명칭들, 각각 지원된 서비스의 인스턴스(들)의 엔드포인트 정보 등을 포함할 수 있다.

NRF(200)는 S213 단계에서 수신한 인증 토큰이 S211 단계에서 등록한 인증토큰과 일치하는지 판단하는 NF 무결성 검증을 수행한다(S215). 여기서, NF 무결성 검증은 인증 토큰이 정당하게 발급된 것인지 판단하는 인증 토큰 자체의 유효성 검증 뿐만 아니라 정당한 사용자에게 발급된 인증 토큰인지, 즉, 인증 토큰에 맵핑된 ID를 가진 NF인지 판단하는 사용자 검증을 포함한다.

NF 무결성 검증이 성공적으로 완료되면, NRF(200)는 S213 단계에서 수신한 NF 프로파일을 등록한다(S217). 이어서, NRF(200)는 NF 등록이 승인되었음을 나타내는 NF 서비스 등록 응답(Nnrf_NFManagement_NFRegister Response) 메시지를 NF(300)에게 전송한다(S219).

만약, S215 단계에서 NF 무결성 검증에 실패하면, S217 단계는 수행되지 않고 S219 단계에서는 NF 등록이 실패하였음을 나타내는 메시지를 전송할 수 있다.

도 5는 본 발명의 실시예에 따른 네트워크 기능 서비스 업데이트(NF service update)를 나타낸다.

이때, 도 4에서 설명한 내용과 중복되는 부분의 설명은 생략한다.

도 5를 참조하면, 소비자인 NF(300)는 NF 프로파일이 업데이트되면, 예를들어, 업데이트된 성능(updated capacity)을 NRF(200)에 알릴 수 있다.

이때, NF(300)는 NRF(200)에게 업데이트된 NF 프로파일을 등록하기에 앞서, NAAF(100)로 인증 토큰 발급 요청을 전송한다(S301).

NAAF(100)는 NF(300)에게 인증 및 권한을 부여하는 인증 토큰을 발급한다(S303). 이때, NAAF(100)는 NF(300)의 식별자(ID)와 발급한 인증 토큰을 맵핑하여 저장한다.

NAAF(100)는 발급한 인증 토큰을 NF(300)에게 전송한다(S305). 그러면, NF(300)는 수신한 인증 토큰을 저장한다(S307).

NAAF(100)는 S305 단계에서 NF(300)에게 전송한 인증 토큰과 그 인증 토큰을 발급받은 NF의 식별자(ID)를 NRF(200)에게 포워딩한다(S309). NRF(200)는 S309 단계에서 수신한 NF 식별자(ID)와 인증 토큰을 맵핑하여 등록한다(S311).

NF(300)는 업데이트된 NF 프로파일을 등록하기 위한 NF 서비스 업데이트 요청(Nnrf_NFManagement_NFUpdate Request) 메시지를 NRF(200)로 전송한다(S313). 이때, NF 서비스 업데이트 요청 메시지는 업데이트된 NF 프로파일, NF 유형, NF ID, NF 서비스 등의 정보를 포함하고, 추가로 S307 단계에서 저장한 인증 토큰을 포함한다.

NRF(200)는 S313 단계에서 수신한 인증 토큰이 S311 단계에서 등록한 인증 토큰과 일치하는지 판단하는 NF 무결성 검증을 수행한다(S315).

NF 무결성 검증이 성공적으로 완료되면, NRF(200)는 S313 단계에서 수신한 업데이트된 NF 프로파일을 등록한다(S317). 이어서, NRF(200)는 NF 프로파일 업데이트가 승인되었음을 나타내는 NF 서비스 업데이트 응답(Nnrf_NFManagement_NF Update) 메시지를 NF(300)에게 전송한다(S319).

만약, S315 단계에서 NF 무결성 검증에 실패하면, S317 단계는 수행되지 않고 S319 단계에서는 NF 등록이 실패하였음을 나타내는 메시지를 전송할 수 있다.

도 6은 본 발명의 실시예에 따른 네트워크 기능 등록 해제(NF service deregistration) 절차를 나타낸다.

이때, 도 4 및 도 5에서 설명한 내용과 중복되는 부분의 설명은 생략한다.

도 6을 참조하면, 소비자인 NF(300)는 NF 프로파일의 등록을 해제할 수 있다. 이때, NF(300)는 NRF(200)에게 NF 등록 해제를 요청하기에 앞서, NAAF(100)로 인증 토큰 발급 요청을 전송한다(S401).

NAAF(100)는 NF(300)에게 인증 및 권한을 부여하는 인증 토큰을 발급한다(S403). 이때, NAAF(100)는 NF의 식별자(ID)와 발급한 인증 토큰을 맵핑하여 저장한다.

NAAF(100)는 발급한 인증 토큰을 NF(300)에게 전송한다(S405). 그러면, NF(300)는 수신한 인증 토큰을 저장한다(S407).

NAAF(100)는 NF(300)에게 전송(S405)한 인증 토큰과 NF 식별자(ID)를 NRF(200)에게 포워딩한다(S409). 그러면, NRF(200)는 NF 식별자(ID)와 인증 토큰을 맵핑하여 등록한다(S411). 이때, NRF(200)는 NF의 식별자(ID)와 발급한 인증 토큰을 맵핑하여 저장한다.

NF(300)는 자신의 프로파일 등록 해제를 요청하는 NF 서비스 등록 해제 요청(Nnrf_NFManagement_NFDeregister Request) 메시지를 NRF(200)에게 전송한다(S413). 이때, NF 서비스 등록 해제 요청 메시지는 업데이트된 NF 프로파일, NF 유형, NF ID, NF 등록 해제 사유 등의 정보를 포함하고, 추가로 S407 단계에서 저장한 인증 토큰을 포함한다.

NRF(200)는 S413 단계에서 수신한 인증 토큰이 S411 단계에서 등록한 인증 토큰과 일치하는지 판단하는 NF 무결성 검증을 수행한다(S415).

NF 무결성 검증이 성공적으로 완료되면, NRF(200)는 등록 해제 요청된 NF 프로파일을 삭제한다(S417). 이어서, NRF(200)는 NF 프로파일 등록 해제가 승인되었음을 나타내는 NF 서비스 등록 해제 응답(Nnrf_NFManagement_NFDeregister Response) 메시지를 NF(300)에게 전송한다(S419).

도 7은 본 발명의 실시예에 따른 NF 프로파일 상태 확인을 위한 가입(NF Status Subscribe) 절차를 나타낸다.

이때, 도 4, 도 5 및 도 6에서 설명한 내용과 중복되는 부분의 설명은 생략한다.

도 7을 참조하면, 소비자인 NF(300)는 N 다른 NF의 NF 프로파일 상태 정보에 대한 알림을 받을 수 있도록 NRF(200)로 상태 확인을 위한 가입(Subscribe)을 요청 할 수 있다. NF 프로파일 상태 확인을 위한 정보는 NF 서비스를 함께 사용할 새로운 NF 등록 정보, NF 프로파일 업데이트 정보, NF 프로파일 등록 해제 정보 등을 포함한다.

이때, NF(300)는 NRF(200)에게 상태 확인 가입을 요청하기에 앞서, NAAF(100)로 인증 토큰 발급 요청을 전송한다(S501).

NAAF(100)는 NF(300)에게 인증 및 권한을 부여하는 인증 토큰을 발급한다(S503). 이때, NAAF(100)는 NF(300)의 식별자(ID)와 발급한 인증 토큰을 맵핑하여 저장한다.

NAAF(100)는 발급한 인증 토큰을 NF(300)에게 전송한다(S505). 그러면, NF(300)는 수신한 인증 토큰을 저장한다(S507).

NAAF(100)는 NF(300)에게 전송(S505)한 인증 토큰 및 그 인증 토큰을 발급받은 NF(300)의 식별자(ID)를 NRF(200)에게 포워딩한다(S509). 그러면, NRF(200)는 S509 단계에서 수신한 NF 식별자(ID)와 인증 토큰을 맵핑하여 등록한다(S511).

NF(300)는 NRF(200)에게 상태 가입 요청(Nnrf_NFManagement_NFStatusSubscribe) 메시지를 전송한다(S513). 이때, 상태 가입 요청 메시지는 서비스 대상 NF 유형, NF ID, NF 서비스 등의 정보와 더불어, S507 단계에서 저장된 인증 토큰을 포함한다.

NRF(200)는 S513 단계에서 수신한 인증 토큰이 S511 단계에서 등록한 인증토큰과 일치하는지 판단하는 NF 무결성 검증을 수행한다(S515).

NF 무결성 검증이 성공적으로 완료되면, NRF(200)는 S513 단계에서 수신한 NF 상태 가입 정보를 등록한다(S517).

만약, S515 단계에서 NF 무결성 검증에 실패하면, S517 단계는 수행되지 않는다. 즉, NRF(200)는 NF 무결성 검증에 실패하면, S513 단계에서 수신된 상태 가입 요청을 무시 또는 폐기할 수 있다.

도 8은 본 발명의 실시예에 따른 NF 프로파일 상태 확인 가입 해제(NF Status Unsubscribe) 절차를 나타낸다.

이때, 도 4, 도 5, 도 6 및 도 7에서 설명한 내용과 중복되는 부분의 설명은 생략한다.

도 8을 참조하면, 소비자 NF(300)는 NF 프로파일 상태 정보에 대한 알림을 더 이상 받지 않도록 NF 프로파일 상태 확인의 가입을 해제(Unsubscribe) 할 수 있다.

NF(300)는 NRF(200)에게 상태 확인 가입 해제를 요청하기에 앞서, NAAF(100)로 인증 토큰 발급 요청을 전송한다(S601).

NAAF(100)는 NF(300)에게 인증 및 권한을 부여하는 인증 토큰을 발급한다(S603). 이때, NAAF(100)는 NF(300)의 식별자(ID)와 발급한 토큰들을 맵핑하여 저장한다.

NAAF(100)는 S603 단계에서 발급한 인증 토큰을 NF(300)에게 전송한다(S605). 그러면, NF(300)는 수신한 인증 토큰을 저장한다(S607).

NAAF(100)는 NF(300)에게 전송(S605)한 인증 토큰과 그 인증 토큰을 발급받은 NF 식별자(ID)를 NRF(200)에게 포워딩한다(S609). 그러면, NRF(200)는 NF 식별자(ID)와 인증 토큰을 맵핑하여 등록한다(S611).

NF(300)는 NF 프로파일 상태 가입 해제 요청(Nnrf_NFManagement_NFStatusUnsubscribe Request) 메시지를 NRF(200)에게 전송한다(S613). 이때, 상태 가입 해제 요청 메시지는 서비스 대상 NF 유형, NF ID, NF 서비스 등의 정보와 더불어, S607 단계에서 저장된 인증 토큰을 포함한다.

NRF(200)는 S613 단계에서 수신한 인증 토큰이 S611 단계에서 등록한 인증 토큰과 일치하는지 판단하는 NF 무결성 검증을 수행한다(S615).

NF 무결성 검증이 성공적으로 완료되면, NRF(200)는 NF 상태 가입 등록을 해제한다(S617).

만약, S615 단계에서 NF 무결성 검증에 실패하면, S617 단계는 수행되지 않는다. 즉, NRF(200)는 NF 무결성 검증에 실패하면, S613 단계에서 수신된 상태 가입 해제 요청을 무시 또는 폐기할 수 있다.

도 9는 본 발명의 실시예에 따른 NF 디스커버리(Discovery) 서비스 절차를 나타낸다.

이때, 도 4, 도 5, 도 6, 도 7 및 도 8에서 설명한 내용과 중복되는 부분의 설명은 생략한다.

도 9를 참조하면, 소비자인 NF(300)는 특정 NF 서비스 또는 대상 NF 유형을 가진 NF 인스턴스(instance) 세트(Set) 혹은 특정 NF 서비스의 발견을 위한 NF 디스커버리 요청을 할 수 있다. 이때, NRF(200)에게 NF 디스커버리 요청을 전송하기에 앞서, NAAF(100)로 인증 토큰 발급 요청을 전송한다(S701).

NAAF(100)는 NF에게 인증 및 권한을 부여하는 인증 토큰을 발급한다(S703). 이때, NAAF(100)는 NF(300)의 식별자(ID)와 발급한 인증 토큰을 맵핑하여 저장한다.

NAAF(100)는 발급한 인증 토큰을 NF(300)에게 전송한다(S705). 그러면, NF(300)는 S705 단계에서 수신한 인증 토큰을 저장한다(S707).

NAAF(100)는 NF(300)에게 전송(S705)한 인증 토큰과 그 인증 토큰을 발급받은 NF(300)의 식별자(ID)를 NRF(200)에게 포워딩한다(S709).

NF(300)는 NF 디스커버리 요청(Nnrf_NFDiscovery_reqeust) 메시지를 NRF(200)로 전송한다(S713). 예를들어, NF(300)가 AMF일 경우, S713 단계에서 NF(300)는 동일한 PLMN에서 SMF 인스턴스를 검색하도록 요청할 수 있다.

이때, NF 디스커버리 요청 메시지는 요청(Required) 필드와 옵션(Optional) 필드를 포함한다. 요청 필드는 적어도 하나의 타겟 NF 서비스 명, 타겟 NF의 유형, NF 서비스 소비자의 NF 유형을 포함하고, 옵션 필드는 S-NSSAI(Network Slice Selection Assistance Information)(s), 타겟 NF ID, 타겟 PLMN ID, 서빙 PLMN ID, NF 서비스 소비자 ID를 포함하며, 타겟 ND는 SUPI, 데이터 셋 ID 등의 데이터 셋을 저장할 수 있다. 이때, 요청 필드는 추가로 S705 단계에서 발급받은 인증 토큰을 포함한다.

NRF(200)는 S713 단계에서 수신한 인증 토큰이 S711 단계에서 등록한 인증 토큰과 일치하는지 판단하는 NF 무결성 검증을 수행한다(S715).

NF 무결성 검증이 성공적으로 완료되면, NRF(200)는 디스커버리된 NF 인스턴스를 결정하고 디스커버리된 NF 인스턴스 세트에 대한 정보를 NF 디스커버리 응답(Nnrf_NFDiscovery_Response) 메시지를 통해 NF(300)에게 전송한다(S717).

이때, S717 단계에서 전송한 NF 디스커버리 응답 메시지에는 디스커버리된 NF 인스턴스의 정보를 포함하고, 대상 NF의 FQDN(Fully Qualified Domain Name) 또는 IP 주소를 포함할 수 있다.

이상 기술한 바와 같이, NF(300)와 NRF(200) 간에 이루어지는 NF 서비스 절차에서 NF(300)가 NAAF(100)로부터 발급받은 인증 토큰은 NRF(200)에게도 동일하게 포워딩된다. 따라서, NRF(200)는 NF(300)로부터 수신한 인증 토큰이 NAAF(100)로부터 수신한 인증 토큰과 일치할 때 NF(300)가 요청한 NF 서비스를 승인한다.

도 9에서 디스커버리 과정을 통해 획득한 NF 정보를 이용하여 NF 간에 서비스 절차가 진행되는데, 이때, 서비스 절차에는 인증 토큰을 이용한 NF 상호 인증(Mutual Authentication between NFs)이 추가된다. 이에 대하여 설명하면, 도 10과 같다.

도 10은 본 발명의 실시예에 따른 NF 간 상호 인증 절차를 나타낸다.

이때, 도 4, 도 5, 도 6, 도 7, 도 8 및 도 9에서 설명한 내용과 중복되는 부분의 설명은 생략한다.

도 10을 참조하면, 소비자 NF #1(301)은 NAAF(100)에게 인증 토큰 발급 요청을 전송한다(S801).

NAAF(100)는 NF #1(301)에게 인증 및 권한을 부여하는 인증 토큰을 발급한다(S803). 이때, NAAF(100)는 NF(301)의 식별자(ID)와 발급한 인증 토큰을 맵핑하여 저장한다.

NAAF(100)는 발급한 인증 토큰을 NF #1(301)에게 전송한다(S805). 그러면, NF #1(301)는 수신한 인증 토큰을 저장한다(S807).

NAAF(100)는 NF #1(301)에게 전송(S805)한 인증 토큰과 동일한 인증 토큰을 NRF(200)에게 포워딩한다(S809). 그러면, NRF(200)는 NF #1(301)의 식별자(ID)와 인증 토큰을 맵핑하여 등록한다(S811).

공급자(Producer) NF #2(303) 역시 마찬가지로 NAAF(100)에게 인증 토큰 발급 요청을 전송한다(S813).

NAAF(100)는 NF #2(303)에게 인증 및 권한을 부여하는 인증 토큰을 발급한다(S815). 이때, NAAF(100)는 NF #2(303)의 식별자(ID)와 발급한 인증 토큰을 맵핑하여 저장한다.

NAAF(100)는 발급한 인증 토큰을 NF #2(303)에게 전송한다(S817). 그러면, NF #2(303)는 수신한 인증 토큰을 저장한다(S819).

NAAF(100)는 NF #2(303)에게 전송(S817)한 인증 토큰과 그 인증 토큰을 발급받은 NF #2(3030)의 식별자(ID)를 NRF(200)에게 포워딩한다(S821). 그러면, NRF(200)는 NF #2(303)의 식별자(ID)와 인증 토큰을 맵핑하여 등록한다(S823).

이와 같이, NF #1(301)과 NF #2(303)는 각각 NAAF(100)로부터 인증 토큰을 발급받아 저장한다.

NF #1(301)이 특정 NF 서비스 정보를 요청하는 NF 디스커버리 요청(Nnrf_NFDiscovery_Request) 메시지를 NRF(200)에게 전송한다(S825).

NRF(200)는 S825 단계에서 수신한 NF 디스커버리 요청 메시지로부터 NF #1(301)의 인증 토큰을 추출하고, 추출한 인증 토큰이 S811 단계에서 등록된 인증 토큰과 일치하는지 판단하는 무결성 검증을 수행한다(S827).

S827 단계의 무결성 검증이 성공적으로 완료되면, NRF(200)는 타겟 NF인 공급자, 즉, NF #2(303)의 정보를 포함하는 NF 디스커버리 응답(Nnrf_NFDiscovery_Response) 메시지를 NF #1(301)에게 전송한다(S829). 이때, NF 디스커버리 응답 메시지는 NF #2(303)의 IP 주소 및 FQDN 정보를 포함할 수 있다.

NF #1(301)은 S829 단계에서 획득한 NF #2(303)의 정보를 토대로, NF #2(303)에게 서비스 요청(Service Request) 메시지를 전송한다(S831). 이때, 서비스 요청 메시지는 NF #1(301)의 인증 토큰을 포함한다.

NF #2(303)는 NF #1(301)의 무결성을 검증하기 위해, NAAF(100)로 NF #1(301)의 무결성 검증 요청(Request for NF #1 validation) 메시지를 전송한다(S833).

NAAF(100)는 S833 단계에서 수신한 NF #1(301)의 인증 토큰이 S803 단계에서 발급한 NF #1(301)의 인증 토큰과 동일한지 판단하는 무결성 검증을 수행(S835)한다.

NAAF(100)는 NF #2(303)에게 무결성 검증 결과를 포함하는 무결성 검증 응답(Response for NF #1 validation) 메시지를 전송한다(S837). 이때, 무결성 검증 응답 메시지는 무결성 검증 성공 또는 무결성 검증 실패를 포함할 수 있다.

NF #2(303)는 S837 단계에서 무결성 검증 성공 응답이 수신되면, NF #1(301)에게 서비스 승인을 위한 서비스 응답(Service Response Message(Access) 메시지를 전송한다(S839).

이와 같이, NF #2(303)는 서비스를 요청한 NF #1(301)의 무결성을 NAAF(100)를 통하여 확인한 후, 서비스 제공 여부를 결정한다.

이때, NAAF(100)로부터 인증 토큰을 발급받지 않고 NRF(200)에 등록되지 않은 악의적인 사용자인 NF #3(305)가 NF #1(301)로부터 NF #2(303)의 정보를 절취하여 NF #2(303)로 서비스 요청 메시지를 전송할 수 있다(S841). 이때, 서비스 요청 메시지는 NF #1(301)의 인증 토큰을 포함한다.

NF #2(303)는 NAAF(100)에게 NF #3(305)에 대한 검증 요청 메시지를 전송한다(S843). 이때, 검증 요청 메시지는 NF #3(305)의 식별자(ID) 및 NF #1(301)의 인증 토큰을 포함한다.

NAAF(100)는 NF #3(305)의 무결성 검증을 수행한다(S845). 그러나, NF #3(305)는 미등록된 사용자이므로, NF #3(305)의 식별자(ID)는 등록되어 있지 않고 N #3(305)가 제공한 인증 토큰은 NF #1(301)에게 발급된 것이므로 NF #3(305)의 식별자(ID)와 맵핑되지 않는다. 따라서, S843 단계에서 수신한 인증 토큰 자체는 유효하더라도, 인증 토큰의 발급자인 NF #1 식별자(ID)와 검증 요청자인 NF #3 식별자(ID)가 일치하지 않아 무결성 검증에 실패한다. 즉, NF #3(305)가 NF #1(301)의 인증 토큰을 절취하여 서비스 요청을 한 경우라도, NAAF(100)는 인증 토큰과 NF 식별자(ID)를 맵핑하여 관리하므로,NF #3(305)가 정당한 사용자가 아님을 식별할 수 있다.

NAAF(100)는 무결성 검증 실패를 포함하는 검증 응답 메시지를 NF #2(303)에게 전송한다(S847). 그러면, NF #2(303)는 검증에 실패하였으므로, NF #3(305)가 악의적인 접속임을 판단하여 NF #3(305)에게 서비스를 거절하는 응답 메시지를 전송한다(S849).

이상 기재한 바와 같이, NF #1(301)은 NF #2(303)로 서비스 요청 메시지를 전송할 때, 자신이 NAAF(100)로부터 발급받은 인증 토큰을 포함시키고, NF #2(303)는 NAAF(100)에게 NF #1(301)로부터 수신한 인증 토큰을 전송함으로써, 인증 토큰 자체의 유효성 뿐만 아니라 정당한 사용자, 즉, NAAF(100)가 발급한 사용자에게서 수신된 인증 토큰인지를 검증하는 절차를 수행한다. 그리고 NF #2(303)는 무결성 검증 결과에 기초하여 서비스 제공 여부를 결정한다. 만약, NF #3(305)와 같이 자신이 발급받지 않은 인증 토큰을 악의적으로 취득하여 NF #2(303)로 전송하더라도 NAAF(100)로 인해 NF #3(305)가 발급받은 인증 토큰이 아니라는게 밝혀져 무결성 검증에 실패하고 서비스가 거절될 것이므로, 종래와 같이 NRF(200)에 등록되지 않은 악의적 사용자의 서비스 요청을 허용하게 되는 문제를 막을 수 있다.

또한, 본 발명의 실시예에 따르면, 인증 토큰은 액세스(Access) 토큰과 리프레시(Refresh) 토큰으로 구분될 수 있다.

도 11은 본 발명의 한 실시예에 따른 NF의 인증 토큰 처리 동작을 나타낸 순서도이다.

도 11을 참조하면, NF(300)는 서비스 요청, 즉, 도 4 내지 도 10에서 설명한 NF 서비스 요청이 발생(S901)하면, NRF(200)로 NF 서비스 요청을 전송하기 전에 기 저장된 토큰이 있는지 판단한다(S903).

NF(300)는 기 저장된 인증 토큰이 없으면, 즉, 최초 인증 토큰 발급으로 판단되면, NAAF(100)로부터 액세스 토큰을 발급받는다(S905). 그리고 NF(300)는 액세스 토큰을 이용하여 서비스 요청을 실행한다(S907). 즉, 도 4 내지 도 10에서 설명한 동작에서 사용되는 인증 토큰은 어느 동작에서이든지 인증 토큰의 최초 발급시에는 액세스 토큰을 이용한다.

S903 단계에서 기 저장된 인증 토큰이 있다고 판단되면, NF(300)는 저장된 인증 토큰의 유효기간을 확인한다(S909). NF(300)는 유효기간의 만료 여부를 판단(S911)하고 유효기간이 만료된 경우, NAAF(100)로부터 리프레시 토큰을 신규 발급받거나 리프레시 토큰을 갱신한다(S913).

NF(300)는 유효기간이 만료되지 않은 경우, 저장된 액세스 토큰 또는 리프레시 토큰을 이용하여 서비스 요청을 실행한다(S915). 또한, NF(300)는 S913 단계에서 신규 발급 또는 갱신한 리프레시 토큰을 이용하여 서비스 요청을 실행한다(S915).

이와 같이, NF 서비스 절차를 하기 전 액세스 토큰을 한번 발급을 받은 후, 액세스 토큰에 부여된 유효 기간 동안 액세스 토큰을 사용하여 무결성 검증을 수행하고, 이후 유효 기간이 만료하면 리프레시 토큰을 발급받아 사용한다. 리프레시 토큰 역시 유효 기간이 설정되어 있고 유효 기간이 만료하면 리프레시 토큰을 갱신하여 사용한다. 따라서, 액세스 토큰에 대한 정보가 누출되더라도 주기적인 리프레시 토큰 업데이트로 보안을 강화할 수 있다.

한편, 도 12는 본 발명의 실시예에 따른 네트워크 장치의 하드웨어 구성을 나타낸 블록도이다.

한 실시예에 따른 네트워크 장치는, 도 1 내지 도 11에서 설명한 NAAF(100), NRF(200) 및 네트워크 기능(NF)(300) 중 적어도 하나를 구현하는 컴퓨터 시스템, 예를들어 컴퓨터 판독 가능 매체로 구현될 수 있다.

도 12를 참조하면, 네트워크 장치(400)는, 본 발명의 동작을 실행하도록 기술된 명령들(instructions)이 포함된 프로그램을 실행할 수 있으며, 하드웨어는 버스(401)를 통해 통신하는 적어도 하나의 프로세서(403), 메모리(405), 스토리지(407), 통신 인터페이스(409)를 포함할 수 있다. 이외에도 입력 장치 및 출력 장치 등의 하드웨어가 포함될 수 있다. 네트워크 장치(400)는 프로그램을 구동할 수 있는 운영 체제를 비롯한 각종 소프트웨어가 탑재될 수 있다.

프로세서(401)는 네트워크 장치(400)의 동작을 제어하는 장치로서, 프로그램에 포함된 명령들을 처리하는 다양한 형태의 프로세서일 수 있고, 예를들면, CPU(Central Processing Unit), MPU(Micro Processor Unit), MCU(Micro Controller Unit), GPU(Graphic Processing Unit) 등 일 수 있다. 메모리(403)는 본 발명의 동작을 실행하도록 기술된 명령들이 프로세서(401)에 의해 처리되도록 해당 프로그램을 로드할 수 있다. 메모리(403)는 예를 들면, ROM(read only memory), RAM(random access memory) 등 일 수 있다. 스토리지(405)는 본 발명의 동작을 실행하는데 요구되는 각종 데이터, 프로그램 등을 저장할 수 있다. 통신 인터페이스(407)는 유/무선 통신 모듈일 수 있다. 본 기재의 실시예에서 메모리는 프로세서의 내부 또는 외부에 위치할 수 있고, 메모리는 이미 알려진 다양한 수단을 통해 프로세서와 연결될 수 있다.

이상에서 설명한 본 발명의 실시예는 장치 및 방법을 통해서만 구현이 되는 것은 아니며, 본 발명의 실시예의 구성에 대응하는 기능을 실현하는 프로그램 또는 그 프로그램이 기록된 기록 매체를 통해 구현될 수도 있다.

이상에서 본 발명의 실시예에 대하여 상세하게 설명하였지만 본 발명의 권리범위는 이에 한정되는 것은 아니고 다음의 청구범위에서 정의하고 있는 본 발명의 기본 개념을 이용한 당업자의 여러 변형 및 개량 형태 또한 본 발명의 권리범위에 속하는 것이다.

Claims

통신 네트워크의 네트워크 기능(Network Function, NF) 장치에서 수행하는 인증 방법으로서,
제1 NF 장치가 제2 NF 장치로부터 서비스 요청 메시지를 수신하는 단계,
상기 서비스 요청 메시지로부터 상기 제2 NF 장치의 인증 토큰을 획득하는 단계,
상기 제2 NF 장치를 식별하기 위한 상기 제2 NF 장치의 ID와 상기 인증 토큰을 포함하는 NF 검증 요청 메시지를 NF 인증 장치에게 전송하는 단계, 그리고
상기 NF 인증 장치로부터 NF 검증 성공 응답 메시지가 수신되면, 상기 제2 NF 장치에게 서비스 요청을 수락하는 서비스 응답 메시지를 전송하는 단계를 포함하고,
상기 NF 검증 성공 응답 메시지는,
상기 NF 인증 장치에 의해 검증 요청된 상기 인증 토큰에 맵핑된 NF 장치 ID가 상기 제2 NF 장치의 ID로 확인되면, 상기 NF 인증 장치로부터 상기 제1 NF 장치에게 전달되는, 인증 방법.
제1항에서,
상기 NF 인증 장치에게 전송하는 단계 이후,
상기 NF 인증 장치로부터 NF 검증 실패 응답 메시지가 수신되면, 상기 제2 NF 장치에게 서비스 요청을 거절하는 서비스 응답 메시지를 전송하는 단계를 더 포함하고,
상기 NF 검증 실패 응답 메시지는,
상기 NF 인증 장치에 의해 상기 제2 NF 장치의 ID와 상기 인증 토큰이 맵핑 등록되어 있지 않은 경우로 확인되면, 상기 NF 인증 장치로부터 상기 제1 NF 장치에게 전달되는, 인증 방법.
제1항에서,
상기 제1 NF 장치 및 상기 제2 NF 장치는,
적어도 하나의 NF 서비스 절차를 수행하기 전에, 상기 NF 인증 장치에게 요청하여 인증 토큰을 발급받고,
상기 NF 서비스는,
NF 프로파일 등록, NF 프로파일 갱신, NF 프로파일 등록 해지, NF 상태 가입, NF 상태 가입 해지 및 NF 디스커버리 중 적어도 하나를 포함하는, 인증 방법.
제3항에서,
상기 인증 토큰은,
상기 NF 인증 장치로부터 상기 제1 NF 장치 또는 상기 제2 NF 장치로 전송되고 동시에 네트워크 저장소 기능(Network Repository Function, NRF)으로 전송되며,
상기 NRF로 전송된 인증 토큰은,
상기 NRF에서 상기 제1 NF 장치 또는 상기 제2 NF 장치와 상기 NF 서비스 절차를 위한 NF 무결성 검증에 사용되는, 인증 방법.
통신 네트워크의 네트워크 기능(Network Function, NF) 장치를 인증하는 방법으로서,
제2 NF 장치로부터 인증 토큰 발급 요청을 수신하는 단계,
상기 제2 NF 장치에게 인증 및 권한을 부여하는 인증 토큰을 발급하고, 발급한 인증 토큰을 상기 제2 NF 장치를 식별하기 위한 상기 제2 NF 장치의 ID와 함께 맵핑하여 저장하는 단계,
상기 발급한 인증 토큰을 상기 제2 NF 장치에게 전송하는 단계,
NF 인증 장치가 제1 NF 장치로부터 제2 NF 장치의 ID 및 상기 제2 NF 장치의 인증 토큰이 포함된 NF 검증 요청 메시지를 수신하는 단계,
상기 제2 NF 장치의 인증 토큰이 상기 제2 NF 장치를 대상으로 발급된 인증 토큰인지 판단하는 NF 무결성 검증을 수행하는 단계, 그리고
상기 제2 NF 장치의 인증 토큰이 상기 제2 NF 장치를 대상으로 발급된 인증 토큰이면, NF 검증 성공 응답 메시지를 상기 제1 NF 장치에게 전송하는 단계를 포함하고,
상기 NF 검증 성공 응답 메시지는,
상기 제1 NF 장치가 상기 제2 NF 장치로부터 수신한 서비스 요청에 대하여 서비스 수락 응답 메시지를 전송하게 하고,
상기 NF 무결성 검증은,
상기 NF 검증 요청 메시지에 포함된 인증 토큰이 유효한지, 그리고 상기 인증 토큰에 맵핑된 NF 장치 ID가 상기 제2 NF 장치의 ID와 동일한지 판단하는, 인증 방법.
제5항에서,
상기 NF 인증 장치는,
NF 장치 들간에 공통의 통신 인터페이스로 통신하는 SBA(Service-Based Architecture) 기반의 5G 코어 시스템에서, 상기 공통의 통신 인터페이스에 연결되는, 인증 방법.
삭제
제5항에서,
상기 제2 NF 장치에게 전송하는 단계 이후,
상기 발급한 인증 토큰을 네트워크 저장소 기능(Network Repository Function, NRF)에게 전송하는 단계를 더 포함하고,
상기 NRF로 전송된 인증 토큰은,
상기 제2 NF 장치의 요청에 따른 적어도 하나의 NF 서비스의 제공 여부를 결정하는데 사용되는, 인증 방법.
제8항에서,
상기 NRF에게 전송하는 단계는,
상기 제2 NF 장치의 ID 및 상기 발급한 인증 토큰을 포워딩하고,
상기 NRF는,
상기 제2 NF 장치로부터 상기 제2 NF 장치의 ID 및 상기 발급한 인증 토큰을 포함하는 NF 서비스 요청을 수신하고, 상기 제2 NF 장치의 ID 및 상기 발급한 인증 토큰이 상기 NF 인증 장치로부터 수신한 정보와 일치하는 경우, 상기 NF 서비스 요청을 처리하는, 인증 방법.