WO2021182938A1 - 무선 통신 시스템에서 근거리 무선 통신을 이용한 사용자 계정 관리 방법 및 이에 대한 장치 - Google Patents

무선 통신 시스템에서 근거리 무선 통신을 이용한 사용자 계정 관리 방법 및 이에 대한 장치 Download PDF

Info

Publication number
WO2021182938A1
WO2021182938A1 PCT/KR2021/095004 KR2021095004W WO2021182938A1 WO 2021182938 A1 WO2021182938 A1 WO 2021182938A1 KR 2021095004 W KR2021095004 W KR 2021095004W WO 2021182938 A1 WO2021182938 A1 WO 2021182938A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
security
user
account
connection
Prior art date
Application number
PCT/KR2021/095004
Other languages
English (en)
French (fr)
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 US17/909,645 priority Critical patent/US20230109583A1/en
Publication of WO2021182938A1 publication Critical patent/WO2021182938A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/14—Direct-mode setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/61—Time-dependent
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • 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

Definitions

  • the client device may read data from the memory or write new data to the corresponding memory in the process of transmitting and receiving messages with the server device.
  • the scanning device If the scanning device receives a broadcast advertisement event and is in an initiator mode capable of initiating a connection request, the scanning device sends a connection request to the advertisement device through an advertisement physical channel. You can start a Bluetooth connection with
  • ADV_IND Linkable non-directional advertising event
  • STK Short Term Key
  • a and/or B may mean representing at least one of A and B.
  • the user's account is managed and provided by a security broker (Credential Broker).
  • the security broker may be an application/service provider that provides a specific application/specific service, and the like, and the user's account may be an account created by the user to use a specific application/specific service provided by the security broker. That is, when a user creates an account for using an application/service provided by a specific application/service provider, the specific application/service provider may serve as a security broker.
  • the specific application/service provider manages the user's account as a security broker, and provides information related to a security token used between the security searcher device and the security provider device to the security searcher device and the security provider device.
  • the secure searcher device #2 110-2 checks the user B token.
  • the secure searcher device #2 110 - 2 may perform an operation for setting an account based pairing (ABP) filter in step S11090.
  • ABSP account based pairing
  • the operation for setting the ABP filter is successfully performed. can be performed.
  • the operation for setting the ABP filter will be described in more detail below with reference to FIG. 16 and the like.
  • the security searcher device #2 110-2 checks the token ID of user A transmitted by the security provider device 120 through the ABP filter and performs ABP. That is, the success or failure of device authentication between the secure searcher device #2 ( 110 - 2 ) and the security provider device ( 120 ) is based on the user A's token ID in the secure searcher device #2 ( 110 - 2 ) of the user A It may be determined based on whether access is made through at least one of the accounts related to the identified user A (ie, the first account and the second account).
  • Profile & Service there are profiles and services available for each device (Profile & Service).
  • the security provider device when the security provider device is a headset, the security provider device may provide an audio function such as A2DP or a telephony service.
  • the security provider device when the security provider device is a computer mouse, it is possible to provide a cursor manipulation function through USB-based information, such as a Human Interface Device (HID) profile.
  • HID Human Interface Device
  • User A is a user of the security searcher device #1 (1310), and the security searcher device #1 (1310) uses two applications, Application #1 and Application #2.
  • the application #1 and the application #2 may be a Music Player and an airline application, respectively.
  • the application #1 may be an application related to the security broker #1
  • the application #2 may be an application related to the security broker #2.
  • both the application #1 and the application #2 may be able to use the ABP function using the ABP profile.
  • User A's security token may be generated by hashing account #1 and account #3.
  • an additional authentication procedure/security token exchange may be performed in the security searcher device to use the ABP ABP function.
  • the security broker #1 and security broker #2 each transmit a registration code to the user's e-mail, and the This can be done by entering a code.
  • ABP device verification is performed (S18060), and through this, the security searcher device is registered with the ABP service and can use the ABP service.
  • user A has accounts associated with security broker #1 and security broker #2, and one security searcher device 110 is configured to include a plurality of security provider devices 120-1 to 120-3. ) and ABP function.
  • the security searcher device 110 was managing only the account related to the security broker #2. Therefore, the security provider device #3 (120-3) manages the token ID associated only with the account associated with the security broker #2. At this time, the security provider device #3 (120-3) broadcasts an advertisement message including a token ID associated only with the account associated with the security broker #2.
  • 21 is a diagram illustrating an example of a method of configuring a security-enhanced network.
  • ABP may be performed based on the airline application account.
  • ABP Manager manages the account-based automatic connection function proposed in the present specification.
  • Bluetooth Auto Connect detects nearby devices and attempts automatic connection according to the implementation details of each manufacturer. At this time, it may be linked with the account-based automatic connection function through the ABP Manager.
  • the IFE AC (Auto Connect) api of FIG. 25 provides an API for account-based automatic connection to the application layer.
  • the API for automatic connection may be Auto Connect Enable, Auto Connect Start, Auto Connect Account Discovery, and the like.
  • the processor controls the receiver to receive a first message including the credential token from the first device based on the established connection.
  • the processor controls the transmitter to broadcast an advertisement message including a token ID (identifier) generated based on the credential token.
  • an embodiment of the present invention may be implemented in the form of modules, procedures, functions, etc. that perform the functions or operations described above.
  • the software code may be stored in the memory and driven by the processor.
  • the memory may be located inside or outside the processor, and may transmit/receive data to and from the processor by various known means.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 명세서는 근 근거리 무선 통신 시스템에서 제 3 디바이스가 디바이스 인증(Authentication)을 수행하는 방법 및 이에 대한 장치에 관한 것이다. 보다 구체적으로, 본 명세서에서 제안하는 방법은 특정 사용자와 관련된 적어도 하나의 사용자 계정(user account)에 기초하여 생성되는 자격 증명 토큰(credential token)을 제공받기 위해 제 1 디바이스와 연결을 형성하는 단계; 상기 형성된 연결에 기초하여, 상기 자격 증명 토큰을 포함하는 제 1 메시지를 상기 제 1 디바이스로부터 수신하는 단계; 상기 자격 증명 토큰에 기초하여 생성된 토큰 ID(identifier)를 포함하는 광고 메시지를 브로드캐스트(broadcast) 하는 단계; 및상기 토큰 ID에 기초하여, 제 2 디바이스에 대한 상기 디바이스 인증을 통해 상기 제 2 디바이스와 연결을 형성하는 단계를 포함하되, 상기 디바이스 인증의 성공 여부는 (i) 상기 토큰 ID에 기초하여 식별되는 상기 특정 사용자와 관련된 적어도 하나의 사용자 계정이 (ii) 상기 제 2 디바이스에 설정된 계정 기반 페어링 필터(account based pairing filter)와 관련된 하나 이상의 사용자 계정 중 적어도 하나와 일치하는지 여부에 기초하여 결정되는 것을 특징으로 한다.

Description

무선 통신 시스템에서 근거리 무선 통신을 이용한 사용자 계정 관리 방법 및 이에 대한 장치
본 발명은 무선 통신 시스템에 관한 것으로써, 보다 구체적으로 근거리 무선 통신을 이용한 사용자 계정 관리 방법 및 이에 대한 장치에 관한 것이다.
블루투스는 근거리에서 각종 디바이스들을 무선으로 연결하여 데이터를 주고 받을 수 있는 근거리 무선 기술 규격이다. 블루투스(Bluetooth) 통신을 이용하여 두 기기간 무선 통신을 수행하고자 하는 경우, 사용자(User)는 통신하고자 하는 블루투스(Bluetooth) 디바이스(Device)들을 검색(Discovery)하고 연결(Connection)을 요청하는 절차를 수행한다. 본 발명에서 디바이스는 기기, 장치를 의미할 수 있다.
이때, 사용자는 블루투스 디바이스를 이용하여 사용하고자 하는 블루투스 통신방법에 따라 블루투스 디바이스를 검색한 후 연결을 수행할 수 있다.
블루투스 통신방법에는 블루투스 BR/EDR (Basic Rate/Enhanced Data Rate)방식과 저전력 방식인 블루투스 LE (Low Energy)방식이 있다. 블루투스 BR/EDR 방식은 클래식 블루투스(Classic Bluetooth)라고 호칭될 수 있다. 클래식 블루투스 방식은 베이직 레이트(Basic Rate)를 이용하는 블루투스 1.0부터 2.1로 이어져온 블루투스 기술과 블루투스 2.0에서부터 지원되는 인핸스드 데이터 레이트(Enhanced Data Rate)를 이용하는 블루투스 기술을 포함한다.
블루투스 저전력 에너지(Bluetooth Low energy, 이하 블루투스 LE라고 한다.)기술은 적은 전력을 소모하여 수백 키로바이트의 정보를 안정적으로 제공할 수 있다. 이러한 블루투스 저전력 에너지 기술은 속성 프로토콜(Attribute Protocol)을 활용해서 디바이스(Device) 간 정보를 교환하게 된다. 이러한 블루투스 LE 방식은 헤더의 오버헤드(overhead)를 줄이고 동작을 간단하게 해서 에너지 소비를 줄일 수 있다.
블루투스 기기들 중에는 디스플레이(Display)나 유저인터페이스(User Interface)가 없는 제품들도 있다. 다양한 종류의 블루투스 기기들과 그 중에서도 유사기술이 적용된 블루투스 기기들 간의 연결 / 관리 / 제어 / 분리 (Connection / Management / Control / Disconnection)의 복잡도가 증가하고 있다.
또한, 블루투스는 비교적 저전력, 저비용으로 비교적 빠른 속도를 낼 수 있으나, 전송 거리가 최대 100m로 한정적이므로, 한정된 공간에서 사용하기 적합하다.
본 명세서는 무선 통신 시스템에서 제 3 디바이스가 디바이스 인증(Authentication)을 수행하는 방법 및 이에 대한 장치를 제공함에 그 목적이 있다.
또한, 본 명세서는 무선 통신 시스템에서 제 3 디바이스가 추가적인 인증 없이도 동일 사용자의 다른 디바이스와 자동으로 연결을 형성하는 방법 및 이에 대한 장치를 제공함에 그 목적이 있다.
또한, 본 명세서는 무선 통신 시스템에서 제 3 디바이스의 단일 사용자의 복수의 계정을 통한 디바이스 인증 방법 및 이에 대한 장치를 제공함에 그 목적이 있다.
또한, 본 명세서는 무선 통신 시스템에서 제 3 디바이스의 복수 사용자의 계정을 통한 디바이스 인증 방법 및 이에 대한 장치를 제공함에 그 목적이 있다.
본 명세서에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 명세서는 근거리 무선 통신 시스템에서 제 3 디바이스가 디바이스 인증(Authentication)을 수행하는 방법 및 이에 대한 장치를 제공한다.
보다 구체적으로, 본 명세서는, 근거리 무선 통신 시스템에서 제 3 디바이스가 디바이스 인증(Authentication)을 수행하는 방법은, 특정 사용자와 관련된 적어도 하나의 사용자 계정(user account)에 기초하여 생성되는 자격 증명 토큰(credential token)을 제공받기 위해 제 1 디바이스와 연결을 형성하는 단계; 상기 형성된 연결에 기초하여, 상기 자격 증명 토큰을 포함하는 제 1 메시지를 상기 제 1 디바이스로부터 수신하는 단계; 상기 자격 증명 토큰에 기초하여 생성된 토큰 ID(identifier)를 포함하는 광고 메시지를 브로드캐스트(broadcast) 하는 단계; 및 상기 토큰 ID에 기초하여, 제 2 디바이스에 대한 상기 디바이스 인증을 통해 상기 제 2 디바이스와 연결을 형성하는 단계를 포함하되, 상기 디바이스 인증의 성공 여부는 (i) 상기 토큰 ID에 기초하여 식별되는 상기 특정 사용자와 관련된 적어도 하나의 사용자 계정이 (ii) 상기 제 2 디바이스에 설정된 계정 기반 페어링 필터(account based pairing filter)와 관련된 하나 이상의 사용자 계정 중 적어도 하나와 일치하는지 여부에 기초하여 결정되는 것을 특징으로 한다.
또한, 본 명세서는, (i) 상기 토큰 ID에 기초하여 식별되는 상기 특정 사용자와 관련된 적어도 하나의 사용자 계정이 (ii) 상기 제 2 디바이스에 설정된 계정 기반 페어링 필터와 관련된 하나 이상의 사용자 계정 중 적어도 하나가 일치하는 것에 기초하여, 상기 디바이스 인증이 성공하는 것을 특징으로 할 수 있다.
또한, 본 명세서는, (i) 상기 토큰 ID에 기초하여 식별되는 상기 특정 사용자와 관련된 적어도 하나의 사용자 계정이 (ii) 상기 제 2 디바이스에 설정된 계정 기반 페어링 필터와 관련된 하나 이상의 사용자 계정 모두와 다른 것에 기초하여, 상기 디바이스 인증이 실패하는 것을 특징으로 할 수 있다.
또한, 본 명세서는,상기 자격 증명 토큰은 상기 특정 사용자와 관련된 적어도 하나의 사용자 계정을 통합하여 생성된 단일 자격 증명 토큰이고, 상기 토큰 ID는 상기 단일 자격 증명 토큰에 기초하여 생성된 통합 토큰 ID인 것을 특징으로 할 수 있다.
또한, 본 명세서는, 적어도 하나 이상의 토큰 ID를 저장하여 관리하기 위한 토큰 스토어(token store)에 상기 토큰 ID를 저장하는 단계를 더 포함하되, 상기 자격 증명 토큰은 상기 자격 증명 토큰이 만료(expiration)되는 시점과 관련된 만료 시점 값이 설정되는 것을 특징으로 할 수 있다.
또한, 본 명세서는, 상기 특정 사용자 외에 상기 제 1 디바이스의 또 다른 사용자가 존재하는 것에 기초하여: 상기 또 다른 사용자와 관련된 적어도 하나의 사용자 계정에 기초하여 생성되는 또 다른 자격 증명 토큰을 제공받기 위해 상기 제 1 디바이스와 연결을 형성하는 단계; 상기 형성된 연결에 기초하여, 상기 또 다른 자격 증명 토큰을 포함하는 제 2 메시지를 상기 제 1 디바이스로부터 수신하는 단계; 및 상기 또 다른 자격 증명 토큰에 기초하여 또 다른 토큰 ID를 생성하는 단계를 더 포함하되, 상기 또 다른 토큰 ID는 상기 토큰 스토어에 저장되는 것을 특징으로 할 수 있다.
또한, 본 명세서는,사용자 입력에 기초하여 상기 광고 메시지에 포함되어 전송되는 토큰 ID를 결정하는 단계를 더 포함하는 것을 특징으로 할 수 있다.
또한, 본 명세서는, 상기 토큰 ID 및 상기 또 다른 토큰 ID에 기초하여 상기 토큰 ID 및 상기 또 다른 토큰 ID가 그룹핑(grouping)된 그룹 토큰 ID를 생성하는 단계를 더 포함하되, 상기 광고 메시지는 상기 그룹 토큰 ID를 포함하는 것을 특징으로 할 수 있다.
또한, 본 명세서는, 상기 자격 증명 토큰에 설정된 상기 만료 시점 값에 기초하여 상기 토큰 ID를 상기 토큰 스토어로부터 제거하는 단계를 더 포함하되, 상기 토큰 ID가 제거된 이후 전송되는 광고 메시지는 상기 토큰 ID를 포함하지 않는(exclude) 것을 특징으로 할 수 있다.
또한, 본 명세서는, 상기 토큰 ID가 제거된 것에 기초하여, 상기 토큰 ID에 기초한 상기 디바이스 인증은 수행되지 않는 것을 특징으로 할 수 있다.
또한, 본 명세서는, 상기 토큰 ID를 생성한 시점 이후 상기 특정 사용자가 상기 특정 사용자와 관련된 적어도 하나의 사용자 계정 외에 또 다른 사용자 계정을 사용하게 된 것에 기초하여: 상기 제 1 디바이스로부터 상기 또 다른 사용자 계정에 대한 정보를 포함하는 제 2 메시지를 수신하는 단계를 더 포함하는 것을 특징으로 할 수 있다.
또한, 본 명세서는, 상기 또 다른 사용자 계정에 대한 정보에 기초하여 상기 토큰 ID를 업데이트하는 단계를 더 포함하되, 업데이트된 토큰 ID는 상기 특정 사용자와 관련된 적어도 하나의 사용자 계정 및 상기 또 다른 사용자 계정과 관련되는 것을 특징으로 할 수 있다.
또한, 본 명세서는, 상기 토큰 ID가 업데이트된 이후에 전송되는 광고 메시지는 상기 업데이트된 토큰 ID를 포함하여 전송되는 것을 특징으로 할 수 있다.
또한, 본 명세서는, 상기 특정 사용자와 관련된 적어도 하나의 사용자 계정은 각각 서로 다른 어플리케이션(application)과 관련된 사용자 계정인 것을 특징으로 할 수 있다.
또한, 본 명세서는, 상기 제 3 디바이스는 복수의 디바이스들로 구성되는 메쉬 네트워크(mesh network)에 포함되어 상기 메쉬 네트워크의 일부를 구성하고, 상기 복수의 디바이스들 간에 교환 되는 모든 메시지들은 상기 제 3 디바이스를 거쳐서만 다른 디바이스로 전달되는 것을 특징으로 할 수 있다.
또한, 본 명세서는, 근거리 무선 통신 시스템에서 디바이스 인증(Authentication)을 수행하는 제 3 디바이스는, 무선 신호를 송신하기 위한 전송기(transmitter); 무선 신호를 수신하기 위한 수신기(receiver); 및 상기 전송기 및 수신기와 기능적으로 연결되는 프로세서를 포함하고, 상기 프로세서는, 특정 사용자와 관련된 적어도 하나의 사용자 계정(user account)에 기초하여 생성되는 자격 증명 토큰(credential token)을 제공받기 위해 제 1 디바이스와 연결을 형성하도록 상기 전송기 및 상기 수신기를 제어하고, 상기 형성된 연결에 기초하여, 상기 자격 증명 토큰을 포함하는 제 1 메시지를 상기 제 1 디바이스로부터 수신하도록 상기 수신기를 제어하고, 상기 자격 증명 토큰에 기초하여 생성된 토큰 ID(identifier)를 포함하는 광고 메시지를 브로드캐스트(broadcast) 하도록 상기 전송기를 제어하고, 상기 토큰 ID에 기초하여, 제 2 디바이스에 대한 상기 디바이스 인증을 통해 상기 제 2 디바이스와 연결을 형성하도록 상기 전송기 및 상기 수신기를 제어하되, 상기 디바이스 인증의 성공 여부는 (i) 상기 토큰 ID에 기초하여 식별되는 상기 특정 사용자와 관련된 적어도 하나의 사용자 계정이 (ii) 상기 제 2 디바이스에 설정된 계정 기반 페어링 필터(account based pairing filter)와 관련된 하나 이상의 사용자 계정 중 적어도 하나와 일치하는지 여부에 기초하여 결정되는 것을 특징으로 한다.
본 명세서는 무선 통신 시스템에서 제 3 디바이스가 디바이스 인증(Authentication)을 수행할 수 있는 효과가 있다.
또한, 본 명세서는 무선 통신 시스템에서 제 3 디바이스가 추가적인 인증 없이도 동일 사용자의 다른 디바이스와 자동으로 연결을 형성할 수 있는 효과가 있다.
또한, 본 명세서는 무선 통신 시스템에서 제 3 디바이스가 단일 사용자의 복수의 계정을 통한 디바이스 인증을 수행할 수 있는 효과가 있다.
또한, 본 명세서는 무선 통신 시스템에서 제 3 디바이스가 복수 사용자의 계정을 통한 디바이스 인증을 수행할 수 있는 효과가 있다.
본 명세서에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는, 첨부 도면은 본 발명에 대한 실시 예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 특징을 설명한다.
도 1은 본 명세서에서 제안하는 블루투스 저전력 에너지 기술을 이용하는 무선 통신 시스템의 일 예를 나타낸 개략도이다.
도 2는 본 명세서에서 제안하는 방법들을 구현할 수 있는 디바이스의 내부 블록도의 일 예를 나타낸다.
도 3은 본 명세서에서 제안하는 방법들이 적용될 수 있는 블루투스 통신 아키텍처(Architecture)의 일 예를 나타낸다.
도 4는 블루투스 저전력 에너지의 GATT(Generic Attribute Profile)의 구조의 일 예를 나타낸다.
도 5는 블루투스 저전력 에너지의 GATT(Generic Attribute Profile)의 구조의 일 예를 나타낸다.
도 6은 본 발명이 적용될 수 있는 블루투스 저전력 에너지 기술에서 연결 절차 방법의 일 예를 나타내는 흐름도이다.
도 7은 서버와 디바이스 간의 권한 토큰 확인(Right Token Check)과정을 설명하기 위한 일 예를 나타낸 도이다.
도 8은 디바이스가 특정 기능을 수행하기 위해 정의되는 디바이스의 모드 등에 대한 이해를 돕기 위한 일 예를 나타낸 도이다.
도 9는 계정 기반 페어링이 수행되는 메커니즘의 일 예를 나타낸 도이다.
도 10은 본 명세서에서 제안하는 두 디바이스 간의 연결을 위한 사용자 계정 관리 방법의 일 예를 나타낸 흐름도이다.
도 11은 소스 디바이스가 적어도 하나의 싱크 디바이스의 오디오 데이터 출력을 위한 다양한 설정을 제어하기 위한 일 예를 나타낸다.
도 12는 본 명세서에서 제안하는 두 디바이스 간의 연결을 위한 사용자 계정 관리 방법의 또 다른 일 예를 나타낸 흐름도이다.
도 13 및 도 14는 보안 검색자 디바이스에서의 보안 토큰 생성 및 보안 제공자 디바이스에서의 토큰 ID 관리의 일 예를 나타낸 도이다.
도 15는 보안 검색자 디바이스에서의 보안 토큰 생성의 또 다른 일 예를 나타낸 도이다.
도 16은 보안 검색자 디바이스에서의 사용자 계정 정보 획득 방법의 일 예를 나타낸 도이다.
도 17은 보안 검색자 디바이스에서의 보안 토큰 획득 및 저장 방법의 일 예를 나타낸 흐름도이다.
도 18은 보안 검색자 디바이스에서 수행되는 ABP 동작의 일 예를 나타낸 흐름도이다.
도 19는 보안 만료 및 보안 갱신을 위한 방법이 수행되는 일 예를 나타낸 흐름도이다.
도 20은 보안 갱신을 위한 방법이 수행되는 또 다른 일 예를 나타낸 흐름도이다.
도 21은 보안이 강화된 네트워크를 구성하는 방식의 일 예를 나타낸 도이다.
도 22 및 도 23은 본 명세서에서 제안하는 방법이 항공기의 기내 시스템에 적용되는 일 예를 나타낸 도이다.
도 24는 본 명세서에서 제안하는 방법이 항공기의 기내 시스템에 적용되는 또 다른 일 예를 나타낸 도이다.
도 25는 본 명세서에서 제안하는 방법이 항공기의 기내 시스템에 적용되는 경우의 소프트웨어 구성도의 일 예를 나타낸 도이다.
도 26은 본 명세서에서 제안하는 디바이스 인증(Authentication) 방법이 수행되는 일 예를 나타낸 흐름도이다.
도 27은 본 명세서에서 제안하는 디바이스 인증 방법의 수행 과정에서 전송되는 메시지 포맷의 일 예를 나타낸다.
도 28은 본 명세서에서 제안하는 무선 통신 시스템에서 제 3 디바이스가 디바이스 인증(Authentication)을 수행하는 방법을 수행하기 위한 제 3 디바이스에서 구현되는 동작의 일례를 나타낸 흐름도이다.
본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는 첨부 도면은 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 특징을 설명한다. 명세서 전체에 걸쳐서 동일한 참조번호들은 원칙적으로 동일한 구성요소들을 나타낸다. 또한, 본 발명과 관련된 공지 기능 혹은 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 또한, 첨부된 도면은 본 발명의 사상을 쉽게 이해할 수 있도록 하기 위한 것일 뿐, 첨부된 도면에 의해 본 발명의 사상이 제한되는 것으로 해석되어서는 아니 됨을 유의해야 한다.
이하, 본 발명과 관련된 방법 및 장치에 대하여 도면을 참조하여 보다 상세하게 설명한다. 또한, 본 발명에서 사용되는 일반적인 용어는 사전에 정의되어 있는 바에 따라, 또는 전후 문맥상에 따라 해석되어야 하며, 과도하게 축소된 의미로 해석되지 않아야 한다. 또한, 본 명세서에서 사용되는 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "구성된다" 또는 "포함한다" 등의 용어는 명세서 상에 기재된 여러 구성 요소들, 또는 여러 단계들을 반드시 모두 포함하는 것으로 해석되지 않아야 하며, 그 중 일부 구성 요소들 또는 일부 단계들은 포함되지 않을 수도 있고, 또는 추가적인 구성 요소 또는 단계들을 더 포함할 수 있는 것으로 해석되어야 한다. 이하의 설명에서 사용되는 구성요소에 대한 접미사 "유닛", "모듈" 및 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다. "제1", "제2" 등의 용어는 하나의 구성요소를 다른 구성요소로부터 구별하기 위한 것으로 이들 용어들에 의해 권리범위가 한정되어서는 아니 된다.
도 1은 본 명세서에서 제안하는 블루투스 저전력 에너지 기술을 이용하는 무선 통신 시스템의 일 예를 나타낸 개략도이다.
무선 통신 시스템(100)은 적어도 하나의 서버 디바이스(Server Device, 120) 및 적어도 하나의 클라이언트 디바이스(Client Device, 110)를 포함한다.
서버 장치와 클라이언트 장치는 블루투스 저전력 에너지(Bluetooth Low Energy:BLE, 이하 편의상 ‘BLE’로 표현한다.) 기술을 이용하여 블루투스 통신을 수행한다.
먼저, BLE 기술은 블루투스 BR/EDR(Basic Rate/Enhanced Data Rate) 기술과 비교하여, 상대적으로 작은 duty cycle을 가지며 저 가격 생산이 가능하고, 저속의 데이터 전송률을 통해 전력 소모를 크게 줄일 수 있어 코인 셀(coin cell) 배터리를 이용할 경우 1년 이상 동작이 가능하다.
또한, BLE 기술에서는 디바이스 간 연결 절차를 간소화하였으며, 패킷 사이즈도 블루투스 BR/EDR 기술에 비해 작게 설계되어 있다.
BLE 기술에서, (1) RF 채널수는 40개이며, (2) 데이터 전송 속도는 1Mbps를 지원하며, (3) 토폴로지는 스캐터넷 구조이며, (4) latency는 3ms이며, (5) 최대 전류는 15mA 이하이며, (6) 출력 전력은 10mW(10dBm) 이하이며, (7) 휴대폰, 시계, 스포츠, 헬스케어, 센서, 기기제어 등의 어플리케이션에 주로 사용된다.
상기 서버 장치(120)는 다른 장치와의 관계에서 클라이언트 장치로 동작할 수 있고, 상기 클라이언트 장치는 다른 장치와의 관계에서 서버 장치로 동작할 수 있다. 즉, BLE 통신 시스템에서 어느 하나의 장치는 서버 장치 또는 클라이언트 장치로 동작하는 것이 가능하며, 필요한 경우, 서버 장치 및 클라이언트 장치로 동시에 동작하는 것도 가능하다.
상기 서버 장치(120)는 데이터 서비스 장치(Data Service Device), 슬레이브 디바이스(slave device) 디바이스, 슬레이브(slave), 서버, 컨덕터(Conductor), 호스트 디바이스(Host Device), 게이트웨이(Gateway), 센싱 장치(Sensing Device), 모니터링 장치(monitoring device), 제 1 디바이스, 제 2 디바이스 등으로 표현될 수 있다.
상기 클라이언트 디바이스(110)는 마스터 디바이스(master device), 마스터(master), 클라이언트, 멤버(Member), 센서 디바이스, 싱크 디바이스(Sink Device), 콜렉터(Collector), 제 3 디바이스, 제 4 디바이스 등으로 표현될 수 있다.
서버 장치와 클라이언트 장치는 상기 무선 통신 시스템의 주요 구성요소에 해당하며, 상기 무선 통신 시스템은 서버 장치 및 클라이언트 장치 이외에도 다른 구성요소를 포함할 수 있다.
상기 서버 장치는 클라이언트 장치로부터 데이터를 제공 받고, 클라이언트 장치와 직접 통신을 수행함으로써, 클라이언트 장치부터 데이터 요청을 수신하는 경우, 응답을 통해 클라이언트 장치로 데이터를 제공하는 장치를 말한다.
또한, 상기 서버 장치는 클라이언트 장치로 데이터 정보를 제공하기 위해 클라이언트 장치에게 알림/통지(Notification) 메시지, 지시(Indication) 메시지를 보낸다. 또한, 상기 서버 장치는 상기 클라이언트 장치로 지시 메시지를 전송하는 경우, 상기 클라이언트로부터 상기 지시 메시지에 대응하는 확인(Confirm) 메시지를 수신한다.
또한, 상기 서버 장치는 알림, 지시, 확인 메시지들을 클라이언트 디바이스와 송수신하는 과정에서 출력부(Display Unit)을 통해서 사용자에게 데이터 정보를 제공하거나 입력부(User Input Interface)를 통해 사용자로부터 입력되는 요청을 수신할 수 있다.
또한, 상기 서버 장치는 상기 클라이언트 장치와 메시지를 송수신하는 과정에서 메모리(memory unit)로부터 데이터를 읽어 오거나 새로운 데이터를 해당 메모리에 쓸 수 있다.
또한, 하나의 서버 장치는 다수의 클라이언트 장치들과 연결될 수 있으며, 본딩(Bonding) 정보를 활용하여 클라이언트 장치들과 쉽게 재 연결(또는 접속)이 가능하다.
상기 클라이언트 장치 (120)는 서버 장치에게 데이터 정보 및 데이터 전송을 요청하는 장치를 말한다.
클라이언트 장치는 상기 서버 장치로부터 알림 메시지, 지시 메시지 등을 통해 데이터를 수신하고, 지시 메시지를 상기 서버 디바이스로부터 수신하는 경우, 상기 지시 메시지에 대한 응답으로 확인 메시지를 보낸다.
상기 클라이언트 장치도 마찬가지로 상기 서버 장치와 메시지들을 송수신하는 과정에서 출력부를 통해 사용자에게 정보를 제공하거나 입력부를 통해 사용자로부터의 입력을 수신할 수 있다.
또한, 상기 클라이언트 장치는 상기 서버 장치와 메시지를 송수신하는 과정에서 메모리로부터 데이터를 읽어 오거나 새로운 데이터를 해당 메모리에 쓸 수 있다.
상기 서버 장치 및 클라이언트 장치의 출력부, 입력부 및 메모리 등과 같은 하드웨어 구성요소에 대해서는 도 2에서 구체적으로 살펴보기로 한다.
또한, 상기 무선 통신 시스템은 블루투스 기술을 통해 개인 영역 네트워킹(Personal Area Networking:PAN)을 구성할 수 있다. 일 예로, 상기 무선 통신 시스템에서는 디바이스 간 개인적인 피코넷(private piconet)을 확립함으로써 파일, 서류 등을 신속하고 안전하게 교환할 수 있다.
도 2는 본 명세서에서 제안하는 방법들을 구현할 수 있는 디바이스의 내부 블록도의 일 예를 나타낸다.
도 2에 도시된 바와 같이, 보안 검색자(Credential seeker) 디바이스(110)는 출력부(Display Unit, 111), 입력부(User Input Interface, 112), 전력 공급부(Power Supply Unit, 113), 제어부(Control unit, 114), 메모리(Memory Unit, 115), 네트워크 인터페이스(Network Interface, 116), 저장부(Storage, 117), 멀티미디어 모듈(Multimedia module, 118) 및 AAA 관리자(Authentication, Authorization, Accounting manager, 119)를 포함한다.
상기 출력부(111), 입력부(112), 전력 공급부(113), 제어부(114), 메모리(115), 네트워크 인터페이스(116), 저장부(117), 멀티미디어 모듈(118) 및 AAA 관리자(119)는 본 명세서에서 제안하는 방법을 수행하기 위해 기능적으로 연결되어 있다.
또한, 보안 제공자(Credential provider) 디바이스(120)는 출력부(Display Unit, 121), 입력부(User Input Interface, 122), 전력 공급부(Power Supply Unit, 123), 제어부(Control unit, 124), 메모리(Memory Unit, 125), 네트워크 인터페이스(Network Interface, 126), 저장부(Storage, 127), 멀티미디어 모듈(Multimedia module, 128) 및 AAA 관리자(Authentication, Authorization, Accounting manager, 129)를 포함한다.
상기 출력부(121), 입력부(122), 전력 공급부(123), 제어부(124), 메모리(125), 네트워크 인터페이스(126), 저장부(127), 멀티미디어 모듈(128) 및 AAA 관리자(129)는 본 명세서에서 제안하는 방법을 수행하기 위해 기능적으로 연결되어 있다.
상기 네트워크 인터페이스(116,126)는 특정한 통신 기술을 이용하여 디바이스들 간의 요청/응답, 명령, 알림, 지시/확인 메시지 등 또는 데이터 전송이 가능한 유닛(또는 모듈)을 말한다. 상기 네트워크 인터페이스(116, 126)를 통해서 하나 이상의 통신 기술이 구현될 수 있다. 상기 네트워크 인터페이스는 통신부를 포함할 수 있으며, 상기 통신부는 전송기/수신기를 포함할 수 있다. 상기 통신부는 무선 신호를 처리하기 위한 베이스밴드 회로를 포함할 수 있다. 실시 예가 소프트웨어로 구현될 때, 상술한 기법은 상술한 기능을 수행하는 모듈(과정, 기능 등)로 구현될 수 있다. 모듈은 메모리에 저장되고, 프로세서에 의해 실행될 수 있다. 상기 네트워크 인터페이스(116, 126)를 통하여 아래에서 설명되는 인증 권한 관리자와 데이터가 송수신 될 수 있다.
상기 메모리(115,125)는 다양한 종류의 디바이스에 구현되는 유닛으로서, 다양한 종류의 데이터가 저장되는 유닛을 말한다.
상기 제어부(114,124)는 보안 검색자 디바이스(110) 또는 보안 제공자 디바이스(120)의 전반적인 동작을 제어하는 모듈을 말하며, 네트워크 인터페이스로 메시지(116, 126)를 전송 요청하고, 네트워크 인터페이스(116, 126)로 수신 받은 메시지를 처리하도록 제어한다.
상기 제어부(114,124)는 제어 유닛, 컨트롤러, 프로세서 등으로 표현될 수 있다.
상기 제어부(114,124)는 ASIC(application-specific integrated circuit), 다른 칩셋, 논리 회로 및/또는 데이터 처리 장치를 포함할 수 있다.
상기 제어부(114)는 보안 제공자 디바이스(120)로부터 광고(Advertising) 메시지를 수신하도록 상기 통신부를 제어하며, 상기 보안 제공자 디바이스(120)로 스캔 요청(Scan Request) 메시지를 전송하고, 상기 보안 제공자 디바이스(120)로부터 상기 스캔 요청에 대한 응답으로 스캔 응답(Scan Response) 메시지를 수신하도록 상기 통신부를 제어하며, 상기 보안 제공자 디바이스(120)와 블루투스 연결 설정을 위해 상기 보안 제공자 디바이스(120)로 연결 요청(Connect Request) 메시지를 전송하도록 상기 통신부를 제어한다.
또한, 상기 제어부(114)는 상기 연결 절차를 통해 블루투스 LE 커넥션(Connection)이 형성된 이후, 상기 보안 제공자 디바이스(120)로부터 속성 프로토콜을 이용하여 데이터를 읽어오거나(Read), 기록(Write)할 수 있도록 상기 통신부를 제어한다.
상기 메모리(115,125)는 ROM(read-only memory), RAM(random access memory), 플래쉬 메모리, 메모리 카드, 저장 매체 및/또는 다른 저장 장치를 포함할 수 있다.
상기 메모리(115,125)는 프로세서(114,124) 내부 또는 외부에 있을 수 있고, 잘 알려진 다양한 수단으로 프로세서(114,124)와 연결될 수 있다.
상기 출력부(111,121)는 디바이스의 상태 정보 및 메시지 교환 정보 등을 화면을 통해서 사용자에게 제공하기 위한 모듈을 말한다.
상기 전력 공급부(전원 공급부, 113, 123)는 제어부의 제어 하에 외부의 전원, 내부의 전원을 인가 받아 각 구성요소들의 동작에 필요한 전원을 공급해주는 모듈을 말한다.
상기 AAA 관리자(119, 129)는 디바이스의 인증/권한부여/계정을 관리할 수 있다.
앞에서 살핀 것처럼, BLE 기술에서는 작은 duty cycle을 가지며, 저속의 데이터 전송률을 통해 전력 소모를 크게 줄일 수 있다.
도 3은 본 명세서에서 제안하는 방법들을 구현할 수 있는 디바이스의 내부 블록도의 또 다른 일 예를 나타낸다.
도 3에 도시된 바와 같이, 인증 권한 관리자(Certificate Authority Manager) 디바이스(130)는 출력부(Display Unit, 131), 입력부(User Input Interface, 132), 전력 공급부(Power Supply Unit, 133), 제어부(Control unit, 134), 메모리(Memory Unit, 135), 네트워크 인터페이스(Network Interface, 136), 저장부(Storage, 137), 멀티미디어 모듈(Multimedia module, 138) 및 AAA 관리자(Authentication, Authorization, Accounting manager, 139)를 포함한다. 인증 권한 관리자 디바이스는 디바이스 형태뿐만 아니라 SW entity로도 구성될 수 있다.
상기 출력부(131), 입력부(132), 전력 공급부(1133), 제어부(134), 메모리(135), 네트워크 인터페이스(136), 저장부(137), 멀티미디어 모듈(138) 및 AAA 관리자(139)는 본 명세서에서 제안하는 방법을 수행하기 위해 기능적으로 연결되어 있다.
도 2에서 설명된 내용들은 상기 출력부(131), 입력부(132), 전력 공급부(1133), 제어부(134), 메모리(135), 네트워크 인터페이스(136), 저장부(137), 멀티미디어 모듈(138) 및 AAA 관리자(139)에 대해서 동일하게 적용될 수 있다.
도 4는 본 명세서에서 제안하는 방법들이 적용될 수 있는 블루투스 통신 아키텍처(Architecture)의 일 예를 나타낸다.
구체적으로, 도 4는 블루투스 LE(Low Energy)의 아키텍처의 일 예를 나타낸다.
도 4에 도시된 바와 같이, BLE 구조는 타이밍이 중요한 무선장치 인터페이스를 처리하도록 동작가능한 컨트롤러 스택(Controller stACK)과 고레벨(high level) 데이터를 처리하도록 동작가능한 호스트 스택(Host stACK)을 포함한다.
상기 Controller stack은 Controller로 호칭될 수도 있으나, 앞서 도 2,3에서 언급한 디바이스 내부 구성요소인 프로세서와의 혼동을 피하기 위해 이하에서는 Controller stACK으로 표현하기로 한다.
먼저, 컨트롤러 스택은 블루투스 무선장치를 포함할 수 있는 통신 모듈과, 예를 들어, 마이크로프로세서와 같은 프로세싱 디바이스를 포함할 수 있는 프로세서 모듈을 이용하여 구현될 수 있다.
호스트 스택은 프로세서 모듈 상에서 작동되는 OS의 일부로서, 또는 OS 위의 패키지(package)의 인스턴스 생성(instantiation)으로서 구현될 수 있다.
일부 사례들에서, 컨트롤러 스택 및 호스트 스택은 프로세서 모듈 내의 동일한 프로세싱 디바이스 상에서 작동 또는 실행될 수 있다.
호스트 스택은 GAP(Generic Access Profile,310), GATT based Profiles(320), GATT(Generic Attribute Profile,330), ATT(Attribute Protocol,340), SM(Security Manage,350), L2CAP(Logical Link Control and Adaptation Protocol,360)을 포함한다. 다만, 호스트 스택은 이것으로 한정되지는 않고 다양한 프로토콜들 및 프로파일들을 포함할 수 있다.
호스트 스택은 L2CAP을 사용하여 블루투스 상위에서 제공하는 다양한 프로토콜, 프로파일 등을 다중화(multiplexing)한다.
먼저, L2CAP(Logical Link Control and Adaptation Protocol,360)은 특정 프로토콜 또는 프로파일에게 데이터를 전송하기 위한 하나의 양방향 채널을 제공한다.
L2CAP은 상위 계층 프로토콜들 사이에서 데이터를 다중화(multiplex)하고, 패키지(package)들을 분할(segment) 및 재조립(reassemble)하고, 멀티캐스트 데이터 송신을 관리하도록 동작 가능할 수 있다.
BLE 에서는 3개의 고정 채널(signaling CH을 위해 1개, Security Manager를 위해 1개, Attribute protocol을 위해 1개)을 사용한다.
반면, BR/EDR(Basic Rate/Enhanced Data Rate)에서는 동적인 채널을 사용하며, protocol service multiplexer, retransmission, streaming mode 등을 지원한다.
SM(Security Manager,350)은 디바이스를 인증하며, 키 분배(key distribution)를 제공하기 위한 프로토콜이다.
ATT(Attribute Protocol,340)는 서버-클라이언트(Server-Client) 구조로 상대 디바이스의 데이터를 접근하기 위한 규칙을 정의한다. ATT에는 6가지의 메시지 유형(Request, Response, Command, Notification, Indication, Confirmation)이 있다.
즉, ① 요청(Request) 및 응답(Response) 메시지: Request 메시지는 클라이언트 디바이스에서 서버 디바이스로 특정 정보를 요청하기 위한 메시지이며, Response 메시지는 Request 메시지에 대한 응답 메시지로서, 서버 디바이스에서 클라이언트 디바이스로 전송되는 메시지를 말한다.
② Command 메시지: 클라이언트 디바이스에서 서버 디바이스로 특정 동작의 명령을 지시하기 위해 전송하는 메시지로, 서버 디바이스는 Command 메시지에 대한 응답을 클라이언트 디바이스로 전송하지 않는다.
③ Notification 메시지: 서버 디바이스에서 클라이언트 디바이스로 이벤트 등과 같은 통지를 위해 전송하는 메시지로, 클라이언트 디바이스는 Notification 메시지에 대한 확인 메시지를 서버 디바이스로 전송하지 않는다.
④ Indication 및 Confirm 메시지: 서버 디바이스에서 클라이언트 디바이스로 이벤트 등과 같은 통지를 위해 전송하는 메시지로, Notification 메시지와는 달리, 클라이언트 디바이스는 Indication 메시지에 대한 확인 메시지를 서버 디바이스로 전송한다.
GAP(Generic Access Profile)는 BLE 기술을 위해 새롭게 구현된 계층으로, BLE 디바이스들 간의 통신을 위한 역할 선택, 멀티 프로파일 작동이 어떻게 일어나는지를 제어하는데 사용된다.
또한, GAP는 디바이스 발견, 연결 생성 및 보안 절차 부분에 주로 사용되며, 사용자에게 정보를 제공하는 방안을 정의하며, 하기와 같은 attribute의 type을 정의한다.
① Service : 데이터와 관련된 behavior의 조합으로 디바이스의 기본적인 동작을 정의
② Include : 서비스 사이의 관계를 정의
③ Characteristics : 서비스에서 사용되는 data 값
④ Behavior : UUID(Universal Unique Identifier, value type)로 정의된 컴퓨터가 읽을 수 있는 포맷
GATT-based Profiles은 GATT에 의존성을 가지는 profile 들로 주로 BLE 디바이스에 적용된다. GATT-based Profiles은 Battery, Time, FindMe, Proximity, Time, Object Delivery Service 등일 수 있다. GATT-based Profiles의 구체적인 내용은 하기와 같다.
Battery : 배터리 정보 교환 방법
Time : 시간 정보 교환 방법
FindMe : 거리에 따른 알람 서비스 제공
Proximity : 배터리 정보 교환 방법
Time : 시간 정보 교환 방법
GATT는 서비스들의 구성 시에 ATT가 어떻게 이용되는지를 설명하는 프로토콜로서 동작 가능할 수 있다. 예를 들어, GATT는 ATT 속성들이 어떻게 서비스들로 함께 그룹화되는지를 규정하도록 동작 가능할 수 있고, 서비스들과 연계된 특징들을 설명하도록 동작 가능할 수 있다.
따라서, GATT 및 ATT는 디바이스의 상태와 서비스들을 설명하고, 특징들이 서로 어떻게 관련되며 이들이 어떻게 이용되는지를 설명하기 위하여, 특징들을 사용할 수 있다.
컨트롤러(Controller) 스택은 물리 계층(Physical Layer,390), 링크 계층(Link Layer,380) 및 호스트 컨트롤러 인터페이스(Host Controller Interface,370)를 포함한다.
물리 계층(무선 송수신 모듈,390)은 2.4 GHz 무선 신호를 송수신하는 계층으로 GFSK (Gaussian Frequency Shift Keying) modulation과 40 개의 RF 채널로 구성된 frequency hopping 기법을 사용한다.
링크 계층(380)은 블루투스 패킷을 전송하거나 수신한다.
또한, 링크 계층은 3개의 Advertising 채널을 이용하여 Advertising, Scanning 기능을 수행한 후에 디바이스 간 연결을 생성하고, 37개 Data 채널을 통해 최대 42bytes 의 데이터 패킷을 주고 받는 기능을 제공한다.
HCI(Host Controller Interface)는 Host 스택과 Controller 스택 사이의 인터페이스를 제공하여, Host 스택에서 command와 Data를 Controller 스택으로 제공하게 하며, Controller 스택에서 event와 Data를 Host 스택으로 제공하게 해준다.
이하에서, 블루투스 저전력 에너지(Bluetooth Low Energy:BLE) 기술의 절차(Procedure)들에 대해 간략히 살펴보기로 한다.
BLE 절차는 디바이스 필터링 절차(Device Filtering Procedure), 광고 절차(Advertising Procedure), 스캐닝 절차(Scanning Procedure), 디스커버링 절차(Discovering Procedure), 연결 절차(Connecting Procedure) 등으로 구분될 수 있다.
디바이스 필터링 절차(Device Filtering Procedure)
디바이스 필터링 절차는 컨트롤러 스택에서 요청, 지시, 알림 등에 대한 응답을 수행하는 디바이스들의 수를 줄이기 위한 방법이다.
모든 디바이스에서 요청 수신 시, 이에 대해 응답하는 것이 불필요하기 때문에, 컨트롤러 스택은 요청을 전송하는 개수를 줄여서, BLE 컨트롤러 스택에서 전력 소비가 줄 수 있도록 제어할 수 있다.
광고 디바이스 또는 스캐닝 디바이스는 광고 패킷, 스캔 요청 또는 연결 요청을 수신하는 디바이스를 제한하기 위해 상기 디바이스 필터링 절차를 수행할 수 있다.
여기서, 광고 디바이스는 광고 이벤트를 전송하는 즉, 광고를 수행하는 디바이스를 말하며, 광고자(Advertiser)라고도 표현된다.
스캐닝 디바이스는 스캐닝을 수행하는 디바이스, 스캔 요청을 전송하는 디바이스를 말한다.
BLE에서는, 스캐닝 디바이스가 일부 광고 패킷들을 광고 디바이스로부터 수신하는 경우, 상기 스캐닝 디바이스는 상기 광고 디바이스로 스캔 요청을 전송해야 한다.
하지만, 디바이스 필터링 절차가 사용되어 스캔 요청 전송이 불필요한 경우, 상기 스캐닝 디바이스는 광고 디바이스로부터 전송되는 광고 패킷들을 무시할 수 있다.
연결 요청 과정에서도 디바이스 필터링 절차가 사용될 수 있다. 만약, 연결 요청 과정에서 디바이스 필터링이 사용되는 경우, 연결 요청을 무시함으로써 상기 연결 요청에 대한 응답을 전송할 필요가 없게 된다.
광고 절차(Advertising Procedure)
광고 디바이스는 영역 내 디바이스들로 비지향성의 브로드캐스트를 수행하기 위해 광고 절차를 수행한다.
여기서, 비지향성의 브로드캐스트는 특정 방향으로의 브로드캐스트가 아닌 전(모든) 방향으로의 브로드캐스트를 말한다.
이와 달리, 지향성 브로드 캐스트는 특정 방향으로의 브로드캐스트를 말한다. 비지향성 브로드캐스트는 광고 디바이스와 리스닝(또는 청취) 상태에 있는 디바이스(이하, 리스닝 디바이스라 한다.) 간에 연결 절차 없이 발생한다.
광고 절차는 근처의 개시 디바이스와 블루투스 연결을 확립하기 위해 사용된다.
또는, 광고 절차는 광고 채널에서 리스닝을 수행하고 있는 스캐닝 디바이스들에게 사용자 데이터의 주기적인 브로드캐스트를 제공하기 위해 사용될 수 있다.
광고 절차에서 모든 광고(또는 광고 이벤트)는 광고 물리 채널을 통해 브로드캐스트된다.
광고 디바이스들은 광고 디바이스로부터 추가적인 사용자 데이터를 얻기 위해 리스닝을 수행하고 있는 리스닝 디바이스들로부터 스캔 요청을 수신할 수 있다. 광고 디바이스는 스캔 요청을 수신한 광고 물리 채널과 동일한 광고 물리 채널을 통해, 스캔 요청을 전송한 디바이스로 스캔 요청에 대한 응답을 전송한다.
광고 패킷들의 일 부분으로서 보내지는 브로드캐스트 사용자 데이터는 동적인 데이터인 반면에, 스캔 응답 데이터는 일반적으로 정적인 데이터이다.
광고 디바이스는 광고 (브로드캐스트) 물리 채널 상에서 개시 디바이스로부터 연결 요청을 수신할 수 있다. 만약, 광고 디바이스가 연결 가능한 광고 이벤트를 사용하였고, 개시 디바이스가 디바이스 필터링 절차에 의해 필터링 되지 않았다면, 광고 디바이스는 광고를 멈추고 연결 모드(connected mode)로 진입한다. 광고 디바이스는 연결 모드 이후에 다시 광고를 시작할 수 있다.
스캐닝 절차(Scanning Procedure)
스캐닝을 수행하는 디바이스 즉, 스캐닝 디바이스는 광고 물리 채널을 사용하는 광고 디바이스들로부터 사용자 데이터의 비지향성 브로드캐스트를 청취하기 위해 스캐닝 절차를 수행한다.
스캐닝 디바이스는 광고 디바이스로부터 추가적인 데이터를 요청 하기 위해, 광고 물리 채널을 통해 스캔 요청을 광고 디바이스로 전송한다. 광고 디바이스는 광고 물리 채널을 통해 스캐닝 디바이스에서 요청한 추가적인 데이터를 포함하여 상기 스캔 요청에 대한 응답인 스캔 응답을 전송한다.
상기 스캐닝 절차는 BLE 피코넷에서 다른 BLE 디바이스와 연결되는 동안 사용될 수 있다.
만약, 스캐닝 디바이스가 브로드캐스트되는 광고 이벤트를 수신하고, 연결 요청을 개시할 수 있는 개시자 모드(initiator mode)에 있는 경우, 스캐닝 디바이스는 광고 물리 채널을 통해 광고 디바이스로 연결 요청을 전송함으로써 광고 디바이스와 블루투스 연결을 시작할 수 있다.
스캐닝 디바이스가 광고 디바이스로 연결 요청을 전송하는 경우, 스캐닝 디바이스는 추가적인 브로드캐스트를 위한 개시자 모드 스캐닝을 중지하고, 연결 모드로 진입한다.
디스커버링 절차(Discovering Procedure)
블루투스 통신이 가능한 디바이스(이하, '블루투스 디바이스'라 한다.)들은 근처에 존재하는 디바이스들을 발견하기 위해 또는 주어진 영역 내에서 다른 디바이스들에 의해 발견되기 위해 광고 절차와 스캐닝 절차를 수행한다.
디스커버링 절차는 비대칭적으로 수행된다. 주위의 다른 디바이스를 찾으려고 하는 블루투스 디바이스를 디스커버링 디바이스(discovering device)라 하며, 스캔 가능한 광고 이벤트를 광고하는 디바이스들을 찾기 위해 리스닝한다. 다른 디바이스로부터 발견되어 이용 가능한 블루투스 디바이스를 디스커버러블 디바이스(discoverable device)라 하며, 적극적으로 광고 (브로드캐스트) 물리 채널을 통해 다른 디바이스가 스캔 가능하도록 광고 이벤트를 브로드캐스트한다.
디스커버링 디바이스와 디스커버러블 디바이스 모두 피코넷에서 다른 블루투스 디바이스들과 이미 연결되어 있을 수 있다.
연결 절차(Connecting Procedure)
연결 절차는 비대칭적이며, 연결 절차는 특정 블루투스 디바이스가 광고 절차를 수행하는 동안 다른 블루투스 디바이스는 스캐닝 절차를 수행할 것을 요구한다.
즉, 광고 절차가 목적이 될 수 있으며, 그 결과 단지 하나의 디바이스만 광고에 응답할 것이다. 광고 디바이스로부터 접속 가능한 광고 이벤트를 수신한 이후, 광고 (브로트캐스트) 물리 채널을 통해 광고 디바이스로 연결 요청을 전송함으로써 연결을 개시할 수 있다.
다음으로, BLE 기술에서의 동작 상태 즉, 광고 상태(Advertising State), 스캐닝 상태(Scanning State), 개시 상태(Initiating State), 연결 상태(connection state)에 대해 간략히 살펴보기로 한다.
광고 상태(Advertising State)
링크 계층(LL)은 호스트 (스택)의 지시에 의해, 광고 상태로 들어간다. 링크 계층이 광고 상태에 있을 경우, 링크 계층은 광고 이벤트들에서 광고 PDU(Packet Data Unit)들을 전송한다.
각각의 광고 이벤트는 적어도 하나의 광고 PDU들로 구성되며, 광고 PDU들은 사용되는 광고 채널 인덱스들을 통해 전송된다. 광고 이벤트는 광고 PDU가 사용되는 광고 채널 인덱스들을 통해 각각 전송되었을 경우, 종료되거나 광고 디바이스가 다른 기능 수행을 위해 공간을 확보할 필요가 있을 경우 좀 더 일찍 광고 이벤트를 종료할 수 있다.
스캐닝 상태(Scanning State)
링크 계층은 호스트 (스택)의 지시에 의해 스캐닝 상태로 들어간다. 스캐닝 상태에서, 링크 계층은 광고 채널 인덱스들을 리스닝한다.
스캐닝 상태에는 수동적 스캐닝(passive scanning), 적극적 스캐닝(active scanning)의 두 타입이 있으며, 각 스캐닝 타입은 호스트에 의해 결정된다.
스캐닝을 수행하기 위한 별도의 시간이나 광고 채널 인덱스가 정의되지는 않는다.
스캐닝 상태 동안, 링크 계층은 스캔윈도우(scanWindow) 구간(duration) 동안 광고 채널 인덱스를 리스닝한다. 스캔인터벌(scanInterval)은 두 개의 연속적인 스캔 윈도우의 시작점 사이의 간격(인터벌)으로서 정의된다.
링크 계층은 스케쥴링의 충돌이 없는 경우, 호스트에 의해 지시되는 바와 같이 스캔윈도우의 모든 스캔인터벌 완성을 위해 리스닝해야한다. 각 스캔윈도우에서, 링크 계층은 다른 광고 채널 인덱스를 스캔해야한다. 링크 계층은 사용 가능한 모든 광고 채널 인덱스들을 사용한다.
수동적인 스캐닝일 때, 링크 계층은 단지 패킷들만 수신하고, 어떤 패킷들도 전송하지 못한다.
능동적인 스캐닝일 때, 링크 계층은 광고 디바이스로 광고 PDU들과 광고 디바이스 관련 추가적인 정보를 요청할 수 있는 광고 PDU 타입에 의존하기 위해 리스닝을 수행한다.
개시 상태(Initiating State)
링크 계층은 호스트(스택)의 지시에 의해 개시 상태로 들어간다.
링크 계층이 개시 상태에 있을 때, 링크 계층은 광고 채널 인덱스들에 대한 리스닝을 수행한다.
개시 상태 동안, 링크 계층은 스캔윈도우 구간 동안 광고 채널 인덱스를 리스닝한다.
연결 상태(connection state)
링크 계층은 연결 요청을 수행하는 디바이스 즉, 개시 디바이스가 CONNECT_REQ PDU를 광고 디바이스로 전송할 때 또는 광고 디바이스가 개시 디바이스로부터 CONNECT_REQ PDU를 수신할 때 연결 상태로 들어간다.
연결 상태로 들어간 이후, 연결이 생성되는 것으로 고려된다. 다만, 연결이 연결 상태로 들어간 시점에서 확립되도록 고려될 필요는 없다. 새로 생성된 연결과 기 확립된 연결 간의 유일한 차이는 링크 계층 연결 감독 타임아웃(supervision timeout) 값뿐이다.
두 디바이스가 연결되어 있을 때, 두 디바이스들은 다른 역할로 활동한다.
마스터 역할을 수행하는 링크 계층은 마스터로 불리며, 슬레이브 역할을 수행하는 링크 계층은 슬레이브로 불린다. 마스터는 연결 이벤트의 타이밍을 조절하고, 연결 이벤트는 마스터와 슬레이브 간 동기화되는 시점을 말한다.
이하에서, 블루투스 인터페이스에서 정의되는 패킷에 대해 간략히 살펴보기로 한다. BLE 디바이스들은 하기에서 정의되는 패킷들을 사용한다.
패킷 포맷(Packet Format)
링크 계층(Link Layer)은 광고 채널 패킷과 데이터 채널 패킷 둘 다를 위해 사용되는 단지 하나의 패킷 포맷만을 가진다.
각 패킷은 프리앰블(Preamble), 접속 주소(Access Address), PDU 및 CRC 4개의 필드로 구성된다.
하나의 패킷이 광고 물리 채널에서 송신될 때, PDU는 광고 채널 PDU가 될 것이며, 하나의 패킷이 데이터 물리 채널에서 전송될 때, PDU는 데이터 채널 PDU가 될 것이다.
광고 채널 PDU(Advertising Channel PDU)
광고 채널 PDU(Packet Data Unit)는 16비트 헤더와 다양한 크기의 페이로드를 가진다.
헤더에 포함되는 광고 채널 PDU의 PDU 타입 필드는 하기 표 1에서 정의된 바와 같은 PDU 타입을 나타낸다.
Figure PCTKR2021095004-appb-img-000001
광고 PDU(Advertising PDU)
아래 광고 채널 PDU 타입들은 광고 PDU로 불리고 구체적인 이벤트에서 사용된다.
ADV_IND: 연결 가능한 비지향성 광고 이벤트
ADV_DIRECT_IND: 연결 가능한 지향성 광고 이벤트
ADV_NONCONN_IND: 연결 가능하지 않은 비지향성 광고 이벤트
ADV_SCAN_IND: 스캔 가능한 비지향성 광고 이벤트
상기 PDU들은 광고 상태에서 링크 계층(Link Layer)에서 전송되고, 스캐닝 상태 또는 개시 상태(Initiating State)에서 링크 계층에 의해 수신된다.
스캐닝 PDU(Scanning PDU)
아래 광고 채널 PDU 타입은 스캐닝 PDU로 불리며, 하기에서 설명되는 상태에서 사용된다.
SCAN_REQ: 스캐닝 상태에서 링크 계층에 의해 전송되며, 광고 상태에서 링크 계층에 의해 수신된다.
SCAN_RSP: 광고 상태에서 링크 계층에 의해 전송되며, 스캐닝 상태에서 링크 계층에 의해 수신된다.
개시 PDU(Initiating PDU)
아래 광고 채널 PDU 타입은 개시 PDU로 불린다.
CONNECT_REQ: 개시 상태에서 링크 계층에 의해 전송되며, 광고 상태에서 링크 계층에 의해 수신된다.
데이터 채널 PDU(Data Channel PDU)
데이터 채널 PDU는 16 비트 헤더, 다양한 크기의 페이로드를 가지고, 메시지 무결점 체크(Message Integrity Check:MIC) 필드를 포함할 수 있다.
앞에서 살펴본, BLE 기술에서의 절차, 상태, 패킷 포맷 등은 본 명세서에서 제안하는 방법들을 수행하기 위해 적용될 수 있다.
도 5는 블루투스 저전력 에너지의 GATT(Generic Attribute Profile)의 구조의 일 예를 나타낸다.
도 5를 참조하면 블루투스 저전력 에너지의 프로파일 데이터(Profile Data) 교환을 위한 구조를 살펴볼 수 있다.
구체적으로, GATT(Generic Attribute Profile)는 블루투스 LE 장치 간의 서비스(Service), 특성(Characteristic)을 이용해서 데이터를 주고받는 방법을 정의한 것이다.
일반적으로, 페리페럴(Peripheral) 장치(예를 들면, 센서 장치)가 GATT 서버(Server)역할을 하며, 서비스(Service), 특성(Characteristic)에 대한 정의를 가지고 있다.
데이터를 읽거나 쓰기 위해서 GATT 클라이언트는 GATT 서버로 데이터 요청을 보내게 되며, 모든 동작(Transaction)은 GATT client에서 시작되어 GATT 서버로부터 응답을 받게 된다.
블루투스 LE에서 사용하는 GATT 기반 동작구조는 프로파일(Profile), 서비스(Service), 특성(Characteristic)에 기초하며, 상기 도 5와 같은 수직 구조를 이룰 수 있다.
상기 프로파일(Profile) 하나 또는 그 이상의 서비스들로 구성되어 있으며, 상기 서비스는 하나 이상의 특성 또는 다른 서비스들로 구성되어 있을 수 있다.
상기 서비스(Service)는 데이터를 논리적인 단위로 나누는 역할을 하며 하나 이상의 특성(Characteristic) 또는 다른 서비스들을 포함하고 있을 수 있다. 각 서비스는 UUID(Universal Unique Identifier)라 불리는 16bit 또는 128bit의 구분자를 가지고 있다.
상기 특성(Characteristic)은 GATT 기반 동작 구조에서 가장 하위 단위이다. 상기 특성은 단 하나의 데이터를 포함하며, 상기 서비스와 유사하게 16 bit 또는 128 bit의 UUID를 가지고 있다.
상기 특성은 여러 가지 정보들의 값으로 정의되고, 각각의 정보를 담기 위해서 속성(Attribute)을 하나씩 필요로 한다. 상기 특성 여러 개의 연속된 속성을 사용할 수 있다.
상기 속성(Attribute)은 네 개의 구성 요소로 이루어지며, 아래와 같은 의미를 갖는다.
- handle: 속성의 주소
- Type: 속성의 유형
- Value: 속성의 값
- Permission: 속성에 대한 접근 권한
도 6은 본 발명이 적용될 수 있는 블루투스 저전력 에너지 기술에서 연결 절차 방법의 일 예를 나타내는 흐름도이다.
서버는 클라이언트로 3개의 광고 채널을 통해 광고 메시지를 전송한다(S5010).
서버는 연결 전에는 광고자(Advertiser)로 호칭될 수 있고, 연결 이후에는 마스터(Master)로 호칭될 수 있다. 상기 서버의 일 예로, 센서(온도 센서 등)이 있을 수 있다.
또한, 클라이언트는 연결 전에는 스캐너(Scanner)로 호칭될 수 있고, 연결 이후에는 슬레이브(Slave)로 호칭될 수 있다. 클라이언트의 일 예로 스마트 폰 등이 있을 수 있다.
앞에서 살펴본 것처럼, 블루투스는 2.4GHz 밴드를 통해 총 40개의 채널로 나뉘어 통신을 한다. 40개의 채널 중 3개의 채널은 광고 채널로써, 각종 광고 패킷(Advertising Packet)을 비롯하여 연결을 맺기 위해 주고 받는 패킷들의 교환에 이용된다.
나머지 37개의 채널들은 데이터 채널로 연결 이후의 데이터 교환에 이용된다.
상기 클라이언트는 상기 광고 메시지를 수신한 후, 상기 서버로 추가적인 데이터(예: 서버 디바이스 이름 등)을 획득하기 위해 서버로 스캔 요청 메시지(Scan Request message)를 전송할 수 있다.
이 경우, 상기 서버는 상기 클라이언트로 스캔 요청 메시지(Scan Request message)에 대한 응답으로 추가적인 데이터를 포함하는 스캔 응답 메시지(Scan Response message)를 전송한다.
여기서, 스캔 요청 메시지(Scan Request message) 및 스캔 응답 메시지(Scan Response message)는 광고 패킷의 한 종료로써, 광고 패킷은 31 bytes 이하의 사용자 데이터(User Data)만을 포함할 수 있다.
따라서, 데이터의 크기가 3 bytes보다 크지만, 연결까지 맺어서 데이터를 보내기에는 오버헤드가 큰 데이터가 존재하는 경우, 스캔 요청 메시지/스캔 응답 메시지를 이용하여 두번에 걸쳐서 데이터를 나눠 보낸다.
다음, 클라이언트는 서버와 블루투스 연결 설정을 위한 연결 요청 메시지(Connection Request message)를 서버로 전송한다(S5020).
이를 통해, 서버와 클라이언트 간에 Link Layer(LL) 연결이 형성(establish)된다.
이후, 서버와 클라이언트는 보안 설립 절차를 수행한다.
보안 설립 절차는 보안 심플 페어링(Secure Simple Pairing)으로 해석되거나 이를 포함하여 수행될 수 있다.
즉, 보안 설립 절차는 페이즈(Phase) 1 단계 내지 페이즈 3 단계를 거쳐 수행될 수 있다.
구체적으로, 서버와 클라이언트 간에 페어링 절차(페이즈 1)를 수행한다(S5030).
페어링 절차는 클라이언트가 서버로 페어링 요청 메시지(Pairing Request message)를 전송하고, 서버가 클라이언트로 페어링 응답 메시지(Pairing Response message)를 전송한다.
페어링 절차를 통해서 장치간 인증 요건(authentication requirements)과 인풋/아웃풋 능력(I(Input)/O(Output) capabilities)과 키 사이즈(Key Size)정보를 주고 받는다. 이 정보를 통해 페이즈 2에서 어떤 키(Key) 생성 방법을 사용할지 결정하게 된다.
다음, 페이즈 2로서, 서버와 클라이언트 간에 레거시 페어링(Legacy pairing) 또는 보안 연결(Secure Connections)을 수행한다(S5040).
페이즈 2에서 레거시 페어링을 수행하는 128bits의 임시 키(Temporary Key) 및 쇼트 텀 키(Short Term Key(STK))를 생성한다.
- 임시 키(Temporary Key): STK를 생성하기 위해 만들어진 Key
- 쇼트 텀 키(Short Term Key(STK)): 기기간 암호화된 연결(Encrypted connection)을 만드는데 사용되는 Key 값
만약, 페이즈 2에서 보안 연결을 수행하는 경우, 128 bit의 롱 텀 키(Long Term Key(LTK))를 생성한다.
- 롱 텀 키(Long Term Key(LTK)): 기기간 암호화된 연결뿐만 아니라 추후의 연결에서도 사용되는 Key 값
다음, 페이즈 3으로서, 서버와 클라이언트 간에 키 분배(Key Distribution) 절차를 수행한다(S5050).
이를 통해, 서버와 클라이언트간에 보안 연결이 확립되고, 암호화된 링크를 형성하여 데이터를 송수신할 수 있게 된다.
이하에서, 무선 통신 시스템에서 근거리 무선 통신을 이용한 사용자 계정 관리(user account management) 방법에 대해서 구체적으로 설명하도록 한다.
무선 통신이 가능한 기기(device)들 간에 데이터가 송수신 되기 위해서는, 두 기기 중 한 기기가 데이터를 송수신하고자 하는 다른 기기를 검색하고, 상기 다른 기기와 연결을 형성해야 한다. 또한, 두 기기간의 연결을 형성하는 과정에서 두 기기 간의 상호 인증을 위한 인증 절차가 수행되어야 한다. 인증 절차는 두 기기간에 서로 인증하고, 사용 권한을 부여하는 과정일 수 있다. 상기 인증 절차의 수행 과정에서 사용자는 연결을 형성하고자 하는 두 기기에서 다양한 설정을 해야 한다. 이 때, 각각의 기기의 특성 및 각각의 기기가 사용하는 무선 통신의 기술에 따라서 검색, 연결, 인증 방식이 다를 수 있는데, 이는 사용자에게 불편함을 초래할 수 있다. 보다 구체적으로, 두 기기간의 연결이 처음 형성되는 경우, 두 기기 간의 인증 절차를 위해 소요되는 시간이 이미 연결 이력이 있는 경우에 비교하여 길어질 수 있다. 특히, 헤드셋(headset), 웨어러블(Wearable) 기기 등은 디스플레이(Display)의 크기, 조작 버튼의 제약으로 인해, 데이터를 송수신하고자 하는 다른 기기를 검색하여 사용자에게 보여주는 동작, 상기 다른 기기와 연결을 형성하는 동작과 관련된 UX(user experience)에 불편함이 있다. 위와 같은 사용자의 불편함을 해결하기 위해, 두 기기간의 연결을 최초로 형성하는 두 기기 간의 인증 절차 수행의 개선이 필요하다.
또한, 사용자의 개인 계정에 기반하여 두 기기 간의 인증 절차가 수행된 후 두 기기가 연결을 형성할 때, 단일 사용자가 다수의 계정을 가진 경우 또는 한 기기에 다수의 계정이 등록된 경우를 관리할 수 있는 방법이 없는데, 이는 사용자의 불편함을 초래할 수 있다. 따라서, 단일 사용자가 다수의 계정을 가진 경우 또는 한 기기에 다수의 계정이 등록된 경우에서도 무선 통신에서 필수적인 인증(Authentication), 권한 부여(Authorization) 및 보안 절차를 사용자의 불편함 없이 지원 가능하도록 할 필요가 있다.
본 명세서는, 두 기기 간의 연결을 위한 다수의 사용자 보안 관리(Multiple User Credential Management for connection between two devices)방법 (방법 1)을 제안한다. 보다 구체적으로, 본 방법은 헤드셋(Headset), 웨어러블(Wearable) 등의 기기가 랩탑(Laptop) 컴퓨터, 핸드폰 등의 기기와 근접했다는 것을 감지하고, 사용자 계정(Account) 정보를 획득하면, 근접한 두 기기간의 연결을 자동으로 형성하기 위한 프로토콜(Protocol)을 제안한다. 또한, 본 방법은 한 명의 사용자가 다수의 계정을 사용하거나, 하나의 기기가 다수의 계정을 관리할 경우에 대한 기기의 동작 방식을 제안한다. 본 제안을 통하여, 사용자가 자신의 다수의 기기와 특정 기기를 연결, 제어하고자 할 경우, 사용자는 자신의 다수의 기기 개수만큼의 인증 절차를 수행하지 않을 수 있다.
본 명세서에서, 헤드셋, 웨어러블 등의 기기는 보안 제공자(Credential Provider), 보안 제공자 디바이스, 제 3 디바이스 등으로 호칭될 수 있으며, 이와 동일 또는 유사하게 해석되는 범위에서 다양하게 표현 가능함은 물론이다. 또한, 랩탑(Laptop) 컴퓨터, 핸드폰 등의 기기는 보안 검색자(Credential Seeker), 보안 검색자 디바이스, 제 1 디바이스, 제 2 디바이스 등으로 호칭될 수 있으며, 이와 동일 또는 유사하게 해석되는 범위에서 다양하게 표현 가능함은 물론이다.
본 방법을 통해 보안 제공자와 보안 검색자 간의 무선 연결이 사용자의 계정 정보에 기반하여 손쉽게 형성될 수 있다. 또한, 사용자가 보안 제공자 및 보안 검색자의 조작에 익숙하지 않은 경우, 사용자는 두 기기에 대한 별도의 조작 없이도 두 기기 간의 연결을 형성할 수 있다. 추가적으로, 사용자가 다수의 어플리케이션과 각각 관련된 다수의 계정을 보유하고 있는 경우, 사용자는 계정 별로 보안 토큰(Credential token)을 생성하지 않고, 사용자의 모든 계정에 적용될 수 있는 통합 보안 토큰을 생성할 수 있다.
또한, 본 명세서는 보안 만료 및 갱신(Credential Expiration and Refresh) 방법 (방법 2)을 제안한다. 보다 구체적으로, 본 방법은 권한 관리자(Authority Manager) 기기가 다른 기기들에게 기기 제어 권한 및 Credential을 부여하고, 부여된 Credential을 회수, 변경하는 방안을 제안한다. 여기서 다른 기기는 보안 제공자 디바이스 및/또는 보안 검색자 디바이스일 수 있다. 권한 관리자 기기는 다른 기기가 사용자 정보를 가지고 있는지를 확인하고, 인증된 사용자 정보를 가지고 있을 경우 제어/연결에 대한 권한을 상기 다른 기기에게 부여할 수 있다. 본 방법을 통해, 권한 관리자 기기가 특정 공간에서의 정책, 권한, Credential을 다른 기기들(보안 제공자 및/또는 보안 검색자 디바이스)에게 부여하고 회수, 변경하는 것이 가능하다. 사용자의 기기들이 정책 관리자 기기에게 인증을 받으면, 사용자는 자신의 기기들을 이용하여 특정 공간의 기기들을 쉽게 연결하고, 제어하는 것이 가능하다. 또한, 본 방법을 통하여, 사용자는 장시간 동일한 Credential을 사용하거나, 특정 공간에서 임시로 사용하는 보안 정보에 대한 폐기, 최신화를 수행하여 보안 강도가 강화될 수 있다. 이하에서, A 및/또는 B는 A와 B 중 적어도 하나를 나타내는 것을 의미할 수 있다.
도 7은 서버와 디바이스 간의 권한 토큰 확인(Right Token Check)과정을 설명하기 위한 일 예를 나타낸 도이다.
권한 토큰 확인 과정은, 계정에 대한 권한을 구매한 사용자의 토큰을 검증하고, 기기를 이용하여 서비스/콘텐츠를 소비하기 위한 과정이다. 모바일 핸드셋 D1은 중간 장치(IMD1)의 기능을 확인하고, 대상 장치(IMD1)에서 CS의 DRM 보호 콘텐츠를 다운로드하고 재생할 수 있는지 확인한다
S710: 디바이스1(D1) 다운로드를 위한 미디어 리스트를 CS로 전송한다.
S720: CS는 다운로드할 미디어를 선택한다.
S730: 디바이스 1(D1)과 중간 장치(IMD1)은 디바이스 디스커버리 절차를 수행한다.
S740: 디바이스 1(D1)은 중간 장치(IMD1)로 중간 장치(IMD1)의 능력 정보를 요청한다.
S750: 중간 장치(IMD1)는 이에 대한 응답으로 디바이스 1(D1)로 자신의 능력 정보를 전송한다.
S760: 디바이스 1(D1)은 중간 장치(IMD1)로 Queue 요청을 전송한다.
S770: 이후, CS는 중간장치(IMD1)로 미디어 Queuing/ 다운로드를 요청한다.
상기 S750 단계와 S760 단계에서 본 명세서에서 제안하는 방법들이 적용될 수 있다.
디바이스가 특정 기능을 수행할 때, 상기 디바이스가 상기 특정 기능을 수행하기 위한 상기 디바이스의 모드(mode), 상태(state), 상기 특정 기능을 수행하기 위한 절차(procedure), 상기 특정 기능을 수행하기 위해 송수신되는 메시지(message), 상기 메시지에 포함되는 파라미터(parameter)가 정의될 수 있다. 이는 표 2에 나타난 것과 같고, 도 8은 디바이스가 특정 기능을 수행하기 위해 정의되는 디바이스의 모드 등에 대한 이해를 돕기 위한 일 예를 나타낸 도이다.
Figure PCTKR2021095004-appb-img-000002
표 3은 디바이스가 본 명세서에서 제안하는 방법들을 수행하기 위해 정의되는 모드(mode), 상태(state), 절차(procedure), 메시지(message) 및 파라미터(parameter)를 나타낸다.
Figure PCTKR2021095004-appb-img-000003
이하에서, 앞서 언급한 내용들을 토대로 방법 1 및 방법 2에 대해서 구체적으로 설명하며, 설명의 편의를 위해, 이하에서는 보안 제공자 등으로 표현될 수 있는 디바이스는 보안 제공자 디바이스, 보안 검색자 등으로 표현될 수 있는 디바이스는 보안 검색자 디바이스로 통일하여 호칭하도록 한다.
두 디바이스 간의 연결을 위한 다수의 사용자 보안 관리 방법-(방법 1)
본 방법은, 연결을 형성하고자 하는 두 디바이스 간에 서로 연결을 형성한 기록이 없더라도, 상기 두 디바이스가 동일한 계정(Account) 정보를 가진 경우, 상기 두 디바이스 간의 추가적인 인증이나, 사용자의 별도 입력(Input) 없이도 자동으로 상기 두 디바이스 간의 연결이 형성되도록 하는 방법에 관한 것이다. 이하에서, 계정 정보에 기초하여 서로 연결을 형성한 기록이 없는 두 기기간에 자동으로 연결을 형성하도록 하는 동작은 계정 기반 페어링(Account Based Pairing: ABP), 보안-기반 인증(Credential-based authorization) 등으로 호칭될 수 있으며, 이와 동일/유사하게 해석되는 범위에서 다양하게 호칭될 수 있다.
보다 구체적으로, 사용자의 계정(account)은 보안 브로커(Credential Broker)에 의해 관리되고 제공된다. 상기 보안 브로커는 특정 어플리케이션/특정 서비스 등을 제공하는 어플리케이션/서비스 제공자일 수 있고, 상기 사용자의 계정은 사용자가 상기 보안 브로커가 제공하는 특정 어플리케이션/특정 서비스를 이용하기 위해 생성한 계정일 수 있다. 즉, 사용자가 특정 어플리케이션/서비스 제공자가 제공하는 어플리케이션/서비스를 이용하기 위한 계정을 생성한 경우, 상기 특정 어플리케이션/서비스 제공자는 보안 브로커로서의 역할을 수행할 수 있다. 다시 말해, 상기 특정 어플리케이션/서비스 제공자는 보안 브로커로서 사용자의 계정을 관리하고, 보안 검색자 디바이스 및 보안 제공자 디바이스 사이에 사용되는 보안 토큰(credential token) 관련 정보를 보안 검색자 디바이스 및 보안 제공자 디바이스에게 제공할 수 있다. 여기서, 상기 보안 브로커로부터 제공 받은 보안 토큰 관련 정보에 기초하여, 상기 보안 검색자 디바이스 및 상기 보안 제공자 디바이스 간에 연결이 형성된 적이 없더라도, 상기 보안 검색자 디바이스 및 상기 보안 제공자 디바이스는 추가적인 인증 또는 사용자의 별도 입력 없이도 연결을 자동으로 형성할 수 있다.
일반적으로 보안 검색자 디바이스 및 보안 제공자 디바이스는 한 명의 사용자 소유의 디바이스인 경우가 많으므로, 한 명의 사용자에 대한 계정 정보만을 관리한다. 반대로, 하나의 디바이스를 복수의 사용자가 사용하는 경우, 보안 제공자 디바이스는 보안 토큰 스토어(Credential Token Store)에 복수의 사용자와 각각 관련된 복수의 보안 토큰에 대한 정보를 저장하여 관리할 수 있다.
앞서 설명한 내용을 도 9를 참조하여 보다 구체적으로 살펴본다. 도 9는 계정 기반 페어링이 수행되는 메커니즘의 일 예를 나타낸 도이다. 보다 구체적으로, 도 9는 사용자 A가 보안 검색자 디바이스 #2를 통하여 보안 제공자 디바이스 #1(120)에 접근하는 경우에 관한 것이다. 또한, 도 9에서, 보안 제공자 디바이스 #1(120)이 보안 검색자 디바이스 #2(110-2)와 연결을 형성하기 전에, 보안 제공자 디바이스 #1(120)은 먼저 보안 검색자 디바이스 #1(110-1)과 연결을 형성하고, 보안 검색자 디바이스 #1(110-1)로부터 사용자 A의 계정에 기초하여 생성된 보안 토큰 관련 정보를 획득한 상태임을 가정한다.
보안 브로커 #1, 보안 브로커 #2 및 보안 브로커 #3(900)은 각각 사용자 계정을 저장하여 관리하고 있다. 보다 구체적으로, 보안 브로커 #1은 사용자 A의 계정 #1 및 사용자 B의 계정 #2를 관리하고(910), 보안 브로커 #2는 사용자 A의 계정 #3을 관리하며(920), 보안 브로커 #3은 사용자 B의 계정 #4를 관리한다(930). 보안 브로커 #1, 보안 브로커 #2 및 보안 브로커 #3(900)은 각각 서로 다른 어플리케이션/서비스의 제공자일 수 있다. 사용자 A가 보안 검색자 디바이스 #2(110-2)를 사용하여 보안 브로커 #1 및/또는 보안 브로커 #2와 관련된 계정으로 로그인(Log-in)하면, 보안 검색자 디바이스 #2(110-2)는 사용자 A와 관련된 보안 토큰(credential token) 관련 정보를 보안 브로커 #1 및 보안 브로커 #2로부터 제공 받을 수 있다. 이후, 보안 검색자 디바이스 #2(110-2)는, 제공 받은 사용자 A와 관련된 보안 토큰 관련 정보에 기초하여, 보안 검색자 디바이스 #2(110-2) 및 보안 제공자 디바이스 #1 (120) 간에 연결이 형성된 적이 없더라도, 보안 제공자 디바이스 #1(120)과의 추가적인 인증 또는 사용자의 별도 입력 없이도 보안 제공자 디바이스 #1(120)과의 연결을 자동으로 형성할 수 있다.
이하에서, 도 10 및 도 11을 참조하여, 보안 제공자 디바이스와 연결을 형성한 적이 없는 보안 검색자 디바이스가 추가적인 인증 없이 상기 보안 제공자 디바이스와 연결을 형성하기 위한 구체적인 동작에 대해 살펴보도록 한다.
도 10은 본 명세서에서 제안하는 두 디바이스 간의 연결을 위한 사용자 계정 관리 방법의 일 예를 나타낸 흐름도이다.
보다 구체적으로, 도 10은 사용자가 하나의 보안 브로커에 대한 계정만을 가진 경우에서의 사용자 계정 관리 방법에 관한 것이다.
S10010: 보안 브로커 #1은 사용자 A의 계정 및 사용자 B의 계정을 등록한다.
S10020: 보안 브로커 #2는 사용자 A의 계정을 등록한다.
S10030: 보안 제공자 디바이스(120)는 보안 검색자 디바이스 #1(110-1)과 연결을 형성한다. 상기 연결을 블루투스 저전력(Bluetooth Low Energy: BLE)에 기초한 연결일 수 있다.
S10040: 사용자 B는 보안 브로커 #1의 계정을 통하여 보안 검색자 디바이스 #1(110-1)에 접근(Access)한다. 보다 구체적으로, 상기 사용자 B는 보안 브로커 #1로서의 역할을 수행하는 특정 어플리케이션/서비스 제공자가 제공하는 특정 어플리케이션/서비스에 상기 특정 어플리케이션/서비스와 관련된 계정을 사용하여 로그인(Log-in)하는 방식으로 상기 보안 브로커 #1에 접근할 수 있다.
S10050: 보안 검색자 디바이스 #1(110-1)은 보안 브로커 #1과 관련된 사용자 B의 계정에 기초하여 보안 토큰(credential token)을 생성한다. 상기 보안 토큰은 자격 증명 토큰이라고도 호칭될 수 있으며, 이와 동일/유사하게 해석되는 범위에서 다양하게 호칭될 수 있다.
S10060: 보안 검색자 디바이스 #1(110-1)은 보안 브로커 #1과 관련된 사용자 B의 계정에 기초하여 생성된 보안 토큰을 보안 토큰 공유(Credential Token Share)절차를 통해 보안 제공자 디바이스(120)에게 공유한다. 보다 구체적으로, 보안 제공자 디바이스(120)는 S10030에서 형성된 연결에 기초하여, 상기 보안 토큰을 포함하는 메시지를 보안 검색자 디바이스 #1(110-1)로부터 수신할 수 있다.
S10070: 보안 제공자 디바이스(120)는 토큰 ID(identifier)를 광고 패킷에(Advertising packet)에 포함하여 전송한다. 여기서, 보안 제공자 디바이스(120)는 보안 검색자 디바이스 #1(110-1)로부터 제공 받은 보안 토큰에 기초하여 상기 토큰 ID를 생성할 수 있고, 상기 토큰 ID를 포함하는 광고 메시지를 브로드캐스트(broadcast)할 수 있다. 여기서, 상기 토큰 ID는 보안 토큰 ID 등으로도 호칭될 수 있으며, 이와 동일/유사한 범위 내에서 다양하게 호칭될 수 있다.
S10080: 사용자 B는 보안 검색자 디바이스 #2(110-2)에 접근(Access)한다. 보다 구체적으로, 상기 사용자 B는 보안 브로커 #1로서의 역할을 수행하는 특정 어플리케이션/서비스 제공자가 제공하는 특정 어플리케이션/서비스에 상기 특정 어플리케이션/서비스와 관련된 계정을 사용하여 로그인(Log-in)하는 방식으로 상기 보안 브로커 #2에 접근할 수 있다.
S10090: 이후, 보안 검색자 디바이스 #2(110-2)는 사용자 B 토큰을 확인한다. 도 10에 도시되어 있지는 않지만, S11090 단계에서 보안 검색자 디바이스 #2(110-2)는 계정 기반 페어링(Account based pairing: ABP) 필터를 설정하기 위한 동작을 수행할 수 있다. 이 때, 상기 사용자 B가 상기 사용자 B와 관련된 토큰 ID의 생성의 기초가 된 계정을 통하여 보안 검색자 디바이스 #2(110-2)에 접근한 경우에 상기 ABP 필터를 설정하기 위한 동작이 성공적으로 수행될 수 있다. 상기 ABP 필터를 설정하기 위한 동작은 이하에서 도 16 등을 참조하여 보다 구체적으로 설명하도록 한다.
또한, 상기 ABP 필터는 상기 ABP 동작이 수행되도록 할 수 있는 다양한 종류의 필터일 수 있고, 일 예로 블룸 필터(Bloom filter)일 수 있다. 상기 블룸 필터는 보안 제공자 디바이스가 전송하는 광고 메시지에 포함되는 AD 타입의 종류에 따라서 다양한 크기로 설정될 수 있다.
상기 ABP 필터는 상기 ABP 필터는 토큰 필터(Token filter)라고도 호칭될 수 있으며, 이와 동일/유사하게 해석되는 범위에서 다양하게 표현될 수 있다.
S10100: 보안 검색자 디바이스 #2(110-2)는 상기 ABP 필터를 통하여 보안 제공자 디바이스(120)가 전송하는 사용자 B의 토큰 ID를 확인하고 ABP를 수행한다. 즉, 보안 검색자 디바이스 #2(110-2)와 보안 제공자 디바이스(120) 간의 디바이스 인증의 성공 여부는 사용자가 보안 검색자 디바이스 #2(110-2)에 상기 사용자 B의 토큰 ID에 기초하여 식별되는 사용자 B와 관련된 계정(즉, 보안 브로커 #1과 관련된 계정)을 통하여 접근하였는지 여부에 기초하여 결정될 수 있다.
상기 설명한 내용을 보다 일반적으로 표현하면, 보안 검색자 디바이스 #2(110-2)와 보안 제공자 디바이스(120) 간의 디바이스 인증의 성공 여부는 상기 사용자 B의 토큰 ID에 기초하여 식별되는 사용자 B와 관련된 계정이 보안 검색자 디바이스 #2(110-2)에 설정된 ABP 필터와 관련된 사용자 B와 관련된 계정과 일치하는 지 여부에 기초하여 결정되는 것으로 이해될 수 있다.
보다 구체적으로, 상기 토큰 ID에 기초하여 식별되는 상기 사용자 B와 관련된 계정이 상기 ABP 필터와 관련된 사용자 B와 관련된 계정과 일치하는 경우, 상기 디바이스 인증이 성공하며, 추가적인 인증 또는 별도 사용자 입력 없이도 보안 검색자 디바이스 #2(110-2)와 보안 제공자 디바이스(120) 간의 연결이 형성될 수 있다. 반면, 상기 토큰 ID에 기초하여 식별되는 상기 사용자 B와 관련된 계정이 상기 ABP 필터와 관련된 사용자 B와 관련된 계정과 일치하지 않는 경우, 상기 디바이스 인증은 실패하며, 보안 검색자 디바이스 #2(110-2)와 보안 제공자 디바이스(120) 간의 연결이 형성되지 않을 수 있다.
도 11은 본 명세서에서 제안하는 두 디바이스 간의 연결을 위한 사용자 계정 관리 방법의 또 다른 일 예를 나타낸 흐름도이다.
보다 구체적으로, 도 11은 사용자가 복수의 보안 브로커에 대한 복수의 계정을 가진 경우에서의 사용자 계정 관리 방법에 관한 것이다. 또한, 도 11에서 설명되는 S11010 내지 S11100 단계는 도 10에서 설명된 S10010 내지 S10100 단계 이후에 수행되는 것을 가정하는데, 이는 설명의 편의를 위한 것일 뿐, 도 11의 S11010 내지 S11100 단계는 도 10에서 설명된 S10010 내지 S10100 단계와 무관하게 독립적으로 수행될 수 있음은 물론이다.
도 11에서, 보안 브로커 #1은 사용자 A의 계정 및 사용자 B의 계정을 관리하고, 보안 브로커 #2는 사용자 A의 계정을 관리한다. 즉, 특정 사용자와 관련된 적어도 하나의 사용자 계정은 각각 서로 다른 어플리케이션(application)과 관련된 사용자 계정일 수 있다.
S11010: 보안 제공자 디바이스(120)는 보안 검색자 디바이스 #1(110-1)과 연결을 형성한다. 상기 연결을 블루투스 저전력(Bluetooth Low Energy: BLE)에 기초한 연결일 수 있다.
S11020: 사용자 A는 보안 브로커 #1의 계정 및/또는 보안 브로커 #2의 계정을 통하여 보안 검색자 디바이스 #1(110-1)에 접근(Access)한다. 보다 구체적으로, 상기 사용자 B는 (i) 보안 브로커 #1로서의 역할을 수행하는 제 1 어플리케이션/서비스 제공자가 제공하는 제 1 어플리케이션/서비스와 관련된 제 1 계정 및/또는 (ii) 보안 브로커 #2로서의 역할을 수행하는 제 2 어플리케이션/서비스 제공자가 제공하는 제 2 어플리케이션/서비스와 관련된 제 2 계정을 사용하여 상기 제 1 어플리케이션/서비스 및/또는 상기 제 2 어플리케이션/서비스에 로그인(Log-in)하는 방식으로 상기 보안 브로커 #1에 접근할 수 있다.
S11030: 보안 검색자 디바이스 #1(110-1)은 보안 브로커 #1과 관련된 상기 제 1 계정 및/또는 보안 브로커 #2와 관련된 제 2 계정에 기초하여 보안 토큰(credential token)을 생성한다. 보다 구체적으로, 보안 검색자 디바이스 #1(110-1)은 사용자 A의 보안 브로커 #1과 관련된 제 1 계정 기반 보안 토큰을 생성하거나, 또는 사용자 A의 보안 브로커 #2와 관련된 제 2 계정 기반 보안 토큰을 생성할 수 있다.
또한, 보안 검색자 디바이스 #1(110-1)은 사용자 A가 2개 이상의 보안 브로커와 관련된 2개 이상의 계정을 가지고 있을 경우, 상기 2개 이상의 계정에 기초하여 단일 보안 토큰을 생성할 수 있다. 이 경우, 보안 검색자 디바이스 #1(110-1)은 보안 브로커 #1과 관련된 상기 제 1 계정 및 보안 브로커 #2와 관련된 상기 제 2 계정에 기초하여 단일 보안 토큰을 생성할 수 있다. 상기 보안 토큰은 자격 증명 토큰이라고도 호칭될 수 있으며, 이와 동일/유사하게 해석되는 범위에서 다양하게 호칭될 수 있다. 설명의 편의를 위해, 이하에서는 보안 검색자 디바이스 #1이 단일 보안 토큰을 생성한 경우로 한정하여 설명하도록 한다.
S11040: 보안 검색자 디바이스 #1(110-1)은 보안 브로커 #1과 관련된 사용자 A의 제 1 계정에 및 보안 브로커 #2과 관련된 사용자 A의 제 2 계정에 기초하여 생성된 단일 보안 토큰을 보안 토큰 공유(Credential Token Share)절차를 통해 보안 제공자 디바이스(120)에게 공유한다. 보다 구체적으로, 보안 제공자 디바이스(120)는 S11010에서 형성된 연결에 기초하여, 상기 단일 보안 토큰을 포함하는 메시지를 보안 검색자 디바이스 #1(110-1)로부터 수신할 수 있다.
S11050: 보안 검색자 디바이스 #1(110-1)은 사용자 A 및 사용자 B 2 명의 사용자에 대한 ABP 필터를 관리한다. 즉, 보안 검색자 디바이스 #1(110-1)은 복수의 사용자에 대하여 ABP 필터를 설정하고, 복수의 사용자에 대한 보안 토큰을 관리할 수 있다. 또한, 보안 검색자 디바이스 #1(110-1)의 ABP 필터는 특정 토큰 ID를 수신하면 사용자에게 이를 통지(notify)할 수 있다. 보다 구체적으로, 보안 검색자 디바이스 #1(110-1)가 사용자 A 및/또는 사용자 B와 관련된 토큰 ID를 수신하면, 보안 검색자 디바이스 #1(110-1)는 사용자 A 및/또는 사용자 B와 관련된 토큰 ID를 수신하였음을 사용자에게 통지할 수 있다.
보안 제공자 디바이스(120)는 토큰 스토어(Token Store)에 사용자 A 및 사용자 B와 각각 관련된 두 개의 토큰(Token) ID를 저장한다. 즉, 보안 제공자 디바이스(120)를 복수의 사용자가 사용하는 경우, 상기 토큰 스토어는 복수의 사용자들 각각에 대한 토큰 ID를 저장할 수 있다. 또한, 특정 사용자에 대한 토큰 ID가 이미 생성되어 있는 경우, 이미 생성되어 있는 토큰 ID에 기초하여 식별되는 사용자 계정과 현재 시점에서의 사용자 계정이 다르면, 보안 제공자 디바이스(120)의 토큰 스토어는 이미 생성되어 있는 토큰 ID를 제거하고 토큰 ID를 업데이트 할 수 있다.
S11060: 사용자는 보안 검색자 디바이스(120)가 광고 패킷에(Advertising packet)에 포함시킬 토큰 ID를 토큰 ID 세팅(Setting)을 통해 설정할 수 있다. 보다 구체적으로, 사용자 설정에 따라, 보안 검색자 디바이스는 광고 패킷에 사용자 A의 토큰 ID 및/또는 사용자 B의 토큰 ID 중 일부/전부를 포함하여 전송할 수 있다. 이하에서는, 설명의 편의를 위해, 사용자가 보안 검색자 디바이스의 토큰 스토어에 저장된 토큰 ID를 모두 광고 패킷에 포함시키도록 설정한 경우로 한정하여 설명하도록 한다.
S11070: 보안 제공자 디바이스(120)는 사용자 A에 대한 토큰 ID 및 사용자 B에 대한 토큰 ID를 모두 광고 패킷에 포함하여 전송한다. 여기서, 보안 제공자 디바이스(120)는 보안 검색자 디바이스 #1(110-1)로부터 제공 받은 사용자 A와 관련된 단일 보안 토큰에 기초하여 상기 사용자 A에 대한 토큰 ID를 생성할 수 있고, 상기 사용자 A 및 사용자 B에 대한 2개의 토큰 ID를 포함하는 광고 메시지를 브로드캐스트(broadcast)할 수 있다.
S11080: 사용자 A는 보안 브로커 #1과 관련된 제 1 계정 및/또는 보안 브로커 #2와 관련된 제 2 계정에 기초하여 보안 검색자 디바이스 #2(110-2)에 접근(Access)한다.
S11090: 이후, 보안 검색자 디바이스 #2(110-2)는 사용자 A 토큰을 확인한다. 도 11에 도시되어 있지는 않지만, S11090 단계에서 보안 검색자 디바이스 #2(110-2)는 계정 기반 페어링(Account based pairing: ABP) 필터를 설정하기 위한 동작을 수행할 수 있다. 이 때, 상기 사용자 A가 상기 사용자 A와 관련된 토큰 ID의 생성의 기초가 된 계정(즉, 제 1 계정 및 제 2 계정) 중 적어도 하나의 계정을 통하여 보안 검색자 디바이스 #2(110-2)에 접근한 경우에 상기 ABP 필터를 설정하기 위한 동작이 성공적으로 수행될 수 있다. 상기 ABP 필터를 설정하기 위한 동작은 이하에서 도 16 등을 참조하여 보다 구체적으로 설명하도록 한다.
S11100: 보안 검색자 디바이스 #2(110-2)는 상기 ABP 필터를 통하여 보안 제공자 디바이스(120)가 전송하는 사용자 A의 토큰 ID를 확인하고 ABP를 수행한다. 즉, 보안 검색자 디바이스 #2(110-2)와 보안 제공자 디바이스(120) 간의 디바이스 인증의 성공 여부는 사용자 A가 보안 검색자 디바이스 #2(110-2)에 상기 사용자 A의 토큰 ID에 기초하여 식별되는 사용자 A와 관련된 계정(즉, 제 1 계정 및 제 2 계정) 중 적어도 하나의 계정을 통하여 접근하였는지 여부에 기초하여 결정될 수 있다.
예를 들어, 상기 사용자 A가 상기 사용자 A의 토큰 ID로부터 식별되는 제 1 계정 및 제 2 계정 중 하나인 제 1 계정으로 보안 검색자 디바이스 #2(110-2)에 접근한 경우, 보안 제공자 디바이스(120)와 보안 검색자 디바이스 #2(110-2) 간의 디바이스 인증이 성공하고, 연결이 형성될 수 있다. 다시 말하면, 상기 사용자 A가 상기 사용자 A의 토큰 ID로부터 식별되는 제 1 계정 및 제 2 계정 중 하나인 제 1 계정으로 보안 검색자 디바이스 #2(110-2)에 접근한 경우, 보안 검색자 디바이스 #2(110-2)에서의 ABP 필터 설정이 성공적으로 수행될 수 있고, 보안 검색자 디바이스 #2(110-2)는 ABP 필터를 통하여 보안 제공자 디바이스(120)가 전송한 광고 메시지에 포함된 사용자 A와 관련된 토큰 ID를 확인하여 추가적인 인증 등 없이 보안 제공자 디바이스(120)와 보안 검색자 디바이스 #2(110-2) 간의 디바이스 인증이 성공하고, 연결이 형성될 수 있다.
상기 설명한 내용을 보다 일반적으로 표현하면, 보안 검색자 디바이스 #2(110-2)와 보안 제공자 디바이스(120) 간의 디바이스 인증의 성공 여부는 상기 사용자 A의 토큰 ID에 기초하여 식별되는 사용자 A와 관련된 적어도 하나의 계정이 보안 검색자 디바이스 #2(110-2)에 설정된 ABP 필터와 관련된 사용자 A와 관련된 하나 이상의 계정 중 적어도 하나와 일치하는 지 여부에 기초하여 결정되는 것으로 이해될 수 있다.
보다 구체적으로, 상기 토큰 ID에 기초하여 식별되는 상기 사용자 A와 관련된 적어도 하나의 계정이 상기 ABP 필터와 관련된 사용자 A와 관련된 하나 이상의 계정 중 적어도 하나와 일치하는 경우, 상기 디바이스 인증이 성공하며, 추가적인 인증 또는 별도 사용자 입력 없이도 보안 검색자 디바이스 #2(110-2)와 보안 제공자 디바이스(120) 간의 연결이 형성될 수 있다. 반면, 상기 토큰 ID에 기초하여 식별되는 상기 사용자 A와 관련된 적어도 하나의 계정이 상기 ABP 필터와 관련된 사용자 A와 관련된 하나 이상의 계정과 모두 서로 다른 경우, 상기 디바이스 인증은 실패하며, 보안 검색자 디바이스 #2(110-2)와 보안 제공자 디바이스(120) 간의 연결이 형성되지 않을 수 있다.
추가적으로, 앞서 설명한 계정 기반 디바이스 인증 방법에서, 보안 검색자 디바이스와 보안 제공자 디바이스 간의 자동 연결 시, 보안 검색자 디바이스 및 보안 제공자 디바이스의 종류가 고려될 필요가 있다.
보다 구체적으로, 디바이스마다 사용 가능한 프로파일 및 서비스(Profile & Service)가 존재한다. 예를 들어, 보안 제공자 디바이스가 헤드셋(Headset)일 경우, 보안 제공자 디바이스는 A2DP와 같은 오디오 기능 또는 전화 서비스(Telephony service)를 제공할 수 있다. 또한, 보안 제공자 디바이스가 컴퓨터의 마우스일 경우, HID(Human Interface Device) 프로파일과 같이 USB기반 정보를 통한 커서 조작 기능을 제공할 수 있다.
보안 검색자 디바이스와 보안 제공자 디바이스 간의 연결이 계정 기반 페어링(ABP)에 기초하여 수행될 때, 디바이스들의 제공 가능한 프로파일 및 서비스가 고려되지 않는 경우, 디바이스간의 연결은 성공적으로 수행할 수 있으나, 연결 형성 후 후 사용자는 연결한 두 디바이스를 통하여 이용할 수 있는 서비스가 없을 수 있다. 예를 들어, 랩톱(Laptop) 컴퓨터와 마우스는 ABP를 이용해 연결하여 HID 프로파일을 수행할 수 있으나, 프린터(Printer)와 마우스가 연결된다면 사용자는 프린터와 마우스 사이의 연결을 통해 이용할 수 있는 서비스가 없을 수 있다. 따라서, 보안 검색자 디바이스와 보안 제공자 디바이스는 제공자 프로파일/서비스 능력 공유(Provider Profile/Service Capability share) 절차를 통해 보안 제공자 디바이스가 제공 가능한 프로파일 및 서비스를 보안 검색자 디바이스와 공유할 수 있다. 이하에서, 도 12를 참조하여 제공자 프로파일/서비스 능력 공유(Provider Profile/Service Capability share) 절차를 구체적으로 살펴본다.
도 12는 본 명세서에서 제안하는 두 디바이스 간의 연결을 위한 사용자 계정 관리 방법의 또 다른 일 예를 나타낸 흐름도이다.
도 12에서, 보안 브로커 #1은 사용자 A의 계정 및 사용자 B의 계정을 관리하고, 보안 브로커 #2는 사용자 A의 계정을 관리한다. 또한, 도 12는 사용자 B가 보안 검색자 디바이스 #1(110-1)을 통하여 보안 토큰을 생성하고, 보안 검색자 디바이스 (110-2) #2를 통하여 ABP를 수행하는 경우에 관한 것이다.
제공자 프로파일/서비스 능력 공유 절차는 ABP와 연계하여 도 12의 흐름도에서 3가지 시점(S12050/S12070/S12090) 중 적어도 하나의 시점에 수행될 수 있다.
S12010: 보안 제공자 디바이스(120)는 보안 검색자 디바이스 #1(110-1)과 연결을 형성한다. 상기 연결을 블루투스 저전력(Bluetooth Low Energy: BLE)에 기초한 연결일 수 있다.
S12020: 사용자 B는 보안 브로커 #1의 계정을 통하여 보안 검색자 디바이스 #1(110-1)에 접근(Access)한다. 보다 구체적으로, 상기 사용자 B는 보안 브로커 #1로서의 역할을 수행하는 특정 어플리케이션/서비스 제공자가 제공하는 특정 어플리케이션/서비스에 상기 특정 어플리케이션/서비스와 관련된 계정을 사용하여 로그인(Log-in)하는 방식으로 상기 보안 브로커 #1에 접근할 수 있다.
S12030: 보안 검색자 디바이스 #1(110-1)은 보안 브로커 #1과 관련된 사용자 B의 계정에 기초하여 보안 토큰(credential token)을 생성한다. 상기 보안 토큰은 자격 증명 토큰이라고도 호칭될 수 있으며, 이와 동일/유사하게 해석되는 범위에서 다양하게 호칭될 수 있다.
S12040: 보안 검색자 디바이스 #1(110-1)은 보안 브로커 #1과 관련된 사용자 B의 계정에 기초하여 생성된 보안 토큰을 보안 토큰 공유(Credential Token Share)절차를 통해 보안 제공자 디바이스(120)에게 공유한다. 보다 구체적으로, 보안 제공자 디바이스(120)는 S12010에서 형성된 연결에 기초하여, 상기 보안 토큰을 포함하는 메시지를 보안 검색자 디바이스 #1(110-1)로부터 수신할 수 있다.
S12050: 보안 토큰 공유 절차가 수행된 후, 보안 제공자 디바이스(120)가 애드버타이징(Advertising)할 토큰 ID를 부여/생성하는 과정에서, 보안 제공자 디바이스(120)는 어떤 프로파일 및 서비스가 이용 가능한지 보안 검색자 디바이스 #2(110-2)에게 공유한다. 보안 검색자 디바이스(110-2)는 ABP 필터를 구성할 때, 프로파일 및 서비스를 함께 고려하여 필터링(Filtering)을 할 수 있다. 즉, 보안 검색자 디바이스 #2(110-2)는 보안 제공자 디바이스(120)의 프로파일 및 서비스를 분석한 결과 자신이 제공받을 수 있는 서비스가 없는 것으로 판단한 경우, 토큰 ID로부터 식별된 사용자 계정과 사용자가 보안 검색자 디바이스 #2(110-2)에 접근하기 위해 사용한 계정이 일치하더라도, 보안 제공자 디바이스(120)와 연결을 형성하지 않을 수 있다.
S12060: 보안 제공자 디바이스(120)는 토큰 ID(identifier)를 광고 패킷에(Advertising packet)에 포함하여 전송한다. 여기서, 보안 제공자 디바이스(120)는 보안 검색자 디바이스 #1(110-1)로부터 제공 받은 보안 토큰에 기초하여 상기 토큰 ID를 생성할 수 있고, 상기 토큰 ID를 포함하는 광고 메시지를 브로드캐스트(broadcast)할 수 있다. 여기서, 상기 토큰 ID는 보안 토큰 ID 등으로도 호칭될 수 있으며, 이와 동일/유사한 범위 내에서 다양하게 호칭될 수 있다.
S12070: 보안 제공자 디바이스(120)는 토큰 ID를 광고메시지에 포함하여 전송하는 시점에 프로파일 및 서비스 정보를 함께 보안 검색자 디바이스 #2(110-2)로 제공할 수 있다. 이 때, 보안 검색자 디바이스(110-2)는, (i)토큰 ID와 (ii) 프로파일 및 서비스 정보에 기초하여, 보안 제공자 디바이스(120)와의 연결 여부를 결정할 수 있다.
S12080: 사용자 B는 보안 검색자 디바이스 #2(110-2)에 접근(Access)한다. 보다 구체적으로, 상기 사용자 B는 보안 브로커 #1로서의 역할을 수행하는 특정 어플리케이션/서비스 제공자가 제공하는 특정 어플리케이션/서비스에 상기 특정 어플리케이션/서비스와 관련된 계정을 사용하여 로그인(Log-in)하는 방식으로 상기 보안 브로커 #2에 접근할 수 있다.
S12090: 보안 제공자 디바이스(120)는 사용자의 S12080 단계 이후 프로파일 및 서비스 정보를 보안 검색자 디바이스 #2(110-2)로 제공할 수 있다.
보다 구체적으로, 보안 검색자 디바이스 #2(110-2)는 토큰 ID만으로 결정된 보안 제공자 디바이스에게 연결 형성을 요청하고, 연결된 링크 기반으로 프로파일 및 서비스 정보를 보안 제공자 디바이스(120)로부터 수신하며, 상기 링크 기반으로 수신한 프로파일 및 서비스 정보에 기초하여 최종적인 ABP 연결 여부를 결정할 수 있다.
S12100: 이후, 보안 검색자 디바이스 #2(110-2)는 사용자 B 토큰을 확인한다. 도 10에 도시되어 있지는 않지만, S11090 단계에서 보안 검색자 디바이스 #2(110-2)는 계정 기반 페어링(Account based pairing: ABP) 필터를 설정하기 위한 동작을 수행할 수 있다. 이 때, 상기 사용자 B가 상기 사용자 B와 관련된 토큰 ID의 생성의 기초가 된 계정을 통하여 보안 검색자 디바이스 #2(110-2)에 접근한 경우에 상기 ABP 필터를 설정하기 위한 동작이 성공적으로 수행될 수 있다. 상기 ABP 필터를 설정하기 위한 동작은 이하에서 도 16 등을 참조하여 보다 구체적으로 설명하도록 한다.
S12110: 보안 검색자 디바이스 #2(110-2)는 상기 ABP 필터를 통하여 보안 제공자 디바이스(120)가 전송하는 사용자 B의 토큰 ID를 확인하고 ABP를 수행한다. 즉, 보안 검색자 디바이스 #2(110-2)와 보안 제공자 디바이스(120) 간의 디바이스 인증의 성공 여부는 사용자가 보안 검색자 디바이스 #2(110-2)에 상기 사용자 B의 토큰 ID에 기초하여 식별되는 사용자 B와 관련된 계정(즉, 보안 브로커 #1과 관련된 계정)을 통하여 접근하였는지 여부에 기초하여 결정될 수 있다.
상기 설명한 내용을 보다 일반적으로 표현하면, 보안 검색자 디바이스 #2(110-2)와 보안 제공자 디바이스(120) 간의 디바이스 인증의 성공 여부는 상기 사용자 B의 토큰 ID에 기초하여 식별되는 사용자 B와 관련된 계정이 보안 검색자 디바이스 #2(110-2)에 설정된 ABP 필터와 관련된 사용자 B와 관련된 계정과 일치하는 지 여부에 기초하여 결정되는 것으로 이해될 수 있다.
도 13 및 도 14는 보안 검색자 디바이스에서의 보안 토큰 생성 및 보안 제공자 디바이스에서의 토큰 ID 관리의 일 예를 나타낸 도이다.
도 13을 참조하면, 보안 브로커 #1이 관리하는 사용자 A의 계정을 계정 #1, 보안 브로커 1이 관리하는 사용자 B의 계정을 계정 #2 및 보안 브로커 #2가 관리하는 사용자 A의 계정을 계정 #3 이라고 한다.
사용자 A는 보안 검색자 디바이스 #1(1310)의 사용자이며, 상기 보안 검색자 디바이스 #1(1310)은 어플리케이션(Application) #1 및 어플리케이션 #2, 총 2개의 어플리케이션을 사용하고 있다. 예를 들어, 상기 어플리케이션 #1 및 어플리케이션 #2는 각각 Music Player와 항공사 어플리케이션일 수 있다. 또한, 상기 어플리케이션 #1은 보안 브로커 #1과 관련된 어플리케이션이고, 상기 어플리케이션 #2는 보안 브로커 #2와 관련된 어플리케이션일 수 있다. 이 때, 상기 어플리케이션 #1 및 어플리케이션 #2는 모두 ABP 프로파일(Profile)을 사용하여 ABP 기능을 이용하는 것이 가능할 수 있다. 사용자 A의 보안 토큰(Credential token)은 계정 #1 및 계정 #3을 해싱(Hashing)하여 생성될 수 있다.
사용자 B는 보안 검색자 디바이스 #2(1320)의 사용자이며, 상기 보안 검색자 디바이스 #2(1320)는 어플리케이션(Application) #3만을 사용하고 있다. 예를 들어, 상기 어플리케이션 #3은 Music Player 어플리케이션일 수 있다. 또한, 상기 어플리케이션 #3은 보안 브로커 #1과 관련된 어플리케이션일 수 있다. 상기 어플리케이션 #3은 ABP 프로파일(Profile)을 사용하여 ABP 기능을 이용하는 것이 가능할 수 있다. 사용자 B의 보안 토큰(Credential token)은 계정 #2를 해싱(Hashing)하여 생성될 수 있다.
도 14를 참조하면, 보안 검색자 디바이스는 보안 토큰 생성을 위해 보안 브로커가 제공하는 키(Key)(1410)를 사용할 수 있고, 또는 ABP 키(Key)(1420)를 사용할 수도 있다. 여기서, ABP 키는 두 기기간의 통신에 사용되는 링크 키(Link Key)를 기반으로 생성될 수 있다. 상기 두 기기 간의 통신은 블루투스(Bluetooth) 통신일 수 있다.
다시 도 13으로 돌아와서, 보안 제공자 디바이스(1330)는 보안 검색자 디바이스(1310/1320)로부터 공유된 보안 토큰에 기초하여 사용자 별로 토큰 ID를 생성할 수 있다. 보안 제공자 디바이스(1330)은 생성된 토큰 ID를 토큰 스토어(Token Store)(1340)에 저장하고, 토큰 ID를 포함하는 광고 패킷을 전송할 수 있다. 이 때, 광고 패킷의 효율적인 활용을 위해, 보안 제공자 디바이스(1330)의 사용자는 토큰 스토어에 포함(저장)된 토큰 ID들 중 광고 패킷에 포함시킬 토큰 ID를 선택할 수 있다. 즉, 도 13에서, 보안 제공자 디바이스(1330)의 토큰 스토어(1340)는 사용자 A에 대한 토큰 ID 및 사용자 B에 대한 토큰 ID를 저장하고 있는데, 보안 제공자 디바이스(1330)의 사용자는 사용자 A에 대한 토큰 ID 및 사용자 B에 대한 토큰 ID중 보안 제공자 디바이스(1330)가 전송할 광고 패킷에 포함시킬 토큰 ID를 선택할 수 있다. 광고 패킷에 포함시킬 토큰 ID의 선택은 보안 제공자 디바이스(1330)가 사용자에게 토큰 ID에 대응하는 사용자 ID / 이름을 보여주고, 사용자는 보여지는 사용자 ID / 이름에 중에서 광고 패킷에 포함시킬 토큰 ID와 관련된 사용자 ID / 이름을 선택하는 방식으로 수행될 수 있다. 사용자의 토큰 ID 선택은 보안 제공자 디바이스(1330)의 토큰 ID 관리자(Manager)에 의해서 수행될 수 있다.
도 15는 보안 검색자 디바이스에서의 보안 토큰 생성의 또 다른 일 예를 나타낸 도이다.
보다 구체적으로, 도 15는 보안 검색자 디바이스가 복수의 사용자들에 대한 복수의 보안 토큰을 그룹핑(grouping)하여 하나의 그룹 보안 토큰을 생성하는 일 예에 관한 것이다.
도 15(a)를 참조하면, 보안 제공자 디바이스(1511)는 토큰 스토어(1512)에 사용자 A, 사용자 B, 사용자 D 및 사용자 E 각각에 대한 토큰 ID를 저장하고 있다.
광고 패킷의 크기는 제한적이므로, 보안 제공자 디바이스(1511)은 보안 검색자 디바이스와의 협상을 통해 광고 패킷에 포함시킬 토큰 ID를 결정할 수 있다. 보안 제공자 디바이스(1511)의 토큰 ID 관리자는 도 15(b)에 도시된 광고 패킷의 토큰 프레임(Token Frame)에 기초하여, 보안 검색자 디바이스와의 협상을 통해 결정된 토큰 ID를 광고 패킷에 포함시켜 전송할 수 있다. 도 15(b)에 도시된 토큰 프레임에서, Token Flags 필드는 토큰 프레임에 포함된 토큰 ID가 개별 계정과 관련된 것인지, 통합 계정과 관련된 것인지, 또는 Guest 계정과 관련된 것인지 여부를 나타낼 수 있다.
도 15(a)와 같이, 사용자 A, 사용자B, 사용자D 및 사용자 E, 4명의 토큰 ID가 토큰 스토어에 저장되어 있는 경우, 보안 검색자 디바이스와 보안 제공자 디바이스는 협상을 통해 각 사용자 별 토큰 ID를 개별적으로 광고 패킷에 포함하지 않고, 그룹핑하여 포함시키도록 결정할 수 있다. 예를 들어, 사용자 A 및 사용자 B가 가족인 경우, 사용자 A의 토큰 ID(토큰 B)와 사용자 B의 토큰 ID(토큰 A)를 모두 광고 패킷에 포함시키는 것이 아니라, 그룹 계정인 “가족” 계정에 해당하는 토큰 ID를 생성하여 광고 패킷의 토큰 프레임에 포함시킬 수 있다. 보다 구체적으로, 도 15(c)에 도시된 것과 같이, 보안 검색자 디바이스는 가족 관계인 사용자 A 및 사용자 B 각각의 계정에 기초하여 하나의 그룹 보안 토큰을 생성하고, 이를 보안 제공자 디바이스로 공유할 수 있다. 이후, 보안 제공자 디바이스는 공유받은 그룹 보안 토큰에 기초하여 그룹 토큰 ID를 생성할 수 있다. 이와 같이 그룹 보안 토큰 및 그룹 토큰 ID를 생성하여 관리함으로써, 보안 검색자 디바이스 및 보안 제공자 디바이스의 토큰 스토어의 저장 공간이 절약될 수 있는 효과가 있다.
이하에서, 도 16 내지 도 18을 참조하여 보안 검색자 디바이스의 사용자 계정 정보 획득 방법 및 보안 브로커 간의 계정 연동 방법에 대하여 설명하도록 한다.
도 16은 보안 검색자 디바이스에서의 사용자 계정 정보 획득 방법의 일 예를 나타낸 도이다. 보다 구체적으로, 도 16은 도 16에서 도시된 S16010 내지 S16040 단계의 수행 이전에 보안 제공자 디바이스와 도 16의 보안 검색자 디바이스가 아닌 특정 보안 검색자 디바이스 사이에서 보안 토큰 생성 및 토큰 ID 생성이 완료된 경우에 관한 것이다.
S16010: 사용자는 보안 검색자 디바이스에서 이용 가능한 특정한 어플리케이션/서비스의 사용자 브라우저(User Browser)에 상기 특정한 어플리케이션/서비스와 관련된 자신의 계정 정보를 입력한다. 상기 계정 정보는 상기 특정한 어플리케이션/서비스와 관련된 계정 ID 및 패스워드(Password) 등일 수 있다. 여기서, 특정한 어플리케이션/서비스는 ABP 프로파일을 포함하는 어플리케이션/서비스일 수 있다.
S16020: 특정한 어플리케이션/서비스는 ABP 프로파일을 포함하는 어플리케이션/서비스이므로, 상기 보안 검색자 디바이스의 사용자는 S16010 단계를 통해 ABP 웹 포털(Web Portal)에 로그인(Log-in)을 수행할 수 있다. 이후, 상기 보안 검색자 디바이스는 ABP 기능을 사용하기 위해, 상기 ABP 웹 포털로 상기 보안 검색자 디바이스 자신 및 보안 제공자 디바이스의 등록을 요청한다. 상기 등록 요청은 Navigate to Add Device 절차를 통해 수행될 수 있다. 이후, 상기 보안 검색자 디바이스는 디바이스 인증 토큰을 교환하여 상기 보안 검색자 디바이스에서 사용할 보안 토큰을 획득한다. 보다 구체적으로, 상기 보안 검색자 디바이스로부터 등록 요청을 받으면, 상기 ABP웹 포털은 사용자의 계정을 관리하는 보안 브로커 #1 및 보안 브로커 #2로 토큰을 요청하고, 상기 보안 브로커 #1 및 보안 브로커 #2는 각각 자신이 관리하는 사용자 계정을 상기 ABP 웹 포털로 전달한다. 이후, 상기 ABP 웹 포털은 보안 검색자 디바이스로 상기 보안 브로커 #1 및 보안 브로커 #2로부터 각각 전달받은 보안 토큰을 전달한다.
S16030: 필요한 경우, ABP ABP 기능을 이용하기 위해 보안 검색자 디바이스에서 추가적인 인증 절차/보안 토큰 교환(Security token exchange)이 수행될 수 있다. 상기 추가적인 인증 절차/ 보안 토큰 교환은, 상기 보안 브로커 #1 및 보안 브로커 #2가 각각 사용자의 이메일(E-mail)로 등록을 위한 코드(Register code)를 전송하고, 사용자가 전달 받은 등록을 위한 코드를 입력하는 방식으로 수행될 수 있다.
S16040: S16030단계 이후, 보안 검색자 디바이스 및 보안 제공자 디바이스가 ABP 기기로 등록되고, 보안 검색자 디바이스에 ABP 필터가 설정될 수 있다. ABP 필터가 설정된 보안 검색자 디바이스는 보안 제공자 디바이스가 전송하는 광고 패킷에 포함된 토큰 ID(토큰 정보)를 확인하고, ABP 필터와 관련된 사용자의 계정과 토큰 ID에 기초하여 식별되는 사용자 계정의 일치 여부에 기초하여 ABP를 수행할 수 있게 된다.
아래의 표 4 내지 표 6은 보안 브로커와 보안 검색자 디바이스 간에 교환되는 파라미터들, 보안 브로커들 간에 교환이 필요한 파라미터들을 정의한다.
보다 구체적으로, 표 4는 디바이스 description으로부터의 ABP 계정 정보이며, 표 5는 보안 코튼의 ABP 계정 정보와 관련된 것이다.
디바이스가 콘텐츠가 보호되는 DRM(Digital rights management)을 지원하는지가 확인될 수 있다. 또한, 디바이스 description의 DRM 정보와 콘텐츠의 DRM 정보 사이의 맵핑(mapping) 테이블이 만들어질 수 있다. 여기서 콘텐츠의 DRM 정보는 UPnP에서 CDS 별 콘텐츠의 프로토콜 정보(Protocol Info)일 수 있다. 디바이스/계정 권한 정보에 기반하여 Source URI 접근/연결 권한 관리가 수행될 수 있다. 컨텐츠 확인/접근 권한 관리 방안에 기초하여 BLE를 통한 계정 확인 후 연결/권한 관리가 수행될 수 있다.
Figure PCTKR2021095004-appb-img-000004
Figure PCTKR2021095004-appb-img-000005
Figure PCTKR2021095004-appb-img-000006
도 17은 보안 검색자 디바이스에서의 보안 토큰 획득 및 저장 방법의 일 예를 나타낸 흐름도이다. 도 17은 사용자가 특정 서비스/어플리케이션을 사용하기 위해 ABP 기능을 사용하는 경우에 관한 것이다. 상기 특정 서비스/어플리케이션은 음악 듣기, 화면 공유 등일 수 있다.
사용자가 서비스를 요청하면(S17000), 상기 보안 검색자 디바이스는 ABP 계정이 서버에서 이용 가능한 지 여부를 판단한다(S17010).
ABP 계정이 서버에서 이용 가능하지 않은 것으로 판단된 경우, 토큰이 다운로드 될 수 없다는 에러가 발생한다(S17090).
반면, ABP 계정이 서버에서 이용 가능한 것으로 판단된 경우, 상기 보안 검색자 디바이스는 ABP 계정이 보호되었는지(protected) 여부를 판단한다(S17020).
ABP 계정이 보호되지 않은 것으로 판단된 경우, 토큰이 다운로드 될 수 없다는 에러가 발생한다(S17090).
반면, ABP 계정이 보호된 것으로 판단된 경우, 상기 보안 검색자 디바이스는 디바이스의 DRM 정보를 획득하고(S17030), 콘텐츠 설명의 DRM 정보를 획득한다(S17040). 여기서, 디바이스의 DRM 정보와 콘텐츠 설명의 DRM 정보 사이에 맵핑 테이블이 생성될 수 있다.
이후, 상기 보안 검색자 디바이스는 토큰의 DRM이 지원되는 지 여부를 판단한다(S17050).
토큰의 DRM이 지원되지 않는 것으로 판단된 경우, 토큰이 다운로드 될 수 없다는 에러가 발생한다(S17090).
반면, 토큰의 DRM이 지원되는 것으로 판단된 경우, 상기 보안 검색자 디바이스는 ABP 계정의 토큰 정보를 획득한다(S17060). 상기 토큰 정보는 사용자 계정을 관리하는 하나 이상의 보안 브로커로부터 획득될 수 있으며, 상기 토큰 정보는 앞서 설명한 보안 토큰일 수 있다.
이후, 상기 보안 검색자 디바이스는 사용자의 토큰의 유효성을 검사한다(S17070).
사용자의 토큰이 유효하지 않은 것으로 판단된 경우, 토큰이 다운로드 될 수 없다는 에러가 발생한다(S17090).
반면, 사용자의 토큰이 유효한 것으로 판단된 경우, 상기 보안 검색자 디바이스는 토큰 스토어에 토큰을 저장한다(S17080).
도 18은 보안 검색자 디바이스에서 수행되는 ABP 동작의 일 예를 나타낸 흐름도이다.
상기 보안 검색자 디바이스는 상기 보안 검색자 디바이스가 ABP 계정과 연동되어 있는지를 판단한다(S18010).
상기 보안 검색자 디바이스가 ABP 계정과 연동되어 있지 않은 것으로 판단된 경우, 사용자의 ABP 계정이 존재하는 지 여부를 판단한다(S18022).
사용자의 ABP 계정이 존재하지 않는 것으로 판단된 경우, ABP 계정을 생성한다(S18032).
반면, 사용자의 ABP 계정이 존재하는 것으로 판단된 경우, 상기 보안 검색자 디바이스는 상기 ABP 계정에 기초하여 토큰을 생성하고(S18031), 생성된 토큰을 보안 브로커에 등록한다(S18040). 상기 생성된 토큰은 보안 검색자 디바이스와 보안 제공자 디바이스간에 공유될 수 있다.
상기 보안 검색자 디바이스는 보안 브로커와의 추가 인증 수행 여부를 판단한다(S18050).
상기 보안 브로커와의 추가 인증이 수행되지 않은 경우, 상기 보안 검색자 디바이스는 ABP 계정을 생성한다(S18032). 이후, S18031 단계 및 그 이후의 단계들이 재수행될 수 있다.
반면, 상기 보안 브로커와의 추가 인증이 수행된 경우, ABP 디바이스 확인이 수행되고(S18060), 이를 통하여 상기 보안 검색자 디바이스는 ABP 서비스에 등록되고, ABP 서비스를 이용할 수 있다.
다시 S18010단계로 돌아와서, 상기 보안 검색자 디바이스가 ABP 계정에 연동된 경우, 상기 보안 검색자 디바이스는 ABP 프로파일을 포함하는 ABP 기반의 어플리케이션을 통하여 ABP 서비스를 사용할 수 있다(S18021).
사용자는 ABP 서비스에 등록된 디바이스를 제거할 수 있다(S18090). ABP 서비스에 등록된 디바이스의 제거를 요청하는 경우, 사용자는 디바이스의 제거에 대한 최종 확인을 요청 받는다(S18100).
상기 최종 확인에 대하여 사용자가 디바이스를 제거한다는 응답을 한 경우, 해당 디바이스에 대한 제거 확인이 수행된다(S18110).
반면, 상기 최종 확인에 대하여 사용자가 디바이스를 제거하지 않는다는 응답을 한 경우, S18090 단계가 재수행될 수 있다.
다시 S18021단계로 돌아와서, 상기 보안 검색자 디바이스는 미디어/서비스가 보안 제공자 디바이스에 존재하는 지 여부를 판단한다(S18070).
미디어/서비스가 보안 제공자 디바이스에 존재하지 않은 것으로 판단된 경우, 다른 ABP 디바이스를 선택한다(S18082).
미디어/서비스가 보안 제공자 디바이스에 존재하는 것으로 판단된 경우, 상기 보안 검색자 디바이스는 상기 보안 제공자 디바이스가 제공하는 미디어/서비스를 이용한다(S18081).
추가적으로, 사용자는 클라우드 서비스를 통하여 보안 검색자 디바이스 및 보안 제공자 디바이스를 클라우드(Cloud)에 등록 후, 리스 또는 렌트(Lease or rent) 후 연결/권한을 관리할 수 있다. 아래의 표 7은 보안 검색자 디바이스 및 보안 제공자 디바이스를 클라우드(Cloud)에 등록 후, 리스 또는 렌트(Lease or rent) 후 연결/권한을 관리하는 경우 사용되는 요소(element)들과 관련된 표이다.
Figure PCTKR2021095004-appb-img-000007
보안 제공자 디바이스 및 보안 검색자 디바이스는 서비스에 대한 토큰의 사용이 제한 될 수 있는 기간을 지정해야 할 수 있다. 이 때, 서비스에 대한 토큰의 사용이 제한 될 수 있는 기간은 권한 가용성 “윈도우(Rights availability window)”, "만료 기간(expiration period)" 또는 "서비스 제한 윈도우(service restriction window)" 등으로 호칭될 수 있다.
토큰 / 서비스에 적용되는 제한 유형은 다음과 같을 수 있다.
- 토큰은 취소되거나 교체 될 수 있다.
- 특정 지역 및 기간에 따라 다운로드 기능이 제한 될 수 있다.
- 스트리밍 서비스, 미디어 권한 실행도 마찬가지로 제한 될 수 있다.
상기의 제한 유형은 토큰에 저장되며, 보안 검색자 디바이스/보안 브로커가 언제든지 업데이트 할 수 있다.
보안 만료 및 갱신(Credential Expiration and Refresh) 방법-(방법 2)
본 방법은 보안 검색자 디바이스가 생성한 보안 토큰의 만료 및 보안 토큰의 갱신에 관한 것이다.
이하에서, 도 19 및 도 20을 참조하여 보안 만료 및 갱신(Credential Expiration and Refresh) 방법에 관하여 구체적으로 설명하도록 한다.
도 19는 보안 만료 및 보안 갱신을 위한 방법이 수행되는 일 예를 나타낸 흐름도이다. 보다 구체적으로, 도 19는 사용자 B는 보안 브로커 #1과 관련된 계정을 보유하고 있고, 보안 검색자 디바이스 #1(110-1) 및 보안 검색자 디바이스 #2(110-2)는 보안 브로커 #1과 관련된 사용자 B의 보안 토큰을 저장하고 있으며, 사용자 B가 보안 검색자 디바이스 #2를 사용하여 ABP 기능을 수행하는 경우에 관한 것이다.
S19010: 상기 보안 브로커 #1과 관련된 사용자 B의 계정에 기초하여 생성된 보안 토큰이 만료되기 전, 보안 제공자 디바이스(120)는 상기 보안 토큰에 기초하여 생성된 토큰 ID를 포함하는 광고 메시지를 브로드캐스트 한다(S19010).
S19020: 보안 검색자 디바이스가 보안 토큰을 생성하면, 상기 생성된 보안 토큰은 보안 토큰 만료 시점과 관련된 만료 값(expiration value)가 함께 설정될 수 있다. S19020 단계에서, 상기 보안 브로커 #1과 관련된 사용자 B의 계정에 기초하여 생성된 보안 토큰이 만료 값에 기초하여 만료된다. 상기 보안 토큰 값이 만료되면, 보안 검색자 디바이스(110-1 및 110-2)에 설정된 ABP 필터에서 상기 보안 토큰이 제거된다.
또한, 상기 보안 브로커 #1과 관련된 사용자 B의 계정에 기초하여 생성된 보안 토큰이 만료된 것에 기초하여, 보안 제공자 디바이스(120)는 상기 보안 토큰에 기초하여 생성된 토큰 ID를 제거한다(S19030). 보안 제공자 디바이스(120)는 만료 값이 설정된 보안 토큰에 기초하여 토큰 ID를 생성하므로, 상기 보안 토큰에 설정된 만료 값을 획득함으로써, 토큰 ID의 제거 시점을 판단할 수 있다. 추가적으로, 보안 검색자 디바이스(110-1 및 110-2)가 보안 토큰에 설정된 만료 값을 별도로 보안 제공자 디바이스(120)에게 알려줄 수 있다. 보안 제공자 디바이스(120)는 보안 검색자 디바이스(110-1 및 110-2)로부터 획득한 만료 값에 기초하여 토큰 ID를 제거할 수 있다.
S19030: 사용자 B는 상기 보안 브로커 #1과 관련된 사용자 B의 계정에 기초하여 보안 검색자 디바이스 #2(110-2)에 접근한다.
S19040: 보안 검색자 디바이스 #2(110-2)는 ABP 필터에서 상기 보안 브로커 #1과 관련된 사용자 B의 계정에 기초하여 생성된 보안 토큰을 제거하였고, 보안 제공자 디바이스(120)는 상기 보안 토큰에 기초하여 생성된 토큰 ID를 제거하였으므로, 두 기기간에는 ABP가 수행되지 않는다.
S19050: 만료된 보안 토큰을 갱신하기 위해, (i) 보안 브로커 #1과 보안 검색자 디바이스 #1(110-1) 및 ii) 보안 브로커 #1과 보안 검색자 디바이스 #2(110-2)에서 각각 사용자 B의 보안 갱신 절차가 수행된다.
S19060: 이후, 보안 검색자 디바이스 #2(110-2)는 갱신된 보안 토큰을 보안 제공자 디바이스(120)로 공유하며, 보안 제공자 디바이스(120)은 갱신된 보안 토큰에 기초하여 토큰 ID를 새롭게 생성한다.
S19070: 보안 제공자 디바이스(120)는 갱신된 토큰 ID를 포함하는 광고메시지를 브로드캐스트 한다.
S19080: S19050에서 보안 검색자 디바이스 #1(110-1)과 보안 브로커 #1 사이에서의 보안 갱신을 위한 절차가 실패하거나 수행되지 않은 경우, 보안 검색자 디바이스 #1(110-1)는 갱신된 토큰 ID가 포함된 광고 메시지를 수신함으로써 보안 토큰이 갱신되지 않음을 확인할 수 있다. 위와 같은 동작은 보안 갱신 확인(Credential Refresh Check)절차라고 호칭될 수 있다. 이 때, 보안 브로커 #1과 보안 검색자 디바이스 #1(110-1) 사이에서 보안 갱신 절차가 수행될 수 있다.
도 20은 보안 갱신을 위한 방법이 수행되는 또 다른 일 예를 나타낸 흐름도이다.
보다 구체적으로, 도 20에서, 사용자 A는 보안 브로커 #1 및 보안 브로커 #2와 관련된 계정을 보유하고, 하나의 보안 검색자 디바이스(110)가 복수의 보안 제공자 디바이스(120-1 내지 120-3)와 ABP 기능을 수행한다.
S20010: 보안 검색자 디바이스(110)는 상기 보안 브로커 #1 및 보안 브로커 #2와 관련된 계정과 관련된 보안 토큰을 관리한다.
S20020: 보안 제공자 디바이스 #1(120-1)는 보안 브로커 #1 및 보안 브로커 #2와 관련된 계정과 모두 관련된 토큰 ID를 관리하고 있고, 보안 브로커 #1 및 보안 브로커 #2와 관련된 계정과 모두 관련된 토큰 ID를 포함하는 광고 메시지를 브로드캐스트 한다.
또한, 보안 검색자 디바이스(110)와 보안 제공자 디바이스 #2(120-2) 사이에서 보안 토큰 공유 절차를 수행한 시점에 보안 검색자 디바이스(110)는 보안 브로커 #1과 관련된 계정만을 관리하고 있었기 때문에, 보안 제공자 디바이스 #2(120-2)는 보안 브로커 #1과 관련된 계정과만 관련된 토큰 ID를 관리하고 있다. 이 때, 보안 제공자 디바이스 #2(120-2)는 보안 브로커 #1과 관련된 계정과만 관련된 토큰 ID를 포함하는 광고 메시지를 브로드캐스트 한다.
또한, 보안 검색자 디바이스(110)와 보안 제공자 디바이스 #3(120-3) 사이에서 보안 토큰 공유 절차를 수행한 시점에 보안 검색자 디바이스(110)는 보안 브로커 #2와 관련된 계정만을 관리하고 있었기 때문에, 보안 제공자 디바이스 #3(120-3)은 보안 브로커 #2와 관련된 계정과만 관련된 토큰 ID를 관리하고 있다. 이 때, 보안 제공자 디바이스 #3(120-3)은 보안 브로커 #2와 관련된 계정과만 관련된 토큰 ID를 포함하는 광고 메시지를 브로드캐스트 한다.
보안 검색자 디바이스(110)는 보안 제공자 디바이스 #2 및 #3(120-2 및 120-3)으로부터 수신한 광고 메시지에 기초하여 보안 제공자 디바이스 #2 및 #3에서 사용자의 계정 정보(토큰 ID)의 업데이트 여부를 판단한다. 도 20에서, 보안 제공자 디바이스 #2(120-2)는 보안 브로커 #1과 관련된 계정과만 관련된 토큰 ID를 관리하고 있고, 보안 제공자 디바이스 #3(120-3)은 보안 브로커 #2와 관련된 계정과만 관련된 토큰 ID를 관리하고 있으므로, 보안 검색자 디바이스(110)는 보안 제공자 디바이스 #2(120-2) 및 보안 제공자 디바이스 #3(120-3)의 계정 정보가 업데이트 되지 않은 것으로 판단한다. 보안 검색자 디바이스(110)는 보안 제공자 디바이스 #2(120-2) 및 보안 제공자 디바이스 #3(120-3)의 계정 정보가 업데이트 되지 않음을 사용자에게 통지할 수 있다.
S200230: 보안 검색자 디바이스(110)는 보안 제공자 디바이스 #2(120-2) 및 보안 제공자 디바이스 #3(120-3)의 계정 정보가 업데이트 되지 않음을 통지 받은 사용자로부터 보안 제공자 디바이스 #2(120-2) 및 보안 제공자 디바이스 #3(120-3)의 계정 정보의 업데이트 여부에 대한 사용자 입력을 획득한다. 이후, 보안 검색자 디바이스(110)는 보안 제공자 디바이스 #2(120-2)에게 보안 브로커 #2와 관련된 계정 정보를 전달하고, 보안 제공자 디바이스 #3(120-3)에게 보안 브로커 #1과 관련된 계정 정보를 전달한다.
보안 검색자 디바이스(110)로부터 추가적인 계정 정보(보안 토큰)를 획득한 보안 제공자 디바이스들(120-2 및 120-3)은 상기 계정 정보에 기초하여 토큰 ID를 새롭게 생성/갱신할 수 있다. 위에서 설명한 절차는 계정 참여 절차(Account Join Procedure)로 호칭될 수 있다.
S12040: S12030단계에서 토큰 ID를 새롭게 생성/갱신 보안 제공자 디바이스들(120-2 및 120-3)은 보안 브로커 #1 및 보안 브로커 #2와 관련된 계정과 모두 관련된 토큰 ID를 포함하는 광고 메시지를 브로드캐스트 한다.
추가적으로, 다수의 기기가 동일한 보안 토큰을 공유하여 네트워크를 구성하는 경우에서, 네트워크의 보안을 강화하기 위한 방법을 설명하도록 한다.
도 21은 보안이 강화된 네트워크를 구성하는 방식의 일 예를 나타낸 도이다.
도 21(a)에서, 다수의 기기가 동일한 보안 보안 토큰/키를 공유하여 네트워크를 구성하고 있다. 보다 구체적으로, 도 21에 도시된 네트워크(G1)는 BLE 메쉬 네트워크이며, S1 내지 S9 기기로 구성된다. 네트워크(G1)는 보안을 위해 주기적으로 보안 토큰/키를 갱신(Refresh) 하며 이는 G1 관리자(브로커)에 의해 관리된다.
도 21(b)에 도시된 것과 같이, 경우에 따라, 네트워크(G1)의 관리자는 일부 기기가(S5, S8, S9) 네트워크(G1)로부터 분리되어 별도의 네트워크(G2)가 구성되는 것을 제한해야 할 수 있다.
별도의 네트워크(G2)가 구성되는 것을 제한하기 위해 네트워크(G1)의 관리자는 강화된 보안 갱신 방식(Enhanced Credential Refresh Scheme: ECRS)을 네트워크에 적용할 수 있다. 보다 구체적으로, ECRS이 적용된 네트워크에서는 단순히 라우팅(Routing)이 최단 홉(Hop), 최단 지연과 같은 성능에 따라 결정되지 않고, 보안을 강화하기 위한 루트(Route)로 설정된다. 즉, 보안을 강화하기 위해 설정된 루트를 통해서만 네트워크를 구성하는 디바이스간의 메시지 전달이 가능하다. 보다 구체적으로, 도 21(a)에서 ECRS가 네트워크(G1)에 적용되는 경우, S9와 S5 사이의 거리는 S9가 S5로 직접 메시지를 전송할 수 있는 거리임에도 불구하고, S9는 S4 통해서 메시지를 S5로 전송하여야 한다. 여기서, S5 또한 S4를 통해서 S9가 전송한 메시지를 수신했다는 인증을 완료한 경우에만, S9가 전송한 메시지를 유효한 패킷(packet)으로 해석한다. S4와 같은 노드의 디바이스를 보안 릴레이 노드(Security Relay Node)라고 호칭할 수 있다. 네트워크(G1)에 ECRS가 적용된 경우, 네트워크(G1)을 구성하는 모든 노드들은 특정 보안 릴레이 노드를 거쳐서만 데이터 패킷(packet)을 다른 노드로 전송할 수 있다. 보안 릴레이 노드는 주기적으로 변경될 수 있다.
ECRS가 적용된 네트워크(G1)에서, ECRS이 네트워크(G1)에 적용되기 전 사용하던 보안 토큰/키만으로 암호화, 인증된 메시지는 보안 릴레이 노드를 거치지 않고서는 유효하지 않다. 도 21(b)와 같이, ECRS가 적용된 IoT 로컬 네트워크(Local Network)의 경우 S5, S8, S9로 구성되는 별도의 네트워크(G2)를 구성할 경우, 해당 네트워크(G2)는 동작이 불가능하다.
이하에서, 본 명세서에서 제안하는 방법들의 구체적인 활용 예를 도 22 내지 도 27를 참조하여 설명하도록 한다.
도 22 및 도 23은 본 명세서에서 제안하는 방법이 항공기의 기내 시스템에 적용되는 일 예를 나타낸 도이다.
도 22 (a)를 참조하면, 항공기 이용 고객이 항공기에 탑승하여 IFE(In-Flight Entertainment) 시스템을 이용하는 경우, IFE 시스템에 본인의 디바이스(Bring Your Own Device':BYOD)(2201)를 연결하기 위한 디바이스 검색 시, 다른 고객들의 Bluetooth / Wi-Fi 디바이스(2202)가 IFE 시스템의 검색 결과 리스트에 나타나게 된다. 이는 항공기 이용 고객의 IFE 시스템으로의 Bluetooth / Wi-Fi 를 이용한 본인 디바이스 연결에 어려움을 야기시킨다.
위와 같은 문제점을 해결하기 위해, 접근 감지(Proximity detection) 및 본 명세서에서 제안하는 ABP를 사용함으로써, IFE에 고객이 자신의 디바이스를 근접 시키면 IFE 시스템과 고객의 디바이스가 자동으로 연결을 형성하도록 할 수 있다. 즉, 항공사 어플리케이션 계정에 기초하여 ABP가 수행될 수 있다.
도 22(b)를 참조하면, 탑승 전 항공사 어플리케이션을 통한 좌석 예약 시, 탑승객의 디바이스 등록 절차를 추가하고, 기기 정보를 항공사 어플리케이션(보안 브로커)에 등록하는 절차가 추가될 수 있다(S22010 및 S22020).
이후, 탑승객은 항공기 탑승 후, IFE에 자신의 디바이스를 접근시키는 경우, IFE는 탑승객 디바이스의 접근을 인식하고, ABP를 통해 두 디바이스간에 연결이 자동으로 형성될 수 있다(S22030).
도 23을 참조하면, 탑승객의 디바이스 1(이어폰) 및 디바이스 2(스마트폰)이 IFE 시스템에 근접하면 IFE 시스템과 각각 자동으로 연결이 형성되고, 형성된 연결에 기초하여 디바이스 1(이어폰) 및 디바이스 2(스마트폰)는 각각 IFE 시스템에서 제공되는 서비스를 이용하게 된다.
도 24는 본 명세서에서 제안하는 방법이 항공기의 기내 시스템에 적용되는 또 다른 일 예를 나타낸 도이다.
항공기의 기내 시스템에 본 명세서에서 제안하는 방법이 적용됨으로써, 탑승객은 ABP 서비스를 이용하여 IFE 시스템에 본인의 디바이스를 간편하게 연결할 수 있다. 탑승 전 항공사 어플리케이션을 통해서 탑승객 디바이스 정보를 사전 연동하였으므로(S24010), 탑승객이 탑승한 후에 IFE 시스템에 탑승객의 디바이스들이 근접하는 경우(S24020-S24030), 사전 등록된 정보에 기초하여 자동 연결이 수행(S24040)된다.
도 25는 본 명세서에서 제안하는 방법이 항공기의 기내 시스템에 적용되는 경우의 소프트웨어 구성도의 일 예를 나타낸 도이다.
도 25를 참조하면, ABP Manager는 본 명세서에서 제안하는 계정 기반 자동 연결 기능을 관리한다. 또한, Bluetooth Auto Connect는 근접 기기를 감지하여 각 제조사별 구현 내용에 맞게 자동 연결을 시도한다. 이 때, 상기 ABP Manager를 통해 계정 기반 자동 연결 기능과 연동될 수 있다.
도 25의 IFE AC (Auto Connect) api는 어플리케이션 계층(Application layer)에 계정 기반 자동연결을 위한 API를 제공한다. 예를 들어, 상기 자동 연결을 위한 API는 Auto Connect Enable, Auto Connect Start, Auto Connect Account Discovery 등일 수 있다.
도 26은 본 명세서에서 제안하는 디바이스 인증(Authentication) 방법이 수행되는 일 예를 나타낸 흐름도이고, 도 27은 디바이스 인증 방법의 수행 과정에서 전송되는 메시지 포맷의 일 예를 나타낸다.
S26010: 보안 제공자 디바이스는 사전에 토큰 공유 절차를 통해 획득한 토큰 관련 데이터를 광고 메시지에 포함시켜 주변에 전송한다. 상기 광고 메시지의 포맷은 도 27(a)와 같을 수 있다. 즉, 광고 메시지에 포함된 토큰 관련 데이터는 토큰 ID, 브로커 ID 또는 이름, 계정 ID 또는 이름, 서비스 정보 및 전송 전력 등일 수 있다.
S26020: 보안 검색자 디바이스는 근접 확인(Proximity Check)을 통해 근접한 보안 제공자 디바이스를 발견한다. 보안 검색자 디바이스는 보안 검색자 디바이스는 발견된 보안 제공자 디바이스가 전송한 광고 메시지에 기초하여 보안 제공자 디바이스가 ABP 서비스를 지원하는지 확인한다. 이후, 보안 검색자 디바이스는 확인 결과에 기초하여 도 27(b), (c), (d)의 AD Data의 Token Frame에 해당하는 사용자 정보를 확인하고, ABP 수행 여부에 대한 확인을 사용자에게 통지한다.
S26030: 보안 검색자 디바이스가 사용자로부터 ABP 수행에 대한 확인(confirm)을 입력 받은 경우, 보안 검색자 디바이스는 계정 기반 자동 연결 요청을 수행한다.
도 28은 본 명세서에서 제안하는 무선 통신 시스템에서 제 3 디바이스가 디바이스 인증(Authentication)을 수행하는 방법을 수행하기 위한 제 3 디바이스에서 구현되는 동작의 일례를 나타낸 흐름도이다.
보다 구체적으로, 상기 제 3 디바이스는 특정 사용자와 관련된 적어도 하나의 사용자 계정(user account)에 기초하여 생성되는 자격 증명 토큰(credential token)을 제공받기 위해 제 1 디바이스와 연결을 형성한다(S2810).
다음, 상기 제 3 디바이스는 상기 형성된 연결에 기초하여, 상기 자격 증명 토큰을 포함하는 제 1 메시지를 상기 제 1 디바이스로부터 수신한다(S2820).
이후, 상기 제 3 디바이스는 상기 자격 증명 토큰에 기초하여 생성된 토큰 ID(identifier)를 포함하는 광고 메시지를 브로드캐스트(broadcast) 한다(S2830).
다음, 상기 제 3 디바이스는 상기 토큰 ID에 기초하여, 제 2 디바이스에 대한 상기 디바이스 인증을 통해 상기 제 2 디바이스와 연결을 형성한다(S2840). 여기서, 상기 디바이스 인증의 성공 여부는 (i) 상기 토큰 ID에 기초하여 식별되는 상기 특정 사용자와 관련된 적어도 하나의 사용자 계정이 (ii) 상기 제 2 디바이스에 설정된 계정 기반 페어링 필터(account based pairing filter)와 관련된 하나 이상의 사용자 계정 중 적어도 하나와 일치하는지 여부에 기초하여 결정된다.
또한 상기 제 3 디바이스는, 무선 신호를 송신하기 위한 전송기(transmitter); 무선 신호를 수신하기 위한 수신기(receiver); 및
상기 전송기 및 수신기와 기능적으로 연결되는 프로세서를 포함하며, 상기 프로세서는, 도 28에서 설명된 동작을 수행하도록 구성될 수 있다.
보다 구체적으로, 상기 프로세서는 특정 사용자와 관련된 적어도 하나의 사용자 계정(user account)에 기초하여 생성되는 자격 증명 토큰(credential token)을 제공받기 위해 제 1 디바이스와 연결을 형성하도록 상기 전송기 및 상기 수신기를 제어한다.
또한, 상기 프로세서는 상기 형성된 연결에 기초하여, 상기 자격 증명 토큰을 포함하는 제 1 메시지를 상기 제 1 디바이스로부터 수신하도록 상기 수신기를 제어한다.
또한, 상기 프로세서는 상기 자격 증명 토큰에 기초하여 생성된 토큰 ID(identifier)를 포함하는 광고 메시지를 브로드캐스트(broadcast) 하도록 상기 전송기를 제어한다.
이후, 상기 프로세서는 상기 토큰 ID에 기초하여, 제 2 디바이스에 대한 상기 디바이스 인증을 통해 상기 제 2 디바이스와 연결을 형성하도록 상기 전송기 및 상기 수신기를 제어한다. 여기서, 상기 디바이스 인증의 성공 여부는 (i) 상기 토큰 ID에 기초하여 식별되는 상기 특정 사용자와 관련된 적어도 하나의 사용자 계정이 (ii) 상기 제 2 디바이스에 설정된 계정 기반 페어링 필터(account based pairing filter)와 관련된 하나 이상의 사용자 계정 중 적어도 하나와 일치하는지 여부에 기초하여 결정된다.
본 발명은 본 발명의 필수적 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있음은 통상의 기술자에게 자명하다. 따라서, 상술한 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니 되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.
이상에서 설명된 실시 예들은 본 발명의 구성요소들과 특징들이 소정 형태로 결합된 것들이다. 각 구성요소 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려되어야 한다. 각 구성요소 또는 특징은 다른 구성요소나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한, 일부 구성요소들 및/또는 특징들을 결합하여 본 발명의 실시 예를 구성하는 것도 가능하다. 본 발명의 실시 예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시예의 일부 구성이나 특징은 다른 실시 예에 포함될 수 있고, 또는 다른 실시예의 대응하는 구성 또는 특징과 교체될 수 있다. 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시 예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함시킬 수 있음은 자명하다.
본 발명에 따른 실시 예는 다양한 수단, 예를 들어, 하드웨어, 펌웨어(firmware), 소프트웨어 또는 그것들의 결합 등에 의해 구현될 수 있다. 하드웨어에 의한 구현의 경우, 본 발명의 일 실시 예는 하나 또는 그 이상의 ASICs(application specific integrated circuits), DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays), 프로세서, 콘트롤러, 마이크로 콘트롤러, 마이크로 프로세서 등에 의해 구현될 수 있다.
펌웨어나 소프트웨어에 의한 구현의 경우, 본 발명의 일 실시 예는 이상에서 설명된 기능 또는 동작들을 수행하는 모듈, 절차, 함수 등의 형태로 구현될 수 있다. 소프트웨어 코드는 메모리에 저장되어 프로세서에 의해 구동될 수 있다. 상기 메모리는 상기 프로세서 내부 또는 외부에 위치하여, 이미 공지된 다양한 수단에 의해 상기 프로세서와 데이터를 주고 받을 수 있다.
본 발명은 본 발명의 필수적 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있음은 통상의 기술자에게 자명하다. 따라서, 상술한 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니 되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.
이상, 전술한 본 발명의 바람직한 실시예는, 예시의 목적을 위해 개시된 것으로, 당업자라면 이하 첨부된 특허청구범위에 개시된 본 발명의 기술적 사상과 그 기술적 범위 내에서, 다양한 다른 실시예들을 개량, 변경, 대체 또는 부가 등이 가능할 것이다.

Claims (16)

  1. 근거리 무선 통신 시스템에서 제 3 디바이스가 디바이스 인증(Authentication)을 수행하는 방법은,
    특정 사용자와 관련된 적어도 하나의 사용자 계정(user account)에 기초하여 생성되는 자격 증명 토큰(credential token)을 제공받기 위해 제 1 디바이스와 연결을 형성하는 단계;
    상기 형성된 연결에 기초하여, 상기 자격 증명 토큰을 포함하는 제 1 메시지를 상기 제 1 디바이스로부터 수신하는 단계;
    상기 자격 증명 토큰에 기초하여 생성된 토큰 ID(identifier)를 포함하는 광고 메시지를 브로드캐스트(broadcast) 하는 단계; 및
    상기 토큰 ID에 기초하여, 제 2 디바이스에 대한 상기 디바이스 인증을 통해 상기 제 2 디바이스와 연결을 형성하는 단계를 포함하되,
    상기 디바이스 인증의 성공 여부는 (i) 상기 토큰 ID에 기초하여 식별되는 상기 특정 사용자와 관련된 적어도 하나의 사용자 계정이 (ii) 상기 제 2 디바이스에 설정된 계정 기반 페어링 필터(account based pairing filter)와 관련된 하나 이상의 사용자 계정 중 적어도 하나와 일치하는지 여부에 기초하여 결정되는 것을 특징으로 하는 방법.
  2. 제 1 항에 있어서,
    (i) 상기 토큰 ID에 기초하여 식별되는 상기 특정 사용자와 관련된 적어도 하나의 사용자 계정이 (ii) 상기 제 2 디바이스에 설정된 계정 기반 페어링 필터와 관련된 하나 이상의 사용자 계정 중 적어도 하나가 일치하는 것에 기초하여, 상기 디바이스 인증이 성공하는 것을 특징으로 하는 방법.
  3. 제 1 항에 있어서,
    (i) 상기 토큰 ID에 기초하여 식별되는 상기 특정 사용자와 관련된 적어도 하나의 사용자 계정이 (ii) 상기 제 2 디바이스에 설정된 계정 기반 페어링 필터와 관련된 하나 이상의 사용자 계정 모두와 다른 것에 기초하여, 상기 디바이스 인증이 실패하는 것을 특징으로 하는 방법.
  4. 제 1 항에 있어서,
    상기 자격 증명 토큰은 상기 특정 사용자와 관련된 적어도 하나의 사용자 계정을 통합하여 생성된 단일 자격 증명 토큰이고,
    상기 토큰 ID는 상기 단일 자격 증명 토큰에 기초하여 생성된 통합 토큰 ID인 것을 특징으로 하는 방법.
  5. 제 1 항에 있어서,
    적어도 하나 이상의 토큰 ID를 저장하여 관리하기 위한 토큰 스토어(token store)에 상기 토큰 ID를 저장하는 단계를 더 포함하되,
    상기 자격 증명 토큰은 상기 자격 증명 토큰이 만료(expiration)되는 시점과 관련된 만료 시점 값이 설정되는 것을 특징으로 하는 방법.
  6. 제 5 항에 있어서,
    상기 특정 사용자 외에 상기 제 1 디바이스의 또 다른 사용자가 존재하는 것에 기초하여:
    상기 또 다른 사용자와 관련된 적어도 하나의 사용자 계정에 기초하여 생성되는 또 다른 자격 증명 토큰을 제공받기 위해 상기 제 1 디바이스와 연결을 형성하는 단계;
    상기 형성된 연결에 기초하여, 상기 또 다른 자격 증명 토큰을 포함하는 제 2 메시지를 상기 제 1 디바이스로부터 수신하는 단계; 및
    상기 또 다른 자격 증명 토큰에 기초하여 또 다른 토큰 ID를 생성하는 단계를 더 포함하되,
    상기 또 다른 토큰 ID는 상기 토큰 스토어에 저장되는 것을 특징으로 하는 방법.
  7. 제 6 항에 있어서,
    사용자 입력에 기초하여 상기 광고 메시지에 포함되어 전송되는 토큰 ID를 결정하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  8. 제 6 항에 있어서,
    상기 토큰 ID 및 상기 또 다른 토큰 ID에 기초하여 상기 토큰 ID 및 상기 또 다른 토큰 ID가 그룹핑(grouping)된 그룹 토큰 ID를 생성하는 단계를 더 포함하되,
    상기 광고 메시지는 상기 그룹 토큰 ID를 포함하는 것을 특징으로 하는 방법.
  9. 제 5 항에 있어서,
    상기 자격 증명 토큰에 설정된 상기 만료 시점 값에 기초하여 상기 토큰 ID를 상기 토큰 스토어로부터 제거하는 단계를 더 포함하되,
    상기 토큰 ID가 제거된 이후 전송되는 광고 메시지는 상기 토큰 ID를 포함하지 않는(exclude) 것을 특징으로 하는 방법.
  10. 제 9 항에 있어서,
    상기 토큰 ID가 제거된 것에 기초하여, 상기 토큰 ID에 기초한 상기 디바이스 인증은 수행되지 않는 것을 특징으로 하는 방법.
  11. 제 1 항에 있어서,
    상기 토큰 ID를 생성한 시점 이후 상기 특정 사용자가 상기 특정 사용자와 관련된 적어도 하나의 사용자 계정 외에 또 다른 사용자 계정을 사용하게 된 것에 기초하여:
    상기 제 1 디바이스로부터 상기 또 다른 사용자 계정에 대한 정보를 포함하는 제 2 메시지를 수신하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  12. 제 11 항에 있어서,
    상기 또 다른 사용자 계정에 대한 정보에 기초하여 상기 토큰 ID를 업데이트하는 단계를 더 포함하되,
    업데이트된 토큰 ID는 상기 특정 사용자와 관련된 적어도 하나의 사용자 계정 및 상기 또 다른 사용자 계정과 관련되는 것을 특징으로 하는 방법.
  13. 제 12 항에 있어서,
    상기 토큰 ID가 업데이트된 이후에 전송되는 광고 메시지는 상기 업데이트된 토큰 ID를 포함하여 전송되는 것을 특징으로 하는 방법.
  14. 제 1 항에 있어서,
    상기 특정 사용자와 관련된 적어도 하나의 사용자 계정은 각각 서로 다른 어플리케이션(application)과 관련된 사용자 계정인 것을 특징으로 하는 방법.
  15. 제 1 항에 있어서,
    상기 제 3 디바이스는 복수의 디바이스들로 구성되는 메쉬 네트워크(mesh network)에 포함되어 상기 메쉬 네트워크의 일부를 구성하고,
    상기 복수의 디바이스들 간에 교환 되는 모든 메시지들은 상기 제 3 디바이스를 거쳐서만 다른 디바이스로 전달되는 것을 특징으로 하는 방법.
  16. 근거리 무선 통신 시스템에서 디바이스 인증(Authentication)을 수행하는 제 3 디바이스는,
    무선 신호를 송신하기 위한 전송기(transmitter);
    무선 신호를 수신하기 위한 수신기(receiver); 및
    상기 전송기 및 수신기와 기능적으로 연결되는 프로세서를 포함하고,
    상기 프로세서는,
    특정 사용자와 관련된 적어도 하나의 사용자 계정(user account)에 기초하여 생성되는 자격 증명 토큰(credential token)을 제공받기 위해 제 1 디바이스와 연결을 형성하도록 상기 전송기 및 상기 수신기를 제어하고,
    상기 형성된 연결에 기초하여, 상기 자격 증명 토큰을 포함하는 제 1 메시지를 상기 제 1 디바이스로부터 수신하도록 상기 수신기를 제어하고,
    상기 자격 증명 토큰에 기초하여 생성된 토큰 ID(identifier)를 포함하는 광고 메시지를 브로드캐스트(broadcast) 하도록 상기 전송기를 제어하고,
    상기 토큰 ID에 기초하여, 제 2 디바이스에 대한 상기 디바이스 인증을 통해 상기 제 2 디바이스와 연결을 형성하도록 상기 전송기 및 상기 수신기를 제어하되,
    상기 디바이스 인증의 성공 여부는 (i) 상기 토큰 ID에 기초하여 식별되는 상기 특정 사용자와 관련된 적어도 하나의 사용자 계정이 (ii) 상기 제 2 디바이스에 설정된 계정 기반 페어링 필터(account based pairing filter)와 관련된 하나 이상의 사용자 계정 중 적어도 하나와 일치하는지 여부에 기초하여 결정되는 것을 특징으로 하는 제 3 디바이스.
PCT/KR2021/095004 2020-03-10 2021-01-20 무선 통신 시스템에서 근거리 무선 통신을 이용한 사용자 계정 관리 방법 및 이에 대한 장치 WO2021182938A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/909,645 US20230109583A1 (en) 2020-03-10 2021-01-20 Method for managing user account using near-field communication in wireless communication system, and apparatus for same

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2020-0029836 2020-03-10
KR20200029836 2020-03-10

Publications (1)

Publication Number Publication Date
WO2021182938A1 true WO2021182938A1 (ko) 2021-09-16

Family

ID=77671007

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2021/095004 WO2021182938A1 (ko) 2020-03-10 2021-01-20 무선 통신 시스템에서 근거리 무선 통신을 이용한 사용자 계정 관리 방법 및 이에 대한 장치

Country Status (2)

Country Link
US (1) US20230109583A1 (ko)
WO (1) WO2021182938A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016134022A1 (en) * 2015-02-17 2016-08-25 Sensormatic Electronics, LLC Method and system for credential management
US20160379220A1 (en) * 2015-06-23 2016-12-29 NXT-ID, Inc. Multi-Instance Shared Authentication (MISA) Method and System Prior to Data Access
KR101713013B1 (ko) * 2014-04-15 2017-03-07 구글 인코포레이티드 컴퓨팅 디바이스의 자동-사용자 등록 및 로킹해제
US20170070500A1 (en) * 2015-09-08 2017-03-09 Plaid Technologies, Inc. Secure permissioning of access to user accounts, including secure deauthorization of access to user accounts
US20180189780A1 (en) * 2015-04-24 2018-07-05 Capital One Services, Llc Token identity devices

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101713013B1 (ko) * 2014-04-15 2017-03-07 구글 인코포레이티드 컴퓨팅 디바이스의 자동-사용자 등록 및 로킹해제
WO2016134022A1 (en) * 2015-02-17 2016-08-25 Sensormatic Electronics, LLC Method and system for credential management
US20180189780A1 (en) * 2015-04-24 2018-07-05 Capital One Services, Llc Token identity devices
US20160379220A1 (en) * 2015-06-23 2016-12-29 NXT-ID, Inc. Multi-Instance Shared Authentication (MISA) Method and System Prior to Data Access
US20170070500A1 (en) * 2015-09-08 2017-03-09 Plaid Technologies, Inc. Secure permissioning of access to user accounts, including secure deauthorization of access to user accounts

Also Published As

Publication number Publication date
US20230109583A1 (en) 2023-04-06

Similar Documents

Publication Publication Date Title
WO2018074892A1 (ko) 블루투스 기술을 이용하여 데이터를 송수신하기 위한 방법 및 장치
WO2018038459A1 (ko) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2018048268A1 (ko) 블루투스 기술을 이용하여 디바이스를 연결하기 위한 방법 및 장치
WO2017043869A1 (ko) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2018169380A1 (ko) 블루투스 기술을 이용하여 오디오 신호를 처리하기 위한 방법 및 장치
WO2016039598A1 (ko) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2018222024A1 (ko) 블루투스 le 기술을 이용하여 디바이스를 연결하기 위한 방법 및 장치
WO2016167541A1 (ko) 블루투스 저전력 기술을 이용하여 디바이스를 연결하기 위한 방법 및 장치
WO2015194854A1 (ko) 블루투스 le(low energy) 기술을 이용하여 디바이스 간 커넥션을 형성하기 위한 방법 및 장치
WO2016122186A1 (ko) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2016182404A1 (ko) 블루투스 저전력 에너지 기술을 이용하여 대체 통신 수단을 연결하기 위한 방법 및 장치
WO2018135926A1 (ko) 블루투스 통신 방법 및 장치
WO2016017908A1 (ko) 블루투스 통신을 지원하는 무선 통신 시스템에서 전자기기를 제어하기 위한 방법 및 장치
WO2016017909A1 (ko) 블루투스 통신을 지원하는 무선 통신 시스템에서 전자기기를 제어하기 위한 방법 및 장치
WO2016017907A1 (ko) 블루투스 통신을 지원하는 무선 통신 시스템에서 전자기기를 제어하기 위한 방법 및 장치
WO2018021877A1 (ko) 디바이스의 연결을 형성하기 위한 방법 및 장치
WO2016036139A2 (ko) 블루투스 le(low energy) 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2016175638A1 (ko) 블루투스 메쉬 네트워크에서 디바이스의 주소를 할당하기 위한 방법 및 장치
WO2018097687A1 (ko) 블루투스를 이용한 메쉬 네트워크에서 데이터를 송수신하기 위한 방법 및 장치
WO2016159678A1 (ko) 블루투스 저 전력 에너지 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2015163680A1 (ko) 무선 통신 시스템에서 블루투스 저전력 에너지 기술을 이용하여 데이터를 송수신하기 위한 방법 및 장치
WO2016108646A1 (ko) 블루투스 le 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2016178542A1 (ko) 블루투스에서 데이터를 송수신하기 위한 방법 및 장치
WO2016036206A2 (ko) 블루투스 le(low energy) 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2018066925A1 (ko) 블루투스 기술을 이용하여 데이터를 송수신하기 위한 방법 및 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21767918

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21767918

Country of ref document: EP

Kind code of ref document: A1