KR20180086118A - 통신 시스템에서 보안 정보 제공 및 관리 장치 및 방법 - Google Patents

통신 시스템에서 보안 정보 제공 및 관리 장치 및 방법 Download PDF

Info

Publication number
KR20180086118A
KR20180086118A KR1020170119878A KR20170119878A KR20180086118A KR 20180086118 A KR20180086118 A KR 20180086118A KR 1020170119878 A KR1020170119878 A KR 1020170119878A KR 20170119878 A KR20170119878 A KR 20170119878A KR 20180086118 A KR20180086118 A KR 20180086118A
Authority
KR
South Korea
Prior art keywords
information
service provider
key
auxiliary device
mobile
Prior art date
Application number
KR1020170119878A
Other languages
English (en)
Inventor
정수연
신인영
원은태
이국희
이종효
Original Assignee
삼성전자주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자주식회사 filed Critical 삼성전자주식회사
Priority to PCT/KR2018/000962 priority Critical patent/WO2018135919A1/en
Priority to CN201880007940.XA priority patent/CN110235424B/zh
Priority to KR1020197021952A priority patent/KR102460122B1/ko
Priority to EP18741656.5A priority patent/EP3520363B1/en
Priority to US15/877,020 priority patent/US10805287B2/en
Publication of KR20180086118A publication Critical patent/KR20180086118A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/107—Network architectures or network communication protocols for network security for controlling access to devices or network resources wherein the security policies are location-dependent, e.g. entities privileges depend on current location or allowing specific operations only from locally connected terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • 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/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/52—Network services specially adapted for the location of the user terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 개시는 센서 네트워크(sensor network), 사물 통신(machine to machine (M2M) communication), MTC(machine type communication) 및 사물 인터넷(internet of things: IoT)을 위한 기술과 관련된 것이다. 본 개시는 통신 시스템에서 제1 디바이스의 방법에 있어서, 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하기를 요청함을 검출하는 과정과; 서비스 제공자로 상기 제2 디바이스의 정보를 등록하는 과정과; 상기 서비스 제공자로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 인증 정보를 수신하는 과정과; 상기 제2 디바이스로 상기 인증 정보를 송신하는 과정을 포함함을 특징으로 한다.

Description

통신 시스템에서 보안 정보 제공 및 관리 장치 및 방법{APPARATUS AND METHOD FOR PROVIDING AND MANAGING SECURITY INFORMAITON IN COMMUNICNATION SYSTEM}
본 개시는 통신 시스템에서 보안 정보를 제공 및 관리하는 장치 및 방법에 관한 것이다.
인터넷은 인간이 정보를 생성하고 소비하는 인간 중심의 연결 네트워크에서, 사물 등 분산된 구성 요소들 간에 정보를 주고 받아 처리하는 사물 인터넷(internet of things: IoT, 이하 " IoT"라 칭하기로 한다) 네트워크로 진화하고 있다. IoE (internet of everything) 기술은 클라우드 서버(cloud server) 등과의 연결을 통한 빅 데이터(big data) 처리 기술 등이 IoT 기술에 결합된 하나의 예가 될 수 있다.
IoT를 구현하기 위해서, 센싱 기술, 유무선 통신 및 네트워크 인프라, 서비스 인터페이스 기술 및 보안 기술 등과 같은 기술 요소 들이 요구되어, 최근에는 사물간의 연결을 위한 센서 네트워크(sensor network), 사물 통신 (machine to machine (M2M) communication: 이하 " M2M 통신"이라 칭하기로 한다), MTC(machine type communication) 등의 기술이 연구되고 있다.
IoT 환경에서는 연결된 사물들에서 생성된 데이터를 수집, 분석하여 인간의 삶에 새로운 가치를 창출하는 지능형 IT (internet technology) 서비스가 제공될 수 있다. IoT는 기존의 IT 기술과 다양한 산업 간의 융합 및 복합을 통하여 스마트 홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 스마트 그리드, 헬스 케어, 스마트 가전, 첨단 의료 서비스 등의 분야에 응용될 수 있다.
먼저, 자동차 업계에서는 다양한 형태의 키 기술들을 개발해왔으며, 그 개발된 키 기술들을 사용하여 운전자들에게 편의를 제공해오고 있다.
먼저, 기계식 키를 사용하여 차량 문을 열고 시동을 거는 "턴키 스타터(turn-key starter)" 기술이 개발되고, 이후 기계식 키를 사용하지 않고도 차량 문을 여닫을 수 있고, 시동도 걸 수 있는 "버튼식 무선 키(remote keyless entry)" 기술이 개발되었다. 이런, 버튼식 무선 키 기술은 이모빌라이저(immobilizer) 기술과 결합되고, 이모빌라이저 기술을 사용함에 따라 키와 차량 간의 고유 암호가 일치될 경우에만 시동이 걸릴 수 있다.
또한, 최근에는 패시브 스타트 앤 엔트리(passive start and entry: PASE, 이하 "PASE"라 칭하기로 한다) 기술이 개발된 바 있으며, 상기 PASE 기술이 적용된 키가 스마트 키이다. 상기 스마트키는 운전자가 키를 가방에서 꺼낸 후 키의 버튼을 눌러야만 하는 기존 버튼식 무선 키와 달리 운전자가 키를 가방에서 꺼내지 않고도 차량 문을 열 수 있고, 운전자가 시동을 걸기 위해 키를 돌리는 대신 버튼을 누르면 바로 시동이 걸릴 수 있다. 상기 스마트 키는 운전석 근처에 허가된 키가 없으면 시동이 걸리지 않고 스티어링 휠도 움직이지 않아 차량 도난을 방지할 수 있는 키 기술이며, 다양한 형태로 진화되고 있다.
한편, 키는 무선 통신 기술, 일 예로 근거리 무선 통신(near field communication: NFC) 기술과 같은 무선 통신 기술을 사용하여 이동 단말기, 일 예로 스마트 폰에 통합되는 형태로 개발되고 있다. 즉, 디지털화된 가상 키, 즉 디지털 키가 스마트 폰에 삽입되고, 이렇게 디지컬 키가 스마트 폰에 삽입됨에 따라 운전자는 키를 가지고 다닐 필요가 없게 된다.
상기에서 설명한 바와 같이 자동차 업계에서는, 기계식 키에서 리모콘 키로, 리모콘 키에서 스마트 키로, 스마트 키에서 디지털 키의 형태로 키 기술이 발전하고 있다. 따라서, 차량과 스마트 폰의 결합으로 키를 소유한다는 개념이 사라지게 될 것이다.
그리고 디지털 키의 등장은 카셰어링 서비스 확대에도 큰 역할을 하고 있을 뿐만 아니라, NFC 기술 발전에 따른 카셰어링 시장 확대는 향후 자율 주행차 시대와 맞물려 더 이상 차를 소유하는 것이 아닌 공유하는 개념으로 업계에 변화를 미칠 것으로 전망된다.
이와 같이 디지털 키의 사용은 사용자 편의 및 산업적 효과에 있어 큰 개선을 가져오는 것은 사실이지만, 그 보안에 대한 우려가 제기되고 있는 것도 사실이다. 즉, 디지털 키는 기본적으로 이동 단말기와의 결합을 필요로 하므로, 해킹등과 같은 악의적인 사용에 노출될 수 있으며, 따라서 신뢰성 있는 디지털 키를 제공 및 사용하는 방안에 대한 필요성이 대두되고 있다.
또한, 디지털 키를 제공하는 키 서버, 일 예로 서비스 제공자는 디지털 키를 소유하는 소유자(owner, 이하 "owner"라 칭하기로 한다) 디바이스, 일 예로 차량 소유자의 스마트 디바이스에게 디지털 키를 제공한다. 여기서, 상기 owner 디바이스 이외의 다른 디바이스, 일 예로 클라이언트(client, 이하 "client"라 칭하기로 한다) 디바이스가 상기 owner디바이스의 디지털 키를 공유하고자 할 경우 상기 client 디바이스는 상기 키 서버에 계정을 등록하고, 디지털 키 서비스에 가입한 후 상기 키 서버로 디지털 키를 제공해 줄 것을 요청한다.
이 경우 상기 키 서버는 상기 client 디바이스에 대해 계정을 별도로 관리해야만 한다.
또한, 상기 client 디바이스는 상기 owner디바이스의 디지털 키를 공유하기 위해 상기 키 서버에 계정을 등록하는 프로세스와, 상기 디지털 키 서비스에 가입하는 프로세스와, 상기 키 서버로 디지털 키의 제공을 요청하는 프로세스와, 상기 키 서버로부터 디지털 키를 수신하는 프로세스와 같은 다수의 프로세스들을 포함하는, 디지털 키 획득 절차를 수행해야만 한다.
따라서, 키 서버가 관리하는 계정들의 개수를 감소시키면서도 클라이언트 디바이스가 신뢰성 있는 방식으로 owner 디바이스와 디지털 키를 공유하는 방안에 대한 필요성이 대두되고 있다.
한편, 상기와 같은 정보는 본 개시의 이해를 돕기 위한 백그라운드(background) 정보로서만 제시될 뿐이다. 상기 내용 중 어느 것이라도 본 개시에 관한 종래 기술로서 적용 가능할지 여부에 관해, 어떤 결정도 이루어지지 않았고, 또한 어떤 주장도 이루어지지 않는다.
본 개시의 일 실시예는 통신 시스템에서 보안 정보를 제공 및 관리하는 장치 및 방법을 제안한다.
또한, 본 개시의 일 실시예는 통신 시스템에서 보안 정보를 공유하는 장치 및 방법을 제안한다.
또한, 본 개시의 일 실시예는 통신 시스템에서 보안 정보를 공유하는 디바이스들에 대한 인증을 강화하는 장치 및 방법을 제안한다.
또한, 본 개시의 일 실시예는 통신 시스템에서 서버에 계정을 등록하지 않고도 보안 정보를 획득하는 장치 및 방법을 제안한다.
또한, 본 개시의 일 실시예는 통신 시스템에서 보안 정보의 신뢰성을 향상시키는 장치 및 방법을 제안한다.
본 개시의 일 실시예에서 제안하는 방법은; 통신 시스템에서 제1 디바이스의 방법에 있어서, 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하기를 요청함을 검출하는 과정과; 서비스 제공자로 상기 제2 디바이스의 정보를 등록하는 과정과; 상기 서비스 제공자로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 인증 정보를 수신하는 과정과; 상기 제2 디바이스로 상기 인증 정보를 송신하는 과정을 포함함을 특징으로 한다.
본 개시의 일 실시예에서 제시하는 다른 방법은; 통신 시스템에서 제1디바이스의 방법에 있어서, 서비스 제공자로 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는 서비스를 신청하는 과정과; 상기 서비스 제공자로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제1 인증 정보를 수신하는 과정과; 상기 제1 인증 정보와 상기 제1 디바이스의 보안 정보를 기반으로 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제2 인증 정보를 생성하는 과정과; 상기 제2 인증 정보를 상기 제2 디바이스로 송신하는 과정을 포함함을 특징으로 한다.
본 개시의 일 실시예에서 제시하는 또 다른 방법은; 통신 시스템에서 제2 디바이스의 방법에 있어서, 제1 디바이스로 상기 제1 디바이스의 보안 정보를 공유하기를 요청하는 과정과; 상기 제1 디바이스로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 인증 정보를 수신하는 과정과; 상기 인증 정보를 기반으로 서비스 제공자와 인증 동작을 수행하는 과정과; 상기 서비스 제공자로부터 상기 제1 디바이스의 보안 정보를 수신하는 과정을 포함함을 특징으로 한다.
본 개시의 일 실시예에서 제시하는 또 다른 방법은; 통신 시스템에서 제2디바이스의 방법에 있어서, 제1 디바이스와 커넥션(connection)을 셋업하는 과정과; 상기 제1 디바이스로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제1 인증 정보와 상기 제1 디바이스의 보안 정보를 기반으로 생성된, 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제2 인증 정보를 수신하는 과정과; 서비스 제공자로 상기 제1 디바이스의 보안 정보를 공유하기를 요청하는 과정과; 상기 서비스 제공자로부터 상기 제1 디바이스의 보안 정보를 수신하는 과정을 포함함을 특징으로 한다.
본 개시의 일 실시예에서 제시하는 또 다른 방법은; 통신 시스템에서 서비스 제공자의 방법에 있어서, 제1 디바이스로부터 제2 디바이스의 정보를 수신하고, 상기 제2 디바이스의 정보를 등록하는 과정과; 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 인증 정보를 생성하는 과정과; 상기 인증 정보를 상기 제1 디바이스로 송신하는 과정과; 상기 인증 정보를 기반으로 상기 제2 디바이스와 인증 동작을 수행하는 과정과; 상기 제2 디바이스로 상기 제1 디바이스의 보안 정보를 송신하는 과정을 포함함을 특징으로 한다.
본 개시의 일 실시예에서 제시하는 또 다른 방법은; 통신 시스템에서 서비스 제공자의 방법에 있어서, 제1 디바이스가 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는 서비스를 신청함을 검출하는 과정과; 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제1 인증 정보를 생성하는 과정과; 상기 제1 인증 정보를 상기 제1 디바이스로 송신하는 과정과; 상기 제2 디바이스로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하기를 요청함을 검출하는 과정과; 상기 제1 디바이스의 보안 정보를 상기 제2 디바이스로 송신하는 과정을 포함함을 특징으로 한다.
본 개시의 일 실시예에서 제시하는 장치는; 통신 시스템에서 제1 디바이스에 있어서, 신호를 송신 혹은 수신하는 송수신기와; 상기 송수신기에 연결되고, 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하기를 요청함을 검출하고, 서비스 제공자로 상기 제2 디바이스의 정보를 등록하고, 상기 서비스 제공자로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 인증 정보를 수신하고, 상기 제2 디바이스로 상기 인증 정보를 송신하는 적어도 하나의 프로세서를 포함함을 특징으로 한다.
본 개시의 일 실시예에서 제시하는 다른 장치는; 통신 시스템에서 제1디바이스에 있어서, 신호를 송신 혹은 수신하는 송수신기와; 상기 송수신기에 연결되고, 서비스 제공자로 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는 서비스를 신청하고, 상기 서비스 제공자로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제1 인증 정보를 수신하고, 상기 제1 인증 정보와 상기 제1 디바이스의 보안 정보를 기반으로 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제2 인증 정보를 생성하고, 상기 제2 인증 정보를 상기 제2 디바이스로 송신하는 적어도 하나의 프로세서를 포함함을 특징으로 한다.
본 개시의 일 실시예에서 제시하는 또 다른 장치는; 통신 시스템에서 제2 디바이스에 있어서, 신호를 송신 혹은 수신하는 송수신기와; 상기 송수신기에 연결되고, 제1 디바이스로 상기 제1 디바이스의 보안 정보를 공유하기를 요청하고, 상기 제1 디바이스로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 인증 정보를 수신하고, 상기 인증 정보를 기반으로 서비스 제공자와 인증 동작을 수행하고, 상기 서비스 제공자로부터 상기 제1 디바이스의 보안 정보를 수신함을 특징으로 한다.
본 개시의 일 실시예에서 제시하는 또 다른 장치는; 통신 시스템에서 제2디바이스에 있어서, 신호를 송신 혹은 수신하는 송수신기와; 상기 송수신기에 연결되고, 제1 디바이스와 커넥션(connection)을 셋업하고, 상기 제1 디바이스로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제1 인증 정보와 상기 제1 디바이스의 보안 정보를 기반으로 생성된, 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제2 인증 정보를 수신하고, 서비스 제공자로 상기 제1 디바이스의 보안 정보를 공유하기를 요청하고, 상기 서비스 제공자로부터 상기 제1 디바이스의 보안 정보를 수신하는 적어도 하나의 프로세서를 포함함을 특징으로 한다.
본 개시의 일 실시예에서 제시하는 또 다른 장치는; 통신 시스템에서 서비스 제공자에 있어서, 신호를 송신 혹은 수신하는 송수신기와; 상기 송수신기에 연결되고, 제1 디바이스로부터 제2 디바이스의 정보를 수신하고, 상기 제2 디바이스의 정보를 등록하고, 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 인증 정보를 생성하고, 상기 인증 정보를 상기 제1 디바이스로 송신하고, 상기 인증 정보를 기반으로 상기 제2 디바이스와 인증 동작을 수행하고, 상기 제2 디바이스로 상기 제1 디바이스의 보안 정보를 송신하는 적어도 하나의 프로세서를 포함함을 특징으로 한다.
본 개시의 일 실시예에서 제시하는 또 다른 장치는; 통신 시스템에서 서비스 제공자에 있어서, 신호를 송신 혹은 수신하는 송수신기와; 상기 송수신기에 연결되고, 제1 디바이스가 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는 서비스를 신청함을 검출하고, 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제1 인증 정보를 생성하고, 상기 제1 인증 정보를 상기 제1 디바이스로 송신하고, 상기 제2 디바이스로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하기를 요청함을 검출하고, 상기 제1 디바이스의 보안 정보를 상기 제2 디바이스로 송신하는 적어도 하나의 프로세서를 포함함을 특징으로 한다.
본 개시의 다른 측면들과, 이득들 및 핵심적인 특징들은 부가 도면들과 함께 처리되고, 본 개시의 바람직한 실시예들을 개시하는, 하기의 구체적인 설명으로부터 해당 기술 분야의 당업자에게 자명할 것이다.
하기의 본 개시의 구체적인 설명 부분을 처리하기 전에, 이 특허 문서를 통해 사용되는 특정 단어들 및 구문들에 대한 정의들을 설정하는 것이 효과적일 수 있다: 상기 용어들 "포함하다(include)" 및 "포함하다(comprise)"와 그 파생어들은 한정없는 포함을 의미하며; 상기 용어 "혹은(or)"은 포괄적이고, "및/또는"을 의미하고; 상기 구문들 "~와 연관되는(associated with)" 및 "~와 연관되는(associated therewith)"과 그 파생어들은 포함하고(include), ~내에 포함되고(be included within), ~와 서로 연결되고(interconnect with), 포함하고(contain), ~내에 포함되고(be contained within), ~에 연결하거나 혹은 ~와 연결하고(connect to or with), ~에 연결하거나 혹은 ~와 연결하고(couple to or with), ~와 통신 가능하고(be communicable with), ~와 협조하고(cooperate with), 인터리빙하고(interleave), 병치하고(juxtapose), ~로 가장 근접하고(be proximate to), ~로 ~할 가능성이 크거나 혹은 ~와 ~할 가능성이 크고(be bound to or with), 가지고(have), 소유하고(have a property of) 등과 같은 내용을 의미하고; 상기 용어 "제어기"는 적어도 하나의 동작을 제어하는 임의의 디바이스, 시스템, 혹은 그 부분을 의미하고, 상기와 같은 디바이스는 하드웨어, 펌웨어 혹은 소프트웨어, 혹은 상기 하드웨어, 펌웨어 혹은 소프트웨어 중 적어도 2개의 몇몇 조합에서 구현될 수 있다. 어떤 특정 제어기와 연관되는 기능성이라도 집중화되거나 혹은 분산될 수 있으며, 국부적이거나 원격적일 수도 있다는 것에 주의해야만 할 것이다. 특정 단어들 및 구문들에 대한 정의들은 이 특허 문서에 걸쳐 제공되고, 해당 기술 분야의 당업자는 많은 경우, 대부분의 경우가 아니라고 해도, 상기와 같은 정의들이 종래 뿐만 아니라 상기와 같이 정의된 단어들 및 구문들의 미래의 사용들에도 적용된다는 것을 이해해야만 할 것이다.
본 개시의 일 실시예는 통신 시스템에서 보안 정보를 제공 및 관리하는 것을 가능하게 한다는 효과가 있다.
또한, 본 개시의 일 실시예는 통신 시스템에서 보안 정보를 공유하는 것을 가능하게 한다는 효과가 있다.
또한, 본 개시의 일 실시예는 통신 시스템에서 보안 정보를 공유하는 디바이스들에 대한 인증을 강화하는 것을 가능하게 한다는 효과가 있다.
또한, 본 개시의 일 실시예는 통신 시스템에서 서버에 계정을 등록하지 않고도 보안 정보를 획득하는 것을 가능하게 한다는 효과가 있다.
또한, 본 개시의 일 실시예는 통신 시스템에서 보안 정보의 신뢰성을 향상시키는 것을 가능하게 한다는 효과가 있다.
본 개시의 특정한 바람직한 실시예들의 상기에서 설명한 바와 같은 또한 다른 측면들과, 특징들 및 이득들은 첨부 도면들과 함께 처리되는 하기의 설명으로부터 보다 명백하게 될 것이다:
도 1은 본 개시의 일 실시예에 따른 통신 시스템의 내부 구조를 개략적으로 도시한 도면이다;
도 2은 본 개시의 일 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다;
도 3은 본 개시의 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다;
도 4는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다;
도 5는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다;
도 6a 내지 도 6b는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다;
도 7은 본 개시의 일 실시예에 따른 통신 시스템에서 기본 디바이스의 동작 과정의 일 예를 개략적으로 도시한 도면이다;
도 8은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다;
도 9a 내지 도 9b는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다;
도 10a 내지 도 10b는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다;
도 11은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다;
도 12는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 보조 디바이스의 위치를 검증하는 과정의 일 예를 개략적으로 도시한 도면이다;
도 13은 본 개시의 일 실시예에 따른 통신 시스템에서 기본 디바이스의 동작 과정의 다른 예를 개략적으로 도시한 도면이다;
도 14는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다;
도 15는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 보조 디바이스를 검증하는 과정의 일 예를 개략적으로 도시한 도면이다;
도 16a 내지 도 16b는 도 15의 보조 디바이스를 검증하는 과정에 따른 신호 송/수신 과정을 개략적으로 도시한 도면이다;
도 17은 본 개시의 일 실시예에 따른 통신 시스템에서 기본 디바이스와 보조 디바이스간의 연결 과정의 일 예를 개략적으로 도시한 도면이다;
도 18은 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 일 예를 개략적으로 도시한 도면이다;
도 19는 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 다른 예를 개략적으로 도시한 도면이다;
도 20a 내지 도 20b는 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 또 다른 예를 개략적으로 도시한 도면이다;
도 21은 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 또 다른 예를 개략적으로 도시한 도면이다;
도 22는 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 인증하는 과정의 일 예를 개략적으로 도시한 도면이다;
도 23은 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 인증하는 과정의 다른 예를 개략적으로 도시한 도면이다;
도 24는 본 개시의 일 실시예에 따른 통신 시스템에서 디지털 키를 발급하는 과정의 일 예를 개략적으로 도시한 도면이다;
도 25a 내지 도 25b는 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스의 정보를 획득하는 과정의 일 예를 개략적으로 도시한 도면이다;
도 26a 내지 도 26b는 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스의 정보를 획득하는 과정의 다른 예를 개략적으로 도시한 도면이다;
도 27은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다;
도 28은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다;
도 29a 내지 도 29b는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 일 예를 개략적으로 도시한 도면이다;
도 30a 내지 도 30b는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 검증 과정의 일 예를 개략적으로 도시한 도면이다;
도 31은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키 공유 서비스를 위한 프로토콜 스택의 구조를 개략적으로 도시한 도면이다;
도 32는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 기본 디바이스의 동작 과정의 일 예를 개략적으로 도시한 도면이다;
도 33a 내지 도 33b는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 다른 예를 개략적으로 도시한 도면이다;
도 34a 내지 도 34b는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 또 다른 예를 개략적으로 도시한 도면이다;
도 35는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다;
도 36은 도 35의 디지털 키 제공 과정에 따른 보조 디바이스와, 기본 디바이스 및 서비스 제공자 간의 신호 송/수신 동작을 개략적으로 도시한 도면이다;
도 37은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다;
도 38은 도 37의 디지털 키 제공 과정에 따른 보조 디바이스와, 기본 디바이스 및 서비스 제공자 간의 신호 송/수신 동작을 개략적으로 도시한 도면이다;
도 39는 본 개시의 일 실시예에 따른 통신 시스템에서 Attribute 의 포맷을 개략적으로 도시한 도면이다;
도 40은 본 개시의 일 실시예에 따른 통신 시스템에서 GATT Profile Stack의 구조를 개략적으로 도시한 도면이다;
도 41a 내지 도 41b는 본 발명의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 또 다른 예를 개략적으로 도시한 도면이다;
도 42a 내지 도 42b는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 검증 과정의 또 다른 예를 개략적으로 도시한 도면이다;
도 43은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 또 다른 예를 개략적으로 도시한 도면이다;
도 44는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 기본 디바이스의 동작 과정의 또 다른 예를 개략적으로 도시한 도면이다;
도 45는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 사용자 어플리케이션을 검증하는 과정의 일 예를 개략적으로 도시한 도면이다;
도 46은 도 45의 사용자 어플리케이션을 검증하는 과정에 따른 신호 송/수신 동작을 개략적으로 도시한 도면이다;
도 47은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 또 다른 예를 개략적으로 도시한 도면이다;
도 48은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 TEE의 구조를 개략적으로 도시한 도면이다;
도 49는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 TEE에서 사용자 정보를 생성하는 과정을 개략적으로 도시한 도면이다;
도 50은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 소유자 디바이스에서 TEE를 사용하여 보증 동작을 수행하는 과정을 개략적으로 도시한 도면이다;
도 51은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 TA에 저장된 디지털 키 공유 서비스 보증을 위한 키를 사용하여 서명 동작을 수행하는 과정을 개략적으로 도시한 도면이다.
상기 도면들을 통해, 유사 참조 번호들은 동일한 혹은 유사한 엘리먼트들과, 특징들 및 구조들을 도시하기 위해 사용된다는 것에 유의해야만 한다.
첨부되는 도면들을 참조하는 하기의 상세한 설명은 청구항들 및 청구항들의 균등들로 정의되는 본 개시의 다양한 실시예들을 포괄적으로 이해하는데 있어 도움을 줄 것이다. 하기의 상세한 설명은 그 이해를 위해 다양한 특정 구체 사항들을 포함하지만, 이는 단순히 예로서만 간주될 것이다. 따라서, 해당 기술 분야의 당업자는 여기에서 설명되는 다양한 실시예들의 다양한 변경들 및 수정들이 본 개시의 범위 및 사상으로부터 벗어남이 없이 이루어질 수 있다는 것을 인식할 것이다. 또한, 공지의 기능들 및 구성들에 대한 설명은 명료성 및 간결성을 위해 생략될 수 있다.
하기의 상세한 설명 및 청구항들에서 사용되는 용어들 및 단어들은 문헌적 의미로 한정되는 것이 아니라, 단순히 발명자에 의한 본 개시의 명료하고 일관적인 이해를 가능하게 하도록 하기 위해 사용될 뿐이다. 따라서, 해당 기술 분야의 당업자들에게는 본 개시의 다양한 실시예들에 대한 하기의 상세한 설명은 단지 예시 목적만을 위해 제공되는 것이며, 첨부되는 청구항들 및 상기 청구항들의 균등들에 의해 정의되는 본 개시를 한정하기 위해 제공되는 것은 아니라는 것이 명백해야만 할 것이다.
또한, 본 명세서에서 명백하게 다른 내용을 지시하지 않는 "한"과, "상기"와 같은 단수 표현들은 복수 표현들을 포함한다는 것이 이해될 수 있을 것이다. 따라서, 일 예로, "컴포넌트 표면(component surface)"은 하나 혹은 그 이상의 컴포넌트 표현들을 포함한다.
또한, 제1, 제2 등과 같이 서수를 포함하는 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되지는 않는다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 개시의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.
또한, 본 명세서에서 사용한 용어는 단지 특정한 실시 예를 설명하기 위해 사용된 것으로, 본 개시를 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 명세서에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
또한, 별도로 다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가지는 것으로 이해되어야만 한다.
본 개시의 다양한 실시예들에 따르면, 전자 디바이스는 통신 기능을 포함할 수 있다. 일 예로, 전자 디바이스는 스마트 폰(smart phone)과, 태블릿(tablet) 개인용 컴퓨터(personal computer: PC, 이하 'PC'라 칭하기로 한다)와, 이동 전화기와, 화상 전화기와, 전자책 리더(e-book reader)와, 데스크 탑(desktop) PC와, 랩탑(laptop) PC와, 넷북(netbook) PC와, 개인용 복합 단말기(personal digital assistant: PDA, 이하 'PDA'라 칭하기로 한다)와, 휴대용 멀티미디어 플레이어(portable multimedia player: PMP, 이하 'PMP'라 칭하기로 한다)와, 엠피3 플레이어(mp3 player)와, 이동 의료 디바이스와, 카메라와, 웨어러블 디바이스(wearable device)(일 예로, 헤드-마운티드 디바이스(head-mounted device: HMD, 일 예로 'HMD'라 칭하기로 한다)와, 전자 의류와, 전자 팔찌와, 전자 목걸이와, 전자 앱세서리(appcessory)와, 전자 문신, 혹은 스마트 워치(smart watch) 등이 될 수 있다.
본 개시의 다양한 실시예들에 따르면, 전자 디바이스는 통신 기능을 가지는 스마트 가정용 기기(smart home appliance)가 될 수 있다. 일 예로, 상기 스마트 가정용 기기는 텔레비젼과, 디지털 비디오 디스크(digital video disk: DVD, 이하 'DVD'라 칭하기로 한다) 플레이어와, 오디오와, 냉장고와, 에어 컨디셔너와, 진공 청소기와, 오븐과, 마이크로웨이브 오븐과, 워셔와, 드라이어와, 공기 청정기와, 셋-탑 박스(set-top box)와, TV 박스 (일 예로, Samsung HomeSyncTM, Apple TVTM, 혹은 Google TVTM)와, 게임 콘솔(gaming console)과, 전자 사전과, 캠코더와, 전자 사진 프레임 등이 될 수 있다.
본 개시의 다양한 실시예들에 따르면, 전자 디바이스는 의료 기기(일 예로, 자기 공명 혈관 조영술(magnetic resonance angiography: MRA, 이하 'MRA'라 칭하기로 한다) 디바이스와, 자기 공명 화상법(magnetic resonance imaging: MRI, 이하 "MRI"라 칭하기로 한다)과, 컴퓨터 단층 촬영(computed tomography: CT, 이하 'CT'라 칭하기로 한다) 디바이스와, 촬상 디바이스, 혹은 초음파 디바이스)와, 네비게이션(navigation) 디바이스와, 전세계 위치 시스템(global positioning system: GPS, 이하 'GPS'라 칭하기로 한다) 수신기와, 사고 기록 장치(event data recorder: EDR, 이하 'EDR'이라 칭하기로 한다)와, 비행 기록 장치(flight data recorder: FDR, 이하 'FER'이라 칭하기로 한다)와, 자동차 인포테인먼트 디바이스(automotive infotainment device)와, 항해 전자 디바이스(일 예로, 항해 네비게이션 디바이스, 자이로스코프(gyroscope), 혹은 나침반)와, 항공 전자 디바이스와, 보안 디바이스와, 산업용 혹은 소비자용 로봇(robot) 등이 될 수 있다.
본 개시의 다양한 실시예들에 따르면, 전자 디바이스는 통신 기능을 포함하는, 가구와, 빌딩/구조의 일부와, 전자 보드와, 전자 서명 수신 디바이스와, 프로젝터와, 다양한 측정 디바이스들(일 예로, 물과, 전기와, 가스 혹은 전자기 파 측정 디바이스들) 등이 될 수 있다.
본 개시의 다양한 실시예들에 따르면, 전자 디바이스는 상기에서 설명한 바와 같은 디바이스들의 조합이 될 수 있다. 또한, 본 개시의 바람직한 실시예들에 따른 전자 디바이스는 상기에서 설명한 바와 같은 디바이스에 한정되는 것이 아니라는 것은 당업자에게 자명할 것이다.
본 개시의 일 실시예는 통신 시스템에서 보안 정보를 제공 및 관리하는 장치 및 방법을 제안한다.
또한, 본 개시의 일 실시예는 통신 시스템에서 보안 정보를 공유하는 장치 및 방법을 제안한다.
또한, 본 개시의 일 실시예는 통신 시스템에서 보안 정보를 공유하는 디바이스들에 대한 인증을 강화하는 장치 및 방법을 제안한다.
또한, 본 개시의 일 실시예는 통신 시스템에서 서버에 계정을 등록하지 않고도 보안 정보를 획득하는 장치 및 방법을 제안한다.
또한, 본 개시의 일 실시예는 통신 시스템에서 보안 정보의 신뢰성을 향상시키는 장치 및 방법을 제안한다.
한편, 본 개시의 일 실시예에서 제안하는 장치 및 방법은 롱 텀 에볼루션 (long-term evolution: LTE, 이하 "LTE"라 칭하기로 한다) 이동 통신 시스템과, 롱 텀 에볼루션-어드밴스드 (long-term evolution-advanced: LTE-A, 이하 "LTE-A"라 칭하기로 한다) 이동 통신 시스템과, 인가-보조 억세스(licensed-assisted access: LAA, 이하 "LAA"라 칭하기로 한다)-LTE 이동 통신 시스템과, 고속 하향 링크 패킷 접속(high speed downlink packet access: HSDPA, 이하 "HSDPA"라 칭하기로 한다) 이동 통신 시스템과, 고속 상향 링크 패킷 접속(high speed uplink packet access: HSUPA, 이하 "HSUPA"라 칭하기로 한다) 이동 통신 시스템과, 3세대 프로젝트 파트너쉽 2(3rd generation partnership project 2: 3GPP2, 이하 "3GPP2"라 칭하기로 한다)의 고속 레이트 패킷 데이터(high rate packet data: HRPD, 이하 "HRPD"라 칭하기로 한다) 이동 통신 시스템과, 3GPP2의 광대역 코드 분할 다중 접속(wideband code division multiple access: WCDMA, 이하 "WCDMA"라 칭하기로 한다) 이동 통신 시스템과, 3GPP2의 코드 분할 다중 접속(code division multiple access: CDMA, 이하 "CDMA"라 칭하기로 한다) 이동 통신 시스템과, 국제 전기 전자 기술자 협회(institute of electrical and electronics engineers: IEEE, 이하 "IEEE"라 칭하기로 한다) 802.16m 통신 시스템과, IEEE 802.16e 통신 시스템과, 진화된 패킷 시스템(evolved packet system: EPS, 이하 "EPS"라 칭하기로 한다)과, 모바일 인터넷 프로토콜(mobile internet protocol: Mobile IP, 이하 "Mobile IP"라 칭하기로 한다) 시스템과, 디지털 멀티미디어 방송(digital multimedia broadcasting, 이하 "DMB"라 칭하기로 한다) 서비스와, 휴대용 디지털 비디오 방송(digital video broadcasting-handheld: DVP-H, 이하 "DVP-H"라 칭하기로 한다), 및 모바일/휴대용 진화된 텔레비젼 시스템 협회(advanced television systems committee-mobile/handheld: ATSC-M/H, 이하 "ATSC-M/H"라 칭하기로 한다) 서비스 등과 같은 모바일 방송 서비스와, 인터넷 프로토콜 텔레비젼(internet protocol television: IPTV, 이하 "IPTV"라 칭하기로 한다) 서비스와 같은 디지털 비디오 방송 시스템과, 엠펙 미디어 트랜스포트(moving picture experts group (MPEG) media transport: MMT, 이하 "MMT"라 칭하기로 한다) 시스템 등과 같은 다양한 통신 시스템들에 적용 가능하다.
본 개시의 다양한 실시예들에서는 보안 정보가 일 예로 디지털 키(digital key) 및 상기 디지털 키에 관련된 정보, 일 예로 억세스 속성(access property) 정보를 포함한다고 가정하기로 한다. 하지만, 상기 보안 정보는 상기 디지털 키 및 디지털 키에 관련된 정보 뿐만 아니라 다른 정보를 포함할 수도 있음은 물론이다.
또한, 본 개시의 다양한 실시예들에서는 보안 정보를 송신 혹은 수신하는 장치가 일 예로 스마트 디바이스(smart device), 혹은 차량, 혹은 키 서버라고 가정하기로 한다. 하지만, 상기 스마트 디바이스, 혹은 차량, 혹은 키 서버 이외의 다른 디바이스들도 상기 보안 정보를 송신 혹은 수신할 수 있음은 물론이다.
또한, 본 개시의 다양한 실시예들에서는 보안 정보를 송신 혹은 수신하는 장치가 일 예로 상기 보안 정보가 적용되는 타겟 디바이스, 일 예로 차량을 사용하는 것이 이미 인증되어 있는 기본(primary) 디바이스, 일 예로 차량 소유자의 디바이스, 일 예로 소유자(owner, 이하 "owner"라 칭하기로 한다) 디바이스가 될 수 있다. 상기 기본 디바이스는 상기 보안 정보를 제공 및 관리하는 서버에 의해 이미 인증된 디바이스를 나타내며, 상기 기본 디바이스는 상기 서버에 의해 이미 인증되어 있기 때문에 상기 타겟 디바이스에 대한 보안 정보를 이미 획득한 상태이다. 또한, 상기 보안 정보는 보안 정보를 제공 및 관리하는 서버로부터 획득된다. 또한, 상기 기본 디바이스는 상기 서버에 이미 등록되어 있기 때문에 상기 기본 디바이스에 대한 정보 역시 상기 서버에 이미 등록되어 있다.
또한, 본 개시의 다양한 실시예들에서는 보안 정보를 송신 혹은 수신하는 장치가 일 예로 보조(secondary) 디바이스라고 가정하기로 한다. 상기 보조 디바이스는 상기 서버에 의해 인증되지 않은 디바이스를 나타내며, 상기 기본 디바이스를 통해 상기 서버에 등록 및 인증되고, 상기 기본 디바이스와 보안 정보를 공유하는 디바이스를 나타낸다. 본 개시의 다양한 실시예들에서 상기 보조 디바이스는 "클라이언트(client, 이하 "client"라 칭하기로 한다) 디바이스" 등과 같은 용어와 혼용될 수 있다.
본 개시의 다양한 실시예들에서, 기본 디바이스 및 보조 디바이스는 스마트 디바이스가 될 수 있다.
본 개시의 다양한 실시예들에서, 상기 스마트 디바이스는 이동 단말기(mobile station: MS, 이하 "MS"라 칭하기로 한다)가 될 수 있다. 또한, 본 개시의 다양한 실시예들에서, MS는 사용자 단말기(user equipment: UE)와, 단말기와, 디바이스와, 무선 디바이스와, 이동 디바이스, 이동 전화기 등과 같은 용어들과 혼용될 수 있다.
먼저, 도 1을 참조하여 본 개시의 일 실시예에 따른 통신 시스템의 내부 구조에 대해서 설명하기로 한다.
도 1은 본 개시의 일 실시예에 따른 통신 시스템의 내부 구조를 개략적으로 도시한 도면이다.
도 1을 참조하면, 먼저 상기 통신 시스템은 신뢰 서비스 관리자(trusted service manager: TSM, 이하 "TSM"이라 칭하기로 한다)(110)와 스마트 디바이스(120)를 포함한다. 상기 스마트 디바이스(120)는 이동 사용자 인터페이스(user interface: UI, 이하 "UI"라 칭하기로 한다) 유닛(130)과, 삽입 보안 엘리먼트(embedded secure element: eSE, 이하 "eSE"라 칭하기로 한다)(140)를 포함한다.
상기 TSM(110)은 보안 정보, 일 예로 디지털 키 및 상기 디지털 키에 관련된 정보를 관리하는 엔터티(entity)이다. 상기 TSM(110)은 스마트 디바이스들, 일 예로 스마트 디바이스들에 포함되어 있는 보안 엘리먼트, 일 예로 eSE에 대한 억세스를 허락함으로써 서비스 제공자(service provider)(100)가 상기 서비스 제공자(100)의 컨택트리스 어플리케이션(contactless application)을 원격으로 분배 및 관리하는 것을 가능하게 한다. 본 개시의 다양한 실시예들에서, 서비스 제공자는 "서버" 혹은 "OEM"이라는 용어와도 혼용될 수 있다.
이와는 달리, 상기 서비스 제공자, 즉 서버(100)가 보안 정보를 관리할 수도 있으며, 스마트 디바이스들, 일 예로 스마트 디바이스들에 포함되어 있는 보안 엘리먼트, 일 예로 eSE에 대한 억세스를 허락함으로써 컨택트리스 어플리케이션을 원격으로 분배 및 관리한다. 본 개시의 다양한 실시예들에서는, 상기 서버(100)가 보안 정보를 제공 및 관리한다고 가정하기로 한다.
또한, 상기 스마트 디바이스(120)는 운영 시스템 모듈(operating system module)(130)과, eSE(140)와, 통신 모듈(150)을 포함한다. 본 개시의 다양한 실시예들에서, 용어 "통신 모듈"은 용어 "송수신기" 등과 혼용될 수 있다.
상기 운영 시스템 모듈(130)은 이동 사용자 인터페이스(user interface: UI, 이하 "UI"라 칭하기로 한다)(이하, "Mobile UI"라 칭하기로 한다)(131)를 포함한다. 상기 Mobile UI(131)는 상기 서버(100) 혹은 TSM(110)과 스마트 디바이스(120)간의 인터페이스를 나타낸다.
상기 eSE(140)는 애플릿(applet)(141)과 제어기(143)를 포함한다. 도 1에서는 상기 스마트 디바이스(120)가 포함하는 제어기(143)를 "OPEN"으로 도시하였음에 유의하여야만 할 것이다. 상기 eSE(140)는 상기 스마트 디바이스(120)에 포함되어 있는 보안 저장 장치이다. 도 1에서는 상기 스마트 디바이스(120)가 eSE(140)를 포함하지만, 상기 eSE(140) 대신 범용 집적 회로 카드(universal integrated circuit card: UICC, 이하 "UICC"라 칭하기로 한다) 보안 엘리먼트(secure element: SE, 이하 "SE"라 칭하기로 한다)를 포함할 수도 있음은 물론이다. 상기 애플릿(applet)(141)은 상기 eSE(140) 내부에서 실행되는 작은 어플리케이션(small application)을 나타내며, 상기 TSM(110) 혹은 SE 발행자(issuer, 이하 "issuer"라 칭하기로 한다)(160)에 의해 로딩되거나 혹은 인스톨될 수 있다. 상기 제어기(143)는 본 개시의 일 실시예에 따른 보안 정보에 관련된 전반적인 동작을 제어한다.
또한, 상기 eSE(140) 이외에도 다양한 엘리먼트들이 보안 저장 장치가 될 수 있음은 물론이다. 즉, 상기 스마트 디바이스(120)는 상기 eSE(140) 뿐만 아니라 별도의 보안 저장 장치를 포함할 수 있으며, 따라서 상기 eSE(140) 가 아닌 별도의 보안 저장 장치에 상기 보안 정보가 저장될 수 있다.
상기 통신 모듈(150)은 타겟 디바이스(170), 일 예로 차량과 상기 스마트 디바이스(120)간에 신호를 송신 및/혹은 수신하기 위해 사용되는 단거리 통신 디바이스(short range communication device)를 나타낸다. 여기서, 상기 통신 모듈(150)은 일 예로 근거리 무선 통신(near field communication: NFC, 이하 "NFC"라 칭하기로 한다) 방식을 기반으로 상기 타겟 디바이스(170)와 상기 스마트 디바이스(120)간에 신호를 송신 및/혹은 수신할 수 있다. 본 개시의 일 실시예에서는 상기 통신 모듈(150)이 NFC 방식을 사용하는 경우를 가정하였으나, 상기 NFC 방식 뿐만 아니라 블루투스, 와이파이, 적외선통신, MST(Magnetic Secure Transmission, 마그네틱보안통신과 같은 다양한 단거리 통신 방식들이 사용될 수 있음은 물론이다.
또한, 상기 타겟 디바이스(170)는 통신 모듈(171)을 포함하며, 상기 통신 모듈(171)은 상기 스마트 디바이스(120)와 상기 타겟 디바이스(170) 간에 신호를 송신 및/혹은 수신하기 위해 사용되는 단거리 통신 디바이스를 나타낸다. 여기서, 상기 통신 모듈(171)은 일 예로 NFC 방식을 기반으로 상기 타겟 디바이스(170)와 상기 스마트 디바이스(120)간에 신호를 송신 및/혹은 수신할 수 있다. 본 개시의 일 실시예에서는 상기 통신 모듈(171)이 NFC 방식을 사용하는 경우를 가정하였으나, 상기 NFC 방식 뿐만 아니라 블루투스와 같은 다양한 단거리 통신 방식들이 사용될 수 있음은 물론이다. 한편, 도 1에서는 각 엔터티가 다수의 모듈들을 포함하는 경우를 설명하였으나, 각 엔터티가 포함하는 모듈들은 적어도 1개의 프로세서로 구현될 수도 있음은 물론이다.
도 1에서는 본 개시의 일 실시예에 따른 통신 시스템의 내부 구조에 대해서 설명하였으며, 다음으로 도 2를 참조하여 본 개시의 일 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하기로 한다.
도 2은 본 개시의 일 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다.
도 2를 참조하면, 먼저 도 2에는 서비스 제공자가 "OEM server"로, 기본 디바이스가 "Owner 단말"로, 보조 디바이스가 "Client 단말"로 도시되어 있음에 유의하여야만 할 것이다.
도 2를 참조하면, 먼저 상기 통신 시스템은 서비스 제공자와, 기본 디바이스와, 보조 디바이스를 포함한다. 따라서, 상기 보조 디바이스는 상기 서비스 제공자에 등록되어 있지 않고, 따라서 상기 서비스 제공자에는 상기 보조 디바이스에 대한 계정이 존재하지 않는다고 가정하기로 한다.
먼저, 상기 보조 디바이스가 상기 기본 디바이스의 디지털 키를 공유하고자 할 경우, 상기 보조 디바이스는 상기 기본 디바이스로 디지털 키를 공유하기를 요청하는 메시지를 송신한다. 여기서, 디지털 키를 공유하기를 요청하는 메시지를 "키 공유 메시지"라 칭하기로 한다. 상기 키 공유 메시지는 상기 보조 디바이스의 식별자(identifier: ID, 이하 "ID"라 칭하기로 한다)와 인증서를 포함한다(1. Client ID + Client 인증서).
상기 보조 디바이스로부터 키 공유 메시지를 수신한 기본 디바이스는 상기 키 공유 메시지에 포함되어 있는, 상기 보조 디바이스의 ID와 인증서를 기반으로 상기 보조 디바이스에 대한 검증 동작을 수행하고, 상기 보조 디바이스에 대한 검증 결과가 성공을 나타낼 경우, 상기 보조 디바이스에 대한 보증서를 생성한다(2. Client 검증 및 보증서 작성). 이렇게, 상기 보조 디바이스에 대한 검증 결과가 성공을 나타낼 경우, 상기 기본 디바이스는 상기 서비스 제공자로 상기 보조 디바이스를 등록하기를 요청하는 메시지를 송신한다. 여기서, 보조 디바이스를 등록하기를 요청하는 메시지를 "보조 디바이스 등록 요청 메시지"라 칭하기로 한다. 여기서, 상기 보조 디바이스 등록 요청 메시지는 상기 보조 디바이스에 대한 보증서를 포함하며, 상기 보증서는 일회용 비밀 번호(one time password: OTP, 이하 "OTP"라 칭하기로 한다)와, 억세스 속성(access property)를 포함한다(3. Client 대리 등록(보증서 제출), (opt.) Access Property 포함).
상기 기본 디바이스로부터 보조 디바이스 등록 요청 메시지를 수신한 서비스 제공자는 상기 클라이언트 등록 요청 메시지에 포함되어 있는 보증서에 대한 확인 동작을 수행하고(4. Owner 보증 확인), 상기 보증서에 대한 확인 결과가 성공을 나타낼 경우 상기 기본 디바이스로 상기 보조 디바이스 등록 요청 메시지에 대한 응답 메시지를 송신한다(5. Client 용 OTP 발급). 여기서, 보조 디바이스 등록 요청 메시지에 대한 응답 메시지를 "보조 디바이스 등록 응답 메시지"라 칭하기로 한다. 상기 보조 디바이스 등록 응답 메시지는 상기 보조 디바이스에 대해 상기 서비스 제공자가 발급한 OTP를 포함한다.
상기 서비스 제공자로부터 보조 디바이스 등록 응답 메시지를 수신한 기본 디바이스는 상기 보조 디바이스로 상기 클라이언트 등록 요청 메시지에 대한 응답 메시지인 보조 디바이스 등록 결과 통보 메시지를 송신한다(6. OTP 전달). 여기서, 상기 보조 디바이스 등록 결과 통보 메시지는 상기 서비스 제공자로부터 수신한 상기 보조 디바이스에 대한 OTP를 포함한다.
상기 기본 디바이스로부터 보조 디바이스 등록 결과 통보 메시지를 수신한 보조 디바이스는 상기 서비스 제공자와 상기 보조 디바이스 등록 결과 통보 메시지에 포함되어 있는 OTP를 기반으로 인증 동작을 수행한다(7. OTP 이용 Client 인증). 상기 보조 디바이스에 대한 인증 결과가 성공을 나타낼 경우, 상기 서비스 제공자는 상기 보조 디바이스로 디지털 키를 발급한다(8. Digital Key 발급).
결과적으로, 도 2에 도시되어 있는 디지털 키를 제공하는 과정은 다음과 같이 정리될 수 있다.
(1) 이전에 OEM서버와 Client 단말은 관계가 없고,
(2) Owner 단말이 Client 단말을 보증하여 OEM 서버에 Client 정보를 대신 등록하고,
(3) OEM이 발급한 비밀정보(OTP)를 Client에 전달하고,
(4) OEM은 등록된 Client가 비밀정보를 가지고 서비스 요청했을 때, Key를 발급한다.
도 2에서는 본 개시의 일 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하였으며, 다음으로 도 3을 참조하여 본 개시의 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하기로 한다.
도 3은 본 개시의 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다.
도 3을 참조하면, 먼저 도 3에는 서비스 제공자가 "OEM Server"로, 기본 디바이스가 "Owner Entity"로, 보조 디바이스가 "Client 단말"로 도시되어 있음에 유의하여야만 할 것이다.
도 3에 도시되어 있는 디지털 키 제공 과정은 기본 디바이스가 보조 디바이스와의 키 공유를 먼저 신청하고, 기본 디바이스가 발급한 공유 토큰(sharing token, 이하 "sharing token"라 칭하기로 한다)을 서비스 제공자가 검증할 경우의 디지털 키 제공 과정임에 유의하여야만 할 것이다.
먼저, 상기 기본 디바이스는 서비스 제공자로 키 공유를 신청하면(1. Key sharing 신청), 상기 서비스 제공자는 nonce를 발행한다(2. Nonce 발행). 그리고 나서, 상기 서비스 제공자는 상기 발행한 nonce를 상기 기본 디바이스로 전달하고(3. Nonce*전달), 상기 기본 디바이스는 상기 nonce 및 디지털 키를 기반으로 sharing token를 생성한다(4. Nonce 및 Digital Key (또는 양단간 사전 공유된 SHS를 이용하여 Sharing Token 생성).
그리고 나서, 상기 기본 디바이스는 상기 보조 디바이스와 NCF 커넥션을 성립하고(5. NFC 연결), 상기 보조 디바이스로 sharing token을 송신한다(6. Sharing Token 전달). 상기 기본 디바이스로부터 sharing token을 수신한 보조 디바이스는 상기 서비스 제공자로 서비스를 신청하고, 즉 디지털 키 발급을 신청하고(7. 서비스(Digital Key 발급) 신청), 이에 따라 상기 보조 디바이스와 서비스 제공자간에는 sharing token에 대한 검증 동작이 수행된다(8. Sharing Token 검증). 그리고 나서, 상기 sharing token에 대한 검증 결과가 성공적임을 나타낼 경우 상기 서비스 제공자는 상기 보조 디바이스로 서비스를 제공한다(9. 서비스 제공). 즉, 상기 sharing token에 대한 검증 결과가 성공적임을 나타낼 경우 상기 서비스 제공자는 상기 보조 디바이스로 디지털 키를 발급한다.
도 3에서는 본 개시의 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하였으며, 다음으로 도 4를 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하기로 한다.
도 4는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다.
도 4를 참조하면, 먼저 도 4에는 서비스 제공자가 "Service provider"로, 기본 디바이스가 "Owner"로, 보조 디바이스가 "Client"로 도시되어 있음에 유의하여야만 할 것이다.
도 4에 도시되어 있는 디지털 키 제공 과정은 보조 디바이스가 먼저 서비스 제공자에 접속한 후 서비스를 요청하여 서비스 접속 정보를 획득하고, 상기 보조 디바이스가 획득한 서비스 접속 정보를 기반으로 기본 디바이스가 서비스 제공자에 접속하여 인증 및 주요 정보 전달에 대한 확인 동작을 수행할 경우의 디지털 키 제공 과정임에 유의하여야만 할 것이다.
먼저, 상기 보조 디바이스가 상기 서비스 제공자로 서비스를 요청하고(1. 서비스 요청), 이에 상기 서비스 제공자와 보조 디바이스간에는 서비스 접속 정보가 전달된다(2. 서비스 접속 정보 전달(네트워크(network: N/W, 이하 "N/W"라 칭하기로 한다) 정보, URL(uniform resource locator), Service ID 등)). 여기서, 상기 서비스 접속 정보는 N/W 정보와, URL 정보와, Service ID 등을 포함할 수 있다.
그리고 나서, 상기 보조 디바이스는 상기 기본 디바이스로 상기 서비스 접속 정보와 상기 보조 디바이스의 정보를 송신한다(3. 서비스 접속 정보 재전송 + Client 정보). 상기 보조 디바이스로부터 서비스 접속 정보와 상기 보조 디바이스의 정보를 수신한 기본 디바이스는 상기 서비스 제공자로 접속하고(4. 서버 접속), 상기 서비스 제공자와 상기 기본 디바이스간에는 소유자 인증 절차, 즉 기본 디바이스 인증 절차가 진행된다(5. Owner 인증). 상기 기본 디바이스 인증 절차가 성공하면, 상기 기본 디바이스는 상기 서비스 제공자로 서비스를 신청한다(6. 서비스 신청(Key 발급 또는 주요 정보 대리 전달 등), (opt) Access property 포함). 여기서, 상기 서비스 신청은 일 예로 상기 보조 디바이스에 대해 디지털 키를 발급해줄 것을 요청하는 서비스 신청이 될 수 있다.
상기 기본 디바이스로부터 서비스 신청을 수신한 서비스 제공자는 상기 보조 디바이스로 서비스를 제공한다(7. 서비스 제공(Key 발급 또는 Owner로부터 받은 정보 전달).
도 4에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하였으며, 다음으로 도 5를 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하기로 한다.
도 5는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다.
도 5를 참조하면, 먼저 도 5에는 서비스 제공자가 "OEM"으로, 기본 디바이스가 "Owner"로, 보조 디바이스가 "Client"로 도시되어 있음에 유의하여야만 할 것이다.
그리고, 도 5에 기재되어 있는 디지털 키를 제공하는 과정은 기본 디바이스를 중심으로 디지털 키를 공유하는 과정임에 유의하여야만 할 것이다.
또한, 도 5에 기재되어 있는 디지털 키를 제공하는 과정은 도 2에서 설명한 바와 같은 디지털 키 제공 과정에 따른 서비스 제공자와, 기본 디바이스와, 보조 디바이스간의 신호 송/수신 동작임에 유의하여야만 할 것이다.
도 5b에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하였으며, 다음으로 도 6a내지 도 6b를 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하기로 한다.
도 6a 내지 도 6b는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다.
도 6a내지 도 6b를 참조하면, 먼저 도 6a 내지 도 6b에는 서비스 제공자가 "OEM"으로, 기본 디바이스가 "Owner Smart Device"로, 보조 디바이스가 "Client Smart Device"로 도시되어 있음에 유의하여야만 할 것이다.
그리고, 도 6a 내지 도 6b에 기재되어 있는 디지털 키를 제공하는 과정은 기본 디바이스를 중심으로 디지털 키를 공유하는 과정임에 유의하여야만 할 것이다.
또한, 도 6a 내지 도 6b에 기재되어 있는 디지털 키를 제공하는 과정은 도 2에서 설명한 바와 같은 디지털 키 제공 과정에 따른 서비스 제공자와, 기본 디바이스와, 보조 디바이스간의 신호 송/수신 동작임에 유의하여야만 할 것이다.
도 6a 내지 도 6b에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하였으며, 다음으로 도 7을 참조하여 본 개시의 일 실시예에 따른 통신 시스템에서 기본 디바이스의 동작 과정의 일 예에 대해서 설명하기로 한다.
도 7은 본 개시의 일 실시예에 따른 통신 시스템에서 기본 디바이스의 동작 과정의 일 예를 개략적으로 도시한 도면이다.
도 7을 참조하면, 먼저 도 7에는 서비스 제공자가 "OEM Server"로, 기본 디바이스가 "Owner Phone"으로 도시되어 있음에 유의하여야만 할 것이다.
그리고, 도 7에 기재되어 있는 기본 디바이스의 동작 과정은 기본 디바이스를 중심으로 디지털 키를 공유할 경우의 기본 디바이스의 동작 과정임에 유의하여야만 할 것이다.
또한, 도 7에 기재되어 있는 기본 디바이스의 동작 과정은 도 2에서 설명한 바와 같은 디지털 키 제공 과정에 따른 기본 디바이스의 동작 과정임에 유의하여야만 할 것이다.
도 7에서는 본 개시의 일 실시예에 따른 통신 시스템에서 기본 디바이스의 동작 과정의 일 예에 대해서 설명하였으며, 다음으로 도 8을 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하기로 한다.
도 8은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다.
도 8을 참조하면, 먼저 도 8에는 보조 디바이스가 "Client Smart Device"로, 기본 디바이스가 "Owner Smart Device"로, 서비스 제공자가 "OEM"으로 기재되어 있음에 유의하여야만 할 것이다.
먼저, 기본 디바이스는 서비스 제공자로 key sharing 서비스를 신청하는 메시지를 송신한다(1. Key Sharing 신청(Owner ID), (opt.) Access property). 상기 key sharing 서비스를 신청하는 메시지는 기본 디바이스의 식별자, 즉 Owner ID 등과 같은 ID를 포함할 수 있다. 또한, 상기 key sharing 서비스를 신청하는 메시지는 선택적으로(optional 하게) Access property 등과 같은 정보를 포함할 수 있다.
여기서, 상기 Access property 는 Key 유효 시간, 자동 운행 거리, 자동차 운행 가능 지역에 관련된 정보, 일 예로 Geo fencing, 일 예로 특정 지역 내에서만 운행 가능함을 나타내는 정보, 자동차 속성, 일 예로 최대 속도 등과 같은 자동차 속성과, 자동차 사용 권한, 일 예로 문 열기/트렁크 열기/시동 걸기 등과 같은 등과 같은 자동차 사용 권한 등을 포함할 수 있다.
그리고, 상기 서비스 제공자는 key sharing 신청에 대한 응답과 함께 nonce와 service ID를 송신한다(2. Key Sharing 응답(Nonce, Service ID). 여기서, 상기 nonce는 일 예로 상기 기본 디바이스가 생성할 Token의 재 사용을 방지하기 위해 사용될 수 있다.
또한, 상기 Service ID는 일 예로 이후의 절차에서 상기 보조 디바이스가 key 발급을 요청했을 때 (즉, "7" 동작) 서비스 제공자와, 기본 디바이스와, 보조 디바이스간의 Service sync-up을 일치시키기 위해 사용될 수 있다.
그리고 나서, 상기 기본 디바이스는 상기 기본 디바이스에 저장된 Digital Key또는 상기 디지털 키에 준하는 권한을 가진 Key를 사용하여 Sharing Token을 생성한다. 여기서, 상기 Sharing Token 은 Digital Key, 혹은 상기 Digital Key에 준하는 권한을 가진 Key 와 상기 서비스 제공자로부터 제공받은 nonce를 기반으로 생성될 수 있다. (3. Perform Security Operation APDU: Token Generation operation; 4. Shr. Token = Hash (Iuput Data, DK.sharing); 5. rsp. (Shr. Token); Compute Shr. Token by OEM = Hash(Input Data, DK.sharing)
그리고 나서 상기 보조 디바이스와 기본 디바이스간에는 NFC, BT 등과 같은 근거리 통신 방식을 기반으로 통신 환경이 성립된다. 도 8에서는 상기 NFC 방식을 기반으로 상기 보조 디바이스와 기본 디바이스간에 통신 환경이 성립된다고 가정하기로 한다. 즉, 도 8에서는 상기 보조 디바이스와 기본 디바이스간에 NFC 커넥션이 성립된다고 가정하기로 한다(NFC connection Established). 이로 인해 상기 보조 디바이스와 기본 디바이스간에는 secure한 channel 이 생성되었다고 가정한다.
그리고 나서 상기 기본 디바이스는 상기 보조 디바이스로 Sharing Token과 Service ID를 전달한다(6. Shr.Token, Service ID 전달).
그리고 나서 상기 보조 디바이스는 상기 서비스 제공자로 Digital Key Sharing 을 요청한다(7. Key Sharing 신청(Service ID)).
상기 서비스 제공자는 상기 보조 디바이스가 어떤 기본 디바이스와 연결되어 있는지 등을 상기 Service ID를 통해 인식할 수 있다.
상기 서비스 제공자는 Challenge와 함께 상기 보조 디바이스로 Verification을 요청한다(8. Shr.Token Verification request (Challenge)).
여기서, 상기 서비스 제공자가 Verification 을 요청하는 이유는 상기 기본 디바이스가 생성된 Sharing Token을 상기 보조 디바이스가 가지고 있는지 확인하기 위함이다.
그리고 나서 상기 보조 디바이스는 Challenge Response를 생성하여 상기 서비스 제공자로 응답한다(9. Compute Challenge response = f (Shr.Token, Challenge); 10. Challenge Response).
여기서, 상기 Challenge Response는 Sharing Token (기본 디바이스에 의해 제공된)과 Challenge (서비스 제공자에 의해 제공된r)를 기반으로 생성될 수 있다.
그리고 나서, 상기 서비스 제공자는 상기 기본 디바이스로부터 수신된 Challenge Response를 검증한다(11. Compute Challenge response by OEM = f (Shr.Token_by OEM, Challenge); 12. Verify Challenge response by comparing with challenge response by OEM).
상기 서비스 제공자는 Nonce, Challenge 값을 알고 있고, Owner ID를 통해 상기 기본 디바이스가 어떤 Digital Key를 사용했는지 파악할 수 있다.
따라서, 상기 서비스 제공자는 상기 값들을 기반으로 Sharing Token (nonce + Digital Key)을 계산하고, Challenge Response (Sharing Token + Challenge) 를 계산한다.
그리고 나서, 상기 서비스 제공자는 상기 보조 디바이스로부터 전달받은 Challenge response 와 상기 서비스 제공자가 직접 계산한 Challenge response 이 일치하는 지를 통해 상기 기본 디바이스를 검증한다.
여기서 상기 서비스 제공자와 기본 디바이스/보조 디바이스간에는 Sharing Token 계산 함수와 Challenge Response 계산 함수를 사용할지 sync-up 이 되어 있거나, 혹은 미리 결정되어 있다고 가정하기로 한다.
상기 보조 디바이스가 성공적으로 검증된 경우, 상기 서비스 제공자는 상기 보조 디바이스에게 Digital Key를 발급한다(13. Service 제공(key 발급 등), (opt) Access property가 있는 경우, Access property가 반영된 서비스 제공).
여기서, 상기 "1" 동작에서 Access property가 설정 된 경우, 상기 서비스 제공자는 상기 설정된 Access property에 해당하는 특징이 반영된 디지털 키를 발급한다.
한편, 상기 Digital Key 값과 Access property는 디바이스 내 서로 다른 디바이스들 혹은 서로 다른 영역들에 저장 될 수 있다. 일 예로, Digital Key는 SE에 저장, Access Property는 TEE 등과 같은 별도의 디바이스 혹은 영역에 저장될 수 있다.
그리고, 도 8에 기재되어 있는 디지털 키 제공 과정은 보조 디바이스를 중심으로 디지털 키를 공유할 경우의 디지털 키 제공 과정임에 유의하여야만 할 것이다.
또한, 도 8에 기재되어 있는 디지털 키 제공 과정은 도 3에서 설명한 바와 같은 디지털 키 제공 과정에 따른 서비스 제공자와, 기본 디바이스와, 보조 디바이스간의 신호 송수신 동작 과정임에 유의하여야만 할 것이다.
도 8에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하였으며, 다음으로 도 9a 내지 도 9b를 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하기로 한다.
도 9a 내지 도 9b는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다.
도 9a 내지 도 9b를 참조하면, 먼저 도 9a 내지 도 9b에는 서비스 제공자가 "OEM"으로, 기본 디바이스가 "Owner Smart Device"로, 보조 디바이스가 "Client Smart Device"로 도시되어 있음에 유의하여야만 할 것이다.
그리고, 도 9a 내지 도 9b에 기재되어 있는 디지털 키를 제공하는 과정은 보조 디바이스를 중심으로 디지털 키를 공유하는 과정임에 유의하여야만 할 것이다.
또한, 도 9a 내지 도 9b에 기재되어 있는 디지털 키를 제공하는 과정은 기본 디바이스와 보조 디바이스간의 보안이 강화된 디지털 키 제공 과정임에 유의하여야만 할 것이다.
또한, 도 9a 내지 도 9b에 기재되어 있는 디지털 키를 제공하는 과정은 도 3에서 설명한 바와 같은 디지털 키 제공 과정에 따른 서비스 제공자와, 기본 디바이스와, 보조 디바이스간의 신호 송/수신 동작임에 유의하여야만 할 것이다.
도 9a 내지 도 9b에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하였으며, 다음으로 도 10a 내지 도 10b를 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하기로 한다.
도 10a 내지 도 10b는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다.
도 10a 내지 도 10b를 참조하면, 먼저 도 10a 내지 도 10b에는 서비스 제공자가 "OEM"으로, 기본 디바이스가 "Owner Smart Device"로, 보조 디바이스가 "Client Smart Device"로 도시되어 있음에 유의하여야만 할 것이다.
그리고, 도 10a 내지 도 10b에 기재되어 있는 디지털 키를 제공하는 과정은 보조 디바이스를 중심으로 디지털 키를 공유하는 과정임에 유의하여야만 할 것이다.
또한, 도 10a 내지 도 10b에 기재되어 있는 디지털 키를 제공하는 과정은 기본 디바이스를 통한 재확인 절차가 추가된 디지털 키 제공 과정임에 유의하여야만 할 것이다.
또한, 도 10a 내지 도 10b에 기재되어 있는 디지털 키를 제공하는 과정은 도 3에서 설명한 바와 같은 디지털 키 제공 과정에 따른 서비스 제공자와, 기본 디바이스와, 보조 디바이스간의 신호 송/수신 동작임에 유의하여야만 할 것이다.
도 10a 내지 도 10b에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하였으며, 다음으로 도 11을 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하기로 한다.
도 11은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다.
도 11을 참조하면, 먼저 도 11에는 보조 디바이스가 "Client Smart Device"로, 기본 디바이스가 "Authorized Entity(Owner)"로, 서비스 제공자가 "Service Provider"로 기재되어 있음에 유의하여야만 할 것이다.
먼저, 보조 디바이스가 Service Provider에 서비스를 요청한다(1. 서비스 신청(Key Sharing 또는 보안 정보 Sharing 등). 여기서, 상기 서비스의 종류에 대해서 설명하면 다음과 같다.
먼저, Key Sharing 등과 같이 다른 디바이스의 주요 정보를 전달 받거나, 본 개시의 다양한 실시예들에서는 Key를 공유하기 위한 주요 정보를 전달받거나,
상기 보조 디바이스가 직접 가입하지 않은 서비스를 기본 디바이스의 허락 아래 사용하거나,
상기 기본 디바이스의 주요 정보, 일 예로 인증서, ID, 패스워드(password: PW, 이하 "PW"라 칭하기로 한다) 등과 같은 주요 정보를 상기 서비스 제공자를 통해 안전하게 전달받고자 하는 서비스들을 포함할 수 있다.
이후, 상기 Service Provider는 상기 보조 디바이스에게 Secure한 서비스 접속 정보를 전달한다(2. 서비스 접속 정보 전달(N/W Access 정보, 서버 URL, Service ID 등). 여기서, 상기 서비스 접속 정보는 일시적으로 사용 가능한 네트워크 Access 정보, 서비스 관련 Service URL, Service ID 등을 포함할 수 있다.
또한, 상기 서비스 제공자는 필요에 따라 상기 보조 디바이스가 Rooting 되지 않았는지, Application이 신뢰성 있는 Appliation인지 등과 같은 검사를 수행하는 동작이 미리 수행될 수도 있다.상기 기본 디바이스와 상기 보조 디바이스간에 NFC 커넥션이 성립된 상태에서(NFC Connection Established) 상기 보조 디바이스는 상기 기본 디바이스로 서비스 허용 (Key Sharing 또는 정보 공유 또는 로그인 허락 등)을 요청한다(3. 정보 공유 요청(서비스 접속 정보, Client ID). 여기서, 상기 보조 디바이스는 상기 서비스 제공자로부터 수신한 서비스 접속 정보를 상기 기본 디바이스로 전달할 수 있다. 즉, 상기 보조 디바이스는 서비스 접속 정보와 상기 보조 디바이스 자신의 ID, 즉 Client ID를 포함하여 서비스 허용을 요청할 수 있다.
그리고, 상기 기본 디바이스는 상기 보조 디바이스로부터 수신한 서비스 접속 정보를 기반으로 Service Provider(SP)에 접속한다(4. 서비스 접속 정보 기반 서버 접속).
그리고, 상기 기본 디바이스와 서비스 제공자 간에는 상기 기본 디바이스 인증을 위한 절차가 수행된다. 즉, 상기 서비스 제공자는 상기 서비스에 대해 허가할 수 있는지 검증하기 위해 상기 기본 디바이스를 검증한다(5. Owner 인증(계정 인증 또는 Digital Key 인증 등). 여기서, 상기 서비스 제공자는 상기 기본 디바이스에 Digital Key가 저장되어 있는지 검사함으로써 상기 기본 디바이스를 검증할 수 있다. 물론, 이는 상기 서비스 제공자와 기본 디바이스가 디지털 키를 공유한다고 가정할 경우에 가능하다.
이와는 달리 상기 서비스 제공자는 상기 기본 디바이스가 ID/PW 등과 같은 상기 서비스 제공자의 서비스에 기 가입/등록된 사용자가 맞는지 검사함으로써 상기 기본 디바이스를 검증할 수 있다. 물론, 이는 정보 전달/서비스 허용을 가정할 경우에 가능하다.
또한, 상기 서비스 제공자와 기본 디바이스는 부가적으로 상기 기본 디바이스의 사용자의 동의를 명확하게 구하기 위한 동작, 일 예로 사용자에 의한 확인 버튼 입력 또는 지문 인증 등과 같은 상기 기본 디바이스의 사용자의 동의를 명확하게 구하기 위한 동작을 추가적으로 수행할 수 있다.
그리고 나서, 상기 기본 디바이스는 상기 보조 디바이스에게 공유할 정보가 있는 경우, 해당 정보를 상기 서비스 제공자로 전달한다(6. 공유할 보안 정보 전달(예: Access Property 또는 보안 정보 그 자체).
상기 서비스 제공자는 상기 보조 디바이스가 요구하고, 상기 기본 디바이스가 확인해 준 정보/서비스를 상기 보조 디바이스에게 제공한다(7. 보안 정보 전달).
Case 1. 인증서 등과 주요 정보가 기본 디바이스에 저장된 경우, 상기 기본 디바이스는 상기 주요 정보를 서비스 제공자에 업로드한다.
Case 2. Digital Key 공유의 경우, 상기 기본 디바이스는 Key ID 와 Key Property 등을 서비스 제공자로 전달하고, 상기 서비스 제공자가 조건에 부합하는 Digital Key를 보조 디바아스에게 발급한다.
Case 3. 특정 서비스를 서비스 제공자가 제공만 하면 되는 경우, 일 예로 음악 감상 서비스 등과 같은 서비스를 서비스 제공자가 제공만 하면 되는 경우, 상기 "6" 동작은 생략 가능하고 "5" 동작에서의 보조 디바이스 인증 후 바로 서비스를 제공한다.
또한, 도 11에 기재되어 있는 디지털 키를 제공하는 과정은 도 4에서 설명한 바와 같은 디지털 키 제공 과정에 따른 서비스 제공자와, 기본 디바이스와, 보조 디바이스간의 신호 송/수신 동작임에 유의하여야만 할 것이다.
한편, 전화 번호, IMEI, SE ID 등과 같은, 보조 디바이스를 식별하기 위한 정보는 고유한 정보이지만, 누구나 생성 및 획득이 가능한 정보이다. 따라서, 기본 디바이스는 상기 보조 디바이스에 대한 보조 디바이스 식별 정보를 수신한다고 할지라도, 상기 보조 디바이스 식별 정보에 대한 비교 대상이 존재하지 않기 때문에 상기 보조 디바이스 식별 정보를 검증하는 것이 어려울 수 있다.
따라서, 본 개시의 일 실시예에서는 기본 디바이스와 보조 디바이스간의 GPS정보를 비교 및 검증하여 상기 기본 디바이스와 보조 디바이스간의 동시성, 일 예로 시간 및 장소와 같은 동시성을 보조 디바이스를 인증한다.
또한, 서로 다른 2개의 경로들을 통해 보조 디바이스 ID를 획득 및 비교함으로써 보조 디바이스에 대한 검증을 강화시킬 수 있다.
그러면 여기서 도 12를 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 보조 디바이스의 위치를 검증하는 과정의 일 예에 대해서 설명하기로 한다.
도 12는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 보조 디바이스의 위치를 검증하는 과정의 일 예를 개략적으로 도시한 도면이다.
도 12에 도시되어 있는 보조 디바이스의 위치를 검증하는 과정은 디지털 키 공유 과정에서 보조 디바이스를 등록할 때 GPS 정보 및 타임 스탬프(time stamp) 등과 같은 추가 정보를 함께 등록함으로써 기본 디바이스와 보조 디바이스가 동일 영역에 존재하는지 확인하고 디지털 키를 공유함으로써 중간자 공격(man in the middle attack) 등과 같은 보안 공격에 대해 보다 강인한 디지털 키 공유 서비스를 제공하는 것을 가능하게 한다.
또한, 도 12에는 기본 디바이스가 "Owner"로, 보조 디바이스가 "Client"로 도시되어 있음에 유의하여야만 할 것이다.
도 12에 도시되어 있는 바와 같이 기본 디바이스와 보조 디바이스가 키 공유 서비스를 선택하면(1. App 실행(Key 공유 선택), tap 절차가 수행되고(2. Tap), 상기 기본 디바이스는 내부적으로 tapping 시점의 GPS 및 절대 시간을 획득한다(3. 내부적으로 Tapping 시점의 GPS 및 절대 시간 확보(기준시, 기준 GPS)).
또한, 상기 보조 디바이스는 상기 보조 디바이스의 사용자 정보와 tapping 시점의 절대 시간, GPS를 획득한다(4. Info (SE Id, Client 인증서) + Tapping된 시점의 절대 시간, GPS 확보). 그리고 나서, 상기 보조 디바이스는 상기 기본 디바이스로 상기 보조 디바이스의 사용자 정보를 송신하며, 이때 절대 시간 및 GPS 정보가 함께 송신된다(5. Client 정보 전달(SE Id, Client 인증서, 시간, GPS).
상기 기본 디바이스는 상기 기본 디바이스의 기준 시간과, 기준 GPS 정보와, 상기 보조 디바이스로부터 수신된 시간 및 GPS 정보를 비교하고(6. 기준시, 기준 GPS와 Client의 시간/GPS 비교,검증), 상기 비교 결과 상기 보조 디바이스가 상기 기본 디바이스와 동일 영역에 존재한다고 판단될 경우 상기 기본 디바이스의 디지털 키를 사용하여 상기 기본 디바이스의 사용자 정보에 서명하고(7. DK 이용 서명), 상기 서명된 사용자 정보를 서비스 제공자에 등록한다(8. 대리 등록).
도 12에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 보조 디바이스의 위치를 검증하는 과정의 일 예에 대해서 설명하였으며, 다음으로 도 13을 참조하여 본 개시의 일 실시예에 따른 통신 시스템에서 기본 디바이스의 동작 과정의 다른 예에 대해서 설명하기로 한다.
도 13은 본 개시의 일 실시예에 따른 통신 시스템에서 기본 디바이스의 동작 과정의 다른 예를 개략적으로 도시한 도면이다.
도 13을 참조하면, 먼저 기본 디바이스가 "Owner"로 도시되어 있음에 유의하여야만 할 것이다.
도 13에서, 상기 GPS 및 time stamp 검증 동작은 디지털 키 제공 과정에서 수행되는 보조 디바이스 등록 과정 중 일 예로 소유자 사전 확인(Owner Pre-Confirmation) 동작에서 수행될 수 있다.
도 13에서는 본 개시의 일 실시예에 따른 통신 시스템에서 기본 디바이스의 동작 과정의 다른 예에 대해서 설명하였으며, 다음으로 도 14를 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하기로 한다.
도 14는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다.
도 14를 참조하면, 먼저 도 14에는 보조 디바이스가 "Client Smart Device"로, 기본 디바이스가 "Owner Smart Device"로, 서비스 제공자가 "OEM"으로 기재되어 있음에 유의하여야만 할 것이다.
또한, 도 14에 도시되어 있는 디지털 키 제공 과정은 기본 디바이스가 인증에 관련된 정보를 생성 및 전달하는 과정을 포함하고 있음에 유의하여야만 할 것이다.
한편, 본 개시의 다양한 실시예들에서는 보조 디바이스를 인증하는 것이 중요한 이슈들 중 하나이며, 이런 보조 디바이스에 대한 인증은 정보의 소스에 대한 신뢰성을 확보하기 위함이며, 어플리케이션의 무결성을 검증하기 위함이다.
어플리케이션의 무결성을 검증하는 방식들은 다양하게 존재할 수 있으며, 첫 번째 방식은 서비스 제공자를 통해 어플리케이션의 무결성을 검증하는 방식이다. 즉, 서비스 제공자가 어플리케이션의 무결성을 검증해주는 것이며, 이 경우 서비스 제공자가 어플리케이션 인증을 위한 서버를 별도로 운영해야 하므로 서비스 운영 및 관리 비용이 증가될 수 있다.
두 번째 방식은 서비스 제공자 없이 디바이스들간에 어프리케이션의 무결성을 검증하는 방식이다. 이 경우, 디바이스들, 즉 기본 디바이스와 보조 디바이스간의 OS 및 어플리케이션의 버전이 동일해야만 하며, 기본 디바이스가 보조 디바이스의 어플리케이션의 해시(hash) 값을 수신한 후, 상기 기본 디바이스 자신의 어플리케이션의 해시 값과 비교함으로써 어플리케이션의 무결성을 검증할 수 있다. 하지만, 상기 두 번째 방식의 경우 디바이스 제조사, OS, 디바이스 종류 등과 같은 다양한 파라미터들이 모두 고려되어야 하며, 따라서 그 구현이 어려울 수 있다.
따라서, 본 개시의 다양한 실시예들에서는 정보의 신뢰성을 기본 디바이스가 직접적으로 검증하는 방안을 제안한다. 즉, 상기 기본 디바이스는 직접 SE에 저장되어 있는 정보를 획득하고 검증함으로써 정보의 신뢰성을 향상시킬 수 있다. 설명의 편의상, 이와 같은 검증 방식을 2-way 검증 방식이라 칭하기로 한다.
다음으로 도 15를 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 보조 디바이스를 검증하는 과정의 일 예에 대해서 설명하기로 한다.
도 15는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 보조 디바이스를 검증하는 과정의 일 예를 개략적으로 도시한 도면이다.
도 15를 참조하면, 먼저 도 15에서는 기본 디바이스가 "Owner"로, 보조 디바이스가 "Client"로 도시되어 있음에 유의하여야만 할 것이다.
먼저, 2-way 검증 방식이 구현될 경우 기본 디바이스가 보조 디바이스의 어플리케이션과 보조 디바이스의 SE로부터 각각 SE ID 를 확보하여 비교한 후, 보조 디바이스의 어플리케이션과 보조 디바이스의 SE를 바인딩(binding)하여 서비스 제공자에 등록할 수 있다.
즉, 먼저 디지털 키를 공유하는 과정에서 OS 영역에 존재하는 Mobile UI(=Application)를 통해서 User Information을 획득하기 때문에, OS가 루팅되었거나 Application이 해킹 공격 등으로 인해 감염된 경우, Application으로부터 전달받는 User Information의 신뢰성이 낮을 수 있다. 따라서, Mobile UI를 통하지 않는 주요 정보를User Secure Element 에서 직접 확보하여 User Application을 통해 얻은 정보와 비교함으로써 User application에 대한 추가 검증에 활용할 수 있다.
도 15에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 보조 디바이스를 검증하는 과정의 일 예에 대해서 설명하였으며, 다음으로 도 16a 내지 도 16b를 참조하여 도 15의 보조 디바이스를 검증하는 과정에 따른 신호 송/수신 과정에 대해서 설명하기로 한다.
도 16a 내지 도 16b는 도 15의 보조 디바이스를 검증하는 과정에 따른 신호 송/수신 과정을 개략적으로 도시한 도면이다.
도 16a 내지 도 16b를 참조하면, 먼저 도 16a 내지 도 16b에는 보조 디바이스가 "Client Smart Device"로, 기본 디바이스가 "Owner Smart Device"로, 서비스 제공자가 "OEM"으로 기재되어 있음에 유의하여야만 할 것이다.
도 16a 내지 도 16b에 도시되어 있는 보조 디바이스 검증 과정은 도 15에서 설명한 바와 같은 2-way 방식을 기반으로 하는 보조 디바이스 검증 과정에 따른 서비스 제공자와, 기본 디바이스와, 보조 디바이스간의 신호 송/수신 동작임에 유의하여야만 할 것이다.
다음으로 본 개시에서 제안하는 어플리케이션 프로토콜 데이터 유닛(application protocol data unit: APDU, 이하 "APDU"라 칭하기로 한다) 명령(command)에 대해서 설명하기로 한다.
먼저, 디지털 키 제공과정에서, 디지털 서명을 계산하는데 사용되는 APDU command는 다음과 같다.
<APDU command>
Figure pat00001
상기 디지털 서명을 계산하는데 사용되는 APDU command에서 Data 필드는 하기와 같이 나타낼 수 있다.
<Data field details>
Figure pat00002
또한, 상기 디지털 서명을 계산하는데 사용되는 APDU command에 대해서 응답되는 응답 메시지, 즉 APDU response에 포함되는 데이터 필드는 하기와 같이 나타낼 수 있다.
<Data Field Returned in the Response Message>
Figure pat00003
또한, 상기 디지털 서명을 계산할 경우의 Error Condition들은 다음과 같다.
<Error Conditions>
Figure pat00004
다음으로, 디지털 키 제공과정에서, 토큰을 생성하는데 사용되는 APDU command는 다음과 같다.
<APDU command>
Figure pat00005
상기 토큰을 생성하는데 사용되는 APDU command에서 Data 필드는 하기와 같이 나타낼 수 있다.
<Data field details>
Figure pat00006
또한, 상기 토큰을 생성하는데 사용되는 APDU command에 대해서 응답되는 응답 메시지, 즉 APDU response에 포함되는 데이터 필드는 하기와 같이 나타낼 수 있다.
<Data Field Returned in the Response Message>
Figure pat00007
또한, 상기 토큰을 생성할 경우의 Error Condition들은 다음과 같다.
<Error Conditions>
Figure pat00008
다음으로, 디지털 키 제공과정에서, 토큰을 검증하는데 사용되는 APDU command는 다음과 같다.
<APDU command>
Figure pat00009
상기 토큰을 검증하는데 사용되는 APDU command에서 Data 필드는 하기와 같이 나타낼 수 있다.
<Data field details>
Figure pat00010
또한, 상기 토큰을 검증할 경우의 Error Condition들은 다음과 같다.
<Error Conditions>
Figure pat00011
다음으로 도 17을 참조하여 본 개시의 일 실시예에 따른 통신 시스템에서 기본 디바이스와 보조 디바이스간의 연결 과정의 일 예에 대해서 설명하기로 한다.
도 17은 본 개시의 일 실시예에 따른 통신 시스템에서 기본 디바이스와 보조 디바이스간의 연결 과정의 일 예를 개략적으로 도시한 도면이다.
도 17을 참조하면, 먼저 도 17에는 보조 디바이스가 "Client"로, 기본 디바이스가 "Owner"로, 서비스 제공자가 "OEM"으로 기재되어 있음에 유의하여야만 할 것이다.
먼저, 비교적 근거리, 일 예로 기본 디바이스와 보조 디바이스간의 거리가 미리 설정되어 있는 제1 거리 미만일 경우, NFC를 통해 Secure Connection을 셋업할 수 있다.
또한, 비교적 원거리, 일 예로 상기 기본 디바이스와 보조 디바이스간의 거리가 상기 제1 거리 이상일 경우, 상기 기본 디바이스와 보조 디바이스간에는 OTP를 이용하여 상호 발견 및 어플리케이션 식별자(APP ID)를 통해 Secure Connection 을 셋업할 수 있다. 여기서, 상기 NFC 이외의 다른 연결 방식들은 다양하게 존재할 수 있으며, 일 예로 블루투스, 와이 파이 등이 될 수 있음은 물론이다.
도 17에서는 본 개시의 일 실시예에 따른 통신 시스템에서 기본 디바이스와 보조 디바이스간의 연결 과정의 일 예에서 대해서 설명하였으며, 다음으로 도 18을 참조하여 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 일 예에 대해서 설명하기로 한다.
도 18은 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 일 예를 개략적으로 도시한 도면이다.
도 18을 참조하면, 먼저 도 18에는 보조 디바이스가 "Client"로, 기본 디바이스가 "Owner"로, 서비스 제공자가 "OEM"으로 기재되어 있음에 유의하여야만 할 것이다. 또한, 도 18에서 PK는 공중 키(public key)를 나타내며, SK는 비밀 키(secrete key), 즉 사설 키(private key)를 나타낸다.
또한, 도 18에 도시되어 있는 보조 디바이스 등록 과정은 클라이언트 어플리케이션(client application: CA, 이하 "CA"라 칭하기로 한다)가 존재하는 경우 CA 인증서를 기반으로 기본 디바이스를 보증할 경우의 보조 디바이스 등록 과정임에 유의하여야만 할 것이다.
도 18에서는 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 일 예에 대해서 설명하였으며, 다음으로 도 19를 참조하여 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 다른 예에 대해서 설명하기로 한다.
도 19는 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 다른 예를 개략적으로 도시한 도면이다.
도 19를 참조하면, 먼저 도 19에는 보조 디바이스가 "Client"로, 기본 디바이스가 "Owner"로, 서비스 제공자가 "OEM"으로 기재되어 있음에 유의하여야만 할 것이다. 또한, 도 19에서 PK는 공중 키를 나타내며, SK는 비밀 키, 즉 사설 키를 나타낸다.
또한, 도 19에 도시되어 있는 보조 디바이스 등록 과정은 CA가 존재하는 경우 디지털 키(DK)를 기반으로 보조 디바이스를 등록하는 과정임에 유의하여야만 할 것이다.
도 19에서는 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 다른 예에 대해서 설명하였으며, 다음으로 도 20a 내지 도 20b를 참조하여 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 또 다른 예에 대해서 설명하기로 한다.
도 20a 내지 도 20b는 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 또 다른 예를 개략적으로 도시한 도면이다.
도 20a 내지 도 20b를 참조하면, 먼저 도 20a 내지 도 20b에는 보조 디바이스가 "Client"로, 기본 디바이스가 "Owner"로, 서비스 제공자가 "OEM"으로 기재되어 있음에 유의하여야만 할 것이다. 또한, 도 20a 내지 도 20b에서 PK는 공중 키를 나타내며, SK는 비밀 키, 즉 사설 키를 나타낸다.
또한, 도 20a 내지 도 20b에 도시되어 있는 보조 디바이스 등록 과정은 CA가 존재하는 경우 별도의 디지털 키 권한 인증용 키를 기반으로 보조 디바이스를 등록하는 과정임에 유의하여야만 할 것이다. 여기서, 디지털 키 권한 인증용 키는 디지털 키 자체에 대한 권한을 인증하기 위해 사용되는 키를 나타낸다.
도 20a 내지 도 20b에서는 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 또 다른 예에 대해서 설명하였으며, 다음으로 도 21을 참조하여 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 또 다른 예에 대해서 설명하기로 한다.
도 21은 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 또 다른 예를 개략적으로 도시한 도면이다.
도 21을 참조하면, 먼저 도 21에는 보조 디바이스가 "Client"로, 기본 디바이스가 "Owner"로, 서비스 제공자가 "OEM"으로 기재되어 있음에 유의하여야만 할 것이다. 또한, 도 21에서 PK는 공중 키를 나타내며, SK는 비밀 키, 즉 사설 키를 나타낸다.
또한, 도 21에 도시되어 있는 보조 디바이스 등록 과정은 CA가 존재하지 않는 경우 보조 디바이스가 디지털 키를 발급받기 위해 사용되는 키를 기반으로 보조 디바이스를 등록하는 과정임에 유의하여야만 할 것이다. 여기서, 상기 보조 디바이스가 디지털 키를 발급받기 위해 사용되는 키는 키 페어(key pair) 형태로 구현될 수 있다.
도 21에서는 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 또 다른 예에 대해서 설명하였으며, 다음으로 도 22를 참조하여 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 인증하는 과정의 일 예에 대해서 설명하기로 한다.
도 22는 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 인증하는 과정의 일 예를 개략적으로 도시한 도면이다.
도 22를 참조하면, 도 22에는 보조 디바이스가 "Client"로, 기본 디바이스가 "Owner"로, 서비스 제공자가 "OEM"으로 기재되어 있음에 유의하여야만 할 것이다.
또한, 도 22에 도시되어 있는 보조 디바이스를 인증하는 과정은 보조 디바이스와 서비스 제공자가 소유할 수 있는 공유 비밀 키를 기반으로 보조 디바이스를 인증하는 과정임에 유의하여야만 할 것이다.
도 22에서는 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 인증하는 과정의 일 예에 대해서 설명하였으며, 다음으로 도 23을 참조하여 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 인증하는 과정의 다른 예에 대해서 설명하기로 한다.
도 23은 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 인증하는 과정의 다른 예를 개략적으로 도시한 도면이다.
도 23을 참조하면, 도 23에는 보조 디바이스가 "Client"로, 기본 디바이스가 "Owner"로, 서비스 제공자가 "OEM"으로 기재되어 있음에 유의하여야만 할 것이다.
또한, 도 23에 도시되어 있는 보조 디바이스를 인증하는 과정은 보조 디바이스와 서비스 제공자가 소유할 수 있는 공유 비밀 키를 기반으로 보조 디바이스를 인증하는 과정임에 유의하여야만 할 것이다.
도 23에서는 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스를 인증하는 과정의 다른 예에 대해서 설명하였으며, 다음으로 도 24를 참조하여 본 개시의 일 실시예에 따른 통신 시스템에서 디지털 키를 발급하는 과정의 일 예에 대해서 설명하기로 한다.
도 24는 본 개시의 일 실시예에 따른 통신 시스템에서 디지털 키를 발급하는 과정의 일 예를 개략적으로 도시한 도면이다.
도 24를 참조하면, 도 24에는 보조 디바이스가 "Client"로, 기본 디바이스가 "Owner"로, 서비스 제공자가 "OEM"으로 기재되어 있음에 유의하여야만 할 것이다.
먼저, 서비스 제공자는 클라이언트로 디지털 키를 직접 발급할 수 있다.
이와는 달리, 상기 서비스 제공자는 도 24에 도시되어 있는 바와 같이 보조 디바이스에 디지털 키를 발급하면서, 이와 동시에 기본 디바이스의 디지털 키를 일시적으로 사용 중지시킬 수 있다. 이 경우, 마치 서비스 제공자가 보조 디바이스로 물리적인 키(physical key)를 전달한 것과 동일한 효과를 획득할 수 있다.
도 24에서는 본 개시의 일 실시예에 따른 통신 시스템에서 디지털 키를 발급하는 과정의 일 예에 대해서 설명하였으며, 다음으로 도 25a 내지 도 25b를 참조하여 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스의 정보를 획득하는 과정의 일 예에 대해서 설명하기로 한다.
도 25a 내지 도 25b는 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스의 정보를 획득하는 과정의 일 예를 개략적으로 도시한 도면이다.
도 25a 내지 도 25b를 참조하면, 도 25a 내지 도 25b에는 보조 디바이스가 "Secondary Smart Device"로, 기본 디바이스가 "Primary Smart Device"로, 서비스 제공자가 "OEM"으로 기재되어 있음에 유의하여야만 할 것이다.
도 25a 내지 도 25b에 도시되어 있는 보조 디바이스의 정보를 획득하는 과정은 보조 디바이스가 포함하는 신뢰되는 실행 환경(trusted execution environment: TEE, 이하 "TEE"라 칭하기로 한다)을 통해 보조 디바이스의 정보를 획득하는 과정임에 유의하여야만 할 것이다.
도 25a 내지 도 25b에서는 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스의 정보를 획득하는 과정의 일 예에 대해서 설명하였으며, 다음으로 도 26a 내지 도 26b를 참조하여 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스의 정보를 획득하는 과정의 다른 예에 대해서 설명하기로 한다.
도 26a 내지 도 26b는 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스의 정보를 획득하는 과정의 다른 예를 개략적으로 도시한 도면이다.
도 26a 내지 도 26b를 참조하면, 도 26a 내지 도 26b에는 보조 디바이스가 "Secondary Smart Device"로, 기본 디바이스가 "Primary Smart Device"로, 서비스 제공자가 "OEM"으로 기재되어 있음에 유의하여야만 할 것이다.
도 26a 내지 도 26b에 도시되어 있는 보조 디바이스의 정보를 획득하는 과정은 TEE를 통해 보조 디바이스의 정보를 획득하고, 디지털 키 공유를 위해 상기 보조 디바이스의 정보를 보증하는 과정임에 유의하여야만 할 것이다.
도 26a 내지 도 26b에서는 본 개시의 일 실시예에 따른 통신 시스템에서 보조 디바이스의 정보를 획득하는 과정의 다른 예에 대해서 설명하였으며, 다음으로 도 27을 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하기로 한다.
도 27은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다.
도 27을 참조하면, 도 27에는 보조 디바이스가 "Client 단말"로, 기본 디바이스가 "Owner 단말"로, 서비스 제공자가 "OEM Server"로 기재되어 있음에 유의하여야만 할 것이다.
먼저, 서비스 제공자와 기본 디바이스간에 공유되고 있는 Credential 정보를 통해 기본 디바이스가 보조 디바이스의 신뢰성을 보증하고, 상기 서비스 제공자로 보조 디바이스의 정보를 등록한다([2],[3]).
상기 서비스 제공자가 생성한 인증용 정보([6])가 기본 디바이스를 통해 보조 디바이스에게 전달되고([7]), 따라서 서비스 제공자와 보조 디바이스간에 인증 동작이 수행되고, 상기 서비스 제공자가 상기 보조 디바이스로 키를 발급한다([9]).
본 개시의 다양한 실시예들에서 사용되는 용어들에 대해서 설명하면 다음과 같다.
(1) 소유자(owner)
소유자는 타겟 디바이스, 일 예로 차량의 소유자로 보안 정보, 일 예로 디지털 키, 일 예로 차량 키의 원래 주인을 나타낸다. 따라서, 소유자의 디바이스(이하, "소유자 디바이스"라 칭하기로 한다)가 기본 디바이스(primary device)가 될 수 있다. 여기서, 상기 기본 디바이스는 보안 정보를 제공 및 관리하는 서비스 제공자, 일 예로 서버, 일 예로 OEM에 의해 이미 인증된 디바이스를 나타내며, 상기 기본 디바이스는 상기 서비스 제공자에 의해 이미 인증되었기 대문에 상기 타겟 디바이스에 대한 보안 정보를 이미 획득하고 있다. 일 예로, 상기 소유자 디바이스는 상기 차량에 대한 디지털 키를 이미 획득하고 있다.
(2) 사용자(user)
사용자는 타겟 디바이스, 일 예로 차량의 소유자는 아니지만 보안 정보, 일 예로 디지털 키, 일 예로 차량 키를 상기 소유자로부터 전달 받아서, 상기 전달받은 차량 키를 사용하여 차량을 사용하는 사용자를 나타낸다. 따라서, 상기 사용자의 디바이스(이하, "사용자 디바이스"라 칭하기로 한다)가 보조 디바이스(primary device)가 될 수 있다. 여기서, 상기 보조 디바이스는 상기 서비스 제공자에 의해 인증되지 않은 디바이스를 나타내며, 상기 기본 디바이스를 통해 상기 서비스 제공자에 등록 및 인증되고, 상기 기본 디바이스와 보안 정보를 공유하는 디바이스를 나타낸다.
(3) 기본 디바이스/소유자 디바이스/소유자 단말
보안 정보를 공유하는 시점에 보안 정보를 저장하고 있는 디바이스를 나타낸다. 상기 기본 디바이스는 소유자 디바이스, 소유자 단말 등과 같은 용어들과 혼용될 수 있다. 여기서, 상기 기본 디바이스는 스마트 디바이스가 될 수 있다.
(4) 보조 디바이스/사용자 디바이스/사용자 단말
보안 정보를 공유하는 시점에 보안 정보를 발급받을 디바이스를 나타낸다. 상기 보조 디바이스는 사용자 디바이스, 사용자 단말 등과 같은 용어들과 혼용될 수 있다. 여기서, 상기 보조 디바이스는 스마트 디바이스가 될 수 있다.
(5) 디지털 키 공유 클라이언트(digital key sharing client: DKSC, 이하 "DKSC"라 칭하기로 한다)
DKSC는 명령(command, 이하 "command"라 칭하기로 한다)들을 개시하고, 디지털 키 공유 서버(digital key sharing server: DKSS, 이하 "DKSS"라 칭하기로 한다)에 대해 요청하고, 상기 DKSS에 의해 송신되는 응답들, 지시들, 통지들을 수신할 수 있는 엔터티를 나타낸다. 본 개시의 다양한 실시예들에서, command를 송신하는 엔터티는 기본 디바이스가 될 수도 있고 보조 디바이스가 될 수도 있다.
(6) DKSS
DKSS는 입력되는 command들을 수락하고, 상기 DKSC로 요청하고, 상기 DKSC로 응답들, 지시들 통지들을 송신하는 디바이스를 나타낸다. 본 개시의 다양한 실시예들에서, command를 수락하는 엔터티는 기본 디바이스가 될 수도 있고 보조 디바이스가 될 수도 있다.
본 개시의 다양한 실시예들에서 사용되는 약어들에 대해서 설명하면 다음과 같다.
(1) APDU: 어플리케이션 프로토콜 데이터 유닛(application protocol data unit)
(2) BT: 블루투스(Bluetooth)
(3) DKS: 디지털 키 공유(digital key sharing)
(4) DKSC: 디지털 키 공유 클라이언트(digital key sharing client)
(5) DKSS: 디지털 키 공유 서버(digital key sharing server)
(6) ISDN: 통합 서비스 디지털 네트워크(integrated services digital network)
(7) IMEI: 국제 이동 단말기 식별자(international mobile equipment identity
(8) MSISDN: 이동국 국제 ISDN 번호(mobile station international ISDN number)
MSISDN 은 GSM(Global System for Mobile Communications) 또는 UMTS(Universal Mobile Telecommunications System) 이동 네트워크에서 가입자 단말기를 식별하는 고유 번호를 나타낸다. 즉, 상기 MSISDN 은 이동 전화 또는 셀룰러 전화에서 가입자 식별 모듈(subscriber identity module: SIM, 이하 "SIM"이라 칭하기로 한다) 카드에 할당되는 전화 번호를 나타낸다.
(9) OTP: 일회성 비밀 번호(one time password)
OTP는 사용자 디바이스 인증을 위해 일회성으로 생성 및 배포되는 비밀 번호를 나타낸다.
(10) P2P: 피어-대-피어(peer to peer)
(11) SDP: 서비스 발견 프로토콜(service discovery protocol)
본 발명의 다양한 실시예들에서 SDP는 일 예로 BT가 될 수 있다.
(12) SE: 보안 엘리먼트(secure element)
SE는 디바이스에 포함되는 보안 저장 장치를 나타낸다.
(13) SEID: SE 식별자(SE identifier)
(14) SHS: 공유 비밀(shared secret)
SHS는 사용자 디바이스 검증에 사용되는 값이며, 서비스 제공자, 일 예로 OEM과 사용자 디바이스 간에서 안전하게 공유되는 정보를 나타낸다.
먼저, 도 28을 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하기로 한다.
도 28은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다.
도 28을 참조하면, 먼저 도 28에 도시되어 있는 디지털 키를 제공하는 과정은 일 예로 디지털 키를 공유하는 과정임에 유의하여야만 할 것이다. 여기서, 키 공유(key sharing) 과정이란 기본 디바이스, 일 예로 소유자 디바이스가 소유하고 있는 보안 정보, 일 예로 디지털 키를 다른 디바이스, 일 예로 보조 디바이스, 일 예로 사용자 디바이스에게 사용할 수 있도록 공유하는 과정을 나타낸다. 본 발명의 다양한 실시예들에서, 기본 디바이스가 소유하고 있는 디지털 키의 포맷과 보조 디바이스에게 발급되는 디지털 키의 포맷은 서버, 일 예로 서비스 제공자, 일 예로 OEM 에 따라 상이할 수도 있고, 이는 상기 OEM의 서비스 방식을 따른다.
또한, 본 발명의 다양한 실시예들에서, 디지털 키의 포맷은 서비스 제공자 별로 고유할 수도 있고, 혹은 모든 서비스 제공자들에 대해 동일할 수도 있다.
또한, 도 28에 도시되어 있는 디지털 키를 제공하는 과정은 일 예로 서비스 제공자를 통한 근접성 트리거-원격 키 공유 프로세스일 수 있으며, 상기 서비스 제공자를 통한 근접성 트리거-원격 키 공유 프로세스는 "proximity triggered remote key sharing via OEM Backend" 라고도 칭해질 수 있다. 또한, 도 28에는 보조 디바이스가 "User"로, 기본 디바이스가 "Owner"로, 서비스 제공자가 "Car OEM Backend"로 도시되어 있음에 유의하여야만 할 것이다.
만약, 보조 디바이스가 기본 디바이스의 근처에 위치할 경우, 보안 정보, 일 예로 디지털 키는 상기 보조 디바이스가 서비스 제공자 혹은 상기 서비스 제공자에서 제공하는 서비스에 등록되어 있지 않을 지라도 상기 보조 디바이스에게 전달되거나 혹은 상기 보조 디바이스와 공유될 수 있다. 이에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 상기 기본 디바이스와 보조 디바이스는 NFC와, 블루투스 등과 같은 근접 연결(proximity connectivity)을 기반으로 연결된다. 즉, 상기 기본 디바이스와 보조 디바이스 간에는 커넥션(connection)이 셋업된다(1. Connection Setup)
이렇게, 상기 기본 디바이스와 보조 디바이스간에 커넥션이 셋업되면, 상기 보조 디바이스의 사용자 정보가 상기 기본 디바이스를 통해 상기 서비스 제공자에 일시적으로 등록된다(2. User Registration).
이렇게, 상기 기본 디바이스를 통해 상기 보조 디바이스의 사용자 정보가 상기 서비스 제공자에 등록된 후, 상기 서비스 제공자는 상기 보조 디바이스가 공유 키의 프로비져닝(provisioning)을 요구할 때 상기 보조 디바이스를 검증한다(3. User Verification).
상기 보조 디바이스에 대한 검증이 성공적일 경우, 상기 서비스 제공자는 디지털 키 서비스 배치 및 키 프로비져닝 프로세스를 기반으로 상기 디지털 키를 상기 보조 디바이스로 전달한다. 상기 디지털 키 서비스 배치 및 키 프로비져닝 프로세스는 일 예로 레가시(legacy) 차량 연결 컨소시엄(car connectivity consortium: CCC, 이하 "CCC"라 칭하기로 한다) 디지털 키 서비스 배치 및 키 프로비져닝 프로세스가 될 수 있으며, 여기서는 상기 디지털 키 서비스 배치 및 키 프로비져닝 프로세스에 대한 구체적인 설명은 생략하기로 한다(4. Key Provisioning).
도 28에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하였으며, 다음으로 도 29a 내지 도 29b를 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 일 예에 대해서 설명하기로 한다.
도 29a 내지 도 29b는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 일 예를 개략적으로 도시한 도면이다.
도 29a 내지 도 29b를 참조하면, 먼저 도 29a 내지 도 29b에 도시되어 있는 보조 디바이스 등록 과정은 보조 디바이스와 상기 보조 디바이스의 사용자 정보를 서비스 제공자에 어떻게 등록하는지를 나타낸다.
또한, 도 29a 내지 도 29b에는 상기 보조 디바이스가 "User Device(DKS Server)"로, 기본 디바이스가 "Owner Device(DKS Client)"로, 상기 서비스 제공자가 "Car OEM Back-End"로 도시되어 있음에 유의하여야만 할 것이다.
먼저, 상기 보조 디바이스는 SE와 Mobile UI를 포함하며, 상기 기본 디바이스는 Mobile UI와 SE를 포함한다. 도 29a 내지 도 29b에서, 설명의 편의상 상기 보조 디바이스에 포함되는 SE와 Mobile UI는 각각 "SE-A" 및 "Mobile UI-A"라 칭하기로 하며, 상기 기본 디바이스에 포함되는 SE와 Mobile UI는 각각 "SE-B" 및 "Mobile UI-B"라 칭하기로 한다. 또한, 상기 Mobile UI-A 및 상기 Mobile UI-B는 각각 상기 SE-A 및 상기 SE-B에 억세스할 수 있다. 즉, Mobile UI는 다른 디바이스와의 P2P 통신을 가능하게 하고, SE에 억세스할 수 있는 엔터티를 나타낸다.
먼저, 상기 Mobile UI-B가 활성화되며(Activation of Owner Mobile UI), 이에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 어플리케이션 시작 및 루팅 체크(rooting check) 등에 의해 상기 Mobile UI-B가 실행되며(a. Start app and rooting check), 키 전달하기/키 공유하기 등과 같은 메뉴가 선택된다(b. Select "To share my Key). 상기 어플리케이션 루팅 체크는 서비스 개발에 따라 어플리케이션의 실행시에 수행되거나 혹은 특정 기능이 필요로 될 때 수행될 수 있다.
또한, 상기 Mobile UI-B의 제공자 또는 서비스 제공자의 서비스 정책에 따라 필요할 경우 사용자 인증(user authentication) 프로세스가 수행될 수 있으며(c. User Authentication), 상기 사용자 인증 프로세스는 상기 기본 디바이스에 미리 등록되어 있는 개인 식별 번호(personal identification number: PIN, 이하 "PIN"이라 칭하기로 한다)를 기반으로 수행될 수 있거나, 혹은 생체 인식 등을 기반으로 수행될 수 있다.그리고 나서 상기 Mobile UI-B는 NFC P2P 모드로 그 동작을 시작한다(d. Start NFC P2P operation).
한편, 상기 Mobile UI-B의 활성화 프로세스에서 루팅 체크를 제외한 나머지 동작들은 선택적(optional)일 수 있으며, 상기 Mobile UI-B의 제공자의 구현에 따라 수행될 수도 있고 혹은 생략될 수도 있다. 또한, 상기 Mobile UI-B는 하나 혹은 그 이상의 어플리케이션 루팅 체크 메카니즘을 지원한다(Mobile UI shall support one or more app rooting check mechanism).
또한, 상기 Mobile UI-A가 활성화되며(Activation of User Mobile UI), 이에 대해서 구체적으로 설명하면 다음과 같다. 도 29a 내지 도 29b에서는 상기 보조 디바이스가 적어도 하나의 Mobile UI를 설치했다고 가정된 것임에 유의하여야만 한다.
먼저, 어플리케이션 시작 및 루팅 체크 등에 의해 상기 Mobile UI-A가 실행되며(a. Start app and rooting check), 키 수신하기 등과 같은 메뉴가 선택된다(b. Select "to have shared key). 상기 어플리케이션 루팅 체크는 서비스 개발에 따라 어플리케이션의 실행시에 수행되거나 혹은 특정 기능이 필요로 될 때 수행될 수 있다.
또한, 상기 Mobile UI-A는 NFC P2P 모드로 그 동작을 시작한다(c. Start NFC P2P operation).
한편, 상기 Mobile UI-A의 활성화 프로세스에서 루팅 체크를 제외한 나머지 동작들은 선택적일 수 있으며, 상기 Mobile UI-A의 제공자의 구현에 따라 수행될 수도 있고 혹은 생략될 수도 있다. 또한, 상기 Mobile UI-A는 하나 혹은 그 이상의 어플리케이션 루팅 체크 메카니즘을 지원한다(Mobile UI shall support one or more app rooting check mechanism)
그리고 나서, 상기 보조 디바이스와 기본 디바이스간에는 NFC 에서 BT 혹은 와이-파이(WiFi, 이하 "WiFi"라 칭하기로 한다) 등과 같은, 즉 상기 NFC에 비해 비교적 커버리지(coverage)가 넓은 블루투스 혹은 와이-파이 등으로의 핸드오버가 수행된다 (NFC Handover to a Bluetooth). 이에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 상기 Mobile UI-B는 상기 Mobile UI-A로 NFC에서 블루투스로 핸드오버할 것을 요청하는 메시지, 일 예로 핸드오버 요청(handover request) 메시지(이하, "handover request 메시지"라 칭하기로 한다)를 송신한다([01] Handover Request (BT)). 상기 Mobile UI-B로부터 handover request 메시지를 수신한 Mobile UI-A는 블루투스로 핸드오버하기로 선택한 후, 상기 Mobile UI-B로 핸드오버하기로 선택하였음을 나타내는 메시지, 일 예로 핸드오버 선택(handover select) 메시지(이하, "handover select 메시지"라 칭하기로 한다)를 송신한다([02]Handover Select (BT)). 즉, 상기 기본 디바이스는 핸드오버 요청자(handover requester)가 되고, 상기 보조 디바이스는 핸드오버 선택자(handover selector)가 된다. 또한, 상기 NFC에서 블루투스로의 핸드오버 동작에 대한 보다 구체적인 사항들은 NFC 커넥션 핸드오버 기술 규격(NFC Connection Handover Technical Specification [xx]) 및 블루투스 보안 심플 페어링 규격(Bluetooth Secure Simple Pairing specification [xx])에서 설명되고 있는 바와 동일함에 유의하여야만 할 것이다.
또한, 범용 고유 식별자(universally unique identifier: UUID, 이하 "UUID"라 칭하기로 한다)로 일 예로 "3cbb4363-dd09-4856-94e4-416605fa8fcb" 이 핸드오버시 사용될 것이다.
상기한 바와 같은 handover request 메시지 및 handover select 메시지 교환에 따라 상기 Mobile UI-B와 Mobile UI-A 간에는 블루투스 커넥션이 성립된다([03] Bluetooth Connection Establishment).
이렇게, 상기 Mobile UI-B와 Mobile UI-A 간에 블루투스 커넥션이 성립됨에 따라 상기 보조 디바이스와, 기본 디바이스와, 서비스 제공자간에는 블루투스 커넥션을 통한 통신이 수행된다(Communication through Bluetooth Connection).
상기 Mobile UI-B는 상기 서비스 제공자로 근접성 트리거링 키 공유를 개시할 것임을 나타내는, 즉 근접 터치를 기반으로 하는 키 공유 프로세스(key sharing process)가 개시됨을 나타내는 메시지, 일 예로 근접성 트리거링 키 공유 개시(proximity triggering key sharing initiation) 메시지(이하, "proximity triggering key sharing initiation 메시지"라 칭하기로 한다)를 송신한다([04] Proximity Triggering Key Sharing initiation). 상기 Mobile UI-B와 서비스 제공자간의 인터페이스는 다양한 형태들로 구현될 수 있으며, 여기서는 그 상세한 설명을 생략하기로 한다.
상기 Mobile UI-B로부터 proximity triggering key sharing initiation 메시지를 수신한 서비스 제공자는 랜덤(random) 변수인 넌스(nonce, 이하 "nonce" 라 칭하기로 한다)를 생성한다. 여기서, 상기 nonce는 상기 보조 디바이스의 정보를 수신 및 검증할 때 사용되는데, 이는 상기 보조 디바이스의 정보를 생성할 때 nonce를 사용함으로써, 상기 보조 디바이스의 정보가 재사용되는 것을 방지하기 위함이다. 또한, 상기 nonce는 키 공유 프로세스가 시작될 때 마다 새롭게 생성되며, 이로 인해 보조 디바이스에 대해 고유한 정보가 생성될 수 있다.
또한, 도 29a 내지 도 29b에서는 상기 nonce가 상기 서비스 제공자에서 생성된다고 가정하지만, 상기 nonce는 기본 디바이스에서 생성될 수 있다. 상기 nonce가 상기 기본 디바이스에서 생성될 경우, 하기에서 설명될 [8] 동작에서 상기 기본 디바이스가 생성한 nonce를 상기 서비스 제공자에게 송신하여 상기 서비스 제공자가 상기 기본 디바이스가 생성한 nonce 를 기반으로 상기 보조 디바이스를 검증하는 것을 가능하게 한다.
한편, 상기 서비스 제공자는 상기 기본 디바이스로 상기 서비스 제공자에 등록할 보조 디바이스의 사용자 정보를 요청하는 메시지, 일 예로 사용자 정보 요청(user information request) 메시지(이하 "user information request 메시지"라 칭하기로 한다)를 송신한다([05] User Information Request(Nonce)). 여기서, 상기 user information request 메시지는 상기 서비스 제공자에 의해 생성된 nonce를 포함한다.
상기 서비스 제공자로부터 user information request 메시지를 수신한 기본 디바이스의 Mobile UI-B는 상기 보조 디바이스의 Mobile UI-A로 상기 서비스 제공자에 등록할 보조 디바이스의 사용자 정보를 요청하는 메시지, 일 예로 사용자 정보 획득 요청(get user information request) 메시지(이하, "get user information request 메시지"라 칭하기로 한다)를 송신한다([06] Get User Information Request(Nonce)). 여기서, 상기 get user information request 메시지는 상기 user information request 메시지에 포함되어 있는 nonce를 포함한다.
상기 Mobile UI-B로부터 get user information request 메시지를 수신한 Mobile UI-A는 상기 서비스 제공자에 등록할 사용자 정보, 일 예로 어플리케이션 파라미터(application parameter)들을 생성하는 사용자 정보 생성 동작을 수행한다(Generation of User Information). 여기서, 상기 사용자 정보는 다음과 같은 어플리케이션 파라미터들을 포함할 수 있다.
(1) ID정보
상기 ID 정보는 MSISDN과, SE ID 등을 포함할 수 있다. 또한, 상기 ID 정보는 SE Issuer 정보, 어플리케이션 버전(App version), IMEI, 상기 보조 디바이스가 포함하는 SE에 대한 인증서, 상기 보조 디바이스의 디바이스 모델 명, 디바이스 제조사 명, 디바이스 일련 번호(serial number: S/N, 이하 "S/N" 이라 칭하기로 한다) 등을 추가적으로 포함할 수 있다.
(2) 기본 디바이스의 출력 디바이스, 일 예로 스크린(screen)에 출력될 정보
상기 기본 디바이스의 출력 디바이스에 출력될 정보는 일 예로 상기 보조 디바이스의 전화 번호, 상기 보조 디바이스의 디바이스 모델, 상기 보조 디바이스의 명칭, 운영 시스템(operating system: OS, 이하 "OS" 라 칭하기로 한다)에 등록된 계정/상기 보조 디바이스의 별명 등을 포함할 수 있다.
(3) 공중/사설 키 페어(public/private key pair, 이하 "public/private key pair"라 칭하기로 한다)(U.Kpub, U.Kpriv))
상기 U.Kpub는 상기 보조 디바이스, 즉 사용자 디바이스에 의해 생성된 공중 키를 나타내며, 상기 U.Kpriv는 상기 보조 디바이스, 즉 사용자 디바이스에 의해 생성된 사설 키를 나타낸다.
(4) 키 핸들(key handle)
상기 키 핸들은 상기 public/private key pair에 대한 ID를 나타낸다.
(5) 사용자 서명(user signature) Uinfo.Signature
상기 사용자 서명 Uinfo.Signature은 상기 ID정보와, 상기 기본 디바이스의 출력 디바이스에 출력될 정보와, 공중 키U.Kpub와, key handle과 nonce값을 입력 파라미터로 하고, 사설 키U.Kpriv을 이용하여 생성된다. 여기서, 상기 ID정보와, 상기 기본 디바이스의 출력 디바이스에 출력될 정보와, 공중 키U.Kpub와, key handle과, nonce값 및 사설 키U.Kpriv를 기반으로 상기 사용자 서명 Uinfo.Signature을 생성하는 방식은 다양한 형태들로 구현될 수 있으며, 이에 대한 구체적인 설명은 생략하기로 한다.
상기 사용자 정보 생성 동작을 수행한 후, 상기 Mobile UI-A는 상기 Mobile UI-B로 상기 get user information request에 대한 응답 메시지, 일 예로 사용자 정보 획득 응답(get user information response) 메시지(이하, "get user information response 메시지"라 칭하기로 한다)를 송신한다([07] Get User Information Response(Application params)). 여기서, 상기 get user information response 메시지는 상기 Mobile UI-A가 생성한 상기 보조 디바이스의 사용자 정보, 즉 어플리케이션 파라미터들을 포함한다.
상기 Mobile UI-A로부터 get user information response 메시지를 수신한 Mobile UI-B는 사전 확인(pre-confirmation) 동작을 수행한다(Owner Pre-Confirmation). 여기서, 상기 사전 확인 동작에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 상기 Mobile UI-B는 Mobile UI-A로부터 수신한 공중키 U.Kpub을 사용하여 Uinfo.Signature를 검증한다(a. User Smart Device Signature Verification).
상기 Uinfo.Signature에 대한 검증이 성공적인 경우, 상기 Mobile UI-B는 상기 기본 디바이스에 포함되어 있는 출력 디바이스, 일 예로 스크린에 상기 보조 디바이스의 사용자 정보를 출력한다(b. Display Displayable UserInfo). 이렇게, 상기 출력 디바이스에 상기 보조 디바이스의 사용자 정보를 출력하는 이유는 상기 보조 디바이스의 사용자 정보에 대해 확인받기 위함이며, 이런 확인은 일 예로 상기 기본 디바이스의 사용자의 개입에 따른 이벤트 발생, 일 예로 확인 버튼 터치, 혹은 지문 검사 등과 같은 이벤트 발생에 따라 이루어질 수 있다. 상기 출력 디바이스에 출력되어 있는, 상기 보조 디바이스의 사용자 정보가 확인됨을 검출하면(c. Get Owner consent (confirm button, fingerprint checking, etc.)), 상기 Mobile UI-B는 상기 기본 디바이스에 저장되어 있는 디지털 키y또는 상기 디지털 키에 준하는 권한을 가지는 키 를 사용하여 상기 보조 디바이스의 사용자 정보에 서명한다(Signature on User Info using Owner's Digital Key). 상기 Mobile UI-B가 상기 SE-B에 저장되어 있는 디지털 키를 직접 사용할 경우, 디지털 키 서명(digital key signature)를 위한 APDU를 사용한다. 상기 디지털 키 서명을 위한 APDU는 하기에서 도 32를 참조하여 구체적으로 설명할 것이므로, 여기서는 그 상세한 설명을 생략하기로 한다.
한편, 상기 사전 확인 동작을 수행한 후 Mobile UI-B는 상기 서비스 제공자로 상기 user information request 메시지에 대한 응답 메시지, 일 예로 사용자 정보 응답(user information response) 메시지(이하 "user information response 메시지"라 칭하기로 한다)를 송신한다([08] User Information Response (User Info, DK signature). 여기서, 상기 user information response 메시지는 상기 보조 디바이스로부터 수신한 사용자 정보와 상기 기본 디바이스의 디지털 키 서명을 포함한다. 상기 Mobile UI-B로부터 user information response 메시지를 수신한 서비스 제공자는 사용자 디바이스 검증 동작 및 보조 디바이스 등록 동작을 수행한다( Owner Verification and User enrollment). 여기서, 상기 사용자 디바이스 검증 동작 및 보조 디바이스 등록 동작에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 상기 서비스 제공자는 상기 기본 디바이스의 디지털 키 서명에 대한 검증 동작을 수행한다(a. Owner Digital Key signature verification). 즉 상기 서비스 제공자는 상기 기본 디바이스의 디지털 키 서명에 대한 검증 동작을 수행하여 상기 기본 디바이스가 실제 디지털 키를 소유하는 소유자 디바이스인지, 그리고 상기 기본 디바이스가 적합한 권한을 가지고 있는지 검사한다.
상기 기본 디바이스의 디지털 키 서명에 대한 검증 결과가 성공을 나타낼 경우, 상기 서비스 제공자는 상기 기본 디바이스로부터 수신하고, 상기 디지털 키로 서명된 상기 보조 디바이스의 사용자 정보를 등록, 즉 저장한다(b. User Information enrollment).
여기서, 상기 보조 디바이스의 사용자 정보는 상기에서 설명한 바와 같이 상기 보조 디바이스가 포함하는 SE, 즉 SE-A의 SE ID와, MSISDN와, U.Kpub, key handle등을 포함할 수 있다.
그리고 나서, 상기 서비스 제공자는 상기 서비스 제공자와 상기 보조 디바이스가 공유할 공유 비밀(shared secret: SHS, 이하 "SHS"라 칭하기로 한다)을 생성하고, 상기 SHS를 상기 보조 디바이스의 공중 키로 암호화하여 OTP를 생성한다(c. Generate sharing OTP = enc (U.Kpub, SHS).
상기 SHS 는 이후의 절차에서 상기 보조 디바이스를 검증하는데 사용되는 값이다. 즉, 상기 서비스 제공자는 상기 보조 디바이스가 상기 SHS를 가지고 있는지 확인한다.
여기서, 상기 서비스 제공자가 OTP를 생성하는 이유는, 상기 서비스 제공자가 해당 정보, 일 예로 디지털 키를 기본 디바이스를 통해서 상기 보조 디바이스로 전달하는 데, 상기 보조 디바이스 외에는 다른 어떤 디바이스도 상기 OTP를 해독하여 SHS를 확보할 수 없도록 하기 위함이다.
한편, 상기 사용자 디바이스 검증 동작 및 보조 디바이스 등록 동작을 수행한 후 상기 서비스 제공자는 상기 Mobile UI-B로 사용자 등록 결과를 사용자 등록 결과(user registration result) 메시지(이하, "user registration result 메시지"라 칭하기로 한다)를 송신한다([09] User Registration Result (Sharing OTP). 상기 보조 디바이스의 사용자 정보가 정상적으로 등록된 경우, 상기 user registration result 메시지는 공유 OTP(sharingOTP, 이하 "sharingOTP"라 칭하기로 한다)를 포함한다. 여기서, 상기 sharingOTP는 상기 서비스 제공자가 생성한 OTP를 나타낸다.
상기 서비스 제공자로부터 user registration result 메시지를 수신한 Mobile UI-B는 상기 Mobile UI-A로 상기 서비스 제공자로부터 수신한 SharingOTP를 그대로 전달한다([10] Push SharingOTP Request(SharingOTP)). 즉, 상기 Mobile UI-B는 상기 Mobile UI-A로 SharingOTP 푸쉬 요청(push SharingOTP request) 메시지(이하, "push SharingOTP request 메시지"라 칭하기로 한다)를 통해 상기 SharingOTP를 전달한다. 상기 Mobile UI-B로부터 push SharingOTP request 메시지를 수신한 Mobile UI-A는 상기 SharingOTP를 저장하고, 상기 Mobile UI-A로 상기 push SharingOTP request 메시지에 대한 응답 메시지, 일 예로 SharingOTP 푸쉬 응답(push SharingOTP response) 메시지(이하, "push SharingOTP response 메시지"라 칭하기로 한다)를 송신한다([11] Push SharingOTP Response()). 상기 Push SharingOTP Response 메시지를 송신한 후 상기 Mobile UI-A는 SHS 획득 동작을 수행한다(Acquisition of SHS). 여기서, 상기 SHS 획득 동작에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 상기 Mobile UI-A는 상기 보조 디바이스의 사설 키인 U.KPriv 를 이용하여 SharingOTP를 복호하고, 상기 SharingOTP를 사용하여 SHS를 획득한다(User Mobile UI calculates SHS from Sharing OTP and U.Kpriv).
도 29a 내지 도 29b에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 일 예에 대해서 설명하였으며, 다음으로 도 30a 내지 도 30b를 사용하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 검증 과정의 일 예에 대해서 설명하기로 한다.
도 30a 내지 도 30b는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 검증 과정의 일 예를 개략적으로 도시한 도면이다.도 30a 내지 도 30b를 참조하면, 먼저 도 30a 내지 도 30b에 도시되어 있는 보조 디바이스 검증 과정은 보조 디바이스에 대해 디지털 키를 발급하기 전에 상기 보조 디바이스가 SHS를 소유하고 있는지 검사하고, 기본 디바이스를 통해 상기 보조 디바이스를 확인한 후 상기 보조 디바이스에게 디지털 키를 공유하기 위한 보조 디바이스 검증 과정임에 유의하여야만 할 것이다.
또한, 도 30a 내지 도 30b에는 상기 보조 디바이스가 "User Device(DKS Server)"로, 기본 디바이스가 "Owner Device(DKS Client)"로, 서비스 제공자가 "Car OEM Back-End"로 도시되어 있음에 유의하여야만 할 것이다. 또한, 상기 보조 디바이스는 SE와 Mobile UI를 포함하며, 상기 기본 디바이스는 Mobile UI와 SE를 포함한다.
도 30a 내지 도 30b에서, 설명의 편의상 상기 보조 디바이스에 포함되는 SE와 Mobile UI는 각각 "SE-A" 및 "Mobile UI-A"라 칭하기로 하며, 상기 기본 디바이스에 포함되는 SE와 Mobile UI는 각각 "SE-B" 및 "Mobile UI-B"라 칭하기로 한다.
먼저, SHS를 획득한 보조 디바이스가 포함하는 Mobile UI-A는 서비스 제공자로 디지털 키를 공유하는 서비스인 키 공유(key sharing) 서비스(이하, "key sharing 서비스"라 칭하기로 한다)를 신청한다([12] Key Sharing triggering by User (Key Handle)). 즉, 상기 Mobile UI-A는 상기 서비스 제공자로 key sharing 서비스를 요청하는 키 공유 트리거링(key sharing triggering) 메시지(이하, "key sharing triggering 메시지"라 칭하기로 한다)를 송신한다. 여기서, 상기 key sharing triggering 메시지는 key handle을 포함한다.
상기 서비스 제공자는 상기 key sharing triggering 메시지에 포함되어 있는 key handle을 통해, 어떤 보조 디바이스가 key sharing 서비스를 요청하는지 알 수 있다.
또한, 상기 서비스 제공자가 key sharing 서비스를 요청하는 보조 디바이스를 보다 명확하게 식별하도록 하기 위해 상기 key sharing triggering 메시지는 MSISDN와, SE ID와, IMEI 등을 추가적으로 포함할 수 있다.
상기 Mobile UI-A로부터 key sharing triggering 메시지를 수신한 서비스 제공자는 상기 Mobile UI-A로 사용자 검증을 요청한다([13] User Verification Request(Challenge). 일 예로, 상기 서비스 제공자는 사용자 검증 요청(user verification request) 메시지(이하, "user verification request"라 칭하기로 한다) 를 송신하여 사용자 검증을 요청할 수 있으며, 상기 user verification request 메시지는 챌린지(challenge, 이하 "challenge"라 칭하기로 한다)를 포함한다.
만일, 상기 보조 디바이스가 상기 challenge를 사용하여 상기 서비스 제공자가 예상하는 답변, 즉 챌린지 응답(challenge response, 이하 "challenge response"라 칭하기로 한다)을 생성한 후 상기 서비스 제공자에게 상기 challenge response 를 송신한다면, 상기 서비스 제공자는 상기 보조 디바이스가 정상적으로 검증되었다고 판단할 수 있다.
상기에서는 1개의 challenge가 고려되었으나, 기본 디바이스를 위한 challenge와 보조 디바이스를 위한 challenge가 별도로 구현될 수도 있음은 물론이다.
도 30a 내지 도 30b에서는 1개의 challenge가 사용되고, 1개의 challenge에 대하여 사용자 디바이스와 기본 디바이스가 각각 challenge response를 작성하는 경우를 가정하기로 한다.
한편, 상기 서비스 제공자로부터 user verification request 메시지를 수신한 Mobile UI-A 는 challenge response를 계산한다(Calculates User Challenge Response). 여기서, 상기 보조 디바이스에 의해 생성되는 challenge response를 "사용자 challenge response(user challenge response)"라고 칭하기로 한다.
여기서, 상기 challenge response는 SHS와 challenge를 사용하여 challenge response 를 계산한다. 본 개시의 다양한 실시예들에서, challenge response는 "cRes" 라고도 칭해질 수 있다.
또한, 상기 Mobile UI-A 는 challenge response를 상기 보조 디바이스 의 사설 키인 U.Kpriv으로 서명하여 서명서를 생성할 수도 있다.
이후, 상기 보조 디바이스와, 기본 디바이스 및 서비스 제공자간에는 기본 디바이스 최종 확인 동작이 수행된다(Owner final Confirmation). 상기 기본 디바이스 최종 확인 동작에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 상기 서비스 제공자는 상기 기본 디바이스 최종 확인 동작을 트리거링한다([14] Owner confirmation triggering((opt) Challenge)). 여기서, 상기 서비스 제공자는 소유자 확인 트리거링(owner confirmation triggering) 메시지(이하, "owner confirmation triggering 메시지"라 칭하기로 한다)를 송신함으로써 상기 기본 디바이스 최종 확인 동작을 트리거링한다.
상기 owner confirmation triggering 메시지는 상기 서비스 제공자가 상기 기본 디바이스에게 송신한 challenge를 포함할 수도 있다.
상기 owner confirmation triggering 메시지에 포함되는 challenge는 하기의 [16] 동작에서 보조 디바이스를 통해서 수신되는 challenge와 비교되며, 이런 비교 동작을 통해 보안이 강화될 수 있다.
상기 서비스 제공자로부터 owner confirmation triggering 메시지를 수신한 Mobile UI-B는 상기 Mobile UI-A로 challenge 값을 요청한다([15] Get Owner Challenge Request). 여기서, 상기 Mobile UI-B는 일 예로 소유자 챌린지 획득 요청(get owner challenge request) 메시지(이하, "get owner challenge request 메시지"라 칭하기로 한다)를 통해 Mobile UI-A로 challenge 값을 요청할 수 있다.
상기 Mobile UI-B로부터 get owner challenge request 메시지를 수신한 Mobile UI- A 는 상기 get owner challenge request 메시지에 대한 응답 메시지, 일 예로 소유자 챌린지 획득 응답(get owner challenge response) 메시지(이하, "get owner challenge response 메시지"라 칭하기로 한다)를 상기 Mobile UI-B로 송신한다([16] Get Owner Challenge Response(Challenge)). 여기서, 상기 get owner challenge response 메시지는 다음과 같은 파라미터들을 포함한다.
1) 상기 Mobile UI-A가 생성한 challenge response (cRes),
2) 상기 서비스 제공자로부터 수신한 challenge (만약, [13] 동작에서 기본 디바이스용 challenge가 별도로 존재할 경우 상기 Mobile UI-A는 상기 get owner challenge response 메시지에 상기 서비스 제공자로부터 수신한 challenge가 아니라 상기 기본 디바이스용 challenge를 포함한다)상기 Mobile UI-A로부터 get owner challenge response 메시지를 수신한 Mobile UI-B는 기본 디바이스의 challenge 를 계산하는 소유자 challenge 계산 동작을 수행한다(Calculate Owner Challenge). 여기서, 상기 소유자 challenge 계산 동작에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 상기 Mobile UI-B는 상기 서비스 제공자로부터 challenge를 수신하였을 경우 상기 서비스 제공자로부터 수신한 challenge와 상기 get owner challenge response 메시지에 포함되어 있는 challenge를 비교한다(a. [opt] Compare Challenges if Challenge value is also given form Car OEM).
그리고 나서, 상기 Mobile UI-B는 상기 보조 디바이스에 대한 사용자 정보가 저장되어 있을 경우, 최종 확인을 위해 상기 기본 디바이스의 출력 디바이스, 일 예로 스크린에 출력한다.(b. [opt] Display Displayable UserInfo If present).
상기 사용자 정보가 암호화되어 있을 경우, 상기 Mobile UI-B는 상기 사용자 정보를 상기 기본 디바이스의 사설 키로 복호하고, 복호된 사용자 정보를 상기 출력 디바이스, 일 예로 스크린에 출력준다.
만일 스크린에 출력, 즉 디스플레이되 사용자 정보가 도 29a 내지 도 29b에서 설명한 바와 같은 사전 확인 동작(Owner pre-confirmation)에서의 사용자 정보와 다를 경우, 중간자 공격(man in the middle attack) 등과 같은 보안 공격이 발행하였다고 예상할 수 있으므로, 상기 보조 디바이스에 대한 공유키 발급을 방지 할 수 있다.
한편, 상기 확인 사항에 대한 최종 확인을 검출하면, 상기 Mobile UI-B는 상기 기본 디바이스에 저장되어 있는 디지털 키 또는 상기 디지털 키에 준하는 권한을 가진 키를 이용하여 상기 보조 디바이스의 사용자 정보에 대해 최종 확인한다.
여기서, 상기 최종 확인은 상기 기본 디바이스의 challenge response (oRes) 형태로 생성되며, 상기 보조 디바이스를 통해 상기 서비스 제공자에게 전달되고, 상기 서비스 제공자가 상기 challenge response (oRes)를 검증한다.
여기서, 상기 oRes, 즉 기본 디바이스의 challenge response는 challenge, cRes, 디지털 키(혹은, 상기 디지털 키에 준하는 권한을 가진 키)를 사용하여 생성된다.
상기 Mobile UI-B가 SE- B에 저장되어 있는 디지털 키를 직접 사용할 경우, 디지털 키 서명을위한 APDU를 사용하여 challenge와 사용자 정보에 서명을 하여 상기 기본 디바이스의 challenge response (oRes)를 생성한다(Sign(Challenge, Digital Key, cRes)). 여기서, 상기 디지털 서명은 하기에서 도 32를 참조하여 구체적으로 설명할 것이므로 여기서는 그 상세한 설명을 생략하기로 한다.
상기 challenge response (oRes)는 서명이 아닌 hash 함수 등의 방법으로 생성될 수도 있는데, 이때 challenge와 사용자 정보, 디지털 키 모두 hash 함수의 입력 파라미터로 고려하여 소유자 challenge 결과(OwneChallengeResult)를 생성한다(Hash(Challenge, Digital Key, cRes)).
그리고 나서, 상기 Mobile UI-B는 상기 생성된 OwnerChallengeResult를 Mobile UI-A로 송신한다([17] Set Challenge Result Request (OwnerChallengeResult)). 여기서, 상기 Mobile UI-B는 일 예로 challenge 결과 설정 요청(set challenge result request) 메시지(이하 "set challenge result request 메시지"라 칭하기로 한다)를 통해 상기 생성된 OwnerChallengeResult를 상기 Mobile UI-A로 송신한다.
상기 Mobile UI-B로부터 set challenge result request 메시지를 수신한 Mobile UI-A는 상기 Mobile UI-B로 상기 set challenge result request 메시지에 대한 응답 메시지, 일 예로 challenge 결과 설정 응답(set challenge result response) 메시지(이하, "set challenge result response 메시지"라 칭하기로 한다)를 송신한다([18] Set Challenge Result Response()). 여기서, 상기 set challenge result response 메시지는 상기 Mobile UI-A가 직접 생성한 Challenge Response (cRes)와 상기 Mobile UI-B로부터 수신한 확인, 즉 challenge response (oRes)를 포함한다. 여기서, 상기 challenge response (oRes)가 상기 보조 디바이스에 저장되어 있지 않다면, 상기 set challenge result response 메시지는 상기 challenge response (oRes)를 포함하지 않는다.
그리고 나서, 상기 Mobile UI-A는 challenge response (oRes)를 상기 set challenge result request 메시지를 통해 수신한 OwnerChallengeResult로 설정한다(oRes = OwnerChallengeResult).
상기에서 설명한 바와 같이 기본 디바이스 최종 확인 동작이 수행된 후, 상기 Mobile UI-A는 상기 서비스 제공자로 상기 user verification request 메시지에 대한 응답 메시지, 일 예로 사용자 검증 응답 메시지(이하, "user verification response 메시지")를 송신한다([19] User Verification Response(cRes, [opt] oRes)). 여기서, 상기 user verification response 메시지는 상기 Mobile UI-A가 생성한 challenge response (cRes)와 상기 Mobile UI-B로부터 수신한 challenge response(oRes)를 포함한다. 여기서, 상기 challenge response(oRes)가 존재하지 않을 경우 상기 user verification response 메시지는 상기 Mobile UI-A가 생성한 challenge response(cRes)만을 포함할 수도 있음은 물론이다.
상기 Mobile UI-A로부터 user verification response 메시지를 수신한 서비스 제공자는 보조 디바이스에 대한 검증 동작을 수행한다(User Verification). 여기서, 상기 보조 디바이스에 대한 검증 동작에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 상기 Mobile UI-A로부터 user verification response 메시지를 수신한 서비스 제공자는 상기 user verification response 메시지에 포함되어 있는 challenge response 들, 즉 cRes 및 oRes에 대한 검증 동작을 수행한다(a. cRes verification; b. [opt] oRes verification). 상기 cRes 및 oRes에 대한 검증 결과가 성공적임을 나타낼 경우, 상기 서비스 제공자는 상기 보조 디바이스에게 디지털 키를 발급한다. 즉, 상기 서비스 제공자와 보조 디바이스간에는 CCC 프로세스에 따라 디지털 키 프로비져닝(provisioning) 프로세스가 진행된다([20] Digital Key Provisioning according to CCC general process).
그리고 나서, 상기 보조 디바이스에 대한 검증 결과가 성공적임을 나타낼 경우, 상기 서비스 제공자는 상기 보조 디바이스에게 디지털 키를 발급한다. 즉, 상기 서비스 제공자와 보조 디바이스간에는 CCC 프로세스에 따라 디지털 키 프로비져닝(provisioning) 프로세스가 진행된다([20] Digital Key Provisioning according to CCC general process).
그리고 나서, 상기 서비스 제공자는 상기 보조 디바이스에 대한 디지털 키 발급 결과를 나타내는 메시지를 상기 기본 디바이스로 송신하여 상기 기본 디바이스가 상기 보조 디바이스에게 디지털 키가 발급되었음을 인지할 수 있도록 할 수 있다([21] Notice of Client Digital Key provisioning result).
도 30a 내지 도 30b에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 검증 과정의 일 예에 대해서 설명하였으며, 다음으로 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키 공유 서비스를 위한 블루투스 구성(Bluetooth configuration)들에 대해서 설명하기로 한다.
먼저, 도 31을 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키 공유 서비스를 위한 프로토콜 스택(protocol stack)의 구조에 대해서 설명하기로 한다.
도 31은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키 공유 서비스를 위한 프로토콜 스택의 구조를 개략적으로 도시한 도면이다.
도 31을 참조하면, 기저 대역(Baseband) 계층과, 링크 관리자 프로토콜(link manager protocol: LMP, 이하 "LMP"라 칭하기로 한다) 계층 및 논리 링크 제어 및 적응 프로토콜(logical link control and adaptation protocol: L2CAP, 이하 "L2CAP"라 칭하기로 한다) 계층은 블루투스 프로토콜의 물리 및 데이터 링크 계층들이다. 또한, 무선 주파수 통신(radio frequencty communication: RFCOMM, 이하 "RFCOMM"라 칭하기로 한다) 계층은 블루투스 직렬 포트 에뮬레이션 엔터티(Bluetooth serial port emulation entity)이다. 또한, 서비스 발견 프로토콜(service discovery protocol: SDP, 이하 "SDP"라 칭하기로 한다) 계층은 블루투스 서비스 발견 프로토콜 계층이다.
또한, 상기 디지털 키 공유 서비스는 일 예로 디지털 키 공유 서비스 UUID로 오픈(open)된 클라이언트와 서버간의 underlying 오브젝션 교환(objection exchange: OBEX, 이하 "OBEX"라 칭하기로 한다) 세션으로 정의될 수 있다..
또한, 상기 프로토콜 스택에서 구성 및 역할(role)들에 대해서 설명하면 다음과 같다.
먼저, DKSC는 DKSS로 오브젝트들을 푸쉬(push) 및 풀(pull)하고, 또한 상기 DKSS로부터 오브젝트들을 푸쉬 및 풀하는 동작을 개시한다. 본 개시의 다양한 실시예들에서는 일 예로 기본 디바이스, 즉 소유자 디바이스가 DKSC의 역할을 할 수 있다.
또한, DKSS는 오브젝트 교환 서버(object exchange server)를 제공하는 타겟 블루투스 디바이스이며, 본 개시의 다양한 실시예들에서 일 예로 보조 디바이스, 즉 사용자 디바이스가 DKSS의 역할을 할 수 있다.
또한, 디지털 키 공유 서비스 UUID, 즉 디지털 키 공유 서비스를 위해 사용되는 UUID는 일 예로 "3cbb4363-dd09-4856-94e4-416605fa8fcb"가 될 수 있다.
본 개시의 다양한 실시예들에서, 상기 디지털 키 공유 서비스 UUID는 블루투스 특정 관심 그룹(special interest group: BT SIG)으로부터 16-비트 고유 UUID(16-bit unique UUID)를 획득하는 것을 고려할 수 있다.
또한, 블루투스 보안(Bluetooth security)에 대해서 설명하면 다음과 같다.
먼저, 2개의 디바이스들이 제너릭 억세스 프로파일(Generic Access Profile)에서 설명되는 인증 절차를 사용하여 보안 커넥션을 생성할 수 있다. 상기 디지털 키 공유 서비스는 다음과 같은 블루투스 보안 특징들을 부여할 수 있다. (The two devices shall create a secure connection using the authentication procedure described in the Generic Access Profile [11]. The Digital Key Sharing service mandates the use of several Bluetooth security features:)
(1) 본딩(bonding)
DKSC 및 DKSS는 디지털 키 서비스 커넥션을 셋업하기 전에 결합(bond)될 수 있다. 보안 모드(eecurity mode) 4는 상기 DKSC 및 DKSS 둘 다에 의해 지원될 경우 사용될 수 있다. 아웃-오브-밴드(out-of-band) (NFC) 모델을 사용하는 보안 간단 페어링(secure simple pairing)이 적용될 수 있다. (The DKSC and DKSS shall be bonded before setting up Digital Key service connection. Security Mode 4 shall be used if supported both by DKSC and DKSS. Secure Simple Pairing with Out-ot-Band(NFC) model shall be applied.)
(2) 인크립션(encryption)
DKSC 와 DKSS간의 링크는 블루투스 인크립션을 사용하여 인크립트 될 수 있다(The link between DKSC and DKSS shall be encrypted using Bluetooth encryption).
(3) 링크 키들(link keys)
결합 키들이 디지털 키 공유 서비스 커넥션들을 위해 사용될 수 있다(Combination keys shall be used for Digital Key Sharing service connections).
(4) 인크립션 키 길이(encryption key length)
인크립션 키의 길이는 적어도 64비트이며, 보안을 증가시키기 위해서는 최대 길이의 인크립션 키가 사용될 수 있고, 상기 최대 길이는 주어진 지역 규정을 따른다(The length of the encryption key shall be at least 64 bits. For increased security, use of the maximum length allowed given regional regulation is encouraged).
또한, 디지털 키 공유 서비스 기능(function)들은 하기 표 1에 나타낸 바와 같다.
<표 1>
Figure pat00012
상기 표 1에서, 사용자 등록에 관련되는 기능들은 사용자 정보 획득(GetUserInformation) 기능(이하, "GetUserInformation 기능"이라 칭하기로 한다)과, 공유OTP푸쉬(PushSharingOTP) 기능(이하, "PushSharingOTP 기능"이라 칭하기로 한다)을 포함하며, 사용자 검증에 관련되는 기능들은 소유자 챌린지 획득(GetOwnerChallenge) 기능(이하, "GetOwnerChallenge 기능"이라 칭하기로 한다)과, 챌린지 결과 설정(SetChallengeResult) 기능(이하, "SetChallengeResult 기능"이라 칭하기로 한다)을 포함한다.
첫 번째로, GetUserInformation 기능에 대해서 설명하기로 한다.
상기 GetUserInformation 기능은 DKSS로부터 디지털 키를 공유하기 위해 DKSC가 보조 디바이스, 즉 사용자 디바이스의 정보를 획득하기 위해 사용된다.(This function is used by the DKSC to obtain the information of the User to share the Digital Key from the DKSS.)
상기 GetUserInformation 기능의 공통 필드(common field)들 및 헤더(header)들은 다음과 같다. 또한, 어플리케이션 서비스는 추가적인 헤더들을 포함할 수 있다(The common fields and headers of the function are listed below. The application service may add further headers.)
먼저, 상기 GetUserInformation 기능에서 요청(request)은 하기 표 2와 같이 형성된다.
<표 2>
Figure pat00013
상기 표 2에서, GET는 BT 제너릭 오프젝트 교환 프로파일(BT generic object exchange profile: GOEP, 이하 " GOEP"라 칭하기로 한다)에 설명되어 있으며, 상기 GETS는 최종 비트(final bit) 설정 여부에 따라 그 값이 결정된다. 또한, 상기 GetUserInformation 기능에서 응답(response)은 하기 표 3과 같이 형성된다.
<표 3>
Figure pat00014
그러면 여기서 상기 표 2 및 표 3에 기재되어 있는 필드/헤더들에 대해서 설명하면 다음과 같다.
(1) Connection ID
The type header shall be used to indicate the connection ID, received during the connection establishment, in order to signal the recipient of the request which OBEX connection this request belongs to.
(2) Type
The Type header shall be used to indicate the type of object to be transmitted:
<x-bt/DKS-UserInformation>
(3) Application parameters
- Nonce
: This header shall be used by the DKSC to send the DKSS a nonce value received from the car OEM server.
-MSISDN / SEIdentifier / IMEI / DeviceSerialNumber
: These headers are used to identify the User to be shared the Digital Key. The MSISDN and SEIdentifier parameters shall be sent by DKSS. The others (IMEI, DeviceServialNumber) may be included if required.
-DisplayableUserInfo
: This header shall contain the text regarding user information to be shown on the screen of Owner Smart Device display.
-UserPublicKey
: This header shall contain the public key newly created by the User Smart Device for the current Digital Key Sharing service session. The User Smart Device shall create a key pair of public and private keys when the DKSS is requested to provide user information through GetUserInformation Function.
-UserKeyHandle
: This header shall contain the identification of the key pair. This handle is used by DKSS and Car OEM server to identify the key to be used for generating and calculating the sharing OTP.
-UserSignature
: This header shall contain the resulting signature. The DKSS shall generate a Signature which is composed of the UserKeyHandle value, UserPublicKey value, DisplaybleUserInfo value, MSISDN, SEIdentifier and Nonce. If IMEI and/or DeviceSerialNumber are presence in the GetUserInformation Response, their value also shall be composed to the Signature.
상기 Application parameters에 대해서는 하기에서 보다 구체적으로 설명될 것이므로, 여기서는 그 상세한 설명을 생략하기로 한다.
두 번째로, PushSharingOTP 기능에 대해서 설명하기로 한다.
상기 PushSharingOTP 기능은 DKSC가 서비스 제공자, 일 예로 car OEM Server 에 의해 생성되는 sharing OTP를 전달하는 것을 허락한다(This function allows the DKSC to deliver the sharing OTP which is generated by the car OEM Server).
상기 PushSharingOTP 기능의 공통 필드들 및 헤더들은 하기와 같으며, 어플리케이션 서비스는 추가적인 헤더들을 포함할 수 있다.
먼저, 상기 PushSharingOTP 기능에서 요청(request)은 하기 표 4와 같이 형성된다.
<표 4>
Figure pat00015
먼저, 상기 PushSharingOTP 기능에서 응답(response)은 하기 표 5와 같이 형성된다.
<표 5>
Figure pat00016
그러면 여기서 상기 표 4 및 표 5에 기재되어 있는 필드/헤더들에 대해서 설명하면 다음과 같다.
(1) Connection ID
상기 Connection ID 는 상기 표 2 및 표 3에서 설명한 바와 유사하므로 여기서는 그 상세한 설명을 생략하기로 한다.
(2) Type
The Type header shall be used to indicate the type of object to be transmitted:
<x-bt/DKS-SharingOTP>
(3) Application parameters
-SharingOTP
: This header shall contain the SharingOTP which is received from the Car OEM Server by the DKSC.
상기 Application parameters에 대해서는 하기에서 보다 구체적으로 설명될 것이므로, 여기서는 그 상세한 설명을 생략하기로 한다.
세 번째로, GetOwnerChallenge 기능에 대해서 설명하기로 한다.
상기 GetOwnerChallenge 기능은 DKSC가 DKSS로부터 소유자 challenge를 획득하기 위해 사용된다. 상기 소유자 challenge는 서비스 제공자, 일 예로 car OEM Server에 의해 생성되며, 보조 디바이스, 일 예로 사용자 디바이스로부터 수신된다(This function is used by DKSC to get the owner challenge from the DKSS. The owner challenge is generated by the car OEM Server and received by the User Smart Device).
상기 GetOwnerChallenge 기능의 공통 필드들 및 헤더들은 하기와 같으며, 어플리케이션 서비스는 추가적인 헤더들을 포함할 수 있다.
상기 GetOwnerChallenge 기능에서, 요청(request)는 하기 표 6에 나타낸 바와 같다.
<표 6>
Figure pat00017
상기 GetOwnerChallenge 기능에서, 응답(response)은 하기 표 7에 나타낸 바와 같다.
<표 7>
Figure pat00018
그러면 여기서 상기 표 6 및 표 7에 기재되어 있는 필드/헤더들에 대해서 설명하면 다음과 같다.
(1) Connection ID
상기 Connection ID 는 상기 표 2 및 표 3에서 설명한 바와 유사하므로 여기서는 그 상세한 설명을 생략하기로 한다.
(2) Type
The Type header shall be used to indicate the type of object to be transmitted:
<x-bt/DKS-OwnerChallenge>
(3) Application parameters
-Challenge
: This header shall contain the challenge which is received from the Car OEM Server by the DKSS.
-DisplayableUserInfo
: 상기 DisplayableUserInfo 는 상기 표 2 및 표 3에서 설명한 바와 유사하므로 여기서는 그 상세한 설명을 생략하기로 한다.
상기 Application parameters에 대해서는 하기에서 보다 구체적으로 설명될 것이므로, 여기서는 그 상세한 설명을 생략하기로 한다.
네 번째로, SetChallengeResult 기능에 대해서 설명하기로 한다.
상기 SetChallengeResult 기능은 DKSC가 소유자 challenge의 계산 결과를 DKSS로 송신하는 것을 허락한다(This function allows the DKSC to send the calculation result of the owner challenge to DKSS.)
상기 SetChallengeResult 기능의 공통 필드들 및 헤더들은 다음과 같다. 또한, 어플리케이션 서비스는 추가적인 헤더들을 포함할 수 있다.
상기 SetChallengeResult 기능에서, 요청(request)은 하기 표 8과 같이 형성된다.
<표 8>
Figure pat00019
상기 SetChallengeResult 기능에서, 응답(response)은 하기 표 9와 같이 형성된다.
<표 9>
Figure pat00020
그러면 여기서 상기 표 8 및 표 9에 기재되어 있는 필드/헤더들에 대해서 설명하면 다음과 같다.
(1) Connection ID
상기 Connection ID 는 상기 표 2 및 표 3에서 설명한 바와 유사하므로 여기서는 그 상세한 설명을 생략하기로 한다 .
(2) Type
The Type header shall be used to indicate the type of object to be transmitted:
<x-bt/DKS-OwnerChallengeResult>
(3) Application parameters
-OwnerChallengeResult
: This header shall contain the resulting of owner challenge response calculated using Digital Key stored in the Owner Smart Device. 상기 APDU command들에 대해서는 하기에서 도 32를 참조하여 구체적으로 설명할 것이므로, 여기서는 그 상세한 설명을 생략하기로 한다.
상기 Application parameters에 대해서는 하기에서 보다 구체적으로 설명될 것이므로, 여기서는 그 상세한 설명을 생략하기로 한다.
다음으로, Application Parameter Header에 대해서 설명하기로 한다.
상기 Application Parameter Header에서 사용되는 태그(tag) ID들은 하기 표 10 과 같이 나타낼 수 있다.
<표 10>
Figure pat00021
다음으로 도 32를 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 기본 디바이스의 동작 과정의 일 예에 대해서 설명하기로 한다.
도 32는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 기본 디바이스의 동작 과정의 일 예를 개략적으로 도시한 도면이다.
도 32를 참조하면, 도 32에 도시되어 있는 기본 디바이스의 동작 과정은 기본 디바이스의 디지털 키를 사용하여 디지털 서명을 생성하는 과정임에 유의하여야만 할 것이다.
본 개시의 일 실시예에서 제안하는 디지털 서명을 생성하는 과정은 ISO 7816-8에서 설명되고 있는 PerformSecurityOperation command 중 디지털 서명 연산(COMPUTE DIGITAL SIGNATURE) 동작(이하, "COMPUTE DIGITAL SIGNATURE 동작"이라 칭하기로 한다)을 수정하여 구현될 수 있으며, 이에 대해서 구체적으로 설명하면 다음과 같다.
ISO 7816-8은 ISO 7816-4에 있는 APDU(Aplication Process Data Unit)를 사용하는데, APDU는 SE에 명령어를 전달할 때 사용되는 일반적인 데이터 형태이며 양식은 다음과 같다
Figure pat00022
첫번째 테이블은 Command이고 두번째 테이블은 Command에 대한 Response이다. Command는 Command header와 Lc, Data Field, Le field로 이뤄져있다. 여기서 Command field는 Class byte code인 CLA(Command의Class를 표현하는 것으로, 보내는 Command가 Secure한 Message 인지, 혹은 특정 단체에서 정의한 양식을 따르는 것인지 등을 표시한다.) 두번째 header field은 INS는 instruction field로 해당 메시지가 어떤 명령어인지 명시한다. (예: Store / Get / PerformSecurityOperation 등). P1-P2는 INS에 따라 의미하는 바가 달라진다. 본 발명에서 INS = PerformSecurityOperation이 적용된 경우 P1, P2는 다음을 의미한다.
P1 = 수행하려는 Securirty opertion이 어떤 것인지 정의함 (예: 디지털서명(P1=9E)).
P2 = P1에 따라 의미하는 바가 달라지며, INS와 P1에 의해 결정된 명령어를 더 구체화하는 역할을 맡는다. 본 발명에서 P2는 디지털서명이 1) 제2디바이스를 서비스 제공자에 등록할 때 수행되지는 것인지 (P2='xx') 혹은 2) 제 2디바이스와 서비스 제공자간 인증 시, 최종 확인을 하기 위함인지 (P2='yy')를 분간하기 위한 용도로 사용되었다.
두번째 테이블은 Command에 대한 응답APDU로, 응답 APDU는 크게 Data field와 Response trailer field로 나누어져 있다. 응답의 종류에 따라 Data field는 존재할 수도 있고, 존재하지 않을 수도 있다. Response trailer 필드는 SW(=Status Byte) 2개의 값을 포함하고 있다. 이 Status Byte들은 받은 Command APDU에 대한 수행의 결과를 표현한다.
ISO 7816-4에 정의된 Status Byte를 그대로 사용할 수도 있고, 각 표준단체에서 새로 Status Byte를 정의하는 것도 가능하다.
먼저, 기본 디바이스, 즉 소유자 디바이스는 Mobile UI와 SE를 포함하며, 상기 Mobile UI와 SE간에는 SE 명령들이 실행된다.
상기 COMPUTE DIGITAL SIGNATURE 동작은 디지털 서명의 연산을 개시한다. 즉, 상기 Mobile UI는 상기 SE로 디지털 서명 연산을 수행할 것을 요청하는 메시지, 일 예로 보안 동작-디지털 서명 연산 수행(Perform Security Operation-Compute Digital Signature, 이하 "Perform Security Operation-Compute Digital Signature"라 칭하기로 한다) APDU를 송신한다([01][APDU] Perform Security Operation-Compute Digital Signature) .
본 개시의 다양한 실시예들에서 상기 디지털 서명의 연산은 일 예로 디지털 서명 알고리즘 혹은 해쉬 알고리즘과 디지털 서명 알고리즘의 결합에 의해 수행될 수 있다.
디지털 서명의 연산을 위해서, 서명 프로세스에서 서명되는 혹은 통합될 데이터는 명령 데이터 필드(command data field)에 포함되며, P2에서 디지털 서명은 태그 'XX'로 특정된다.
일 예로, 디지털 서명 연산 동작에서 사용될 수 있는 코드들은 하기 표 11과 같이 나타낼 수 있다.
<표 11>
Figure pat00023
상기 표 11에는 각 코드별 Presence가 일 예로 Mandatory로 기재되어 있으나, 상황에 따라 각 코드별 Presence는 Mandatory가 될 수도 있고, Conditional이 될 수도 있고, Optional 이 될 수도 있음은 물론이다.
상기 표 11에서, 데이터 필드는 하기 표 12와 같이 나타낼 수 있다.
<표 12>
Figure pat00024
상기 표 12에서, User Secure Identifier와, User Certificate 및 User MSISDN는 사전 확인(pre-confirmation) 동작에서 사용되는 데이터 포맷이며, User Challenge Response와, Challenge (received from Car OEM Backend through the User)는 사후 확인(post-confirmation) 동작에서 사용되는 데이터 포맷이다.
또한, 상기 표 12에 기재되어 있는 각 데이터 포맷별 Presence는 상황에 따라 변경될 수 있다. 일 예로, User Secure Identifier의 presence는 Mandatory, 혹은 Conditional for P2=xx로 기재되어 있으나 상황에 따라 optional이 될 수도 있고, User MSISDN의 presence는 Conditional for P2=xx로 기재되어 있으나, 상황에 따라 Mandatory, 혹은 optional이 될 수도 있다.
Data Field는 Type-Length-Value의 TLV 형태로 정의되어 있으며, Type은 본 발명에서 임으로 xx, yy로 표기하였으나, 이 값들은 표준 단체에서 정한 값이 사용될 수 있다.
한편, 상기 Mobile UI로부터 Perform Security Operation-Compute Digital Signature APDU를 수신한 SE는 하기 표 13에 나타낸 바와 같이 디지털 서명을 포함하는 보안 동작 수행 응답(Perform Security Operation Response, 이하 "Perform Security Operation Response"라 칭하기로 한다) APDU를 송신한다([02] [APDU] Perform Security Operation Response).여기서 Status Byte 부부분에 Error code가 "Digital Key object not found"가 추가 되었다. 이는 SE내에 서명에 사용할 Digital Key 또는 그에 상응하는 Key가 존재하지 않음을 알려주기 위한 에러 코드로 사용된다.
<표 13>
Figure pat00025
도 32에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 기본 디바이스의 동작 과정의 일 예에 대해서 설명하였으며, 다음으로 도 33a 내지 도 33b를 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 다른 예에 대해서 설명하기로 한다.
도 33a 내지 도 33b는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 다른 예를 개략적으로 도시한 도면이다.
도 33a 내지 도 33b를 참조하면, 먼저 도 33a 내지 도 33b에 도시되어 있는 보조 디바이스 등록 과정은 보조 디바이스와 상기 보조 디바이스의 사용자 정보를 서비스 제공자에 어떻게 등록하는지를 나타낸다.
또한, 도 33a 내지 도 33b에는 상기 보조 디바이스가 "Client Device"로, 기본 디바이스가 "Owner Device"로, 상기 서비스 제공자가 "Car OEM Back-End"로 도시되어 있음에 유의하여야만 할 것이다.
먼저, 상기 보조 디바이스는 SE와 Mobile UI를 포함하며, 상기 기본 디바이스는 Mobile UI와 SE를 포함한다. 도 33a 내지 도 33b에서, 설명의 편의상 상기 보조 디바이스에 포함되는 SE와 Mobile UI는 각각 "SE-A" 및 "Mobile UI-A"라 칭하기로 하며, 상기 기본 디바이스에 포함되는 SE와 Mobile UI는 각각 "SE-B" 및 "Mobile UI-B"라 칭하기로 한다. 또한, 상기 Mobile UI-A 및 상기 Mobile UI-B는 각각 상기 SE-A 및 상기 SE-B에 억세스할 수 있다. 즉, Mobile UI는 다른 디바이스와의 P2P 통신을 가능하게 하고, SE에 억세스할 수 있는 엔터티를 나타낸다.
먼저, 상기 Mobile UI-B가 활성화되며(Activation of Owner Mobile UI), 이에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 어플리케이션 시작 및 루팅 체크(rooting check) 등에 의해 상기 Mobile UI-B가 실행되며(a. Start app and rooting check), 키 전달하기/키 공유하기 등과 같은 메뉴가 선택된다(b. Select "To share my Key). 상기 어플리케이션 루팅 체크는 서비스 개발에 따라 어플리케이션의 실행시에 수행되거나 혹은 특정 기능이 필요로 될 때 수행될 수 있다.
또한, 상기 Mobile UI-B의 제공자 또는 서비스 제공자의 서비스 정책에 따라 필요할 경우 사용자 인증(user authentication) 프로세스가 수행될 수 있으며(c. User Authentication), 상기 사용자 인증 프로세스는 상기 기본 디바이스에 미리 등록되어 있는 개인 식별 번호(personal identification number: PIN, 이하 "PIN"이라 칭하기로 한다)를 기반으로 수행될 수 있거나, 혹은 생체 인식 등을 기반으로 수행될 수 있다.그리고 나서 상기 Mobile UI-B는 NFC P2P 모드로 그 동작을 시작한다(d. Start NFC P2P operation).
한편, 상기 Mobile UI-B의 활성화 프로세스에서 루팅 체크를 제외한 나머지 동작들은 선택적(optional)일 수 있으며, 상기 Mobile UI-B의 제공자의 구현에 따라 수행될 수도 있고 혹은 생략될 수도 있다. 또한, 상기 Mobile UI-B는 하나 혹은 그 이상의 어플리케이션 루팅 체크 메카니즘을 지원한다(Mobile UI shall support one or more app rooting check mechanism).
또한, 상기 Mobile UI-A가 활성화되며(Activation of User Mobile UI), 이에 대해서 구체적으로 설명하면 다음과 같다. 도 29a 내지 도 29b에서는 상기 보조 디바이스가 적어도 하나의 Mobile UI를 설치했다고 가정된 것임에 유의하여야만 한다.
먼저, 어플리케이션 시작 및 루팅 체크 등에 의해 상기 Mobile UI-A가 실행되며(a. Start app and rooting check), 키 수신하기 등과 같은 메뉴가 선택된다(b. Select "to have shared key). 상기 어플리케이션 루팅 체크는 서비스 개발에 따라 어플리케이션의 실행시에 수행되거나 혹은 특정 기능이 필요로 될 때 수행될 수 있다.
또한, 상기 Mobile UI-A는 NFC P2P 모드로 그 동작을 시작한다(c. Start NFC P2P operation).
한편, 상기 Mobile UI-A의 활성화 프로세스에서 루팅 체크를 제외한 나머지 동작들은 선택적일 수 있으며, 상기 Mobile UI-A의 제공자의 구현에 따라 수행될 수도 있고 혹은 생략될 수도 있다. 또한, 상기 Mobile UI-A는 하나 혹은 그 이상의 어플리케이션 루팅 체크 메카니즘을 지원한다(Mobile UI shall support one or more app rooting check mechanism)
상기 Mobile UI-B는 상기 서비스 제공자로 근접성 트리거링 키 공유를 개시할 것임을 나타내는, 즉 근접 터치를 기반으로 하는 키 공유 프로세스(key sharing process)가 개시됨을 나타내는 메시지, 일 예로 proximity triggering key sharing initiation 메시지를 송신한다([01] Proximity Triggering Key Sharing initiation). 상기 Mobile UI-B와 서비스 제공자간의 인터페이스는 다양한 형태들로 구현될 수 있으며, 여기서는 그 상세한 설명을 생략하기로 한다.
상기 Mobile UI-B로부터 proximity triggering key sharing initiation 메시지를 수신한 서비스 제공자는 랜덤(random) 변수인 넌스(nonce, 이하 "nonce" 라 칭하기로 한다)를 생성한다. 여기서, 상기 nonce는 상기 보조 디바이스의 정보를 수신 및 검증할 때 사용되는데, 이는 상기 보조 디바이스의 정보를 생성할 때 nonce를 사용함으로써, 상기 보조 디바이스의 정보가 재사용되는 것을 방지하기 위함이다. 또한, 상기 nonce는 키 공유 프로세스가 시작될 때 마다 새롭게 생성되며, 이로 인해 보조 디바이스에 대해 고유한 정보가 생성될 수 있다.
한편, 상기 서비스 제공자는 상기 기본 디바이스로 상기 서비스 제공자에 등록할 보조 디바이스의 사용자 정보를 요청하는 메시지, 일 예로 클라이언트 정보 요청(client information request) 메시지(이하 "client information request 메시지"라 칭하기로 한다)를 송신한다([02] Client Information Request(Nonce = n)). 여기서, 상기 client information request 메시지는 상기 서비스 제공자에 의해 생성된 nonce를 포함하며, 도 33a 내지 도 33b에서는 상기 서비스 제공자에 의해 생성된 nonce가 "n"이라고 가정하기로 한다(nonce = n).
상기 서비스 제공자로부터 client information request 메시지를 수신한 기본 디바이스의 Mobile UI-B는 상기 보조 디바이스의 Mobile UI-A로 상기 서비스 제공자에 등록할 보조 디바이스의 사용자 정보를 요청하는 메시지, 일 예로 client information request 메시지를 송신한다([03] Client Information Request(n)). 여기서, 상기 [03] 동작에서 송신되는 client information request 메시지는 상기 [02] 동작에서 송신되는 client information request 메시지에 포함되어 있는 nonce를 포함한다. 상기 Mobile UI-B로부터 client information request 메시지를 수신한 Mobile UI-A는 상기 서비스 제공자에 등록할 사용자 정보를 생성하는 사용자 정보 생성 동작을 수행한다( [Generation of User Information]). 상기 사용자 정보 생성 동작을 보다 구체적으로 설명하면 다음과 같다.
먼저, 상기 Mobile UI-A는 Public/Private Key pair(C.Kpub, C.Kpriv)를 생성하고,
상기 Public/Private Key pair(C.Kpub, C.Kpriv)에 대한 ID인 handle h를 생성하고,
사용자 정보를 생성한다.
상기 사용자 정보는 다음과 같은 파라미터들을 포함한다.
(1) SE ID, MSISDN
(2) 필요에 따라, 상기 사용자 정보는 SE Issuer 정보, App version, IMEI, 보조 디바이스 SE, 즉 SE-A에 대한 인증서 및 보조 디바이스 모델 명, 보조 디바이스 제조사 명, 보조 디바이스 S/N 등을 더 포함할 수 있다.
상기 사용자 정보에 포함되는 정보 중 SE ID와 IMEI 등은 보조 디바이스를 식별하기 위한 정보로서 사용되고, MSISDN은 상기 보조 디바이스의 사용자를 식별하기 위해 사용되는 정보이다.
그리고 나서, 상기 Mobile UI-A는 상기 사용자 정보 및 handle h, 공중 키 C.Kpub, nonce값에 사설 키 C.Kpriv로 서명하여 사용자 정보 서명(Cinfo.Signature)을 생성한다. 여기서, "Cinfo.Signature"는 클라이언트 디바이스, 즉 보조 디바이스에 의해 생성된 사용자 정보 서명을 나타낸다.
상기 사용자 정보 생성 동작을 수행한 후, 상기 Mobile UI-A는 상기 Mobile UI-B로 상기 client information request 에 대한 응답 메시지, 일 예로 클라이언트 정보 응답(client information response) 메시지(이하, " client information response 메시지"라 칭하기로 한다)를 송신한다([04] Client Information Response(C Info)). 여기서, 상기 client information response 메시지는 상기 Mobile UI-A가 생성한 상기 보조 디바이스의 사용자 정보와, 상기 보조 디바이스의 공중 키C.Kpub, handle h, Cinfo.Signature를 포함한다.
한편, 상기 보조 디바이스와 기본 디바이스간의 커넥션이 NFC방식을 기반으로 할 경우, 사용자 경험(user experience: UX, 이하 "UX"라 칭하기로 한다) 개선을 위해 다른 방식, 일 예로 WiFi, 블루투스 등과 같은 다른 방식으로 핸드오버할 수 있다. 이에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 도 33a 내지 도 33b에서는 NFC 에서 다른 connectivity로 핸드오버하는 경우를 가정하기로 한다. 이 경우, 상기 Mobile UI-B는 상기 Mobile UI-A로 NFC에서 다른 connectivity로 핸드오버할 것을 요청하는 handover request 메시지를 송신한다([05] Handover Request). 상기 Mobile UI-B로부터 handover request 메시지를 수신한 Mobile UI-A는 다른 connectivity로 핸드오버하기로 선택한 후, 상기 Mobile UI-B로 다른 connectivity로 핸드오버하기로 선택하였음을 나타내는 메시지, 일 예로 handover select 메시지를 송신한다([02]Handover Select). 즉, 상기 기본 디바이스는 핸드오버 요청자(handover requester)가 되고, 상기 보조 디바이스는 핸드오버 선택자(handover selector)가 된다. 또한, 상기 NFC에서 다른 connectivity로의 핸드오버 동작에 대한 보다 구체적인 사항들은 NFC 커넥션 핸드오버 기술 규격(NFC Connection Handover Technical Specification [xx])에서 설명되고 있는 바와 동일함에 유의하여야만 할 것이다.
상기한 바와 같은 handover request 메시지 및 handover select 메시지 교환에 따라 상기 Mobile UI-B와 Mobile UI-A 간에는 다른 connectivity를 기반으로 하는 커넥션이 성립된다([07] Handover connection established (WiFi, BT, etc).
그리고 나서, 상기 Mobile UI-B는 사전 확인(pre-confirmation) 동작을 수행한다(Owner Pre-Confirmation). 여기서, 상기 사전 확인 동작에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 상기 Mobile UI-B는 Mobile UI-A로부터 수신한 공중키 C.Kpub을이용하여 Cinfo.Signature를 검증한다(a. Check signature).
상기 Cinfo.Signature에 대한 검증이 성공적인 경우, 상기 Mobile UI-B는 상기 기본 디바이스에 포함되어 있는 출력 디바이스, 일 예로 스크린에 상기 보조 디바이스의 사용자 정보를 출력한다(b. User information is shown in Owner's display). 이렇게, 상기 출력 디바이스에 상기 보조 디바이스의 사용자 정보를 출력하는 이유는 상기 보조 디바이스의 사용자 정보에 대해 확인받기 위함이며, 이런 확인은 일 예로 상기 기본 디바이스의 사용자의 개입에 따른 이벤트 발생, 일 예로 확인 버튼 터치, 혹은 지문 검사 등과 같은 이벤트 발생에 따라 이루어질 수 있다. 상기 출력 디바이스에 출력되어 있는, 상기 보조 디바이스의 사용자 정보가 확인됨을 검출하면(c. Owner confirms user information), 상기 Mobile UI-B는 상기 기본 디바이스에 저장되어 있는 디지털 키y또는 상기 디지털 키에 준하는 권한을 가지는 키 를 사용하여 상기 보조 디바이스의 사용자 정보에 서명한다(Signature on Client Info using Owner's Digital Key). 상기 Mobile UI-B가 상기 SE-B에 저장되어 있는 디지털 키를 직접 사용할 경우, 디지털 키 서명(digital key signature)를 위한 APDU를 사용한다. 상기 디지털 키 서명을 위한 APDU는 상기에서 도 32를 참조하여 구체적으로 설명되었으므로 것이므로, 여기서는 그 상세한 설명을 생략하기로 한다.
한편, 상기 사전 확인 동작을 수행한 후 Mobile UI-B는 상기 서비스 제공자로 상기 client information request 메시지에 대한 응답 메시지, 일 예로 클라이언트 정보 응답(client information response) 메시지(이하 "client information response 메시지"라 칭하기로 한다)를 송신한다([08] Client Information Response (C Info, DK signature). 여기서, 상기 client information response 메시지는 상기 보조 디바이스로부터 수신한 사용자 정보와 상기 기본 디바이스의 디지털 키 서명을 포함한다.
상기 Mobile UI-B로부터 client information response 메시지를 수신한 서비스 제공자는 사용자 디바이스 검증 동작 및 보조 디바이스 등록 동작을 수행한다( Owner Verification and User enrollment). 여기서, 상기 사용자 디바이스 검증 동작 및 보조 디바이스 등록 동작에 대해서 구체적으로 설명하면 다음과 같다.
상기 Mobile UI-B로부터 user information response 메시지를 수신한 서비스 제공자는 사용자 디바이스 검증 동작 및 보조 디바이스 등록 동작을 수행한다( Owner Verification and User enrollment). 여기서, 상기 사용자 디바이스 검증 동작 및 보조 디바이스 등록 동작에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 상기 서비스 제공자는 상기 기본 디바이스의 디지털 키 서명에 대한 검증 동작을 수행한다(a. Digital Key signature verification). 즉 상기 서비스 제공자는 상기 기본 디바이스의 디지털 키 서명에 대한 검증 동작을 수행하여 상기 기본 디바이스가 실제 디지털 키를 소유하는 소유자 디바이스인지, 그리고 상기 기본 디바이스가 적합한 권한을 가지고 있는지 검사한다.
상기 기본 디바이스의 디지털 키 서명에 대한 검증 결과가 성공을 나타낼 경우, 상기 서비스 제공자는 상기 기본 디바이스로부터 수신하고, 상기 디지털 키로 서명된 상기 보조 디바이스의 사용자 정보를 등록, 즉 저장한다(b. C. Infor, handle, C.Kpub enrollment).
여기서, 상기 보조 디바이스의 사용자 정보는 상기에서 설명한 바와 같이 상기 보조 디바이스가 포함하는 SE, 즉 SE-A의 SE ID와, MSISDN, C.Kpub, handle h 등을 포함할 수 있다.
그리고 나서, 상기 서비스 제공자는 상기 서비스 제공자와 상기 보조 디바이스가 공유할 공유 비밀(shared secret: SHS, 이하 "SHS"라 칭하기로 한다)을 생성하고, 상기 SHS를 상기 보조 디바이스의 공중 키로 암호화하여 OTP를 생성한다(c. Create OTP = enc (C.Kpub, SHS).
상기 SHS 는 이후의 절차에서 상기 보조 디바이스를 검증하는데 사용되는 값이다. 즉, 상기 서비스 제공자는 상기 보조 디바이스가 상기 SHS를 가지고 있는지 확인한다.
여기서, 상기 서비스 제공자가 OTP를 생성하는 이유는, 상기 서비스 제공자가 해당 정보, 일 예로 디지털 키를 기본 디바이스를 통해서 상기 보조 디바이스로 전달하는 데, 상기 보조 디바이스 외에는 다른 어떤 디바이스도 상기 OTP를 해독하여 SHS를 확보할 수 없도록 하기 위함이다.
한편, 상기 사용자 디바이스 검증 동작 및 보조 디바이스 등록 동작을 수행한 후 상기 서비스 제공자는 상기 Mobile UI-B로 사용자 등록 결과를 클라이언트 등록 결과(client registration result) 메시지(이하, "client registration result 메시지"라 칭하기로 한다)를 송신한다([09] Client Registration Result (OTP). 상기 보조 디바이스의 사용자 정보가 정상적으로 등록된 경우, 상기 user registration result 메시지는OTP를 포함한다. 여기서, 상기 OTP는 상기 서비스 제공자가 생성한 OTP를 나타낸다.
상기 서비스 제공자로부터 user registration result 메시지를 수신한 Mobile UI-B는 상기 Mobile UI-A로 상기 서비스 제공자로부터 수신한 OTP를 그대로 전달한다([10] Client Registration Result (OTP)). 즉, 상기 Mobile UI-B는 상기 Mobile UI-A로 client registration result 메시지를 통해 상기 OTP를 전달한다.
그리고 나서, 상기 Mobile UI-A는 SHS 획득 동작을 수행한다(Acquisition of SHS). 여기서, 상기 SHS 획득 동작에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 상기 Mobile UI-A는 상기 보조 디바이스의 사설 키인 C.KPriv 를 이용하여 OTP를 복호하고, 상기 OTP를 사용하여 SHS를 획득한다(Client Mobile UI calculates SHS from OTP and C.Kpriv).
도 33a 내지 도 33b에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 다른 예에 대해서 설명하였으며, 다음으로 도 34a 내지 도 34b를 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 또 다른 예에 대해서 설명하기로 한다.
도 34a 내지 도 34b는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 또 다른 예를 개략적으로 도시한 도면이다.
도 34a 내지 도 34b를 참조하면, 먼저 도 34a 내지 도 34b에 도시되어 있는 보조 디바이스 등록 과정은 보조 디바이스와 상기 보조 디바이스의 사용자 정보를 서비스 제공자에 어떻게 등록하는지를 나타낸다.
또한, 도 34a 내지 도 34b에는 상기 보조 디바이스가 "Client Device"로, 기본 디바이스가 "Owner Device"로, 상기 서비스 제공자가 "Car OEM Back-End"로 도시되어 있음에 유의하여야만 할 것이다.
먼저, 상기 보조 디바이스는 SE와 Mobile UI를 포함하며, 상기 기본 디바이스는 Mobile UI와 SE를 포함한다. 도 34a 내지 도 34b에서, 설명의 편의상 상기 보조 디바이스에 포함되는 SE와 Mobile UI는 각각 "SE-A" 및 "Mobile UI-A"라 칭하기로 하며, 상기 기본 디바이스에 포함되는 SE와 Mobile UI는 각각 "SE-B" 및 "Mobile UI-B"라 칭하기로 한다. 또한, 상기 Mobile UI-A 및 상기 Mobile UI-B는 각각 상기 SE-A 및 상기 SE-B에 억세스할 수 있다. 즉, Mobile UI는 다른 디바이스와의 P2P 통신을 가능하게 하고, SE에 억세스할 수 있는 엔터티를 나타낸다.
한편, 도 34a 내지 도 34b에 도시되어 있는 보조 디바이스 등록 과정은 도 33a 내지 도 33b에서 설명한 바와 같은 보조 디바이스 등록 과정과 유사하며, 다만 하기와 같은 측면들에서 도 33a 내지 도 33b에서 설명한 바와 같은 보조 디바이스 등록 과정과 상이함에 유의하여야만 할 것이다.
첫 번째로, 기본 디바이스는 보조 디바이스의 사용자 정보를 획득하기 전까지 서비스 제공자와 통신을 수행하지 않는다.
두 번째로, 기본 디바이스가 상기 서비스 제공자와 사전에 별도로 통신을 수행하지 않으므로 상기 기본 디바이스에 포함되는 Mobile UI-B가 nonce를 값을 생성하여 상기 보조 디바이스에 포함되는 Mobile UI-A에게 전달하고, 상기 서비스 제공자로 상기 보조 디바이스의 사용자 정보를 전달할 때 상기 사용자 정보와 함께 상기 nonce값을 전달함으로써 상기 서비스 제공자가 상기 사용자 정보를 검증하는 것이 가능하게 할 수 있다.
또한, 도 34a 내지 도 34b의 [06] 동작 내지 [08] 동작은 도 33a 내지 도 33b의 [08] 동작 내지 [10] 동작과 유사하며, 다만 Req-Res 매커니즘 상 그 기능(function)의 명칭만 다른 것임에 유의하여야만 할 것이다.
도 34a 내지 도 34b에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 또 다른 예에 대해서 설명하였으며, 다음으로 도 35를 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하기로 한다.
도 35는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다.
도 35를 참조하면, 먼저 도 35에는 서비스 제공자가 "OEM Server"로, 기본 디바이스가 "Owner Entity"로, 보조 디바이스가 "Client 단말"로 도시되어 있음에 유의하여야만 할 것이다.
도 35에 도시되어 있는 디지털 키 제공 과정은 기본 디바이스가 보조 디바이스와의 키 공유를 먼저 신청하고, 기본 디바이스가 발급한 공유 토큰(sharing token, 이하 "sharing token"라 칭하기로 한다)을 서비스 제공자가 검증할 경우의 디지털 키 제공 과정임에 유의하여야만 할 것이다.
먼저, 상기 기본 디바이스는 서비스 제공자로 키 공유를 신청하면(1. Key sharing 신청), 상기 서비스 제공자는 nonce를 발행한다(2. Nonce 발행). 그리고 나서, 상기 서비스 제공자는 상기 발행한 nonce를 상기 기본 디바이스로 전달하고(3. Nonce*전달), 상기 기본 디바이스는 상기 nonce 및 디지털 키를 기반으로 sharing token를 생성한다(4. Nonce 및 Digital Key (또는 양단간 사전 공유된 SHS를 이용하여 Sharing Token 생성).
그리고 나서, 상기 기본 디바이스는 상기 보조 디바이스와 NCF 커넥션을 성립하고(5. NFC 연결), 상기 보조 디바이스로 sharing token을 송신한다(6. Sharing Token 전달). 상기 기본 디바이스로부터 sharing token을 수신한 보조 디바이스는 상기 서비스 제공자로 서비스를 신청하고, 즉 디지털 키 발급을 신청하고(7. 서비스(Digital Key 발급) 신청), 이에 따라 상기 보조 디바이스와 서비스 제공자간에는 sharing token에 대한 검증 동작이 수행된다(8. Sharing Token 검증). 그리고 나서, 상기 sharing token에 대한 검증 결과가 성공적임을 나타낼 경우 상기 서비스 제공자는 상기 보조 디바이스로 서비스를 제공한다(9. 서비스 제공). 즉, 상기 sharing token에 대한 검증 결과가 성공적임을 나타낼 경우 상기 서비스 제공자는 상기 보조 디바이스로 디지털 키를 발급한다.
도 35에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하였으며, 다음으로 도 36을 참조하여 도 35의 디지털 키 제공 과정에 따른 보조 디바이스와, 기본 디바이스 및 서비스 제공자 간의 신호 송/수신 동작에 대해서 설명하기로 한다. 도 36은 도 35의 디지털 키 제공 과정에 따른 보조 디바이스와, 기본 디바이스 및 서비스 제공자 간의 신호 송/수신 동작을 개략적으로 도시한 도면이다.
도 36을 참조하면, 먼저 도 36에는 보조 디바이스가 "Client Smart Device"로, 기본 디바이스가 "Owner Smart Device"로, 서비스 제공자가 "OEM"으로 기재되어 있음에 유의하여야만 할 것이다.
먼저, 기본 디바이스는 서비스 제공자로 key sharing 서비스를 신청하는 메시지를 송신한다(1. Key Sharing 신청(Owner ID), (opt.) Access property).
상기 key sharing 서비스를 신청하는 메시지는 기본 디바이스의 식별자, 즉 Owner ID 등과 같은 ID를 포함할 수 있다.
또한, 상기 key sharing 서비스를 신청하는 메시지는 선택적으로(optional 하게) Access property 등과 같은 정보를 포함할 수 있다.
여기서, 상기 Access property 는 Key 유효 시간, 자동 운행 거리, 자동차 운행 가능 지역에 관련된 정보, 일 예로 Geo fencing, 일 예로 특정 지역 내에서만 운행 가능함을 나타내는 정보, 자동차 속성, 일 예로 최대 속도 등과 같은 자동차 속성과, 자동차 사용 권한, 일 예로 문열기 / 트렁크열기 / 시동걸기 등과 같은 등과 같은 자동차 사용 권한 등을 포함할 수 있다.
그리고, 상기 서비스 제공자는 key sharing 신청에 대한 응답과 함께 nonce와 service ID를 송신한다(2. Key Sharing 응답(Nonce, Service ID).
여기서, 상기 nonce는 일 예로 상기 기본 디바이스가 생성할 Token의 재 사용을 방지하기 위해 사용될 수 있다.
또한, 상기 Service ID는 일 예로 이후의 절차에서 상기 보조 디바이스가 key 발급을 요청했을 때 (즉, "7" 동작) 서비스 제공자와, 기본 디바이스와, 보조 디바이스간의 Service sync-up을 일치시키기 위해 사용될 수 있다.
그리고 나서, 상기 기본 디바이스는 상기 기본 디바이스에 저장된 Digital Key또는 상기 디지털 키에 준하는 권한을 가진 Key를 사용하여 Sharing Token을 생성한다.
여기서, 상기 Sharing Token 은 Digital Key, 혹은 상기 Digital Key에 준하는 권한을 가진 Key 와 상기 서비스 제공자로부터 제공받은 nonce를 기반으로 생성될 수 있다.
(3. Perform Security Operation APDU: Token Generation operation; 4. Shr. Token = Hash (Iuput Data, DK.sharing); 5. rsp. (Shr. Token); Compute Shr. Token by OEM = Hash(Input Data, DK.sharing)
그리고 나서 상기 보조 디바이스와 기본 디바이스간에는 NFC, BT 등과 같은 근거리 통신 방식을 기반으로 통신 환경이 성립된다. 도 36에서는 상기 NFC 방식을 기반으로 상기 보조 디바이스와 기본 디바이스간에 통신 환경이 성립된다고 가정하기로 한다. 즉, 도 36에서는 상기 보조 디바이스와 기본 디바이스간에 NFC 커넥션이 성립된다고 가정하기로 한다(NFC connection Established). 이로 인해 상기 보조 디바이스와 기본 디바이스간에는 secure한 channel 이 생성되었다고 가정한다.
그리고 나서 상기 기본 디바이스는 상기 보조 디바이스로 Sharing Token과 Service ID를 전달한다(6. Shr.Token, Service ID 전달).
그리고 나서 상기 보조 디바이스는 상기 서비스 제공자로 Digital Key Sharing 을 요청한다(7. Key Sharing 신청(Service ID)).
상기 서비스 제공자는 상기 보조 디바이스가 어떤 기본 디바이스와 연결되어 있는지 등을 상기 Service ID를 통해 인식할 수 있다.
상기 서비스 제공자는 Challenge와 함께 상기 보조 디바이스로 Verification을 요청한다(8. Shr.Token Verification request (Challenge)).
여기서, 상기 서비스 제공자가 Verification 을 요청하는 이유는 상기 기본 디바이스가 생성된 Sharing Token을 상기 보조 디바이스가 가지고 있는지 확인하기 위함이다.
그리고 나서 상기 보조 디바이스는 Challenge Response를 생성하여 상기 서비스 제공자로 응답한다(9. Compute Challenge response = f (Shr.Token, Challenge); 10. Challenge Response).
여기서, 상기 Challenge Response는 Sharing Token (기본 디바이스에 의해 제공된)과 Challenge (서비스 제공자에 의해 제공된r)를 기반으로 생성될 수 있다.
그리고 나서, 상기 서비스 제공자는 상기 기본 디바이스로부터 수신된 Challenge Response를 검증한다(11. Compute Challenge response by OEM = f (Shr.Token_by OEM, Challenge); 12. Verify Challenge response by comparing with challenge response by OEM).
상기 서비스 제공자는 Nonce, Challenge 값을 알고 있고, Owner ID를 통해 상기 기본 디바이스가 어떤 Digital Key를 사용했는지 파악할 수 있다.
따라서, 상기 서비스 제공자는 상기 값들을 기반으로 Sharing Token (nonce + Digital Key)을 계산하고, Challenge Response (Sharing Token + Challenge) 를 계산한다.
그리고 나서, 상기 서비스 제공자는 상기 보조 디바이스로부터 전달받은 Challenge response 와 상기 서비스 제공자가 직접 계산한 Challenge response 이 일치하는 지를 통해 상기 기본 디바이스를 검증한다.
여기서 상기 서비스 제공자와 기본 디바이스/보조 디바이스간에는 Sharing Token 계산 함수와 Challenge Response 계산 함수를 사용할지 sync-up 이 되어 있거나, 혹은 미리 결정되어 있다고 가정하기로 한다.
상기 보조 디바이스가 성공적으로 검증된 경우, 상기 서비스 제공자는 상기 보조 디바이스에게 Digital Key를 발급한다(13. Service 제공(key 발급 등), (opt) Access property가 있는 경우, Access property가 반영된 서비스 제공).
여기서, 상기 "1" 동작에서 Access property가 설정 된 경우, 상기 서비스 제공자는 상기 설정된 Access property에 해당하는 특징이 반영된 디지털 키를 발급한다.
한편, 상기 Digital Key 값과 Access property는 디바이스 내 서로 다른 디바이스들 혹은 서로 다른 영역들에 저장 될 수 있다. 일 예로, Digital Key는 SE에 저장, Access Property는 TEE 등과 같은 별도의 디바이스 혹은 영역에 저장될 수 있다.
도 36에서는 도 35의 디지털 키 제공 과정에 따른 보조 디바이스와, 기본 디바이스 및 서비스 제공자 간의 신호 송/수신 동작에 대해서 설명하였으며, 다음으로 도 37을 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하기로 한다.
도 37은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정을 개략적으로 도시한 도면이다.
도 37을 참조하면, 먼저 도 37에는 서비스 제공자가 "Service provider"로, 기본 디바이스가 "Owner"로, 보조 디바이스가 "Client"로 도시되어 있음에 유의하여야만 할 것이다.
도 37에 도시되어 있는 디지털 키 제공 과정은 보조 디바이스가 먼저 서비스 제공자에 접속한 후 서비스를 요청하여 서비스 접속 정보를 획득하고, 상기 보조 디바이스가 획득한 서비스 접속 정보를 기반으로 기본 디바이스가 서비스 제공자에 접속하여 인증 및 주요 정보 전달에 대한 확인 동작을 수행할 경우의 디지털 키 제공 과정임에 유의하여야만 할 것이다.
먼저, 상기 보조 디바이스가 상기 서비스 제공자로 서비스를 요청하고(1. 서비스 요청), 이에 상기 서비스 제공자와 보조 디바이스간에는 서비스 접속 정보가 전달된다(2. 서비스 접속 정보 전달(네트워크(network: N/W, 이하 "N/W"라 칭하기로 한다) 정보, URL(uniform resource locator), Service ID 등)). 여기서, 상기 서비스 접속 정보는 N/W 정보와, URL 정보와, Service ID 등을 포함할 수 있다.
그리고 나서, 상기 보조 디바이스는 상기 기본 디바이스로 상기 서비스 접속 정보와 상기 보조 디바이스의 정보를 송신한다(3. 서비스 접속 정보 재전송 + Client 정보). 상기 보조 디바이스로부터 서비스 접속 정보와 상기 보조 디바이스의 정보를 수신한 기본 디바이스는 상기 서비스 제공자로 접속하고(4. 서버 접속), 상기 서비스 제공자와 상기 기본 디바이스간에는 소유자 인증 절차, 즉 기본 디바이스 인증 절차가 진행된다(5. Owner 인증). 상기 기본 디바이스 인증 절차가 성공하면, 상기 기본 디바이스는 상기 서비스 제공자로 서비스를 신청한다(6. 서비스 신청(Key 발급 또는 주요 정보 대리 전달 등), (opt) Access property 포함). 여기서, 상기 서비스 신청은 일 예로 상기 보조 디바이스에 대해 디지털 키를 발급해줄 것을 요청하는 서비스 신청이 될 수 있다.
상기 기본 디바이스로부터 서비스 신청을 수신한 서비스 제공자는 상기 보조 디바이스로 서비스를 제공한다(7. 서비스 제공(Key 발급 또는 Owner로부터 받은 정보 전달).
도 37에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 대해서 설명하였으며, 다음으로 도 38을 참조하여 도 37의 디지털 키 제공 과정에 따른 보조 디바이스와, 기본 디바이스 및 서비스 제공자 간의 신호 송/수신 동작에 대해서 설명하기로 한다.
도 38은 도 37의 디지털 키 제공 과정에 따른 보조 디바이스와, 기본 디바이스 및 서비스 제공자 간의 신호 송/수신 동작을 개략적으로 도시한 도면이다.
도 38을 참조하면, 먼저 도 38에는 보조 디바이스가 "Client Smart Device"로, 기본 디바이스가 "Authorized Entity(Owner)"로, 서비스 제공자가 "Service Provider"로 기재되어 있음에 유의하여야만 할 것이다.
먼저, 보조 디바이스가 Service Provider에 서비스를 요청한다(1. 서비스 신청(Key Sharing 또는 보안 정보 Sharing 등)
여기서, 상기 서비스의 종류에 대해서 설명하면 다음과 같다.
먼저, Key Sharing 등과 같이 다른 디바이스의 주요 정보를 전달 받거나, 본 개시의 다양한 실시예들에서는 Key를 공유하기 위한 주요 정보를 전달받거나,
상기 보조 디바이스가 직접 가입하지 않은 서비스를 기본 디바이스의 허락 아래 사용하거나,
상기 기본 디바이스의 주요 정보, 일 예로 인증서, ID, 패스워드(password: PW, 이하 "PW"라 칭하기로 한다) 등과 같은 주요 정보를 상기 서비스 제공자를 통해 안전하게 전달받고자 하는 서비스들을 포함할 수 있다.
이후, 상기 Service Provider는 상기 보조 디바이스에게 Secure한 서비스 접속 정보를 전달한다(2. 서비스 접속 정보 전달(N/W Access 정보, 서버 URL, Service ID 등).
여기서, 상기 서비스 접속 정보는 일시적으로 사용 가능한 네트워크 Access 정보, 서비스 관련 Service URL, Service ID 등을 포함할 수 있다.
또한, 상기 서비스 제공자는 필요에 따라 상기 보조 디바이스가 Rooting 되지 않았는지, Application이 신뢰성 있는 Appliation인지 등과 같은 검사를 수행하는 동작이 미리 수행될 수도 있다.상기 기본 디바이스와 상기 보조 디바이스간에 NFC 커넥션이 성립된 상태에서(NFC Connection Established) 상기 보조 디바이스는 상기 기본 디바이스로 서비스 허용 (Key Sharing 또는 정보 공유 또는 로그인 허락 등)을 요청한다(3. 정보 공유 요청(서비스 접속 정보, Client ID).
여기서, 상기 보조 디바이스는 상기 서비스 제공자로부터 수신한 서비스 접속 정보를 상기 기본 디바이스로 전달할 수 있다. 즉, 상기 보조 디바이스는 서비스 접속 정보와 상기 보조 디바이스 자신의 ID, 즉 Client ID를 포함하여 서비스 허용을 요청할 수 있다.
그리고, 상기 기본 디바이스는 상기 보조 디바이스로부터 수신한 서비스 접속 정보를 기반으로 Service Provider(SP)에 접속한다(4. 서비스 접속 정보 기반 서버 접속).
그리고, 상기 기본 디바이스와 서비스 제공자 간에는 상기 기본 디바이스 인증을 위한 절차가 수행된다. 즉, 상기 서비스 제공자는 상기 서비스에 대해 허가할 수 있는지 검증하기 위해 상기 기본 디바이스를 검증한다(5. Owner 인증(계정 인증 또는 Digital Key 인증 등).
여기서, 상기 서비스 제공자는 상기 기본 디바이스에 Digital Key가 저장되어 있는지 검사함으로써 상기 기본 디바이스를 검증할 수 있다. 물론, 이는 상기 서비스 제공자와 기본 디바이스가 디지털 키를 공유한다고 가정할 경우에 가능하다.
이와는 달리 상기 서비스 제공자는 상기 기본 디바이스가 ID/PW 등과 같은 상기 서비스 제공자의 서비스에 기 가입/등록된 사용자가 맞는지 검사함으로써 상기 기본 디바이스를 검증할 수 있다. 물론, 이는 정보 전달/서비스 허용을 가정할 경우에 가능하다.
또한, 상기 서비스 제공자와 기본 디바이스는 부가적으로 상기 기본 디바이스의 사용자의 동의를 명확하게 구하기 위한 동작, 일 예로 사용자에 의한 확인 버튼 입력 또는 지문 인증 등과 같은 상기 기본 디바이스의 사용자의 동의를 명확하게 구하기 위한 동작을 추가적으로 수행할 수 있다.
그리고 나서, 상기 기본 디바이스는 상기 보조 디바이스에게 공유할 정보가 있는 경우, 해당 정보를 상기 서비스 제공자로 전달한다(6. 공유할 보안 정보 전달(예: Access Property 또는 보안 정보 그 자체).
상기 서비스 제공자는 상기 보조 디바이스가 요구하고, 상기 기본 디바이스가 확인해 준 정보/서비스를 상기 보조 디바이스에게 제공한다(7. 보안 정보 전달).
Case 1. 인증서 등과 주요 정보가 기본 디바이스에 저장된 경우, 상기 기본 디바이스는 상기 주요 정보를 서비스 제공자에 업로드한다.
Case 2. Digital Key 공유의 경우, 상기 기본 디바이스는 Key ID 와 Key Property 등을 서비스 제공자로 전달하고, 상기 서비스 제공자가 조건에 부합하는 Digital Key를 보조 디바아스에게 발급한다.
Case 3. 특정 서비스를 서비스 제공자가 제공만 하면 되는 경우, 일 예로 음악 감상 서비스 등과 같은 서비스를 서비스 제공자가 제공만 하면 되는 경우, 상기 "6" 동작은 생략 가능하고 "5" 동작에서의 보조 디바이스 인증 후 바로 서비스를 제공한다.
도 38에서는 도 37의 디지털 키 제공 과정에 따른 보조 디바이스와, 기본 디바이스 및 서비스 제공자 간의 신호 송/수신 동작에 대해서 설명하였으며, 다음으로 제너릭 어트리뷰트 프로파일(generic attribute profile: GATT, 이하 "GATT"라 칭하기로 한다) 기반 블루투스 메시지에 대해서 설명하기로 한다.
먼저, 어트리뷰트 프로토콜(attribute protocol: ATT, 이하 "ATT"라 칭하기로 하다)는 Attribute 들을 리드/라이트하는 등을 지원하는 프로토콜을 나타낸다. 즉, 상기 ATT는 Attribute을 송/수신하기 위한 프로토콜을 나타낸다.
또한, GATT는:송신될Attribute 가 어떻게 구성/정의 되어야 하는지 명시한 규격을 나타내며,
Attribute 로 본 개시의 다양한 실시예들에서의 "nonce / Public key" 등이 정의될 것이고,
특정 Attribute를 송/수신함으로써 서비스가 구현될 수 있다.
본 개시의 다양한 실시예들에서, CCC에서 정의할 Attribute 들의 논리 형태는 도 39에 나타낸 바와 같다.
도 39는 본 개시의 일 실시예에 따른 통신 시스템에서 Attribute 의 포맷을 개략적으로 도시한 도면이다.
도 39를 참조하면, Attribute Handle은 특정 attribute를 나타내는 index이며, 일 예로 2 octet 길이로 구현될 수 있다.
또한, Attribute Type은 UUID를 나타내며, 특정 attribute value가 정의하는 내용에 대해 설명한다. 또한, Attribute value 은 Attribute Type + Attribute Handle로서, 식별 가능한 Attribute의 실제 값을 나타낸다. 일 예로, Attribute Handle=0, Attribute Type=Nonce일 경우 , Attribute Value=1234이다.
도 39에서는 본 개시의 일 실시예에 따른 통신 시스템에서 Attribute 의 포맷에 대해서 설명하였으며, 다음으로 도 40을 참조하여 본 개시의 일 실시예에 따른 통신 시스템에서 GATT Profile Stack의 구조에 대해서 설명하기로 한다.
도 40은 본 개시의 일 실시예에 따른 통신 시스템에서 GATT Profile Stack의 구조를 개략적으로 도시한 도면이다.
도 40을 참조하면, 본 개시의 일 실시예에 따른 GATT Profile Stack은 오른쪽에 도시되어 있는 블루투스 저 에너지(Bluetooth low energy: BLE, 이하 "BLE"라 칭하기로 한다)를 기반으로 함을 알 수 있다.
도 40에서는 본 개시의 일 실시예에 따른 통신 시스템에서 GATT Profile Stack의 구조에 대해서 설명하였으며, 다음으로 도 41a 내지 도 41b를 참조하여 본 발명의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 또 다른 예에 대해서 설명하기로 한다.
도 41a 내지 도 41b는 본 발명의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 또 다른 예를 개략적으로 도시한 도면이다.
도 41a 내지 도 41b를 참조하면, 먼저 도 41a 내지 도 41b에 도시되어 있는 보조 디바이스 등록 과정은 보조 디바이스와 상기 보조 디바이스의 정보를 서비스 제공자에 어떻게 등록하는지를 나타낸다.
또한, 도 41a 내지 도 41b에는 상기 보조 디바이스가 "User Device(DKS Server)"로, 기본 디바이스가 "Owner Device(DKS Client)"로, 상기 서비스 제공자가 "Car OEM Back-End"로 도시되어 있음에 유의하여야만 할 것이다.
먼저, 상기 보조 디바이스는 SE와 Mobile UI를 포함하며, 상기 기본 디바이스는 Mobile UI와 SE를 포함한다. 또한, 상기 보조 디바이스는 SE와 Mobile UI를 포함하며, 상기 기본 디바이스는 Mobile UI와 SE를 포함한다.
도 41a 내지 도 41b에서, 설명의 편의상 상기 보조 디바이스에 포함되는 SE와 Mobile UI는 각각 "SE-A" 및 "Mobile UI-A"라 칭하기로 하며, 상기 기본 디바이스에 포함되는 SE와 Mobile UI는 각각 "SE-B" 및 "Mobile UI-B"라 칭하기로 한다.
여기서, 상기 Mobile UI-A 및 Mobile UI-B 각각은 다른 디바이스와의 P2P 통신을 가능하게 한다. 또한, 상기 Mobile UI-A 및 Mobile UI-B는 각각 상기 SE-A 및 SE-B 각각에 억세스할 수 있다. 즉, Mobile UI는 다른 디바이스와의 P2P 통신을 가능하게 하고, SE에 억세스할 수 있는 엔터티를 나타낸다.
먼저, 상기 기본 디바이스에 포함되는 Mobile UI-B가 활성화되며(Activation of Owner Mobile UI), 이에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 어플리케이션 시작 및 루팅 체크(rooting check) 등에 의해 상기 Mobile UI-B가 실행되며(a. Start app and rooting check), 키 전달하기/키 공유하기 등과 같은 메뉴가 선택된다(b. Select "to share my Key). 상기 어플리케이션 루팅 체크는 서비스 개발에 따라 어플리케이션의 실행시에 수행되거나 혹은 특정 기능이 필요로 될 때 수행될 수 있다. 또한, 상기 Mobile UI-B의 제공자 혹은 서비스 제공자의 정책에 따라 필요할 경우 사용자 인증(user authentication) 프로세스가 수행될 수 있으며 (c. User Authentication), 상기 사용자 인증 프로세스는 상기 기본 디바이스에 미리 등록되어 있는 개인 식별 번호(personal identification number: PIN, 이하 "PIN"이라 칭하기로 한다)를 기반으로 수행될 수 있거나, 혹은 생체 인식 등을 기반으로 수행될 수 있다. 그리고 나서, 상기 Mobile UI-B는 NFC P2P 모드로 그 동작을 시작한다(d. Start NFC P2P operation).
한편, 상기 Mobile UI-B의 활성화 프로세스에서 루팅 체크를 제외한 나머지 동작들은 선택적(optional)일 수 있으며, 상기 Mobile UI-B의 제공자의 구현에 따라 수행될 수도 있고 혹은 생략될 수도 있다. 또한, 상기 Mobile UI-B는 하나 혹은 그 이상의 어플리케이션 루팅 체크 메카니즘을 지원한다(Mobile UI shall support one or more app rooting check mechanism).
또한, 상기 보조 디바이스에 포함되는 Mobile UI-A가 활성화되며(Activation of User Mobile UI), 이에 대해서 구체적으로 설명하면 다음과 같다. 도 41a 내지 도 41b에서는 상기 보조 디바이스가 적어도 하나의 Mobile UI를 설치했다고 가정된 것임에 유의하여야만 한다.
먼저, 어플리케이션 시작 및 루팅 체크 등에 의해 상기 Mobile UI-A가 실행되며(a. Start app and rooting check), 키 공유하기 등과 같은 메뉴가 선택된다(b. Select "to have shared key). 상기 어플리케이션 루팅 체크는 서비스 개발에 따라 어플리케이션의 실행시에 수행되거나 혹은 특정 기능이 필요로 될 때 수행될 수 있다. 또한, 상기 Mobile UI-A는 NFC P2P 모드로 그 동작을 시작한다(c. Start NFC P2P operation).
한편, 상기 Mobile UI-A의 활성화 프로세스에서 루팅 체크를 제외한 나머지 동작들은 선택적일 수 있으며, 상기 Mobile UI-A의 제공자의 구현에 따라 수행될 수도 있고 혹은 생략될 수도 있다. 또한, 상기 Mobile UI-A는 하나 혹은 그 이상의 어플리케이션 루팅 체크 메카니즘을 지원한다(Mobile UI shall support one or more app rooting check mechanism).
그리고 나서, 상기 보조 디바이스와 기본 디바이스간에는 NFC방식에서 다른 방식, 일 예로 블루투스 혹은 WiFi 등과 같은 다른 방식으로의 핸드오버가 수행된다(NFC Handover to a Bluetooth). 이에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 상기 Mobile UI-B는 상기 Mobile UI-A로 NFC에서 블루투스로 핸드오버할 것을 요청하는 메시지, 일 예로 handover request를 송신한다([01] Handover Request (BT)). 상기 Mobile UI-B로부터 handover request 메시지를 수신한 Mobile UI-A는 블루투스로 핸드오버하기로 선택한 후, 상기 Mobile UI-B로 핸드오버하기로 선택하였음을 나타내는 메시지, 일 예로 handover select 메시지를 송신한다([02] Handover Select (BT)). 즉, 상기 기본 디바이스는 핸드오버 요청자(handover requester)가 되고, 상기 보조 디바이스는 핸드오버 선택자(handover selector)가 된다. 또한, 상기 NFC에서 블루투스로의 핸드오버 동작에 대한 보다 구체적인 사항들은 NFC 커넥션 핸드오버 기술 규격(NFC Connection Handover Technical Specification [xx]) 및 블루투스 보안 심플 페어링 규격(Bluetooth Secure Simple Pairing specification [xx])에서 설명되고 있는 바와 동일함에 유의하여야만 할 것이다. 또한, 범용 고유 식별자(universally unique identifier: UUID, 이하 "UUID"라 칭하기로 한다)로 일 예로 "3cbb4363-dd09-4856-94e4-416605fa8fcb"이 핸드오버시 사용될 수 있다.
상기한 바와 같은 handover request 메시지 및 handover select 메시지 교환에 따라 상기 Mobile UI-B와 Mobile UI-A 간에는 블루투스 커넥션이 성립된다([03] Bluetooth Connection Establishment).
이렇게, 상기 Mobile UI-B와 Mobile UI-A 간에 블루투스 커넥션이 성립됨에 따라 상기 보조 디바이스와, 기본 디바이스와, 서비스 제공자간에는 블루투스 커넥션을 통한 통신이 수행된다(Communication through Bluetooth Connection).
상기 Mobile UI-B는 상기 서비스 제공자로 근접성 트리거링 키 공유를 개시할 것임을 나타내는, 즉 근접 터치를 기반으로 하는 키 공유 프로세스가 개시됨을 나타내는 메시지, 일 예로 근접성 트리거링 키 공유 개시(proximity triggering key sharing initiation) 메시지(이하, "proximity triggering key sharing initiation 메시지"라 칭하기로 한다)를 송신한다([04] Proximity Triggering Key Sharing initiation). 상기 Mobile UI-B와 서비스 제공자간의 인터페이스는 다양한 형태들로 구현될 수 있으며, 여기서는 그 상세한 설명을 생략하기로 한다.
상기 Mobile UI-B로부터 proximity triggering key sharing initiation 메시지를 수신한 서비스 제공자는 랜덤(random) 변수인 nonce를 생성한다. 여기서, 상기 nonce는 상기 보조 디바이스의 정보를 수신 및 검증할 때 사용되는데, 이는 상기 보조 디바이스의 정보를 생성할 때 nonce를 이용함으로써, 상기 보조 디바이스의 정보가 재사용되는 것을 방지하기 위함이다. 또한, 상기 nonce는 키 공유 프로세스가 시작될 때마다 새롭게 생성되며, 보조 디바이스에 대한 고유한 정보가 생성될 수 있다. 또한, 도 41a 내지 도 41b에서는 상기 nonce가 상기 서비스 제공자에서 생성된다고 가정하지만, 상기 nonce는 상기 기본 디바이스에서 생성될 수도 있음은 물론이다. 상기 nonce가 상기 기본 디바이스에서 생성될 경우 하기에서 설명될 [08] 동작에서 상기 기본 디바이스가 생성한 nonce를 상기 서비스 제공자로 송신하여 상기 서비스 제공자가 상기 기본 디바이스가 생성한 nonce를 기반으로 상기 보조 디바이스를 검증하는 것을 가능하게 한다.
그리고 나서, 상기 서비스 제공자는 상기 Mobile UI-B로 상기 보조 디바이스의 정보를 요청하는 메시지, 일 예로 user information request 메시지를 송신한다([05] User Information Request (Nonce = n)). 여기서, 상기 user information request 메시지는 상기 서비스 제공자에 의해 생성된 nonce를 포함하며, 도 41a 내지 도 41b에서는 상기 nonce가 "n"으로 생성되었다고 가정하기로 한다(nonce = n).
상기 서비스 제공자로부터 user information request 메시지를 수신한 Mobile UI-B는 상기 Mobile UI-A로 상기 보조 디바이스에 대한 사용자 정보를 요청하는 라이트 요청(write request) 메시지(이하, "write request 메시지"라 칭하기로 한다)를 송신한다([06] Write Request (n)). 여기서, 상기 write request 메시지는 키 공유를 위한 사용자 정보를 요청하는 메시지로서 사용되며, 상기 user information request 메시지를 통해 수신된 nonce가 포함된다.
상기 Mobile UI-B로부터 write request 메시지를 수신한 Mobile UI-A는 키 공유를 위해 사용자 정보가 요청됨을 검출하게 된다. 따라서, 상기 Mobile UI-A는 상기 보조 디바이스에 대한 사용자 정보를 생성하는 사용자 정보 생성 동작을 수행한다(Generation of User Information). 여기서, 상기 사용자 정보 생성 동작에 대해서 설명하면 다음과 같다.
먼저 상기 Mobile UI-A는 공중 키(public key)와 사설 키(private key)를 포함하는 공중/사설 키 페어(public/private key pair, 이하 "public/private key pair"라 칭하기로 한다)(U.Kpub, U.Kpriv)를 생성한다. 여기서, U.Kpub는 상기 보조 디바이스, 즉 사용자 디바이스에 의해 생성된 공중 키를 나타내며, U.Kpriv는 상기 보조 디바이스, 즉 사용자 디바이스에 의해 생성된 사설 키를 나타낸다. 그리고 나서, 상기 Mobile UI-A는 상기 public/private key pair에 대한 ID인 핸들 h(handle h, 이하 "handle h"라 칭하기로 한다)를 생성한다. 도 41a 내지 도 41b에서는 상기 handle h가 상기 public/private key pair에 대한 ID로서 사용되지만, 상기 handle h는 상기 보조 디바이스를 대표하는 ID가 될 수 있음은 물론이다.
그리고 나서, 상기 Mobile UI-A는 상기 public/private key pair(U.Kpub, U.Kpriv)와 handle h를 기반으로 사용자 정보를 생성한다. 여기서, 상기 사용자 정보는 SE ID와 MSISDN를 포함한다. 상기 MSISDN는 GSM 혹은 UMTS 이동 네트워크에서 가입자 단말기를 식별하는 고유 번호로서, 이동 전화기 혹은 셀룰라 전화기에서 가입자 식별 모듈(subscriber identity module: SIM, 이하 "SIM"이라 칭하기로 한다)에 할당되는 전화 번호를 나타낸다. 또한, 필요에 따라 상기 사용자 정보는 상기 보조 디바이스에 대한 SE Issuer 정보와, 어플리케이션 버전(application version: App version, 이하 "APP version"이라 칭하기로 한다)과, 상기 보조 디바이스의 IMEI와, 상기 보조 디바이스의 SE에 대한 인증서와, 상기 보조 디바이스의 모델 명, 상기 보조 디바이스의 제조사 명, 상기 보조 디바이스의 S/N 등을 추가적으로 포함할 수 있다. 여기서, 상기 사용자 정보는 상기 보조 디바이스를 식별하고, 상기 보조 디바이스의 사용자를 식별하기 위해 사용되며, 일 예로 SE Identifier, IMEI 등은 상기 보조 디바이스를 식별하기 위해 사용되며, 상기 MSISDN 등은 상기 보조 디바이스의 사용자를 식별하기 위해 사용된다.
상기 Mobile UI-A는 상기 사용자 정보(u)와, handle h와, 상기 보조 디바이스의 공중 키인 U.Kpub와, 상기 nonce, 즉 n를 상기 보조 디바이스의 사설 키인 U.Kpriv로 서명하여 사용자 서명(user signature), 즉 Uinfo.Signature를 생성한다. 도 41a 내지 도 41b에서 사용자 정보 특성(user information characteristic)은 상기 handle h와, 상기 사용자 정보(u)와, 상기 보조 디바이스의 공중 키인 U.Kpub와, 상기 보조 디바이스의 사용자 서명 Uinfo.Signature를 포함한다.
상기에서 설명한 바와 같이 사용자 정보가 생성되면, 상기 Mobile UI-A는 상기 Mobile UI-B로 상기 라이트 요청 메시지에 대한 응답 메시지, 일 예로 라이트 응답(write response) 메시지(이하, "write response 메시지"라 칭하기로 한다)를 송신한다([07] Write Response()). 여기서, 상기 write response 메시지는 상기 보조 디바이스가 상기 서비스 제공자에 의해 생성된 nonce를 기반으로 성공적으로 사용자 정보를 생성하였음을 나타낸다.
상기 Mobile UI-A로부터 write response 메시지를 수신한 Mobile UI-B는 상기 Mobile UI-A로 사용자 정보를 리드할 것을 요청하는 메시지, 일 예로 리드 요청(read request) 메시지(이하, "read request 메시지"라 칭하기로 한다)를 송신한다([08] Read Request (User Information characteristic UUIC)). 여기서, 상기 read request 메시지는 상기 기본 디바이스의 사용자 정보 특성 및 UUID를 포함한다.
상기 Mobile UI-B로부터 read request 메시지를 수신한 Mobile UI-A는 상기 Mobile UI-B로 상기 read request 메시지에 대한 응답 메시지, 일 예로 리드 응답(read response) 메시지(이하, "read response 메시지"라 칭하기로 한다)를 송신한다([09] Read Response (User Information characteristic)). 여기서, 상기 read response 메시지는 상기 보조 디바이스의 사용자 정보 특성을 포함한다.
상기 Mobile UI-A로부터 read response 메시지를 수신한 Mobile UI-B는 사전 확인(pre-confirmation) 동작을 수행한다([Owner pre-confirmation]). 여기서, 상기 사전 확인 동작에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 상기 Mobile UI-B는 상기 Mobile UI-A로부터 수신한 상기 보조 디바이스의 공중 키 U.Kpub를 기반으로 상기 보조 디바이스의 사용자 서명 Uinfo.Signature를 검증한다. 상기 보조 디바이스의 사용자 서명 Uinfo.Signature에 대한 검증 결과가 성공을 나타내면, 상기 Mobile UI-B는 상기 기본 디바이스의 사용자 정보를 출력한다. 그리고, 상기 출력된 기본 디바이스의 사용자 정보가 확인될 경우, 상기 Mobile UI-B는 상기 기본 디바이스, 즉 SE-B에 저장되어 있는 디지털 키 또는 상기 디지털 키와 유사한 권한을 가지는 키를 사용하여 상기 기본 디바이스의 사용자 정보를 서명한다. 여기서, 상기 기본 디바이스가 상기 SE-B에 저장되어 있는 디지털 키를 사용할 경우 디지털 키 서명을 위한 APDU을 사용한다. 상기 디지털 키 서명을 위한 APDU는 상기에서 도 32를 참조하여 구체적으로 설명하였으므로, 여기서는 그 상세한 설명을 생략하기로 한다.
그리고 나서, 상기 Mobile UI-B는 상기 서비스 제공자로 상기 user information request 메시지에 대한 응답 메시지, 일 예로 사용자 정보 응답(user information response) 메시지(이하, "user information response 메시지"라 칭하기로 한다)를 송신한다([10] User Information Response (User Information, DK. signatuer, (opt) n)). 여기서 상기 user information response 메시지는 상기 보조 디바이스의 사용자 정보와, 디지털 키 서명을 포함한다. 또한, 상기 user information response 메시지는 필요에 따라 nonce, 즉 n을 포함할 수 있다.
상기 Mobile UI-B로부터 user information response 메시지를 수신한 서비스 제공자는 상기 기본 디바이스에 대한 검증 동작 및 상기 보조 디바이스에 대한 등록 동작을 수행한다(Owner verification and User enrollment). 여기서, 상기 기본 디바이스에 대한 검증 동작 및 상기 보조 디바이스에 대한 등록 동작에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 상기 서비스 제공자는 상기 기본 디바이스의 디지털 키에 대한 검증 동작을 수행하여 상기 기본 디바이스가 실제 디지털 키를 소유하고 있는 소유자 디바이스인지, 또한 상기 기본 디바이스가 상기 소유자 디바이스로서의 적합한 권한을 가지고 있는지 검사한다(a. Digital Key signature verification). 그리고 나서, 상기 서비스 제공자는 상기 Mobile UI-B로부터 수신한 상기 보조 디바이스의 사용자 정보, 즉 상기 기본 디바이스의 디지털 키를 사용하여 서명된 상기 보조 디바이스의 사용자 정보를 저장한다. 여기서, 상기 서비스 제공자는 상기 보조 디바이스의 사용자 정보를 임시로 저장할 수 있으며, 상기 보조 디바이스의 사용자 정보는 SE ID와, MSISDN와, U.Kpub와, handle h 등을 포함할 수 있다(b. U.Info, handle, U.Kpub enrollment). 그리고 나서 상기 서비스 제공자는 상기 보조 디바이스와 상기 서비스 제공자간에 공유될 SHS를 생성하고, 상기 SHS를 상기 보조 디바이스의 공중 키 U.Kpub로 암호화하여 OTP를 생성한다(c. Create OTP = enc(U.Kpub, SHS). 여기서, 상기 SHS는 이후에 상기 보조 디바이스의 검증에 사용되는 값이다. 즉, 상기 서비스 제공자는 상기 보조 디바이스가 상기 SHS를 보유하고 있는지 등을 검사하여 상기 보조 디바이스를 검증할 수 있다. 또한, 상기 OTP는 상기 서비스 제공자에서 상기 기본 디바이스를 통해 상기 보조 디바이스로 SHS를 전달하는데, 상기 보조 디바이스 이외의 다른 어떤 디바이스가 상기 SHS를 획득하는 것을 방지하기 위해서이다.
상기 기본 디바이스에 대한 검증 동작 및 상기 보조 디바이스에 대한 등록 동작을 수행한 후, 상기 서비스 제공자는 상기 Mobile UI-B로 상기 보조 디바이스에 대한 등록 결과를 나타내는 메시지, 일 예로 사용자 등록 결과(user registration result) 메시지(이하, "user registration result 메시지"라 칭하기로 한다)를 송신한다([11] User Registration Result (OTP)). 여기서, 상기 user registration result 메시지가 상기 보조 디바이스가 성공적으로 등록되었음을 나타낼 경우 상기 user registration result 메시지는 상기 OTP를 포함한다.
상기 서비스 제공자로부터 user registration result 메시지를 수신한 Mobile UI-B는 상기 Mobile UI-A로 OTP를 저장할 것을 요청하는 write request 메시지를 송신한다([12] Write Request (OTP)). 여기서, 상기 write request 메시지는 상기 user registration result 메시지에 포함되어 있는 OTP를 포함한다. 상기 Mobile UI-B로부터 write request 메시지를 수신한 Mobile UI-A는 상기 OTP를 저장하고, 상기 OTP를 저장하였음을 나타내는 메시지, 즉, 상기 write request 메시지에 대한 응답 메시지인 write response 메시지를 송신한다([13] Write Response ()).
그리고 나서, 상기 Mobile UI-A는 상기 보조 디바이스의 사설 키인 U.KPriv를 사용하여 상기 OTP를 복호하여 SHS를 획득한다(Acquisition of SHS; User Mobile UI calculates SHS from OTP and U.KPriv).
도 41a 내지 도 41b는 본 발명의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 또 다른 예에 대해서 설명하였으며, 다음으로 도 42a 내지 도 42b를 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 검증 과정의 또 다른 예에 대해서 설명하기로 한다.
도 42a 내지 도 42b는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 검증 과정의 또 다른 예를 개략적으로 도시한 도면이다.
도 42a 내지 도 42b를 참조하면, 먼저 도 42a 내지 도 42b에 도시되어 있는 보조 디바이스 검증 과정은 보조 디바이스에 대해 디지털 키를 발급하기 전에 상기 보조 디바이스가 SHS를 소유하고 있는지 검사하고, 기본 디바이스로부터 상기 보조 디바이스를 확인한 후 상기 보조 디바이스에게 디지털 키를 공유하기 위한 보조 디바이스 검증 과정임에 유의하여야만 할 것이다.
또한, 도 42a 내지 도 42b에는 상기 보조 디바이스가 "User Device(DKS Server)"로, 기본 디바이스가 "Owner Device(DKS Client)"로, 상기 서비스 제공자가 "Car OEM Back-End"로 도시되어 있음에 유의하여야만 할 것이다. 또한, 상기 보조 디바이스는 SE와 Mobile UI를 포함하며, 상기 기본 디바이스는 Mobile UI와 SE를 포함한다. 도 42a 내지 도 42b에서, 설명의 편의상 상기 보조 디바이스에 포함되는 SE와 Mobile UI는 각각 "SE-A" 및 "Mobile UI-A"라 칭하기로 하며, 상기 기본 디바이스에 포함되는 SE와 Mobile UI는 각각 "SE-B" 및 "Mobile UI-B"라 칭하기로 한다.
먼저, SHS를 획득한 보조 디바이스의 Mobile UI-A는 상기 서비스 제공자로 디지털 키를 공유하는 서비스인 키 공유(key sharing) 서비스(이하, "key sharing"라 칭하기로 한다)를 신청한다. 즉, 상기 보조 디바이스는 상기 서비스 제공자로 key sharing 서비스를 요청하는 키 공유 트리거링(key sharing triggering) 메시지(이하, "key sharing triggering 메시지"라 칭하기로 한다)를 송신한다([14] Key Sharing triggering by User(h)). 여기서, 상기 key sharing triggering 메시지는 handle h를 포함하며, 따라서 상기 서비스 제공자는 상기 handle h를 기반으로 어떤 보조 디바이스가 key sharing 서비스를 요청하는지 알 수 있다. 상기 보조 디바이스를 보다 명확하게 식별하는 것이 가능하도록 하기 위해 상기 key sharing triggering 메시지는 상기 handle h 뿐만 아니라 MSISDN과, SE ID와, IMEI 등과 같은 값을 추가로 포함할 수 있다.
상기 Mobile UI-A로부터 key sharing triggering 메시지를 수신한 서비스 제공자는 상기 보조 디바이스의 Mobile UI-A로 상기 보조 디바이스를 검증할 것을 요청하는 사용자 검증 요청(user verification request) 메시지(이하, "user verification request 메시지"라 칭하기로 한다)를 송신한다([15] User Verification Request (Challenge)). 여기서, 상기 user verification request 메시지는 챌린지(challenge)를 포함한다.
상기 Mobile UI-A가 상기 user verification request 메시지에 포함되어 있는 challenge를 기반으로 상기 서비스 제공자가 예상한 답변을 생성한 후, 상기 서비스 제공자에게 송신한다면, 상기 서비스 제공자는 상기 보조 디바이스가 성공적으로 검증되었다고 결정할 수 있다.
한편, 상기 user verification request 메시지가 상기 기본 디바이스를 위한 challenge와 보조 디바이스를 위한 challenge를 포함할 수도 있다.
또한, 상기 서비스 제공자는 상기 기본 디바이스에게만 사용자 ID에 대한 정보를 전달하기 위해 상기 기본 디바이스의 공중 키를 사용하여 상기 기본 디바이스의 사용자 정보를 암호화한 후 상기 user verification request 메시지에 포함시킬 수 있다. 이 경우, 상기 기본 디바이스의 사용자 정보는 상기 보조 디바이스를 통해 전달되지만, 상기 기본 디바이스만 상기 기본 디바이스의 공중 키를 사용하여 복호할 수 있으므로 보안 성능이 향상될 수 있다. 이 경우, 상기 서비스 제공자는 상기 기본 디바이스의 사설 키에 대응되는 공중 키를 미리 보유하고 있으며, 상기 기본 디바이스의 사설 키에 대응되는 공중 키는 일 예로 상기 기본 디바이스와 상기 서비스 제공자간의 최초 키 발급 프로세스에서 발급될 수 있다.
한편, 도 42a 내지 도 42b에서는 상기 user verification request 메시지가 1개의 challenge를 포함하고, 상기 1개의 challenge에 대해 상기 보조 디바이스와 상기 기본 디바이스가 각각 상기 challenge를 기반으로 답변을 작성하는 경우에 대해서 설명하기로 한다.
상기 서비스 제공자로부터 user verification request 메시지를 수신한 Mobile UI-A는 사용자 챌린지 응답(user challenge response, 이하 "user challenge response"라 칭하기로 한다) 계산 동작을 수행한다(Calculate User Challenge Response, cRes = Hash (SHS, Challenge)). 상기 user challenge response 계산 동작에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 상기 Mobile UI-A는 상기 user verification request 메시지에 포함되어 있는 challenge를 기반으로 challenge response를 계산한다. 여기서, 상기 challenge response는 하기 수학식 1과 같이 계산될 수 있다.
<수학식 1>
cRes = Hash(SHS, Challenge)
상기 수학식 1에서 cRes는 challenge response를 나타내며, 상기 challenge response는 상기 수학식 1에 나타낸 바와 같이 SHS와 challenge를 기반으로 생성됨을 알 수 있다.
또한, 상기 challenge response를 상기 보조 디바이스의 사설 키인 U.Kpriv를 사용하여 서명서를 추가적으로 생성할 수 있다.
한편, 상기 보조 디바이스와, 기본 디바이스와, 서비스 제공자 간에는 기본 디바이스 최종 확인 동작이 수행된다((opt.) Owner Final Confirmation). 여기서, 상기 기본 디바이스 최종 확인 동작에 대해서 구체적으로 설명하면 다음과 같다.
먼저, 상기 서비스 제공자에 의해 상기 기본 디바이스 최종 확인 동작이 트리거된다([16] Owner confirmation triggering). 상기 서비스 제공자의 트리거링에 따라 상기 Mobile UI-B는 상기 Mobile UI-A에게 상기 기본 디바이스의 challenge를 요청하는 메시지, 일 예로 read request 메시지를 송신한다([17] Read Request (Owner Challenge UUID)). 여기서, 상기 read request 메시지는 상기 기본 디바이스의 UUID를 포함한다.
상기 Mobile UI-B로부터 read request 메시지를 수신한 Mobile UI-A는 challenge response 를 계산하고, 상기 Mobile UI-B로 상기 read request 메시지에 대한 응답 메시지인 read response 메시지를 송신한다([18] Read Response (Owner Challenge)). 상기 read response 메시지는 상기 user verification request 메시지에 포함되어 있는 challenge와, 상기 계산된 challenge response를 포함한다. 여기서, 상기 user verification request 메시지가 1개의 challenge를 포함하는 것이 아니라 상기 기본 디바이스를 위한 challenge와 보조 디바이스를 위한 challenge를 포함할 경우, 상기 read response 메시지는 상기 기본 디바이스를 위한 challenge를 포함할 수 있다. 또한, 상기 user verification request 메시지가 상기 기본 디바이스의 공중 키를 사용하여 암호화된, 상기 기본 디바이스의 사용자 정보를 포함할 경우, 상기 read response 메시지는 상기 기본 디바이스의 공중 키를 사용하여 암호화된, 상기 기본 디바이스의 사용자 정보를 포함할 수 있다.
한편, 상기 Mobile UI-A로부터 상기 read response 메시지를 수신한 Mobile UI-B는 상기 기본 디바이스에 대한 최종 확인을 위한 확인 사항을 출력하고, 상기 확인 사항에 대한 최종 확인을 검출한다(a. Final confirmation request is displayed on Owner's screen; b. Owner's confirmation received). 여기서, 상기 Mobile UI-B는 상기 기본 디바이스에 대한 최종 확인을 위한 확인 사항을 상기 기본 디바이스에 포함되는 스크린에 디스플레이함으로써 상기 기본 디바이스에 대한 최종 확인을 위한 확인 사항을 출력할 수 있다. 한편, 상기 read response 메시지에 상기 기본 디바이스의 공중 키를 사용하여 암호화된, 상기 기본 디바이스의 사용자 정보가 포함되어 있을 경우, 상기 기본 디바이스의 공중 키를 사용하여 상기 기본 디바이스의 사용자 정보를 복호하고, 상기 복호된 결과를 상기 기본 디바이스에 포함되는 스크린에 디스플레이한다. 또한, 상기 기본 디바이스에 포함되는 스크린에 디스플레이되는 정보가 도 41a 내지 도 41b에서 설명된 바와 같은 사전 확인 동작에서 디스플레이되는 정보가 상이할 경우 중간자 공격(man in the middle attack) 등과 같은 보안 공격이 발생하였다고 예상할 수 있으므로, 상기 보조 디바이스에 대한 디지털 키 발급이 중단될 수 있다.
한편, 상기 확인 사항에 대한 최종 확인을 검출하면, 상기 Mobile UI-B는 상기 기본 디바이스에 저장되어 있는 디지털 키 혹은 상기 디지털 키에 준하는 권한을 가지는 키를 기반으로 상기 보조 디바이스를 최종적으로 확인한다. 여기서, 상기 최종 확인은 상기 기본 디바이스의 challenge response(oRes) 형태로 생성되며, 상기 challenge response(oRes)는 상기 보조 디바이스를 통해 상기 서비스 제공자로 전달되고, 상기 서비스 제공자는 상기 challenge response(oRes)를 검증한다. 상기 challenge response(oRes)는 일 예로 하기 수학식 2와 같이 계산될 수 있다.
<수학식 2>
oRes = Sign(Challenge, Digital Key, cRes)
상기 기본 디바이스가 상기 기본 디바이스에 포함되는 SE-B에 저장되어 있는 디지털 키를 사용할 경우 디지털 키 서명을 위한 APDU를 사용하여 challenge와 사용자 정보에 서명을 하여 상기 기본 디바이스의 challenge response (oRes)를 생성한다. 여기서, 상기 디지털 키 서명을 위한 APDU는 상기에서 도 32를 참조하여 구체적으로 설명하였으므로, 여기서는 그 상세한 설명을 생략하기로 한다.
한편, 상기 challenge response는 서명이 아닌 hash 등을 기반으로 생성될 수도 있으며, 이 경우 상기 challenge response(oRes)는 일 예로 하기 수학식 3과 같이 계산될 수 있다.
<수학식 3>
oRes = Hash(Challenge, Digital Key, cRes)
상기 기본 디바이스의 Mobile UI-B는 상기 생성된 challenge response(oRes)를 write request 메시지를 통해 상기 Mobile UI-A로 송신한다([19] Write Request(Owner Challenge)]). 상기 Mobile UI-B로부터 challenge response(oRes)를 포함하는 write request 메시지를 수신한 Mobile UI-A는 상기 challenge response(oRes)를 저장하고, 상기 write request 메시지에 대한 응답 메시지, 일 예로 write response 메시지를 송신한다([20] Write Response).
상기에서 설명한 바와 같이 기본 디바이스 최종 확인 동작이 수행된 후, 상기 Mobile UI-A는 상기 서비스 제공자로 상기 user verification request 메시지에 대한 응답 메시지, 일 예로 사용자 검증 응답 메시지(이하, "user verification response 메시지")를 송신한다([21] User Verification Response (cRes, oRes)). 여기서, 상기 user verification response 메시지는 상기 Mobile UI-A가 생성한 challenge response (cRes)와 상기 Mobile UI-B로부터 수신한 challenge response(oRes)를 포함한다. 여기서, 상기 challenge response(oRes)가 존재하지 않을 경우 상기 user verification response 메시지는 상기 Mobile UI-A가 생성한 challenge response(cRes)만을 포함할 수도 있음은 물론이다.
상기 Mobile UI-A로부터 user verification response 메시지를 수신한 서비스 제공자는 상기 user verification response 메시지에 포함되어 있는 challenge response들, 즉 cRes 및 oRes에 대한 검증 동작을 수행한다(User Verification: a. cRes verification; b. oRes verification). 상기 cRes 및 oRes에 대한 검증 결과가 성공적임을 나타낼 경우, 상기 서비스 제공자는 상기 보조 디바이스에게 디지털 키를 발급한다. 즉, 상기 서비스 제공자와 보조 디바이스간에는 CCC 프로세스에 따라 디지털 키 프로비져닝(provisioning) 프로세스가 진행된다([22] Digital Key Provisioning according to CCC general process).
그리고 나서, 상기 서비스 제공자는 상기 보조 디바이스에 대한 디지털 키 발급 결과를 나타내는 메시지를 상기 기본 디바이스로 송신하여 상기 기본 디바이스가 상기 보조 디바이스에게 디지털 키가 발급되었음을 인지할 수 있도록 할 수 있다([23] Notice of Client Digital Key provisioning result).
도 42a 내지 도 42b에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 검증 과정의 또 다른 예에 대해서 설명하였으며, 다음으로 블루투스 디지털 키 공유 서비스에 대해서 설명하기로 한다.
첫 번째로, 디지털 키 공유 서비스 특성들에 대해서 설명하기로 하며, 디지털 키 공유 서비스를 위한 디지컬 키 공유 서비스 특성들은 하기 표 14와 같이 나타낼 수 있다.
<표 14>
Figure pat00026
상기 표 14에 기재되어 있는 각 특성에 대해서 설명하면 다음과 같다.
첫 번째로, Nonce 특성은 하기 표 15와 같이 나타낼 수 있다.
<표 15>
Figure pat00027
두 번째로, User Information 특성은 보조 디바이스, 즉 사용자 스마트 디바이스의 정보를 설명하기 위해 사용될 수 있으며, DKSC는 DKSS로부터 상기 User Information 특성을 리드할 수 있다. 일 예로, 상기 User Information 특성은 기본 디바이스가 보조 디바이스로부터 사용자 정보를 리드할 때 사용되는 특성이다.
또한, 상기 User Information 특성은 디지털 키를 수신할 보조 디바이스의 사용자 정보를 나타내기 위해 사용된다.
상기 User Information 특성은 하기 표 16과 같이 나타낼 수 있다.
<표 16>
Figure pat00028
상기 표 16에서 SE Identifier는 unit 32로도 구현될 수 있고 unit 64로도 구현될 수 있다.
또한, 상기 표 16에서 MSISDN과 SE Identifier는 그 상태(status)가 Conditional로 기재되어 있지만, 상기 MSISDN과 SE Identifier는 Mandatory로 구현될 수도 있음은 물론이다. 상기 표 16에서 "C~"는 해당 Attribute Type이 Conditional로 구현될 수 있음을 나타내고, "O"는 Optional로 구현될 수 있음을 나타내고, "M"은 Mandatory로 구현될 수도 있음을 나타낸다.
또한, 상기 User Public Key는 GPCS ECC Key Length 와 유사하게 구현될 수 있으며, User Signature는 GPCS amd B.3.1.1 와 유사하게 구현될 수 있으며, Signature scheme = RSASSA-PKCS-v1_5 as defined in PKCS#1, hash function is SHA-1이다.
또한, 상기 MSISDN과, SE Identifier와, IMEI와, Device Serial Number 중 적어도 하나는 User ID로 사용될 수 있다.
세 번째로, DKS OTP 특성은 DKS Client(소유자 디바이스)이 DKS Server(사용자 디바이스)에 OTP를 전달(write)할 때 사용하는 특성이다.
상기 DKS OTP 특성은 하기 표 17과 같이 나타낼 수 있다.
<표 17>
Figure pat00029
네 번째로, Owner Challenge 특성에 대해서 설명하기로 한다.
상기 Owner Challenge 특성은 DKS Client(소유자 디바이스)가 DKS Server(사용자 디바이스)로부터 Challenge를 읽어올 때 사용하는 특성이다.
상기 Owner Challenge 특성은 하기 표 18에 나타낸 바와 같다.
<표 18>
Figure pat00030
다섯 번째로, Owner Challenge Result 특성에 대해서 설명하기로 한다.
상기 Owner Challenge Result 특성은 DKS Client(소유자 디바이스)이 DKS Server(사용자 디바이스)에 Owner Challenge 결과를 전달(write)할 때 사용하는 특성이다.
상기 Owner Challenge Result 특성은 하기 표 19와 같이 나타낼 수 있다.
<표 19>
Figure pat00031
다음으로, 도 43을 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 또 다른 예에 대해서 설명하기로 한다.
도 43은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 또 다른 예를 개략적으로 도시한 도면이다.
도 43을 참조하면, 도 43에 도시되어 있는 보조 디바이스 등록 과정은 디지털 키 공유 과정에서 보조 디바이스를 등록할 때 GPS 정보 및 타임 스탬프(time stamp) 등과 같은 추가 정보를 함께 등록함으로써 기본 디바이스와 보조 디바이스가 동일 영역에 존재하는지 확인하고 디지털 키를 공유함으로써 중간자 공격(man in the middle attack) 등과 같은 보안 공격에 대해 보다 강인한 디지털 키 공유 서비스를 제공하는 것을 가능하게 하는 보조 디바이스 등록 과정임에 유의하여야만 할 것이다.
또한, 도 43에는 기본 디바이스가 "Owner"로, 보조 디바이스가 "Client"로 도시되어 있음에 유의하여야만 할 것이다.
도 43에 도시되어 있는 바와 같이 기본 디바이스와 보조 디바이스가 키 공유 서비스를 선택하면(1. App 실행(Key 공유 선택), tap 절차가 수행되고(2. Tap), 상기 기본 디바이스는 내부적으로 tapping 시점의 GPS 및 절대 시간을 획득한다(3. 내부적으로 Tapping 시점의 GPS 및 절대 시간 확보(기준시, 기준 GPS)).
또한, 상기 보조 디바이스는 상기 보조 디바이스의 사용자 정보와 tapping 시점의 절대 시간, GPS를 획득한다(4. Info (SE Id, Client 인증서) + Tapping된 시점의 절대 시간, GPS 확보). 그리고 나서, 상기 보조 디바이스는 상기 기본 디바이스로 상기 보조 디바이스의 사용자 정보를 송신하며, 이때 절대 시간 및 GPS 정보가 함께 송신된다(5. Client 정보 전달(SE Id, Client 인증서, 시간, GPS).
상기 기본 디바이스는 상기 기본 디바이스의 기준 시간과, 기준 GPS 정보와, 상기 보조 디바이스로부터 수신된 시간 및 GPS 정보를 비교하고(6. 기준시, 기준 GPS와 Client의 시간/GPS 비교,검증), 상기 비교 결과 상기 보조 디바이스가 상기 기본 디바이스와 동일 영역에 존재한다고 판단될 경우 상기 기본 디바이스의 디지털 키를 사용하여 상기 기본 디바이스의 사용자 정보에 서명하고(7. DK 이용 서명), 상기 서명된 사용자 정보를 서비스 제공자에 등록한다(8. 대리 등록).
한편, 상기 보조 디바이스가 GPS 정보 및 시간 정보, 일 예로 time stamp를 상기 기본 디바이스로 송신하기 위해서 본 개시의 일 실시예에서는 사용자 정보 획득 기능(GetUserInformation Function)에 하기 표 20과 같이 파라미터를 추가한다. 물론, 상기 GetUserInformation Function이 아닌 다른 기능이라고 할지라도 상기 GetUserInformation Function와 유사한 기능이 존재할 경우, 해당 기능에는 GPS 정보 및 시간 정보를 나타내는 파라미터가 추가될 수도 있음은 물론이다.
<표 20>
Figure pat00032
도 43에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 보조 디바이스를 등록하는 과정의 또 다른 예에 대해서 설명하였으며, 다음으로 도 44를 본 개시의 또 다른 실시예에 따른 통신 시스템에서 기본 디바이스의 동작 과정의 또 다른 예에 대해서 설명하기로 한다.
도 44는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 기본 디바이스의 동작 과정의 또 다른 예를 개략적으로 도시한 도면이다.
도 44를 참조하면, 먼저 기본 디바이스가 "Owner"로 도시되어 있음에 유의하여야만 할 것이다.
도 44에서, 상기 GPS 및 time stamp 검증 동작은 디지털 키 제공 과정에서 수행되는 보조 디바이스 등록 과정 중 일 예로 소유자 사전 확인(Owner Pre-Confirmation) 동작에서 수행될 수 있다.
도 44에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 기본 디바이스의 동작 과정의 또 다른 예에 대해서 설명하였으며, 다음으로 도 45를 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 사용자 어플리케이션을 검증하는 과정의 일 예에 대해서 설명하기로 한다.
도 45는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 사용자 어플리케이션을 검증하는 과정의 일 예를 개략적으로 도시한 도면이다.
도 45를 참조하면, 먼저 디지털 키를 공유하는 과정에서 OS 영역에 존재하는 Mobile UI(=Application)를 통해서 User Information을 획득하기 때문에, OS가 루팅되었거나 Application이 해킹 공격 등으로 인해 감염된 경우, Application으로부터 전달받는 User Information의 신뢰성이 낮을 수 있다.
따라서, Mobile UI를 통하지 않는 주요 정보를User Secure Element 에서 직접 확보하여 User Application을 통해 얻은 정보와 비교함으로써 User application에 대한 추가 검증에 활용할 수 있다.
도 45에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 사용자 어플리케이션을 검증하는 과정의 일 예에 대해서 설명하였으며, 다음으로 도 46을 참조하여 에 대해서 설명하기로 한다.
도 46은 도 45의 사용자 어플리케이션을 검증하는 과정에 따른 신호 송/수신 동작을 개략적으로 도시한 도면이다.
도 46을 참조하면, 먼저 1. Owner 단말이 Client Information을 요청한다.
Client 단말이 SE ID와 Client.PK(Client의 Public key가 들어가있음)
Client Application을 통해 정보 획득을 완료 한 후, 두 번째 NFC Connection을 준비하여 다시 tapping 한다.
Owner Smart Device = NFC Reader하고, Client Smart Device (SE) = NFC Tag 처럼 동작
2. Owner 의 Application 직접 APDU 를 생성하여 NFC 로 Client 단말로 보낸다
3. Owner가 보낸 APDU가 NFC Controller를 거쳐 바로 SE 로 전달된다 (OS로 올라가지 않음)
APDU 명령 (GETDATA)에 따라 SE Identification (SE ID)가 APDU Response로 회신된다.
4. Owner Application은 Client Application을 통해 획득한 SE ID와 Client SE에서 직접 읽어온 SE ID를 비교하여, 두 값이 동일할 때 이후 절차를 수행한다.
(이후 절차 = Client Application이 보내온 인증서, Public key 등 다른 정보 검증 및 서명, 서버 등록 등)
도 46에서는 도 45의 사용자 어플리케이션을 검증하는 과정에 따른 신호 송/수신 동작에 대해서 설명하였으며, 다음으로 도 47을 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 또 다른 예에 대해서 설명하기로 한다.
도 47은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 또 다른 예를 개략적으로 도시한 도면이다.
도 47을 참조하면, 도 47에 도시되어 있는 보조 디바이스 등록 과정은 상기에서 설명한 바와 같은 다른 보조 디바이스 등록 과정의 예들과 다음과 같은 측면에서 차이를 가진다.
즉, 이전에서 설명한 바와 같은 보조 디바이스 등록 과정의 예들은 NFC를 easy setup에만 사용하고, 주요 데이터는 BT 등과 같은 2nd connectoin을 통해서 송/수신한다. 하지만, 도 47에서 설명되는 보조 디바이스 등록 과정은 Client Registration, Client의 Information 확보는 NFC를 통해서 진행하고, 그 이후의 절차는 BT 등과 같은 2nd connectoin을 통해서송/수신한다.
먼저, 두 디바이스들, 일 예로 클라이언트 디바이스, 즉 보조 디바이스와 소유자 디바이스, 즉 기본 디바이스가 NFC P2P 모드에서 동작을 시작한다.
이후에, Nonce 및 Client Info 정보는 NFC 포럼 데이터 교환 포맷(NFC forum data exchange format: NDEF, 이하 "NDEF"라 칭하기로 한다) 프로토콜을 이용하여 교환함을 알 수 있다.
도 47에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 디지털 키를 제공하는 과정에 포함되는 보조 디바이스 등록 과정의 또 다른 예에 대해서 설명하였으며, 다음으로 도 48을 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 신뢰되는 실행 환경(trusted execution environment: TEE, 이하 "TEE"라 칭하기로 한다)의 구조에 대해서 설명하기로 한다.
도 48은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 TEE의 구조를 개략적으로 도시한 도면이다.
도 48을 참조하면, 먼저 메인 프로세서의 일부를 보안 영역인 TEE와 일반 영역인 REE(Rich Execution Environment)로 나누어 비교적 민감한 정보의 저장과 처리를 보안 영역에서 수행하도록 한다. 어플리케이션 프로세서(application processor: AP, 이하 "AP"라 칭하기로 한다) 칩 안에 안드로이드 OS와 분리된 안전 영역에 별도의 보안 OS(Secure OS)를 구동시켜서 TEE를 구성할 수 있다. REE에서는 TEE로 접근 불가능하고 TEE에서 정의한 API를 통해서 한정적으로 보안 리소스에 접근 가능하다.
도 48에서, TA는 신뢰되는 어플리케이션(trusted application: TA, 이하 "TA"라 칭하기로 한다)을 나타내며, 상기 TA는 TEE 상에 설치/실행되며, 클라이언트 어플리케이션(client application: CA, 이하 "CA"라 칭하기 한다)은 REE 상에 설치/실행되며, TA에서 제공하는 기능들을 사용하는 어플리케이션이다.
도 48에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 TEE의 구조에 대해서 설명하였으며, 다음으로 도 49를 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 TEE에서 사용자 정보를 생성하는 과정에 대해서 설명하기로 한다.
도 49는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 TEE에서 사용자 정보를 생성하는 과정을 개략적으로 도시한 도면이다.
도 49를 참조하면, 먼저 소유자 디바이스와 사용자 디바이스간에 NFC PWP 세션이 생성되고(NFC P2P Session Created), PKI를 기반으로 어플리케이션 대 어플리케이션 보안 채널이 셋업된 후(App to App Secure Channel based on PKI) 상기 소유자 디바이스는 상기 사용자 디바이스로 키 공유 서비스 개시 및 디바이스 정보를 요청한다(1. Key Sharing initiate + Device Info request).
그리고 나서, User App이 TEE Client를 이용, TEE 영역에 있는 TA에 User Information을 요청한다(2. User Info 요청).
또한, TA가 SE에 직접 Access 하여 SE ID를 획득한다(3. Get SE ID, 4. SE ID)
상기 TA는 생성한 Device info에 서명한다(5. Device Info = Sig(SApp.SK, SE ID).
여기서, 상기 TA는 실시간으로 서명 및 암호화에 사용 할 Key Pair를 생성하거나,
TA 개발자가 설치 시에 탑재한 인증서의 key를 서명 및 암호화에 사용할 수 있다.
그리고 나서, 상기 TA는 CA(Clinet App)에 서명을 전달한다(6. rsp).
이 경우, User Info가 REE 대비 안전한 TEE에서 생성되어, User Info의 신뢰성이 향상될 수 있다.
도 49에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 TEE에서 사용자 정보를 생성하는 과정에 대해서 설명하였으며, 다음으로 도 50을 참조하여 본 개시의 또 다른 실시예에 따른 통신 시스템에서 소유자 디바이스에서 TEE를 사용하여 보증 동작을 수행하는 과정에 대해서 설명하기로 한다.
도 50은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 소유자 디바이스에서 TEE를 사용하여 보증 동작을 수행하는 과정을 개략적으로 도시한 도면이다.
도 50을 참조하면, TEE에 디지털 키와 유사한 레벨의 키 공유 서비스를 보증하기 위한 키가 확보된다.
도 50에서, 서비스 제공자, 즉 OEM은 CCC 규격에 따라 Digital Key를 SE에 저장한다 (1. Digital Key 주입)
OEM이 Owner App을 통해 TA에서 DK Sharing 보증용 Key Pair를 생성하도록 한다(2. Digital Key Sharing Service 용 Key 생성 Triggering)
그리고 나서, TA에서 DK Sharing 보증용 Key Pair를 생성하고, Public Key를 OEM 서버에 등록한다(3. DK Sharing Key 요청; 4. DK Shr Key Pair P.Shr.SK, P.Shr.PK 생성; 5. P.Shr. PK).
여기서, TA에 DK Sharing 보증용 Key를 설치/주입하는 것은 다양한 variation이 있을 수 있다.
일 예로 OEM이 Digital Key를 주입할 때, TA에 직접 Key를 주입할 수 있다.
도 50에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 소유자 디바이스에서 TEE를 사용하여 보증 동작을 수행하는 과정에 대해서 설명하였으며, 도 51에서는 본 개시의 또 다른 실시예에 따른 통신 시스템에서 TA에 저장된 디지털 키 공유 서비스 보증을 위한 키를 사용하여 서명 동작을 수행하는 과정에 대해서 설명하기로 한다.
도 51은 본 개시의 또 다른 실시예에 따른 통신 시스템에서 TA에 저장된 디지털 키 공유 서비스 보증을 위한 키를 사용하여 서명 동작을 수행하는 과정을 개략적으로 도시한 도면이다.
도 51을 참조하면, 먼저 TEE가 SE보다 연산 처리 능력이 뛰어나 속도가 더 빠르고 다양한 기능을 추가할 수 있다 있다.
먼저, 도 51에서 방법A는 REE 상의 일반 application으로부터 user info를 획득하는 방법을 나타내며, 방법B는 TA간 직접 BT 등 connectivity를 연결하여 User 단말의 TA로부터 직접 User Info를 획득하는 방법을 나타낸다.
그리고, 상기에서 설명한 바와 같은 본 개시의 다양한 실시예들에서 제시된 디지털 키 공유 과정에서는 SE에서 Sharing 용 서명 동작을 수행하는 반면,
도 51에서는 TA가 Client info에 대한 서명 동작을 수행한다.
이 경우, 특히 [6b] 동작에서 TA는 SE대비 연산 속도가 빠르므로, user info에 대한 검증을 직접 수행하도록 구현할 수 있다.
본 개시의 특정 측면들은 또한 컴퓨터 리드 가능 기록 매체(computer readable recording medium)에서 컴퓨터 리드 가능 코드(computer readable code)로서 구현될 수 있다. 컴퓨터 리드 가능 기록 매체는 컴퓨터 시스템에 의해 리드될 수 있는 데이터를 저장할 수 있는 임의의 데이터 저장 디바이스이다. 상기 컴퓨터 리드 가능 기록 매체의 예들은 리드 온니 메모리(Read-Only Memory: ROM)와, 랜덤-접속 메모리(Random-Access Memory: RAM)와, CD-ROM들과, 마그네틱 테이프(magnetic tape)들과, 플로피 디스크(floppy disk)들과, 광 데이터 저장 디바이스들, 및 캐리어 웨이브(carrier wave)들(상기 인터넷을 통한 데이터 송신과 같은)을 포함할 수 있다. 상기 컴퓨터 리드 가능 기록 매체는 또한 네트워크 연결된 컴퓨터 시스템들을 통해 분산될 수 있고, 따라서 상기 컴퓨터 리드 가능 코드는 분산 방식으로 저장 및 실행된다. 또한, 본 개시를 성취하기 위한 기능적 프로그램들, 코드, 및 코드 세그먼트(segment)들은 본 개시가 적용되는 분야에서 숙련된 프로그래머들에 의해 쉽게 해석될 수 있다.
또한 본 개시의 일 실시예에 따른 장치 및 방법은 하드웨어, 소프트웨어 또는 하드웨어 및 소프트웨어의 조합의 형태로 실현 가능하다는 것을 알 수 있을 것이다. 이러한 임의의 소프트웨어는 예를 들어, 삭제 가능 또는 재기록 가능 여부와 상관없이, ROM 등의 저장 장치와 같은 휘발성 또는 비휘발성 저장 장치, 또는 예를 들어, RAM, 메모리 칩, 장치 또는 집적 회로와 같은 메모리, 또는 예를 들어 CD, DVD, 자기 디스크 또는 자기 테이프 등과 같은 광학 또는 자기적으로 기록 가능함과 동시에 기계(예를 들어, 컴퓨터)로 읽을 수 있는 저장 매체에 저장될 수 있다. 본 개시의 일 실시예에 따른 방법은 제어부 및 메모리를 포함하는 컴퓨터 또는 휴대 단말에 의해 구현될 수 있고, 상기 메모리는 본 개시의 실시 예들을 구현하는 지시들을 포함하는 프로그램 또는 프로그램들을 저장하기에 적합한 기계로 읽을 수 있는 저장 매체의 한 예임을 알 수 있을 것이다.
따라서, 본 개시는 본 명세서의 임의의 청구항에 기재된 장치 또는 방법을 구현하기 위한 코드를 포함하는 프로그램 및 이러한 프로그램을 저장하는 기계(컴퓨터 등)로 읽을 수 있는 저장 매체를 포함한다. 또한, 이러한 프로그램은 유선 또는 무선 연결을 통해 전달되는 통신 신호와 같은 임의의 매체를 통해 전자적으로 이송될 수 있고, 본 개시는 이와 균등한 것을 적절하게 포함한다
또한 본 개시의 일 실시예에 따른 장치는 유선 또는 무선으로 연결되는 프로그램 제공 장치로부터 상기 프로그램을 수신하여 저장할 수 있다. 상기 프로그램 제공 장치는 상기 프로그램 처리 장치가 기 설정된 컨텐츠 보호 방법을 수행하도록 하는 지시들을 포함하는 프로그램, 컨텐츠 보호 방법에 필요한 정보 등을 저장하기 위한 메모리와, 상기 그래픽 처리 장치와의 유선 또는 무선 통신을 수행하기 위한 통신부와, 상기 그래픽 처리 장치의 요청 또는 자동으로 해당 프로그램을 상기 송수신 장치로 전송하는 제어부를 포함할 수 있다.
한편 본 개시의 상세한 설명에서는 구체적인 실시예에 관해 설명하였으나, 본 개시의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형할 수 있음은 물론이다. 그러므로 본 개시의 범위는 설명된 실시예에 국한되어 정해져서는 안되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.

Claims (20)

  1. 통신 시스템에서 제1 디바이스의 방법에 있어서,
    제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하기를 요청함을 검출하는 과정과;
    서비스 제공자로 상기 제2 디바이스의 정보를 등록하는 과정과;
    상기 서비스 제공자로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 인증 정보를 수신하는 과정과;
    상기 제2 디바이스로 상기 인증 정보를 송신하는 과정을 포함함을 특징으로 하는 통신 시스템에서 제1 디바이스의 방법.
  2. 제1항에 있어서,
    상기 제2 디바이스를 검증하는 과정을 더 포함함을 특징으로 하는 통신 시스템에서 제1 디바이스의 방법.
  3. 통신 시스템에서 제1디바이스의 방법에 있어서,
    서비스 제공자로 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는 서비스를 신청하는 과정과;
    상기 서비스 제공자로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제1 인증 정보를 수신하는 과정과;
    상기 제1 인증 정보와 상기 제1 디바이스의 보안 정보를 기반으로 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제2 인증 정보를 생성하는 과정과;
    상기 제2 인증 정보를 상기 제2 디바이스로 송신하는 과정을 포함함을 특징으로 하는 통신 시스템에서 제1 디바이스의 방법.

  4. 제3항에 있어서,
    상기 제2 인증 정보를 상기 제2 디바이스로 송신하는 과정은:
    상기 제2 디바이스와 커넥션(connection)을 셋업하는 과정과;
    상기 셋업된 커넥션을 통해 상기 제2 인증 정보를 상기 제2 디바이스로 송신하는 과정을 포함함을 특징으로 하는 통신 시스템에서 제1 디바이스의 방법.
  5. 통신 시스템에서 제2 디바이스의 방법에 있어서,
    제1 디바이스로 상기 제1 디바이스의 보안 정보를 공유하기를 요청하는 과정과;
    상기 제1 디바이스로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 인증 정보를 수신하는 과정과;
    상기 인증 정보를 기반으로 서비스 제공자와 인증 동작을 수행하는 과정과;
    상기 서비스 제공자로부터 상기 제1 디바이스의 보안 정보를 수신하는 과정을 포함함을 특징으로 하는 통신 시스템에서 제2 디바이스의 방법.
  6. 제5항에 있어서,
    상기 서비스 제공자와 인증 동작을 수행한 후 상기 서비스 제공자로 상기 제1 디바이스의 보안 정보를 공유하기를 요청하는 과정을 더 포함함을 특징으로 하는 통신 시스템에서 제2 디바이스의 방법.
  7. 통신 시스템에서 제2디바이스의 방법에 있어서,
    제1 디바이스와 커넥션(connection)을 셋업하는 과정과;
    상기 제1 디바이스로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제1 인증 정보와 상기 제1 디바이스의 보안 정보를 기반으로 생성된, 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제2 인증 정보를 수신하는 과정과;
    서비스 제공자로 상기 제1 디바이스의 보안 정보를 공유하기를 요청하는 과정과;
    상기 서비스 제공자로부터 상기 제1 디바이스의 보안 정보를 수신하는 과정을 포함함을 특징으로 하는 통신 시스템에서 제2 디바이스의 방법.
  8. 제7항에 있어서,
    상기 제2 인증 정보를 기반으로 서비스 제공자와 인증 동작을 수행하는 과정을 더 포함함을 특징으로 하는 통신 시스템에서 제2 디바이스의 방법.
  9. 통신 시스템에서 서비스 제공자의 방법에 있어서,
    제1 디바이스로부터 제2 디바이스의 정보를 수신하고, 상기 제2 디바이스의 정보를 등록하는 과정과;
    상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 인증 정보를 생성하는 과정과;
    상기 인증 정보를 상기 제1 디바이스로 송신하는 과정과;
    상기 인증 정보를 기반으로 상기 제2 디바이스와 인증 동작을 수행하는 과정과;
    상기 제2 디바이스로 상기 제1 디바이스의 보안 정보를 송신하는 과정을 포함함을 특징으로 하는 통신 시스템에서 서비스 제공자의 방법.
  10. 통신 시스템에서 서비스 제공자의 방법에 있어서,
    제1 디바이스가 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는 서비스를 신청함을 검출하는 과정과;
    상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제1 인증 정보를 생성하는 과정과;
    상기 제1 인증 정보를 상기 제1 디바이스로 송신하는 과정과;
    상기 제2 디바이스로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하기를 요청함을 검출하는 과정과;
    상기 제1 디바이스의 보안 정보를 상기 제2 디바이스로 송신하는 과정을 포함함을 특징으로 하는 통신 시스템에서 서비스 제공자의 방법.
  11. 통신 시스템에서 제1 디바이스에 있어서,
    신호를 송신 혹은 수신하는 송수신기와;
    상기 송수신기에 연결되고, 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하기를 요청함을 검출하고, 서비스 제공자로 상기 제2 디바이스의 정보를 등록하고, 상기 서비스 제공자로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 인증 정보를 수신하고, 상기 제2 디바이스로 상기 인증 정보를 송신하는 적어도 하나의 프로세서를 포함함을 특징으로 하는 통신 시스템에서 제1 디바이스.
  12. 제11항에 있어서,
    상기 적어도 하나의 프로세서는 상기 제2 디바이스를 검증함을 특징으로 하는 통신 시스템에서 제1 디바이스.
  13. 통신 시스템에서 제1디바이스에 있어서,
    신호를 송신 혹은 수신하는 송수신기와;
    상기 송수신기에 연결되고, 서비스 제공자로 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는 서비스를 신청하고, 상기 서비스 제공자로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제1 인증 정보를 수신하고, 상기 제1 인증 정보와 상기 제1 디바이스의 보안 정보를 기반으로 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제2 인증 정보를 생성하고, 상기 제2 인증 정보를 상기 제2 디바이스로 송신하는 적어도 하나의 프로세서를 포함함을 특징으로 하는 통신 시스템에서 제1 디바이스.
  14. 제13항에 있어서,
    상기 적어도 하나의 프로세서는:
    상기 제2 디바이스와 커넥션(connection)을 셋업하고,
    상기 셋업된 커넥션을 통해 상기 제2 인증 정보를 상기 제2 디바이스로 송신함을 특징으로 하는 통신 시스템에서 제1 디바이스.
  15. 통신 시스템에서 제2 디바이스에 있어서,
    신호를 송신 혹은 수신하는 송수신기와;
    상기 송수신기에 연결되고, 제1 디바이스로 상기 제1 디바이스의 보안 정보를 공유하기를 요청하고, 상기 제1 디바이스로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 인증 정보를 수신하고, 상기 인증 정보를 기반으로 서비스 제공자와 인증 동작을 수행하고, 상기 서비스 제공자로부터 상기 제1 디바이스의 보안 정보를 수신함을 특징으로 하는 통신 시스템에서 제2 디바이스.
  16. 제15항에 있어서,
    상기 적어도 하나의 프로세서는:
    상기 서비스 제공자와 인증 동작을 수행한 후 상기 서비스 제공자로 상기 제1 디바이스의 보안 정보를 공유하기를 요청함을 특징으로 하는 통신 시스템에서 제2 디바이스.
  17. 통신 시스템에서 제2디바이스에 있어서,
    신호를 송신 혹은 수신하는 송수신기와;
    상기 송수신기에 연결되고, 제1 디바이스와 커넥션(connection)을 셋업하고, 상기 제1 디바이스로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제1 인증 정보와 상기 제1 디바이스의 보안 정보를 기반으로 생성된, 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제2 인증 정보를 수신하고, 서비스 제공자로 상기 제1 디바이스의 보안 정보를 공유하기를 요청하고, 상기 서비스 제공자로부터 상기 제1 디바이스의 보안 정보를 수신하는 적어도 하나의 프로세서를 포함함을 특징으로 하는 통신 시스템에서 제2 디바이스.
  18. 제17항에 있어서,
    상기 적어도 하나의 프로세서는:
    상기 제2 인증 정보를 기반으로 서비스 제공자와 인증 동작을 수행함을 특징으로 하는 통신 시스템에서 제2 디바이스.
  19. 통신 시스템에서 서비스 제공자에 있어서,
    신호를 송신 혹은 수신하는 송수신기와;
    상기 송수신기에 연결되고, 제1 디바이스로부터 제2 디바이스의 정보를 수신하고, 상기 제2 디바이스의 정보를 등록하고, 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 인증 정보를 생성하고, 상기 인증 정보를 상기 제1 디바이스로 송신하고, 상기 인증 정보를 기반으로 상기 제2 디바이스와 인증 동작을 수행하고, 상기 제2 디바이스로 상기 제1 디바이스의 보안 정보를 송신하는 적어도 하나의 프로세서를 포함함을 특징으로 하는 통신 시스템에서 서비스 제공자.
  20. 통신 시스템에서 서비스 제공자에 있어서,
    신호를 송신 혹은 수신하는 송수신기와;
    상기 송수신기에 연결되고, 제1 디바이스가 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는 서비스를 신청함을 검출하고, 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하는데 사용되는 제1 인증 정보를 생성하고, 상기 제1 인증 정보를 상기 제1 디바이스로 송신하고, 상기 제2 디바이스로부터 상기 제2 디바이스가 상기 제1 디바이스의 보안 정보를 공유하기를 요청함을 검출하고, 상기 제1 디바이스의 보안 정보를 상기 제2 디바이스로 송신하는 적어도 하나의 프로세서를 포함함을 특징으로 하는 통신 시스템에서 서비스 제공자.
KR1020170119878A 2017-01-20 2017-09-18 통신 시스템에서 보안 정보 제공 및 관리 장치 및 방법 KR20180086118A (ko)

Priority Applications (5)

Application Number Priority Date Filing Date Title
PCT/KR2018/000962 WO2018135919A1 (en) 2017-01-20 2018-01-22 Apparatus and method for providing and managing security information in communication system
CN201880007940.XA CN110235424B (zh) 2017-01-20 2018-01-22 用于在通信系统中提供和管理安全信息的设备和方法
KR1020197021952A KR102460122B1 (ko) 2017-01-20 2018-01-22 통신 시스템에서 보안 정보 제공 및 관리 장치 및 방법
EP18741656.5A EP3520363B1 (en) 2017-01-20 2018-01-22 Apparatuses and methods for providing and managing security information in communication system
US15/877,020 US10805287B2 (en) 2017-01-20 2018-01-22 Apparatus and method for providing and managing security information in communication system

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201762448551P 2017-01-20 2017-01-20
US62/448,551 2017-01-20
US201762523513P 2017-06-22 2017-06-22
US62/523,513 2017-06-22

Publications (1)

Publication Number Publication Date
KR20180086118A true KR20180086118A (ko) 2018-07-30

Family

ID=63048443

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020170119878A KR20180086118A (ko) 2017-01-20 2017-09-18 통신 시스템에서 보안 정보 제공 및 관리 장치 및 방법
KR1020197021952A KR102460122B1 (ko) 2017-01-20 2018-01-22 통신 시스템에서 보안 정보 제공 및 관리 장치 및 방법

Family Applications After (1)

Application Number Title Priority Date Filing Date
KR1020197021952A KR102460122B1 (ko) 2017-01-20 2018-01-22 통신 시스템에서 보안 정보 제공 및 관리 장치 및 방법

Country Status (2)

Country Link
EP (1) EP3520363B1 (ko)
KR (2) KR20180086118A (ko)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020091382A1 (ko) * 2018-11-02 2020-05-07 삼성전자주식회사 전자장치 및 그 제어방법
WO2020149500A1 (ko) * 2019-01-17 2020-07-23 삼성전자 주식회사 공유된 키를 등록하기 위한 방법 및 장치
WO2020214701A1 (en) * 2019-04-17 2020-10-22 Prestacom Services Llc Sharing keys for a wireless accessory
KR20200138059A (ko) * 2019-05-30 2020-12-09 현대오토에버 주식회사 차량 공유를 위한 이동통신 단말의 디지털 키를 관리하는 방법 및 이를 이용한 키 서버
US20220070667A1 (en) 2020-08-28 2022-03-03 Apple Inc. Near owner maintenance
US11282351B2 (en) 2012-10-24 2022-03-22 Apple Inc. Devices and methods for locating accessories of an electronic device
US11606669B2 (en) 2018-09-28 2023-03-14 Apple Inc. System and method for locating wireless accessories
US11863671B1 (en) 2019-04-17 2024-01-02 Apple Inc. Accessory assisted account recovery
US12073705B2 (en) 2021-05-07 2024-08-27 Apple Inc. Separation alerts for notification while traveling

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112637156B (zh) * 2020-12-14 2022-08-02 卓尔智联(武汉)研究院有限公司 密钥分配方法、装置、计算机设备和存储介质
CN113821835B (zh) * 2021-11-24 2022-02-08 飞腾信息技术有限公司 密钥管理方法、密钥管理装置和计算设备
CN113993115B (zh) * 2021-12-27 2022-04-01 飞天诚信科技股份有限公司 自动解锁屏幕方法、装置、电子设备及可读存储介质
EP4311732A1 (en) * 2022-07-29 2024-01-31 Bayerische Motoren Werke Aktiengesellschaft A concept for server-based sharing of digital keys

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2257026B1 (en) * 2009-05-29 2021-01-13 Alcatel Lucent System and method for accessing private digital content
EP2337300B1 (en) * 2009-12-21 2014-01-22 BlackBerry Limited Method of Securely Transferring Services Between Mobile Devices
US9365188B1 (en) * 2011-04-22 2016-06-14 Angel A. Penilla Methods and systems for using cloud services to assign e-keys to access vehicles
US20140365781A1 (en) * 2013-06-07 2014-12-11 Technische Universitaet Darmstadt Receiving a Delegated Token, Issuing a Delegated Token, Authenticating a Delegated User, and Issuing a User-Specific Token for a Resource

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12106641B2 (en) 2012-10-24 2024-10-01 Apple Inc. Devices and methods for locating accessories of an electronic device
US11282351B2 (en) 2012-10-24 2022-03-22 Apple Inc. Devices and methods for locating accessories of an electronic device
US11606669B2 (en) 2018-09-28 2023-03-14 Apple Inc. System and method for locating wireless accessories
US11641563B2 (en) 2018-09-28 2023-05-02 Apple Inc. System and method for locating wireless accessories
US12075313B2 (en) 2018-09-28 2024-08-27 Apple Inc. System and method for locating wireless accessories
WO2020091382A1 (ko) * 2018-11-02 2020-05-07 삼성전자주식회사 전자장치 및 그 제어방법
US11949779B2 (en) 2019-01-17 2024-04-02 Samsung Electronics Co., Ltd. Method and apparatus for registering shared key
WO2020149500A1 (ko) * 2019-01-17 2020-07-23 삼성전자 주식회사 공유된 키를 등록하기 위한 방법 및 장치
WO2020214701A1 (en) * 2019-04-17 2020-10-22 Prestacom Services Llc Sharing keys for a wireless accessory
US11863671B1 (en) 2019-04-17 2024-01-02 Apple Inc. Accessory assisted account recovery
KR20200138059A (ko) * 2019-05-30 2020-12-09 현대오토에버 주식회사 차량 공유를 위한 이동통신 단말의 디지털 키를 관리하는 방법 및 이를 이용한 키 서버
US11889302B2 (en) 2020-08-28 2024-01-30 Apple Inc. Maintenance of wireless devices
US20220070667A1 (en) 2020-08-28 2022-03-03 Apple Inc. Near owner maintenance
US12073705B2 (en) 2021-05-07 2024-08-27 Apple Inc. Separation alerts for notification while traveling

Also Published As

Publication number Publication date
EP3520363A4 (en) 2019-09-25
EP3520363A1 (en) 2019-08-07
KR102460122B1 (ko) 2022-10-31
KR20190100961A (ko) 2019-08-29
EP3520363B1 (en) 2021-10-13

Similar Documents

Publication Publication Date Title
KR102460122B1 (ko) 통신 시스템에서 보안 정보 제공 및 관리 장치 및 방법
US10805287B2 (en) Apparatus and method for providing and managing security information in communication system
US10887318B2 (en) Method and apparatus for downloading profile on embedded universal integrated circuit card of terminal
CN110177354B (zh) 一种车辆的无线控制方法及系统
KR101491392B1 (ko) 간접적인 디바이스 통신
EP3293993B1 (en) Method and apparatus for providing profile
US20220311625A1 (en) Certificate Application Method And Device
EP2873216A1 (en) Portable token for pairing two devices
CN110809892B (zh) 一种认证方法及终端、网络设备
US9319882B2 (en) Method for mutual authentication between a terminal and a remote server by means of a third-party portal
US9271151B2 (en) Fingerprinting a mobile device through near field communication
KR20220051306A (ko) 전자 디바이스 및 전자 디바이스가 타겟 디바이스에게 제어 명령을 전달하는 방법
US11006464B2 (en) Method, apparatus, storage medium, and terminal for establishing a Wi-Fi connection
CN112449323B (zh) 一种通信方法、装置和系统
CN114762290A (zh) 对数字密钥进行管理的方法和电子装置
JP6470425B2 (ja) デバイスコンテンツプロビジョニングシステム
CN112640385A (zh) 非3gpp设备对核心网络的接入
US20230071702A1 (en) Managing communications between a vehicle and a user device
JP2024501550A (ja) セキュアリレーを備えた物理アクセス制御システム
KR101505735B1 (ko) 시간 검증을 이용한 엔에프씨카드 인증 방법
KR20180056493A (ko) 블랙박스장치를 이용한 2채널 인증 방법
KR20170134857A (ko) 별도의 신호장치를 이용한 2채널 인증 방법
KR20180056494A (ko) 차량항법장치를 이용한 2채널 인증 방법