WO2022154646A1 - 초광대역통신 기반 보안 레인징을 위한 방법 및 장치 - Google Patents
초광대역통신 기반 보안 레인징을 위한 방법 및 장치 Download PDFInfo
- Publication number
- WO2022154646A1 WO2022154646A1 PCT/KR2022/000934 KR2022000934W WO2022154646A1 WO 2022154646 A1 WO2022154646 A1 WO 2022154646A1 KR 2022000934 W KR2022000934 W KR 2022000934W WO 2022154646 A1 WO2022154646 A1 WO 2022154646A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- uwb
- uwbs
- secure
- application
- ranging
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 132
- 238000004891 communication Methods 0.000 title description 45
- 230000004044 response Effects 0.000 description 41
- 230000006870 function Effects 0.000 description 39
- 238000005516 engineering process Methods 0.000 description 18
- 238000012545 processing Methods 0.000 description 13
- 101100012910 Plasmodium falciparum (isolate FC27 / Papua New Guinea) FIRA gene Proteins 0.000 description 9
- 238000010586 diagram Methods 0.000 description 8
- 239000003999 initiator Substances 0.000 description 8
- 238000013461 design Methods 0.000 description 7
- 230000000977 initiatory effect Effects 0.000 description 7
- 230000008569 process Effects 0.000 description 7
- 230000008901 benefit Effects 0.000 description 6
- 238000007726 management method Methods 0.000 description 6
- 230000003068 static effect Effects 0.000 description 6
- 238000012546 transfer Methods 0.000 description 6
- 238000012795 verification Methods 0.000 description 5
- 238000004590 computer program Methods 0.000 description 4
- 230000002093 peripheral effect Effects 0.000 description 4
- 239000008186 active pharmaceutical agent Substances 0.000 description 3
- PCTMTFRHKVHKIS-BMFZQQSSSA-N (1s,3r,4e,6e,8e,10e,12e,14e,16e,18s,19r,20r,21s,25r,27r,30r,31r,33s,35r,37s,38r)-3-[(2r,3s,4s,5s,6r)-4-amino-3,5-dihydroxy-6-methyloxan-2-yl]oxy-19,25,27,30,31,33,35,37-octahydroxy-18,20,21-trimethyl-23-oxo-22,39-dioxabicyclo[33.3.1]nonatriaconta-4,6,8,10 Chemical compound C1C=C2C[C@@H](OS(O)(=O)=O)CC[C@]2(C)[C@@H]2[C@@H]1[C@@H]1CC[C@H]([C@H](C)CCCC(C)C)[C@@]1(C)CC2.O[C@H]1[C@@H](N)[C@H](O)[C@@H](C)O[C@H]1O[C@H]1/C=C/C=C/C=C/C=C/C=C/C=C/C=C/[C@H](C)[C@@H](O)[C@@H](C)[C@H](C)OC(=O)C[C@H](O)C[C@H](O)CC[C@@H](O)[C@H](O)C[C@H](O)C[C@](O)(C[C@H](O)[C@H]2C(O)=O)O[C@H]2C1 PCTMTFRHKVHKIS-BMFZQQSSSA-N 0.000 description 2
- 238000013475 authorization Methods 0.000 description 2
- 238000005259 measurement Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000009795 derivation Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
Images
Classifications
-
- 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]
-
- 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/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
- H04W12/0431—Key distribution or pre-distribution; Key agreement
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/30—Security of mobile devices; Security of mobile applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/30—Security of mobile devices; Security of mobile applications
- H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/60—Context-dependent security
- H04W12/69—Identity-dependent
-
- 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
본 개시는 UWB 보안 레인징을 위한 방법을 개시한다. 본 개시의 일 실시예에 따른 전자 장치의 방법은 보안 레인징을 위한 레인징 데이터 세트를 설정하기 위한 요청을 보안 컴포넌트로 전송하는 동작, 레인징 데이터 세트를 UWB 서브시스템으로 전달하기 위한 요청을 보안 컴포넌트로 전송하는 동작을 포함할 수 있다. 여기서, 레인징 데이터 세트는 프레임워크를 통해 보안 컴포넌트와 UWB 서브시스템 사이에 설정된 보안 채널을 이용하여 보안 컴포넌트로부터 상기 UWB 서브시스템으로 전달될 수 있다.
Description
본 개시는 UWB 통신에 관한 것으로, 보다 상세하게는 UWB 기반의 보안 레인징을 위한 방법 및 장치에 관한 것이다.
인터넷은 인간이 정보를 생성하고 소비하는 인간 중심의 연결 망에서, 사물 등 분산된 구성 요소들 간에 정보를 주고 받아 처리하는 IoT (Internet of Things, 사물 인터넷) 망으로 진화하고 있다. 클라우드 서버 등과의 연결을 통한 빅데이터 (Big data) 처리 기술 등이 IoT 기술에 결합된 IoE(Internet of Everything) 기술도 대두되고 있다. IoT를 구현하기 위해서는, 센싱 기술, 유무선 통신 및 네트워크 인프라, 서비스 인터페이스 기술, 및 보안 기술과 같은 기술 요소 들이 요구된다. 최근에는 사물간의 연결을 위한 센서 네트워크(sensor network), 사물 통신 (Machine to Machine, M2M), MTC(Machine Type Communication) 등의 기술이 연구되고 있다.
IoT 환경에서는 연결된 사물들에서 생성된 데이터를 수집, 분석하여 인간의 삶에 새로운 가치를 창출하는 지능형 IT(Internet Technology) 서비스가 제공될 수 있다. IoT는, 기존의 IT(information technology) 기술과 다양한 산업 간의 융합 및 복합을 통하여, 스마트홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 스마트 그리드, 헬스 케어, 스마트 가전, 첨단의료서비스 등의 분야에 응용될 수 있다.
무선 통신 시스템의 발전에 따라 다양한 서비스를 제공할 수 있게 됨으로써, 이러한 서비스들을 효과적으로 제공하기 위한 방안이 요구되고 있다. 예를 들어, UWB(Ultra Wide Band)를 이용하여 전자 디바이스들 간의 거리를 측정하는 레인징(ranging) 기술이 사용될 수 있다.
본 개시는 단순하고 효율적인 UWB 기반의 보안 레인징을 위한 보안 컴포넌트 및 프레임워크를 구성하는 방법을 제공한다. 본 개시는 구성된 보안 컴포넌트가 보안 레인징을 위한 세션 키를 UWB 서브시스템으로 안전하게 전달하는 방법을 제공한다.
본 개시는 보안 어플리케이션과 함께 TEE 영역에 포함된 UWB 서브시스템이 보안 어플리케이션으로부터 보안 데이터를 효율적이고 안전하게 획득하기 위한 방법을 제공한다.
본 개시의 일 양상에 따른, 보안 레인징(secure ranging)을 수행하는 전자 장치의 방법은 상기 전자 장치의 프레임워크가, 상기 보안 레인징을 위한 레인징 데이터 세트를 설정하기 위한 요청을 보안 컴포넌트로 전송하는 동작; 및 상기 프레임워크가, 상기 레인징 데이터 세트를 UWB 서브시스템으로 전달하기 위한 요청을 상기 보안 컴포넌트로 전송하는 동작을 포함하며, 상기 레인징 데이터 세트는 상기 프레임워크를 통해 상기 보안 컴포넌트와 상기 UWB 서브시스템 사이에 설정된 보안 채널을 이용하여 상기 보안 컴포넌트로부터 상기 UWB 서브시스템으로 전달될 수 있다.
본 개시의 다른 양상에 따른, 보안 레인징을 수행하는 전자 장치는, 메모리; 및 상기 메모리에 연결된 제어부를 포함하며, 상기 제어부는: 상기 전자 장치의 프레임워크가, 상기 보안 레인징을 위한 레인징 데이터 세트를 설정하기 위한 요청을 보안 컴포넌트로 전송하고, 상기 프레임워크가, 상기 레인징 데이터 세트를 UWB 서브시스템으로 전달하기 위한 요청을 상기 보안 컴포넌트로 전송하도록 구성되며, 상기 레인징 데이터 세트는 상기 프레임워크를 통해 상기 보안 컴포넌트와 상기 UWB 서브시스템 사이에 설정된 보안 채널을 이용하여 상기 보안 컴포넌트로부터 상기 UWB 서브시스템으로 전달될 수 있다.
본 개시의 다양한 실시예에 따른, 보안 레인징을 수행하는 UWB 장치의 방법은 상기 UWB 장치의 UWB 서브시스템이, 상기 보안 레인징을 위한 레인징 데이터 세트(RDS)를 상기 UWB 장치의 보안 어플리케이션으로부터 가져오라는 명령을 프레임워크로부터 수신하는 단계; 상기 UWB 서브시스템이, 상기 명령에 기초하여, 상기 보안 어플리케이션과의 보안 채널을 설정하는 단계; 및 상기 UWB 서브시스템이, 상기 보안 어플리케이션으로부터 상기 설정된 보안 채널을 통해 상기 RDS를 수신하는 단계를 포함하며, 상기 UWB 서브시스템 및 상기 보안 어플리케이션은 TEE (Trusted Execution Environment) 영역 내에 포함되며, 상기 RDS는 UWB 레인징 세션을 보안하기 위해 사용되는 레인징 세션 키를 포함할 수 있다.
본 개시의 다양한 실시예에 따른, 보안 레인징을 수행하는 UWB 장치의 방법은 상기 UWB 장치의 보안 어플리케이션이, 상기 보안 레인징을 위한 레인징 데이터 세트(RDS)를 상기 UWB 장치의 UWB 서브시스템으로 전달하라는 명령을 프레임워크로부터 수신하는 단계; 상기 보안 어플리케이션이, 상기 명령에 기초하여, 상기 보안 어플리케이션의 보안 OS와 상기 UWB 서브시스템 사이의 보안 채널을 설정하기 위한 요청을 상기 보안 OS로 전송하는 단계; 및 상기 보안 어플리케이션이, 상기 설정된 보안 채널을 통해 상기 RDS를 상기 UWB 서브시스템으로 전달하는 단계를 포함하며, 상기 UWB 서브시스템 및 상기 보안 어플리케이션은 TEE (Trusted Execution Environment) 영역 내에 포함되며, 상기 RDS는 UWB 레인징 세션을 보안하기 위해 사용되는 레인징 세션 키를 포함할 수 있다.
실시예로서, 상기 명령은 어플리케이션의 어플리케이션 ID 또는 상기 어플리케이션에 의해 설정된 적어도 하나의 세션 중 하나와 연관된 인스턴스 ID 중 적어도 하나를 포함할 수 있다.
실시예로서, 상기 TEE 영역 내의 컴포넌트와 통신하기 위한 제1 인터페이스 및 상기 TEE 영역 외의 컴포넌트와 통신하기 위한 제2 인터페이스가 상기 UWB 서브시스템을 위해 구성될 수 있다.
실시예로서, 상기 프레임워크는 상기 TEE 영역 외에 포함될 수 있다.
실시예로서, 상기 UWB 서브시스템은 상기 RDS에 포함된 레인징 세션 키를 이용하여 다른 UWB 장치의 UWB 서브시스템과의 보안 레인징을 수행할 수 있다.
본 개시의 보안 컴포넌트 및 프레임워크의 구성에 따라, 단순하고 효율적인 UWB 기반의 보안 레인징을 수행할 수 있다. 본 개시의 보안 컴포넌트가 보안 레인징을 위한 세션 키를 UWB 서브시스템으로 전달하는 방식에 따라, 안전하게 세션 키가 전달될 수 있다.
본 개시의 실시예에 따른 방법에 따라, 보안 어플리케이션과 함께 TEE 영역에 포함된 UWB 서브시스템이 보안 어플리케이션으로부터 보안 데이터를 효율적이고 안전하게 획득할 수 있다.
도 1은 UWB 기반 서비스를 지원하는 전자 장치의 예시적인 레이어 구성을 나타낸다.
도 2a는 UWB 기반 서비스를 지원하는 전자 장치를 포함하는 통신 시스템의 예시적인 구성을 나타낸다.
도 2b는 UWB 기반 결제 서비스를 지원하는 전자 장치를 포함하는 통신 시스템의 예시적인 구성을 나타낸다.
도 3은 UWB 기반 서비스를 지원하는 전자 장치에 포함된 프레임워크의 예시적인 구성을 나타낸다.
도 4는 본 개시의 예시적인 실시예에 따른 제1 보안 컴포넌트를 이용하여 보안 레인징(secure ranging)을 수행하는 통신 시스템의 예시적인 동작을 나타낸다.
도 5는 본 개시의 예시적인 실시예에 따른 제1 보안 컴포넌트를 이용하여 secure ranging을 수행하는 전자 장치의 예시적인 구성 및 동작을 나타낸다.
도 6은 본 개시의 예시적인 실시예에 따른 제2 보안 컴포넌트를 이용하여 secure ranging을 수행하는 전자 장치의 예시적인 구성 및 동작을 나타낸다.
도 7a는 본 개시의 예시적인 실시예에 따른 전자 장치가 제1 보안 컴포넌트와 UWBS 사이의 보안 채널을 설정하는 방법을 나타낸다.
도 7b는 본 개시의 예시적인 실시예에 따른 전자 장치가 제2 보안 컴포넌트와 UWBS 사이의 보안 채널을 설정하는 방법을 나타낸다.
도 8은 본 개시의 예시적인 실시예에 따른 제2 보안 컴포넌트를 포함하는 전자 장치가 RDS를 제공하는 방법의 흐름도이다.
도 9a는 본 개시의 예시적인 실시예에 따른 대칭 암호화 방식(Symmetric 방식)을 이용한 UWBS와 보안 컴포넌트 간의 보안 채널 설정 절차를 나타낸다.
도 9b는 본 개시의 예시적인 실시예에 따른 비대칭 암호화 방식(Asymmetric 방식)을 이용한 UWBS와 보안 컴포넌트 간의 보안 채널 설정 절차의 일 예를 나타낸다.
도 9c는 본 개시의 예시적인 실시예에 따른 Asymmetric 방식을 이용한 UWBS와 보안 컴포넌트 간의 보안 채널 설정 절차의 다른 예를 나타낸다.
도 9d는 본 개시의 예시적인 실시예에 따른 UWBS와 보안 컴포넌트 간의 보안 채널을 통해 UWBS가 보안 컴포넌트로 RDS를 전달하는 절차를 나타낸다.
도 10a는 본 개시의 예시적인 실시예에 따른 제1 보안 컴포넌트를 포함하는 전자 장치를 위한 키 프로비저닝(provisioning) 방법을 나타낸다.
도 10b는 본 개시의 일 실시예에 따른 제2 보안 컴포넌트를 포함하는 전자 장치를 위한 키 프로비저닝(provisioning) 방법을 나타낸다.
도 11은 본 개시의 일 실시예에 따른 제2 보안 컴포넌트를 포함하는 전자 장치를 위한 키 프로비저닝을 위한 증명(attestation) 절차를 나타낸다.
도 12는 본 개시의 예시적인 실시예에 따른 전자 장치의 예시적인 구성을 나타낸다.
도 13은 본 개시의 일 실시예에 따른 전자 장치의 방법을 나타내는 흐름도이다.
도 14는 본 개시의 일 실시예에 따른 제1 전자 장치의 구조를 도시한 도면이다.
도 15는 본 개시의 일 실시예에 따른 제2 전자 장치의 구조를 도시한 도면이다.
도 16은 SE를 포함하는 UWB 장치의 예시적인 구성을 나타낸다.
도 17은 SE를 포함하는 UWB 장치의 동작을 나타낸다.
도 18은 본 개시의 일 실시예에 따른, TEE를 포함하는 UWB 장치의 예시적인 구성을 나타낸다.
도 19는 본 개시의 일 실시예에 따른 TEE를 포함하는 UWB 장치의 동작을 나타낸다.
도 20은 본 개시의 일 실시예에 따른 TEE 및 SE를 포함하는 UWB 장치의 동작을 나타낸다.
도 21은 본 개시의 일 실시예에 따른 제1 UWB 장치가 제2 UWB 장치와 보안 레인징을 수행하는 방법을 나타낸다.
도 22는 본 개시의 다른 실시예에 따른 TEE를 포함하는 UWB 장치의 동작을 나타낸다.
도 23은 본 개시의 다른 실시예에 따른 제1 UWB 장치가 제2 UWB 장치와 보안 레인징을 수행하는 방법을 나타낸다.
도 24는 본 개시의 일 실시예에 따른 UWB 장치의 구성을 나타낸다.
도 25는 본 개시의 일 실시예에 따른 UWB 장치의 방법을 나타내는 흐름도이다.
도 26은 본 개시의 다른 실시예에 따른 UWB 장치의 방법을 나타내는 흐름도이다.
도 27는 본 개시의 일 실시예에 따른 전자 장치의 구조를 도시한 도면이다.
이하, 본 개시의 실시 예를 첨부된 도면을 참조하여 상세하게 설명한다.
실시 예를 설명함에 있어서 본 개시가 속하는 기술 분야에 익히 알려져 있고 본 개시와 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다. 이는 불필요한 설명을 생략함으로써 본 개시의 요지를 흐리지 않고 더욱 명확히 전달하기 위함이다.
마찬가지 이유로 첨부된 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성요소에는 동일한 참조 번호를 부여하였다.
본 개시의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 개시는 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 개시의 실시 예들은 본 개시가 완전하도록 하고, 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 개시의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 개시는 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.
이때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성하게 된다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능할 수 있다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능할 수 있다.
또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예컨대, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능할 수 있다.
이때, 본 실시 예에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA(Field Programmable Gate Array) 또는 ASIC(Application Specific Integrated Circuit)과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행한다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일부 실시 예에 따르면 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합되거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다. 또한 일부 실시 예에 따르면, '~부'는 하나 이상의 프로세서를 포함할 수 있다.
본 명세서에서 사용하는 용어 '단말' 또는 '기기'는 이동국(MS), 사용자 장비(UE; User Equipment), 사용자 터미널(UT; User Terminal), 무선 터미널, 액세스 터미널(AT), 터미널, 가입자 유닛(Subscriber Unit), 가입자 스테이션(SS; Subscriber Station), 무선 기기(wireless device), 무선 통신 디바이스, 무선 송수신 유닛(WTRU; Wireless Transmit/Receive Unit), 이동 노드, 모바일 또는 다른 용어들로서 지칭될 수 있다. 단말의 다양한 실시 예들은 셀룰러 전화기, 무선 통신 기능을 가지는 스마트 폰, 무선 통신 기능을 가지는 개인 휴대용 단말기(PDA), 무선 모뎀, 무선 통신 기능을 가지는 휴대용 컴퓨터, 무선 통신 기능을 가지는 디지털 카메라와 같은 촬영장치, 무선 통신 기능을 가지는 게이밍 장치, 무선 통신 기능을 가지는 음악저장 및 재생 가전제품, 무선 인터넷 접속 및 브라우징이 가능한 인터넷 가전제품뿐만 아니라 그러한 기능들의 조합들을 통합하고 있는 휴대형 유닛 또는 단말기들을 포함할 수 있다. 또한, 단말은 M2M(Machine to Machine) 단말, MTC(Machine Type Communication) 단말/디바이스를 포함할 수 있으나, 이에 한정되는 것은 아니다. 본 명세서에서 상기 단말은 전자 장치 또는 단순히 장치라 지칭할 수도 있다.
이하 첨부된 도면을 참조하여 본 개시의 동작 원리를 상세히 설명한다. 하기에서 본 개시를 설명함에 있어 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다. 그리고 후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
이하 본 개시의 실시 예를 첨부한 도면과 함께 상세히 설명한다. 이하에서는 UWB를 이용하는 통신 시스템(예컨대, FiRa Consotium에 의해 규정되는 UWB 통신 시스템)을 일례로서 본 개시의 실시예를 설명하지만, 유사한 기술적 배경 또는 특성을 갖는 여타의 통신 시스템에도 본 개시의 실시예가 적용될 수 있다. 예를 들어, 블루투스 또는 지그비를 이용하는 통신 시스템 등이 이에 포함될 수 있을 것이다. 따라서, 본 개시의 실시예는 숙련된 기술적 지식을 가진 자의 판단으로써 본 개시의 범위를 크게 벗어나지 아니하는 범위에서 일부 변형을 통해 다른 통신시스템에도 적용될 수 있다.
또한, 본 개시를 설명함에 있어서 관련된 기능 혹은 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단된 경우 그 상세한 설명은 생략한다. 그리고 후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
일반적으로 무선 센서 네트워크 기술은 인식 거리에 따라 크게 무선랜(Wireless Local Area Network; WLAN) 기술과 무선 사설망(Wireless Personal Area Network; WPAN) 기술로 구분된다. 이 때 무선랜은 IEEE 802.11에 기반한 기술로서, 반경 100m 내외에서 기간망(backbone network)에 접속할 수 있는 기술이다. 그리고 무선 사설망은 IEEE 802.15에 기반한 기술로서, 블루투스(Bluetooth), 지그비(ZigBee), 초광대역 통신(ultra wide band; UWB) 등이 있다. 이러한 무선 네트워크 기술이 구현되는 무선 네트워크는 복수의 전자 장치들로 이루어질 수 있다.
FCC (Federal Communications Commission)의 정의에 따르면, UWB는 500MHz 이상의 대역폭을 사용하거나, 또는 중심 주파수에 대응하는 대역폭이 20% 이상인 무선통신 기술을 의미할 수 있다. UWB는 UWB 통신이 적용되는 대역 자체를 의미할 수도 있다. UWB는 장치들 간의 안전하고 정확한(secure and accurate) 레인징을 가능하게 한다.
UWB 기반 서비스의 동작은 UWB 기반의 서비스를 개시하기 위한 서비스 개시 단계(Service Initiation Step), 보안을 위한 키를 제공하기 위한 키 프로비저닝 단계(Key provisioning Step), 장치를 발견하기 위한 디스커버리 단계(Discovery Step), 보안 채널 생성과 파라미터 교환을 포함하는 연결 단계(Connection Step) 및/또는 장치들 간의 위치/거리를 측정하기 위한 UWB 레인징 단계(UWB Ranging Step)를 포함할 수 있다.
한편, 실시예에 따라, 일부 단계는 생략될 수 있다. 예를 들면, 어떤 실시예에서는, 서비스 개시 단계 및 UWB 레인징 단계는 맨데토리 단계일 수 있으나, 키 프로비저닝 단계, 디스커버리 단계 및 연결 단계는 옵셔널 단계일 수 있다. 다른 예를 들면, 다른 실시예에서는, 서비스 개시 단계, 키 프로비저닝 단계 및 UWB 레인징 단계는 맨데토리 단계일 수 있으나, 디스커버리 단계 및 연결 단계는 옵셔널 단계일 수 있다.
이하의 설명에서 사용되는 특정 용어들은 본 개시의 이해를 돕기 위해서 제공된 것이며, 이러한 특정 용어의 사용은 본 개시의 기술적 사상을 벗어나지 않는 범위에서 다른 형태로 변경될 수 있다.
"Application Dedicated File (ADF)"는 예를 들면, 어플리케이션이나, 어플리케이션 특정 데이터(application specific data)를 호스팅(hosting)할 수 있는 데이터 구조일 수 있다.
" Application Protocol Data Unit(APDU)"는 Secure Element(SE)(예컨대, embedded SE) 또는 Application Data Structure와 통신하는 경우에 사용되는 명령(command) 및 응답(response)일 수 있다.
"application specific data"는 예를 들면, Applet, proprietary applet 또는 Ranging Device 내의 동등한 구현(equivalent implementation)일 수 있다.
" Controller"는 Ranging Control Messages (RCM)를 정의 및 제어하는 Ranging Device일 수 있다. 본 개시에서, Ranging Device는 예컨대, IEEE Std 802.15.4z 스펙에 정의된 ERDEV(Enhanced Ranging Device)일 수 있다.
" Controlee"는 Controller로부터 수신된 RCM 내의 레인징 파라미터를 이용하는 Ranging Device일 수 있다.
" Dynamic STS"는 STS가 confidential 이며, 레인징 세션 동안 절대 반복되지 않는 동작 모드일 수 있다. STS는 이 모드에서 Secure Component에 의해 관리될 수 있다.
" Applet"는 Secure Component 상에서 실행되는 APDU 인터페이스를 구현하고, well-defined AID(Application (Applet) ID)에 의해 식별되는 Applet일 수 있다. 이 Applet은 secure ranging을 위해 필요한 데이터를 호스팅할 수 있다. 일 실시예에서, Applet은 예컨대, FIRA CONSORTIUM COMMON SERVICE & MANAGEMENT LAYER(CSML) 스펙에 정의된 FiRa Applet일 수 있다.
" Ranging Device"는 미리 정의된 profiles(예컨대, UWB 지원(UWB-enabled) door lock 서비스에서 사용되는 UWB 및 OOB 관련 설정 파라미터의 세트)을 사용하는 다른 Ranging Device와 통신할 수 있는 Ranging Device이거나, 또는, 다른 Ranging Device와 레이징 세션을 수행하기 위해 미리 정의된 UWB 레인징 서비스를 지원할 수 있는 Ranging Device일 수 있다. 본 개시에서, Ranging Device는 UWB Device 또는 UWB Ranging Device로 지칭될 수 있다. 일 실시예에서, Ranging Device은 예컨대, FIRA CONSORTIUM CSML 스펙에 정의된 FiRa Device일 수 있다.
"Ranging Data Set(RDS)"는 기밀성(confidentiality), 진정성(authenticity) 및 무결성(integrity)이 보장될(protected) 필요가 있는 UWB 세션을 설정하기 위해 요구되는 데이터일 수 있다. 실시예로서, RDS는 UWB Session Key를 포함할 수 있다. 실시예로서, RDS는 보안 레인징을 위해 사용될 수 있다. 예를 들면, RDS는 보안 레인징을 위한 STS를 생성하기 위해 사용될 수 있다.
"UWB-enabled Application"는 UWB 세션을 위한, OOB Connector, Secure Service 및/또는 UWB 서비스를 구성하기 위한 Framework API를 이용하는 어플리케이션일 수 있다. 본 개시에서, " UWB-enabled Application"는 어플리케이션으로 약칭될 수 있다. 일 실시예에서, UWB-enabled Application은 예컨대, FIRA CONSORTIUM CSML 스펙에 정의된 FiRa-enabled Application일 수 있다.
" Framework"는 OOB Connector, Secure Service 및/또는 UWB 서비스를 포함하는 논리적 소프트웨어 컴포넌트(logical software components)의 집합(collection)일 수 있다. 일 실시예에서, Framework는 예컨대, FIRA CONSORTIUM CSML 스펙에 정의된 FiRa Framework일 수 있다.
" OOB Connector"는 Ranging Device 간의 OOB(out-of-band) 통신(예컨대, BLE 통신)을 설정하기 위한 소프트웨어 컴포넌트일 수 있다. 일 실시예에서, OOB Connector는 예컨대, FIRA CONSORTIUM CSML 스펙에 정의된 FiRa OOB Connector일 수 있다.
" Profile"은 UWB 및 OOB 구성 파라미터(configuration parameter)의 미리 정의된 세트일 수 있다. 일 실시예에서, Profile은 예컨대, FIRA CONSORTIUM CSML 스펙에 정의된 FiRa Profile일 수 있다.
"Profile Manager"는 Ranging Device에서 이용가능한 프로필을 구현할 수 있다. 일 실시예에서, Profile Manager는 예컨대, FIRA CONSORTIUM CSML 스펙에 정의된 FiRa Profile Manager일 수 있다.
" Smart Ranging Device"는 하나 이상의 UWB-enabled Application을 호스팅할 수 있고, Framework를 구현할 수 있는 Ranging Device이거나, 또는 제조사에 의해 제공되는 특정 service application를 구현하는 Ranging device일 수 있다(예컨대, physical access reader). Smart Ranging Device는 다른 Ranging Device 또는 Smart Ranging Device와의 레인징 세션을 수행하기 위해 UWB 레인징 기반 서비스를 지원하기 위하여, 다중 UWB-enabled Application을 인스톨할 수 있는 Ranging Device일 수 있다. 일 실시예에서, Smart Ranging Device는 예컨대, FIRA CONSORTIUM CSML 스펙에 정의된 FiRa Smart Device일 수 있다.
" Global Dedicated File(GDF)"는 USB 세션을 설정하기 위해 필요한 데이터를 포함하는 application specific data의 root level일 수 있다. application specific data는 예를 들면, Applet, proprietary applet 또는 Ranging Device 내의 동등한 구현(equivalent implementation)일 수 있다.
" Framework API"는 Framework와 통신하기 위해 UWB-enabled Application에 의해 사용되는 API일 수 있다.
" Initiator"는 레인징 교환(ranging exchange)을 개시하는 Ranging Device일 수 있다.
" Object Identifier (OID)"는 application data structure 내의 ADF의 식별자이거나, 또는 service provider(SP)를 식별하는 unique ID일 수 있다.
" Out-Of-Band (OOB)"는 하위(underlying) 무선 기술로서 UWB를 사용하지 않는 데이터 통신일 수 있다.
" Responder"는 레인징 교환에서 Initiator에 응답하는 Ranging Device일 수 있다.
" Scrambled Timestamp Sequence (STS)"는 레인징 측정 타임스탬프(ranging measurement timestamps)의 신뢰도 및 정확도(integrity and accuracy)를 증가시키기 위한 암호화된 시퀀스(ciphered sequence)일 수 있다.
" Secure Channel"는 overhearing 및 tampering을 방지하는 데이터 채널일 수 있다.
" Secure Component"은 예컨대, dynamic STS가 사용되는 경우에, UWBS에 RDS를 제공하기 위한 목적으로 UWBS와 인터페이싱하는 컴포넌트일 수 있다. 또한, 이는 UWB-enabled Application data를 호스팅할 수 있다.
" Secure Element (SE)"는 Ranging Device 내 Secure Component로서 사용될 수 있는 tamper-resistant secure hardware component일 수 있다.
" Secure Service"는 Secure Element 또는 TEE(Trusted Execution Environment)와 같은 시스템의 Secure Component와 인터페이싱하기 위한 컴포넌트일 수 있다.
" Static STS"는 STS가 세션 동안 반복되는 동작 모드로서, Secure Component에 의해 관리될 필요가 없다.
" SUS Applet"은 UWBS와 SE와 같은 Secure Component 간의 Secure Channel을 위해 end point로서 동작하는 Secure Component 상의 Applet일 수 있다.
" UWB Service"는 UWBS에 대한 접속(access)을 제공하는 implementation-specific software component일 수 있다.
" UWB Session"은 Controller 및 Controlee(s)가 UWB 레인징을 시작할 수 있는 경우에 설정되는 것이 고려될 수 있다. UWB Session은 Controller 및 Controlee가 UWB를 통해 통신을 시작할 때부터 통신을 정지(stop)할 때까지의 기간(period)일 수 있다. UWB Session은 레인징, 데이터 전달(transfer) 및 둘 모두를 포함할 수 있다.
" UWB Session ID"는 UWB Session을 식별하는 ID(예컨대, 정수)일 수 있다.
" UWB Session Key"는 UWB Session을 보호하기 위해 사용되는 키일 수 있다. 본 개시에서, UWB Session Key는 UWB Ranging Session Key(URSK), 또는 세션 키로 지칭될 수 있다.
" UWB Subsystem (UWBS)"는 UWB PHY 및 MAC 스펙을 구현하는 하드웨어 컴포넌트일 수 있다. UWBS는 UCI logical interface layer가 구현된 FiRa Framework에 대한 인터페이스 및 RDS를 검색하기 위한 Secure Component에 대한 인터페이스를 가질 수 있다. 일 실시예에서, UWB PHY 및 MAC 스펙은 예컨대, FiRa CONSORTIUM PHY 및 MAC 스펙일 수 있다.
그리고, 본 개시를 설명함에 있어서, 관련된 공지기능 또는 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단된 경우, 그 상세한 설명은 생략한다.
이하 첨부된 도면을 참고하여 본 개시의 다양한 실시예들을 설명한다.
도 1은 UWB 기반 서비스를 지원하는 전자 장치의 예시적인 레이어 구성을 나타낸다.
도 1의 전자 장치(UWB 장치)(100)는 예컨대, Smart Ranging Device 또는 Ranging Device일 수 있다. 실시예로서, Smart Ranging Device 또는 Ranging Device는 IEEE 802.15.4z에 정의된 Enhanced Ranging Device (ERDEV) 또는 FiRa Consortium에 의해 정의된 FiRa Device일 수 있다. 도 1에서, 전자 장치는 UWB 장치로 지칭될 수도 있다.
도 1의 실시예에서, UWB 장치(100)는 UWB 세션을 통해 다른 UWB 장치와 상호작용(interact)할 수 있다.
도 1을 참조하면, 전자 장치(100)는 UWB-enabled Application Layer(UWB-enabled Application)(110), Common Service & Management Layer(Framework)(120), 및/또는 UWB MAC Layer와 UWB Physical Layer를 포함하는 UWB 서브시스템(UWBS)(130)를 포함할 수 있다. 실시예에 따라서는, 일부 엔티티가 전자 장치에 포함되지 않거나, 추가적인 엔티티(예컨대, 보안 레이어)가 더 포함될 수 있다.
전자 장치(100)는 UWB-enabled Application(110)과 Framework(120) 간의 인터페이스인 제1 인터페이스(Interface(IF) #1)를 구현할 수 있고, 제1 인터페이스는 전자 장치(100) 상의 UWB-enabled application(110)이 미리 정해진 방식으로 전자 장치(100)의 UWB 성능들을 사용할 수 있게 해준다. 일 실시예에서, 제1 인터페이스는 예컨대, Framework API일 수 있으나, 이에 한정되지 않는다.
전자 장치(100)는 Framework(110)와 UWBS(130) 간의 인터페이스인 제2 인터페이스(Interface(IF) #2)를 구현할 수 있다. 일 실시예에서, 제2 인터페이스는 예컨대, UCI(UWB Command Interface)일 수 있으나, 이에 한정되지 않는다.
UWB-enabled Application Layer(110)는 예컨대, UWB 세션을 위한 OOB Connector, Secure Sevice 및 UWB 서비스를 구성하기 위하여, 제1 인터페이스(예컨대, Framework API)를 이용하는 어플리케이션(예컨대, FiRa-enabled Application)의 레이어일 수 있다.
UWB-enabled Application(110)은 제1 인터페이스를 이용하여 UWBS(130)에 의한 UWB 세션의 설정을 트리거링할 수 있다. 또한, UWB-enabled Application(110)은 미리 정의된 프로필(profile) 중 하나를 사용할 수 있다. 예를 들면, UWB-enabled Application(110)은 FiRa에 정의된 프로필 중 하나 또는 custom profile을 사용할 수 있다. UWB-enabled Application(110)은 제1 인터페이스를 사용하여, 서비스 발견(Service discovery), 레인징 통지(Ranging notifications), 및/또는 에러 컨디션(Error conditions)과 같은 관련 이벤트를 다룰 수 있다.
Common Service & Management Layer(Framework)(120)는 예컨대, UWB secure ranging을 구현하기 위해 필요한 공통(common) 컴포넌트 및 절차를 정의할 수 있다.
Framework(120)는 Profile에 대한 access, 개별 UWB 설정 및/또는 통지를 제공할 수 있다. 또한, Framework(120)는 UWB 레인징 및 트랜잭션 수행을 위한 기능, 어플리케이션 및 UWBS(130)에 대한 인터페이스 제공 기능 또는 장치(100)의 위치 추정 기능과 같은 기능 중 적어도 하나를 지원할 수 있다. Framework(120)는 소프트웨어 컴포넌트의 집합일 수 있다. 상술한 것처럼, UWB-enabled Application(110)은 제1 인터페이스를 통해 프레임워크(120)와 인터페이싱할 수 있고, 프레임워크(120)는 제2 인터페이스를 통해 UWBS(130)와 인터페이싱할 수 있다.
한편, 본 개시에서, UWB-enabled Application(110) 및/또는 Framework(120)는 어플리케이션 프로세서(AP)(또는, 프로세서)에 의해 구현될 수 있다. 따라서, 본 개시에서, UWB-enabled Application(110) 및/또는 Framework(120)의 동작은 AP(또는, 프로세서)에 의해 수행되는 것으로 이해될 수 있다.
UWB MAC Layer와 UWB Physical Layer는 UWB 서브시스템(UWBS)(130)로 통칭될 수 있다. UWBS(130)는 예컨대, IEEE 802.15.4z 스펙(spec)을 참조하는 FiRa PHY 및 MAC 스펙에 기초할 수 있다.
UWBS(130)는 UWB MAC Layer와 UWB Physical Layer를 포함하는 하드웨어 컴포넌트일 수 있다. UWBS(130)는 UWB 세션 관리를 수행하고, 다른 UWB 장치의 UWBS와 통신할 수 있다. UWBS(130)는 제2 인터페이스를 통해 Framework(120)와 인터페이싱할 수 있고, Secure Component로부터 보안 데이터를 획득할 수 있다. 일 실시예에서, Framework(또는, 어플리케이션 프로세서)(120)는 UCI를 통해서 명령(command)을 UWBS(130)로 전송할 수 있고, UWBS(130)는 명령에 대한 응답(response)를 Framework(120)에 전달할 수 있다. UWBS(130)는 UCI를 통해 Framework(120)에 통지(notification)을 전달할 수도 있다.
도 2a는 UWB 기반 서비스를 지원하는 전자 장치를 포함하는 통신 시스템의 예시적인 구성을 나타낸다.
도 2a를 참조하면, 통신 시스템(200)은 제1 전자 장치(210a) 및 제2 전자 장치(220a)를 포함한다.
실시예로서, 제1 UWB 장치(210a) 및 제2 UWB 장치(220a)는 예컨대, 도 1의 UWB 장치 또는 도 1의 UWB 장치를 포함하는 전자 장치일 수 있다. 예를 들면, 제1 전자 장치(제1 UWB 장치)(210a)는 예컨대, Smart Ranging Device 또는 Ranging Device일 수 있고, 제2 전자 장치(제2 UWB 장치)(220a)는 예컨대, Ranging Device 또는 Ranging Device일 수 있다. 실시예로서, Smart Ranging Device 또는 Ranging Device는 IEEE 802.15.4z에 정의된 Enhanced Ranging Device (ERDEV) 또는 FiRa Consortium에 의해 정의된 FiRa Device일 수 있다. 도 2a에서, 제1 전자 장치는 제1 UWB 장치로, 제2 전자 장치는 제2 UWB 장치로 지칭될 수 있다.
제1 전자 장치(210a)는 예컨대, 사용자(예, 모바일 폰)에 의해 인스톨될 수 있는, 하나 이상의 UWB-enabled Application을 호스팅(host)할 수 있다. 이는 Framework API에 기초할 수 있다. 제2 전자 장치(220a)는 Framework API를 제공하지 않고, 예컨대, 제조자에 의해서만 제공되는 특정 UWB-enabled Application를 구현하기 위해 proprietary interface를 이용할 수 있다. 한편, 도시된 것과 달리, 실시예에 따라서는, 제1 UWB 장치 및 제2 UWB 장치 모두가 Framework API를 이용하는 Ranging Device이거나, 제1 UWB 장치 및 제2 UWB 장치 모두가 proprietary interface를 이용하는 Ranging Device일 수도 있다.
제1 전자 장치(210a) 및 제2 전자 장치(220a)는 UWB-enabled Application Layer(UWB-enabled Application)(211a,221a), Framework(212a,222a), OOB component(OOB subsystem)(213a,223a), Secure Component(214a,224a) 및/또는 UWBS(215a,225a)를 각각 포함할 수 있다. 실시예에 따라서는 일부 컴포넌트가 생략되거나, 추가적인 컴포넌트가 더 포함될 수 있다.
제1 전자 장치(210a) 및 제2 전자 장치(220a)는 OOB 컴포넌트(213a,223a)를 통해 OOB 연결(채널)을 생성할 수 있고, UWBS(215a,225a)를 통해 UWB 연결(채널)을 생성하여, 서로 통신할 수 있다.
Framework(212a,222a)는 프로필에 대한 access, 개별 UWB 설정 및/또는 통지를 제공하는 역할을 수행할 수 있다. Framework(212a,222a)는 소프트웨어 컴포넌트의 집합으로서, 예컨대, Profile Manager, OOB Connector, Secure Service 및/또는 UWB 서비스를 포함할 수 있다.
OOB 컴포넌트(213a,223a)는 OOB 통신(예컨대, BLE 통신)을 위한 MAC Layer 및/ Physical Layer를 포함하는 하드웨어 컴포넌트일 수 있다. OOB 컴포넌트(213a,223a)는 다른 장치의 OOB 컴포넌트와 통신할 수 있다. 일 실시예에서, 제1 UWB 장치(210a) 및 제2 UWB 장치(220a)는 OOB 컴포넌트(213a,223a)를 이용하여 OOB 연결(채널)을 생성할 수 있고, OOB 채널을 통해 UWB 세션을 설정하기 위한 파라미터들을 교환할 수 있다. 본 개시에서, OOB 컴포넌트(213a,223a)는 OOB 서브시스템으로 지칭될 수 있다.
Secure Component(214a,224a)는 RDS를 제공하기 위해 프레임워크 및/또는 UWBS와 인터페이싱하는 하드웨어 컴포넌트일 수 있다. 실시예로서, Secure Component(214a,224a)는 SE(예컨대, eSE), TEE(또는, TEE 내의 TA(trusted application)) 또는 Strongbox(SB)일 수 있다.
UWBS(215a,225a)는 UWB MAC Layer와 UWB Physical Layer를 포함하는 하드웨어 컴포넌트일 수 있다. UWBS(215a,225a)는 UWB 세션 관리를 수행하고, 다른 UWB 장치의 UWBS와 통신할 수 있다. 일 실시예에서, 제1 UWB 장치(210a) 및 제2 UWB 장치(220a)는 서로 교환된 파라미터들을 이용하여 UWBS(215a,225a)를 통해 설정된 UWB 세션을 통해, UWB 레인징 및 서비스 데이터의 트랜잭션을 수행할 수 있다.
본 개시에서, UWB-enabled Application Layer 및/또는 Framework는 어플리케이션 프로세서(AP)(또는, 프로세서)에 의해 구현될 수 있다. 따라서, 본 개시에서, UWB-enabled Application Layer 및/또는 Framework의 동작은 AP(또는, 프로세서)에 의해 수행되는 것으로 이해될 수 있다.
도 2b는 UWB 기반 결제 서비스를 지원하는 전자 장치를 포함하는 통신 시스템의 예시적인 구성을 나타낸다.
도 2b의 실시예는 도 2a의 실시예의 하나의 예시일 수 있다.
도 2b를 참조하면, UWB 기반 결제 서비스를 제공하는 통신 시스템(200b)는 제1 전자 장치(제1 UWB 장치)(210b) 및 제2 전자 장치(제2 UWB 장치)(220b)를 포함할 수 있다. 도 2b에서, 제1 전자 장치는 제1 UWB 장치로, 제2 전자 장치는 제2 UWB 장치로 지칭될 수 있다.
제1 전자 장치(210b)는 UWB 기반 결제 서비스를 위한 사용자의 전자 장치(예컨대, 사용자의 모바일 장치)일 수 있다. 제1 전자 장치(210b)는 적어도 하나의 UWB enabled Wallet Application(UWB enabled application)(211b-1,211b-2), UWB enabled Wallet Framework(Framework)(212b), OOB 컴포넌트(213b), 적어도 하나의 보안 컴포넌트(214b-1,214b-2) 및/또는 UWBS(215b)를 포함할 수 있다. 각 컴포넌트에 대한 설명은 도 2a의 설명을 참조할 수 있다.
한편, 도 2b의 실시예에서는 설명의 편의를 위해, UWB enabled application이 UWB enabled Wallet Application에 해당하고, Framework가 UWB enabled Wallet Framework에 해당하는 것으로 설명하지만, 실시예가 이에 한정되지 않고, 다양한 종류의 다른 서비스를 제공하기 위한 다양한 UWB enabled application 및 framework가 구현될 수 있다. 도 2b에서, UWB enabled Wallet Application은 UWB enabled application로, UWB enabled Wallet Framework는 Framework로 지칭될 수 있다.
(1) UWB enabled application(211b-1,211b-2)은 다음 특징(feature)들 중 적어도 하나를 지원할 수 있다.
- SE(예컨대, eSE) 내 UWB 기반 결제를 위한 applet(payment applet) 또는 TEE 내 UWB 기반 결제를 위한 Trusted Application(Trusted Payment Application)를 호스팅
- Framework에 의해 요청되는 경우, 제1 전자 장치의 위치 추정을 위한 앵커들의 배치 정보 및 UWB 블록 구조(예컨대, 레인징 블록 구조)를 제공
- payment applet 또는 Trusted Payment Application(TPA)의 personalization을 위하여 제2 전자 장치 및 백엔드 서버와의 통신
(2) Framework(212b)는 다음 특징들 중 적어도 하나를 지원할 수 있다.
- 제1 전자 장치의 위치를 추정
- UCI 명령들을 구현
- UWB enabled application가 UWBS 및 OOB 컴포넌트에 접근하기 위한 API의 세트를 제공
(3) OOB 컴포넌트(213b)는 다음 특징들을 지원할 수 있다.
- OOB 연결 동작(예컨대, BLE 연결 동작)을 구현
(4) Trusted Payment Application(211b-2)은 TEE 내에 포함될 수 있고, 다음 특징들 중 적어도 하나를 지원할 수 있다.
- TEE Client API를 지원
- Trusted Application을 구현
- 보안 방식으로 제2 전자 장치와 통신하기 위해 보안 채널 프로토콜을 구현
- 보안 채널을 위한 payment credential 및 cryptographic keys를 호스팅
- UWB 기반 결제 서비스를 지원하기 위한 중요한 정보(예컨대, 카드 정보)를 호스팅
(5) payment applet(211b-1)은 SE(eSE) 내에 포함될 수 있고, 다음 특징들 중 적어도 하나를 지원할 수 있다.
- APDU를 지원
- 보안 방식으로 제2 전자 장치와 통신하기 위해 보안 채널 프로토콜을 구현
- 보안 채널을 위한 payment credential 및 cryptographic keys를 호스팅
- UWB 기반 결제 서비스를 지원하기 위한 중요한 정보(예컨대, 카드 정보)를 호스팅
제1 전자 장치(210b)의 각 구성은 미리 정의된 인터페이스(IF)를 통해 다른 구성과 통신할 수 있다. 이하에서, 각 인터페이스에 대하여 설명한다.
- IF#1: 제1 전자 장치(210b)의 UWBS(215b)와 다른 전자 장치의 UWBS(예컨대, 제2 전자 장치(220b)의 UWBS(223b)) 사이의 인터페이스. IF#1은 UWB 메시지 및/또는 payment transaction을 교환하기 위해 사용될 수 있다.
- IF#2: 제1 전자 장치(210b)의 OOB 컴포넌트(213b)와 다른 전자 장치의 OOB 컴포넌트(예컨대, 제2 전자 장치(220b)의 OOB 컴포넌트(222b)) 사이의 인터페이스. IF#2는 OOB 메시지를 교환하기 위해 사용될 수 있다.
- IF#3: Framework(212b)와 UWBS(215b) 사이의 인터페이스. IF#3은 UCI 메시지를 교환하기 위해 사용될 수 있다. 예를 들면, IF#3은 Trusted Payment Application(211b-2)와 UWBS(215b) 사이의 보안 채널을 설정하기 위한 UCI 메시지를 교환하기 위해 사용될 수 있다.
- IF#4: UWB enabled application(211b-2)과 TEE 내의 Trusted Payment Application(211b-2) 사이의 인터페이스. IF#4는 TEE Client API를 통해 TEE Commands를 교환하기 위해 사용될 수 있다. 예를 들면, IF#4는 Trusted Payment Application(211b-2)와 UWBS(215b) 사이의 보안 채널을 설정하기 위한 TEE Commands를 교환하기 위해 사용될 수 있다.
- IF#A: UWB enabled application(211b-1, 211b-2)과 UWBS(215b) 사이의 인터페이스. IF#A는 예컨대, SUS external API일 수 있다.
- IF#B: UWB enabled application(211b-2)과 SE(eSE) 내의 Payment Applet(214b-1) 사이의 인터페이스. IF#B는 OMAPI를 통해 APDU를 교환하기 위해 사용될 수 있다. 예를 들면, IF#B는 eSE와 UWBS 사이의 보안 채널을 설정하기 위한 APDU를 교환하기 위해 사용될 수 있다.
- IF#C: OOB 컴포넌트(213b)와 Framework(212b) 또는 UWB enabled application(211b-1, 211b-2) 사이의 인터페이스.
- IF#D: UWB enabled application(211b-1, 211b-2)와 Framework(212b) 사이의 인터페이스. IF#D는 Framework(212b)에 의해 제공되는 API(Framework API)일 수 있다.
제2 전자 장치(220b)는 UWB 기반 결제 서비스를 위한 사업자의 전자 장치(예컨대, retail의 PoS(Point of Service) 단말)일 수 있다. 제2 전자 장치(220b)는 단말 어플리케이션(221b), OOB 컴포넌트(222b) 및/또는 UWBS(223b)를 포함할 수 있다. 실시예로서, 단말 어플리케이션(221b) UWB enabled application일 수 있다.
도 3은 UWB 기반 서비스를 지원하는 전자 장치에 포함된 프레임워크의 예시적인 구성을 나타낸다.
도 3의 프레임워크(300)는 도 2a 및 도 2b의 프레임워크의 일 예일 수 있다. 도 3의 프레임워크(300)는 예컨대, FIRA CONSORTIUM에 정의된 FiRa Framework일 수 있다.
프레임워크(300)는 논리적 소프트웨어 컴포넌트(logical software component)의 집합일 수 있다. UWB-enabled Application는 프레임워크(300)에 의해 제공되는 프레임워크 API를 통해 프레임워크와 인터페이싱할 수 있다.
도 3을 참조하면, 프레임워크(300)는 Profile Manger(310), OOB Connector(320), Secure Service(330) 및/또는 UWB Service(340)를 포함할 수 있다. 다만, 실시예에 따라 일부 컴포넌트가 생략되거나, 추가적인 컴포넌트를 더 포함할 수 있다.
Profile Manger 컴포넌트(310)는 Ranging Device(UWB 장치) 상에서 이용가능한 Profile(s)을 관리할 수 있다. Profile은 Ranging Device(UWB 장치) 사이에 성공적인 UWB 세션을 설정(establish)하기 위해 요구되는 파라미터들의 집합일 수 있다. 예를 들면, 프로필은 어떤 보안 채널(예컨대, OOB 보안 채널)이 사용되는지를 나타내는 파라미터, UWB/OOB 설정 파라미터, 특정 보안 컴포넌트의 사용이 맨데토리(mandatory)인지를 나타내는 파라미터 및/또는 ADF의 파일 구조와 관련된 파라미터를 포함할 수 있다. 또한, Profile Manger는 UWB-enabled Application로부터의 UWB 및 OOB 구성 파라미터를 추상화할 수 있다.
OOB Connector 컴포넌트(320)는 Ranging Device(UWB 장치) 사이의 OOB 연결을 설정하기 위한 컴포넌트일 수 있다. OOB Connector(320)는 UWB 기반 서비스를 제공하기 위한 Discovery Phase 및 Connection Phase를 다룰 수 있다.
Secure Service 컴포넌트(330)는 Secure Element (SE) 또는 Trusted Execution Environment (TEE)와 같은 보안 컴포넌트와 인터페이싱하는 역할을 수행할 수 있다. 보안 컴포넌트는 UWBS에 UWB 레인징 데이터를 전달하기 위해 UWBS와 인터페이싱하는 컴포넌트일 수 있다.
UWB Service 컴포넌트(340)는 UWBS에 대한 액세스를 제공하는 컴포넌트일 수 있다.
* 상술한 것처럼, UWB enabled Wallet Application과 같은 UWB enabled application은 framework가 제공한 API를 통해 UWBS 및 OOB를 이용하기 위해 framework와 인터랙션할 수 있다. 또한, UWB enabled application은 자격 증명(credential), 암호화 키(cryptographic key) 및 기타 민감한 정보(sensitive information)를 저장하는 적어도 하나의 보안 컴포넌트과 연관될 수 있다. 예를 들면, UWB enabled application은 eSE(또는, eSE 내의 Applet)(제1 보안 컴포넌트) 및/또는 TEE(또는, TEE 내의 Trusted application(TA))(제2 보안 컴포넌트)를 보안 컴포넌트로서 가질 수 있다.
한편, TEE 내의 TA는 UWBS와 직접 또는 간접적으로 인터랙션할 수 있다.
만일 UWBS가 중간 엔티티(예컨대, Framework)를 통해 TA와 연결된 경우, UWBS는 TA와 간접적으로 통신할 수 있다. 이러한 방식의 모드는 bypass 모드로 지칭될 수 있다.
만일 UWBS가 TEE 내의 Driver TA(Secure OS)에 물리적으로 연결된 경우, UWBS는 TA와 직접 통신할 수 있다. 이러한 방식의 모드는 attached 모드로 지칭될 수 있다. Attached 모드의 경우, UWBS는 TEE 영역 내에 포함된 것으로 이해될 수 있다.
<실시예 A>
실시예 A는 상술한 bypass 모드와 관련된 실시예에 해당한다. 이하에서는, 도 4 내지 15를 참조하여, 실시예 A에 대하여 예시적으로 설명한다.
도 4는 본 개시의 예시적인 실시예에 따른 제1 보안 컴포넌트를 이용하여 secure ranging을 수행하는 통신 시스템의 예시적인 동작을 나타낸다.
도 4의 실시예에서, 제1 보안 컴포넌트는 Secure Element (예컨대, embedded SE(eSE))일 수 있다. SE는 tamper resistant 특성을 기반으로 한 안전한 보안 모듈이지만, 다양한 엔티티 간의 계약 관계가 성립되지 않으면, 어플리케이션을 설치 및 구동하는데 제약이 따른다.
eSE는 전자 장치에 고정하여 사용하는 고정식 SE를 의미한다. eSE는 통상적으로 단말 제조사의 요청에 의해 제조사 전용으로 제조되며, 운영체제와 프레임워크를 포함하여 제조 될 수 있다. eSE는 원격으로 애플릿 형태의 서비스 제어 모듈을 다운받아 설치하고, 예컨대, 전자지갑, 티켓팅, 전자여권, 디지털키 등과 같은 다양한 보안 서비스 용도로 사용될 수 있다.
본 개시에서, 제1 보안 컴포넌트는 TEE(또는, TEE 내의 TA) 또는 Strongbox와 같은 보안 컴포넌트인 제2 보안 컴포넌트와 구별된다.
TEE는 예를 들면, 특정 칩셋(예컨대, ARM 기반)에서 지원하는 코드를 기반으로 가상의 분리된 환경을 만드는 S/W 중심의 보안 환경일 수 있다. TEE는 tamper resistant 특성을 가지지 않지만, 사용가능한 메모리가 크고 속도가 빠르며, SE에 비해 비용이 저렴하다는 이점을 갖는다. 또한, 모바일 제조사가 허용한 범위 내에서 다양한 서비스 프로바이더가 바로 사용 가능하므로, SE에 비해 엔티티 간 복잡도가 낮다는 이점을 갖는다.
Strongbox는 예컨대, Javacard OS 기반인 물리적인 보안 칩일 수 있다. Strongbox 역시, TEE와 마찬가지로, SE에 비해 엔티티 간 복잡도가 낮다는 이점을 갖는다.
한편, 제2 보안 컴포넌트는 상술한 TEE 또는 Strongbox에 한정되지 않고, TEE 또는 Strongbox와 동일 또는 유사한 특성을 갖는 보안 컴포넌트일 수도 있다.
이하에서 설명할 것처럼, 제1 보안 컴포넌트를 이용하는 경우와 제2 보안 컴포넌트를 이용하는 경우에는 키 프로비저닝 절차, 보안 레인징을 위한 세션 키의 UWBS로의 전달 절차 등에 있어 차이를 갖는다.
도 4를 참조하면, 통신 시스템(400)은 제1 전자 장치(410), 제2 전자 장치(420) 및/또는 서비스 프로바이더(430)를 포함한다.
도 4의 실시예에서, 제1 전자 장치(제1 UWB 장치)(410) 및 제2 전자 장치(제2 UWB 장치)(420)는 도 1 내지 3에서 상술한 전자 장치 중 하나일 수 있다. 예를 들면, 제1 전자 장치(제1 UWB 장치)(410)는 예컨대, Smart Ranging Device일 수 있고, 제2 전자 장치(제2 UWB 장치)(420)는 예컨대, Ranging Device 또는 Smart Ranging Device일 수 있다.
서비스 프로바이더(430)는 UWB-enabled Application을 제공하고, secure ranging을 위한 키를 프로비저닝하는 역할을 수행하는 엔티티일 수 있다.
도 4를 참조하면, 제1 전자 장치(410)는 비-보안 영역(non-secure world)에 속하는 UWB-enabled Application(411), Framework(412) 및 OOB 컴포넌트(413)를 포함하고, 보안 영역(secure world)에 속하는 Secure element(SE)(제1 보안 컴포넌트) 및 UWBS(414)를 포함할 수 있다. 제2 전자 장치(420)는 Application(421), OOB 컴포넌트(422) 및/또는 UWBS(423)를 포함할 수 있다.
UWB-enabled Application(411)은 UWB 기능들을 요구하고, Framework(412)를 통해 UWBS(414)에 접속할 수 있다.
Framework(412)는 상이한 Profiles에 대한 접속을 제공한다. 도 3에서 예시된 것처럼, Framework(412)는 Profile Manger, OOB Connector, Secure Service 및/또는 UWB Service 컴포넌트를 포함할 수 있다.
SE(예컨대, eSE)는 Applet(415) 및/또는 SUS(Secure UWB Service) Applet(416)을 포함할 수 있다. Applet(415)은 Ranging Data Set(RDS)를 안전하게 생성하기 위해 요구되는 적어도 하나의 Application Dedicated File (ADF)를 포함할 수 있다. 예를 들면, 도시된 것처럼, Applet(415)은 각 서비스 프로바이더(SP)에 의해 제공된 각 ADF(예컨대, SP1의 ADF(ADF(SP1)) 및 SP2의 ADF(ADF(SP2)))를 포함할 수 있다. ADF는 예컨대, 키 프로비저닝 단계에서, 서비스 프로바이더에 의해 제공될 수 있다. 또한, Applet(415)은 RDS를 SUS Applet(416)을 통해 UWBS(414)로 전달할 수 있다. 일 실시예에서, RDS는 특정 UWB 세션에 대한 세션 ID 및/또는 UWB Session Key를 포함할 수 있다.
OOB 컴포넌트(413)는 Framework(412)의 OOB Connector에 연결되며, Ranging Device(UWB Device)들 간의 OOB 연결(예컨대, 블루투스 저전력 에너지(BLE) 연결)을 설정할 수 있다. 예를 들면, 제1 전자 장치(410)의 OOB 컴포넌트(413)와 제2 전자 장치(420)의 OOB 컴포넌트(422)를 통해, 제1 전자 장치(410)와 제2 전자 장치(420) 간의 OOB 연결이 설정될 수 있다.
UWBS(414)는 UWB 하드웨어를 관리한다. UWBS(414)는 다른 Ranging Device의 UWBS(예컨대, 제2 전자 장치(420)의 UWBS(423))와 UWB 세션을 수행할 수 있다. UWBS(414)는 Framework(412)에 의해 관리되며, SE로부터 secure ranging을 위해 필요한 RDS를 수신할 수 있다.
도 4를 참조하면, 동작 1(discovery 동작)에서, 제1 전자 장치(410)와 제2 전자 장치(420)는 OOB 컴포넌트(413,422)를 통해 service discovery 절차를 수행할 수 있다. service discovery 절차는 Secure Channel(SC) 협상 동작을 포함할 수 있다.
동작 2(보안 채널 설정 동작)에서, 제1 전자 장치(410)와 제2 전자 장치(420)는 전자 장치(예컨대, FiRa Device) 간에 안전하게 데이터를 공유하기 위해, Framework를 통해, 장치 간 Secure Channel(예컨대, SC#1, SC#2)을 설정할 수 있다. Secure Channel은 OOB channel(연결)을 통해 오픈(open)될 수 있다.
동작 3(RDS 생성/전달 동작)에서, UWB 세션 키(URSK)가 Applet(415)와 SUS Applet(416) 사이에 교환될 수 있다. 예를 들면, Applet(415)의 UWB Ranging Session Key (URSK)가 SUS Applet(416)와의 통신을 통해, SUS Applet(416)로 전달될 수 있다. 또한, 세션 ID가 SUS Applet(416)를 통해 UWBS(414)로 전달될 수 있다. 이를 위해, Applet(415)와 SUS Applet(416) 간의 보안 채널 및 SUS Applet(416)와 UWBS(414) 간의 보안 채널이 먼저 설정될 수 있다. UWBS(414)는 설정된 Secure Channel을 통해, SUS Applet(416)로부터 해당 RDS를 획득할 수 있다. 세션 ID와 UWB 세션 키는 Applet(415)에 의해 생성된 것일 수 있다.
동작 4(보안 레인징 동작)에서, 제1 전자 장치(410)와 제2 전자 장치(420)는 UWBS(414,423)를 통해 secure ranging 절차를 수행할 수 있다. 획득된 URSK가 secure ranging을 위해 UWBS에 의해 사용될 수 있다.
도 5는 본 개시의 예시적인 실시예에 따른 제1 보안 컴포넌트를 이용하여 secure ranging을 수행하는 전자 장치의 예시적인 구성 및 동작을 나타낸다.
도 5의 실시예에서, 전자 장치(UWB 장치)(510)는 도 1 내지 3에서 상술한 전자 장치 중 하나일 수 있다. 예를 들면, 전자 장치(510)는 예컨대, Smart Ranging Device일 수 있고, 제1 보안 컴포넌트는 Secure Element (예컨대, eSE)일 수 있다.
도 5를 참조하면, 전자 장치(510)는 UWB-enabled Application(511), Framework(512) 및 제1 보안 컴포넌트(513)를 포함하며, 외부 전자 장치(520)과 통신할 수 있다.
도 5의 실시예에서, Framework(512)는 APDU 인터페이스를 통해 다른 Ranging device 및 제1 보안 컴포넌트(513)와 통신할 수 있다. APDU 인터페이스는 예컨대, ISO/IEC 7816-4에 기초한다. 예를 들면, 전자 장치(510)의 Framework(512)는 외부 Ranging Device(예컨대, FiRa Device)(520)로부터 OID에 의해 식별되는 ADF를 선택하기 위한 APDU 명령(SELECT ADF(OID))를 수신하고, 수신된 APDU 명령을 제1 보안 컴포넌트(513)로 전송할 수 있다. 또한, Framework(512)는 이 APDU 명령에 대한 응답을 제1 보안 컴포넌트(513)로부터 수신하고, 수신된 응답을 외부 Ranging Device(예컨대, FiRa Device)(520)로 전송할 수 있다. 응답은 Cryptogram, 암호화된 메시지(EncMsg) 및/또는 메시지 인증 코드(MAC)를 포함할 수 있다.
한편, 이러한 APDU 인터페이스는 Framework(512)에 의해서만 호출될 수 있고, Application(511)에 의해 호출될 수 없다. 따라서, APDU 인터페이스를 사용하는 경우, UWB-enabled Application(511)은 예컨대, ServiceInit() API를 이용하여 단지 Service Profile을 Framework(512)에 제공하는 역할을 수행할 수 있을 뿐이다. 즉, UWB-enabled Application(511)은 능동적으로 동작될 수 없다.
도 6은 본 개시의 예시적인 실시예에 따른 제2 보안 컴포넌트를 이용하여 secure ranging을 수행하는 전자 장치의 예시적인 구성 및 동작을 나타낸다.
도 6의 실시예에서, 전자 장치(UWB 장치)(610)는 도 1 내지 3에서 상술한 전자 장치 중 하나일 수 있다. 예를 들면, 전자 장치(610)는 예컨대, Smart Ranging Device일 수 있고, 제2 보안 컴포넌트는 TEE 또는 Strongbox(SB)일 수 있다.
도 6을 참조하면, 전자 장치(610)는 UWB-enabled Application(611), Framework(612) 및 제2 보안 컴포넌트(613)를 포함하며, 외부 전자 장치(620)와 통신할 수 있다.
일 실시예에서, 제2 보안 컴포넌트(613)는 예컨대, 보안 채널 1(SC01)의 구현 기능 및/또는 키 구현 기능을 포함할 수 있다. 예를 들면, 제2 보안 컴포넌트(613)는 어플리케이션(예컨대, abc를 Appid로 갖는 어플리케이션)에 대응하는 MAC Privacy key(예컨대, 123를 키 값으로 갖는 MAC Privacy key) 및/또는 어플리케이션(예컨대, abc를 Appid로 갖는 어플리케이션)에 대응하는 ENC Privacy key(예컨대, 456 를 키 값으로 갖는 ENC Privacy key)을 포함할 수 있다. 일 실시예에서, MAC Privacy key 는 메시지 인증 코드의 생성을 위해 사용될 수 있고, ENC Privacy key는 암호화를 위해 사용될 수 있다. 이러한 보안 채널 키는 예컨대, 키 프로비저닝 단계에서 서비스 프로바이더에 의해 제공될 수 있다. 키 프로비저닝 단계는 디스커버리 단계 이전에 수행될 수 있다.
도 6의 실시예에서, Framework(612)는 APDU 인터페이스가 아닌, Framework API의 세트를 통해 제2 보안 컴포넌트(TEE/SB)(613)와 통신할 수 있다. 일 실시예에서, Framework API 세트는 예컨대, 어플리케이션의 등록을 위한 Register(), 보안 메시징 세션의 설정을 위한 setSecureMessagingSession() 및/또는 레인징 데이터(또는, RDS)의 설정을 위한 setRangingData()와 같은 API를 포함할 수 있다.
APDU 인터페이스를 사용하는 도 5의 실시예와 달리, 이 Framework API는 Application(611)에 의해 호출될 수 있다. 따라서, 이 Framework API를 사용하는 경우, Framework(612)는 로직을 담당하고, UWB-enabled Application(611)가 API를 이용하여 secure ranging을 위한 상세 파라미터 설정과 함께, 다양한 서비스들(예컨대, FiRa service 들)을 구현하고, 이와 관련된 데이터를 Framework로 제공할 수 있다. 이를 통해, 도 6의 실시예는 도 5의 실시예에 비해, 서비스 프로바이더에 의한 Application의 유지 보수 및 신뢰성 측면에서 유리하게 된다.
도 7a는 본 개시의 예시적인 실시예에 따른 전자 장치가 제1 보안 컴포넌트와 UWBS 사이의 보안 채널을 설정하는 방법을 나타낸다.
도 7a의 실시예에서, 전자 장치(710)는 예컨대, 도 5의 구성을 갖는 전자 장치이고, 제1 보안 컴포넌트는 SE(예컨대, eSE)일 수 있다.
도 7a를 참조하면, 전자 장치(710)는 UWB-enabled Application(711), Framework(712), UWBS(713) 및 제1 보안 컴포넌트(714)를 포함할 수 있다.
도 7a의 실시예에서, 보안 채널은 APDU 인터페이스에 의해, UWBS(713)와 제1 보안 컴포넌트(714) 사이에 직접 설정된다. 도시된 것처럼, 보안 채널은 UWBS(713)와 제1 보안 컴포넌트(714)가 동일한 공유키(예컨대, 공유 비밀키("sharedScret=K"))을 공유하는 Symmetric key 기반 보안 채널이다.
도 7b는 본 개시의 예시적인 실시예에 따른 전자 장치가 제2 보안 컴포넌트와 UWBS 사이의 보안 채널을 설정하는 방법을 나타낸다.
도 7b의 실시예에서, 전자 장치(720)는 예컨대, 도 6의 구성을 갖는 전자 장치이고, 제2 보안 컴포넌트는 TEE 및/또는 SB일 수 있다.
도 7b를 참조하면, 전자 장치(720)는 UWB-enabled Application(721), Framework(722), UWBS(723) 및 제2 보안 컴포넌트(724)를 포함할 수 있다. 제2 보안 컴포넌트(724)는 TEE 또는 Strongbox일 수 있고, TEE는 TA를 포함할 수 있다.
도 7b의 실시예에서, 보안 채널은 function 호출(API 호출)에 의해, Framework(722)를 통해 UWBS(723)와 제2 보안 컴포넌트(724) 사이에 설정된다. 즉, 보안 채널이 UWBS(723)와 보안 컴포넌트(724) 사이에 직접 설정되는 것이 아닌, Framework(722)를 경유하여 설정될 수 있다. 예를 들면, TEE(또는, SB)(724)와 Framework(722) 사이에 보안 채널(제1 보안 채널)이 설정되고, Framework(722)와 UWBS(723) 사이에 보안 채널(제2 보안 채널)이 설정됨으로써, TEE(또는, SB)(724)와 UWBS(723) 사이에 간접적으로 보안 채널이 설정될 수 있다. 이에 대하여는 도 9a 및 b를 참조하여 이하에서 추가적으로 설명한다.
도 7b의 실시예에서, 보안 채널은 Asymmetric key 또는 Symmetric key 기반 보안 채널일 수 있다. 즉, 도 7b의 실시예에서, 보안 채널은 Asymmetric cryptographic 알고리즘 또는 symmetric cryptographic 알고리즘에 기반하여 설정될 수 있다. 이처럼, 제1 보안 컴포넌트를 이용하는 도 7a의 실시예에서와 달리, 제2 보안 컴포넌트를 이용하는 도 7b의 실시예의 경우에는, Asymmetric key 기반의 보안 채널이 설정될 수도 있다.
도 8은 본 개시의 예시적인 실시예에 따른 제2 보안 컴포넌트를 포함하는 전자 장치가 RDS를 제공하는 방법의 흐름도이다.
UWB 보안 레인징을 위해, 전자 장치는 외부 전자 장치와 End to End encryption (E2EE) 통신을 수행해야 한다. 이를 위해, 외부 장치와 공유한 특정 세션 키(URSK)가 보안 컴포넌트로부터 UWBS로 안전하게 전달되어야 한다. 도 8의 실시예에서는, 이를 위한, 이 세션 키를 보안 컴포넌트로부터 UWBS로 안전하게 전달할 수 있는 실시예에 대하여 설명한다.
도 8의 실시예에서, 전자 장치(810)는 예컨대, 도 6의 구성을 갖는 전자 장치일 수 있고, 전자 장치(810)는 프레임워크(811), UWBS(812) 및 제2 보안 컴포넌트(813)를 포함하며, 외부 전자 장치(820)와 통신을 수행할 수 있다. 제2 보안 컴포넌트(813)는 TEE(또는, TEE 내의 TA) 및/또는 SB일 수 있다. TEE는 TA(Trusted application)를 포함할 수 있다. 한편, 도시되지는 않았지만, 전자 장치(810)는 다른 UWB 장치와 마찬가지로, 적어도 하나의 어플리케이션(UWB-enabled application)을 포함할 수 있고, 프레임워크 및 UWB-enabled application은 적어도 하나의 프로세서(예컨대, 어플리케이션 프로세서(AP))에 의해 구현될 수 있다. 따라서, 본 개시에서, 프레임워크 및/또는 UWB-enabled application의 동작은 프로세서의 동작으로 표현될 수 있다.
도 8의 실시예에서는, 제2 보안 컴포넌트(813)가 제1 어플리케이션(예컨대, abc를 어플리케이션을 식별하는 식별자(예컨대, Application ID(AppID), UUID)로 갖는 UWB-enabled Application)에 대응하는 보안 채널 키(예컨대, 123를 키 값으로 갖는 키) 및 제2 어플리케이션(예컨대, xyz를 어플리케이션을 식별하는 식별자(예컨대, Application ID(AppID), UUID)로 갖는 UWB-enabled Application)에 대응하는 보안 채널 키(예컨대, 789를 키 값으로 갖는 키)를 포함하는 것으로 가정한다. 실시예로서, 보안 채널 키는 암호화를 위한 키 및/또는 메시지 인증을 위한 키를 포함할 수 있다. 다만, 이에 한정되지 않고, 제2 보안 채널은 더 많은 수의 보안 채널 키 또는 단일 보안 채널 키를 포함할 수도 있다.
동작 8010에서, 외부 전자 장치(820)는 보안 채널 요청(제1 보안 채널 요청)을 전자 장치(810)로 전송할 수 있다. 예를 들면, 외부 전자 장치(820)는 OID를 포함하는 제1 보안 채널 요청을 전자 장치(810)로 전송할 수 있다. 제1 보안 채널 요청은 외부 전자 장치(820)와 전자 장치(810) 간의 보안 채널의 생성을 요청하는 요청일 수 있다. 즉, 제1 보안 채널 요청은 장치 간 보안 채널의 생성 요청일 수 있다. 전송된 제1 보안 채널 요청은 전자 장치(810)의 Framework(811)로 전달될 수 있다.
동작 8020에서, Framework(811)는 제1 보안 채널 요청에 포함된 OID에 매칭되는 어플리케이션 식별자(예컨대, AppID)를 식별할 수 있다. 이를 통해, Framework(811)는 OID를 AppID로 변환시킬 수 있다. 여기서, AppID는 서비스 프로바이더에 의해 제공되는 UWB-enabled Application을 식별하기 위한 ID일 수 있다. 본 개시에서, AppID는 상술한 applet을 식별하기 위한 applet ID(AID)와 구별될 수 있다. 일 실시예에서, Framework(811)는 OID와 AppID 간의 맵핑 테이블(리스트)를 포함할 수 있다.
동작 8030에서, Framework(811)는 제1 보안 채널 요청에 대응하는 제2 보안 채널 요청을 전자 장치(810)의 제2 보안 컴포넌트(813)로 전달할 수 있다. 예를 들면, Framework(811)는 제1 보안 채널 요청의 OID에 매칭되는 AppID를 포함하는 제2 보안 채널 요청을 제2 보안 컴포넌트(813)로 전달할 수 있다.
동작 8040에서, 전자 장치(810)는 전자 장치(810)의 제2 보안 컴포넌트(813)(또는, 전자 장치(810))와 외부 전자 장치(820) 사이의 보안 채널을 설정할 수 있다. 일 실시예에서, 보안 채널은 제2 보안 채널 요청에 포함된 AppID에 의해 식별되는 UWB-enabled Application과 연관되며, 외부 전자 장치(820)와 제2 보안 컴포넌트(813) 사이에 직접 또는 간접적으로 설정될 수 있다.
동작 8050에서, 전자 장치(810)는 설정된 보안 채널을 통해 외부 전자 장치(820)와의 UWB 세션을 위한 파라미터 교환 절차를 수행할 수 있다. 이를 통해, 전자 장치(810)는 외부 전자 장치(820)와 설정된 파라미터의 값을 협상할 수 있다. 예를 들면, 전자 장치(810)는 설정된 보안 채널을 통해, 예컨대, Session ID 및/또는 URSK와 같은 파라미터의 값을 협상할 수 있다. 교환된 파라미터는 제2 보안 컴포넌트(813)에 저장될 수 있다. 일 실시예에서, 파라미터는 UWB 성능 파라미터(capabitility paramenter) 및/또는 UWB 구성 파라미터(configuration parameter)를 포함할 수 있다.
동작 8060에서, Framework(811)는 레인징 데이터(RDS)를 설정하도록 하는 명령을 제2 보안 컴포넌트(813)로 전달할 수 있다. 예를 들면, Framework(811)(또는, UWB-enabled application)는 제2 보안 컴포넌트(813)에 대한 setRangingData() API/명령를 호출/사용할 수 있다. setRangingData()는 제2 보안 컴포넌트(813)가 RDS를 준비(또는, 설정/생성)하도록 하는 기능을 갖는다. 즉, setRangingData()는 제2 보안 컴포넌트(813)가 RDS를 설정하도록 하기 위해 사용되는 API일 수 있다. setRangingData()는 어떤 Application이 이 API를 호출했는지를 식별하기 위해 해당 Application에 대한 AppID를 포함할 수 있다.
동작 8070에서, 제2 보안 컴포넌트(813)는 RDS를 준비(또는, 설정/생성)할 수 있다. 예를 들면, TEE(또는, TEE 내의 TA)는 RDS를 준비할 수 있다. 일 실시예에서, RDS는 Session ID 및/또는 URSK를 포함할 수 있다.
동작 8080에서, 제2 보안 컴포넌트(813)는 레인징 데이터(RDS)를 설정하도록 하는 명령에 대응하는 응답을 Framework(811)로 전달할 수 있다. 예를 들면, 제2 보안 컴포넌트(813)는 setRangingData(AppID)에 대응하는 리턴/응답(API Return)을 Framework(811)로 전달할 수 있다. 일 실시예에서, 리턴은 RDS가 준비(또는, 설정/생성)되었음을 알리는 값(API Return: RDS ready)을 포함할 수 있다.
동작 8090에서, Framework(811)는 RDS를 UWBS로 전달하도록 하는 명령을 제2 보안 컴포넌트(813)로 전달할 수 있다. 예를 들면, Framework(811)(또는, UWB-enabled application)는 제2 보안 컴포넌트(813)에 대한 PushRDStoUWBS() API/명령을 호출/사용할 수 있다. PushRDStoUWBS()는 제2 보안 컴포넌트(813)가 준비된 RDS를 UWBS로 전송(또는, pushing)하도록 하는 기능을 갖는다. 즉, PushRDStoUWBS()는 제2 보안 컴포넌트(813)가 RDS를 UWBS로 전달하도록 하기 위해 사용되는 API일 수 있다. PushRDStoUWBS()는 준비된 RDS에 대응하는 어플리케이션에 대한 AppID를 포함할 수 있다.
동작 8100에서, 전자 장치(810)는 UWBS(812)와 제2 보안 컴포넌트(813) 사이의 보안 채널을 설정할 수 있다. 이를 통해, 장치 내 UWBS(812)와 제2 보안 컴포넌트(813) 사이에 보안 채널이 설정될 수 있다. 예를 들면, UWBS와 TEE(또는, TEE 내의 TA) 사이에 보안 채널이 설정될 수 있다. 도 7b에서 상술한 것처럼, UWBS(812)와 제2 보안 컴포넌트(813) 사이의 보안 채널은 예컨대, Framework(811)를 통해 간접적으로 설정될 수 있다. 이 보안 채널 설정 절차의 예시에 대하여는 도 9a 및 9b를 참조하여 이하에서 설명한다.
동작 8110에서, 제2 보안 컴포넌트(813)는 설정된 보안 채널을 통해 암호화된 RDS를 UWBS(812)로 전달할 수 있다. 예를 들면, TEE(또는, TEE 내의 TA)는 보안 채널 설정 절차를 통해 획득된 암호화 키(K_ENC)를 이용하여 RDS를 암호화하고, 암호화된 RDS를 UWBS(812)로 전달할 수 있다. 이를 통해, RDS가 안전하게 제2 보안 컴포넌트에서 UWBS로 전달(푸싱)될 수 있다.
동작 8120에서, Framework(811)는 UWB 세션을 시작하기 위한 레인징 시작 명령(command)을 UWBS(812)로 전송할 수 있다. 예를 들면, Framework(811)는 UWB 세션/레인징을 시작하기 위한 UCI 명령(UCI: Ranging Start())을 UWBS로 전송할 수 있다. Ranging Start()는 AppID를 포함할 수 있다. 일 실시예에서, AppID는 상기 UWB 세션을 식별하는 Session ID와 연관될 수 있다.
동작 8130에서, UWBS(812)는 레인징 시작 명령에 대응하는 응답(response)을 Framework(811)로 전송할 수 있다. 일 실시예에서, 응답은 레인징 시작 명령이 수락(accepted)되었는지 아니지를 지시하는 상태 값을 포함할 수 있다. 예를 들면, 응답은 레인징 시작 명령이 수락됨을 지시하는 OK 값, 또는 레인징 시작 명령이 수락되지 않음을 지시하는 NOK 값을 포함할 수 있다.
동작 8140에서, 전자 장치(810)는 UWBS(812)를 통해 외부 전자 장치(820)와 Secure Ranging을 수행할 수 있다. 이때, UWBS(812)는 URSK를 이용하여 Secure Ranging을 수행할 수 있다.
도 8의 실시예에서와 같이, 제2 보안 컴포넌트를 포함하는 전자 장치에서는, 어플리케이션의 API 호출에 의해 URSK를 포함하는 RDS가 제2 보안 컴포넌트로부터 UWBS로 푸싱될 수 있다. 예를 들면, 어플리케이션의 PushRDStoUWBS(AppID) API 호출을 통해, RDS가 TEE(또는, TEE 내 TA)로부터 UWBS로 전달될 수 있다.
한편, 도 8에 개시된 제2 보안 컴포넌트에 의해 전달된 세션 키를 이용한 보안 레인징 동작은, 도 4에 개시된 제1 보안 컴포넌트에 의해 전달된 세션 키를 이용한 보안 레인징 동작과 외부 장치의 관점에서는 동일하게 보여질 수 있다.
<UWBS와 제2 보안 컴포넌트(예컨대, TEE) 간의 보안 채널 설정 절차의 제1 실시예>
도 9a는 본 개시의 예시적인 실시예에 따른 Symmetric 방식을 이용한 UWBS와 보안 컴포넌트 간의 보안 채널 설정 절차를 나타낸다.
도 9a의 보안 채널 설정 절차는 도 8의 동작 8100의 보안 채널 설정 절차의 일 예일 수 있다.
도 9a의 Symmetric 방식은 상호 간에 랜덤 값을 주고받고, 해당 랜덤 값을 기반으로 session key를 생성하는 방식에 해당한다. 이 경우, 인증을 위한 키를 가지고 있음을 증명하기 위해 cryptogram이 활용된다. 생성된 세션 키는 암호화를 위한 세션 키(s_ENC)(제1 세션 키) 및/또는 메시지 인증을 위한 세션 키(s_MAC)(제2 세션 키)를 포함할 수 있다.
도 9a의 실시예에서, 전자 장치는 프레임워크(911), UWBS(912) 및 보안 컴포넌트(913)를 포함할 수 있다.
도 9a의 실시예에서, 보안 컴포넌트(913) 및 UWBS(912)가 Symmetric cryptographic 알고리즘을 이용하는 Symmetric 방식을 위한 미리 공유된 공유키(예컨대, K1, K2)를 포함할 수 있다. 각 키는 예컨대, 도 10b에서 설명할 키 프로비저닝 동작을 통해 보안 컴포넌트에 저장될 수 있다.
도 9a의 보안 채널 설정 절차는 예컨대, 동작 9100에서와 같이, PushRDStoUWBS() API가 호출된 경우에 개시될 수 있다. 예를 들면, RDS를 UWBS로 푸쉬하기 위한 명령이 프레임워크(또는, UWB-enabled application)으로부터 보안 컴포넌트로 전달된 경우, 보안 채널 설정 절차가 개시될 수 있다. 그러나, 실시예가 이에 한정되지 않는다.
도 9a를 참조하면, 동작 9101에서, 보안 컴포넌트(913)는 랜덤 값(r)을 생성하여, Framework(912)로 전송한다. 보안 컴포넌트는 TEE 또는 Strongbox일 수 있다. 상술한 것처럼, TEE는 TA를 포함할 수 있고, TEE인 보안 컴포넌트의 동작은 TEE 내의 TA의 동작으로 이해될 수 있다.
동작 9102에서, Framework(911)는 UWBS(912)로 수신된 랜덤 값(r)을 전달한다. 랜덤 값(r)은 제1 랜덤 값으로 지칭될 수 있다.
동작 9103에서, UWBS(912)는 랜덤 값(r') 생성 동작(Gen random r'), 제1 세션 키(s_enc) 생성 동작(Gen SessionKey s_enc), 제2 세션 키(s_MAC) 생성 동작(Gen SessionKey s_MAC) 및/또는 cryptogram (q) 생성 동작(Gen cryptogram q)를 수행할 수 있다.
UWBS(912)는 랜덤 값 생성 동작을 통해 랜덤 값(r')를 생성할 수 있다. 랜덤 값(r')는 제2 랜덤 값으로 지칭될 수 있다.
UWBS(912)는 제1 세션 키 생성 동작을 통해 암호화를 위해 사용되는 제1 세션 키(s_enc)를 생성할 수 있다.
UWBS(912)는 제2 세션 키 생성 동작을 통해 메시지 인증을 위해 사용되는 제2 세션 키(s_MAC)를 생성할 수 있다.
UWBS(912)는 cryptogram 생성 동작을 통해 cryptogram(q)을 생성할 수 있다. cryptogram(q)는 제1 cryptogram으로 지칭될 수 있다.
동작 9104에서, UWBS(912)는 랜덤 값(r') 및 cryptogram (q)를 보안 컴포넌트(913)로 전송할 수 있다. 랜덤 값(r') 및 cryptogram (q)는 프레임워크(911)를 통해 보안 컴포넌트(913)로 전달될 수 있다.
동작 9105에서, 보안 컴포넌트는 제1 세션 키(s_enc) 생성 동작(Gen SessionKey s_enc), 제2 세션 키(s_MAC) 생성 동작(Gen SessionKey s_MAC), cryptogram (q) 검증 동작(Verify cryptogram (q)) 및/또는 cryptogram (p) 생성 동작(Gen cryptogram p)를 수행할 수 있다. 일 실시예에서, 세션 키는 보안 채널 키 및 랜덤 값에 기초하여 생성될 수 있다.
보안 컴포넌트(913)는 제1 세션 키 생성 동작을 통해 암호화를 위해 사용되는 제1 세션 키(s_enc)를 생성할 수 있다.
보안 컴포넌트(913)는 제2 세션 키 생성 동작을 통해 메시지 인증을 위해 사용되는 제2 세션 키(s_MAC)를 생성할 수 있다.
보안 컴포넌트(913)는 cryptogram 검증 동작을 통해 UWBS(912)로부터 수신된 cryptogram(q)를 검증할 수 있다.
보안 컴포넌트(913)는 cryptogram 생성 동작을 통해 cryptogram(p)을 생성할 수 있다. cryptogram(p)는 제2 cryptogram으로 지칭될 수 있다.
동작 9106에서, 보안 컴포넌트(913)는 cryptogram (p)를 UWBS(912)로 전송할 수 있다. cryptogram(p)는 프레임워크(911)를 통해 보안 컴포넌트(913)로 전달될 수 있다.
동작 9107에서, UWBS(912)는 cryptogram (p) 검증 동작(Verify cryptogram (p))을 수행할 수 있다. UWBS(912)는 cryptogram 검증 동작을 통해 보안 컴포넌트(913)으로부터 수신된 cryptogram(p)를 검증할 수 있다.
동작 9108에서, Framework(911)는 UWBS(912) 및 보안 컴포넌트(913)에 대한 랜덤 챌린지 동작을 수행할 수 있다. 예를 들면, 도시된 것처럼, Framework(911)는 랜덤 챌린지 동작을 통해, 랜덤 챌린지(랜덤 값)을 UWBS(912) 및 보안 컴포넌트(913)로 전달할 수 있다.
동작 9109에서, Framework(911)는 UWBS(912) 및 보안 컴포넌트(913)로부터 랜덤 챌린지에 대한 응답을 수신할 수 있다. 예를 들면, 도시된 것처럼, Framework(911)는 랜덤 챌린지 및 메시지 인증을 위해 사용되는 제2 세션 키(s_MAC)에 기초하여 생성된 MAC를 USBS(912) 및 보안 컴포넌트(913)으로부터 각각 수신할 수 있다. 실시예로서, MAC를 생성하기 위해, HMAC(Hash-based Message Authentication Code) 알고리즘 또는 CMAC(Cipher-based Message Authentication Code) 알고리즘이 사용될 수 있다.
또한, Framework(911)는 UWBS(912)로부터 수신된 MAC(제1 MAC) 및 보안 컴포넌트(913)으로부터 수신된 MAC(제2 MAC)가 일치하는지 여부를 결정할 수 있다.
이러한 과정을 통해, UWBS(912)는 URSK(또는, RDS)를 수신할 준비가 되며, Framework(911) 및 보안 컴포넌트(913)는 UWBS(912)로 URSK(또는, RDS)를 푸쉬할 준비가 완료될 수 있다. 예를 들면, UWBS(912)로부터 수신된 MAC(제1 MAC) 및 보안 컴포넌트(913)으로부터 수신된 MAC(제2 MAC)가 일치하는 경우, UWBS(912)는 URSK(또는, RDS)를 수신할 준비가 되며, Framework(911) 및 보안 컴포넌트(913)는 UWBS(912)로 URSK(또는, RDS)를 전달할 준비가 완료될 수 있다.
<UWBS와 제2 보안 컴포넌트(예컨대, TEE) 간의 보안 채널 설정 절차의 제2 실시예>
도 9b는 본 개시의 예시적인 실시예에 따른 Asymmetric 방식을 이용한 UWBS와 보안 컴포넌트 간의 보안 채널 설정 절차의 일 예를 나타낸다.
도 9b의 보안 채널 설정 절차는 도 8의 동작 8100의 보안 채널 설정 절차의 일 예일 수 있다.
도 9b의 Asymmetric 방식은 PFS(Perfect Forward Secrecy)를 만족하기 위해 ECC(Elliptic curve) 기반의 임시 키(ephemeral key)를 이용하여 공유 비밀키(shared secret)를 생성하는 것을 특징으로 한다. 생성된 공유 비밀키는 세션 키를 생성하기 위해 사용될 수 있다. 또한, Asymmetric 방식은 인증을 위해서 미리 모바일 벤더가 저장한 인증서 및 개인키(static key) 가 필요하며, ephemeral key와 static key를 양측에서 ECC 알고리즘에 맞게 구성하여, shared secret을 생성하여 활용할 수 있다.
도 9b의 실시예에서, 전자 장치는 프레임워크(921), UWBS(922) 및 보안 컴포넌트(923)를 포함할 수 있다. 실시예로서, 보안 컴포넌트(923)는 TEE 또는 SB일 수 있다. 상술한 것처럼, TEE는 TA를 포함할 수 있고, TEE인 보안 컴포넌트의 동작은 TEE 내의 TA의 동작으로 이해될 수 있다.
도 9b의 실시예에서, UWBS(922) 및 보안 컴포넌트(923)는 Asymmetric cryptographic 알고리즘을 이용하는 Asymmetric 방식을 위한 키 및 인증서를 각각 포함한다. 예컨대, 보안 컴포넌트(TA)는 TA의 개인키/공개키(Priv/Pub_TA), TA의 인증서(Cert_TA) 및/또는 UWBS의 인증서(Cert_UWB)를 포함하고, 보안 컴포넌트(SB)는 SB의 개인키/공개키(Priv/Pub_SB), SB의 인증서(Cert_SB) 및/또는 UWB의 인증서(Cert_UWB)를 포함하고, UWBS는 UWBS의 개인키/공개키(Priv/Pub_UWB), TA의 인증서(Cert_TA), 및/또는 SB의 인증서(Cert_SB)를 포함할 수 있다. 각 키는 예컨대, 도 10b에서 설명할 키 프로비저닝 동작을 통해 보안 컴포넌트에 저장될 수 있다.
도 9b를 참조하면, 동작 9201에서, 보안 컴포넌트(923)는 제1 임시 키(e) 생성 동작(Gen ephemeral key e)을 수행할 수 있다. 예를 들면, TEE(또는, TA)는 제1 임시 키 생성 동작을 통해, 제1 임시 키(e)를 생성할 수 있다. 일 실시예에서, 임시 키(e)는 예컨대, 예컨대, 동작 9200에서와 같이, PushRDStoUWBS() API가 호출되기 이전에 생성될 수 있으나, 이에 한정되지 않는다.
보안 컴포넌트(923)는 제1 임시 키(e)에 대한 서명 값(signed(e))를 더 생성할 수 있다. 예를 들면, TEE(또는, TA)는 TA의 개인키(Priv_TA)를 이용하여 제1 임시 키(e)에 대한 서명 값(signed(e))를 더 생성할 수 있다. 본 개시에서, 제1 임시 키(e)는 Pub_e로 지칭될 수도 있고, 제1 임시 키에 대한 서명 값(signed(e))은 signed(Pub_e)로 지칭될 수도 있다.
동작 9202에서, 보안 컴포넌트(923)는 제1 임시 키 및 제1 임시 키에 대한 서명 값("e || signed(e)")를 Framework(921)로 전송하고, 동작 9203에서 Framework(921)는 수신된 제1 임시 키 및 제1 임시 키의 서명 값("e || signed(e)" 또는 "Pub_e || signed(Pub_e)")를 UWBS로 전송한다.
동작 9204에서, UWBS(922)는 서명된 임시키(signed e)를 검증하는 동작(Verify signed e) 및 제2 임시 키(e') 생성 동작(Gen ephemeral key e')을 수행할 수 있다. 예를 들면, UWBS(922)는 TA의 인증서(또는, TA의 공개 키(Pub_TA))를 이용하여 제1 임시 키에 대한 서명 값(signed(e))을 검증할 수 있고, 제2 임시 키 생성 동작을 통해 제2 임시 키(e')를 생성할 수 있다. 실시예로서, 공유 비밀 키(shared secret)는 제1 임시 키(e)와 제2 임시 키(e')에 기초하여 생성/계산될 수 있다. 본 개시에서, 제2 임시 키(e')는 Pub_e'로 지칭될 수도 있다.
UWBS(922)는 제2 임시 키(e')에 대한 서명 값(singed(e') 또는 signed(Pub_e', Pub_e))을 더 생성할 수 있다. 예를 들면, UWBS(922)는 UWBS의 개인키(Priv_UWBS)를 이용하여 제2 임시 키(e')에 대한 서명 값을 더 생성할 수 있다.
동작 9205에서, UWBS(922)는 제2 임시 키 및 제2 임시 키에 대한 서명 값("e' || signed(e')" 또는 "Pub_e' || signed(Pub_e', pub_e)")를 Framework(921)로 전송하고, 동작 9206에서, Framework(921)는 수신된 제2 임시 키 및 제2 임시 키에 대한 서명 값("e' || signed(e')" 또는 "Pub_e' || signed(Pub_e', pub_e)")를 보안 컴포넌트(923)로 전송한다.
동작 9207에서, 보안 컴포넌트(923)는 제2 임시 키(Pub_e') 및 제1 임시 키(pub_e)를 이용하여 공유 비밀키 S를 계산하는 동작, 공유 비밀키 S 및 미리 공유된 파라미터(예컨대, 1234)(제1 컨텍스트)에 기초한 암호화를 위해 사용되는 세션 키(K_ENC)의 생성 동작, 및 공유 비밀키 S 및 미리 공유된 파라미터(예컨대, ABCD)(제2 컨텍스트)에 기초한 MAC를 위한 세션 키(K_MAC)의 생성 동작을 수행할 수 있다. 예를 들면, TEE(또는, TA)는 제2 임시 키(e') 및 제1 임시 키(e)를 이용하여 공유 비밀키 S를 생성하고, 미리 설정된 KDF(key derivation function)를 이용하여 공유 비밀키 S와 제1 컨텍스트로부터 암호화를 위한 세션 키(K_ENC)를 생성하고, 미리 설정된 KDF를 이용하여 공유 비밀키 S와 제2 컨텍스트로부터 메시지 인증을 위한 세션 키(K_MAC)를 생성할 수 있다.
동작 9208에서, UWBS(922)는 제2 임시 키(Pub_e') 및 제1 임시 키(pub_e)를 이용하여 공유 비밀키 S를 계산하는 동작, 공유 비밀키 S 및 미리 공유된 파라미터(예컨대, 1234)(제1 컨텍스트)에 기초한 암호화를 위해 사용되는 세션 키(K_ENC)의 생성 동작, 및 공유 비밀키 S 및 미리 공유된 파라미터(예컨대, ABCD)(제2 컨텍스트)에 기초한 MAC를 위한 세션 키(K_MAC)의 생성 동작을 수행할 수 있다. 예를 들면, UWBS(922)는 제2 임시 키(Pub_e') 및 제1 임시 키(pub_e)를 이용하여 공유 비밀키 S를 생성하고, 미리 설정된 KDF를 이용하여 공유 비밀키 S와 제1 컨텍스트로부터 암호화를 위한 제1 세션 키(K_ENC)를 생성하고, 미리 설정된 KDF를 이용하여 공유 비밀키 S와 제2 컨텍스트로부터 메시지 인증을 위한 제2 세션 키(K_MAC)를 생성할 수 있다. 이를 통해, UWBS(922) 및 보안 컴포넌트(923)가 동일한 암호화를 위한 키(K_ENC) 및 메시지 인증을 위한 키(K_MAC)를 소유할 수 있다.
한편, 도시된 실시예에서는, 동작 9208이, 동작 9205 이후에 수행되는 것으로 예시되어 있으나, 동작 9208은 동작 9204 이후의 어느 시점에서도 수행될 수 있다. 예를 들면, 동작 9208은 동작 9204 이후, 그리고, 동작 9205 이전에 수행될 수도 있다.
동작 9209에서, Framework(921)는 UWBS(922) 및 보안 컴포넌트(923)에 대한 랜덤 챌린지 동작을 수행할 수 있다. 예를 들면, 도시된 것처럼, Framework(921)는 랜덤 챌린지 동작을 통해, 랜덤 챌린지(랜덤 값)을 UWBS(922) 및 보안 컴포넌트(923)로 전달할 수 있다.
동작 9210에서, Framework(921)는 UWBS(922) 및 보안 컴포넌트(923)로부터 랜덤 챌린지에 대한 응답을 수신할 수 있다. 예를 들면, 도시된 것처럼, Framework(921)는 랜덤 챌린지 및 메시지 인증을 위해 사용되는 제2 세션 키(K_MAC)에 기초하여 생성된 MAC를 UWBS(922) 및 보안 컴포넌트(923)으로부터 각각 수신할 수 있다. 실시예로서, MAC를 생성하기 위해, HMAC(Hash-based Message Authentication Code) 알고리즘 또는 CMAC(Cipher-based Message Authentication Code) 알고리즘이 사용될 수 있다.
또한, Framework(921)는 UWBS(922)로부터 수신된 MAC(제1 MAC) 및 보안 컴포넌트(923)로부터 수신된 MAC(제2 MAC)가 일치하는지 여부를 결정할 수 있다.
이러한 과정을 통해, UWBS(922)는 URSK(또는, RDS)를 수신할 준비가 되며, Framework(921) 및 보안 컴포넌트(923)는 UWBS(922)로 URSK(또는, RDS)를 푸쉬할 준비가 완료될 수 있다. 예를 들면, UWBS(922)로부터 수신된 MAC(제1 MAC) 및 보안 컴포넌트(923)으로부터 수신된 MAC(제2 MAC)가 일치하는 경우, UWBS(922)는 URSK(또는, RDS)를 수신할 준비가 되며, Framework(921) 및 보안 컴포넌트(923)는 UWBS(922)로 URSK(또는, RDS)를 전달할 준비가 완료될 수 있다.
<UWBS와 제2 보안 컴포넌트(예컨대, TEE) 간의 보안 채널 설정 절차의 제3 실시예>
도 9c는 본 개시의 예시적인 실시예에 따른 Asymmetric 방식을 이용한 UWBS와 보안 컴포넌트 간의 보안 채널 설정 절차의 다른 예를 나타낸다.
도 9c의 보안 채널 설정 절차는 도 8의 동작 8100의 보안 채널 설정 절차의 일 예일 수 있다.
도 9c의 Asymmetric 방식은 PFS(Perfect Forward Secrecy)를 만족하기 위해 ECC(Elliptic curve) 기반의 임시 키(ephemeral key)를 이용하여 공유 비밀키(shared secret)를 생성하는 것을 특징으로 한다. 생성된 공유 비밀키는 세션 키를 생성하기 위해 사용될 수 있다. 또한, Asymmetric 방식은 인증을 위해서 미리 모바일 벤더가 저장한 인증서 및 개인키(static key) 가 필요하며, ephemeral key와 static key를 양측에서 ECC 알고리즘에 맞게 구성하여, shared secret을 생성하여 활용할 수 있다.
도 9c의 실시예에서는, 설명의 편의를 위해, 전자 장치가 UWB 기반 결제 서비스를 제공하기 위한 전자 장치(예컨대, 도 2b의 제1 전자 장치)이고, 보안 컴포넌트가 TEE(TA)인 것으로 가정하지만, 이에 한정되지 않는다.
도 9c의 실시예에서, 전자 장치는 UWB enabled Wallet Application(UWB enabled application)(921), Wallet Framework(Framework)(932), UWBS(933) 및 Trusted Payment Application(Trusted Application)(934)를 포함할 수 있다.
도 9c의 실시예에서, UWBS(933) 및 Trusted Payment Application(TPA)(934)는 Asymmetric cryptographic 알고리즘을 이용하는 Asymmetric 방식을 위한 키 및 인증서를 각각 포함한다. 예컨대, TPA(934)는 TPA의 비밀키(개인키)(SK.TPA), TPA의 인증서(CERT.TPA) 및/또는 Root 인증서(ROOT.OEM)를 포함하고, UWBS는 UWBS의 비밀키(개인키)(SK.UWBS), UWBS의 인증서(CERT.UWBS), 및/또는 Root 인증서(ROOT.OEM)를 포함할 수 있다. 각 키는 예컨대, 도 10b에서 설명할 키 프로비저닝 동작을 통해 보안 컴포넌트에 저장될 수 있다.
아래 표 1은 UWBS와 TEE(TPA/TA) 사이에 보안 채널을 설정하기 위해 사용되는 키 및 데이터의 일 예를 나타낸다.
| Key name | Type/Length | Purpose | Presence |
| CERT.TPA CERT.UWBS |
ECC-P256 | Public key certificate of the UWBS and Trusted Payment Application. This certificate is issued by Certificate Authority (e.g. Mobile OEM). | Mandatory |
| SK.TPA SK.UWBS |
ECC-P256 | Secret (Private) key of the Trusted Payment Application and UWBS to prove ownership of the authorization certificate. | Mandatory |
| shared credential | AES-128 | Derived shared credential by shared secret from static keys and shared secret from ephemeral keys. This value is K-MAC in accordance with the section 9.1.1.4. | Optional |
아래 표 2는 UWBS와 TEE(TPA/TA) 사이에 보안 채널을 설정하기 위해 교환되는 인증서들(예컨대, TPA의 인증서(CERT.TPA) 및 UWBS의 인증서(CERT.UWBS))의 일 예를 나타낸다.
| Tag | Length | Description | Presence |
| 0x7F21 | Certificate | Mandatory | |
| 0x93 | 1-16 | Serial number | Mandatory |
| 0x42 | Variable | CA Identifier | Optional |
| 0x5F20 | 16 | Subject identifier | Mandatory |
| 0x95 | 1 | Key Usage('82' digital signature verification, or '88' encipherment for confidentiality; see [GPCS] Table 11-17) | Optional |
| 0x5F25 | 4 | Effective Date (YYYYMMDD, BCD format) | Optional |
| 0x5F24 | 4 | Expiration Date (YYYYMMDD, BCD format) | Optional for device, not present for reader |
| 0x53 | 1-127 | Discretionary Data (unspecified format). Can be used to store the OID corresponding to the credentials, useful in case SELECT ADF with multiple selection must be supported. | Optional |
| 0x73 | 1-127 | Discretionary Data (BER-TLV encoded) | Optional |
| 0x7F49 | Public Key Data Object | Mandatory | |
| 0xB0 | 65 | Public Key Point Q (in uncompressed encoding as specified in [TR-03111] section 3.2.1) | Mandatory |
| 0xF0 | 1 | Key Parameter Reference (00 for NIST P256) | Mandatory |
| 0x5F37 | 64 | Signature value | Mandatory |
도 9c를 참조하면, 동작 9301에서, UWB enabled Wallet Application(931)은 TPA로부터 임시 키를 얻기 위한 명령을 TPA(934)로 전달할 수 있다. 예를 들면, UWB enabled Wallet Application(931)은 TPA로부터 임시 키 및/또는 서명된 임시 키를 얻기 위한 TEE 명령(예컨대, TEE Client API CMD: WALLET_GET_ EPHEMERAL_KEY)을 TPA(934)로 전달할 수 있다.아래 표 3은 WALLET_GET_EPHEMERAL_KEY에 대한 TEE 명령의 일 예를 나타낸다.
| Description | This function is to get ephemeral key and signed ephemeral key from Payment Trusted Application. Data is composed ephemeral key and signature of the ephemeral key so those are totally 64bytes(512bit). |
| commandID | 11 |
| params[1] | - Output data buffer : a buffer of 64 bytes, aligned on a byte boundary - Data flow direction : output |
| Error | TBD (0x00000001 - 0xFFFEFFFF) |
동작 9032에서, TPA(934)는 TPA의 임시 키(ePK.TPA)를 생성하고, TPA의 임시 키(ePK) 및/또는 TPA의 인증서(CERT.TPA)를 포함하는 응답을 UWB enabled Wallet Application(931)으로 전달할 수 있다. 예를 들면, TPA(934)는 TPA의 임시 키(ePK.TPA)를 생성하고, TPA의 임시 키(ePK.TPA) 및 TPA의 인증서(CERT.TPA)를 포함하는 TEE 응답(예컨대, TEE Client API Return: ePK.TPA | CERT.TPA)을 UWB enabled Wallet Application(931)으로 전달할 수 있다.동작 9033에서, UWB enabled Wallet Application(931)은 수신된 TPA의 임시 키(ePK.TPA) 및/또는 TPA의 인증서(CERT.TPA)를 Framework(932)로 전달할 수 있다. 예를 들면, UWB enabled Wallet Application(931)은 API(예컨대, Framework API)를 호출하여 수신된 TPA의 임시 키(ePK) 및 TPA의 인증서(CERT.TPA)를 Framework(932)로 전달할 수 있다.
동작 9034에서, Framework(932)는 수신된 TPA의 임시 키(ePK) 및/또는 TPA의 인증서(CERT.TPA)를 USBS(933)로 전달할 수 있다. 예를 들면, Framework(932)는 수신된 TPA의 임시 키(ePK) 및/또는 TPA의 인증서(CERT.TPA)를 포함하는 UCI 명령(예컨대, UCI CMD: WALLET_PUT_EPHEMERAL_KEY_FROM_TEE_CMD)를 USBS(933)로 전달할 수 있다. WALLET_PUT_EPHEMERAL_KEY_FROM_TEE_CMD는 TEE(TPA/TA)로부터의 임시 키 및 인증서를 UWBS에 넣기 위한 명령일 수 있다.
아래 표 4는 WALLET_PUT_EPHEMERAL_KEY_FROM_TEE_CMD에 대한 UCI 명령의 일 예를 나타낸다.
| WALLET_PUT_EPHEMERAL_KEY_FROM_TEE_CMD | ||
| Payload Field(s) |
Length
(Bits) |
Value/ Description |
| command | 0 | Put the ephemeral key and certificate from TEE to UWBS |
| Payload length | 8 | The length of Payload |
| ePK.TPA | 256 | Ephemeral key from Trusted Payment Application |
| CERT.TPA | Variable | Certificate of Trusted Payment Application |
동작 9305에서, USBS(933)는 공유 비밀 키(shared secret)을 생성하고, AES 키를 생성할 수 있다. 예를 들면, USBS(933)는 UWBS의 임시 키(ePK.UWBS)를 생성하고, UWBS의 임시 키(ePK.UWBS) 및 수신된 TPA의 임시 키(ePK.TPA)를 이용하여 shared secret S를 생성할 수 있다. 또한, USBS(933)는 생성된 shared secret S를 이용하여 암호화를 위한 AES Key(K_ENC) 및 메시지 인증을 위한 AES Key(K_MAC)를 생성할 수 있다.동작 9306에서, USBS(933)는 생성된 UWBS의 임시 키(ePK.UWBS) 및 UWBS의 인증서(CERT.UWBS)를 Framework(932)로 전달할 수 있다. 예를 들면, USBS(933)는 생성된 UWBS의 임시 키(ePK.UWBS) 및 UWBS의 인증서(CERT.UWBS)를 포함하는 UCI 응답(예컨대, UCI RSP: WALLET_PUT_EPEHERAL_KEY_FROM_TEE)를 Framework(932)로 전달할 수 있다. WALLET_PUT_EPEHERAL_KEY_FROM_TEE_RSP은 WALLET_PUT_EPHEMERAL_KEY_FROM_TEE_CMD에 대한 응답일 수 있다.
아래 표 5는 WALLET_PUT_EPEHERAL_KEY_FROM_TEE_RSP의 일 예를 나타낸다.
| WALLET_PUT_EPHEMERAL_KEY_FROM_TEE_RSP | ||
| Payload Field(s) |
Length
(bits) |
Value/ Description |
| Status | 8 | For various status values refer to Table 37 in UCI Specification of FiRa Consortium |
| Payload length | 8 | The length of Payload |
| ePK.UWBS | 256 | Ephemeral key from UWBS |
| CERT.UWBS | Variable | Certificate of UWBS |
동작 9307에서, Framework(932)는 수신된 UWBS의 임시 키(ePK.UWBS) 및/또는 UWBS의 인증서(CERT.UWBS)를 UWB enabled Wallet Application(931)로 전달할 수 있다. 예를 들면, Framework(932)는 수신된 UWBS의 임시 키(ePK.UWBS) 및/또는 UWBS의 인증서(CERT.UWBS)를 포함하는 API 응답(예컨대, API Return: ePK.UWBS | CERT.UWBS)을 UWB enabled Wallet Application(931)로 전달할 수 있다.동작 9308에서, UWB enabled Wallet Application(931)은 UWBS로부터의 임시 키를 넣기(put)위한 명령을 TPA(934)로 전달할 수 있다. 예를 들면, UWB enabled Wallet Application(931)은 UWBS부터의 임시 키 및/또는 서명된 임시 키를 TPA에 넣기 위한 TEE 명령(예컨대, TEE Client API CMD: WALLET_PUT_ EPHEMERAL_KEY)을 TPA(934)로 전달할 수 있다.
아래 표 6은 WALLET_PUT_EPHEMERAL_KEY에 대한 TEE 명령의 일 예를 나타낸다.
| Description | This function is to put ephemeral key and signed ephemeral key from UWBS to Trusted Payment Application so those are totally 64bytes(512bit). |
| commandID | 12 |
| params[0] | -Input data buffer : a buffer of 64 bytes, aligned on a byte boundary -Data flow direction : input |
| Error | TBD (0x00000001 - 0xFFFEFFFF) |
동작 9309에서, TPA(934)는 공유 비밀 키(shared secret)을 생성하고, AES 키를 생성할 수 있다. 예를 들면, TPA(934)는 수신된 UWBS의 임시 키(ePK.UWBS) 및 자신(TPA)의 임시 키(ePK.TPA)를 이용하여 shared secret S를 생성할 수 있다. 또한, TPA(934)는 생성된 shared secret S를 이용하여 암호화를 위한 AES Key(K_ENC) 및 메시지 인증을 위한 AES Key(K_MAC)를 생성할 수 있다.동작 9310에서, TPA(934)는 UWBS로부터의 임시 키를 넣기 위한 명령에 대한 응답을 UWB enabled Wallet Application(931)으로 전달할 수 있다. 예를 들면, TPA(934)는 OK/NOK를 지시하는 TEE 응답(예컨대, TEE Client API Return: OK/NOK)을 UWB enabled Wallet Application(931)으로 전달할 수 있다.
도 9d는 본 개시의 예시적인 실시예에 따른 UWBS와 보안 컴포넌트 간의 보안 채널을 통해 UWBS가 보안 컴포넌트로 RDS를 전달하는 절차를 나타낸다.
도 9d의 실시예에서, UWBS와 보안 컴포넌트 간의 보안 채널은 예컨대, 도 9c의 보안 채널 설정 절차를 통해 설정될 수 있다.
도 9d의 실시예에서는, 설명의 편의를 위해, 전자 장치가 UWB 기반 결제 서비스를 제공하기 위한 전자 장치(예컨대, 도 2b의 제1 전자 장치)이고, 보안 컴포넌트가 TEE(TA)인 것으로 가정하지만, 이에 한정되지 않는다.
도 9d의 실시예에서, 전자 장치는 UWB enabled Wallet Application(UWB enabled application)(941), Wallet Framework(Framework)(942), UWBS(943) 및 Trusted Payment Application(Trusted Application)(944)를 포함할 수 있다.
동작 9401에서, UWB enabled Wallet Application(941)은 랜덤 챌린지(랜덤 값)을 TPA(944)로 전달할 수 있다. 예를 들면, UWB enabled Wallet Application(941)은 랜덤 챌린지를 포함하는 TEE 명령(예컨대, TEE Client API CMD: WALLET_PUT_CHALLENGE)를 TPA(944)로 전달할 수 있다. WALLET_PUT_CHALLENGE는 TPA로부터 MAC(예컨대, CMAC)를 얻기 위해 사용되며, 입력은 랜덤 값을 포함하며, 출력은 랜덤 값 및 shared secret의 MAC 값을 포함한다.
아래 표 7은 WALLET_PUT_CHALLENGE 에 대한 TEE 명령의 일 예를 나타낸다.
| Description | This function is to get CMAC from Trusted Payment Application. Input with random value and output with CMAC value of the random value and shared secret. This can check whether UWBS and Trusted Payment Application have same shared secret. |
| commandID | 21 |
| params[0] | - Input data buffer : a buffer of 16 bytes, aligned on a byte boundary- Data flow direction : input |
| params[1] | - Output data buffer: same length as input buffer, aligned on a byte boundary.- Data flow direction: output |
| Error | TBD (0x00000001 - 0xFFFEFFFF) |
동작 9402에서, TPA(944)는 TPA의 MAC(MAC.TPA)를 UWB enabled Wallet Application(941)로 전달할 수 있다. 예를 들면, TPA(944)는 수신된 랜덤 챌린지 및 shared secret에 기초하여 MAC(MAC.TPA)를 생성하고, MAC(MAC.TPA)를 포함하는 TEE 응답(예컨대, TEE Client API Return: MAC.TPA)를 UWB enabled Wallet Application(941)로 전달할 수 있다.동작 9403에서, UWB enabled Wallet Application(941)는 랜덤 챌린지(랜덤 값)을 Framework(942)로 전달할 수 있다. 예를 들면, UWB enabled Wallet Application(941)는 API(Framework API) 호출을 통해 랜덤 챌린지(랜덤 값)을 Framework(942)로 전달할 수 있다.
동작 9404에서, Framework(942)는 수신된 랜덤 챌린지를 UWBS(943)으로 전달할 수 있다. 예를 들면, Framework(942)는 수신된 랜덤 챌린지를 UWBS(943)를 포함하는 UCI 명령(예컨대, WALLET_PUT_CHALLENGE_CMD)를 UWBS(943)으로 전달할 수 있다. WALLET_PUT_CHALLENGE _CMD은 UWBS로부터 UWBS의 MAC(MAC.UWBS)를 얻기 위해 사용될 수 있다.
아래 표 8은 WALLET_PUT_CHALLENGE_CMD 의 일 예를 나타낸다.
| WALLET_PUT_CHALLENGE_CMD | ||
| Payload Field(s) |
Length
(bits) |
Value/ Description |
| command | 0 | Get the MAC.UWBS from UWBS |
| Nonce | 128 | Random number used at once |
동작 9405에서, UWBS(943)은 UWBS의 MAC(MAC.UWBS)를 Framework(942)로 전달할 수 있다. 예를 들면, UWBS(943)은 수신된 랜덤 챌린지 및 shared secret에 기초하여 MAC(MAC.UWBS)를 생성하고, MAC(MAC.UWBS)를 포함하는 UCI 응답(예컨대, WALLET_PUT_CHALLENGE_RSP)를 Framework(942)로 전달할 수 있다. 아래 표 9은 WALLET_PUT_CHALLENGE_RSP의 일 예를 나타낸다.
| WALLET_PUT_CHALLENGE_RSP | ||
| Payload Field(s) |
Length
(bits) |
Value/ Description |
| Status | 8 | For various status values refer to Table 37 in UCI Specification of FiRa Consortium |
동작 9406에서, Framework(942)는 수신된 UWBS의 MAC(MAC.UWBS)를 UWB enabled Wallet Application(941)으로 전달할 수 있다. 예를 들면, Framework(942)는 API 리턴을 통해 UWBS의 MAC(MAC.UWBS)를 UWB enabled Wallet Application(941)으로 전달할 수 있다.동작 9407에서, UWB enabled Wallet Application(941)는 TPA의 MAC(MAC.TPA) 및 UWBS의 MAC(MAC.UWBS)가 동일한지를 결정할 수 있다.
동작 9408에서, UWB enabled Wallet Application(941)는 RDS를 얻기 위한 명령을 TPA(944)로 전달할 수 있다. 예를 들면, TPA의 MAC(MAC.TPA) 및 UWBS의 MAC(MAC.UWBS)가 동일한 경우, UWB enabled Wallet Application(941)는 RDS를 얻기 위한 TEE 명령(예컨대, TEE Client API Command: TEE WALLET_GET_RDS)을 TPA(944)로 전달할 수 있다. WALLET_GET_RDS은 TPA로부터 암호화된 RDS를 얻기 위해 사용될 수 있다.
아래 표 10은 WALLET_GET_RDS에 대한 TEE 명령의 일 예를 나타낸다.
| Description | This function is to get encrypted RDS from Trusted Payment Application. |
| commandID | 31 |
| params[0] | - Value : a=Encryption Key ID- Data flow direction : input |
| params[1] | - Output data buffer: a buffer of 64bytes, aligned on a byte boundary. - Data flow direction: output |
| Error | TBD (0x00000001 - 0xFFFEFFFF) |
동작 9409에서, TPA(944)는 암호화된 RDS(Encrypted_blob)을 UWB enabled Wallet Application(941)로 전달할 수 있다. 예를 들면, TPA(944)는 암호화된 RDS(Encrypted_blob) 및 암호화된 RDS의 MAC(MAC.eRDS)를 포함하는 TEE 응답(예컨대, TEE Client API Return: Encrypted_blob | MAC.eRDS)를 UWB enabled Wallet Application(941)로 전달할 수 있다.동작 9410에서, UWB enabled Wallet Application(941)는 수신된 암호화된 RDS(Encrypted_blob)을 Framework(942)로 전달할 수 있다. 예를 들면, UWB enabled Wallet Application(941)는 API(Framework API) 호출을 통해 암호화된 RDS(Encrypted_blob) 및 암호화된 RDS의 MAC(MAC.eRDS)를 Framework(942)로 전달할 수 있다.
동작 9411에서, Framework(942)는 수신된 암호화된 RDS(Encrypted_blob)를 UWBS(943)으로 전달할 수 있다. 예를 들면, Framework(942)는 암호화된 RDS(Encrypted_blob) 및 암호화된 RDS의 MAC(MAC.eRDS)를 포함하는 UCI 명령(예컨대, WALLET_PUT_ENCRYPTED_RDS_CMD)를 UWBS(943)으로 전달할 수 있다. WALLET_PUT_ENCRYPTED_RDS_CMD은 UWBS로부터 UWBS의 RDS를 넣기 위해 사용될 수 있다.
아래 표 11은 WALLET_PUT_ENCRYPTED_RDS_CMD의 일 예를 나타낸다.
| WALLET_PUT_ENCRYPTED_RDS _CMD | ||
| Payload Field(s) |
Length
(bits) |
Value/ Description |
| command | 0 | Get the capability data from UWBS |
| Payload length | 8 | The length of Payload |
| Encrypted RDS | variable | RDS, which is encrypted by K-ENC in section 9.1.1.4 |
| MAC of encrypted RDS | 128 | MAC of encrypted RDS, which is derived by K-MAC in section 9.1.1.4. |
동작 9412에서, UWBS(943)은 응답을 Framework(942)로 전달할 수 있다. 예를 들면, UWBS(943)은 UCI 명령에 대응하는 UCI 응답(예컨대, WALLET_PUT_ENCRYPTED_RDS_RSP)를 Framework(942)로 전달할 수 있다. WALLET_PUT_ENCRYPTED_RDS_RSP은 암호화된 RDS가 정상적으로 수신되었는지에 대한 상태(OK/NOK)를 나타내는 정보를 포함할 수 있다.아래 표 12는 WALLET_PUT_ENCRYPTED_RDS_RSP 의 일 예를 나타낸다.
| WALLET_PUT_ENCRYPTED_RDS _RSP | ||
| Payload Field(s) | Length | Value/ Description |
| Status | 1 Octet | For various status values refer to Table 37 in UCI Specification of FiRa Consortium |
도 10a는 본 개시의 예시적인 실시예에 따른 제1 보안 컴포넌트를 포함하는 전자 장치를 위한 키 프로비저닝(provisioning) 방법을 나타낸다.
도 10a의 전자 장치는 도 5의 전자장치일 수 있고, 제1 보안 컴포넌트는 SE(예컨대, eSE)일 수 있다.
도 10a를 참조하면, 동작 1에서, Service Provider(SP)(1011)의 키 프로비저닝를 위해, Provisioning Authority(PA)(1012)는 인증(authorization)을 SD(Security Domain) Owner(1013)에게 요청할 수 있고, 동작 2에서, SD Owner(1013)는 요청에 기초하여 PA credential을 제1 보안 컴포넌트(1014)로 제공할 수 있다. 동작 3에서, SP(1011)는 PA(1012)에 ADF(s)를 요청할 수 있고, 동작 4에서, PA(1012)는 요청에 기초하여 ADF(s)를 제1 보안 컴포넌트(1014)로 제공할 수 있다. 동작 5에서, SP(1011)는 제1 보안 컴포넌트(1014)로 제공된 ADF에 대한 personalization을 수행할 수 있다.
이와 같이, 서비스 프로바이더(1011)가 제1 보안 컴포넌트(1014)에 대해 키 프로비저닝을 제공하기 위하여는, 다양한 비즈니스 계약 관계에 있는 여러 엔티티(PA, SD Owner 등)의 협조가 필요하다. 따라서, 서비스 프로바이더(1011)가 키를 바로 제1 보안 컴포넌트(1014)로 제공하기 어렵다. 즉, 서비스 프로바이더(1011)가 유연하고 효율적으로 키를 제공하기 어렵게 된다.
도 10b는 본 개시의 일 실시예에 따른 제2 보안 컴포넌트를 포함하는 전자 장치를 위한 키 프로비저닝(provisioning) 방법을 나타낸다.
도 10b의 전자 장치는 도 6의 전자장치일 수 있고, 제2 보안 컴포넌트는 TEE(TA) 또는 SB일 수 있다.
도 10b의 실시예에서, 전자 장치는 모바일 플랫폼(예컨대, Android 플랫폼)(1022) 및 제2 보안 컴포넌트(1023)를 포함할 수 있다. 일 실시예에서, 모바일 플랫폼은 상술한 Framework를 포함할 수 있다.
도 10b를 참조하면, 동작 1에서, 서비스 프로바이더(1021)는 키 프로비저닝을 위한 API를 호출하고, 동작 2에서, 모바일 플랫폼(1022)은 제2 보안 컴포넌트(1023)로 증명(attestation)을 제공할 수 있다. 동작 3에서, 제2 보안 컴포넌트(1023)는 인증서(certificate)를 모바일 플랫폼(1022)에 전송하고, 동작 4에서, 모바일 플랫폼(1022)은 인증서를 서비스 프로바이더(1021)에게 전송한다. 동작 5에서, 서비스 프로바이더(1021)는 암호화된 키를 모바일 플랫폼(1022)으로 전송하고, 동작 6에서, 모바일 플랫폼(1022)은 암호화된 키를 제2 보안 컴포넌트(1023)로 전송할 수 있다.
제2 보안 컴포넌트를 이용하는 도 10b의 실시예에서는, 제1 보안 컴포넌트를 이용하는 도 10a의 실시예와 달리, 서비스 프로바이더(1021)가 보안화된 방법(secure manner)으로 고유 크리덴셜(own credential)을 신뢰된 영역(trusted area), 예컨대, TEE 또는 SB에 임포팅(import)할 수 있다. 이 경우, 전자 장치의 모바일 플랫폼(또는, 프레임워크)(1022)은 프로비저닝 방식을 위한 API만을 제공하면 된다. 따라서, 서비스 프로바이더(1021)가 유연하고 효율적으로 키를 제공할 수 있다.
도 11은 본 개시의 일 실시예에 따른 제2 보안 컴포넌트를 포함하는 전자 장치를 위한 키 프로비저닝을 위한 증명(attestation) 절차를 나타낸다.
도 11의 실시예에서, 전자 장치는 도 6의 전자장치일 수 있고, 제2 보안 컴포넌트는 TEE(TA) 또는 SB일 수 있다.
도 11의 실시예에서, attestation 절차는 도 10의 절차의 일부일 수 있다. attestation 절차는 키 프로비저닝이 수행되기 이전에 수행된다.
도 11을 참조하면, 동작 1101에서, 전자 장치의 UWB-enabled Application는 서비스 프로바이더(서버)로 넌스(nonce)를 요청하고, 동작 1102에서, 서비스 프로바이더는 요청에 기초하여 넌스를 UWB-enabled Application에게 제공할 수 있다.
동작 1103에서, UWB-enabled Application는 넌스를 포함하는 증명(attest)(attestation request)를 Framework로 전송할 수 있고, 동작 1104에서, Framework는 이 attest(attestation request)를 제2 보안 컴포넌트에 전송할 수 있다.
동작 1105에서, 제2 보안 컴포넌트는 attest(attestation request)에 기초한 Blob(attestation response)을 Framework로 리턴할 수 있다. 일 실시예에서, Blob(attestation response)은 넌스, measurement(s), Device ID, 서명 및/또는 인증서를 포함할 수 있다. 동작 1106에서, Framework는 Blob을 UWB-enabled Application로 전송하고, 동작 1107에서, UWB-enabled Application는 Blob을 서비스 프로바이더로 전송할 수 있다.
동작 1108에서, 서비스 프로바이더는 Blob으로부터 공개 키를 추출하고, 공개 키를 기초로 키 랩핑(key wrapping) 방식을 이용하여 크리덴셜(예컨대, Secure Channel Key)을 암호화할 수 있다.
동작 1109에서, 서비스 프로바이더는 랩핑된 키(wrapped key)를 UWB-enabled Application로 전송하고, 동작 1110에서, UWB-enabled Application는 랩핑된 키를 제2 보안 컴포넌트로 전송할 수 있다. 동작 1111에서, 제2 보안 컴포넌트는 랩핑된 키를 OID 및/또는 AppID와 함께 임포팅할 수 있다.
이와 같은 절차를 통해, 키(보안 채널 키)가 서비스 프로바이더에 의해 제2 보안 컴포넌트에 안전하게(securely) 임포팅될 수 있다.
도 12는 본 개시의 예시적인 실시예에 따른 전자 장치의 예시적인 구성을 나타낸다.
도 12의 실시예에서, 전자 장치(1200)는 예컨대, Smart Ranging device 또는 Ranging device일 수 있다.
도 12를 참조하면, 전자 장치(1200)는 적어도 하나의 어플리케이션(1210), Framework(1220), UWBS(1230) 및/또는 보안 컴포넌트(1240)(예컨대, TA 및/또는 Strongbox)를 포함한다.
각 어플리케이션(1210)은 AppID에 의해 식별되며, Framework(1220)의 Framework API를 호출/사용할 수 있다. 일 실시예에서, 어플리케이션(1210)은 UWB-enabled Application일 수 있다.
Framework(1220)는 OOB Connector(1221), 및/또는 Secure Service(1222)를 포함하고, Framework API(1223)를 통해, 어플리케이션(1210)과 인터페이싱할 수 있다. Framework API(1223)는 예컨대, 어플리케이션의 등록을 위한 Register() API, 보안 메시징 세션의 설정을 위한 setSecureMessagingSession() API, 레인징 데이터(또는, RDS)의 설정을 위한 setRangingData() API, 및/또는 URSK(또는, RDS)의 UWBS로의 전달을 위한 pushURSKtoUWBS() API를 포함할 수 있다.
보안 컴포넌트(1240)는 Cryptogram 생성 기능(genCryptogram) 및/또는 암호화된 메시지 생성 기능(genEncyptedMsg)을 지원하고, 어플리케이션에 대응하는 보안 채널 키(예컨대, AppID(#ABC))를 갖는 어플리케이션에 대응하는 보안 채널 키(예컨대, SC02Key), AppID(#XYZ)를 갖는 어플리케이션에 대응하는 보안 채널 키(예컨대, SC01Key))를 포함할 수 있다. 예를 들면, SB(1241)는 Cryptogram 생성 기능(genCryptogram) 및/또는 암호화된 메시지 생성 기능(genEncyptedMsg)을 지원하고, AppID(#XYZ)를 갖는 어플리케이션에 대응하는 보안 채널 키(예컨대, SC01Key))를 포함할 수 있다. 다른 예를 들면, TEE(TEE의 TA)(1242)는 Cryptogram 생성 기능(genCryptogram) 및/또는 암호화된 메시지 생성 기능(genEncyptedMsg)을 지원하고, AppID(#XYZ)를 갖는 어플리케이션에 대응하는 보안 채널 키(예컨대, SC01Key))를 포함할 수 있다.
일 실시예에서, 보안 컴포넌트(1240)는 세션 ID 및/또는 UWB 세션 키(URSK)를 생성/저장할 수 있다. 세션 ID 및/또는 UWB 세션 키는 예컨대, 어플리케이션(1210)의 pushURSKtoUWBS() API의 호출에 의해 Framwork(1220)를 통해 보안 컴포넌트(1240)로부터 UWBS(1230)로 전달될 수 있다.
도 13은 본 개시의 일 실시예에 따른 전자 장치의 방법을 나타내는 흐름도이다.
도 13의 실시예에서, 전자 장치는 Smart Ranging Device 또는 Ranging Device일 수 있다. 도 13의 실시예의 각 동작에 대한 상세한 설명은 도 1 내지 12에서 상술한 설명을 참조할 수 있다. 도 13의 실시예에서, 전자 장치의 동작은 예컨대, 전자 장치의 프레임워크(또는, 어플리케이션)의 동작 또는 전자 장치의 프레임워크(또는, 어플리케이션)를 제어하는 제어부(또는, 프로세서)의 동작일 수 있다.
전자 장치는 보안 레인징을 위한 레인징 데이터 세트를 설정하기 위한 요청을 보안 컴포넌트로 전송할 수 있다(1310). 예를 들면, 전자 장치는 보안 레인징을 위한 레인징 데이터 세트를 설정하기 위한 요청을 TEE(또는, TEE 내의 TA)로 전송할 수 있다. 본 개시에서, 레인징 데이터 세트는 UWB 레인징을 위해 필요한 데이터의 세트일 수 있다. 일 실시예에서, 레인징 데이터 세트는 보안 레인징과 연관된 UWB 세션을 세션 ID 정보, 및 UWB 세션을 보호하기 위한 세션 키 정보 중 적어도 하나를 포함할 수 있다.
전자 장치는 레인징 데이터 세트를 UWB 서브시스템으로 전달하기 위한 요청을 보안 컴포넌트로 전송할 수 있다(1320). 예를 들면, 전자 장치는 데이터 세트를 UWB 서브시스템으로 전달하기 위한 요청을 TEE(또는, TEE 내의 TA)로 전송할 수 있다. 일 실시예에서, 레인징 데이터 세트는 프레임워크를 통해 보안 컴포넌트와 UWB 서브시스템 사이에 설정된 보안 채널을 이용하여 보안 컴포넌트로부터 상기 UWB 서브시스템으로 전달될 수 있다.
일 실시예에서, 레인징 데이터 세트를 설정하기 위한 요청을 전송하는 동작은 보안 컴포넌트가 상기 레인징 데이터 세트를 설정하도록 요청하는 프레임워크 API(setRangingData() API)를 호출하는 동작을 포함하며, 프레임워크 API는 상기 프레임워크 API를 호출한 어플리케이션을 식별하기 위한 어플리케이션 ID를 포함할 수 있다.
일 실시예에서, 상기 레인징 데이터 세트를 UWB 서브시스템으로 전달하기 위한 요청을 전송하는 동작은 보안 컴포넌트가 레인징 데이터 세트를 UWB 서브시스템으로 전달하도록 요청하는 프레임워크 API(PushRDStoUWBS() API)를 호출하는 동작을 포함하며, 프레임워크 API는 프레임워크 API를 호출한 어플리케이션을 식별하기 위한 어플리케이션 ID를 포함할 수 있다.
일 실시예에서, 프레임워크가, UWB 서브시스템으로 보안 레인징을 시작하는 명령을 전송하는 동작을 더 포함하고, 보안 레인징을 시작하는 명령은 보안 레인징과 연관된 어플리케이션을 식별하기 위한 어플리케이션 ID를 포함할 수 있다.
일 실시예에서, 보안 컴포넌트와 UWB 서브시스템 사이의 보안 채널은 Asymmetric key 기반 보안 채널일 수 있다.
일 실시예에서, 보안 컴포넌트는 TEE(Trusted Execution Environment) 또는 Strongbox일 수 있다.
도 14는 본 개시의 일 실시예에 따른 제1 전자 장치의 구조를 도시한 도면이다.
도 14의 제1 전자 장치는 제2 보안 컴포넌트(예컨대, TEE 또는 SB)를 포함하는 전자 장치(예컨대, Smart Ranging Device)일 수 있다.
도 14를 참고하면, 제1 전자 장치는 송수신부 (1410), 제어부 (1420), 저장부 (1430)을 포함할 수 있다. 본 개시에서 제어부는, 회로 또는 어플리케이션 특정 통합 회로 또는 적어도 하나의 프로세서라고 정의될 수 있다.
송수신부 (1410)는 다른 전자 장치와 신호를 송수신할 수 있다. 송수신부(1410)는 예컨대, UWB 통신을 이용하여 데이터를 송수신할 수 있다.
제어부 (1420)은 본 개시에서 제안하는 실시예에 따른 UWB 인밴드 탐색 방법의 전반적인 동작을 제어할 수 있다. 예를 들어, 제어부 (1420)는 상기에서 기술한 순서도에 따른 동작을 수행하도록 각 블록 간 신호 흐름을 제어할 수 있다. 구체적으로, 제어부(1420)는, 예컨대, 도 1 내지 13을 참조하여 설명한 보안 레인징을 위한 방법의 동작을 제어할 수 있다.
저장부(1430)는 상기 송수신부 (1410)를 통해 송수신되는 정보 및 제어부 (1420)을 통해 생성되는 정보 중 적어도 하나를 저장할 수 있다. 예를 들어, 저장부 (1430)는 예컨대, 도 1 내지 13을 참조하여 설명한 보안 레인징을 위한 정보 및 데이터를 저장할 수 있다.
도 15는 본 개시의 일 실시예에 따른 제2 전자 장치의 구조를 도시한 도면이다.
도 15의 제2 전자 장치는 도 14의 제1 전자 장치와 통신하는 전자 장치(예컨대, Smart Ranging Device 또는 Ranging Device)일 수 있다.
도 15를 참고하면, 제2 전자 장치는 송수신부 (1510), 제어부 (1520), 저장부 (1530)을 포함할 수 있다. 본 개시에서 제어부는, 회로 또는 어플리케이션 특정 통합 회로 또는 적어도 하나의 프로세서라고 정의될 수 있다.
송수신부 (1510)는 다른 전자 장치와 신호를 송수신할 수 있다. 송수신부(1510)는 예컨대, UWB 통신을 이용하여 데이터를 송수신할 수 있다.
제어부 (1520)은 본 개시에서 제안하는 실시예에 따른 UWB 인밴드 탐색 방법의 전반적인 동작을 제어할 수 있다. 예를 들어, 제어부 (1520)는 상기에서 기술한 순서도에 따른 동작을 수행하도록 각 블록 간 신호 흐름을 제어할 수 있다. 구체적으로, 제어부(1520)는, 예컨대, 도 1 내지 13을 참조하여 설명한 보안 레인징을 위한 동작을 제어할 수 있다.
저장부(1530)는 상기 송수신부 (1510)를 통해 송수신되는 정보 및 제어부 (1520)을 통해 생성되는 정보 중 적어도 하나를 저장할 수 있다. 예를 들어, 저장부 (1530)는 예컨대, 도 1 내지 13을 참조하여 설명한 보안 레인징을 위한 정보 및 데이터를 저장할 수 있다.
<실시예 B>
실시예 B는 상술한 attached 모드와 관련된 실시예에 해당한다. 이하에서는, 도 16 내지 27을 참조하여, 실시예 A에 대하여 예시적으로 설명한다.
* 도 16은 SE를 포함하는 UWB 장치의 예시적인 구성을 나타낸다.
도 16의 실시예에서, UWB 장치(1600)는 보안 컴포넌트로서 Secure Element(예컨대, eSE)를 포함하는 UWB 장치(예컨대, FiRa Smart Device 또는 FiRa Device)일 수 있다.
상술한 것처럼, SE는 tamper resistant 특성을 기반으로 한 안전한 보안 모듈이고, eSE는 전자 장치에 고정하여 사용하는 고정식 SE를 의미한다.
도 16을 참조하면, UWB 장치(1600)는 적어도 하나의 어플리케이션(UWB-enabled Application)(1610), Framework(1620), Secure element(1630) 및/또는 UWBS(1640)를 포함할 수 있다. UWB-enabled Application(1610), Framework(1620)에 대한 설명은 도 1 내지 3에서 상술한 설명을 참조할 수 있다.
일 실시예에서, SE(예컨대, eSE)(1630)는 Applet(Service Applet) 및/또는 SUS(Secure UWB Service) Applet을 포함할 수 있다. Applet은 보안 데이터(예컨대, Ranging Data Set(RDS))를 안전하게 생성하기 위해 요구되는 적어도 하나의 Application Dedicated File (ADF)를 포함할 수 있다. 예를 들면, Applet은 각 서비스 프로바이더(SP)에 의해 제공된 ADF를 각각 포함할 수 있다. ADF는 키 프로비저닝 단계에서, 서비스 프로바이더에 의해 제공될 수 있다. 또한, Applet은 RDS를 SUS Applet을 통해 UWBS로 전달할 수 있다.
일 실시예에서, RDS는 UWB 레인징 세션을 보안하기 위해 사용되는 키를 나타내는 레인징 세션 키(UWB 레인징 세션 키) 및/또는 RDS(또는, RDS와 연관된 세션)을 식별하는 세션 ID를 포함할 수 있다. 이때, 레인징 세션 키 및 세션 ID는 개시자(initiator) 및 응답자(responder)에서 동일하여야 한다. 또한, RDS는 적어도 하나의 레인징 파라미터(예컨대, AoA (Angle of Arrival), 근접 거리(Proximity Distance)), 클라이언트 특정 데이터 및/또는 멀티캐스트 응답자-특정 키(Multicast responder-specific key)를 옵셔널하게 더 포함할 수 있다.
UWBS(1640)는 UWB 하드웨어를 관리한다. UWBS(1640)는 다른 Ranging Device의 UWBS와 UWB 세션을 수행할 수 있다. UWBS(1640)는 Framework(1620)에 의해 관리되며, SE(1630)로부터 secure ranging을 위해 필요한 RDS를 수신할 수 있다.
일 실시예에서, UWB 장치(1600)의 각 구성은 미리 정의된 인터페이스를 통해 서로 통신할 수 있다. 예를 들면, 어플리케이션(1610)과 프레임워크(1620)는 미리 정의된 Framework API(Application Programming Interface)를 통해 통신할 수 있다. 프레임워크(1620)와 SE(eSE)(1630)는 미리 정의된 OMAPI(Object Management Application Programming Interface)를 통해 통신할 수 있다. 프레임워크(1620)와 UWBS(1640)는 미리 정의된 UCI를 통해 통신할 수 있다. UWBS(1640)와 SE(eSE)(1630)는 미리 정의된 SUS API를 통해 통신할 수 있다. 다만, 상술한 인터페이스들은 각 구성이 서로 통신하기 위한 인터페이스의 일 예에 불과하고, 실시예에 따라서는 다른 종류의 인터페이스를 사용하여 각 구성이 서로 통신할 수도 있다.
도 17은 SE를 포함하는 UWB 장치의 동작을 나타낸다.
도 17의 실시예의 UWB 장치(1700)는, 도 16의 UWB 장치일 수 있다. 도시된 것처럼, UWB 장치(1700)는 적어도 하나의 어플리케이션(UWB-enabled Application)(1710), Framework(1720), Secure element(예컨대, eSE)(1730) 및/또는 UWBS(1740)를 포함할 수 있다. UWB 장치(1700)는 다른 UWB 장치(1750)와 통신을 수행할 수 있다. 일 실시예에서, UWB 장치(1700)는 다른 UWB(1750) 장치로부터 UWB 레인징을 위한 제어 메시지(정보)를 수신하는 controlee로 동작할 수 있다.
도 17을 참조하면, 절차 1(동작 1)에서, UWB 장치(1700)는 다른 UWB 장치(1750)와 UWB 세션 파라미터의 교환을 위한 절차를 수행할 수 있다. 일 실시예에서, UWB 장치(1700)는 UWB 세션 파라미터 교환을 위해, OOB 컴포넌트(예컨대, BLE 컴포넌트)를 이용하여 설정된 보안 채널을 이용할 수 있다. 일 실시예에서, UWB 세션 파라미터는 UWB 레인징 세션을 보안하기 위해 사용되는 키를 나타내는 레인징 세션 키(UWB 레인징 세션 키) 및/또는 RDS(또는, RDS와 연관된 세션)을 식별하는 세션 ID를 포함할 수 있다. 일 실시예에서, UWB 세션 파라미터는 UWB 장치(1700) 및/또는 다른 UWB 장치(1750)의 Applet에 의해 생성될 수 있다. 절차 1을 통해 교환된 UWB 세션 파라미터는 eSE(1730)에 저장될 수 있다.
절차 2(동작 2)에서, 프레임워크(1720)는 eSE(1730)로 UWB 파라미터를 요청할 수 있고, eSE(1730)는 요청에 응답하여 UWB 파라미터를 프레임워크(1720)로 전달(return)할 수 있다. 일 실시예에서, 프레임워크(1720)와 eSE(1730)는 UWB 파라미터 교환을 위해 미리 정의된 OMAPI를 이용할 수 있다. 일 실시예에서, UWB 파라미터는 eSE(1730)에 저장된 UWB 세션 파라미터의 일부 또는 전부를 포함할 수 있다. 예를 들면, UWB 파라미터는 UWB 세션 파라미터 내의 세션 ID를 포함할 수 있다. UWB 파라미터는 eSE(1730)에 저장된 UWB 장치의 정보(예컨대, controlee info) 파라미터의 일부 또는 전부를 더 포함할 수 있다.
절차 3(동작 3)에서, 프레임워크(1720)와 UWBS(1740)는 UWB 파라미터 설정을 위한 절차를 수행할 수 있다. 일 실시예에서, 프레임워크(1720)는 세션 ID를 UWBS(1740)로 전달할 수 있다. 프레임워크(1720)와 UWBS(1740)는 UWB 파라미터 설정을 위해 미리 정의된 UCI를 이용할 수 있다.
절차 4(동작 4)에서, UWBS(1740)는 eSE(1730)로부터 보안 파라미터를 획득하기 위한 동작을 수행할 수 있다. 예를 들면, UWBS(1740)는 보안 파라미터를 검색하기 위해, UWB 세션을 찾을 수 있다. 일 실시예에서, UWBS(1740)는 프레임워크(1720)를 통해 전달된 세션 ID를 이용하여 RDS를 eSE(1730)로부터 획득할 수 있다. 이 경우, UWBS(1740)는 UWBS(1740)와 eSE(1730) 간에 설정된 보안 채널을 이용하여 RDS를 획득할 수 있다. 일 실시예에서, UWBS(1740)는 보안 파라미터 획득을 위해 미리 정의된 SUS API(예컨대, SUS external API)를 이용할 수 있다.
한편, 도 17의 실시예의 경우, 프레임워크(1720)가 예컨대, 보안 레인징 등을 위해 UWBS(1740)를 호출하기 위해, UWB 세션 파라미터(예컨대, 세션 ID)가 필요하다. 따라서, 절차 2(동작 2)에서와 같이, eSE(1730)에 안전하게 저장된 UWB 세션 파라미터가 복호화되어 프레임워크(1720)로 전달되어야 한다. 이 경우, 세션 ID와 같은 보안 파라미터가 노출되게 되어 보안성 문제가 생길 수 있다. 또한, 도 17의 실시예의 경우, 모든 파라미터에 접근 규칙(access rule)을 설정(예컨대, R/W from remote/local)하여야 하여, 접근 제어에 부담이 생길 수 있다. 또한, 도 17의 실시예의 경우, eSE(1730)의 연산 성능 및 메모리 제약으로 인하여, 다수의 어플리케이션을 처리하는데 한계를 갖는다. 이하에서는, 이러한 문제를 해소할 수 있는 실시예들에 대하여 각 도면을 참조하여 설명한다.
도 18은 본 개시의 일 실시예에 따른, TEE를 포함하는 UWB 장치의 예시적인 구성을 나타낸다.
도 18을 참조하면, UWB 장치(1800)는 적어도 하나의 어플리케이션(UWB-enabled Application)(1810), 프레임워크(1820), 및/또는 TEE(1830)를 포함한다. UWB 장치(1800)는 OOB 컴포넌트를 더 포함할 수 있다. 도 18의 프레임워크(1820), UWBS(1833), UWB-enabled Application(1810) 및 OOB 컴포넌트는 본 개시에서, 새롭게 정의/설명한 내용을 제외하고는 기본적으로 예컨대, 도 1 내지 3에서 상술한 프레임워크, UWBS, UWB-enabled Application 및 OOB 컴포넌트의 정의/설명을 따를 수 있다.
도 18을 참조하면, TEE(1830)는 적어도 하나의 TA(Trusted application)(1831), Secure OS(Trusted OS)(1832) 및/또는 UWBS(1833)를 포함할 수 있다. 도 6의 실시예에서, UWBS(1833)는 도시된 것처럼, TEE 영역 내에 포함될 수 있다. 즉, UWBS(1833)은 TEE(1830)의 Secure OS(Driver TA)(1832)에 직접 연결된 것일 수 있다. 따라서, UWBS(1833)는 TEE 영역의 외부에 위치하는 것 보다 높은 신뢰도 및 보안 레벨을 가질 수 있다.
TEE(1830)는 코드를 실행하는 환경으로서, 높은 수준의 신뢰도(trust)를 가질 수 있다. TEE(1830)에서 신뢰도는 범용 소프트웨어 환경과 비교할 때, TEE 영역(공간)에 저장된 아이템들에 대한 유효성(validity), 격리도(isolation) 및 접근 제어(access control)에서 더 높은 레벨의 신뢰를 가짐을 의미할 수 있다. 따라서, TEE 영역 내에서 실행되는 TA(1831) 및 Secure OS(1832)는 더 높은 신뢰도를 가질 수 있다. 일 실시예에서, TEE(1830)(또는, TA(1831))는 미리 정의된 인터페이스(예컨대, TEE Client API)를 통해 다른 컴포넌트와 통신할 수 있다. 예를 들면, TEE(1830)(또는, TA(1831))는 미리 정의된 인터페이스(예컨대, TEE Client API)를 통해 어플리케이션(1810)과 통신할 수 있다.
TA(1831)는 TEE(1830)의 어플리케이션으로서, REE(Rich Operating System Execution Environment)에서의 어플리케이션의 불확실한 특성과 구별되기 위해 TA 로 지칭된다. 본 개시에서, TA(1831)(또는, TA의 ADF)는 RDS를 생성/저장/전달하는 역할을 수행할 수 있고, 프레임워크(1820)(또는, 프레임워크와 통신하는 UWBS(1833))에 대한 컨택 포인트로서의 역할을 수행할 수 있다. 본 개시에서, TA(1831)는 TA를 위해 정의된 ID(예컨대, UUID)에 의해 식별될 수 있다. 본 개시에서, TA(1831)는 FiRa TA로 지칭될 수도 있다. 상술한 것처럼, RDS는 UWB 레인징 세션을 보안하기 위해 사용되는 키를 나타내는 레인징 세션 키(UWB 레인징 세션 키) 및/또는 RDS(또는, RDS와 연관된 세션)을 식별하는 세션 ID를 포함할 수 있다. 이때, 레인징 세션 키 및 세션 ID는 개시자(initiator) 및 응답자(responder)에서 동일하여야 한다. 또한, RDS는 적어도 하나의 레인징 파라미터(예컨대, AoA (Angle of Arrival), 근접 거리(Proximity Distance)), 클라이언트 특정 데이터 및/또는 멀티캐스트 응답자-특정 키(Multicast responder-specific key)를 옵셔널하게 더 포함할 수 있다.
Secure OS(1832)는 TEE(1830)에 의해 호스팅되는 OS로서, 장치의 나머지(REE)에 의해 호스팅되는 Rich OS(예컨대, 안드로이드)와 구별되는 Trusted OS일 수 있다. TA(1831)와 Secure OS(1832)는 미리 정의된 TEE Core API를 통해 통신할 수 있다. 일반적으로, TA(1831)는 TEE Core API를 이용하여, 명령을 Secure OS(1832)를 통해 외부 장치(peripheral)로 내려주는 방식으로 동작할 수 있다. 본 개시에서, Secure OS(1832)는 driver TA로 지칭될 수 있다.
한편, 도 16 및 17의 실시예와 같이, UWB 장치의 보안 컴포넌트가 eSE인 경우, UWBS가 eSE에 명령을 전달하는 방식을 통해 UWBS와 eSE 간의 통신이 수행된다. 이에 반하여, 도 18의 실시예와 같이, TEE의 경우, 일반적으로 TA는 Secure OS를 통해 외부 장치에 명령을 전달하는 방식을 통해 외부 장치와 통신을 수행한다. 따라서, UWBS를 단지 하나의 외부 장치로 인식하고, 상술한 일반적인 인터페이싱 방식을 통해 TA와 UWBS가 통신하는 경우, eSE 용 UWBS 칩셋과 TEE 용 UWBS 칩셋을 별도로 구현하여야 하는 부담이 발생될 수 있다. 따라서, TA와 UWBS 간의 인터페이싱을 위한 새로운 방식이 고려될 필요가 있다.
이하에서는 각 도면을 참조하여, TEE에 포함된 UWBS와 TA가 서로 통신하는 실시예들에 대하여 예시적으로 설명한다. 이하의 실시예에서는, UWBS가 TA에 저장된 RDS를 획득하기 위해 TA와 통신하는 것을 예로 들어 설명하고 있으나, 이에 한정되지 아니하고, UWBS가 TA에 저장된 다른 종류의 보안 데이터/파라미터를 획득하기 위한 실시예들에 대해서도 이하에서 설명할 내용이 동일 또는 유사하게 적용될 수 있음은 통상의 기술자에게 자명하다.
실시예 1: UWBS가 RDS를 TA로부터 Pull하는 실시예 (예컨대, UWBS가 RDS 전달(획득)을 위한 절차를 개시하는 initiator로 동작하고, TA가 이에 응답하는 responder로 동작하는 실시예)
이하에서는 도 19 내지 21을 참조하여 실시예 1에 대하여 예시적으로 설명한다.
도 19는 본 개시의 일 실시예에 따른 TEE를 포함하는 UWB 장치의 동작을 나타낸다.
도 19의 UWB 장치는 예컨대, 도 18의 UWB 장치일 수 있다.
도 19를 참조하면, UWB 장치(1900)는 TEE(1910) 및 프레임워크(1920)를 포함할 수 있다. 일 실시예에서, TEE(1910)는 TA(1911), Secure OS(Driver TA)(1912) 및/또는 UWBS(1913)를 포함할 수 있다. 도 19의 실시예에서, TEE 영역에 포함된 UWBS(1913)는 TA(또는 Secure OS)(1911)의 관점에서 단순히 하나의 외부 장치(peripheral)의 역할을 수행하기 보다는, RDS 획득 절차를 개시하는 주체로 동작할 수 있다. 예를 들면, UWBS(1913)는 보안 레인징을 위한 RDS 획득(요청) 명령을 전달하는 initiator로 동작할 수 있다. 이 경우, TA(1911)는 UWBS(1913)로부터 전달된 RDS 획득 명령에 응답하여 RDS를 전달하는 responder로 동작할 수 있다. 따라서, 도 19의 실시예에서, TA(1911)는 TEE Core API를 이용하여 RDS를 직접 UWBS(1913)로 push하는 방식으로 동작하지 않는다.
도 19의 실시예의 경우, UWBS(1913)는 보안 레인징을 위한 RDS를 TA(1911)로 요청할 수 있고, TA(1911)는 이 요청에 응답하여 RDS를 UWBS(1913)로 전달할 수 있다. 이 경우, 보안 컴포넌트의 유형과 관계없이, UWBS(1913)의 관점에서는 보안 컴포넌트에 대한 일관된 동작(역할)을 수행하도록 UWBS가 구현될 수 있다. 즉, 보안 컴포넌트가 TEE인지 또는 SE(eSE)인지와 무관하게, RDS 획득을 위한 보안 컴포넌트에 대한 UWBS 동작(역할)을 동일하게 구성할 수 있다. 따라서, 보안 컴포넌트의 구분 없이 설계가 가능하여 UWBS 칩셋의 설계가 용이해질 수 있다.
또한, 도 19의 실시예의 경우, 상술한 것처럼, TA(1911)는 기존에 정의된 TEE Core API를 이용하여 RDS를 push하는 절차를 수행할 수 없다. 따라서, UWBS(1913)와 Secure OS(1912) 사이의 경로를 포함하는, UWBS(1913)와 TA(1911) 사이의 전체 경로에 대한 보안 채널이 설정될 필요가 있다.
또한, 도 19의 실시예의 경우, UWBS(1913)를 위한 하드웨어 인터페이스(예컨대, SPI(Serial Peripheral Interface), I2C(inter-integrated circuit) 등)가 TEE 용 및 REE 용으로 각각 별도로 정의될 수 있다. 이 경우, 필요한 보안 레벨에 따라, 특정 절차(처리)를 TEE 용 인터페이스를 이용하거나, 또는 REE 용 인터페이스를 이용하는 것으로, 유연하게 구성할 수 있다. 예를 들면, 보안 레인징을 위한 RDS 관련 처리는 TEE 용 인터페이스를 통해 수행되고, 예컨대, 일반 레인징을 위한 처리는 REE 용 인터페이스를 통해 수행되도록, 설정될 수 있다.
또한, 도 19의 실시예의 경우, 프레임워크(1920)는 세션 ID를 포함하는 명령을 UWBS(1913)로 전송하는 대신에, 어플리케이션의 어플리케이션 ID 및/또는 인스턴스 ID(랜덤 ID)를 포함하는 명령을 TA(1911) 및/또는 UWBS(1913)로 전송할 수 있다.
여기서, 어플리케이션 ID은 어플리케이션을 식별하기 위한 ID이고, 인스턴스 ID는 어플리케이션 ID에 의해 식별되는 어플리케이션과 연관된 세션 인스턴스를 식별하기 위한 ID(예컨대, 각 세션 별로 할당된 랜덤 값)일 수 있다. 예를 들면, 하나의 어플리케이션(어플리케이션 인스턴스)에 대해 복수의 세션(세션 인스턴스)이 설정되는 경우, 해당 어플리케이션의 각 세션은 어플리케이션 ID 및 인스턴스 ID에 의해 식별될 수 있다. 다른 예를 들면, 하나의 어플리케이션에 대해 하나의 세션만이 설정된 경우, 해당 어플리케이션의 세션은 인스턴스 ID(또는, 어플리케이션 ID)에 의해 식별될 수 있다. 이와 같이, 세션을 식별하기 위해 세션 ID를 사용하는 대신에, 어플리케이션 ID 및/또는 인스턴스 ID를 사용하는 경우, RDS 획득을 위해 세션 ID(보안 파라미터)가 프레임워크(1920)로 노출됨으로써 생기는 보안 문제가 해소될 수 있다. 본 개시에서, 인스턴스 ID는 세션 인스턴스 ID로 지칭될 수 있다.
이러한 도 19의 실시예의 예시적인 동작에 대하여는 도 21를 참조하여 이하에서 설명한다.
도 20은 본 개시의 일 실시예에 따른 TEE 및 SE를 포함하는 UWB 장치의 동작을 나타낸다.
도 20을 참조하면, UWB 장치(2000)는 TEE(2010), SE(예컨대, eSE)(2020) 및 프레임워크(2030)를 포함할 수 있다. 일 실시예에서, TEE(2010)는 TA(2011), Secure OS(2012) 및/또는 UWBS(2013)를 포함할 수 있다.
도 20의 실시예는 보안 컴포넌트로서 TEE(2010)와 SE(2020)가 함께 사용되는 Hybrid 방식의 실시예에 해당한다. 따라서, 각 보안 컴포넌트에 대한 UWBS(2013)의 동작을 효율적으로 구성할 필요가 있다. 즉, 호환성을 높이는 방식으로 구현할 필요가 있다.
도 20의 실시예의 TEE(2010)의 구성 및 동작은 도 19의 실시예의 TEE(1910)의 구성 및 동작을 따를 수 있다. 예를 들면, UWBS(2013)가 TEE 영역 내부에 포함되며, UWBS(2013)를 위한 하드웨어 인터페이스(예컨대, SPI, I2C 등)가 TEE 용 및 REE 용으로 각각 별도로 정의될 수 있다. 또한, UWBS(2013)는 보안 레인징을 위한 RDS를 TA(2011)로 요청하고, TA(2011)는 이 요청에 응답하여 RDS를 UWBS(2013)로 전달할 수 있다. 또한, 프레임워크(2030)는 세션 ID를 포함하는 명령을 UWBS(2013)로 전송하는 대신에, 어플리케이션의 어플리케이션 ID 및/또는 인스턴스 ID(랜덤 ID)를 포함하는 명령을 RDS 획득을 위해 TA(2011) 및/또는 UWBS(2013)로 전송할 수 있다.
도 20의 실시예의 경우, 두 종류의 보안 컴포넌트가 UWB 장치(2000)에 포함되기 때문에, UWB 장치(2000)는 두 개의 동작 모드로 동작할 수 있다. 예를 들면, UWB 장치(2000)는 TEE 모드 또는 SE(eSE) 모드로 동작할 수 있다. 여기서, TEE 모드는 프레임워크(2030)와 UWBS(2013)가 TEE(2011)와 동작하는 모드(즉, 보안 컴포넌트로 TEE(2011)를 이용하는 모드)일 수 있고, SE 모드는 프레임워크(2030)와 UWBS(2013)가 SE(eSE)(2020)와 동작하는 모드(즉, 보안 컴포넌트로 SE(2020)를 이용하는 모드)일 수 있다. 일 실시예에서, TEE 모드에서 UWBS(2013)는 보안 데이터(예컨대, RDS)를 TEE(2010)(예컨대, TEE의 TA(2011))로부터 획득할 수 있고, SE 모드에서 UWBS(2013)는 보안 데이터(예컨대, RDS)를 SE(2020)(예컨대, eSE의 SUS Applet)로부터 획득할 수 있다.
TEE 모드인 경우, 도 19에서 상술한 바와 같이, UWBS(2013)는 RDS 획득을 위한 요청(명령)을 TA(2011)로 전달하고, TA(2011)는 이 요청에 응답하여 RDS를 UWBS(2013)로 전달할 수 있다. 마찬가지로, SE 모드인 경우, UWBS(2013)는 RDS 획득을 위한 요청(명령)을 eSE(2020)의 SUS Applet으로 전달하고, eSE(2020)의 SUS Apple은 이 요청에 응답하여 RDS를 UWBS(2013)로 전달할 수 있다. 이와 같이, 두 모드 모두에서, USBS(2013)는 RDS 획득 절차를 개시하는 initiator로 동작할 수 있다. 즉, UWBS(2013)는 보안 컴포넌트의 종류와 무관하게, RDS 획득을 위해 동일한 역할 및 동작을 수행할 수 있다. 예를 들면, UWBS(2013)는 보안 컴포넌트(TEE(TA) 또는 SE)에 RDS 획득을 위한 동일한 명령들을 전달할 수 있다. 따라서, UWBS 칩 설계가 용이하다는 이점을 갖는다.
한편, UWBS(2013)에 대한 프레임워크(2030)의 명령은 동작 모드에 따라 상이할 수 있다. 예를 들면, TEE 모드인 경우, 프레임워크(2030)는 어플리케이션 ID 및/또는 인스턴스 ID를 포함하는 명령을 UWBS(2013) 및/또는 TA(2011)로 전달할 수 있고, SE 모드인 경우, 프레임워크(2013)는 세션 ID를 포함하는 명령을 UWBS(2013)로 전달할 수 있다.
이와 같이, TEE(2010)와 SE(2020)가 함께 사용되는 Hybrid 방식의 경우, 높은 호환성을 갖는 실시예 1(UWBS가 보안 컴포넌트(TA)로부터 RDS를 pull 하는 실시예)가 칩 설계 측면에서 이점을 갖는다. 이와 같이, Hybrid 케이스에서는, 실시예 1의 방식이 후술할 실시예 2의 방식에 비해 유리할 수 있다.
도 21은 본 개시의 일 실시예에 따른 제1 UWB 장치가 제2 UWB 장치와 보안 레인징을 수행하는 방법을 나타낸다.
도 21의 실시예에서, 제1 UWB 장치(2100a)는 도 18의 UWB 장치일 수 있고, 제2 UWB 장치(2100b)는 제1 UWB 장치(2100a)와 보안 레인징을 수행하는 장치일 수 있다. 도시된 것처럼, 제1 UWB 장치(2100a)는 UWBS(2113a), Secure OS(2112a)와 TA(2111a)를 포함하는 TEE(2110a) 및 프레임워크(2120a)를 포함할 수 있다.
도 21의 실시예에서, 제1 UWB 장치(2100a)는 도 19에서 상술한 방식(실시예 1)에 따라 동작하는 UWB 장치에 해당한다.
도 21을 참조하면, 동작 2101에서, 제2 UWB 장치(2100b)는 제1 UWB 장치(2100a)로 OID(object ID)에 의해 식별되는 오브젝트를 선택하기 위한 SELECT 명령을 제1 UWB 장치(2100a)로 전송할 수 있다. 일 실시예에서, SELECT 명령은 OID를 포함할 수 있다. 일 실시예에서, 어플리케이션은 루트 레벨의 GDF와 적어도 하나의 ADF를 포함하는 데이터 구조를 가질 수 있다. 이 경우, 오브젝트는 어플리케이션에 포함된 적어도 하나의 ADF 중 하나일 수 있다. 일 실시예에서, ADF는 RDS를 생성/저장/전달하는 역할을 수행할 수 있다.
동작 2102에서, 제1 UWB 장치(2100a)의 프레임워크(2120a)는 OID에 의해 식별된 오브젝트와 연관된 어플리케이션(예컨대, OID에 의해 식별된 ADF를 포함하는 어플리케이션)을 식별하고, 어플리케이션의 어플리케이션 ID 및/또는 인스턴스 ID(랜덤 ID)를 TA(2111a)로 전송할 수 있다. 상술한 것처럼, 어플리케이션 ID은 어플리케이션을 식별하기 위한 ID이고, 인스턴스 ID는 어플리케이션 ID에 의해 식별되는 어플리케이션과 연관된 세션 인스턴스를 식별하기 위한 ID(예컨대, 각 세션 별로 할당된 랜덤 값)일 수 있다. 예를 들면, 하나의 어플리케이션(어플리케이션 인스턴스)에 대해 복수의 세션(세션 인스턴스)이 설정되는 경우, 해당 어플리케이션의 각 세션은 어플리케이션 ID 및 인스턴스 ID에 의해 식별될 수 있다. 다른 예를 들면, 하나의 어플리케이션에 대해 하나의 세션만이 설정된 경우, 해당 어플리케이션의 세션은 인스턴스 ID(또는, 어플리케이션 ID)에 의해 식별될 수 있다. 이와 같이, 세션을 식별하기 위해 세션 ID를 사용하는 대신에, 어플리케이션 ID 및/또는 인스턴스 ID를 사용하는 경우, RDS 획득을 위해 세션 ID(보안 파라미터)가 프레임워크로 노출됨으로써 생기는 보안 문제가 해소될 수 있다. 본 개시에서, 인스턴스 ID는 세션 인스턴스 ID로 지칭될 수 있다.
동작 2103에서, 제1 UWB 장치(2100a)와 제2 UWB 장치(2100b)는 보안 채널을 설정할 수 있다. 보안 채널은 제1 UWB 장치(2100a)의 TA(2111a)와 제2 UWB 장치(2100b)의 보안 컴포넌트(예컨대, TA 또는 SUS Applet) 간에 설정될 수 있다. 일 실시예에서, 보안 채널은 BLE와 같은 OOB를 통해 설정될 수 있다. 이 보안 채널을 통해, UWB 파라미터가 교환될 수 있다.
동작 2104에서, TA(2111a)는 교환된 UWB 파라미터에 기초하여, 보안 레인징을 위해 사용되는 RDS를 생성/준비할 수 있다.
동작 2105에서, TA(2111a)는 RDS가 준비되었음을 알리는 notification을 프레임워크(2120a)로 전달할 수 있다.
동작 2106에서, 프레임워크(2120a)는 TA(2111a)로부터 RDS를 가져가라는 PULL 명령을 UWBS(2113a)로 전송할 수 있다. 일 실시예에서, 프레임워크(2120a)는 PULL 명령을 어플리케이션 ID 및/또는 인스턴스 ID와 함께 전송할 수 있다. 예를 들면, 프레임워크(2120a)는 어플리케이션 ID 및/또는 인스턴스 ID를 포함하는 PULL 명령을 전송할 수 있다.
동작 2107에서, UWBS(2113a)는 SELECT 명령을 TA(2111a)로 전송할 수 있고, TA(2111a)는 SELECT 명령에 대응하는 SELECT Response를 UWBS(2113a)로 전송할 수 있다. 일 실시예에서, SELECT 명령은 TA(2111a)의 식별 정보(예컨대, UUID)를 포함할 수 있다. 이를 통해, RDS를 검색할 TA(2111a)가 선택될 수 있다.
동작 2108에서, UWBS(2113a)는 TA(2111a)로부터 랜덤 챌린지(random challenge)를 획득하기 제1 인증 명령(GENERAL AUTHENTICATE(Part 1(1/2): GET RANDOM))을 TA(2111a)로 전송할 수 있고, TA(2111a)는 제1 인증 명령에 대응하는 응답을 UWBS(2113a)로 전송할 수 있다. 또한, 동작 2109에서, 랜덤 챌린지에 응답하여, UWBS(2113a)는 암호화된 챌린지와 함께, TA(2111a)와의 보안 채널을 설정하기 위한 제2 인증 명령(GENERAL AUTHENTICATE(Part 1(2/2): Mutual Authentication))을 TA(2111a)로 전송할 수 있고, TA(2111a)는 제2 인증 명령에 대응하는 응답을 UWBS(2113a)로 전송할 수 있다. 이러한 동작 2108 내지 2109를 통해, UWBS(2113a)와 TA(2111a) 간에 보안 채널이 설정될 수 있다.
동작 2110에서, UWBS(2113a)는 RDS를 획득하기 위한 GET 명령(GET URSK)을 TA(2111a)로 전송할 수 있고, TA(2111a)는 GET 명령에 대응하는 Response를 UWBS(2113a)로 전송할 수 있다. 일 실시예에서, 이 GET 명령은 RDS를 식별하기 위한 세션 ID(UWB 세션 ID)를 포함할 수 있고, 이 Response는 세션 ID에 대응하는 RDS 데이터(예컨대, 레인징 세션 키)를 포함할 수 있다. 이를 통해, UWBS가 RDS 데이터를 획득할 수 있다.
동작 2111에서, UWBS(2113a)는 UWBS(2113a)가 RDS 데이터를 정상적으로 획득하였음을 알려주는 notification(Done)을 프레임워크(2120a)로 전달할 수 있다. 일 실시예에서, 이 notification은 동작 2106의 PULL 명령에 대한 응답으로 전송될 수 있다.
동작 2112에서, UWBS(2113a)는 획득된 RDS 데이터를 이용하여 제2 UWB 장치(2100b)의 UWBS와의 보안 레인징을 수행할 수 있다. 예를 들면, UWBS(2113a)는 RDS의 레인징 세션 키를 이용하여 생성된 STS를 이용하여, 제2 UWB 장치(2100b)의 UWBS와 보안 레인징을 수행할 수 있다.
이와 같이, UWB 장치가 실시예 1에 따라 동작하는 경우, 보안 컴포넌트의 구분 없이 UWBS의 설계가 가능하여 UWBS 칩셋의 설계가 용이해질 수 있다. 다만, TA의 기존 API를 활용하기 어렵고, UWBS와 Secure OA 사이의 경로를 포함하는, UWBS와 TA 사이의 전체 경로에 대한 보안 채널이 설정될 필요가 있다.
상술한 각 동작은 각 구성에서 수행되는 특정 동작을 예시한 것으로, 동작의 순서가 기재된 순서로만 제한되는 것은 아니다. 예를 들면, 기재된 순서와 다른 순서로 각 동작이 수행될 수도 있다.
이하에서는, 호환성 중심으로 한 실시예 1과 다른 관점의 실시예(실시예 2)에 대하여 도 22 내지 23을 참조하여 예시적으로 설명한다. 실시예 2는 예컨대, 효율성 중심으로 한 실시예일 수 있다.
실시예 2: TA가 RDS를 UWBS로 Push 하는 실시예 (예컨대, TA가 RDS 전달(획득)을 위한 절차를 개시하는 initiator로 동작하고, UWBS가 이에 응답하는 responder로 동작하는 실시예)
이하에서는 도 22 내지 23을 참조하여 실시예 2에 대하여 예시적으로 설명한다.
도 22는 본 개시의 다른 실시예에 따른 TEE를 포함하는 UWB 장치의 동작을 나타낸다.
도 22의 UWB 장치는 예컨대, 도 18의 UWB 장치일 수 있다.
도 22를 참조하면, UWB 장치(2200)는 TEE(2210) 및 프레임워크(2220)를 포함할 수 있다. 일 실시예에서, TEE(2210)는 TA(2211), Secure OS(2212) 및/또는 UWBS(2213)를 포함할 수 있다. 도 22의 실시예에서, TEE 영역에 포함된 UWBS(2213)는 TA(2211)(또는 Secure OS(2212))의 관점에서 하나의 외부 장치(peripheral)의 역할을 수행한다. 따라서, 도 19의 실시예와 달리, 도 22의 실시예에서, TA(2211)는 TEE Core API를 이용하여 RDS를 직접 UWBS(2213)로 push하는 방식으로 동작할 수 있다. 즉, UWBS(2213)의 요청과 무관하게, TA(2211)는 RDS를 UWBS(2213)로 전달할 수 있다. 따라서, 구현이 용이하다는 이점을 갖는다. 즉, 실시예 2는 실시예 1 보다 TA의 동작 효율성 측면에서 더 유리하다.
또한, 도 22의 실시예의 경우, TA(2211)와 Secure OA(2212) 간에는 미리 정의된 TEE Core API를 통해 보안된 통신이 수행되기 때문에, RDS 전달을 위해, 전체 경로가 아닌, Secure OA(2212)와 UWBS(2213) 간의 경로에 대한 보안 채널만이 설정되면 된다.
또한, 도 22의 실시예의 경우, UWBS(2213)를 위한 하드웨어 인터페이스(예컨대, SPI, I2C 등)가 TEE 용 및 REE 용으로 각각 별도로 정의될 수 있다. 이 경우, 필요한 보안 레벨에 따라, 특정 절차(처리)를 TEE 용 인터페이스를 이용하거나, 또는 REE 용 인터페이스를 이용하는 것으로, 유연하게 구성할 수 있다. 예를 들면, 보안 레인징을 위한 RDS 관련 처리는 TEE 용 인터페이스를 통해 수행되고, 예컨대, 일반 레인징을 위한 처리는 REE 용 인터페이스를 통해 수행되도록, 설정될 수 있다.
또한, 도 22의 실시예의 경우, 프레임워크는 세션 ID를 포함하는 명령을 UWBS(2213)로 전송하는 대신에, 어플리케이션의 어플리케이션 ID 및/또는 인스턴스 ID(랜덤 ID)를 포함하는 명령을 TA(2211) 및/또는 UWBS(2213)로 전송할 수 있다.
여기서, 어플리케이션 ID은 어플리케이션을 식별하기 위한 ID이고, 인스턴스 ID는 어플리케이션 ID에 의해 식별되는 어플리케이션과 연관된 세션 인스턴스를 식별하기 위한 ID(예컨대, 어플리케이션의 각 세션 별로 할당된 랜덤 값)일 수 있다. 예를 들면, 하나의 어플리케이션(어플리케이션 인스턴스)에 대해 복수의 세션(세션 인스턴스)이 설정되는 경우, 해당 어플리케이션의 각 세션은 어플리케이션 ID 및 인스턴스 ID에 의해 식별될 수 있다. 다른 예를 들면, 하나의 어플리케이션에 대해 하나의 세션만이 설정된 경우, 해당 어플리케이션의 세션은 인스턴스 ID(또는, 어플리케이션 ID)에 의해 식별될 수 있다. 이와 같이, 세션을 식별하기 위해 세션 ID를 사용하는 대신에, 어플리케이션 ID 및/또는 인스턴스 ID를 사용하는 경우, RDS 획득을 위해 세션 ID(보안 파라미터)가 프레임워크로 노출됨으로써 생기는 보안 문제가 해소될 수 있다. 본 개시에서, 인스턴스 ID는 세션 인스턴스 ID로 지칭될 수 있다.
다만, 도 22의 실시예(실시예 2)의 경우, TEE(2210)와 함께 SE(eSE)가 사용되는 경우, TEE(2210)에 대한 UWBS(2213)의 동작과 SE에 대한 UWBS(2213)의 동작을 별도로 구현하여야 하기 때문에, 도 19에 실시예(실시예 1)에 비해, 칩 설계 측면에서 용이하지 않다. 따라서, 실시예 2는 보안 컴포넌트로서 TEE만을 사용하는 케이스에서 더 유리할 수 있다.
이러한 도 22의 실시예의 예시적인 동작에 대하여는 도 23을 참조하여 이하에서 설명한다.
도 23은 본 개시의 다른 실시예에 따른 제1 UWB 장치가 제2 UWB 장치와 보안 레인징을 수행하는 방법을 나타낸다.
도 23의 실시예에서, 제1 UWB 장치(2300a)는 도 18의 UWB 장치일 수 있고, 제2 UWB 장치(2300b)는 제1 UWB 장치(2300a)와 보안 레인징을 수행하는 장치일 수 있다. 도시된 것처럼, 제1 UWB 장치(2300a)는 UWBS(2313a), Secure OS(2312a)와 TA(2311a)를 포함하는 TEE(2310a) 및 프레임워크(2320a)를 포함할 수 있다.
도 23의 실시예에서, 제1 UWB 장치(2300a)는 도 22에서 상술한 방식(실시예 2)에 따라 동작하는 UWB 장치에 해당한다.
도 23을 참조하면, 동작 2301에서, 제2 UWB 장치(2300b)는 제1 UWB 장치(2300a)로 OID(object ID)에 식별되는 오브젝트를 선택하기 위한 SELECT 명령을 전송할 수 있다. 일 실시예에서, SELECT 명령은 OID를 포함할 수 있다. 일 실시예에서, 어플리케이션은 루트 레벨의 GDF와 적어도 하나의 ADF를 포함하는 데이터 구조를 가질 수 있다. 이 경우, 오브젝트는 적어도 하나의 ADF 중 하나일 수 있다. 일 실시예에서, ADF는 RDS를 생성/저장/전달하는 역할을 수행할 수 있다.
동작 2302에서, 제1 UWB 장치(2300a)의 프레임워크(2320a)는 OID에 의해 식별된 오브젝트와 연관된 어플리케이션(예컨대, OID에 의해 식별된 ADF를 포함하는 어플리케이션)을 식별하고, 어플리케이션의 ID 및/또는 인스턴스 ID(랜덤 ID)를 TA(2311a)로 전송할 수 있다.
여기서, 어플리케이션 ID은 어플리케이션을 식별하기 위한 ID이고, 인스턴스 ID는 어플리케이션 ID에 의해 식별되는 어플리케이션과 연관된 세션 인스턴스를 식별하기 위한 ID(예컨대, 각 세션 별로 할당된 랜덤 값)일 수 있다. 예를 들면, 하나의 어플리케이션(어플리케이션 인스턴스)에 대해 복수의 세션(세션 인스턴스)이 설정되는 경우, 해당 어플리케이션의 각 세션은 어플리케이션 ID 및 인스턴스 ID에 의해 식별될 수 있다. 다른 예를 들면, 하나의 어플리케이션에 대해 하나의 세션만이 설정된 경우, 해당 어플리케이션의 세션은 인스턴스 ID(또는, 어플리케이션 ID)에 의해 식별될 수 있다. 이와 같이, 세션을 식별하기 위해 세션 ID를 사용하는 대신에, 어플리케이션 ID 및/또는 인스턴스 ID를 사용하는 경우, RDS 획득을 위해 세션 ID(보안 파라미터)가 프레임워크로 노출됨으로써 생기는 보안 문제가 해소될 수 있다. 본 개시에서, 인스턴스 ID는 세션 인스턴스 ID로 지칭될 수 있다.
동작 2203에서, 제1 UWB 장치(2300a)와 제2 UWB 장치(2300b)는 보안 채널을 설정할 수 있다. 보안 채널은 제1 UWB 장치(2300a)의 TA(2311a)와 제2 UWB 장치(2300b)의 보안 컴포넌트(예컨대, TA 또는 SUS Applet) 간에 설정될 수 있다. 일 실시예에서, 보안 채널은 BLE와 같은 OOB를 통해 설정될 수 있다. 이 보안 채널을 통해, UWB 파라미터가 교환될 수 있다.
동작 2304에서, TA(2311a)는 교환된 UWB 파라미터에 기초하여, 보안 레인징을 위해 사용되는 RDS를 생성할 수 있다.
동작 2305에서, TA(2311a)는 RDS가 준비되었음을 알리는 notification을 프레임워크(2320a)로 전달할 수 있다.
동작 2306에서, 프레임워크(2320a)는 UWBS로 RDS를 보내라는 PUSH 명령(즉, TA가 UWBS로 RDS를 push 하라는 PUSH 명령)을 TA(2311a)로 전송할 수 있다. 일 실시예에서, 프레임워크(2320a)는 PUSH 명령을 어플리케이션 ID 및 인스턴스 ID와 함께 전송할 수 있다. 예를 들면, 프레임워크(2320a)는 어플리케이션 ID 및 인스턴스 ID를 포함하는 PUSH 명령을 전송할 수 있다.
동작 2307에서, TA(2311a)는 Secure OS(2312a)와 UWBS(2313a) 간의 보안 채널을 설정하기 위한 요청을 Secure OS(Driver TA)(2312a)로 전송할 수 있다. TEE(2310a)에서 TA(2311a)와 Secure OS(2312a) 간에는 보안된 상태이므로, TA(2311a)에서 생성된 RDS를 안전하게 UWBS(2313a)로 전달하기 위해서는 Secure OS(2312a)와 UWBS(2313a) 간의 보안 채널이 설정될 필요가 있다. 이하에서는 동작 2308 내지 2312를 통해 Secure OS(2312a)와 UWBS(2313a) 간의 보안 채널 설정 절차에 대하여 설명한다.
동작 2308에서, Secure OS(2312a)는 랜덤 값(p)를 생성하고, 생성된 랜덤 값(p)를 UWBS(2313a)로 전송할 수 있다. 동작 2309에서, UWBS(2313a)는 랜덤 값(p)에 기초하여 세션 키(K)(예컨대, 메시지의 보안을 위한 세션 키)를 생성할 수 있다. 예를 들면, UWBS(2313a)는 수신된 랜덤 값(p) 및/또는 UWBS(2313a)가 생성한 랜덤 값(q)에 기초하여 세션 키(K)를 생성할 수 있다. 또한, UWBS(2313a)는 세션 키(K)에 기초하여 암호화된 데이터(cryptogram)를 생성할 수 있다.
동작 2310에서, UWBS(2313a)는 생성된 cryptogram 및/또는 랜덤 값(q)를 Secure OS(2312a)로 전송할 수 있다. 동작 2311에서, Secure OS(2312a)는 랜덤 값(q)에 기초하여 세션 키(K)를 생성할 수 있다. 예를 들면, Secure OS(2312a)는 수신된 랜덤 값(q) 및/또는 Secure OS(2312a)가 생성한 랜덤 값(p)에 기초하여 세션 키(K)를 생성할 수 있다. 또한, Secure OS(2312a)는 세션 키(K)에 기초하여 암호화된 데이터(cryptogram)를 생성할 수 있다.
동작 2312에서, Secure OS(2312a)는 생성된 cryptogram을 UWBS(2313a)로 전송할 수 있다. 이를 통해, 동일한 세션 키(K)가 Secure OS(2312a)와 UWBS(2313a) 사이에 공유될 수 있고, 이후 동작은 이 세션 키(K)를 이용하여 보호될 수 있다. 이러한 동작 2308 내지 2312을 통해, UWBS(2313a)와 Secure OS(2312a) 간에 보안 채널이 설정될 수 있다.
동작 2313에서, Secure OS(2312a)는 UWBS(2313a)와 Secure OS(2312a) 간에 보안 채널이 설정되었음을 알리는 notification(OK) 또는 UWBS(2313a)와 Secure OS(2312a) 간에 보안 채널이 설정되지 않음을 알리는 notification(NOK)를 TA(2311a)로 전송할 수 있다. 일 실시예에서, 이 notification은 동작 2307의 요청에 대한 응답으로 전송될 수 있다.
동작 2314에서, UWBS(2313a)와 Secure OS(2312a) 간의 보안 채널이 설정된 경우, TA(2311a)는 보안 채널을 통해 RDS를 UWBS(2313a)로 전달할 수 있다. 예를 들면, TA(2311a)는 세션 키(K)를 이용하여 Secure OS(2312a)를 통해 RDS를 UWBS(2313a)로 전달할 수 있다. 예컨대, TA(2311a)는 세션 키(K)를 이용하여 RDS를 암호화하여 UWBS(2313a)로 전달할 수 있다.
동작 2315에서, UWBS(2313a)는 획득된 RDS 데이터를 이용하여 제2 UWB 장치(2300b)의 UWBS와의 보안 레인징을 수행할 수 있다. 예를 들면, UWBS(2313a)는 RDS의 레인징 세션 키를 이용하여 생성된 STS를 이용하여, 제2 UWB 장치(2300b)의 UWBS와 보안 레인징을 수행할 수 있다.
상술한 각 동작은 각 구성에서 수행되는 특정 동작을 예시한 것으로, 동작의 순서가 기재된 순서로만 제한되는 것은 아니다. 예를 들면, 기재된 순서와 다른 순서로 각 동작이 수행될 수도 있다.
도 24는 본 개시의 일 실시예에 따른 UWB 장치의 구성을 나타낸다.
도 24의 UWB 장치는 도 18의 UWB 장치의 일 예일 수 있다.
도 24를 참조하면, UWB 장치(2400)는 TEE(2410), 프레임워크(2420) 및 적어도 하나의 어플리케이션(UWB-enabled Application)(2430)을 포함할 수 있다. 적어도 하나의 어플리케이션(2430)은 TEE 외부에 위치하며, TEE 내부의 어플리케이션인 TA(2411)와 구별될 수 있다. 이러한 TEE 외부의 어플리케이션(2430)은 TA(2411)에 비해 낮은 보안성을 가진다. 본 개시에서, 프레임워크(2420)는 FiRa 프레임워크로, 어플리케이션(2430)은 FiRa 어플리케이션으로, TA(2411)는 FiRa TA로 지칭될 수도 있다.
일 실시예에서, TEE(2410)는 적어도 하나의 TA(2411), Secure OS(Driver TA)(2412) 및/또는 UWBS(2413)를 포함할 수 있다. TA(2411)와 Secure OS(2412)는 TEE core API를 통해 통신할 수 있고, TA(2411)와 TEE 외부의 다른 컴포넌트(예컨대, 어플리케이션(2430))는 TEE Client API를 통해 통신할 수 있다.
일 실시예에서, TA(2411)는 적어도 하나의 ADF를 포함할 수 있다. ADF는 OID에 의해 식별될 수 있다. 예를 들면, 도시된 것처럼, TA(2411)는 OID#1에 의해 식별되는 ADF 및 OID#2에 의해 식별되는 ADF를 포함할 수 있다. 이 경우, 각 ADF는 해당 어플리케이션의 어플리케이션 인증서(AppCert), 어플리케이션 ID(AppID), 인스턴스 ID 및/또는 보안 채널 키 파라미터(SC Key Parameter)(예컨대, 보안 채널 키 ID)를 포함할 수 있다.
일 실시예에서, 프레임워크(2420)는 각 ADF에 저장된 어플리케이션 인증서(AppCert), 어플리케이션 ID(AppID), 인스턴스 ID 및/또는 보안 채널 키 파라미터(SC Key Parameter)(예컨대, 보안 채널 키 ID) 중 적어도 하나를 포함할 수 있다. 이를 통해, 프레임워크(2420)는 외부 UWB 장치로부터 전달된 메시지를 식별하고, 이를 특정 TA(2411)에 연결하는 역할을 수행할 수 있다. 예를 들면, 외부 UWB 장치에서 특정 OID가 호출되는 경우, 프레임워크(2420)는 이를 식별하고 OID와 연관된 어플리케이션의 APP ID 및/또는 인스턴스 ID를 TA(2411)로 전달함으로써, TA(2411)가 해당 어플리케이션의 세션을 식별하게 할 수 있다. 이 경우, TA(2411)는 미리 설정된 방식에 따라, UWBS(2413)의 요청에 응답하여 해당 세션과 연관된 RDS를 UWBS(2413)로 전달하거나, UWBS(2413)의 요청과 무관하게 해당 세션과 연관된 RDS를 UWBS(2413)로 push할 수 있다.
도 25는 본 개시의 일 실시예에 따른 UWB 장치의 방법을 나타내는 흐름도이다.
도 25의 실시예에서, UWB 장치는 도 18의 UWB 장치 또는 도 24의 UWB 장치일 수 있다. 도 25의 UWB 장치의 동작은 도 19 내지 21을 참조하여 설명한 실시예 1에 따른 동작일 수 있다.
도 25를 참조하면, UWB 서브시스템은, 보안 레인징을 위한 레인징 데이터 세트(RDS)를 보안 어플리케이션(TA)으로부터 가져오라는 명령(PULL 명령)을 프레임워크로부터 수신할 수 있다(2510).
UWB 서브시스템은 명령에 기초하여 보안 어플리케이션과의 보안 채널을 설정할 수 있다(2520). UWB 서브시스템과 보안 어플리케이션 간의 보안 채널 설정 절차는 도 21의 설명을 참조할 수 있다.
UWB 서브시스템은 보안 어플리케이션으로부터 설정된 보안 채널을 통해 RDS를 수신할 수 있다(2530). 일 실시예에서, 보안 어플리케이션은 UWB 서브시스템의 요청에 응답하여 RDS를 전달할 수 있다. RDS 전달 절차는 도 9의 설명을 참조할 수 있다.
일 실시예에서, UWB 서브시스템 및 보안 어플리케이션은 TEE 영역 내에 포함되며, RDS는 UWB 레인징 세션을 보안하기 위해 사용되는 레인징 세션 키를 포함할 수 있다.
일 실시예에서, PULL 명령은 어플리케이션의 어플리케이션 ID 또는 어플리케이션에 의해 설정된 적어도 하나의 세션 중 하나와 연관된 인스턴스 ID 중 적어도 하나를 포함할 수 있다.
일 실시예에서, TEE 영역 내의 컴포넌트와 통신하기 위한 제1 인터페이스 및 TEE 영역 외의 컴포넌트와 통신하기 위한 제2 인터페이스가 UWB 서브시스템을 위해 구성될 수 있다.
일 실시예에서, 프레임워크는 TEE 영역 외에 포함될 수 있다.
일 실시예에서, UWB 서브시스템은 RDS에 포함된 레인징 세션 키를 이용하여 다른 UWB 장치의 UWB 서브시스템과의 보안 레인징을 수행할 수 있다.
도 26은 본 개시의 다른 실시예에 따른 UWB 장치의 방법을 나타내는 흐름도이다.
도 26의 실시예에서, UWB 장치는 도 18의 UWB 장치 또는 도 24의 UWB 장치일 수 있다. 도 26의 UWB 장치의 동작은 도 19 내지 21을 참조하여 설명한 실시예 1에 따른 동작일 수 있다.
도 26을 참조하면, 보안 어플리케이션(TA)는 보안 레인징을 위한 레인징 데이터 세트(RDS)를 UWB 서브시스템으로 전달하라는 명령을 프레임워크로부터 수신할 수 있다(2610)
보안 어플리케이션은 명령에 기초하여 보안 어플리케이션의 보안 OS와 UWB 서브시스템 사이의 보안 채널을 설정하기 위한 요청을 보안 OS로 전송할 수 있다(2620). 보안 OS와 UWB 서브시스템 사이의 보안 채널 설정 절차는 도 23의 설명을 참조할 수 있다.
보안 어플리케이션은 설정된 보안 채널을 통해 RDS를 UWB 서브시스템으로 전달할 수 있다(2630).
도 27는 본 개시의 일 실시예에 따른 전자 장치의 구조를 도시한 도면이다.
도 27의 실시예에서, 전자 장치는 도 18의 UWB 장치에 해당하거나, 도 18의 UWB 장치를 포함하는 전자 장치, 또는 도 18의 UWB 장치의 일부 구성에 포함되는 전자 장치일 수 있다.
도 27을 참고하면, 전자 장치는 송수신부 (2710), 제어부 (2720), 저장부 (2730)을 포함할 수 있다. 본 개시에서 제어부는, 회로 또는 어플리케이션 특정 통합 회로 또는 적어도 하나의 프로세서라고 정의될 수 있다.
송수신부 (2710)는 다른 엔티티와 신호를 송수신할 수 있다. 송수신부(2710)는 예컨대, UWB 레인징을 위한 데이터를 송수신할 수 있다.
제어부 (2720)은 본 개시에서 제안하는 실시예에 따른 전자 장치의 전반적인 동작을 제어할 수 있다. 예를 들어, 제어부 (2720)는 상기에서 기술한 순서도에 따른 동작을 수행하도록 각 블록 간 신호 흐름을 제어할 수 있다. 구체적으로, 제어부(2720)는, 예컨대, 도 13 내지 26을 참조하여 설명한 전자 장치의 동작을 제어할 수 있다.
저장부(2730)는 상기 송수신부 (2710)를 통해 송수신되는 정보 및 제어부 (2720)을 통해 생성되는 정보 중 적어도 하나를 저장할 수 있다. 예를 들어, 저장부 (2730)는 예컨대, 도 13 내지 26을 참조하여 설명한 보안 레인징을 위해 필요한 정보 및 데이터를 저장할 수 있다.상술한 본 개시의 구체적인 실시 예들에서, 본 개시에 포함되는 구성 요소는 제시된 구체적인 실시 예에 따라 단수 또는 복수로 표현되었다. 그러나, 단수 또는 복수의 표현은 설명의 편의를 위해 제시한 상황에 적합하게 선택된 것으로서, 본 개시가 단수 또는 복수의 구성 요소에 제한되는 것은 아니며, 복수로 표현된 구성 요소라 하더라도 단수로 구성되거나, 단수로 표현된 구성 요소라 하더라도 복수로 구성될 수 있다.
한편 본 개시의 상세한 설명에서는 구체적인 실시 예에 관해 설명하였으나, 본 개시의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 개시의 범위는 설명된 실시 예에 국한되어 정해져서는 아니 되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.
Claims (15)
- 보안 레인징(secure ranging)을 수행하는 전자 장치의 방법에 있어서,상기 보안 레인징을 위한 레인징 데이터 세트를 설정하기 위한 요청을 보안 컴포넌트로 전송하는 동작; 및상기 레인징 데이터 세트를 UWB 서브시스템으로 전달하기 위한 요청을 상기 보안 컴포넌트로 전송하는 동작을 포함하며,상기 레인징 데이터 세트는 상기 보안 컴포넌트와 상기 UWB 서브시스템 사이에 설정된 보안 채널을 이용하여 상기 보안 컴포넌트로부터 상기 UWB 서브시스템으로 전달되는, 방법.
- 제1항에 있어서,상기 레인징 데이터 세트를 설정하기 위한 요청을 전송하는 동작은:상기 보안 컴포넌트가 상기 레인징 데이터 세트를 설정하도록 요청하는 프레임워크 API를 호출하는 동작을 포함하며, 상기 프레임워크 API는 상기 프레임워크 API를 호출한 어플리케이션을 식별하기 위한 어플리케이션 ID를 포함하는, 방법.
- 제1항에 있어서,상기 레인징 데이터 세트를 UWB 서브시스템으로 전달하기 위한 요청을 전송하는 동작은:상기 보안 컴포넌트가 상기 레인징 데이터 세트를 상기 UWB 서브시스템으로 전달하도록 요청하는 프레임워크 API를 호출하는 동작을 포함하며, 상기 프레임워크 API는 상기 프레임워크 API를 호출한 어플리케이션을 식별하기 위한 어플리케이션 ID를 포함하는, 방법.
- 제1항에 있어서,상기 레인징 데이터 세트를 UWB 서브시스템으로 전달하기 위한 요청을 전송하는 동작은:어플리케이션이 상기 보안 컴포넌트로 상기 레인징 데이터 세트를 획득하기 위한 명령을 상기 UWB 서브시스템으로 전달하는 동작을 포함하는, 방법.
- 제1항에 있어서,상기 레인징 데이터 세트는 상기 보안 레인징과 연관된 UWB 세션을 세션 ID 정보, 및 상기 UWB 세션을 보호하기 위한 세션 키 정보 중 적어도 하나를 포함하는, 방법.
- 제1항에 있어서,프레임워크가, 상기 UWB 서브시스템으로 상기 보안 레인징을 시작하는 명령을 전송하는 동작을 더 포함하고,상기 보안 레인징을 시작하는 명령은 상기 보안 레인징과 연관된 어플리케이션을 식별하기 위한 어플리케이션 ID를 포함하는, 방법.
- 제1항에 있어서,상기 보안 컴포넌트와 상기 UWB 서브시스템 사이의 상기 보안 채널은 Asymmetric key 기반 보안 채널인, 방법.
- 제1항에 있어서,상기 보안 컴포넌트는 TEE(Trusted Execution Environment) 또는 스트롱박스(Strongbox)인, 방법.
- 보안 레인징을 수행하는 전자 장치에 있어서,메모리; 및상기 메모리에 연결된 프로세서를 포함하며, 상기 프로세서는:상기 보안 레인징을 위한 레인징 데이터 세트를 설정하기 위한 요청을 보안 컴포넌트로 전송하고,상기 레인징 데이터 세트를 UWB 서브시스템으로 전달하기 위한 요청을 상기 보안 컴포넌트로 전송하도록 구성되며,상기 레인징 데이터 세트는 상기 프레임워크를 통해 상기 보안 컴포넌트와 상기 UWB 서브시스템 사이에 설정된 보안 채널을 이용하여 상기 보안 컴포넌트로부터 상기 UWB 서브시스템으로 전달되는, 전자 장치.
- 제9항에 있어서,상기 레인징 데이터 세트를 설정하기 위한 요청을 전송하는 동작은:상기 보안 컴포넌트가 상기 레인징 데이터 세트를 설정하도록 요청하는 프레임워크 API를 호출하는 동작을 포함하며, 상기 프레임워크 API는 상기 프레임워크 API를 호출한 어플리케이션을 식별하기 위한 어플리케이션 ID를 포함하는, 전자 장치.
- 제9항에 있어서,상기 레인징 데이터 세트를 UWB 서브시스템으로 전달하기 위한 요청을 전송하는 동작은:상기 보안 컴포넌트가 상기 레인징 데이터 세트를 상기 UWB 서브시스템으로 전달하도록 요청하는 프레임워크 API를 호출하는 동작을 포함하며, 상기 프레임워크 API는 상기 프레임워크 API를 호출한 어플리케이션을 식별하기 위한 어플리케이션 ID를 포함하는, 전자 장치.
- 제9항에 있어서,상기 레인징 데이터 세트는 상기 보안 레인징과 연관된 UWB 세션을 세션 ID 정보, 및 상기 UWB 세션을 보호하기 위한 세션 키 정보 중 적어도 하나를 포함하는, 전자 장치.
- 제9항에 있어서,상기 프로세서는, 상기 UWB 서브시스템으로 상기 보안 레인징을 시작하는 명령을 전송하도록 더 구성되며,상기 보안 레인징을 시작하는 명령은 상기 보안 레인징과 연관된 어플리케이션을 식별하기 위한 어플리케이션 ID를 포함하는, 전자 장치.
- 제9항에 있어서,상기 보안 컴포넌트와 상기 UWB 서브시스템 사이의 상기 보안 채널은 Asymmetric key 기반 보안 채널인, 전자 장치.
- 제9항에 있어서,상기 보안 컴포넌트는 TEE(Trusted Execution Environment) 또는 Strongbox인, 전자 장치.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP22739838.5A EP4274285A1 (en) | 2021-01-18 | 2022-01-18 | Method and device for secure ranging based on ultra-wideband communication |
| CN202280010513.3A CN116724578A (zh) | 2021-01-18 | 2022-01-18 | 用于基于超宽带通信的安全测距的方法和设备 |
Applications Claiming Priority (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR10-2021-0006864 | 2021-01-18 | ||
| KR20210006864 | 2021-01-18 | ||
| KR10-2021-0064354 | 2021-05-18 | ||
| KR20210064354 | 2021-05-18 | ||
| KR1020220006809A KR20220104652A (ko) | 2021-01-18 | 2022-01-17 | Uwb 기반 보안 레인징을 위한 방법 및 장치 |
| KR10-2022-0006809 | 2022-01-17 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2022154646A1 true WO2022154646A1 (ko) | 2022-07-21 |
Family
ID=82447459
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/KR2022/000934 WO2022154646A1 (ko) | 2021-01-18 | 2022-01-18 | 초광대역통신 기반 보안 레인징을 위한 방법 및 장치 |
Country Status (2)
| Country | Link |
|---|---|
| EP (1) | EP4274285A1 (ko) |
| WO (1) | WO2022154646A1 (ko) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090143104A1 (en) * | 2007-09-21 | 2009-06-04 | Michael Loh | Wireless smart card and integrated personal area network, near field communication and contactless payment system |
| US20190013937A1 (en) * | 2017-07-05 | 2019-01-10 | Nxp B.V. | Communication devices and associated method |
| EP3503044A1 (en) * | 2017-12-21 | 2019-06-26 | Gemalto Sa | Method of getting access to a vehicle |
| US20200228331A1 (en) * | 2019-01-10 | 2020-07-16 | Nxp B.V. | Key derivation scheme for data frame transmission in ultra-wide band ranging in keyless entry systems |
| US20200336303A1 (en) * | 2017-09-28 | 2020-10-22 | Apple Inc. | Methods and architectures for secure ranging |
-
2022
- 2022-01-18 WO PCT/KR2022/000934 patent/WO2022154646A1/ko active Application Filing
- 2022-01-18 EP EP22739838.5A patent/EP4274285A1/en active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090143104A1 (en) * | 2007-09-21 | 2009-06-04 | Michael Loh | Wireless smart card and integrated personal area network, near field communication and contactless payment system |
| US20190013937A1 (en) * | 2017-07-05 | 2019-01-10 | Nxp B.V. | Communication devices and associated method |
| US20200336303A1 (en) * | 2017-09-28 | 2020-10-22 | Apple Inc. | Methods and architectures for secure ranging |
| EP3503044A1 (en) * | 2017-12-21 | 2019-06-26 | Gemalto Sa | Method of getting access to a vehicle |
| US20200228331A1 (en) * | 2019-01-10 | 2020-07-16 | Nxp B.V. | Key derivation scheme for data frame transmission in ultra-wide band ranging in keyless entry systems |
Also Published As
| Publication number | Publication date |
|---|---|
| EP4274285A1 (en) | 2023-11-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2017039320A1 (ko) | 통신 시스템에서 프로파일 다운로드 방법 및 장치 | |
| WO2016178548A1 (ko) | 프로파일 제공 방법 및 장치 | |
| WO2015061992A1 (zh) | 一种密钥配置方法、系统和装置 | |
| WO2016167551A1 (ko) | 통신 시스템에서 프로파일을 관리하는 기법 | |
| WO2019050325A1 (en) | METHOD AND APPARATUS FOR SUPPORTING PROFILE TRANSFER BETWEEN DEVICES IN A WIRELESS COMMUNICATION SYSTEM | |
| WO2015061941A1 (zh) | 一种密钥配置方法和装置 | |
| WO2016163796A1 (en) | Method and apparatus for downloading a profile in a wireless communication system | |
| WO2010093200A2 (en) | Method and apparatus for traffic count key management and key count management | |
| WO2015027485A1 (zh) | 远程变更签约方法及其装置 | |
| WO2019107977A1 (en) | Method and electronic device for providing communication service | |
| WO2020171672A1 (en) | Method for interoperating between bundle download process and esim profile download process by ssp terminal | |
| WO2020197221A1 (ko) | 통신 방법 및 통신 디바이스 | |
| WO2020080909A1 (en) | Method and apparatus for handling remote profile management exception | |
| WO2018066925A1 (ko) | 블루투스 기술을 이용하여 데이터를 송수신하기 위한 방법 및 장치 | |
| WO2019107876A1 (en) | Method and apparatus for managing event in communication system | |
| WO2019216739A1 (en) | Security protection method and apparatus in wireless communication system | |
| WO2022045789A1 (en) | Method and apparatus for recovering profile in case of device change failure | |
| EP3854115A1 (en) | Method and apparatus for handling remote profile management exception | |
| WO2020105892A1 (ko) | 디바이스가 디지털 키를 공유하는 방법 | |
| WO2016048054A2 (ko) | 데이터 통신 보안을 위한 방법, 장치 및 시스템 | |
| WO2022154646A1 (ko) | 초광대역통신 기반 보안 레인징을 위한 방법 및 장치 | |
| WO2022092918A1 (ko) | 초광대역 통신을 이용한 결제 방법 및 장치 | |
| WO2018080201A1 (ko) | 블루투스 기술을 이용하여 디바이스를 인증하기 위한 방법 및 장치 | |
| WO2022173245A2 (ko) | 초광대역통신을 이용한 결제 방법 및 장치 | |
| WO2020167045A1 (ko) | Euicc 프로파일 설치 권한을 관리하는 방법 및 장치 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 22739838 Country of ref document: EP Kind code of ref document: A1 |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 202280010513.3 Country of ref document: CN |
|
| ENP | Entry into the national phase |
Ref document number: 2022739838 Country of ref document: EP Effective date: 20230802 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |