KR20230008595A - 근접 통신 기능을 구비한 단말들 간의 인증 방법 및 이 방법이 구현된 단말들 - Google Patents

근접 통신 기능을 구비한 단말들 간의 인증 방법 및 이 방법이 구현된 단말들 Download PDF

Info

Publication number
KR20230008595A
KR20230008595A KR1020220044980A KR20220044980A KR20230008595A KR 20230008595 A KR20230008595 A KR 20230008595A KR 1020220044980 A KR1020220044980 A KR 1020220044980A KR 20220044980 A KR20220044980 A KR 20220044980A KR 20230008595 A KR20230008595 A KR 20230008595A
Authority
KR
South Korea
Prior art keywords
authentication
authentication key
terminal
key
session
Prior art date
Application number
KR1020220044980A
Other languages
English (en)
Inventor
김동호
Original Assignee
삼성에스디에스 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성에스디에스 주식회사 filed Critical 삼성에스디에스 주식회사
Priority to EP22182495.6A priority Critical patent/EP4117230A1/en
Priority to US17/858,435 priority patent/US20230013613A1/en
Publication of KR20230008595A publication Critical patent/KR20230008595A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/047—Key management, e.g. using generic bootstrapping architecture [GBA] without using a trusted network node as an anchor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication

Abstract

근접 통신 기능을 구비한 단말들 간의 인증 방법 및 이 방법이 구현된 단말들이 제공된다. 본 개시의 몇몇 실시예들에 따른 인증 방법은, 랜덤값을 포함하는 세션 기초 정보를 생성하고, 생성된 세션 기초 정보를 제2 단말로 전송하며, 제2 단말과 사전에 공유된 인증키를 이용하여 생성된 세션 기초 정보로부터 세션키를 포함하는 세션 데이터를 생성하고, 생성된 세션 데이터를 이용하여 제2 단말과 UWB(Ultra-Wide Band) 레인징을 수행할 수 있다. 그렇게 함으로써, 보안 채널을 이용하지 않고도 안전한 방식으로 인증이 수행될 수 있으며, 인증에 소요되는 시간이 크게 감소될 수 있다.

Description

근접 통신 기능을 구비한 단말들 간의 인증 방법 및 이 방법이 구현된 단말들{AUTHENTICATION METHOD BETWEEN TERMINALS HAVING PROXIMITY COMMUNICATION FUNCTION AND TERMINALS IMPLEMENTING THE SAME METHOD}
본 개시는 근접 통신 기능을 구비한 단말들 간의 인증 방법 및 이 방법이 구현된 단말들에 관한 것이다. 보다 자세하게는, 본 개시는 UWB(Ultra-Wide Band) 통신 기능 등을 구비한 단말들 간에 수행되는 인증 방법과 이러한 방법을 통해 인증을 수행하도록 구현된 단말들에 관한 것이다.
최근, 정확한 거리 측정 및 보안이 강화된 데이터 전송을 위해 UWB(Ultra-Wide Band) 통신 기술이 이용되기 시작하였다. 특히, UWB 통신 기술은 실내외에서 단말들 사이의 상대적인 위치 또는 거리를 정밀하게 측정하거나, 접촉 없이도 건물 또는 차량의 출입 통제, 상점 또는 대중교통에서의 대금 결제 등을 가능하게 하는 기술로서 큰 관심을 모으고 있다.
FiRa(Fine Ranging) 컨소시엄은 표준화된 UWB 통신 기술을 정의하기 위해 관련 업체들이 모인 단체이며, FiRa 컨소시엄에서는 UWB 기술을 편리하게 사용하기 위한 방법, 인증 및 보안 등에 관한 기술 스펙을 정의해 나가고 있다.
한편, 현재 FiRa 스펙에서는 단말들 간 인증을 수행하기 전에 'GENERAL AUTHENTICATE' 커맨드 등을 통해 보안 채널(secure channel)을 수립하도록 정의하고 있다. 그런데, 현재 FiRa 스펙에 정의된 보안 채널 수립 프로세스는 절차가 복잡하고 많은 시간을 요구하기 때문에, 단말들 간의 인증이 신속하게(e.g. 약 1초 이내) 수행되기 어렵다는 문제점이 있으며, 이러한 문제점은 FiRa 스펙에 따른 UWB 통신 기술의 활용성과 사용 편의성을 떨어뜨릴 수 있다.
한국공개특허공보 제10-2021-0157155호 (2021.12.28. 공개)
본 개시의 몇몇 실시예들을 통해 해결하고자 하는 기술적 과제는, 근접 통신 기능을 구비한 단말들 간의 인증 방법과 이러한 방법을 통해 인증을 수행하도록 구현된 단말들을 제공하는 것이다.
본 개시의 몇몇 실시예들을 통해 해결하고자 하는 보다 구체적인 기술적 과제는, 근접 통신 기능을 구비한 단말들 간에 신속하고도 안전하게 인증을 수행할 수 있는 방법과 이러한 방법을 통해 인증을 수행하도록 구현된 단말들을 제공하는 것이다.
본 개시의 몇몇 실시예들을 통해 해결하고자 하는 다른 기술적 과제는, 현행 FiRa 스펙에 용이하게 반영될 수 있도록 설계된 인증 방법을 제공하는 것이다.
본 개시의 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급되지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명의 기술분야에서의 통상의 기술자에게 명확하게 이해될 수 있을 것이다.
상술한 기술적 과제들을 해결하기 위한, 본 개시의 몇몇 실시예들에 따른 인증 방법은, FiRa(Fine Ranging) 애플릿이 구동되는 제1 단말에서 보안 채널(secure channel) 미사용 모드로 인증을 수행하는 방법에 있어서, 랜덤값을 포함하는 세션 기초 정보를 생성하는 단계, 상기 생성된 세션 기초 정보를 제2 단말로 전송하는 단계, 상기 제2 단말과 사전에 공유된 인증키를 이용하여 상기 생성된 세션 기초 정보로부터 세션키를 포함하는 세션 데이터를 생성하는 단계 및 상기 생성된 세션 데이터를 이용하여 상기 제2 단말과 UWB(Ultra-Wide Band) 레인징을 수행하는 단계를 포함할 수 있다.
일 실시예에서, 상기 세션 기초 정보는 ADF(Application Dedicated File)의 인스턴스 UID(Unique IDentifier)를 더 포함할 수 있다.
일 실시예에서, 상기 세션 데이터를 생성하는 단계는, ADF(Application Dedicated File)의 특정 필드의 설정값을 이용하여 현재 인증 모드를 판단하는 단계 및 상기 현재 인증 모드가 상기 보안 채널 미사용 모드라는 판단에 응답하여, 상기 세션 데이터를 생성하는 단계를 포함할 수 있다.
일 실시예에서, 상기 특정 필드는 상기 ADF의 확장 옵션(extended option) 필드일 수 있다.
상술한 기술적 과제들을 해결하기 위한, 본 개시의 몇몇 실시예들에 따른 인증 방법은, FiRa(Fine Ranging) 애플릿이 구동되는 제2 단말에서 보안 채널(secure channel) 미사용 모드로 인증을 수행하는 방법에 있어서, 제1 단말로부터 랜덤값을 포함하는 세션 기초 정보를 수신하는 단계, 상기 제1 단말과 사전에 공유된 인증키를 이용하여 상기 수신된 세션 기초 정보로부터 세션키를 포함하는 세션 데이터를 생성하는 단계 및 상기 생성된 세션 데이터를 이용하여 상기 제1 단말과 UWB(Ultra-Wide Band) 레인징을 수행하는 단계를 포함할 수 있다.
일 실시예에서, 상기 세션 기초 정보는 ADF(Application Dedicated File)의 인스턴스 UID(Unique IDentifier)를 더 포함하고, 상기 인증키는 상기 ADF의 특정 필드에 저장되어 있으며, 상기 세션 데이터를 생성하는 단계는, 상기 세션 기초 정보에 포함된 상기 인스턴스 UID를 이용하여 상기 특정 필드에서 상기 인증키를 획득하는 단계 및 상기 인증키를 이용하여 상기 세션 데이터를 생성하는 단계를 포함할 수 있다.
일 실시예에서, 상기 세션 데이터를 생성하는 단계는, ADF(Application Dedicated File)의 특정 필드의 설정값을 이용하여 현재 인증 모드를 판단하는 단계 및 상기 현재 인증 모드가 상기 보안 채널 미사용 모드라는 판단에 응답하여, 상기 세션 데이터를 생성하는 단계를 포함할 수 있다.
상술한 기술적 과제들을 해결하기 위한, 본 개시의 몇몇 실시예들에 따른 인증 방법은, FiRa(Fine Ranging) 애플릿이 구동되는 제1 단말에서 보안 채널(secure channel) 미사용 모드로 인증을 수행하는 방법에 있어서, 인증키를 획득하는 단계 - 상기 인증키는 상기 보안 채널 미사용 모드로 제2 단말과 UWB(Ultra-Wide Band) 레인징 기반 인증을 수행하기 위해 이용되는 키임 -, ADF(Application Dedicated File)의 특정 필드에 상기 획득된 인증키를 저장하는 단계 및 상기 획득된 인증키를 보안 채널을 통해 상기 제2 단말과 공유하는 단계를 포함할 수 있다.
일 실시예에서, 상기 특정 필드는 상기 ADF의 애플리케이션 데이터(application data) 필드일 수 있다.
일 실시예에서, 상기 인증키를 획득하는 단계는, 상기 FiRa 애플릿이, 상기 인증키를 생성하는 단계를 포함할 수 있다.
일 실시예에서, 상기 인증키를 획득하는 단계는, 상기 제1 단말에서 구동되는 애플리케이션이 외부로부터 상기 인증키를 수신하는 단계를 포함할 수 있고, 상기 인증키를 저장하는 단계는, 상기 FiRa 애플릿이 상기 수신된 인증키를 저장하는 단계를 포함할 수 있다.
일 실시예에서, 상기 획득된 인증키를 저장하는 단계는, 사전에 공유된 보안 채널용 암호화키를 이용하여 상기 획득된 인증키를 암호화하여 저장하는 단계를 포함할 수 있다.
상술한 기술적 과제들을 해결하기 위한, 본 개시의 몇몇 실시예들에 따른 인증 방법은, FiRa(Fine Ranging) 애플릿이 구동되는 제2 단말에서 보안 채널(secure channel) 미사용 모드로 인증을 수행하는 방법에 있어서, 보안 채널을 통해 제1 단말로부터 인증키를 수신하는 단계 - 상기 인증키는 상기 보안 채널 미사용 모드로 상기 제1 단말과 UWB(Ultra-Wide Band) 레인징 기반 인증을 수행하기 위해 이용되는 키임 - 및 ADF(Application Dedicated File)의 특정 필드에 상기 수신된 인증키를 저장하는 단계를 포함할 수 있다.
일 실시예에서, 상기 수신된 인증키를 저장하는 단계는, 상기 ADF의 다른 특정 필드에 설정된 값을 이용하여 현재 인증 모드를 판단하는 단계 및 상기 현재 인증 모드가 상기 보안 채널 미사용 모드라는 판단에 응답하여, 상기 수신된 인증키를 저장하는 단계를 포함할 수 있다.
일 실시예에서, 상기 제2 단말은 상기 제1 단말로부터 상기 ADF의 인스턴스 UID(Unique IDentifier)를 더 수신하고, 상기 수신된 인증키를 저장하는 단계는, 상기 수신된 인스턴스 UID를 이용하여 상기 특정 필드에 기 저장된 인증키가 존재하는 여부를 판단하는 단계 및 미존재 판단에 응답하여, 상기 수신된 인증키를 저장하는 단계를 포함할 수 있다.
일 실시예에서, 상기 제1 단말로부터 ADF의 인스턴스 UID(Unique IDentifier)를 포함하는 인증키 삭제 요청 메시지를 수신하는 단계는, 상기 인스턴스 UID를 이용하여 상기 특정 필드에 기 저장된 인증키가 존재하는지 여부를 판단하는 단계 및 존재 판단에 응답하여, 상기 기 저장된 인증키를 삭제하는 단계를 더 포함할 수 있다.
본 개시의 몇몇 실시예들에 따르면, 단말들 간에 사전에 인증키를 공유하고, 공유된 인증키와 랜덤값을 이용하여 단말들 간에 UWB(Ultra-Wide Band) 레인징을 위한 세션키가 생성될 수 있다. 이에 따라, 보안 채널(secure channel)을 사용(수립)하지 않고도 안전한 방식으로 단말들 간에 인증이 수행될 수 있고, 인증 프로세스가 간소화될 수 있으며, 인증에 소요되는 시간은 크게 감소될 수 있다. 뿐만 아니라, 인증 시에 소모되는 전력도 최소화될 수 있다.
또한, ADF(Application Dedicated File)의 특정 필드에 인증키를 저장함으로써, 인증키가 안전하게 보관될 수 있다.
또한, 단말들 간에 사전에 공유된 보안 채널용 암호화키를 이용하여 인증키를 암호화하여 저장함으로써, 인증키가 더욱 안전하게 보관될 수 있다.
또한, 단말들 간에 사전에 공유된 보안 채널용 암호화키를 이용하여 인증키를 암호화된 상태로 공유함으로써, 단말들 간에 인증키가 안전하게 공유될 수 있다.
또한, ADF의 특정 필드를 통해 보안 채널을 사용(수립)하지 않는 새로운 인증 모드를 추가함으로써, 개시된 인증 방법이 현행 FiRa 스펙에 용이하게 반영될 수 있다.
도 1은 본 개시의 몇몇 실시예들에 따른 인증 방법이 적용될 수 있는 예시적인 출입 통제 시스템을 나타낸다.
도 2는 몇몇 실시예들에 따른 인증 방법이 구현된 단말들을 나타내는 예시적인 블록도이다.
도 3은 본 개시의 몇몇 실시예들에 따른 인증 방법의 개략적인 흐름을 나타내는 예시적인 도면이다.
도 4 및 도 5는 본 개시의 일 실시예에 따른 인증키 획득 프로세스를 나타내는 예시적인 흐름도이다.
도 6 및 도 7은 본 개시의 다른 실시예에 따른 인증키 획득 프로세스를 나타내는 예시적인 흐름도이다.
도 8 및 도 9는 본 개시의 몇몇 실시예들에 따른 인증키 공유 프로세스를 나타내는 예시적인 흐름도이다.
도 10은 도 9에 도시된 인증키 저장 단계의 세부 과정을 나타내는 예시적인 흐름도이다.
도 11 및 도 12는 본 개시의 몇몇 실시예들에 따른 인증 프로세스를 나타내는 예시적인 흐름도이다.
도 13은 도 12에 도시된 세션 기초 정보 생성 단계의 세부 과정을 나타내는 예시적인 흐름도이다.
도 14는 도 12에 도시된 세션 데이터 생성 단계의 세부 과정을 나타내는 예시적인 흐름도이다.
도 15 및 도 16은 본 개시의 몇몇 실시예들에 따른 인증키 삭제 프로세스를 나타내는 예시적인 흐름도이다.
도 17은 도 16에 도시된 인증키 삭제 단계의 세부 과정을 나타내는 예시적인 흐름도이다.
도 18은 본 개시의 몇몇 실시예들에 따른 단말들을 구현할 수 있는 예시적인 컴퓨팅 장치를 도시한다.
이하, 첨부된 도면을 참조하여 본 개시의 다양한 실시예들을 상세히 설명한다. 본 개시의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시예들을 참조하면 명확해질 것이다. 그러나, 본 개시의 기술적 사상은 이하의 실시예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 이하의 실시예들은 본 개시의 기술적 사상을 완전하도록 하고, 본 개시가 속한 기술분야에서 통상의 지식을 가진 자에게 본 개시의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 개시의 기술적 사상은 청구항의 범주에 의해 정의될 뿐이다.
본 개시의 다양한 실시예들을 설명함에 있어, 관련된 공지 구성 또는 기능에 대한 구체적인 설명이 본 개시의 요지를 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명은 생략한다.
다른 정의가 없다면, 이하의 실시예들에서 사용되는 용어(기술 및 과학적 용어를 포함)는 본 개시가 속한 기술분야에서 통상의 지식을 가진 자에게 공통적으로 이해될 수 있는 의미로 사용될 수 있으나, 이는 관련 분야에 종사하는 기술자의 의도 또는 판례, 새로운 기술의 출현 등에 따라 달라질 수도 있다. 본 개시에서 사용된 용어는 실시예들을 설명하기 위한 것이며 본 개시의 범주를 제한하고자 하는 것은 아니다.
이하의 실시예들에서 사용되는 단수의 표현은 문맥상 명백하게 단수인 것으로 특정되지 않는 한, 복수의 개념을 포함한다. 또한, 복수의 표현은 문맥상 명백하게 복수인 것으로 특정되지 않는 한, 단수의 개념을 포함한다.
또한, 이하의 실시예들에서 사용되는 제1, 제2, A, B, (a), (b) 등의 용어는 어떤 구성요소를 다른 구성요소와 구별하기 위해 사용되는 것일 뿐, 그 용어에 의해 해당 구성요소의 본질이나 차례 또는 순서 등이 한정되지는 않는다.
이하, 첨부된 도면들을 참조하여 본 개시의 다양한 실시예들에 대하여 상세하게 설명한다.
도 1은 본 개시의 몇몇 실시예들에 따른 인증 방법이 적용될 수 있는 예시적인 시스템을 나타낸다. 특히, 도 1은 출입 통제 시스템을 예시하고 있다.
도 1에 도시된 바와 같이, 예시적인 출입 통제 시스템은 제1 단말(10)과 복수의 제2 단말들(20a 내지 20c)을 포함할 수 있다. 도 1에 도시되어 있지는 않으나, 예시적인 출입 통제 시스템은 원격 서버를 더 포함할 수도 있다.
제1 단말(10)은 근접 통신을 통해 제2 단말들(20a 내지 20c에 대한 인증을 수행하고, 인증 결과를 토대로 제2 단말들(20a 내지 20c)(또는 이들을 소지한 사용자)의 출입을 통제하는 장치일 수 있다. 가령, 제1 단말(10)은 등록 프로세스를 실행하여 복수의 제2 단말들(20a 내지 20c)을 사전에 등록하고, 물리적으로 근접하게 위치한 제2 단말(20a 내지 20c)과의 통신을 통해서 제2 단말(20a 내지 20c)과의 거리를 측정하며, 제2 단말(20a 내지 20c)을 인증하고, 사전에 등록된 정보를 이용하여 제2 단말(20a 내지 20c)을 식별할 수 있다. 이를테면, 제1 단말(10)은 사전에 등록된 제2 단말(20a 내지 20c)을 탐지하여, 등록된 단말에 한하여 출입을 허가하는 기능을 제공할 수 있다.
제1 단말(10)은 예를 들어 건물 및/또는 가정집 등에서 사람의 출입을 통제하는 디지털 도어락일 수 있을 것이나, 본 개시의 범위가 이에 한정되는 것은 아니다.
제1 단말(10)은 근접(또는 근거리) 통신 모듈을 구비할 수 있다. 예를 들어, 제1 단말(10)은 NFC(Near Field Communication), 블루투스(Bluetooth), BLE(Bluetooth Lowe Energy), UWB(Ultra-Wide Band), WiFi 등의 통신 기술 중 적어도 일부를 지원하는 하나 이상의 통신 모듈을 구비할 수 있다.
제2 단말들(20a 내지 20c)은 사용자의 출입(또는 인증)을 위해 사용되는 장치로서, 예를 들어 스마트 키, 스마트폰 등이 될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다. 이하에서는, 설명의 편의상, 제2 단말들(20a 내지 20c) 중 어느 하나의 단말을 지칭하거나 복수의 제2 단말들(20a 내지 20c)을 총칭하는 경우에 참조번호 '20'을 사용하도록 한다.
제1 단말(10)과 마찬가지로, 제2 단말(20) 또한 근접(또는 근거리) 통신 모듈을 구비할 수 있다. 예를 들어, 제2 단말(20)도 NFC, Bluetooth, BLE, UWB, WiFi 등의 통신 기술을 지원하는 하나 이상의 통신 모듈을 구비할 수 있다. 또한, 제2 단말(20)은 FIDO 보안 인증 모듈을 더 구비할 수도 있다.
한편, 몇몇 실시예들에서는, 인증키가 제1 단말(10)과 제2 단말(20) 간에 사전 공유될 수 있다. 그리고, 제1 단말(10)과 제2 단말(20)이 물리적으로 근접한 경우, FiRa 스펙에 따른 보안 채널(secure channel)을 수립(사용)하지 않고도 단말들(10, 20) 사이에 안전한 방식으로 인증이 수행될 수 있다. 그렇게 함으로써, 제2 단말(20)에 대한 인증 및 출입 통제가 신속하게 수행될 수 있는데, 본 실시예에 관하여서는 추후 도 3 이하의 도면을 참조하여 상세하게 설명하도록 한다.
지금까지 본 개시의 몇몇 실시예들에 따른 인증 방법이 적용될 수 있는 예시적인 출입 통제 시스템에 대하여 설명하였다. 이하에서는, 도 2를 참조하여 본 개시의 몇몇 실시예들에 따른 인증 방법이 구현된 단말들(10, 20)에 대하여 간략하게 설명하도록 한다.
도 2는 본 개시의 몇몇 실시예들에 따른 제1 단말(10) 및 제2 단말(20)을 나타내는 예시적인 블록도이다.
도 2에 도시된 바와 같이, 제1 단말(10)은 하나 이상의 애플리케이션(11) 및 애플릿(12)을 포함할 수 있고, 제2 단말(20)도 하나 이상의 애플리케이션(21) 및 애플릿(22)을 포함할 수 있다. 다만, 도 2에는 본 개시의 실시예와 관련 있는 구성요소들만이 도시되어 있다. 따라서, 본 개시가 속한 기술분야의 통상의 기술자라면 도 2에 도시된 구성요소들 외에 다른 범용적인 구성 요소들(e.g. 프로세서, 메모리, 입출력 인터페이스 등)이 더 포함될 수 있음을 알 수 있다. 또한, 도 2에 도시된 제1 단말(10) 및 제2 단말(20)의 구성 요소들은 기능적으로 구분되는 기능 요소들을 나타낸 것으로서, 복수의 구성 요소가 실제 물리적 환경에서는 서로 통합되는 형태로 구현될 수도 있고, 특정 기능 요소가 복수의 서브 기능 요소들로 분리되는 형태로 구현될 수도 있다. 이하, 각 구성요소에 대하여 상세하게 설명한다.
먼저, 제1 단말(10)에서 구동되는 애플리케이션(11)은 FiRa 스펙에 규정된 컨트롤러(controller) 측 기능이 구현된 애플리케이션일 수 있다. 애플리케이션(11)은 FiRa 프레임워크 및/또는 FiRa 프레임워크를 이용하는 애플리케이션 등을 포괄하는 것일 수 있다. 또한, 애플리케이션(11)은 출입 인증, 잠금 해제, 차량 운행, 결제 등 제1 단말(10)이 활용되는 다양한 목적에 따른 기능을 구현하는 애플리케이션을 더 포함하는 것일 수도 있다.
애플리케이션(11)은 제1 단말(10)에 구비된 임의의 통신 모듈을 통해 다른 단말, 예컨대 제2 단말(20)과의 사이에 통신 채널(e.g. 보안 채널)을 수립하고, 수립된 통신 채널을 통해 데이터를 교환할 수 있다.
제1 단말(10)에서 구동되는 애플릿(12)은 제1 단말(10)의 애플리케이션(11)에 UWB 통신 및 인증 등의 기능을 제공하는 구성요소일 수 있다. 애플릿(12)은 제1 단말(10)의 보안 영역(Secure Element; e.g. 내장된 보안 영역(eSE)) 내에서 실행(구동)될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다. 애플릿(12)은 제1 단말(10)에서 구동되는 다양한 종류의 애플릿들을 총칭하는 것일 수 있다.
도시된 바와 같이, 애플릿(12)은 FiRa 애플릿(13)과 SUS(Secure UWB Service) 애플릿(14)을 포함할 수 있다. 또한, 애플릿(12)은 FiRa 스펙에 규정된(또는 FiRa 스펙에 규정된 기능이 구현된) 다른 애플릿을 더 포함할 수도 있다. FiRa 애플릿(13)은 인증키 생성, 상대방 단말(e.g. 20)과의 UWB 통신을 위한 세션 관리 기능 등과 같이 단말 인증에 요구되는 다양한 기능을 지원할 수 있다.
애플리케이션(11) 및 애플릿(12)의 세부 기능과 동작에 관하여서는 도 3 이하의 도면을 참조하여 보다 상세하게 설명하도록 한다.
다음으로, 제2 단말(20)의 구성에 대해 설명한다.
제2 단말(20)에서 구동되는 애플리케이션(21)은 FiRa 스펙에서 컨트롤리(controlee) 측 기능이 구현된 애플리케이션일 수 있다. 애플리케이션(21)은 FiRa 프레임워크 및/또는 FiRa 프레임워크를 이용하는 애플리케이션 등을 포괄하는 것일 수 있다. 또한, 애플리케이션(21)은 출입 인증, 잠금 해제, 차량 운행, 결제 등 제2 단말(20)이 활용되는 다양한 목적에 따른 기능을 구현하는 애플리케이션을 더 포함하는 것일 수도 있다.
애플리케이션(21)은 제2 단말(20)에 구비된 임의의 통신 모듈을 통해 다른 단말, 예컨대 제1 단말(10)과의 사이에 통신 채널(e.g. 보안 채널)을 수립하고, 수립된 통신 채널을 통해 데이터를 교환할 수 있다.
제2 단말(20)에서 구동되는 애플릿(22)은 제2 단말(20)의 애플리케이션(21)에 UWB 통신 및 인증 등의 기능을 제공하는 구성요소일 수 있다. 애플릿(22)은 제2 단말(20)의 보안 영역(Secure Element) 내에서 실행(구동)될 수 있으나, 본 개시의 범위가 이에 한정되는 것은 아니다. 애플릿(22)은 제2 단말(20)에서 구동되는 다양한 종류의 애플릿들을 총칭하는 것일 수 있다.
도시된 바와 같이, 애플릿(22) 또한 FiRa 애플릿(23)과 SUS 애플릿(24)을 포함할 수 있고, 애플릿(22)은 FiRa 스펙에 규정된(또는 FiRa 스펙에 규정된 기능이 구현된) 다른 애플릿을 더 포함할 수도 있다. 또는, 제2 단말(20)은 애플릿(22) 외에 다른 애플릿을 더 포함할 수도 있다. 애플릿(22)에 관한 추가적인 설명은 제1 단말(10)의 애플릿(12)에 관한 설명을 더 참조하도록 한다.
애플리케이션(21) 및 애플릿(22)의 세부 기능과 동작에 관하여서는 도 3 이하의 도면을 참조하여 보다 상세하게 설명하도록 한다.
지금까지 도 2를 참조하여 본 개시의 몇몇 실시예들에 따른 단말들(10, 20)에 대하여 설명하였다. 이하에서는, 본 개시의 몇몇 실시예들에 따른 인증 방법에 대하여 설명하도록 한다.
상술한 바와 같이, 현재 FiRa 스펙에서는 단말들 간 인증을 수행하기 전에 'GENERAL AUTHENTICATE' 커맨드(또는 메시지)를 통해 보안 채널(secure channel)을 수립하도록 되어 있기 때문에, 단말들 간 인증이 신속하게 수행되기 어렵다. 이러한 문제를 해결하기 위해, 본 개시의 발명자들은 새로운 인증 방법을 고안하였다.
구체적으로, 본 발명자들은 단말들 간에 인증키(즉, UWB 레인징 기반의 인증에 이용되는 키)를 사전에 공유하고, 보안 채널(secure channel) 수립 없이 사전 공유된 인증키와 랜덤값을 이용하여 신속하고도 안전하게 인증을 수행할 수 있는 방법을 고안하였다. 뿐만 아니라, 본 발명자들은 FiRa 스펙 기반의 단말들이 고안된 인증 방법을 활용할 수 있도록 현행 FiRa 스펙에 용이하게 반영될 수 있는 형태로 인증 방법을 설계하였다.
구체적으로, 현행 FiRa 스펙과의 호환성을 유지하고 고안된 인증 방법을 FiRa 스펙에 용이하게 반영하기 위해, 본 발명자들은 ADF(Application Dedicated File)를 이용하여 새로운 인증 모드를 설정하도록 설계하고, ADF의 설정값이 새로운 인증 모드인 경우에 단말들이 고안된 인증 방법에 따라 인증을 수행하도록 설계하였다. 이하의 설명에서, 새롭게 규정된 인증 모드는 '보안 채널 미사용 모드' 또는 '빠른 인증 모드'로 칭해질 수 있다.
예를 들어, 하기의 표 1에 기재된 바와 같이, ADF의 확장 옵션(extend option) 필드를 이용하여 빠른 인증 모드가 설정(추가)될 수 있고, 보다 상세하게는 UWB 세션 키 유도 방식(UWB session key derivation scheme)을 설정하는 필드를 통해 빠른 인증 모드가 설정(추가)될 수 있다(e.g. 110: Fast authentication 참조). 그러나, 본 개시의 범위가 이에 한정되는 것은 아니며, 빠른 인증 모드는 다른 방식으로 설정될 수도 있다. 예를 들어, 새로운 인증 모드는 확장 옵션(extended option) 필드의 RFU 영역, ADF의 애플리케이션 데이터(application data) 필드 또는 ADF 외의 다른 요소를 이용하여 설정(추가)될 수도 있다.
Byte Bits Values
1 8 Automatic session termination
7 Privacy selection
6-1 RFU
2 8-6 UWB session key derivation scheme
110: Fast authentication
5-1 RFU
3 8-1 RFU
4 8-1 RFU
다만, 이하에서는, 이해의 편의를 제공하기 위해, '빠른 인증 모드'가 상기 표 1에 기재된 바와 같이 설정되는 것을 가정하여 설명을 이어가도록 한다.
이하에서는, 도 3 이하의 도면을 참조하여 고안된 인증 방법에 관한 몇몇 실시예들에 대하여 보다 상세하게 설명하도록 한다.
먼저, 도 3은 본 개시의 몇몇 실시예들에 따른 인증 방법의 개략적인 흐름을 나타내는 예시적인 도면이다.
도 3에 도시된 바와 같이, 실시예들에 따른 인증 방법은 다수의 프로세스들(31 내지 34)로 구성될 수 있으며, 예를 들어 인증키 획득 프로세스(31), 인증키 공유 프로세스(32), 인증 프로세스(33) 및 인증키 삭제 프로세스(34)로 구성될 수 있다. 도 3은 각각의 프로세스(31 내지 34)가 순차적으로 수행되는 것을 예로써 도시하고 있으나, 본 개시의 범위가 이에 한정되는 것은 아니며, 프로세스들(31 내지 34)의 수행 순서는 경우에 따라 달라질 수도 있다.
인증키 획득 프로세스(31)에서는, 제1 단말(10)이 인증키를 획득할 수 있다. 가령, 제1 단말(10)은 자체적으로 인증키를 생성하거나, 외부로부터 인증키를 수신할 수 있다. 본 프로세스(31)에 대한 자세한 설명은 추후 도 4 내지 도 7을 참조하여 상세하게 설명하도록 한다.
다음으로, 인증키 공유 프로세스(32)에서는, 제1 단말(10)과 제2 단말(20) 간에 인증키가 공유될 수 있다. 가령, 제1 단말(10)은 획득한 인증키를 보안 채널을 통해 제2 단말(20)로 전송함으로써 인증키를 공유할 수 있다. 제1 단말(10)과 제2 단말(20) 간의 보안 채널은 FiRa 스펙에 의거하여 수립될 수 있다. 본 프로세스(32)에 대한 자세한 설명은 추후 도 8 내지 도 10을 참조하여 상세하게 설명하도록 한다.
다음으로, 인증 프로세스(33)에서는, 제1 단말(10)과 제2 단말(20) 간에 인증이 수행될 수 있다. 가령, 제1 단말(10)과 제2 단말(20)은 공유된 인증키를 이용하여 세션키를 포함하는 세션 데이터를 생성하고, 생성된 세션 데이터를 이용하여 UWB 레인징 기반의 인증을 수행할 수 있다. 본 프로세스(33)에 대한 자세한 설명은 추후 도 11 내지 도 14를 참조하여 상세하게 설명하도록 한다.
다음으로, 인증키 삭제 프로세스(34)에서는, 인증키 공유 프로세스(32)를 통해 공유된 인증키가 삭제될 수 있다. 본 프로세스(34)에 대한 자세한 설명은 추후 도 15 내지 도 17을 참조하여 상세하게 설명하도록 한다.
지금까지 도 3을 참조하여 본 개시의 몇몇 실시예들에 따른 인증 방법에 대하여 개략적으로 설명하였다. 이하에서는, 인증 방법을 구성하는 각각의 프로세스(31 내지 34)에 대하여 상세하게 설명하도록 한다.
먼저, 도 4 내지 도 7을 참조하여 본 개시의 몇몇 실시예들에 따른 인증키 획득 프로세스(31)에 대하여 상세하게 설명하도록 한다.
도 4는 본 개시의 일 실시예에 따른 인증키 획득 프로세스를 나타내는 예시적인 흐름도이다. 단, 이는 본 개시의 목적을 달성하기 위한 바람직한 실시예일뿐이며, 필요에 따라 일부 단계가 추가되거나 삭제될 수 있음은 물론이다.
도 4에 도시된 바와 같이, 본 실시예는 제1 단말(10)이 직접 인증키를 생성하는 방식에 관한 것으로, FiRa 애플릿(13)과 애플리케이션(11) 간에 수행될 수 있다. 다만, 인증키 획득 프로세스의 개시는 외부의 요청에 의해 이루어질 수 있다.
구체적으로, 본 실시예는 애플리케이션(11)이 인증키 생성 요청을 전송하는 단계 S41에서 시작될 수 있다. 가령, 애플리케이션(11)은 보안 영역(Secure Element)에서 구동되는 FiRa 애플릿(13)으로 인증키 생성 요청 메시지를 전송할 수 있다. 인증키 생성 요청은 예를 들어 FiRa 스펙에 규정된 'GET DATA' 커맨드(또는 메시지)(e.g. 커맨드 APDU(Application Protocol Data Unit) 메시지)를 통해 구현될 수 있다. 보다 구체적인 예로서, 인증키가 없는 상태에서 'GET DATA' 커맨드(e.g. 기 정의된 인증키 저장 영역에서 인증키를 판독하기 위한 커맨드)를 수신하면, FiRa 애플릿(13)이 인증키를 생성하도록 구현될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다. 이하의 설명에서, '요청을 전송한다는 것'은 요청 메시지를 전송하는 동작을 의미할 수도 있다.
단계 S42에서, 수신된 요청에 응답하여, FiRa 애플릿(13)이 인증키를 생성할 수 있다. 본 단계의 세부 과정은 도 5에 도시되어 있다.
도 5에 도시된 바와 같이, 인증키 생성 단계 S42는 FiRa 애플릿(13)이 인증키 생성 요청 메시지를 수신함으로써 시작될 수 있다(S51).
단계 S52에서, FiRa 애플릿(13)은 인증키 요청 메시지의 태그를 체크할 수 있다. 가령, FiRa 애플릿(13)은 수신된 요청 메시지의 태그가 애플리케이션 데이터 태그(application data tag)인지 여부를 체크할 수 있다. 도 5에서, 메시지의 태그를 '0xBF76'과 비교하는 것은 FiRa 스펙에 규정된 애플리케이션 데이터 태그(application data tag)의 값이 '0xBF76'이기 때문이다.
단계 S53에서, FiRa 애플릿(13)은 ADF의 확장 옵션(extended option) 필드를 이용하여 현재 인증 모드가 빠른 인증 모드(즉, 보안 채널 미사용 모드)인지 여부를 판단할
수 있다. 가령, 도시된 바와 같이, 확장 옵션(extended option) 필드의 2번째 바이트 값이 '0xC0'인지 여부가 체크될 수 있다. '0xC0'인지 여부를 체크하는 이유는 빠른 인증 모드를 '110'(6-8 bits 값)으로 정의한 경우(표 1 참조), 2번째 바이트의 값이 '0xC0'이 되기 때문이다. 상술한 바와 같이, 빠른 인증 모드가 다른 방식(e.g. 다른 값 또는 다른 필드를 이용하는 경우)으로 정의되면, 본 단계 또한 그에 맞게 변형될 수 있다.
단계 S54에서, FiRa 애플릿(13)은 인증키가 존재하는지 여부를 판단할 수 있다. 가령, FiRa 애플릿(13)은 ADF의 인스턴스 UID(Unique IDentifier)를 이용하여 ADF의 특정 필드(즉, 미리 정의된 인증키 영역)에 인증키가 존재하는 여부를 판단할 수 있다. 이때, 미리 정의된 인증키 영역은 예를 들어 ADF의 애플리케이션 데이터(application data) 필드일 수 있으나, 본 개시의 범위가 이에 한정되는 것은 아니다. 다만, 이하에서는, 이해의 편의를 위해, 인증키가 ADF의 애플리케이션 데이터(application data) 필드에 저장되는 것을 가정하여 설명을 이어가도록 한다. 인증키가 존재하지 않는다는 판단에 응답하여, 단계 S55가 수행될 수 있다.
단계 S55에서, FiRa 애플릿(13)은 인증키를 생성할 수 있다. 가령, FiRa 애플릿(13)은 랜덤값 생성 알고리즘 또는 당해 기술 분야에서 널리 알려진 키 생성 알고리즘을 이용하여 인증키를 생성할 수 있다. 생성된 인증키는 ADF의 애플리케이션 데이터(application data) 필드에 저장될 수 있고, 보안성 향상을 위해 암호화된 상태로 저장될 수도 있다. 가령, 생성된 인증키는 FiRa 스펙에 따라 사전에 공유되는 보안 채널(secure channel)용 암호화키에 의해 암호화된 상태로 저장될 수도 있다.
단계 S56에서, FiRa 애플릿(13)은 수행 결과를 나타내는 메시지를 생성할 수 있다. 가령, FiRa 애플릿(13)은 수행 결과에 따라 에러 메시지를 생성할 수도 있고(e.g. 메시지 태그 불일치, 인증 모드 불일치 등의 경우), 생성된 인증키 또는 기 저장된 인증키를 포함하는 결과 메시지를 생성할 수도 있다. 이때, 인증키는 보안성 향상을 위해 암호화키에 의해 암호화된 상태로 결과 메시지에 포함될 수도 있다. 가령, 인증키는 보안 채널(secure channel)용 암호화키로 암호화될 수도 있다.
하기의 표 2는 상술한 단계 S56에서 생성될 수 있는 결과 메시지의 포맷을 예시하고 있다.
Tag Length Description Presence
0x7A Variable Add key data Mandatory
0x80 1 ~ 16 Instance UID Mandatory
0x81 1 Status Mandatory
0x82 16 Key data (Encrypted) Mandatory
상기 표 2에서 키 데이터(key data)는 인증키를 의미하고, '0x7A' 값은 인증키 획득 프로세스와 관련하여 새롭게 정의된 메시지의 태그값으로서, 그 값은 얼마든지 변경될 수 있다.
한편, 도 5에 도시되어 있지는 않으나, 경우에 따라 FiRa 애플릿(13)은 보안 채널(secure channel)이 수립되어 있는지 여부를 체크하고(e.g. 외부 단말의 요청에 의해 인증키 획득 프로세스를 개시한 경우, 외부 단말과 보안 채널이 수립되어 있는지를 체크함), 보안 채널(secure channel)이 수립되지 않은 경우 인증키 생성 프로세스를 중단(또는 종료)하며, 에러 메시지를 생성할 수도 있다.
다시 도 4를 참조하여 설명한다.
단계 S43에서, FiRa 애플릿(13)은 인증키 생성 결과를 애플리케이션(11)에게 전달할 수 있다. 가령, FiRa 애플릿(13)은 상술한 단계 S56에서 생성된 결과 메시지를 애플리케이션(11)에게 전달할 수 있다. 이러한 결과 메시지의 전달은 예를 들어 FiRa 스펙에 규정된 'GET DATA RESPONSE' 커맨드를 통해 구현될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다. 이하의 설명에서, '결과를 전달한다는 것'은 결과 메시지를 전달하는 동작을 의미할 수도 있다.
지금까지 도 4 및 도 5를 참조하여 본 개시의 일 실시예에 따른 인증키 획득 프로세스에 대하여 설명하였다. 이하에서는, 도 6 및 도 7을 참조하여 본 개시의 다른 실시예에 따른 인증키 획득 프로세스에 설명하도록 한다.
도 6은 본 개시의 다른 실시예에 따른 인증키 획득 프로세스를 나타내는 예시적인 흐름도이다. 단, 이는 본 개시의 목적을 달성하기 위한 바람직한 실시예일뿐이며, 필요에 따라 일부 단계가 추가되거나 삭제될 수 있음은 물론이다.
도 6에 도시된 바와 같이, 본 실시예는 제1 단말(10)이 외부에서 인증키를 수신하는 방식에 관한 것으로, FiRa 애플릿(13)과 애플리케이션(11) 간에 수행될 수 있다.
구체적으로, 본 실시예는 애플리케이션(11)이 외부에서 인증키를 수신하는 단계 S61에서 시작될 수 있다. 이때, 제1 단말(10)과 외부 간에는 FiRa 스펙에 규정된 방식으로 보안 채널(secure channel)이 수립되어 있을 수 있다.
단계 S62에서, 애플리케이션(11)은 인증키를 FiRa 애플릿(13)에게 전달될 수 있다. 인증키의 전달은 예를 들어 FiRa 스펙에 규정된 'PUT DATA' 커맨드를 통해 구현될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다.
단계 S63에서, FiRa 애플릿(13)은 인증키를 저장할 수 있다. 본 단계의 세부 과정은 도 7에 도시되어 있다.
도 7에 도시된 바와 같이, 인증키 저장 단계 S63은 FiRa 애플릿(13)이 인증키 전달 메시지를 수신함으로써 시작될 수 있다(S71). 인증키 전달 메시지의 포맷은 예를 들어 하기의 표 3과 같이 설계될 수 있으나, 본 개시의 범위가 이에 한정되는 것은 아니다. 상술한 바와 같이, 키 데이터(key data)는 인증키를 의미한다.
Tag Length Description Presence
0xBF76 Variable Application data tag Mandatory
0x7A Variable Add key data Mandatory
0x80 1 ~ 16 Instance UID Mandatory
0x81 1 Status Mandatory
0x82 16 Key data (Encrypted) Mandatory
단계 S72에서, FiRa 애플릿(13)은 인증키 전달 메시지의 태그를 체크할 수 있다. 가령, FiRa 애플릿(13)은 수신된 전달 메시지의 태그가 애플리케이션 데이터 태그(application data tag)인지 여부를 체크할 수 있다.
단계 S73에서, FiRa 애플릿(13)은 ADF의 확장 옵션(extended option) 필드의 설정값을 이용하여 현재 인증 모드가 빠른 인증 모드인지 여부를 판단할 수 있다.
단계 S74에서, FiRa 애플릿(13)은 외부와 보안 채널(secure channel)이 수립되어 있는지 여부를 체크할 수 있다.
단계 S75에서, FiRa 애플릿(13)은 인증키가 존재하는지 여부를 판단할 수 있다. 가령, FiRa 애플릿(13)은 인증키 전달 메시지의 인스턴스 UID를 이용하여 ADF의 애플리케이션 데이터(application data) 필드에 인증키가 존재하는지 여부를 판단할 수 있다. 인증키가 존재하지 않는다는 판단에 응답하여, 단계 S76이 수행될 수 있다.
단계 S76에서, FiRa 애플릿(13)은 인증키를 저장할 수 있다. 가령, FiRa 애플릿(13)은 ADF의 애플리케이션 데이터(application data) 필드에 전달받은 인증키를 저장할 수 있다. 이때, FiRa 애플릿(13)은 보안성 향상을 위해 인증키를 암호화된 상태로 저장할 수도 있다. 가령, 인증키는 보안 채널(secure channel)용 암호화키를 이용하여 암호화될 수도 있다.
경우에 따라, FiRa 애플릿(13)은 인증키가 존재하는 경우에도 전달받은 인증키를 저장할 수도 있다. 이를테면, FiRa 애플릿(13)은 기 존재하는(저장된) 인증키를 전달받은 인증키로 업데이트(교체)할 수도 있다.
단계 S77에서, FiRa 애플릿(13)은 수행 결과를 나타내는 메시지를 생성할 수 있다. 가령, FiRa 애플릿(13)은 수행 결과에 따라 에러 메시지를 생성할 수도 있고(e.g. 메시지 태그 불일치, 인증 모드 불일치, 인증키 존재, 보안 채널 미수립 등의 경우), 저장된 인증키를 포함하는 결과 메시지를 생성할 수도 있다. 이때, 인증키는 보안성 향상을 위해 암호화키에 의해 암호화된 상태로 결과 메시지에 포함될 수도 있다. 가령, 인증키는 보안 채널(secure channel)용 암호화키로 암호화될 수도 있다.
단계 S77에서 생성될 수 있는 결과 메시지의 포맷은 예를 들어 하기의 표 4와 같이 설계될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다.
Tag Length Description Presence
0x7A Variable Add key data Mandatory
0x80 1 ~ 16 Instance UID Mandatory
0x81 1 Status Mandatory
0x82 16 Key data (Encrypted) Mandatory
다시 도 6을 참조하여 설명한다.
단계 S64에서, FiRa 애플릿(13)은 인증키 저장 결과를 애플리케이션(11)에게 전달할 수 있다. 가령, FiRa 애플릿(13)은 상술한 단계 S77에서 생성된 결과 메시지를 애플리케이션(11)에게 전달할 수 있다.
지금까지 도 4 내지 도 7을 참조하여 본 개시의 몇몇 실시예들에 따른 인증키 획득 프로세스(31)에 대하여 설명하였다. 이하에서는, 도 8 내지 도 10을 참조하여 본 개시의 몇몇 실시예들에 따른 인증키 공유 프로세스(32)에 대하여 상세하게 설명하도록 한다.
도 8은 본 개시의 몇몇 실시예들에 따른 인증키 공유 프로세스(32)를 나타내는 예시적인 흐름도이다. 단, 이는 본 개시의 목적을 달성하기 위한 바람직한 실시예일뿐이며, 필요에 따라 일부 단계가 추가되거나 삭제될 수 있음은 물론이다.
도 8에 도시된 바와 같이, 실시예들에 따른 인증키 공유 프로세스(32)는 제1 단말(10)과 제2 단말(20) 간에 보안 채널(secure channel)을 수립하는 단계 S81에서 시작될 수 있다. 'GENERAL AUTHENTICATE' 메시지를 이용하여 보안 채널(secure channel)을 수립하는 세부 과정에 관하여서는 FiRa 스펙을 참조하도록 한다. 또한, 도 8에 도시되어 있지는 않으나, 보안 채널(secure channel)을 수립한 이후에 FiRa 스펙에 따라 제1 단말(10)과 제2 단말(20) 간에 UWB 환경(configuration)을 세팅하는 단계가 더 수행될 수도 있다. UWB 환경을 세팅하는 세부 과정에 관하여서도 FiRa 스펙을 참조하도록 한다.
단계 S82에서, 제1 단말(10)은 인증키 공유 메시지를 생성할 수 있다. 인증키 공유 메시지에는 예를 들어 인증키와 ADF의 UID가 포함될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다. 본 단계의 세부 과정은 도 9에 도시되어 있다.
도 9에 도시된 바와 같이, FiRa 애플릿(13)은 애플리케이션(11)의 인증키 공유 요청에 응답하여 인증키 공유 메시지를 생성하고, 생성된 메시지를 애플리케이션(11)에게 전달할 수 있다(S91 내지 S93). 이때, 인증키는 보안성 향상을 위해 암호화키에 의해 암호화된 상태로 인증키 공유 메시지에 포함될 수도 있다. 가령, 인증키는 보안 채널(secure channel)용 암호화키로 암호화될 수도 있다.
인증키 공유 요청은 예를 들어 FiRa 스펙에 규정된 'TUNNEL'과 'PUT DATA' 커맨드를 통해 구현될 수 있고, 인증키 공유 메시지 전달은 FiRa 스펙에 규정된 'DISPATCH RESPONSE'커맨드를 통해 구현될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다.
단계 S92에서 생성될 수 있는 인증키 공유 메시지의 포맷은 예를 들어 하기의 표 5와 같이 설계될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다.
Tag Length Description Presence
0xBF76 Variable Application data tag Mandatory
0x7A Variable Add key data Mandatory
0x80 1 ~ 16 Instance UID Mandatory
0x81 1 Status Mandatory
0x82 16 Key data (Encrypted) Mandatory
다시 도 8을 참조하여 설명한다.
단계 S83에서, 제1 단말(10)은 인증키 공유 메시지를 제2 단말(20)로 전송할 수 있다. 인증키 공유 메시지의 전송은 예를 들어 FiRa 스펙에 규정된 'DISPATCH REQUEST' 커맨드를 통해 구현될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다.
단계 S84에서, 제2 단말(20)은 인증키 공유 메시지를 수신하고, 메시지에 포함된 인증키를 저장할 수 있다. 본 단계의 세부 과정은 도 9에 도시되어 있다.
도 9에 도시된 바와 같이, 애플리케이션(21)이 인증키 공유 메시지를 수신하여 FiRa 애플릿(23)에게 전달하고, FiRa 애플릿(23)이 인증키를 저장하며, 저장 결과를 애플리케이션(21)에게 전달할 수 있다(S94 내지 S96). 여기서, 인증키 저장 결과의 전달은 예를 들어 FiRa 스펙에 규정된 'DISPATCH RESPONSE' 커맨드를 통해 구현될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다.
단계 S95의 세부 과정은 도 10에 도시되어 있다.
도 10에 도시된 바와 같이, 인증키 저장 단계 S95는 FiRa 애플릿(23)이 인증키 공유 메시지를 수신함으로써 시작될 수 있다(S101). 인증키 공유 메시지의 포맷은 예를 들어 하기의 표 6과 같이 설계될 수 있으나, 본 개시의 범위가 이에 한정되는 것은 아니다. 상술한 바와 같이, 키 데이터(key data)는 인증키를 의미한다.
Tag Length Description Presence
0xBF76 Variable Application data tag Mandatory
0x7A Variable Add key data Mandatory
0x80 1 ~ 16 Instance UID Mandatory
0x81 1 Status Mandatory
0x82 16 Key data (Encrypted) Mandatory
단계 S102에서, FiRa 애플릿(23)은 인증키 공유 메시지의 태그를 체크할 수 있다. 가령, FiRa 애플릿(23)은 수신된 공유 메시지의 태그가 애플리케이션 데이터 태그(application data tag)인지 여부를 체크할 수 있다.
단계 S103에서, FiRa 애플릿(23)은 ADF의 확장 옵션(extended option) 필드의 설정값을 이용하여 현재 인증 모드가 빠른 인증 모드인지 여부를 판단할 수 있다.
단계 S104에서, FiRa 애플릿(23)은 제1 단말(10)과 보안 채널(secure channel)이 수립되어 있는지 여부를 체크할 수 있다.
단계 S105에서, FiRa 애플릿(23)은 인증키가 존재하는지 여부를 판단할 수 있다. 가령, FiRa 애플릿(23)은 인증키 공유 메시지의 인스턴스 UID를 이용하여 ADF의 애플리케이션 데이터(application data) 필드에 인증키가 존재하는지 여부를 판단할 수 있다. 인증키가 존재하지 않는다는 판단에 응답하여, 단계 S106이 수행될 수 있다.
단계 S106에서, FiRa 애플릿(23)은 인증키를 저장할 수 있다. 가령, FiRa 애플릿(23)은 ADF의 애플리케이션 데이터(application data) 필드에 전달받은 인증키를 저장할 수 있다.
경우에 따라, FiRa 애플릿(23)은 인증키가 존재하는 경우에도 전달받은 인증키를 저장할 수도 있다. 이를테면, FiRa 애플릿(23)은 기 존재하는(저장된) 인증키를 전달받은 인증키로 업데이트(교체)할 수도 있다.
단계 S107에서, FiRa 애플릿(23)은 수행 결과를 나타내는 메시지를 생성할 수 있다. 가령, FiRa 애플릿(23)은 수행 결과에 따라 에러 메시지를 생성할 수도 있고(e.g. 메시지 태그 불일치, 인증 모드 불일치, 인증키 존재, 보안 채널 미수립 등의 경우), 저장된 인증키를 포함하는 결과 메시지를 생성할 수도 있다. 이때, 인증키는 보안성 향상을 위해 암호화키에 의해 암호화된 상태로 결과 메시지에 포함될 수도 있다. 가령, 인증키는 보안 채널(secure channel)용 암호화키로 암호화될 수도 있다.
단계 S107에서 생성될 수 있는 결과 메시지의 포맷은 예를 들어 하기의 표 7과 같이 설계될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다.
Tag Length Description Presence
0x7A Variable Add key data Mandatory
0x80 1 ~ 16 Instance UID Mandatory
0x81 1 Status Mandatory
0x82 16 Key data (Encrypted) Mandatory
다시 도 8을 참조하여 설명한다.
단계 S85에서, 제2 단말(20)은 인증키 저장 결과를 제1 단말(10)에게 전달할 수 있다. 가령, 도 9에 도시된 바와 같이, 제2 단말(20)의 애플리케이션(21)이 단계 S96에서 생성된 결과 메시지를 제1 단말(10)의 애플리케이션(11)에게 전달할 수 있다. 여기서, 인증키 저장 결과의 전달은 예를 들어 FiRa 스펙에 규정된 'DISPATCH REQUEST' 커맨드를 통해 구현될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다.
지금까지 도 8 내지 도 10을 참조하여 본 개시의 몇몇 실시예들에 따른 인증키 공유 프로세스(32)에 대하여 설명하였다. 상술한 바에 따르면, 보안 채널(secure channel)을 통해 단말들(10, 20) 간에 인증키가 안전하게 공유될 수 있다. 또한, 사전에 공유된 보안 채널(secure channel)용 암호화키를 이용하여 인증키를 암호화된 상태로 공유함으로써, 단말들(10, 20) 간에 인증키가 더욱 안전하게 공유될 수 있다. 아울러, 이렇게 공유된 인증키를 이용함으로써, 실제 인증 시에는 보안 채널 수립없이 단말들(10, 20) 간에 신속하게 인증이 수행될 수 있다.
이하에서는, 도 11 내지 도 14를 참조하여 본 개시의 몇몇 실시예들에 따른 인증 프로세스(33)에 대하여 상세하게 설명하도록 한다.
도 11은 본 개시의 몇몇 실시예들에 따른 인증 프로세스(33)를 나타내는 예시적인 흐름도이다. 단, 이는 본 개시의 목적을 달성하기 위한 바람직한 실시예일뿐이며, 필요에 따라 일부 단계가 추가되거나 삭제될 수 있음은 물론이다.
도 11에 도시된 바와 같이, 실시예들에 따른 인증 프로세스(33)는 제1 단말(10)이 세션 기초 정보를 생성하는 단계 S111에서 시작될 수 있다. 세션 기초 정보는 세션 데이터를 생성하는데 기초가 되는(또는 이용되는) 정보로서, 예를 들어, ADF의 인스턴스 UID와 랜덤값을 포함할 수 있다. 그러나, 이에 한정되는 것은 아니다.
보다 구체적으로는, 도 12에 도시된 바와 같이, FiRa 애플릿(13)이 애플리케이션(11)의 요청에 응답하여 세션 기초 정보를 생성하고, 생성된 세션 기초 정보를 애플리케이션(11)에게 전달할 수 있다(S121 내지 S123). 세션 기초 정보의 생성 요청은 예를 들어 FiRa 스펙에 규정된 'GET DATA' 커맨드를 통해 구현될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다.
단계 S122의 세부 과정은 도 13에 도시되어 있다.
도 13에 도시된 바와 같이, 세션 기초 정보 생성 단계 S122는 FiRa 애플릿(13)이 요청 메시지를 수신함으로써 시작될 수 있다(S131).
단계 S132에서, FiRa 애플릿(13)은 수신된 요청 메시지의 태그를 체크할 수 있다. 다시 말해, FiRa 애플릿(13)은 수신된 요청 메시지의 태그값이 미리 정의된 세션 기초 정보 관련 메시지의 태그값과 일치하는지 여부를 체크할 수 있다. 도 13은 미리 정의된 태그값이 '0xDA30'인 것을 예시하고 있으나, 이 값은 얼마든지 변경될 수 있다.
단계 S133에서, FiRa 애플릿(13)은 랜덤값을 포함하는 세션 기초 정보를 생성할 수 있다. 상술한 바와 같이, 세션 기초 정보는 랜덤값, ADF(즉, 컨트롤러 측의 ADF)의 인스턴스 UID 등을 포함할 수 있다.
단계 S134에서, FiRa 애플릿(13)은 수행 결과를 나타내는 메시지를 생성할 수 있다. 가령, FiRa 애플릿(13)은 수행 결과에 따라 에러 메시지를 생성할 수도 있고(e.g. 메시지 태그 불일치 등의 경우), 세션 기초 정보를 포함하는 결과 메시지를 생성할 수도 있다.
단계 S134에서 생성될 수 있는 결과 메시지의 포맷은 예를 들어 하기의 표 8과 같이 설계될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다.
Tag Length Description Presence
0xDA30 Variable Fast authentication session basic info Mandatory
0x80 Variable Instance UID of controller Mandatory
0x81 Variable Random value Mandatory
다시 도 11을 참조하여 설명한다.
단계 S112에서, 제1 단말(10)은 생성된 세션 기초 정보를 제2 단말(20)로 전송할 수 있다.
단계 S113-1 및 S113-2에서, 제1 단말(10)과 제2 단말(20) 각각은 세션 기초 정보를 토대로 세션 데이터를 생성할 수 있다. 세션 데이터는 예를 들어 FiRa 스펙에 규정된 바와 같이 세션 ID, 세션키, 서브-세션키 등을 포함할 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다.
보다 구체적으로는, 도 12에 도시된 바와 같이, FiRa 애플릿(13, 23)이 애플리케이션(11, 21)의 요청에 응답하여 세션 데이터를 생성하고, 생성된 세션 데이터를 애플리케이션(11, 21)에게 전달할 수 있다(S124-1 내지 S126-1, S124-2 내지 S126-2). 세션 데이터의 생성 요청은 예를 들어 FiRa 스펙에 규정된 'PUT DATA' 커맨드와 'TERMINATE SESSION' 메시지를 통해 구현될 수 있을 것이나, 본 개시의 범위가 이에 한정되는 것은 아니다.
단계 S125-1과 S125-2의 세부 과정은 도 14에 도시되어 있다.
도 14에 도시된 바와 같이, 세션 데이터 생성 단계 S125-2(또는 S125-1)는 FiRa 애플릿(23)이 요청 메시지를 수신함으로써 시작될 수 있다(S141).
단계 S142에서, FiRa 애플릿(23)은 수신된 요청 메시지의 태그를 체크할 수 있다. 구체적으로, FiRa 애플릿(23)은 수신된 요청 메시지의 태그가 세션 데이터 태그(session data tag)인지 여부를 확인할 수 있다. 도 15에서 요청 메시지의 태그를 '0xBF78'과 비교하는 것은 FiRa 스펙에 규정된 세션 데이터 태그(session data tag)의 값이 '0xBF78'이기 때문이다.
단계 S141에서 수신될 수 있는 요청 메시지의 포맷은 예를 들어 하기의 표 9와 같이 설계될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다. 하기의 표 9에서 각 필드에 대한 자세한 설명은 FiRa 스펙을 참조하도록 한다.
Tag Length Description Presence
0xBF78 Variable Session info Mandatory
0xA5 Variable Secure ranging info Mandatory
0x80 Variable UWB_SESSION_KEY_INFO
(InstanceUID|RandomValue) 		Mandatory
0x81 Variable UWB_SUB_SESSION_KEY_INFO Option
단계 S143에서, FiRa 애플릿(23)은 ADF의 확장 옵션(extended option) 필드의 설정값을 이용하여 현재 인증 모드가 빠른 인증 모드인지 여부를 판단할 수 있다.
단계 S144에서, FiRa 애플릿(23)은 세션키를 포함하는 세션 데이터를 생성할 수 있다. 여기서, 세션 데이터는 FiRa 스펙에 규정된 바와 같이 UWB 레인징을 위한 데이터일 수 있다. 보다 자세하게는, FiRa 애플릿(23)은 수신된 세션 기초 정보의 ADF 인스턴스 UID를 이용하여 ADF의 애플리케이션 데이터(application data) 필드로부터 인증키를 획득하고, 획득된 인증키와 ADF 인스턴스 UID 및 랜덤값을 이용하여 세션 데이터(e.g. 세션 ID, 세션키, 서브-세션키)를 생성할 수 있다. 다만, 세션 데이터를 생성하는 구체적인 방식은 실시예에 따라 달라질 수 있다.
일 실시예에서, FiRa 애플릿(23)은 ADF의 인스턴스 UID와 랜덤값을 인증키로 암호화하여 암호화 데이터를 생성하고, 생성된 암호화 데이터로부터 세션 ID와 세션키를 도출할 수 있다. 가령, 암호화 데이터의 일부(e.g. 0-4 bytes)가 세션 ID가 되고, 암호화 데이터의 해시 값이 세션키가 될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다. 본 실시예에 따르면, 랜덤값과 사전 공유된 인증키를 이용하여 세션 ID와 세션키를 생성되는 바, 보안 채널(secure channel)이 수립되지 않더라도 UWB 레인징 기반 인증의 보안성이 충분히 담보될 수 있다.
다른 실시예에서는, FiRa 애플릿(23)이 사전에 공유된 보안 채널(secure channel)용 암호화키를 더 이용하여 세션 데이터를 생성할 수 있다. 가령, FiRa 애플릿(23)은 보안 채널(secure channel)용 암호화키를 초기 벡터(initial vector)로 이용하고, ADF의 인스턴스 UID와 랜덤값을 인증키로 암호화하여(e.g. AES 알고리즘을 이용하여 암호화) 암호화 데이터를 생성할 수 있다. 또한, FiRa 애플릿(23)은 앞선 실시예와 유사한 방식으로 생성된 암호화 데이터로부터 세션 ID와 세션키를 도출할 수 있다. 이러한 경우, UWB 레인징 기반 인증의 보안성이 더욱 향상될 수 있다.
단계 S145에서, FiRa 애플릿(23)은 수행 결과를 나타내는 메시지를 생성할 수 있다. 가령, FiRa 애플릿(23)은 수행 결과에 따라 에러 메시지를 생성할 수도 있고(e.g. 메시지 태그 불일치, 인증 모드 불일치 등의 경우), 세션 데이터를 포함하는 결과 메시지를 생성할 수도 있다.
다시 도 11을 참조하여 설명한다.
단계 S114-1 및 S114-2에서, 제1 단말(10)과 제2 단말(20) 각각은 생성된 세션 데이터를 토대로 UWB 레인징(ranging)을 위한 데이터를 설정할 수 있다. 레인징 데이터는 예를 들어 FiRa 스펙에 규정된 바와 같이 세션 데이터를 포함할 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다.
보다 구체적으로는, 도 12에 도시된 바와 같이, FiRa 애플릿(13, 23)이 애플리케이션(11, 21)의 요청에 응답하여 SUS 애플릿(14, 24)으로 레인징 데이터를 전송함으로써 레인징 데이터가 설정될 수 있다(S127-1 및 S128-1, S127-2 및 S128-2). 레인징 데이터의 생성 요청은 예를 들어 FiRa 스펙에 규정된 'PUT DATA' 커맨드를 통해 구현될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다. 레인징 데이터 설정과 관련하여서는 FiRa 스펙을 더 참조하도록 한다.
다시 도 11을 참조하여 설명한다.
단계 S115에서, 제1 단말(10)과 제2 단말(20) 간에 UWB 레인징이 수행될 수 있다. UWB 레인징의 세부 과정에 관하여서는 FiRa 스펙을 참조하도록 한다.
지금까지 도 11 내지 도 14를 참조하여 본 개시의 몇몇 실시예들에 따른 인증 프로세스(33)에 대하여 설명하였다. 상술한 바에 따르면, 사전에 공유된 인증키와 랜덤값을 이용하여 UWB 레인징을 위한 세션키가 안전하게 생성될 수 있다. 이에 따라, 보안 채널(secure channel)을 사용(수립)하지 않고도 안전한 방식으로 단말들(10, 20) 간에 인증이 수행될 수 있고, 인증에 소요되는 시간은 크게 감소될 수 있다. 뿐만 아니라, 인증 시에 소모되는 전력도 최소화될 수 있다.
이하에서는, 도 15 내지 도 17을 참조하여 본 개시의 몇몇 실시예들에 따른 인증키 삭제 프로세스(34)에 대하여 상세하게 설명하도록 한다.
도 15는 본 개시의 몇몇 실시예들에 따른 인증키 삭제 프로세스(34)를 나타내는 예시적인 흐름도이다. 단, 이는 본 개시의 목적을 달성하기 위한 바람직한 실시예일뿐이며, 필요에 따라 일부 단계가 추가되거나 삭제될 수 있음은 물론이다.
도 15에 도시된 바와 같이, 실시예들에 따른 인증키 삭제 프로세스(34)는 제1 단말(10)과 제2 단말(20) 간에 보안 채널을 수립하는 단계 S151에서 시작될 수 있다.
단계 S152에서, 제1 단말(10)은 인증키 삭제 요청 메시지를 생성할 수 있다. 본 단계의 세부 과정은 도 16에 도시되어 있다.
도 16에 도시된 바와 같이, FiRa 애플릿(13)은 애플리케이션(11)의 인증키 삭제 요청에 응답하여 ADF(즉, 삭제될 컨트롤러 측의 ADF)의 인스턴스 UID를 포함하는 인증키 삭제 요청 메시지를 생성하고, 생성된 메시지를 애플리케이션(11)에게 전달할 수 있다(S161 내지 S163). 인증키 삭제 요청은 예를 들어 FiRa 스펙에 규정된 'TUNNEL'과 'PUT DATA' 커맨드를 통해 구현될 수 있고, 인증키 삭제 요청 메시지 전달은 FiRa 스펙에 규정된 'DISPATCH RESPONSE' 커맨드를 통해 구현될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다.
다시 도 11을 참조하여 설명한다.
단계 S153에서, 제1 단말(10)은 인증키 삭제 요청 메시지를 제2 단말(20)로 전송할 수 있다.
단계 S154에서, 제2 단말(20)은 인증키를 삭제할 수 있다. 본 단계의 세부 과정은 도 16에 도시되어 있다.
도 16에 도시된 바와 같이, FiRa 애플릿(23)은 애플리케이션(21)의 인증키 삭제 요청(e.g. 인증키 삭제 요청 메시지의 수신)에 응답하여 인증키를 삭제하며, 삭제 결과를 애플리케이션(21)에게 전달할 수 있다(S164 내지 S166). 삭제 결과의 전달은 예를 들어 FiRa 스펙에 규정된 'DISPATCH RESPONSE' 커맨드를 통해 구현될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다.
단계 S165의 세부 과정은 도 17에 도시되어 있다.
도 17에 도시된 바와 같이, 인증키 삭제 단계 S165는 FiRa 애플릿(23)이 애플리케이션(21)으로부터 요청 메시지를 수신하는 단계 S171에서 시작될 수 있다. 예를 들어, FiRa 애플릿(23)은 키 데이터 삭제 태그와 ADF의 인스턴스 UID를 포함하는 인증키 삭제 요청 메시지를 수신할 수 있다.
단계 S171에서 수신될 수 있는 요청 메시지의 포맷은 예를 들어 하기의 표 10과 같이 설계될 수 있다. 그러나, 본 개시의 범위가 이에 한정되는 것은 아니다. 하기의 표 10에서, '0x7B' 값은 인증키 삭제 프로세스와 관련하여 새롭게 정의된 메시지의 태그값으로서, 그 값은 얼마든지 변경될 수 있다.
Tag Length Description Presence
0xBF76 Variable Application data tag Mandatory
0x7B Variable Delete key data Mandatory
0x80 1 ~ 16 Instance UID Mandatory
단계 S172에서, FiRa 애플릿(23)은 수신된 요청 메시지의 태그를 체크할 수 있다. 가령, FiRa 애플릿(23)은 수신된 요청 메시지의 태그가 애플리케이션 데이터 태그(application data tag)인지 여부를 체크할 수 있다.
단계 S173에서, FiRa 애플릿(23)은 ADF의 확장 옵션(extended option) 필드의 설정값을 이용하여 현재 인증 모드가 빠른 인증 모드인지 여부를 판단할 수 있다.
단계 S174에서, FiRa 애플릿(23)은 제1 단말(10)과 보안 채널(secure channel)이 수립되어 있는지 여부를 체크할 수 있다.
단계 S175에서, FiRa 애플릿(23)은 인증키가 존재하는지 여부를 판단할 수 있다. 가령, FiRa 애플릿(23)은 인증키 삭제 요청 메시지에 포함된 ADF 인스턴스 UID를 이용하여 ADF의 애플리케이션 데이터(application data) 필드에 인증키가 존재하는지 여부를 판단할 수 있다. 인증키가 존재한다는 판단에 응답하여, 단계 S176이 수행될 수 있다.
단계 S176에서, FiRa 애플릿(23)은 인증키를 삭제할 수 있다. 다시 말해, FiRa 애플릿(23)은 ADF의 애플리케이션 데이터(application data) 필드에 저장된 인증키를 삭제할 수 있다.
단계 S177에서, FiRa 애플릿(23)은 수행 결과를 나타내는 메시지를 생성할 수 있다. 가령, FiRa 애플릿(23)은 수행 결과에 따라 에러 메시지를 생성할 수도 있고(e.g. 메시지 태그 불일치, 인증 모드 불일치, 인증키 미존재, 보안 채널 미수립 등의 경우), 삭제 성공을 알리는 결과 메시지를 생성할 수도 있다.
다시 도 15를 참조하여 설명한다.
단계 S155에서, 제2 단말(20)은 인증키 삭제 결과를 제1 단말(10)에게 전달할 수 있다.
단계 S156에서, 제1 단말(10)도 인증키를 삭제할 수 있다. 본 단계는 상술한 단계 S154와 유사한 바, 이에 대한 설명은 생략하도록 한다(단계 S167 내지 S169에 대한 설명은 단계 S164 내지 S166 참조).
지금까지 도 14 내지 도 17을 참조하여 본 개시의 몇몇 실시예들에 따른 인증키 삭제 프로세스(34)에 대하여 설명하였다.
한편, 현행 FiRa 스펙에 따르면, FiRa 애플릿(e.g. 13)이 관리하는 ADF 리스트를 확인할 수 있는 방법이 정의되어 있지 않고, 인스턴스 UID를 알지 못하면 특정 ADF의 존재 여부를 확인할 수가 없다. 가령, 인스턴스 UID를 모르면, 'SELECT ADF' 커맨드를 이용하여 특정 ADF의 존재 여부를 확인할 수가 없다. 따라서, FiRa 애플릿(e.g. 13)이 관리하는 ADF의 리스트를 얻어올 수 있는 커맨드(또는 메시지)가 추가로 규정될 필요가 있다. 이러한 커맨드는 'GET DATA'의 커맨드와 ADF 정보와 관련된 새로운 태그값(e.g. '0xBFAD')을 통해 용이하게 구현될 수 있으며, 해당 커맨드에 대한 응답 메시지는 예를 들어 표 11에 기재된 바와 같이 설계될 수 있다.
Tag Length Description Presence
0xBFAD Variable ADF Info Mandatory
0x80 1 ~ 16 OID Mandatory
0x81 Variable Instance UID Option
이하에서는, 도 18을 참조하여 상술한 제1 단말(10) 및/또는 제2 단말(20)을 구현할 수 있는 예시적인 컴퓨팅 장치(180)에 대하여 간략하게 설명하도록 한다.
도 18은 컴퓨팅 장치(180)의 하드웨어 구성도를 예시한다.
도 18에 도시된 바와 같이, 컴퓨팅 장치(180)는 하나 이상의 프로세서(181), 버스(183), 통신 인터페이스(182), 프로세서(181)에 의하여 수행되는 컴퓨터 프로그램(186)을 로드(load)하는 메모리(184)와, 컴퓨터 프로그램(186)을 저장하는 스토리지(185)를 포함할 수 있다.
프로세서(181)는 컴퓨팅 장치(180)의 각 구성의 전반적인 동작을 제어할 수 있다. 프로세서(181)는 CPU(Central Processing Unit), MPU(Micro Processor Unit), MCU(Micro Controller Unit), GPU(Graphic Processing Unit) 또는 본 발명의 기술 분야에 잘 알려진 임의의 형태의 프로세서 중 적어도 하나를 포함하여 구성될 수 있다. 또한, 프로세서(181)는 본 발명의 다양한 실시예들에 따른 방법/동작을 실행하기 위한 적어도 하나의 애플릿, 애플리케이션 및/또는 프로그램에 대한 연산을 수행할 수 있다. 컴퓨팅 장치(180)는 하나 이상의 프로세서(181)를 구비할 수 있다.
다음으로, 메모리(184)는 각종 데이터, 명령 및/또는 정보를 저장할 수 있다. 메모리(184)는 본 발명의 다양한 실시예들에 따른 방법/동작들을 실행하기 위하여 스토리지(185)로부터 하나 이상의 컴퓨터 프로그램(186)을 로드(load)할 수 있다. 메모리(184)의 예시는 RAM이 될 수 있으나, 이에 한정되는 것은 아니다.
다음으로, 버스(183)는 컴퓨팅 장치(180)의 구성 요소 간 통신 기능을 제공할 수 있다. 버스(183)는 주소 버스(Address Bus), 데이터 버스(Data Bus) 및 제어 버스(Control Bus) 등 다양한 형태의 버스로 구현될 수 있다.
다음으로, 통신 인터페이스(182)는 컴퓨팅 장치(180)의 유무선 통신을 지원할 수 있다. 예를 들어, 통신 인터페이스(182)는 다양한 유형의 근접 통신을 지원할 수 있고, 그 외에도 다양한 통신 방식을 더 지원할 수도 있다. 통신 인터페이스(182)는 본 개시의 기술 분야에 잘 알려진 통신 모듈을 포함하여 구성될 수 있다.
다음으로, 스토리지(185)는 하나 이상의 컴퓨터 프로그램(186)을 비임시적으로 저장할 수 있다. 스토리지(185)는 플래시 메모리 등과 같은 비휘발성 메모리, 하드 디스크, 착탈형 디스크, 또는 본 개시가 속하는 기술 분야에서 잘 알려진 임의의 형태의 컴퓨터로 읽을 수 있는 기록 매체를 포함하여 구성될 수 있다.
컴퓨터 프로그램(186)은 본 개시의 다양한 실시예들에 따른 방법/동작들이 구현된 하나 이상의 인스트럭션을 포함할 수 있다. 컴퓨터 프로그램(186)이 메모리(184)에 로드 되면, 프로세서(181)는 로드된 인스트럭션을 실행시킴으로써 본 개시의 다양한 실시예들에 따른 방법/동작들을 수행할 수 있다.
예를 들어, 컴퓨터 프로그램(186)은 애플리케이션(11)과 애플릿(12)의 동작들을 구현하는 인스트럭션들을 포함할 수 있다. 이러한 경우, 컴퓨팅 장치(180)를 통해 본 개시의 몇몇 실시예들에 따른 제1 단말(10)이 구현될 수 있다.
다른 예로서, 컴퓨터 프로그램(186)은 애플리케이션(21)과 애플릿(22)의 동작들을 구현하는 인스트럭션들을 포함할 수 있다. 이러한 경우, 컴퓨팅 장치(180)를 통해 본 개시의 몇몇 실시예들에 따른 제2 단말(20)이 구현될 수 있다.
지금까지 도 18을 참조하여 본 개시의 몇몇 실시예에 따른 단말들(10, 20)을 구현할 수 있는 예시적인 컴퓨팅 장치(180)에 대하여 설명하였다.
지금까지 도 1 내지 도 18을 참조하여 설명된 본 개시의 기술적 사상은 컴퓨터가 읽을 수 있는 매체 상에 컴퓨터가 읽을 수 있는 코드로 구현될 수 있다. 상기 컴퓨터로 읽을 수 있는 기록 매체는, 예를 들어 이동형 기록 매체(CD, DVD, 블루레이 디스크, USB 저장 장치, 이동식 하드 디스크)이거나, 고정식 기록 매체(ROM, RAM, 컴퓨터 구비 형 하드 디스크)일 수 있다. 상기 컴퓨터로 읽을 수 있는 기록 매체에 기록된 상기 컴퓨터 프로그램은 인터넷 등의 네트워크를 통하여 다른 컴퓨팅 장치에 전송되어 상기 다른 컴퓨팅 장치에 설치될 수 있고, 이로써 상기 다른 컴퓨팅 장치에서 사용될 수 있다.
이상 첨부된 도면을 참조하여 본 개시의 실시예들을 설명하였지만, 본 개시의 실시예들이 속하는 기술분야에서 통상의 지식을 가진 자는 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 본 개시의 실시예들이 다른 구체적인 형태로도 실시될 수 있다는 것을 이해할 수 있다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적인 것이 아닌 것으로 이해해야만 한다. 본 개시의 보호 범위는 아래의 청구범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 개시에 의해 정의되는 기술적 사상의 권리범위에 포함되는 것으로 해석되어야 할 것이다.

Claims (22)

  1. FiRa(Fine Ranging) 애플릿이 구동되는 제1 단말에서 보안 채널(secure channel) 미사용 모드로 인증을 수행하는 방법에 있어서,
    랜덤값을 포함하는 세션 기초 정보를 생성하는 단계;
    상기 생성된 세션 기초 정보를 제2 단말로 전송하는 단계;
    상기 제2 단말과 사전에 공유된 인증키를 이용하여 상기 생성된 세션 기초 정보로부터 세션키를 포함하는 세션 데이터를 생성하는 단계; 및
    상기 생성된 세션 데이터를 이용하여 상기 제2 단말과 UWB(Ultra-Wide Band) 레인징을 수행하는 단계를 포함하는,
    인증 방법.
  2. 제1항에 있어서,
    상기 세션 기초 정보는 ADF(Application Dedicated File)의 인스턴스 UID(Unique IDentifier)를 더 포함하는,
    인증 방법.
  3. 제2항에 있어서,
    상기 세션 데이터를 생성하는 단계는,
    상기 랜덤값과 상기 인스턴스 UID를 상기 인증키로 암호화하여 암호화 데이터를 생성하는 단계; 및
    상기 암호화 데이터로부터 상기 세션키를 도출하는 단계를 포함하는,
    인증 방법.
  4. 제3항에 있어서,
    상기 암호화 데이터를 생성하는 단계는,
    사전 공유된 보안 채널용 암호화키를 더 이용하여 상기 암호화 데이터를 생성하는 단계를 포함하는,
    인증 방법.
  5. 제2항에 있어서,
    상기 세션 데이터는 세션 ID를 더 포함하고,
    상기 세션 데이터를 생성하는 단계는,
    상기 랜덤값과 상기 인스턴스 UID를 상기 인증키로 암호화하여 암호화 데이터를 생성하는 단계; 및
    상기 암호화 데이터로부터 상기 세션 ID를 도출하는 단계를 포함하는,
    인증 방법.
  6. 제1항에 있어서,
    상기 세션 데이터를 생성하는 단계는,
    ADF(Application Dedicated File)의 특정 필드의 설정값을 이용하여 현재 인증 모드를 판단하는 단계; 및
    상기 현재 인증 모드가 상기 보안 채널 미사용 모드라는 판단에 응답하여, 상기 세션 데이터를 생성하는 단계를 포함하는,
    인증 방법.
  7. 제6항에 있어서,
    상기 특정 필드는 상기 ADF의 확장 옵션(extended option) 필드인,
    인증 방법.
  8. 제1항에 있어서,
    상기 세션 기초 정보 및 상기 세션 데이터는 상기 제1 단말의 보안 영역(Secure Element)에서 구동되는 상기 FiRa 애플릿에 의해 생성되는 것인,
    인증 방법.
  9. FiRa(Fine Ranging) 애플릿이 구동되는 제2 단말에서 보안 채널(secure channel) 미사용 모드로 인증을 수행하는 방법에 있어서,
    제1 단말로부터 랜덤값을 포함하는 세션 기초 정보를 수신하는 단계;
    상기 제1 단말과 사전에 공유된 인증키를 이용하여 상기 수신된 세션 기초 정보로부터 세션키를 포함하는 세션 데이터를 생성하는 단계; 및
    상기 생성된 세션 데이터를 이용하여 상기 제1 단말과 UWB(Ultra-Wide Band) 레인징을 수행하는 단계를 포함하는,
    인증 방법.
  10. 제9항에 있어서,
    상기 세션 기초 정보는 ADF(Application Dedicated File)의 인스턴스 UID(Unique IDentifier)를 더 포함하고,
    상기 인증키는 상기 ADF의 특정 필드에 저장되어 있으며,
    상기 세션 데이터를 생성하는 단계는,
    상기 세션 기초 정보에 포함된 상기 인스턴스 UID를 이용하여 상기 특정 필드에서 상기 인증키를 획득하는 단계; 및
    상기 인증키를 이용하여 상기 세션 데이터를 생성하는 단계를 포함하는,
    인증 방법.
  11. 제9항에 있어서,
    상기 세션 데이터를 생성하는 단계는,
    ADF(Application Dedicated File)의 특정 필드의 설정값을 이용하여 현재 인증 모드를 판단하는 단계; 및
    상기 현재 인증 모드가 상기 보안 채널 미사용 모드라는 판단에 응답하여, 상기 세션 데이터를 생성하는 단계를 포함하는,
    인증 방법.
  12. FiRa(Fine Ranging) 애플릿이 구동되는 제1 단말에서 보안 채널(secure channel) 미사용 모드로 인증을 수행하는 방법에 있어서,
    인증키를 획득하는 단계 - 상기 인증키는 상기 보안 채널 미사용 모드로 제2 단말과 UWB(Ultra-Wide Band) 레인징 기반 인증을 수행하기 위해 이용되는 키임 - ;
    ADF(Application Dedicated File)의 특정 필드에 상기 획득된 인증키를 저장하는 단계; 및
    상기 획득된 인증키를 보안 채널을 통해 상기 제2 단말과 공유하는 단계를 포함하는,
    인증 방법.
  13. 제12항에 있어서,
    상기 특정 필드는 상기 ADF의 애플리케이션 데이터(application data) 필드인,
    인증 방법.
  14. 제12항에 있어서,
    상기 인증키를 획득하는 단계는,
    상기 FiRa 애플릿이, 상기 인증키를 생성하는 단계를 포함하는,
    인증 방법.
  15. 제14항에 있어서,
    상기 인증키를 생성하는 단계는,
    상기 ADF의 인스턴스 UID(Unique IDentifier)를 이용하여 상기 특정 필드에 기 저장된 인증키가 존재하는 여부를 판단하는 단계; 및
    미존재 판단에 응답하여, 상기 인증키를 생성하는 단계를 포함하는,
    인증 방법.
  16. 제14항에 있어서,
    상기 인증키를 생성하는 단계는,
    상기 ADF의 다른 특정 필드의 설정값을 이용하여 현재 인증 모드를 판단하는 단계; 및
    상기 현재 인증 모드가 상기 보안 채널 미사용 모드라는 판단에 응답하여, 상기 인증키를 생성하는 단계를 포함하는,
    인증 방법.
  17. 제12항에 있어서,
    상기 인증키를 획득하는 단계는,
    상기 제1 단말에서 구동되는 애플리케이션이 외부로부터 상기 인증키를 수신하는 단계를 포함하고,
    상기 인증키를 저장하는 단계는,
    상기 FiRa 애플릿이 상기 수신된 인증키를 저장하는 단계를 포함하는,
    인증 방법.
  18. 제12항에 있어서,
    상기 획득된 인증키를 저장하는 단계는,
    사전에 공유된 보안 채널용 암호화키를 이용하여 상기 획득된 인증키를 암호화하여 저장하는 단계를 포함하는,
    인증 방법.
  19. FiRa(Fine Ranging) 애플릿이 구동되는 제2 단말에서 보안 채널(secure channel) 미사용 모드로 인증을 수행하는 방법에 있어서,
    보안 채널을 통해 제1 단말로부터 인증키를 수신하는 단계 - 상기 인증키는 상기 보안 채널 미사용 모드로 상기 제1 단말과 UWB(Ultra-Wide Band) 레인징 기반 인증을 수행하기 위해 이용되는 키임 - ; 및
    ADF(Application Dedicated File)의 특정 필드에 상기 수신된 인증키를 저장하는 단계를 포함하는,
    인증 방법.
  20. 제19항에 있어서,
    상기 수신된 인증키를 저장하는 단계는,
    상기 ADF의 다른 특정 필드에 설정된 값을 이용하여 현재 인증 모드를 판단하는 단계; 및
    상기 현재 인증 모드가 상기 보안 채널 미사용 모드라는 판단에 응답하여, 상기 수신된 인증키를 저장하는 단계를 포함하는,
    인증 방법.
  21. 제19항에 있어서,
    상기 제2 단말은 상기 제1 단말로부터 상기 ADF의 인스턴스 UID(Unique IDentifier)를 더 수신하고,
    상기 수신된 인증키를 저장하는 단계는,
    상기 수신된 인스턴스 UID를 이용하여 상기 특정 필드에 기 저장된 인증키가 존재하는 여부를 판단하는 단계; 및
    미존재 판단에 응답하여, 상기 수신된 인증키를 저장하는 단계를 포함하는,
    인증 방법.
  22. 제19항에 있어서,
    상기 제1 단말로부터 ADF의 인스턴스 UID(Unique IDentifier)를 포함하는 인증키 삭제 요청 메시지를 수신하는 단계;
    상기 인스턴스 UID를 이용하여 상기 특정 필드에 기 저장된 인증키가 존재하는지 여부를 판단하는 단계; 및
    존재 판단에 응답하여, 상기 기 저장된 인증키를 삭제하는 단계를 더 포함하는,
    인증 방법.
KR1020220044980A 2021-07-07 2022-04-12 근접 통신 기능을 구비한 단말들 간의 인증 방법 및 이 방법이 구현된 단말들 KR20230008595A (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP22182495.6A EP4117230A1 (en) 2021-07-07 2022-07-01 Authentication method between terminals having proximity communication function and terminals implementing the same method
US17/858,435 US20230013613A1 (en) 2021-07-07 2022-07-06 Authentication method between terminals having proximity communication function and terminals implementing the same method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR20210089210 2021-07-07
KR1020210089210 2021-07-07

Publications (1)

Publication Number Publication Date
KR20230008595A true KR20230008595A (ko) 2023-01-16

Family

ID=85109904

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020220044980A KR20230008595A (ko) 2021-07-07 2022-04-12 근접 통신 기능을 구비한 단말들 간의 인증 방법 및 이 방법이 구현된 단말들

Country Status (1)

Country Link
KR (1) KR20230008595A (ko)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20210157155A (ko) 2020-06-19 2021-12-28 주식회사 엘지유플러스 도어락의 원격 개폐를 위한 서버의 동작 방법 및 그 서버

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20210157155A (ko) 2020-06-19 2021-12-28 주식회사 엘지유플러스 도어락의 원격 개폐를 위한 서버의 동작 방법 및 그 서버

Similar Documents

Publication Publication Date Title
Santoso et al. Securing IoT for smart home system
AU2018250465B2 (en) Secondary device as key for authorizing access to resources
KR102036770B1 (ko) 무선 장치의 인증을 위한 방법 및 장치
US20120155643A1 (en) Secure protocol for peer-to-peer network
EP3940989A1 (en) Communication method and communication device
US20160242025A1 (en) Porting wifi settings
KR20160078475A (ko) 키 구성 방법, 시스템, 및 장치
EP2741475B1 (en) Method and apparatus for allocating an internet protocol address to a client device
CN111182546B (zh) 接入无线网络的方法、设备及系统
WO2016180091A1 (zh) 一种网络接入方法及装置
CN107104484B (zh) 一种通过充电装置对用户设备进行充电的方法与设备
CN104125567A (zh) 家庭基站接入网络侧的鉴权方法、装置及家庭基站
US9137103B2 (en) Configuring devices in a secured network
KR102292007B1 (ko) 단거리 통신을 사용한 네트워크 노드 보안
CN103997797A (zh) 一种物联网的组建方法及物联网装置
WO2022111016A1 (zh) 移动网络接入系统、方法、存储介质及电子设备
KR20190101831A (ko) 근거리 통신 연결을 위한 전자 장치 및 방법
WO2023282956A1 (en) Access point, method and non-transitory computer-readable medium for access point
TW201628446A (zh) 無線通訊方法、無線通訊裝置、智慧卡、終端機及通訊系統
KR101732007B1 (ko) 컴퓨팅 장치의 위치 기반 파일 접근 제어 방법
CN115669022A (zh) 电子设备提供基于测距的服务的方法和电子设备
US10531296B2 (en) Method for loading a subscription into an embedded security element of a mobile terminal
KR20230008595A (ko) 근접 통신 기능을 구비한 단말들 간의 인증 방법 및 이 방법이 구현된 단말들
EP4117230A1 (en) Authentication method between terminals having proximity communication function and terminals implementing the same method
JP6640949B2 (ja) 接続情報送信装置、方法およびプログラム