[go: up one dir, main page]

WO2018004303A1 - 블루투스 기술을 사용하는 장치의 인증 방법 및 장치 - Google Patents

블루투스 기술을 사용하는 장치의 인증 방법 및 장치 Download PDF

Info

Publication number
WO2018004303A1
WO2018004303A1 PCT/KR2017/006967 KR2017006967W WO2018004303A1 WO 2018004303 A1 WO2018004303 A1 WO 2018004303A1 KR 2017006967 W KR2017006967 W KR 2017006967W WO 2018004303 A1 WO2018004303 A1 WO 2018004303A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
server
user
client
procedure
Prior art date
Application number
PCT/KR2017/006967
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 US16/314,378 priority Critical patent/US11012227B2/en
Publication of WO2018004303A1 publication Critical patent/WO2018004303A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0631—Substitution permutation network [SPN], i.e. cipher composed of a number of stages or rounds each involving linear and nonlinear transformations, e.g. AES algorithms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G06F21/445—Program or device authentication by mutual authentication, e.g. between devices or programs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50—Secure pairing of devices
    • 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
    • H04W68/00—User notification, e.g. alerting and paging, for incoming communication, change of service or the like
    • H04W68/005—Transmission of information for alerting of incoming communication
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor
    • 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 present invention relates to Bluetooth, which is a short-range technology in a wireless communication system, and more particularly, to a method and an apparatus for a device to perform an authentication procedure using Bluetooth low energy technology.
  • Bluetooth is a short-range wireless technology standard that can transmit and receive data by wirelessly connecting various devices in a short distance.
  • a user When performing wireless communication between two devices using Bluetooth communication, a user performs a procedure of searching for a Bluetooth device and requesting a connection. do.
  • the device may mean an apparatus and an apparatus.
  • the user may search for the Bluetooth device based on the Bluetooth communication method to use using the Bluetooth device and then perform the connection.
  • the Bluetooth communication method includes a basic rate / enhanced data rate (BR / EDR) method and a low energy (LE) method, which is a low power method.
  • the BR / EDR scheme may be referred to as Bluetooth Classic.
  • the Bluetooth classic includes Bluetooth technology that has been adopted since Bluetooth 1.0 using Basic Rate and Bluetooth technology that has used Enhanced Data Rate supported since Bluetooth 2.0.
  • Bluetooth Low Energy (hereinafter referred to as Bluetooth LE) technology has been applied since Bluetooth 4.0, and can consume hundreds of kilobytes (KB) of information stably with low power consumption.
  • the Bluetooth low energy energy technology uses an attribute protocol to exchange information between devices. This Bluetooth LE method can reduce energy overhead by reducing the header overhead and simplifying the operation.
  • Some Bluetooth devices do not have a display or a user interface.
  • the complexity of connection / management / control / disconnection between various kinds of Bluetooth devices and similarly applied Bluetooth devices is increasing.
  • Bluetooth can achieve a relatively high speed at a relatively low power, low cost, but the transmission distance is generally limited to a maximum of 100m, it is suitable for use in a limited space.
  • Another object of the present invention is to provide a method and apparatus for authenticating a device using information of a user for a Bluetooth connection.
  • Another object of the present invention is to provide a method and apparatus for authenticating a user based on identification information of the user for a Bluetooth connection.
  • the present invention provides a method for performing authentication of a device by using a Bluetooth technology for solving the above problems.
  • a method for the first device to perform authentication using Bluetooth Low Energy (LE) forming a Bluetooth LE connection with the second device; Obtaining identification information for identifying a user; Performing a user authentication procedure of authenticating the user based on the identification information; Transmitting a first notification message including an identifier corresponding to the identification information to the second device; Receiving a write request message including a first public key from the second device; Obtaining a first value for authentication of the second device using a first algorithm having the first public key as an input value; Sending a second notification message comprising a second public key to the second device; And performing a device authentication procedure for authenticating the second device using a specific authentication method, wherein the specific authentication method is determined according to the input / output capability of the first device.
  • Bluetooth Low Energy LE
  • the write request message includes input / output capability information of the second device
  • the second notification message includes input / output capability information of the first device
  • performing the device authentication process comprising: outputting specific information corresponding to the first value using the specific authentication method; And obtaining input information for authenticating the second device based on the output of the specific information.
  • An authentication performing method comprising: performing a device authentication procedure, obtaining a second value through a second algorithm based on the input information; And completing authentication of the second device based on the first value and the second value.
  • the step of completing the device authentication in the step of completing the device authentication, whether or not the device authentication is successful according to whether the first value and the second value match.
  • the device authentication procedure uses one of a PIN, a password, a pattern, a vibration, a sentence, and an LED.
  • the identification information is one of a PIN, a gesture, a pattern, a password, and biometric information of the user.
  • the method further comprises: allocating a temporary identifier when the user is a new user of the first device, and storing the temporary identifier as the identifier of the user. .
  • the method further comprises the step of receiving an authentication method determination message including the user authentication procedure or the method of performing the device authentication procedure from the second device, the performing method Specified by the second device.
  • a method for the first device to perform authentication using Bluetooth Low Energy (LE) forming a Bluetooth LE connection with the second device; Sending a write request message requesting the start of an authentication procedure to the second device; Receiving a notification message including an identifier corresponding to identification information of a user from the second device; Transmitting a write request message including a first public key to the second device; Receiving a notification message including a second public key from the second device; Obtaining a first value for authentication of the second device using a first algorithm having the second public key as an input value; Performing a device authentication procedure for authenticating the second device using a specific authentication scheme; And transmitting a write request message indicating a result of the device authentication procedure to the second device, wherein the specific authentication method is determined according to the input / output capability of the first device.
  • L Bluetooth Low Energy
  • a first device for performing authentication using Bluetooth low energy (LE) may form a Bluetooth LE connection with a second device and identify a user. Acquires identification information, performs a user authentication procedure of authenticating the user based on the identification information, and transmits a first notification message including an identifier corresponding to the identification information to the second device, Receive a write request message that includes a first public key from a device, obtain a first value for authentication of the second device using a first algorithm having the first public key as an input value, and Send a second notification message including a second public key to the second device, and authenticate the second device using a specific authentication scheme; The device authentication procedure is performed, and the specific authentication method is determined according to the input / output capability of the first device.
  • the specific authentication method is determined according to the input / output capability of the first device.
  • FIG. 1 is a schematic diagram illustrating an example of a wireless communication system using the Bluetooth low power energy technology proposed in the present specification.
  • FIG. 2 shows an example of an internal block diagram of a device that can implement the methods proposed herein.
  • FIG. 3 shows an example of a Bluetooth low power energy topology.
  • FIG. 4 is a diagram illustrating an example of a Bluetooth communication architecture to which the methods proposed herein may be applied.
  • FIG. 5 is a diagram illustrating an example of a structure of a GATT (Generic Attribute Profile) of Bluetooth low power energy.
  • GATT Generic Attribute Profile
  • FIG. 6 is a flowchart illustrating an example of a connection procedure method in a Bluetooth low power energy technology.
  • FIG 7 and 8 are diagrams showing an example of an authentication method to which the methods proposed herein may be applied.
  • FIG. 9 illustrates an example of a method of authenticating and controlling a plurality of Bluetooth devices.
  • FIG. 10 illustrates an example of a procedure for device-to-device authentication in a user authentication service of Bluetooth low power energy technology.
  • FIG. 11 illustrates an example of a flowchart including a procedure in which a client and a server transmit and receive a message including a UAS function of a server.
  • FIG. 13 shows an example of a user authentication service protocol procedure flow chart.
  • FIG. 15 illustrates an example of a flowchart briefly illustrating a registration session start sequence flowchart disclosed in FIG. 14.
  • 16 shows an example of fields of a start message and information of each field.
  • 17 shows an example of fields of a server hash commit message and information of each field.
  • 19 shows an example of fields of a server public key message and information on each field.
  • 20 shows an example of fields of the client confirmation message and the abort message and information on each field.
  • FIG. 21 shows an example of a flowchart of a registration session procedure including a user interaction procedure for authenticating a user.
  • FIG. 22 illustrates an example of a flowchart including a procedure of transmitting a message indicating an interaction scheme before a registration session procedure as an example of the UAS procedure proposed in the present specification.
  • FIG. 23 shows an example of a flowchart showing a point where a client and a server can obtain a user input in a UAS procedure proposed in the present specification.
  • FIG. 24 illustrates an example of a flowchart showing a point at which a user input can be obtained from a server in the UAS procedure proposed in the specification.
  • 25 illustrates an example of a registration session procedure flowchart including a device authentication procedure proposed in the specification.
  • 26 illustrates another example of a flowchart of a registration session procedure including a device authentication procedure proposed in the specification.
  • FIG. 27 illustrates an example of a device-to-device initial authentication procedure, in which a user interaction authentication procedure is performed in a server, and a server and a client respectively obtain user input.
  • FIG. 28 illustrates an example of a device-to-device initial authentication procedure, in which a user interaction authentication procedure is performed in a client and a server and a client respectively obtain input of a user.
  • 29 illustrates an example of a device-to-device initial authentication procedure, in which a user interaction authentication procedure is performed in a server and the server acquires a user input.
  • FIG. 30 illustrates an example of an initial device-to-device authentication procedure, in which a user interaction authentication procedure is performed in a client and the client acquires a user input.
  • 31 shows an example of performing authentication after an initial authentication procedure between devices.
  • 32 shows another example of performing authentication after an initial authentication procedure between devices.
  • FIG. 33 illustrates an example of authenticating by using a user's biometric information of a device and a user's Bluetooth connection in the process of Bluetooth authentication.
  • 34 illustrates an example of a method of performing an authentication procedure in both devices using a pattern input.
  • 35 shows an example of a flowchart in which the server performs authentication for device registration.
  • 36 shows an example of a flowchart in which a client performs authentication for device registration.
  • FIG. 1 is a schematic diagram illustrating an example of a wireless communication system using the Bluetooth low power energy technology proposed in the present specification.
  • the wireless communication system 100 includes at least one server device 120 and at least one client device 110.
  • the server device and the client device perform Bluetooth communication using Bluetooth Low Energy (BLE) technology.
  • BLE Bluetooth Low Energy
  • BLE technology Compared to Bluetooth Basic Rate / Enhanced Data Rate (BR / EDR) technology, BLE technology has a relatively small duty cycle, enables low-cost production, and significantly reduces power consumption through low data rates. If you use a coin cell battery, it can operate for more than a year.
  • BR / EDR Bluetooth Basic Rate / Enhanced Data Rate
  • the BLE technology simplifies the connection procedure between devices, and the packet size is smaller than that of the Bluetooth BR / EDR technology.
  • the number of RF channels is 40
  • the data rate supports 1Mbps
  • the topology is a scatternet structure
  • latency is 3ms
  • (6) output power is less than 10mW (10dBm)
  • (7) is mainly used in applications such as mobile phones, watches, sports, healthcare, sensors, device control.
  • the server device 120 may operate as a client device in relation to other devices, and the client device may operate as a server device in relation to other devices. That is, in the BLE communication system, any one device may operate as a server device or a client device, and if necessary, operate as a server device and a client device.
  • the server device 120 may include a data service device, a slave device device, a slave, a server, a conductor, a host device, a gateway, and a sensing device. (Sensing Device), a monitoring device (monitoring device), the first device, the second device and the like.
  • the client device 110 may be a master device, a master, a client, a member, a sensor device, a sink device, a collector, a third device, a fourth device, or the like. Can be expressed.
  • the server device and the client device correspond to the main components of the wireless communication system, and the wireless communication system may include other components in addition to the server device and the client device.
  • the server device When the server device receives data from the client device and directly communicates with the client device, and receives a data request from the client device, the server device provides the data to the client device through a response.
  • the server device sends a notification / notification message and an indication message to the client device to provide data information to the client device.
  • the server apparatus transmits an instruction message to the client apparatus, the server apparatus receives a confirmation message corresponding to the instruction message from the client.
  • the server device provides data information to the user through a display unit or receives a request input from the user through a user input interface in the process of transmitting and receiving notification, instruction, and confirmation messages with the client device. can do.
  • the server device may read data from a memory unit or write new data to a corresponding memory in a process of transmitting and receiving a message with the client device.
  • one server device may be connected to a plurality of client devices, and may be easily reconnected (or connected) with client devices by using bonding information.
  • the client device 120 refers to a device for requesting data information and data transmission from a server device.
  • the client device receives data from the server device through a notification message, an instruction message, and the like, and when receiving an instruction message from the server device, sends a confirmation message in response to the instruction message.
  • the client device may provide information to the user through an output unit or receive an input from the user through an input unit in the process of transmitting and receiving messages with the server device.
  • the client device may read data from a memory or write new data to a corresponding memory in a process of transmitting and receiving a message with the server device.
  • Hardware components such as an output unit, an input unit, and a memory of the server device and the client device will be described in detail with reference to FIG. 2.
  • the wireless communication system may configure Personal Area Networking (PAN) through Bluetooth technology.
  • PAN Personal Area Networking
  • the wireless communication system by establishing a private piconet between devices, files, documents, and the like can be exchanged quickly and securely.
  • FIG. 2 shows an example of an internal block diagram of a device that can implement the methods proposed herein.
  • the server device 110 may include an output unit 111, a user input interface 112, a power supply unit 113, a processor 114, and a memory.
  • Memory unit 115 Memory unit 115, a Bluetooth interface 116, another communication interface 117, and a communication unit (or a transceiver unit 118).
  • the output unit 111, the input unit 112, the power supply unit 113, the processor 114, the memory 115, the Bluetooth interface 116, the other communication interface 117 and the communication unit 118 are proposed herein. It is functionally linked to perform the method.
  • the client device 120 may include an output unit 121, a user input interface 122, a power supply unit 123, a processor 124, and a memory unit 125. , A Bluetooth interface 126, and a communication unit (or a transceiver unit 127).
  • the output unit 121, the input unit 122, the power supply unit 123, the processor 124, the memory 125, the Bluetooth interface 126, and the communication unit 127 are used to perform the method proposed in this specification. Functionally connected
  • the Bluetooth interface 116, 126 refers to a unit (or module) capable of transmitting data or request / response, command, notification, indication / confirmation message, etc. between devices using Bluetooth technology.
  • the memories 115 and 125 are units implemented in various types of devices and refer to units in which various kinds of data are stored.
  • the processor 114, 124 refers to a module that controls the overall operation of the server device 110 or the client device 120.
  • the processor 114, 124 controls the message to be transmitted and received through the Bluetooth interface and other communication interfaces.
  • the processors 114 and 124 may be represented by a controller, a control unit, a controller, or the like.
  • the processors 114 and 124 may include application-specific integrated circuits (ASICs), other chipsets, logic circuits, and / or data processing devices.
  • ASICs application-specific integrated circuits
  • the processor 114, 124 controls the communication unit to receive an advertising message from the server device 110, transmits a scan request message to the server device 110, and the server device 110. Controlling the communication unit to receive a scan response message in response to the scan request from the terminal, and connecting to the server device 110 to establish a Bluetooth connection with the server device 110 Control the communication unit to transmit.
  • the processor 114 or 124 may read or write data from the server device 110 using an attribute protocol after the Bluetooth LE connection is established through the connection procedure. Control the communication unit.
  • the memories 115 and 125 may include read-only memory (ROM), random access memory (RAM), flash memory, memory cards, storage media, and / or other storage devices.
  • ROM read-only memory
  • RAM random access memory
  • flash memory memory cards, storage media, and / or other storage devices.
  • the communication unit 118 and 127 may include a baseband circuit for processing a radio signal.
  • the above technique may be implemented as a module (process, function, etc.) for performing the above-described function.
  • the module may be stored in memory and executed by a processor.
  • the memories 115 and 125 may be inside or outside the processors 114 and 124, and may be connected to the processors 114 and 124 by various well-known means.
  • the output units 111 and 121 refer to modules for providing device status information and message exchange information to a user through a screen.
  • the power supply unit refers to a module for supplying power required for the operation of the components by receiving the external power, the internal power under the control of the controller.
  • BLE technology has a small duty cycle, and the low data rate can significantly reduce power consumption.
  • the input units 112 and 122 refer to a module that provides a user's input to the controller like a screen button so that the user can control the operation of the device.
  • FIG. 3 shows an example of a Bluetooth low power energy topology.
  • device A corresponds to a master in a piconet (piconet A, shaded portion) having device B and device C as slaves.
  • a piconet means a set of devices occupying a shared physical channel in which any one of a plurality of devices is a master and the remaining devices are connected to the master device.
  • the BLE slave does not share a common physical channel with the master. Each slave communicates with the master through a separate physical channel. There is another piconet (piconet F) with master device F and slave device G.
  • a scatternet means a group of piconets in which connections between other piconets exist.
  • Device K is a master of device L and a slave of device M.
  • Device O is also on scatternet O.
  • Device O is a slave of device P and a slave of device Q.
  • Device D is an advertiser and device A is an initiator (group D).
  • Device E is a scanner and device C is an advertiser (group C).
  • Device H is an advertiser and devices I and J are scanners (group H).
  • Device K is also an advertiser and device N is an initiator (group K).
  • Device R is the advertiser and device O is the initiator (group R).
  • Devices A and B use one BLE piconet physical channel.
  • Devices A and C use another BLE piconet physical channel.
  • device D advertises using an advertisement event connectable onto an advertising physical channel, and device A is an initiator.
  • Device A may establish a connection with device D and add the device to piconet A.
  • device C advertises on the ad physical channel using some type of advertisement event captured by scanner device E.
  • Group D and Group C may use different advertising physical channels or use different times to avoid collisions.
  • Piconet F has one physical channel. Devices F and G use one BLE piconet physical channel. Device F is the master and device G is the slave.
  • Group H has one physical channel. Devices H, I and J use one BLE advertising physical channel. Device H is an advertiser and devices I and J are scanners.
  • devices K and L use one BLE piconet physical channel.
  • Devices K and M use another BLE piconet physical channel.
  • device K advertises using an advertisement event connectable onto an advertising physical channel
  • device N is an initiator.
  • Device N may form a connection with device K.
  • device K becomes a slave of two devices and simultaneously becomes a master of one device.
  • devices O and P use one BLE piconet physical channel.
  • Devices O and Q use another BLE piconet physical channel.
  • device R advertises using an advertisement event connectable onto an advertising physical channel, and device O is an initiator.
  • Device O may form a connection with device R.
  • device O becomes a slave of two devices and simultaneously becomes a master of one device.
  • FIG. 4 is a diagram illustrating an example of a Bluetooth communication architecture to which the methods proposed herein may be applied.
  • FIG. 4 shows an example of a protocol stack of Bluetooth Basic Rate (BR) / Enhanced Data Rate (EDR), and (b) shows a protocol stack of Bluetooth Low Energy (LE). An example is shown.
  • BR Basic Rate
  • EDR Enhanced Data Rate
  • LE Bluetooth Low Energy
  • the Bluetooth BR / EDR protocol stack may be configured based on a host controller interface (HCI) 18. It may include a host stack (20).
  • HCI host controller interface
  • the host stack (or host module) 20 refers to a wireless transceiver module for receiving a 2.4 GHz Bluetooth signal and hardware for transmitting or receiving a Bluetooth packet. Control and perform actions.
  • the controller stack 10 may include a PHY layer 12, a link controller layer 14, and a link manager layer 16.
  • the PHY layer 12 is a layer that transmits and receives a 2.4 GHz radio signal.
  • PFS layer Global System for Mobile Communications
  • the PHY layer 12 may transmit data by hopping 79 RF channels.
  • the link controller layer 14 is responsible for transmitting a digital signal, selects a channel sequence hopping 1400 times per second, and transmits a 625us length time slot for each channel.
  • the link manager layer 16 controls the overall operation (link setup, control, security) of the Bluetooth connection by using the Link Manager Protocol (LMP).
  • LMP Link Manager Protocol
  • the link manager layer 16 may perform the following functions.
  • Detach Stops the connection and tells the other device the reason for the interruption.
  • the host controller interface layer 18 provides an interface between the host module and the controller module so that the host can provide commands and data to the controller, and the controller can provide events and data to the host.
  • the host stack (or host module) 20 may include a logical link control and adaptation protocol (L2CAP, 21), an attribute protocol (Protocol, 22), a generic attribute profile (GATT, 23), and a generic access profile. Profile, GAP, 24), BR / EDR profile 25.
  • L2CAP logical link control and adaptation protocol
  • Protocol 22
  • GATT generic attribute profile
  • GAP BR / EDR profile
  • the logical link control and adaptation protocol (L2CAP) 21 may provide one bidirectional channel for transmitting data to a specific protocol or profile.
  • the L2CAP 21 may multiplex various protocols, profiles, etc. provided by a higher layer of Bluetooth.
  • L2CAP of Bluetooth BR / EDR uses dynamic channel, supports protocol service multiplexer, retransmission, streaming mode, and provides segmentation, reassembly, per-channel flow control, and error control.
  • the generic attribute profile (GATT) 23 may be operable as a protocol describing how the attribute protocol 22 is used in the construction of services.
  • the general attribute profile 23 may be operable to specify how ATT attributes are grouped together into services, and may be operable to describe features associated with the services.
  • the generic attribute profile 23 and the attribute protocol ATT 22 may use features to describe the state and services of a device and to describe how features relate to each other and how they are used.
  • the attribute protocol 22 and the BR / EDR profile 25 define a service profile using Bluet BR / EDR and an application protocol for sending and receiving these data, and the Generic Access Profile. , GAP, 24) defines device discovery, connectivity, and security levels.
  • the Bluetooth LE protocol stack is a controller stack 30 operable to handle timing-critical radio interface and a host operable to process high level data. It contains a stack (Host stack, 40).
  • the controller stack 30 may be implemented using a communication module that may include a Bluetooth radio, for example, a processor module that may include a processing device such as a microprocessor.
  • the host stack may be implemented as part of an OS running on a processor module, or as an instance of a package on the OS.
  • controller stack and the host stack can be operated or executed on the same processing device in the processor module.
  • the controller stack 30 includes a physical layer (PHY) 32, a link layer 34, and a host controller interface 36.
  • PHY physical layer
  • link layer 34 link layer
  • host controller interface 36 host controller interface
  • the physical layer (PHY) 32 is a layer that transmits and receives a 2.4 GHz radio signal and uses GFSK (Gaussian Frequency Shift Keying) modulation and a frequency hopping technique composed of 40 RF channels.
  • GFSK Gausian Frequency Shift Keying
  • the link layer 34 which transmits or receives a Bluetooth packet, creates a connection between devices after performing advertising and scanning functions using three advertising channels, and generates up to 257 bytes of data packets through 37 data channels. Provides the ability to send and receive.
  • the host stack includes a logical link control and adaptation protocol (L2CAP, 41), a security manager (SM, 42), an attribute protocol (Attribute Protocol, ATT, 43), a generic attribute profile (GATT, 44). It may include a Generic Access Profile (45), LE Profile (46). However, the host stack 40 is not limited to this and may include various protocols and profiles.
  • the host stack uses L2CAP to multiplex the various protocols, profiles, etc. provided by Bluetooth.
  • L2CAP Logical Link Control and Adaptation Protocol 41 may provide one bidirectional channel for transmitting data to a specific protocol or profile.
  • the L2CAP 41 may be operable to multiplex data among higher layer protocols, segment and reassemble packages, and manage multicast data transmission.
  • Bluetooth LE In Bluetooth LE, three fixed channels (one for the signaling channel, one for the Security Manager, and one for the Attribute protocol) are used by default. And, if necessary, a dynamic channel may be used.
  • BR / EDR Base Rate / Enhanced Data Rate
  • the SM (Security Manager) 42 is a protocol for authenticating a device and providing key distribution.
  • Attribute Protocol (ATT) 43 defines a rule for accessing data of a counterpart device in a server-client structure. ATT has six message types (Request, Response, Command, Notification, Indication, Confirmation).
  • the Request message is a message for requesting and delivering specific information from the client device to the server device
  • the Response message is a response message for the request message, which can be used for transmission from the server device to the client device.
  • Command message A message sent mainly from the client device to the server device to indicate a command of a specific operation.
  • the server device does not transmit a response to the command message to the client device.
  • Notification message This message is sent from the server device to the client device for notification such as an event.
  • the client device does not transmit a confirmation message for the notification message to the server device.
  • Indication and Confirm message This message is sent from the server device to the client device for notification / instruction such as an event. Unlike the notification message, the client device transmits a confirmation message for the Indication message to the server device. .
  • the present invention transmits a value for the data length when a long data request is made in the GATT profile using the attribute protocol (ATT, 43) so that the client can know the data length clearly, and from the server using the UUID (Characteristic) Can receive the value.
  • ATT attribute protocol
  • UUID Consumer User Data
  • the generic access profile 45 is a newly implemented layer for Bluetooth LE technology and is used to control role selection and multi-profile operation for communication between Bluetooth LE devices.
  • the general access profile 45 is mainly used for device discovery, connection creation, and security procedures, and defines a method of providing information to a user, and defines the type of an attribute as follows.
  • UUID Universal Unique Identifier, value type
  • the LE profile 46 is mainly applied to a Bluetooth LE device as profiles having a dependency on GATT.
  • the LE profile 46 may include, for example, Battery, Time, FindMe, Proximity, Time, and the like. Details of GATT-based Profiles are as follows.
  • the generic attribute profile GATT 44 may be operable as a protocol describing how the attribute protocol 43 is used in the construction of services.
  • the generic attribute profile 44 may be operable to specify how ATT attributes are grouped together into services, and may be operable to describe features associated with the services.
  • the generic attribute profile 44 and the attribute protocol may use features to describe the state and services of a device, and how features relate to each other and how they are used.
  • the BLE procedure may be classified into a device filtering procedure, an advertising procedure, a scanning procedure, a discovery procedure, a connecting procedure, and the like.
  • the device filtering procedure is a method for reducing the number of devices performing a response to a request, an indication, a notification, and the like in the controller stack.
  • the controller stack can control the number of requests sent, reducing power consumption in the BLE controller stack.
  • the advertising device or scanning device may perform the device filtering procedure to limit the device receiving the advertising packet, scan request or connection request.
  • the advertising device refers to a device that transmits an advertising event, that is, performs an advertisement, and is also referred to as an advertiser.
  • the scanning device refers to a device that performs scanning and a device that transmits a scan request.
  • the scanning device when the scanning device receives some advertising packets from the advertising device, the scanning device should send a scan request to the advertising device.
  • the scanning device may ignore the advertisement packets transmitted from the advertisement device.
  • the device filtering procedure may also be used in the connection request process. If device filtering is used in the connection request process, it is not necessary to transmit a response to the connection request by ignoring the connection request.
  • the advertising device performs an advertising procedure to perform a non-directional broadcast to the devices in the area.
  • non-directional broadcast refers to broadcast in all directions rather than broadcast in a specific direction.
  • Non-directional broadcasts refer to broadcasts in a particular direction. Non-directional broadcasts occur without a connection procedure between an advertising device and a device in a listening (or listening) state (hereinafter referred to as a listening device).
  • the advertising procedure is used to establish a Bluetooth connection with a nearby initiating device.
  • the advertising procedure may be used to provide periodic broadcast of user data to scanning devices that are listening in the advertising channel.
  • the advertising devices may receive a scan request from listening devices that are listening to obtain additional user data from the advertising device.
  • the advertising device transmits a response to the scan request to the device that sent the scan request through the same advertising physical channel as the received advertising physical channel.
  • Broadcast user data sent as part of an advertisement packet is dynamic data, while scan response data is generally static data.
  • the advertising device may receive a connection request from the initiating device on the advertising (broadcast) physical channel. If the advertising device used a connectable advertising event and the initiating device was not filtered by the device filtering procedure, the advertising device stops the advertising and enters the connected mode. The advertising device may start advertising again after the connected mode.
  • the device performing the scanning i.e., the scanning device, performs a scanning procedure to listen to the non-directional broadcast of the user data from the advertising devices using the advertising physical channel.
  • the scanning device sends a scan request to the advertising device via the advertising physical channel to request additional data from the advertising device.
  • the advertising device transmits a scan response that is a response to the scan request, including additional data requested by the scanning device over the advertising physical channel.
  • the scanning procedure can be used while connected to other BLE devices in the BLE piconet.
  • the scanning device If the scanning device is in an initiator mode that can receive the broadcasted advertising event and initiate a connection request, the scanning device sends the connection request to the advertising device via the advertising physical channel to the advertising device. You can start a Bluetooth connection with.
  • the scanning device When the scanning device sends a connection request to the advertising device, the scanning device stops initiator mode scanning for further broadcast and enters the connected mode.
  • Bluetooth devices Devices capable of Bluetooth communication (hereinafter referred to as “Bluetooth devices”) perform an advertisement procedure and a scanning procedure to find devices that are nearby or to be found by other devices within a given area.
  • the discovery procedure is performed asymmetrically.
  • a Bluetooth device that attempts to find another device around it is called a discovering device and listens for devices that advertise a scannable advertisement event.
  • Bluetooth devices discovered and available from other devices are referred to as discoverable devices, and actively broadcast advertising events so that other devices can scan through an advertising (broadcast) physical channel.
  • Both the discovering device and the discoverable device may already be connected with other Bluetooth devices in the piconet.
  • connection procedure is asymmetric, and the connection procedure requires the other Bluetooth device to perform the scanning procedure while the specific Bluetooth device performs the advertisement procedure.
  • the advertising procedure can be the goal, so that only one device will respond to the advertising.
  • the connection may be initiated by sending a connection request to the advertising device via the advertising (broadcast) physical channel.
  • the link layer LL enters the advertisement state by the instruction of the host (stack). If the link layer is in the advertisement state, the link layer sends advertisement packet data units (PDUs) in the advertisement events.
  • PDUs advertisement packet data units
  • Each advertising event consists of at least one advertising PDU, which is transmitted via the advertising channel indexes used.
  • the advertisement event may terminate when the advertisement PDU is transmitted through each of the advertisement channel indexes used, or may terminate the advertisement event earlier when the advertisement device needs to make space for performing another function.
  • the link layer enters the scanning state by the indication of the host (stack). In the scanning state, the link layer listens for advertising channel indices.
  • scanning states There are two types of scanning states: passive scanning and active scanning, each scanning type being determined by the host.
  • ScanInterval is defined as the interval (interval) between the starting points of two consecutive scan windows.
  • the link layer must listen for completion of all scan intervals in the scan window as instructed by the host. In each scan window, the link layer must scan a different advertising channel index. The link layer uses all available advertising channel indexes.
  • the link layer When passive scanning, the link layer only receives packets and does not transmit any packets.
  • the link layer When active scanning, the link layer performs listening to rely on the advertising PDU type, which may request advertising PDUs and additional information related to the advertising device from the advertising device.
  • the link layer enters the initiation state by the indication of the host (stack).
  • the link layer When the link layer is in the initiating state, the link layer performs listening for the advertising channel indexes.
  • the link layer listens for the advertising channel index during the scan window period.
  • the link layer enters the connected state when the device performing the connection request, i.e., the initiating device, sends the CONNECT_REQ PDU to the advertising device or when the advertising device receives the CONNECT_REQ PDU from the initiating device.
  • connection After entering the connected state, the connection is considered to be created. However, it does not need to be considered to be established at the time the connection enters the connected state. The only difference between the newly created connection and the established connection is the link layer connection supervision timeout value.
  • the link layer that performs the master role is called a master, and the link layer that performs the slave role is called a slave.
  • the master controls the timing of the connection event, and the connection event is the point in time when the master and the slave are synchronized.
  • BLE devices use the packets defined below.
  • the link layer has only one packet format used for both advertisement channel packets and data channel packets.
  • Each packet consists of four fields: Preamble, Access Address, PDU, and CRC.
  • the PDU When one packet is sent on an advertising physical channel, the PDU will be an advertising channel PDU, and when one packet is sent on a data physical channel, the PDU will be a data channel PDU.
  • Advertising channel PDU (Advertising Channel PDU )
  • the advertising channel PDU Packet Data Unit
  • PDU Packet Data Unit
  • the PDU type field of the advertising channel PDU included in the header indicates a PDU type as defined in Table 1 below.
  • Advertising PDU (Advertising PDU )
  • advertising channel PDU types are called advertising PDUs and are used in specific events.
  • ADV_IND Connectable Non-Oriented Ads Event
  • ADV_DIRECT_IND Connectable Directional Advertising Event
  • ADV_NONCONN_IND Non-Connectable Non-Oriented Ads Event
  • ADV_SCAN_IND Scannable Non-Oriented Ads Event
  • the PDUs are transmitted at the link layer in the advertisement state and received by the link layer in the scanning state or initiating state.
  • the advertising channel PDU type below is called a scanning PDU and is used in the state described below.
  • SCAN_REQ Sent by the link layer in the scanning state and received by the link layer in the advertising state.
  • SCAN_RSP Sent by the link layer in the advertising state and received by the link layer in the scanning state.
  • the advertising channel PDU type below is called the initiating PDU.
  • CONNECT_REQ Sent by the link layer in the initiating state and received by the link layer in the advertising state.
  • the data channel PDU has a 16-bit header, payloads of various sizes, and may include a message integrity check (MIC) field.
  • MIC message integrity check
  • the procedure, state, packet format, etc. in the BLE technology may be applied to perform the methods proposed herein.
  • FIG. 5 is a diagram illustrating an example of a structure of a GATT (Generic Attribute Profile) of Bluetooth low power energy.
  • GATT Generic Attribute Profile
  • the GATT Generic Attribute Profile
  • a peripheral device for example, a sensor device serves as a GATT server, and has a definition of a service and a characteristic.
  • the GATT client sends a data request to the GATT server, and all transactions begin at the GATT client and receive a response from the GATT server.
  • the GATT-based operating structure used in the Bluetooth LE is based on Profile, Service, and Characteristic, and may form a vertical structure as shown in FIG. 5.
  • the profile consists of one or more services, and the service may consist of one or more features or other services.
  • the service divides data into logical units and may include one or more characteristics or other services.
  • Each service has a 16-bit or 128-bit identifier called the Universal Unique Identifier (UUID).
  • UUID Universal Unique Identifier
  • the characteristic is the lowest unit in the GATT based operation structure.
  • the property contains only one data and has a UUID of 16 bits or 128 bits similar to the service.
  • the property is defined as a value of various pieces of information and requires one attribute to contain each piece of information. Multiple properties of the above properties can be used.
  • the attribute consists of four components and has the following meaning.
  • Type the type of attribute
  • FIG. 6 is a flowchart illustrating an example of a connection procedure method in a Bluetooth low power energy technology.
  • the server transmits an advertisement message to the client through the three advertising channels (S6010).
  • the server may be called an advertiser before connection, and may be called a master after connection.
  • An example of the server may be a sensor (temperature sensor, etc.).
  • the client may be called a scanner before the connection, and may be called a slave after the connection.
  • An example of the client may be a smartphone.
  • Bluetooth communicates over 40 channels across the 2.4 GHz band.
  • Three of the 40 channels are advertising channels, and are used for exchanging packets, including various advertising packets, to establish a connection.
  • the remaining 37 channels are used for data exchange after connection to the data channel.
  • the client may transmit a scan request message to the server to obtain additional data (for example, a server device name) to the server.
  • additional data for example, a server device name
  • the server transmits a scan response message including additional data to the client in response to a scan request message.
  • the scan request message and the scan response message are one end of the advertisement packet, and the advertisement packet may include only user data of 31 bytes or less.
  • the data size is larger than 3 bytes, but there is a large amount of data overhead for sending data through connection, the data is divided twice using a scan request message / scan response message.
  • the client transmits a connection request message for establishing a Bluetooth connection with the server to the server (S6020).
  • the server and client then perform a security establishment procedure.
  • the security establishment procedure may be interpreted as or included in Secure Simple Pairing.
  • the security establishment procedure may be performed through phase 1 to phase 3.
  • phase 1 a pairing procedure (phase 1) is performed between the server and the client (S6030).
  • the client transmits a pairing request message to the server, and the server transmits a pairing response message to the client.
  • the pairing procedure exchanges device-to-device authentication requirements, input / output (I) / output (I) capabilities, and key size information. This information determines which key generation method to use in Phase 2.
  • phase 2 legacy pairing or secure connections are performed between the server and the client (S6040).
  • Phase 2 a 128-bit Temporary Key and a Short Term Key (STK) are generated to perform legacy pairing.
  • STK Short Term Key
  • STK Short Term Key
  • LTK long term key
  • LTK Long Term Key
  • phase 3 a key distribution procedure is performed between the server and the client (S6050).
  • Secure Simple Pairing is performed for the purpose of providing a convenient pairing procedure for the user and for enhancing the security against passive eavesdropping and man-in-the-middle attacks.
  • Secure Simple Pairing is defined as four stages as below.
  • devices exchange IO capabilities to determine the appropriate algorithm to use for Secure Simple Pairing.
  • the initiator transmits an IO capability request message requesting IO capability to the responder, and the responder responds to the input / output capability response message (IO capability request message).
  • IO capability Response message is transmitted.
  • the initiator and the responder exchange the input / output capability of each other through an IO capability exchange step.
  • the public key may be exchanged by exchanging multiple messages.
  • the two devices can exchange Diffie-Hellman (DH) keys, which are 192-bit or 256-bit symmetric keys.
  • DH Diffie-Hellman
  • Passkey Entry One of the two devices does not have a display device capable of displaying six digit numbers, while the input device is present and the other device shows six digit numbers. Used when there is a display device to give.
  • Out of Band Used when searching for a remote device and utilizing the Out Of Mechanism (e.g. NFC) to support the exchange of cryptographic numbers to be used in the pairing process.
  • Out Of Mechanism e.g. NFC
  • an encryption channel is created through the DHKey verification and link key generation procedure through the authentication stage 2 step.
  • FIG 7 and 8 are diagrams showing an example of an authentication method to which the methods proposed herein may be applied.
  • FIG. 7A illustrates an example of legacy pairing
  • FIG. 7B illustrates an example of Numeric Comparison
  • FIG. 8A illustrates an example of just work
  • FIG. 8B illustrates an example of a passkey entry.
  • a PIN code output through an output unit (for example, a display unit) of a master device is input to a slave device.
  • the pairing is performed.
  • the device checks whether the numbers output to the master device and the slave device are the same, and if they are the same, the device is confirmed You will be authenticated.
  • Bluetooth devices must discover the device and establish a connection in order to transmit and receive data using Bluetooth.
  • the two devices need to authenticate each other and grant a use right.
  • methods such as Legacy Pairing, Numeric Comparison, and Passkey Entry described above are inconvenient for a user due to a predefined password or multiple logins. The problem arises, which is a difficult process.
  • the present invention can intuitively recognize the user based on the input / output function of the device, and proposes a method for authentication in a specific profile.
  • a client may be referred to as a UA client
  • a server may be referred to as a UA server.
  • FIG. 9 illustrates an example of a method of authenticating and controlling a plurality of Bluetooth devices.
  • the user may own a plurality of Bluetooth devices.
  • the Bluetooth device includes a wearable device, a smart device or a device controlled by an external control device (eg, a remote controller).
  • Bluetooth devices may include a display by the device based on type or function.
  • a user establishes a Bluetooth connection to each of a plurality of devices.
  • a user must perform authentication between at least one Bluetooth device controlled by an external control device and a wearable device possessed by the user.
  • the user must perform each of a plurality of authentications in order to authenticate each device.
  • Different authentication information may be used in a plurality of authentication procedures. For example, when performing authentication using a password, the user must separately remember all passwords required for authentication of each device.
  • a separate operation / control is required.
  • This conventional authentication method causes inconveniences in Bluetooth connection and use to people who have difficulty using or operating the device (for example, the elderly, the disabled, etc.).
  • an authentication method that enhances user convenience is required. See below for details.
  • FIG. 10 illustrates an example of a procedure for device-to-device authentication in a user authentication service of Bluetooth low power energy technology.
  • the device refers to a device capable of performing Bluetooth communication.
  • the user authentication service (UAS, hereinafter referred to as 'UAS' for convenience) is a service that automatically authenticates other devices using one device.
  • one device may correspond to a wearable device, and another device may correspond to a notebook, a mobile phone, a tablet, a printer, and the like. That is, the UAS is a user authentication service that informs a user who uses a user authentication (UA) server to a device to be used by wearing a wearable device.
  • UAS user authentication service that informs a user who uses a user authentication (UA) server to a device to be used by wearing a wearable device.
  • UAS procedure three procedures may be performed for device-to-device authentication. Three procedures are a registration session, a secure session, and a secure get and put session.
  • the client 10010 and the server 10020 perform a registration session procedure for registering each other's information between the devices (S10010).
  • the registration session procedure includes a notification procedure of an authentication method, a hash value generation procedure, a public key exchange procedure, and a registration ID generation procedure.
  • the client 10010 and the server 10020 perform a secure session procedure for generating an encrypted link (S10020). Before exchanging information between the devices, the client 10010 and the server 10020 may generate a secure link using the registration ID transmitted in the registration session procedure.
  • the client 10010 and the server 10020 After the secure link is generated in the secure session procedure, the client 10010 and the server 10020 perform a secure get and put session procedure that exchanges token information between devices (S10030). .
  • FIG. 11 illustrates an example of a flowchart including a procedure in which a client and a server transmit and receive a message including a UAS function of a server.
  • UAS includes a UAS Feature characteristic.
  • the UAS functional feature allows the UA client to know the function of the UA server before performing the registration session procedure.
  • the client transmits a characteristic read request message for requesting the UAS functional characteristic information of the server to the server (S11010).
  • This message may be referred to as a UAS Feature Get message.
  • the server After receiving the UAS Feature Get message, the server transmits a Characteristic Read Response message including the UAS feature characteristic information of the server in response thereto (S11020). This message may be referred to as a UAS Feature message.
  • the client may determine the functionality supported by the server based on the received UAS capability message.
  • the server may transmit a characteristic notification message including information about the changed token to the client.
  • This message may be referred to as a token change notify message.
  • the client may update the token information based on the received Token Change Notify message.
  • the server may transmit an error response message (Error Response message) to the client (S11040).
  • Error Response message an error response message
  • the UAS server shown in FIG. 12 corresponds to a UA server.
  • the UAS Feature Get message includes a Message Type field indicating the type of the corresponding message.
  • the message type field is set to UAS Feature Get.
  • Requirements indicate whether a corresponding field is mandatory in a message. M indicates that the field is mandatory.
  • UAS Feature messages include the Message Type field, the UAS Version field, the Registration Id Count field, the Token Count field, the Factor Type List field, and the UA Server. It may include an ID (UA Server ID) field and a Max Clock Drift Rate field.
  • the function flag supports MACed Server-Issued Tokens.
  • the function flag generates a MAC value using a token and a session key generated by the UA server.
  • the UA client performs authentication using the same session key.
  • the function flag supports token lookup by factor type.
  • the UA client sends a token value message of a secure get in a secure session.
  • the UA server then sends a Token Value Response message of Secure Get.
  • the UA client checks whether the tokens match each other.
  • the function flag supports SAS verified LTK.
  • the short authentication string SAS may be confirmed by a user using an I / O display of the UA server.
  • SAS may correspond to a combination of four or more alphanumeric characters.
  • the function flag supports Set Time.
  • the function flag may perform a registration session by setting a different setup time for each registration ID of the UA client.
  • the function flag supports distance bounding.
  • the token may be generated using a fixed distance value between the client and the server measured by RSSI.
  • Registration ID Count is the number of client registrations initiated by the server.
  • the UA server may send an error message to the UA client using the registration ID number information when the maximum number of reg IDs that can be supported is used.
  • the Max Clock Drift Rate corresponds to the maximum clock drift rate of the UA server.
  • Clock drift is a phenomenon caused by the clock not operating at the correct speed.
  • the name, size, or format of each field may be changed.
  • FIG. 13 shows an example of a flowchart of a user authentication service protocol procedure.
  • the server and the client form a BLE connection state (BLE connection state) before starting the registration session procedure (S13010).
  • the client requests UAS Feature Characteristic information of the server from the UA server (S13020) and receives UAS feature characteristic information from the server (S13030).
  • the server may transmit a notification message including the information about the changed token to the client (S13060).
  • Each of these three procedures includes the UAS Feature Get message transmission (S11010), the UAS feature message transmission (S11020), and the Token Change Notify message transmission (S11030) procedure described above in connection with FIG. The same can be done.
  • the client After receiving the UAS function information, the client transmits a write request message related to a specific procedure of the client to the server (S13040). This message may be referred to as a UACP Characteristic Write message.
  • the UAS includes a User Authentication (UA) Action Control Point characteristic.
  • the UA motion control point feature allows the UA client to initiate a specific action by the UA server.
  • the server transmits a characteristic indication message including UA Action Control Point (UACP) characteristic information (S13050).
  • UACP UA Action Control Point
  • This message may be referred to as a UACP Control Point Characteristic Indication message.
  • Table 3 shows the op codes of the UACP characteristic write message and the UACP characteristic indication message. The type of message is determined based on the op code included in the UACP characteristic information.
  • the Registration Start (0x00) message initiates a procedure for requesting control of user authentication.
  • the Registration Client Public Key (0x01) message initiates the procedure to provide the public key of the UA client.
  • the Registration confirmation message (0x02) initiates a procedure to confirm the registration session between the UA client and the UA server.
  • the Registration Abort (0x03) message initiates a procedure to terminate the registration procedure.
  • the Secure Get Token Value (0x04) message initiates a procedure to retrieve one token for a secure session.
  • the Secure Get All Token Value (0x05) message initiates a procedure to retrieve all tokens stored on the UA server in a secure session.
  • the Secure Add / Update Token (0x06) message initiates the process of adding or updating a token on the UA server.
  • the Secure Delete Token (0x07) message initiates the procedure to delete the token from the UA server.
  • the Secure Unregister ID message (0x08) initiates a procedure of notifying the UA server of the unregister ID. In that case, the information related to the deregistration ID should be deleted from the UA server.
  • the Secure Set Time (0x09) message initiates a procedure to prevent security attacks on timestamps of other user IDs.
  • the Secure Set Distance Bounding (0x0A) message initiates the procedure of setting a defined distance between the UA server and the UA client. The response message is sent to the UA client according to the indication of the UACP characteristic.
  • the client transmits a write request message for initiating a registration session to the server (S14010).
  • This message may be referred to as a start message.
  • the start message includes Start Registration, Registration Request Number, and Registration Message.
  • the server may transmit a response message to the client (S14020).
  • the server may transmit a notification message including a server hash commit to the client (S14030).
  • This message may be referred to as a server hash commit message.
  • the client After receiving the server hash commit message, the client transmits a read request for registration session read / notify message, which is a read request message, to the server (S14040).
  • the server may transmit a read response message to the client in response (S14050).
  • This read response message includes a server hash commit, H (KS_PUB), a user interaction type, and user interaction data.
  • the client receives a read response message containing H (KS_PUB) and stores H (KS_PUB) for verification at a later step.
  • the client also displays the interaction message required by the user and waits for confirmation from the user.
  • the server may transmit a notification message including whether the user interaction is successful to the client (S14060). This message may be referred to as a User Interaction Complete message. Details of the user interaction will be described later.
  • the server After receiving the client user interaction result, the server transmits a write request message including the public key of the client to the server (S14070).
  • This write request message includes a client public key, KCX_PUB, KCY_PUB, N_c, and User Interaction Data. This message may be referred to as a client public key message.
  • the server receives the write request message and then passes the KCX_PUB and KCY_PUB. Create an LTK using KS_PRIV and store N_c. Thereafter, the server may transmit a write response message to the client (S14080).
  • the client waits for the server to complete the LTK generation. Thereafter, the client may receive a Registration Session Read / Notify notification message notifying the completion of the LTK generation from the server (S14090). The client can obtain the LTK from this message.
  • the server receives a Read Request For Registration Session Read / Notify message, which is a read request message, from the client (S140100) and generates a MAC key for KS_PUB.
  • the server may transmit a read response message including the server public key, KSX_PUB, KSY_PUB, registration ID, N_s, and MAC_s to the client (S140110).
  • This message may be referred to as a server public key message.
  • the server may transmit a message to the client indicating that SAS is displayed on the server device for user confirmation (S140120). The user then verifies the SAS from the display of the UA server device.
  • the client verifies SAS Confirmation, H (KS_PUB) and MAC_s, and generates LTK and MAC_c.
  • the client transmits a write request message including a client confirmation and a MAC_c to the server (S140130). This message may be referred to as a client acknowledgment message.
  • the client confirmation message indicates that device registration is completed.
  • the server verifies the received MAC_c and stores the registration ID and LTK in the database. Thereafter, the server may transmit a write response message to the client (S140140). The client receiving this write response message stores the registration ID and LTK in the database. This message may be referred to as a Client Confirmation Reply message.
  • the registration session start sequence is completed through the above procedure.
  • the UA client can initiate a secure session and generate its own token.
  • FIG. 15 illustrates an example of a flowchart briefly illustrating a registration session start sequence flowchart disclosed in FIG. 14.
  • the client transmits a start message for requesting authentication to the server (S15010).
  • This procedure may be performed in the same manner as in step S14010 of FIG. 14 described above.
  • the server sends a message including a server hash commit (Server Hash Commit) to the client (S15020).
  • This procedure may be performed in the same manner as in S14030 of FIG. 14 described above.
  • the server may transmit a message indicating user interaction completion to the client (S15030). This procedure may be performed in the same manner as in step S14060 of FIG. 14 described above.
  • the client transmits a message including the client public key to the server (S15040). This procedure may be performed in the same manner as in step S14070 of FIG. 14 described above.
  • the server transmits a message including the server public key to the client (S15050).
  • This procedure may be performed in the same manner as in step S140110 of FIG. 14 described above.
  • the client transmits a client confirmation message (S S15060). This procedure may be performed in the same manner as in step S140130 of FIG. 14 described above.
  • the server transmits a client confirmation reply message to the client in response to the client confirmation message (S15070). This procedure may be performed in the same manner as in step S140140 of FIG. 14 described above.
  • the client may transmit an Abort message, which is a message for terminating the registration session procedure, to the server (S15010).
  • the abort message may be transmitted when an error defined in the UAS occurs in the registration session procedure. This may interrupt the registration session procedure.
  • 16 shows an example of fields of a start message and information of each field.
  • the start message includes a Registration Session Number field, a Message Type field, a Reserved field, and a Registration Session Start Flags field.
  • the start message may be referred to as a registration start message.
  • the UAS client shown in FIG. 16 corresponds to a UA client.
  • the message type is set to Registarion Session Start.
  • the reserved field is set to zero.
  • the registration session number field is provided by the UA client to track the registration order and correlate the registration session message. If a registration sequence is initiated by a registration session start message, subsequent registration session messages for the session sequence may include this registration session number.
  • the registration session number field may be provided by the UA client to correlate the message with the registration order and may be included in cryptographic calculations to prevent replay attacks.
  • all messages can use the session number.
  • a CMAC key may be used.
  • the Register with SAS confirmed LTK in the Start Registration Session Flag field is a Registration Type that the UA server must verify with the user's confirmation of SAS characters using the device's display. Register without SAS confirmed does not require user confirmation.
  • the name, size, or format of each field may be changed.
  • 17 shows an example of fields of a server hash commit message and information of each field.
  • the Server Hash Commit message includes a message type field, a temporary registration ID field, a registration session number field, an H (KS_PUB) field, a user interaction type field, and user interaction data ( User Interaction Data) field.
  • the message type field is set to Registration Session Server Hash Commit. Details regarding the registration session number field are as described above.
  • the UAS client shown in FIG. 17 corresponds to a UA client, and the UAS server corresponds to a UA server.
  • the server may provide a temporary registration ID to the client. After the registration session is completed, the temporary registration ID is changed to the user ID.
  • the H (KS_PUB) field is a hash generated based on the server's public key.
  • the H (KS_PUB) field may be 128 bits.
  • the H (KS_PUB) field may be generated using the following equation.
  • the name, size, or format of each field may be changed.
  • the client public key message includes a message type field, a registration ID field, a registration session number field, a KCX_PUB field and a KCY_PUB field, an N_c field, and a user feedback data field.
  • the message type field is set to the Registration Session Client Public Key.
  • the content of the registration session number field is as described above.
  • the registration ID field corresponds to the temporary registration ID field described above.
  • the UAS client shown in FIG. 18 corresponds to a UA client, and the UAS server corresponds to a UA server.
  • the KCX_PUB field corresponds to the X coordicate of the UA client public key.
  • the KCY_PUB field corresponds to the Y coordinate (Y coordicate) of the UA client public key.
  • the KCX_PUB field and the KCY_PUB field correspond to a size of 32 octets and may be based on ECDH P-256.
  • KCX_PUB and KCY_PUB are included in KC_PUB.
  • the N_c field is a 16 byte nonce generated by the UA client.
  • the User Feedback Data field is input data of a user collected by a UA client regarding a user interaction type requested by the UA server.
  • the name, size, or format of each field may be changed.
  • 19 shows an example of fields of a server public key message and information on each field.
  • the server public key message includes a message type field, a registration ID field, a registration session number field, a KCX_PUB field, a KCY_PUB field, an N_s field, and a MAC_s field.
  • the message type field is set to the Registration Session Server Public Key.
  • the KSX_PUB field corresponds to the X coordicate of the UA server public key.
  • the KSY_PUB field corresponds to the Y coordinate of the UA server public key.
  • the KSX_PUB field and the KSY_PUB field correspond to a 32 octet size and may be based on the ECDH P-256.
  • KSX_PUB and KSY_PUB are included in KS_PUB.
  • the UAS server shown in FIG. 19 corresponds to a UA server.
  • the N_s field is a 16 byte nonce generated by the UA server.
  • the MAC_s field is a server public key hash.
  • the MAC_s field is used by the UA client to authenticate that a key exchange occurs at the intended UA server. That is, the MAC_s field confirms sending a message to another device to check whether the message has been changed while being transmitted.
  • the hash contains registration ID information.
  • the name, size, or format of each field may be changed.
  • 20 shows an example of fields of the client confirmation message and the abort message and information on each field.
  • the UAS client shown in FIG. 20 corresponds to a UA client, and the UAS server corresponds to a UA server.
  • the client confirmation message includes a message type field, a registration ID field, a registration session number field, and a MAC_c field.
  • the message type field is set to Registration Session Client Confirmation. Details regarding the registration ID field and the registration session number field are as described above.
  • the MAC_c information is a client public key hash that is used by the UA server to authenticate that a key exchange occurs at the intended UA client.
  • the MAC_c field confirms sending a message to another device to check whether the message has changed during transmission.
  • the hash contains registration ID information.
  • the registration ID information is stored in the database of each device.
  • the Abort message includes a message type field and a registration ID field.
  • the matter regarding the message type field is as described above.
  • the registration ID field contains registration ID information associated with a suspended registration session.
  • the name, size, or format of each field may be changed.
  • FIG. 21 shows an example of a flowchart of a registration session procedure including a user interaction procedure for authenticating a user.
  • the server After the server receives a registration start message (S21030) (see step S14010 of FIG. 14 described above), the server acquires information for identifying a user and authenticates the user using the obtained identification information. A user interaction procedure is performed (S21040). The user interaction procedure may also be referred to as a user authentication procedure.
  • User Interaction is a procedure for authenticating a user using a device.
  • the UAS may use a user interaction type supported by the UAS device.
  • the user interaction type is determined based on a method of performing user interaction or a function supported by the device as a type of identification information.
  • the user interaction type relates to the type of information requested by the UA server and received from the user.
  • the server may receive user information directly from the user based on the input / output capability of the server device. For example, if the server device is equipped with a fingerprint recognition system, it may receive fingerprint information of the user.
  • Table 4 below shows an example of types of user interaction types and user input information input to the UA server according to each type.
  • User Interaction Data is data received from a user according to the type of user interaction requested by the UA server. For example, if the user interaction type is a fingerprint, the user interaction data includes fingerprint information. UAS can further enhance security by performing user authentication using the user's biometric information (eg, fingerprint, iris, etc.).
  • biometric information eg, fingerprint, iris, etc.
  • Table 5 below shows examples of user interaction methods, which are methods of authenticating a user using a user interaction type.
  • the password may be input to the client device Device A or the server device Device B (Method # 1). Iris information may be input to the client device or the server device (Method # 2). Pattern information may be input to the client device or the server device (Method # 3). In addition, there may be a method of using other user interaction types shown in Table 4 above.
  • the server allocates a temporary user ID based on the received user information.
  • the server assigns a new server public key to the temporary user ID.
  • the server then sends a temporary user ID to the client using a User Interaction Complete message.
  • the server transmits a pre-allocated user ID to the client.
  • the client receives the newly generated user ID and assigns the client public key to which the user is not assigned. Thereafter, the client transmits a message including the client public key to the server (S21060). If the received user ID is assigned to the client in advance, the public key corresponding to the stored user ID is transmitted to the server without allocating a new client public key.
  • the server generates a link key and a MAC value using the received client public key (S21070).
  • the MAC value may be referred to as a MAC key.
  • the MAC value is obtained using the link key.
  • the server may generate a link key using an advanced encryption standard (AES) -cipher-based message authentication code (CMAC) algorithm as shown in Equation 2 below.
  • AES advanced encryption standard
  • CMAC message authentication code
  • the server may generate an encryption key using the AES-CMAC algorithm as shown in Equation 3 below using the obtained link key.
  • the server may generate encrypted data and MAC value using the obtained encryption key as shown in Equation 4 below.
  • the MAC value of the server corresponds to MAC_s.
  • the server generates a link key and MAC value and sends a message to the client that includes the server public key.
  • the client generates a link key and a MAC value using the received server public key (S21090).
  • the client may generate a link key using the AES-CMAC algorithm as shown in Equation 5 below.
  • the client may generate an encryption key by applying the obtained link key to Equation 4 described above.
  • the client may generate encrypted data and MAC value by using the obtained encryption key as shown in Equation 6 below.
  • the MAC value of the client corresponds to MAC_c.
  • the client and server each obtain a MAC value.
  • the client then sends a confirmation message to the server that the device registration is complete.
  • the temporary ID of the user is stored as a user ID.
  • FIG. 22 illustrates an example of a flowchart including a procedure of transmitting a message indicating an interaction scheme before a registration session procedure as an example of the UAS procedure proposed in the present specification.
  • the UA client and the server UA server form a BLE connection state (S22010).
  • the client may transmit a message including an authentication method to be used in the UAS procedure to the server (S22030). This message may be referred to as an interaction method message. Thereafter, the client and the server perform a registration session procedure (S22040).
  • the client can determine how to perform authentication based on the received server's UAS functional characteristics. Thereafter, the client may transmit an interaction message including a user authentication method and / or a device interaction method to the server (S22030). That is, the client may determine the authentication method based on the UAS functional characteristics.
  • the user authentication procedure refers to the description relating to Fig. 21 described above as a user interaction procedure. Details of the device authentication procedure will be described later.
  • the server performs an authentication session procedure with the client based on the authentication method included in the received interaction message (S22060).
  • FIG. 23 illustrates an example of a flowchart showing a point at which a client and a server may obtain a user input in a UAS procedure proposed in the present specification.
  • FIG. 23 shows each message of the flowchart shown in FIG. 13 using the ATT protocol.
  • a user may perform user input on a server device or a client device in a UAS procedure.
  • the user input corresponds to information that a user performs a specific operation such as a password input to the device, clicks a confirmation button, inputs a pattern, or obtains information therefrom.
  • the type of user input may be determined based on the input / output capability of the device.
  • a user may perform user input on one or more of the server device or client device.
  • the client may start the registration session procedure by obtaining a user input for starting the registration session from the user, and then sending a write request message requesting the start of the registration session procedure (S23010).
  • This procedure may be performed in the same manner as in step S14010 of FIG. 14 described above.
  • the server may perform user authentication by obtaining a user input from the user.
  • the user input may correspond to user identification information.
  • the server may obtain user identification information and generate data to be used for user authentication.
  • the type of user identification information may be determined based on the input / output capability of the device. For details on user authentication and user identification information, refer to the description associated with FIG. 21 described above.
  • the client receives a notification message including a server public key (S23050). This procedure may be performed in the same manner as in step S140110 of FIG. 14 described above. Thereafter, a user input for confirming device authentication can be obtained from the user. After the server transmits the server public key message to the client (S23050), the server may obtain a user input for confirming device authentication from the user. The device authentication confirmation may be performed based on a user input and a result generated by the user exchanging public keys between the devices.
  • FIG. 24 illustrates an example of a flowchart showing a point at which a user input can be obtained from a server in the UAS procedure proposed in the specification.
  • FIG 24 illustrates a case in which the user performs user input only on the server device side. In this case, the user does not control the client device.
  • the server may obtain a user input requesting the start of a registration session from the user. Thereafter, the server transmits a notification message requesting the start of a registration session to the client (S24010). This notification message may be referred to as a Start Registration Session message.
  • the client may transmit a start message to the server after receiving the start registration session message (S24020). This procedure may be performed in the same manner as in step S14010 of FIG. 14 described above.
  • the server sends a server hash commit message (Server Hash Commit Message) to the client (S24030). This procedure may be performed in the same manner as in S14030 of FIG. 14 described above.
  • the server can then obtain user input for performing user authentication.
  • the server may receive a command message including data obtained by the client using the exchanged public key (S24060).
  • This message may be referred to as an Authentication Value Message.
  • the authentication value message may include a MAC_c generated by the client. The server can then obtain user input confirming device authentication from the user.
  • 25 is an example of a registration session procedure flowchart including a device authentication procedure proposed herein.
  • the device authentication procedure may be referred to as a confirm user interaction, a device authentication, a device interaction, or a device authentication interaction.
  • the device authentication procedure is performed at the server and the client, respectively.
  • the server transmits a server public key message to the client and then performs a confirm user interaction procedure (S25080). After receiving the server public key message and acquiring the MAC value in the manner described above with reference to FIG. 21, the client performs a confirmation user interaction procedure (S25090).
  • 26 illustrates another example of a flowchart of a registration session procedure including a device authentication procedure proposed in the specification.
  • the server receives a registration start message (S26010) and performs a user interaction procedure (S26020). Thereafter, the server transmits a user interaction completion message including the temporary user ID to the client (S26030).
  • the procedure of receiving a start message, performing a user interaction procedure, and transmitting a user interaction completion message may be performed in the same manner as described above with reference to S14010 of FIG. 14, S21040 of FIG. 21, and S14060 of FIG. 14, respectively.
  • the server After the server transmits the user interaction completion message, the server receives a write request message including the client public key from the client (S26040).
  • This write request message may be referred to as a Registration Client Public Key message.
  • the write request message includes I / O capability information of the client. For example, if the client device includes a display, the write request message includes information indicating that the client has display input / output capability.
  • the server acquires a first value (Value 1) through a first algorithm having the obtained public key of the client as an input value (S26050).
  • a first algorithm having the obtained public key of the client as an input value (S26050).
  • the first algorithm is represented by f1
  • the server After acquiring the first value, the server transmits a notification message including the server public key to the client (S26060).
  • This notification message may be referred to as a Registration Server Public Key message.
  • this notification message includes the input / output capability information of the server. For example, if the server device includes an LED, the notification message includes information indicating that the server has LED output capability.
  • the client acquires a first value (Value 1) through a specific algorithm having the obtained server public key as an input value (S26070).
  • the specific algorithm used by the client corresponds to the same algorithm as the first algorithm used by the server.
  • the client obtains the same value as the value obtained by the server through the first algorithm f1.
  • each device acquires input / output information of the counterpart device by exchanging input / output capability information with the counterpart device.
  • Each device may use this to perform a confirmation interaction procedure to be described later. Therefore, each device can perform authentication by selecting an appropriate method according to the acquired input and output information.
  • Table 6 shows an example of a device interaction type used for device authentication and a device action according to each type.
  • the client and the server may present the output corresponding to the above-described first value by using a device interaction type supported by each device.
  • the server may output information corresponding to the first value 1 obtained using the public key of the client through the output unit.
  • the output method may be determined based on at least one of an output capability of the server and a device interaction type supported by the server. For example, when the output of the server device is an LED and the device interaction type is LED Blinking of Table 6, the server may blink an LED of a color corresponding to the first value.
  • the client may output information corresponding to the first value obtained using the server public key through the output unit.
  • the output method may be determined according to the output capability of the client and / or the device interaction type supported by the client. For example, when the output of the client device is a display and the device interaction type is a pin of Table 6, the client may indicate “123456” corresponding to the first value on the display.
  • the server transmits a server public key message to the client and then performs a confirmation user interaction procedure for authenticating the device (S26080).
  • the confirmation user interaction procedure corresponds to a device authentication procedure.
  • the device authentication procedure is a procedure of authenticating a device after user authentication for device registration in a registration session procedure.
  • the server obtains input information related to device authentication from the user.
  • Input information is information about a particular input that a user has made to a server device.
  • the server may obtain, as input information, a specific pattern input by the user on the display of the server device.
  • the input information acquired by the server may correspond to information about an input performed by the user on the server device based on the output corresponding to the first value output from the client device. For example, if the server has a pattern input capability, the user may check the pattern shown on the display of the client device and input the same pattern as the pattern into the server device. At this time, the server obtains the pattern information as input information.
  • the server obtains a second value by using a second algorithm on the obtained input information.
  • the second algorithm corresponds to an algorithm different from the first algorithm described above.
  • the manner of applying the second algorithm may be represented by (Interaction Method (LED) ⁇ -f2 (Value1)).
  • the server may determine whether the device authentication is successful by comparing the first value obtained by using the first algorithm and the second value obtained by using the second algorithm. If the first value and the second value match, the server may determine that authentication succeeds, and if it does not match, the server may determine that authentication fails.
  • the client may perform device authentication by comparing the first value and the second value obtained by using the same method as that performed in the above-described server.
  • the device may be authenticated by performing confirmation user interaction in the client and the server, respectively.
  • the server or client may separately indicate whether authentication is successful, and in this case, the display method may be determined based on the output capability of the device.
  • Device Authentication Confirmation is a procedure for confirming that device authentication is successful and may be performed by a user in a server or a client based on a type of device or an input / output capability.
  • the device authentication confirmation procedure is included in the device authentication procedure. Each device may obtain confirmation information confirming the device authentication.
  • the server may obtain a user input for confirming device authentication. For example, the user may confirm that the user is authenticated based on the output result displayed on each device of the server and the client, and complete the device authentication by clicking the confirmation button of the input unit of the server device. In this case, the server obtains device authentication confirmation information generated by the user clicking the confirmation button.
  • the obtaining method related to the device authentication confirmation may be determined based on the input capability of the server.
  • the client transmits a client confirmation message, which is a write request message including the number of the confirmation user interaction procedure and information indicating the device authentication result, to the server (S26100).
  • This procedure may be performed in the same manner as step 140130 of FIG. 14 described above.
  • the server may complete the server authentication procedure based on the write request message indicating whether the client device has successfully authenticated from the client.
  • Table 7 below shows an example of ways of performing device interaction.
  • DA_value represents a value obtained by the client using a public key.
  • Method # 1 The client generates a unique pattern using the DA_value and displays the generated pattern. The user inputs the same pattern as the pattern displayed on the client device Device A to the server device.
  • Method # 2 The client generates a vibration using a DA_value.
  • the server device displays the number of vibrations.
  • Method # 3 (Method # 3): The client generates a LED blink using the DA_value. The server device displays the color of the blinking LED.
  • device interaction may be performed in various ways according to the function of each device.
  • the server stores the temporary user ID as a user ID (S26110).
  • FIG. 27 illustrates an example of a device-to-device initial authentication procedure, in which a user interaction authentication procedure is performed in a server, and a server and a client respectively obtain user input.
  • the server and client can each obtain user input.
  • User input represents specific information obtained by the device for user authentication or device authentication.
  • the user input is associated with one of information requesting to start authentication, user identification information, and information related to device authentication.
  • the client obtains a user input requesting the start or registration start of the user authentication procedure. For example, when the user presses the authentication start button, the client device transmits a message requesting to start the authentication procedure (S27010). This procedure may be performed in the same manner as in step S14010 of FIG. 14 described above.
  • the server obtains user identification information as a user input in a user interaction authentication procedure S27020.
  • the remaining procedure may be performed in the same manner as the procedure disclosed in the description associated with FIGS. 21 to 26 described above.
  • FIG. 28 illustrates an example of a device-to-device initial authentication procedure, in which a user interaction authentication procedure is performed in a client and a server and a client respectively obtain input of a user.
  • User authentication may be performed in the client rather than the server based on the input / output capability of each device.
  • the server acquires a user input for requesting to start user authentication, and indicates that the server has obtained a related user input, and transmits a message to the client to request user authentication to start (S28010).
  • This message may be referred to as a User Authentication Start message.
  • the authentication can be requested by pressing the start authentication button on the server device.
  • the client obtains user identification information as a user input and performs a user interaction authentication procedure (S28020).
  • the user interaction authentication procedure performed at the client may be performed in the same manner as the user interaction authentication procedure S21040 performed at the server described above with reference to FIG. 21.
  • the remaining procedure may be performed in the same manner as the procedure disclosed in the description associated with FIGS. 21 to 26 described above.
  • 29 illustrates an example of a device-to-device initial authentication procedure, in which a user interaction authentication procedure is performed in a server and the server acquires a user input.
  • the registration session can be started without sending or receiving a message requesting to start the authentication procedure.
  • the user can perform user input only on the server.
  • the server first obtains user identification information as a user input, and performs a user interaction authentication procedure (S29010). This procedure may be performed in the same manner as the S21040 procedure of FIG. 21 described above. Thereafter, the server transmits a user authentication confirmation message to the client indicating that the user authentication has been performed at the server (S29020).
  • the remaining procedure may be performed in the same manner as the procedure disclosed in the description associated with FIGS. 21 to 26 described above.
  • FIG. 30 illustrates an example of an initial device-to-device authentication procedure, in which a user interaction authentication procedure is performed in a client and the client acquires a user input.
  • user authentication may be performed in the client rather than the server based on the input / output capability of each device.
  • the client acquires user identification information and performs user interaction authentication (S30010). After user interaction authentication, the client transmits a message requesting the start of the authentication procedure to the server (S30020). This procedure may be performed in the same manner as in step S14010 of FIG. 14 described above.
  • the remaining procedure may be performed in the same manner as the procedure disclosed in the description associated with FIGS. 21 to 26 described above.
  • 31 shows an example of performing authentication after an initial authentication procedure between devices.
  • the client performs user interaction authentication by using the obtained user identification information (S31010), and transmits a message requesting one token transmission required for a secure session to the server (S31020).
  • This message may be referred to as a Secure Get Token Value message.
  • the server sends a response message to the client to the security token acquisition message (S31030).
  • This message may be referred to as a Response to Secure Get Token Value message.
  • 32 shows another example of performing authentication after an initial authentication procedure between devices.
  • the server acquires user identification information as a user input and performs user interaction authentication (S32010). Thereafter, the server transmits a message indicating that the user performed authentication through the server after the initial authentication to the client (S32020). This message may be referred to as a Secure User Confirmation message. Authentication is completed (Authentication Complete) through the above-described procedure (S32030).
  • FIG. 33 illustrates an example of authenticating by using a user's biometric information of a device and a user's Bluetooth connection in the process of Bluetooth authentication.
  • the user searches for a specific device to be connected with Bluetooth while wearing a wearable device capable of Bluetooth communication.
  • the wearable device may be a life band, and the other device may be a TV, a smart device, or the like.
  • a separate controller can be a remote control, in which case the user controls the controller to discover the device.
  • both devices If the Bluetooth connection between both devices is not the first connection, both devices immediately establish a Bluetooth connection. At this time, Bluetooth of each device should be enabled.
  • both devices exchange authentication information for authentication.
  • the authentication information may be generated using user identification information identifying the user.
  • the type of identification information may be determined based on the function of the wearable device.
  • the identification information may be biometric information of the user.
  • the device may generate and exchange authentication information using information such as an electroencephalogram (EEG), a heart rate, a fingerprint, and the like.
  • EEG electroencephalogram
  • Both devices check that the exchanged authentication information is the same, and if they match, a Bluetooth connection is established. In this case, both devices may display an indication indicating a connection success and transmit a message indicating authentication success to the counterpart device.
  • the Bluetooth connection is not formed if the authentication information is not the same.
  • both devices may display an indication indicating connection failure or transmit a message indicating authentication failure to the counterpart device.
  • 34 illustrates an example of a method of performing an authentication procedure in both devices using a pattern input.
  • Users A, B, and C are separate users. Frequently A is an administrator. User B wants to establish a Bluetooth connection with the printer device using the smart device. If the user is not an administrator, the device may be set so that the user can use only limited functions after the Bluetooth connection is made. For example, device functionality may be limited so that non-administrator users can only use black and white output.
  • User B first performs user authentication using a pattern that only he knows.
  • the smart device generates the ID of user B based on the pattern to perform authentication with the print device.
  • the smart device generates a new ID when the user B is a person who first performs Bluetooth authentication that is not registered in the smart device, and uses a pre-assigned ID when the user B is a registered user.
  • Initial registration is performed on the smart device and the print device.
  • the print device obtains a specific value through a specific algorithm f1 using the key exchanged through the above-described public key transmission / reception procedure.
  • the print device obtains 748 as a specific value and outputs a corresponding pattern on the display.
  • the user checks the pattern displayed on the printer device and inputs the same pattern into the smart device.
  • the smart device acquires a corresponding value from the input pattern, and completes authentication (success) when the value obtained from the pattern and the value generated by the key exchange are the same. After authentication is completed, the devices are connected to each other.
  • 35 shows an example of a flowchart in which the server performs authentication for device registration.
  • the first device corresponds to a server device
  • the second device corresponds to a client device.
  • the server device forms a Bluetooth LE connection with the client (S35010). This step may be performed in the same manner as in step S13010 of FIG. 13 described above.
  • the server device obtains identification information for identifying a user (S35020).
  • the server device performs a user authentication procedure for authenticating a user based on the identification information (S35030). This procedure may be performed in the same manner as in S21040 of FIG. 21 described above.
  • the server device transmits a first notification message including an identifier corresponding to the identification information to the client device (S35040). This procedure may be performed in the same manner as in step S14060 of FIG. 14 described above.
  • the server device receives a write request message including a first public key (client's public key) from the client device (S35050).
  • This write request message includes input / output capability information of the client device. For details, refer to the description associated with FIG. 26 described above.
  • the server device obtains a first value for authentication of the client device using a first algorithm having the first public key as an input value (S35060). For details, refer to the description associated with FIG. 26 described above.
  • the server device transmits a notification message including the second public key (public key of the server) to the client device (S35070).
  • This notification message contains the input / output capability information of the server device. For details, refer to the description associated with FIG. 26 described above.
  • the server device performs a device authentication procedure for authenticating the client device using a specific authentication method (S35080). For details, refer to the description associated with FIG. 26 described above.
  • 36 shows an example of a flowchart in which a client performs authentication for device registration.
  • the first device corresponds to a client device and the second device corresponds to a server device.
  • the client device forms a Bluetooth LE connection with the server device (S36010). This step may be performed in the same manner as in step S13010 of FIG. 13 described above.
  • the client device transmits a write request message requesting to start the authentication procedure to the server device (S36020). This step may be performed in the same manner as in step S14010 of FIG. 14 described above.
  • the client device receives a notification message including an identifier corresponding to the identification information of the user from the server device (S36030). This step may be performed in the same manner as in step S14060 of FIG. 14 described above.
  • the client device transmits a write request message including a first public key (client's public key) to the server device (S36040).
  • This write request message includes input and output information of the client device. For details, refer to the description associated with FIG. 26 described above.
  • the client device receives a notification message including a second public key (public key of the server) from the server device (S36050).
  • This notification message contains the input / output information of the server device.
  • the client device obtains a first value for authentication of the server device using a first algorithm having a first public key as an input value (S36060). For details, refer to the description associated with FIG. 26 described above.
  • the client device performs a device authentication procedure for authenticating the server device using a specific authentication method (S36070). For details, refer to the description associated with FIG. 26 described above.
  • the client device transmits a write request message indicating a result of the device authentication procedure to the server device (S36080). This procedure may be performed in the same manner as in S25100 of FIG. 25 described above.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Power Engineering (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)

Abstract

블루투스 기술을 사용하는 장치의 인증 방법 및 장치를 개시한다. 본 발명의 실시예에 따른 블루투스 LE(Low Energy)를 이용하여 제1 디바이스가 인증을 수행하는 방법은, 사용자의 식별 정보에 기초하여 사용자 인증을 수행하고, 교환된 공개 키를 사용하여 획득한 정보 및 사용자 입력으로부터 획득한 정보를 비교함으로써 디바이스 인증을 수행한다. 디바이스 인증 방식은 디바이스의 입출력 능력에 따라 결정된다.

Description

블루투스 기술을 사용하는 장치의 인증 방법 및 장치
본 발명은 무선 통신시스템에서 근거리 기술인 블루투스에 관한 것으로써, 보다 상세하게 블루투스 저 전력 에너지 기술(Low Energy)을 이용하여 디바이스가 인증 절차를 수행하기 위한 방법 및 장치에 관한 것이다.
블루투스는 근거리에서 각종 디바이스들을 무선으로 연결하여 데이터를 주고 받을 수 있는 근거리 무선 기술 규격이다. 블루투스(Bluetooth) 통신을 이용하여 두 기기간 무선 통신을 수행하고자 하는 경우, 사용자(User)는 통신하고자 하는 블루투스(Bluetooth) 디바이스(Device)들을 검색(Discovery)하고 연결(Connection)을 요청하는 절차를 수행한다. 본 발명에서 디바이스는 기기, 장치를 의미할 수 있다.
이때, 사용자는 블루투스 디바이스를 이용하여 사용하고자 하는 블루투스 통신방법에 기초하여 블루투스 디바이스를 검색한 후 연결을 수행할 수 있다.
블루투스 통신방법에는 BR/EDR (Basic Rate/Enhanced Data Rate)방식과 저전력 방식인 LE (Low Energy)방식이 있다. BR/EDR 방식은 블루투스 클래식 (Bluetooth Classic)라고 호칭될 수 있다. 블루투스 클래식 방식은 베이직 레이트(Basic Rate)를 이용하는 블루투스 1.0부터 이어져온 블루투스 기술과 블루투스 2.0에서부터 지원되는 인핸스드 데이터 레이트(Enhanced Data Rate)를 이용하는 블루투스 기술을 포함한다.
블루투스 저전력 에너지(Bluetooth Low energy, 이하 블루투스 LE라고 한다.)기술은 블루투스 4.0부터 적용되어 적은 전력을 소모하여 수백 키로바이트(KB)의 정보를 안정적으로 제공할 수 있다. 이러한 블루투스 저전력 에너지 기술은 속성 프로토콜(Attribute Protocol)을 활용해서 디바이스(Device) 간 정보를 교환하게 된다. 이러한 블루투스 LE 방식은 헤더의 오버헤드(overhead)를 줄이고 동작을 간단하게 해서 에너지 소비를 줄일 수 있다.
블루투스 기기들 중에는 디스플레이(Display)나 유저인터페이스(User Interface)가 없는 제품들도 있다. 다양한 종류의 블루투스 기기들과 그 중에서도 유사기술이 적용된 블루투스 기기들 간의 연결 / 관리 / 제어 / 분리 (Connection / Management / Control / Disconnection)의 복잡도가 증가하고 있다.
또한, 블루투스는 비교적 저전력, 저비용으로 비교적 빠른 속도를 낼 수 있으나, 전송 거리가 일반적으로 최대 100m로 한정적이므로, 한정된 공간에서 사용하기 적합하다.
본 발명은, 블루투스 기술을 이용하여 디바이스를 인증하기 위한 방법 및 장치를 제공함에 그 목적이 있다.
또한, 본 발명은 블루투스 연결을 위해서 사용자의 정보를 이용하여 디바이스를 인증하기 위한 방법 및 장치를 제공함에 그 목적이 있다.
또한, 본 발명은 블루투스 연결을 위해서 사용자의 식별 정보에 기초하여 사용자를 인증하기 위한 방법 및 장치를 제공함에 목적이 있다.
또한, 본 발명은 디바이스의 입/출력 기능에 기초하여 서로 다른 방식을 통해 디바이스를 인증하기 위한 방법 및 장치를 제공함에 그 목적이 있다.
본 명세서에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명은 상술한 문제점을 해결하기 위한 블루투스 기술을 이용하여 디바이스의 인증을 수행하는 방법을 제공한다.
상술한 기술적 과제를 해결하기 위하여, 본 발명의 실시예에 따른 블루투스 LE(Low Energy)를 이용하여 제1 디바이스가 인증을 수행하는 방법은, 제2 디바이스와 블루투스 LE 연결을 형성하는 단계; 사용자를 식별하기 위한 식별 정보를 획득하는 단계; 상기 식별 정보에 기초하여 상기 사용자를 인증하는 사용자 인증 절차를 수행하는 단계; 상기 식별 정보에 대응하는 식별자가 포함된 제1 통지 메시지를 상기 제2 디바이스로 전송하는 단계; 상기 제2 디바이스로부터 제1 공개 키(Public Key)를 포함하는 기입 요청 메시지를 수신하는 단계; 상기 제1 공개 키를 입력 값으로 갖는 제1 알고리즘을 사용하여 상기 제2 디바이스의 인증을 위한 제1 값을 획득하는 단계; 상기 제2 디바이스로 제2 공개 키를 포함하는 제2 통지 메시지를 전송하는 단계; 및 특정 인증 방식을 사용하여 상기 제2 디바이스를 인증하기 위한 디바이스 인증 절차를 수행하는 단계를 포함하고, 상기 특정 인증 방식은 상기 제1 디바이스의 입출력 능력에 따라 결정된다.
본 발명의 실시예에 따른 인증 수행 방법에 있어서, 상기 기입 요청 메시지는 상기 제2 디바이스의 입출력 능력 정보를 포함하고, 상기 제2 통지 메시지는 상기 제1 디바이스의 입출력 능력 정보를 포함한다.
본 발명의 실시예에 따른 인증 수행 방법에 있어서, 상기 디바이스 인증 절차를 수행하는 단계에 있어서, 상기 특정 인증 방식을 사용하여 상기 제1 값에 대응되는 특정 정보를 출력하는 단계; 및 상기 특정 정보의 출력에 기초하여 상기 제2 디바이스를 인증하기 위한 입력 정보를 획득하는 단계를 포함한다.
본 발명의 실시예에 따른 인증 수행 방법에 있어서, 상기 디바이스 인증 절차를 수행하는 단계에 있어서, 상기 입력 정보에 기초하여 제2 알고리즘을 통해 제2 값을 획득하는 단계; 및 상기 제1 값 및 상기 제2 값에 기초하여 상기 제2 디바이스의 인증을 완료하는 단계를 포함한다.
본 발명의 실시예에 따른 인증 수행 방법에 있어서, 상기 디바이스 인증을 완료하는 단계에 있어서, 상기 디바이스 인증은 상기 제1 값 및 상기 제2 값의 일치 여부에 따라 인증 성공 여부가 결정된다.
본 발명의 실시예에 따른 인증 수행 방법에 있어서, 상기 디바이스 인증 절차는 PIN, 패스워드, 패턴, 진동, 문장 및 LED 중 하나의 방식을 사용한다.
본 발명의 실시예에 따른 인증 수행 방법에 있어서, 상기 식별 정보는 PIN, 제스처, 패턴, 패스워드 및 상기 사용자의 생체정보 중 하나이다.
본 발명의 실시예에 따른 인증 수행 방법에 있어서, 상기 사용자가 상기 제1 디바이스의 새로운 사용자인 경우 임시 식별자를 할당하는 단계, 및 상기 임시 식별자를 상기 사용자의 상기 식별자로 저장하는 단계를 더 포함한다.
본 발명의 실시예에 따른 인증 수행 방법에 있어서, 상기 제2 디바이스로부터 상기 사용자 인증 절차 또는 상기 디바이스 인증 절차의 수행 방식을 포함하는 인증 방식 결정 메시지를 수신하는 단계를 더 포함하고, 상기 수행 방식은 상기 제2 디바이스에 의해 지정된다.
상술한 기술적 과제를 해결하기 위하여, 본 발명의 실시예에 따른 블루투스 LE(Low Energy)를 이용하여 제1 디바이스가 인증을 수행하는 방법은, 제2 디바이스와 블루투스 LE 연결을 형성하는 단계; 상기 제2 디바이스로 인증 절차의 시작을 요청하는 기입 요청 메시지를 전송하는 단계; 상기 제2 디바이스로부터 사용자의 식별 정보에 대응하는 식별자가 포함된 통지 메시지를 수신하는 단계; 상기 제2 디바이스로 제1 공개 키(Public Key)가 포함된 기입 요청 메시지를 전송하는 단계; 상기 제2 디바이스로부터 제2 공개 키가 포함된 통지 메시지를 수신하는 단계; 상기 제2 공개 키를 입력 값으로 갖는 제1 알고리즘을 사용하여 상기 제2 디바이스의 인증을 위한 제1 값을 획득하는 단계; 특정 인증 방식을 사용하여 상기 제2 디바이스를 인증하기 위한 디바이스 인증 절차를 수행하는 단계; 및 상기 제2 디바이스로 상기 디바이스 인증 절차의 결과를 나타내는 기입 요청 메시지를 전송하는 단계를 포함하고, 상기 특정 인증 방식은 상기 제1 디바이스의 입출력 능력에 따라 결정된다.
상술한 기술적 과제를 해결하기 위한 본 발명의 실시예에 따른 블루투스 LE(Low Energy)를 이용하여 인증을 수행하기 위한 제1 디바이스는, 제2 디바이스와 블루투스 LE 연결을 형성하고, 사용자를 식별하기 위한 식별 정보를 획득하고, 상기 식별 정보에 기초하여 상기 사용자를 인증하는 사용자 인증 절차를 수행하고, 상기 식별 정보에 대응되는 식별자가 포함된 제1 통지 메시지를 상기 제2 디바이스로 전송하고, 상기 제2 디바이스로부터 제1 공개 키(Public Key)를 포함하는 기입 요청 메시지를 수신하고, 상기 제1 공개 키를 입력 값으로 갖는 제1 알고리즘을 사용하여 상기 제2 디바이스의 인증을 위한 제1 값을 획득하고, 상기 제2 디바이스로 제2 공개 키를 포함하는 제2 통지 메시지를 전송하고, 특정 인증 방식을 사용하여 상기 제2 디바이스를 인증하기 위한 디바이스 인증 절차를 수행하고, 상기 특정 인증 방식은 상기 제1 디바이스의 입출력 능력에 따라 결정된다.
본 발명의 일 실시예에 따른 블루투스 기술을 이용하여 디바이스를 인증하기 위한 방법 및 장치에 따르면, 디바이스의 연결을 위한 인증 절차를 수행할 수 있는 효과가 있다.
또한, 본 발명에 따르면, 블루투스 연결을 위해 사용자의 정보를 이용하여 디바이스를 인증할 수 있는 효과가 있다.
또한, 본 발명에 따르면 디바이스의 입/출력 기능에 따라 다른 방식을 통해 디바이스를 인증함으로써 직관적으로 인증 절차를 인식할 수 있는 효과가 있다.
본 명세서에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 명세서에서 제안하는 블루투스 저전력 에너지 기술을 이용하는 무선 통신 시스템의 일 예를 나타낸 개략도이다.
도 2는 본 명세서에서 제안하는 방법들을 구현할 수 있는 디바이스의 내부 블록도의 일 예를 나타낸다.
도 3은 블루투스 저전력 에너지 토폴로지(Topology)의 일 예를 나타낸다.
도 4는 본 명세서에서 제안하는 방법들이 적용될 수 있는 블루투스 통신 아키텍처(Architecture)의 일 예를 나타낸 도이다.
도 5는 블루투스 저전력 에너지의 GATT(Generic Attribute Profile)의 구조의 일 예를 나타낸 도이다.
도 6은 블루투스 저전력 에너지 기술에서 연결 절차 방법의 일 예를 나타내는 흐름도이다.
도 7 및 도 8은 본 명세서에서 제안하는 방법들이 적용될 수 있는 인증 방법의 일 예를 나타낸 도이다.
도 9는 복수의 블루투스 디바이스를 인증 및 제어하는 방식의 일 예를 나타낸다.
도 10은 블루투스 저전력 에너지 기술의 사용자 인증 서비스에서 디바이스 간 인증을 위한 절차의 일 예를 나타낸다.
도 11은 클라이언트와 서버가 서버의 UAS 기능을 포함하는 메시지를 송수신하는 절차를 포함하는 흐름도의 일 예를 나타낸다.
도 12는 UAS 기능 획득 메시지 및 UAS 기능 메시지의 필드와 각 필드의 정보의 일 예를 나타낸다.
도 13은 사용자 인증 서비스 프로토콜 절차 흐름도의 일 예를 나타낸다.
도 14는 등록 세션 시작 시퀀스 흐름도의 일 예를 나타낸다.
도 15는 도 14에 개시된 등록 세션 시작 시퀀스 흐름도를 간략히 나타낸 흐름도의 일 예를 나타낸다.
도 16은 시작 메시지의 필드 및 각 필드의 정보의 일 예를 나타낸다.
도 17은 서버 해시 커밋 메시지의 필드 및 각 필드의 정보의 일 예를 나타낸다.
도 18은 클라이언트 공개 키 메시지의 필드 및 각 필드의 정보의 일 예를 나타낸다.
도 19는 서버 공개 키 메시지의 필드 및 각 필드의 정보의 일 예를 나타낸다.
도 20은 클라이언트 확인 메시지와 중단 메시지의 필드 및 각 필드의 정보의 일 예를 나타낸다.
도 21은 사용자를 인증하는 유저인터렉션 절차를 포함하는 등록 세션 절차의 흐름도의 일 예를 나타낸다.
도 22는 본 명세서에서 제안하는 UAS 절차의 일 예로서, 등록 세션 절차 전 인터렉션 방식을 나타내는 메시지가 전송되는 절차가 포함된 흐름도의 일 예를 나타낸다.
도 23은 본 명세서에서 제안하는, UAS 절차에서 클라이언트와 서버가 사용자 의 입력을 획득할 수 있는 지점을 나타낸 흐름도의 일 예를 나타낸다.
도 24는 본 명세서에서 제안하는, UAS 절차에서 서버에 사용자의 입력을 획득할 수 있는 지점을 나타낸 흐름도의 일 예를 나타낸다.
도 25는 본 명세서에서 제안하는 디바이스 인증 절차를 포함하는 등록 세션 절차 흐름도의 일 예를 나타낸다.
도 26은 본 명세서에서 제안하는 디바이스 인증 절차를 포함하는 등록 세션 절차의 흐름도의 다른 예를 나타낸다.
도 27은 디바이스간 최초 인증 절차의 일 예로서, 서버에서 유저인터렉션 인증 절차가 수행되고 서버 및 클라이언트가 각각 사용자의 입력을 획득하는 경우를 나타낸다.
도 28은 디바이스간 최초 인증 절차의 일 예로서, 클라이언트에서 유저인터렉션 인증 절차가 수행되고 서버 및 클라이언트가 각각 사용자의 입력을 획득하는 경우를 나타낸다.
도 29는 디바이스간 최초 인증 절차의 일 예로서, 서버에서 유저인터렉션 인증 절차가 수행되고 서버가 사용자의 입력을 획득하는 경우를 나타낸다.
도 30은 디바이스간 최초 인증 절차의 일 예로서, 클라이언트에서 유저인터렉션 인증 절차가 수행되고 클라이언트가 사용자의 입력을 획득하는 경우를 나타낸다.
도 31은 디바이스간 최초 인증 절차 후 인증을 수행하는 일 예를 나타낸다.
도 32는 디바이스간 최초 인증 절차 후 인증을 수행하는 다른 예를 나타낸다.
도 33은 블루투스 인증 과정에서 사용자가 블루투스 연결을 원하는 디바이스와 사용자의 생체 정보를 이용하여 인증을 수행하는 일 예를 나타낸다.
도 34는 패턴 입력을 사용하여 양 디바이스에서 인증 절차를 수행하는 방식의 일 예를 나타낸다.
도 35는 서버가 디바이스 등록을 위한 인증을 수행하는 순서도의 일 예를 나타낸다.
도 36은 클라이언트가 디바이스 등록을 위한 인증을 수행하는 순서도의 일 예를 나타낸다.
본 발명의 상술한 목적, 특징들 및 장점은 첨부된 도면과 관련된 다음의 상세한 설명을 통해 보다 분명해질 것이다. 다만, 본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시 예들을 가질 수 있는 바, 이하에서는 특정 실시 예들을 도면에 예시하고 이를 상세히 설명하고자 한다. 명세서 전체에 걸쳐서 동일한 참조번호들은 원칙적으로 동일한 구성요소들을 나타낸다. 또한, 본 발명과 관련된 공지 기능 혹은 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 또한, 첨부된 도면은 본 발명의 사상을 쉽게 이해할 수 있도록 하기 위한 것일 뿐, 첨부된 도면에 의해 본 발명의 사상이 제한되는 것으로 해석되어서는 아니 됨을 유의해야 한다.
이하, 본 발명과 관련된 방법 및 장치에 대하여 도면을 참조하여 보다 상세하게 설명한다. 또한, 본 발명에서 사용되는 일반적인 용어는 사전에 정의되어 있는 바에 따라, 또는 전후 문맥상에 따라 해석되어야 하며, 과도하게 축소된 의미로 해석되지 않아야 한다. 또한, 본 명세서에서 사용되는 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "구성된다" 또는 "포함한다" 등의 용어는 명세서 상에 기재된 여러 구성 요소들, 또는 여러 단계들을 반드시 모두 포함하는 것으로 해석되지 않아야 하며, 그 중 일부 구성 요소들 또는 일부 단계들은 포함되지 않을 수도 있고, 또는 추가적인 구성 요소 또는 단계들을 더 포함할 수 있는 것으로 해석되어야 한다. 이하의 설명에서 사용되는 구성요소에 대한 접미사 "모듈" 및 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다.
도 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에 도시된 바와 같이, 서버 디바이스(110)는 출력부(Display Unit, 111), 입력부(User Input Interface, 112), 전력 공급부(Power Supply Unit, 113), 프로세서(Processor, 114), 메모리(Memory Unit, 115), 블루투스 인터페이스(Bluetooth Interface, 116), 다른 통신 인터페이스(Other Interface, 117) 및 통신부(또는 송수신부, 118)를 포함한다.
상기 출력부(111), 입력부(112), 전력 공급부(113), 프로세서(114), 메모리(115), 블루투스 인터페이스(116), 다른 통신 인터페이스(117) 및 통신부(118)는 본 명세서에서 제안하는 방법을 수행하기 위해 기능적으로 연결되어 있다.
또한, 클라이언트 디바이스(120)는 출력부(Display Unit, 121), 입력부(User Input Interface, 122), 전력 공급부(Power Supply Unit, 123), 프로세서(Processor, 124), 메모리(Memory Unit, 125), 블루투스 인터페이스(Bluetooth Interface, 126) 및 통신부(또는 송수신부, 127)를 포함한다.
상기 출력부(121), 입력부(122), 전력 공급부(123), 프로세서(124), 메모리(125), 블루투스 인터페이스(126), 및 통신부(127)는 본 명세서에서 제안하는 방법을 수행하기 위해 기능적으로 연결되어 있다.
상기 블루투스 인터페이스(116,126)는 블루투스 기술을 이용하여 디바이스들 간의 요청/응답, 명령, 알림, 지시/확인 메시지 등 또는 데이터 전송이 가능한 유닛(또는 모듈)을 말한다.
상기 메모리(115,125)는 다양한 종류의 디바이스에 구현되는 유닛으로서, 다양한 종류의 데이터가 저장되는 유닛을 말한다.
상기 프로세서(114,124)는 서버 디바이스(110) 또는 클라이언트 디바이스(120)의 전반적인 동작을 제어하는 모듈을 말하며, 블루투스 인터페이스 및 다른 통신 인터페이스로 메시지를 전송 요청 및 수신받은 메시지를 처리하도록 제어한다.
상기 프로세서(114,124)는 제어부, 제어 유닛(Control Unit), 컨트롤러 등으로 표현될 수 있다.
상기 프로세서(114,124)는 ASIC(application-specific integrated circuit), 다른 칩셋, 논리 회로 및/또는 데이터 처리 장치를 포함할 수 있다.
상기 프로세서(114,124)는 서버 디바이스(110)로부터 광고(Advertising) 메시지를 수신하도록 상기 통신부를 제어하며, 상기 서버 디바이스(110)로 스캔 요청(Scan Request) 메시지를 전송하고, 상기 서버 디바이스(110)로부터 상기 스캔 요청에 대한 응답으로 스캔 응답(Scan Response) 메시지를 수신하도록 상기 통신부를 제어하며, 상기 서버 디바이스(110)와 블루투스 연결 설정을 위해 상기 서버 디바이스(110)로 연결 요청(Connect Request) 메시지를 전송하도록 상기 통신부를 제어한다.
또한, 상기 프로세서(114,124)는 상기 연결 절차를 통해 블루투스 LE 커넥션(Connection)이 형성된 이후, 상기 서버 디바이스(110)로부터 속성 프로토콜을 이용하여 데이터를 읽어오거나(Read), 기록(Write)할 수 있도록 상기 통신부를 제어한다.
상기 메모리(115,125)는 ROM(read-only memory), RAM(random access memory), 플래쉬 메모리, 메모리 카드, 저장 매체 및/또는 다른 저장 장치를 포함할 수 있다.
상기 통신부(118,127)는 무선 신호를 처리하기 위한 베이스밴드 회로를 포함할 수 있다. 실시 예가 소프트웨어로 구현될 때, 상술한 기법은 상술한 기능을 수행하는 모듈(과정, 기능 등)로 구현될 수 있다. 모듈은 메모리에 저장되고, 프로세서에 의해 실행될 수 있다.
상기 메모리(115,125)는 프로세서(114,124) 내부 또는 외부에 있을 수 있고, 잘 알려진 다양한 수단으로 프로세서(114,124)와 연결될 수 있다.
상기 출력부(111,121)는 디바이스의 상태 정보 및 메시지 교환 정보 등을 화면을 통해서 사용자에게 제공하기 위한 모듈을 말한다.
상기 전력 공급부(전원 공급부, 113, 123)는 제어부의 제어 하에 외부의 전원, 내부의 전원을 인가 받아 각 구성요소들의 동작에 필요한 전원을 공급해주는 모듈을 말한다.
앞에서 살핀 것처럼, BLE 기술에서는 작은 duty cycle을 가지며, 저속의 데이터 전송률을 통해 전력 소모를 크게 줄일 수 있다.
상기 입력부(112,122)는 화면 버튼과 같이 사용자의 입력을 제어부에게 제공하여 디바이스의 동작을 사용자가 제어할 수 있게 하는 모듈을 말한다.
도 3은 블루투스 저전력 에너지 토폴로지(Topology)의 일 예를 나타낸다.
도 3을 참조하면, 디바이스 A는 디바이스 B와 디바이스 C를 슬레이브(slave)로 가지는 피코넷(피코넷 A, 음영부분)에서 마스터(master)에 해당한다.
여기서, 피코넷(Piconet)이란, 다수의 디바이스들 중 어느 하나가 마스터이고, 나머지 디바이스들이 마스터 디바이스에 연결되어 있는 공유된 물리 채널을 점유하고 있는 디바이스들의 집합을 의미한다.
BLE 슬레이브는 마스터와 공통 물리 채널을 공유하지 않는다. 각각의 슬레이브는 별개의 물리 채널을 통해 마스터와 통신한다. 마스터 디바이스 F와 슬레이브 디바이스 G를 가지는 또 다른 피코넷(피코넷 F)이 있다.
디바이스 K는 스캐터넷(scatternet K)에 있다. 여기서, 스캐터넷(scatternet)은 다른 피코넷들 간 연결이 존재하는 피코넷의 그룹을 의미한다.
디바이스 K는 디바이스 L의 마스터이면서, 디바이스 M의 슬레이브이다.
디바이스 O 역시 스캐터넷(scatternet O)에 있다. 디바이스 O는 디바이스 P의 슬레이브이면서, 디바이스 Q의 슬레이브이다.
도 3에 도시된 바와 같이, 5개의 다른 디바이스 그룹들이 존재한다.
디바이스 D는 광고자(advertiser)이고, 디바이스 A는 개시자(initiator)이다(그룹 D).
디바이스 E는 스캐너(scanner)이며, 디바이스 C는 광고자이다(그룹 C).
디바이스 H는 광고자이며, 디바이스 I 및 J는 스캐너들이다(그룹 H).
디바이스 K 또한 광고자이며, 디바이스 N은 개시자이다(그룹 K).
디바이스 R은 광고자이며, 디바이스 O는 개시자이다(그룹 R).
디바이스 A와 B는 하나의 BLE 피코넷 물리 채널을 사용한다.
디바이스 A와 C는 또 다른 BLE 피코넷 물리 채널을 사용한다.
그룹 D에서, 디바이스 D는 광고 물리 채널 상으로 연결 가능한 광고 이벤트를 사용하여 광고하며, 디바이스 A는 개시자이다. 디바이스 A는 디바이스 D와 연결을 형성할 수 있고, 피코넷 A로 디바이스를 추가할 수 있다.
그룹 C에서, 디바이스 C는 스캐너 디바이스 E에 의해 캡쳐되는 광고 이벤트의 어떤 타입을 사용하여 광고 물리 채널 상으로 광고를 한다.
그룹 D와 그룹 C는 충돌을 피하기 위해 서로 다른 광고 물리 채널을 사용하거나 다른 시간을 사용할 수 있다.
피코넷 F에는 하나의 물리 채널이 있다. 디바이스 F와 G는 하나의 BLE 피코넷 물리 채널을 사용한다. 디바이스 F는 마스터이고, 디바이스 G는 슬레이브이다.
그룹 H에는 하나의 물리 채널이 있다. 디바이스 H, I 및 J는 하나의 BLE 광고 물리 채널을 사용한다. 디바이스 H는 광고자이며, 디바이스 I 및 J는 스캐너이다.
스캐터넷 K에서, 디바이스 K와 L은 하나의 BLE 피코넷 물리 채널을 사용한다. 디바이스 K와 M은 또 다른 BLE 피코넷 물리 채널을 사용한다.
그룹 K에서, 디바이스 K는 광고 물리 채널 상으로 연결 가능한 광고 이벤트를 사용하여 광고를 하며, 디바이스 N은 개시자이다. 디바이스 N은 디바이스 K와 연결을 형성할 수 있다. 여기서, 디바이스 K는 두 디바이스들의 슬레이브가 되면서 동시에 한 디바이스의 마스터가 된다.
스캐터넷 O에서, 디바이스 O와 P는 하나의 BLE 피코넷 물리 채널을 사용한다. 디바이스 O와 Q는 또 다른 BLE 피코넷 물리채널을 사용한다.
그룹 R에서, 디바이스 R은 광고 물리 채널 상으로 연결 가능한 광고 이벤트를 사용하여 광고를 하며, 디바이스 O는 개시자이다. 디바이스 O는 디바이스 R과 연결을 형성할 수 있다. 여기서, 디바이스 O는 두 디바이스들의 슬레이브가 되면서 동시에 한 디바이스의 마스터가 된다.
도 4는 본 명세서에서 제안하는 방법들이 적용될 수 있는 블루투스 통신 아키텍처(Architecture)의 일 예를 나타낸 도이다.
상기 도 4을 참고하면, 상기 도 4의 (a)는 블루투스 BR(Basic Rate)/EDR(Enhanced Data Rate)의 프로토콜 스택의 일 예를 나타내며, (b)는 블루투스 LE(Low Energy)의 프로토콜 스택의 일 예를 나타낸다.
구체적으로, 도 4의 (a)에 도시된 바와 같이, 블루투스 BR/EDR 프로토콜 스택은 호스트 컨트롤러 인터페이스(Host Controller Interface, HCI, 18)를 기준으로 상부의 컨트롤러 스택(Controller stack, 10)과 하부의 호스트 스택(Host Stack, 20)을 포함할 수 있다.
상기 호스트 스택(또는 호스트 모듈)(20)은 2.4GHz의 블루투스 신호를 받는 무선 송수신 모듈과 블루투스 패킷을 전송하거나 수신하기 위한 하드웨어를 말하며, 상기 컨트롤러 스택(10)인 블루투스 모듈과 연결되어 블루투스 모듈을 제어하고 동작을 수행한다.
상기 컨트롤러 스택(10)은 PHY 계층(12), 링크 컨트롤러 계층(Link Controller, 14), 링크 매니저 계층(Link Manager, 16)을 포함할 수 있다.
상기 PHY 계층(12)은 2.4GHz 무선 신호를 송수신하는 계층으로, GFSK (Gaussian Frequency Shift Keying) modulation을 사용하는 경우 79 개의 RF 채널을 hopping 하여 데이터를 전송할 수 있다.
상기 링크 컨트롤러 계층(14)은 Digital Signal을 전송하는 역할을 담당하며, 초당 1400번 hopping 하는 채널 시퀀스를 선택하며, 각 채널 별 625us 길이의 time slot을 전송한다.
상기 링크 매니저 계층(16)은 LMP(Link Manager Protocol)을 활용하여 블루투스 연결(Bluetooth Connection)의 전반적인 동작(link setup, control, security)을 제어한다.
상기 링크 매니저 계층(16)은 아래와 같은 기능을 수행할 수 있다.
- ACL/SCO logical transport, 논리 링크 셋업(logical link setup) 및 컨트롤(control)을 한다.
- Detach: 연결(connection)을 중단하고, 중단 이유를 상대 디바이스에게 알려준다.
- Power control 및 Role switch를 한다.
- 시큐리티 Security (인증(authentication), 페어링(pairing), 암호화(encryption)) 기능을 수행한다.
상기 호스트 컨트롤러 인터페이스 계층(18)은 Host 모듈과 Controller 모듈 사이의 인터페이스 제공하여 Host 가 command와 Data를 Controller에게 제공하게 하며, Controller가 event와 Data를 Host에게 제공할 수 있도록 해준다.
상기 호스트 스택(또는 호스트 모듈, 20)은 논리적 링크 제어 및 적응 프로토콜(L2CAP, 21), 속성 프로토콜(Protocol, 22), 일반 속성 프로파일(Generic Attribute Profile, GATT, 23), 일반 접근 프로파일(Generic Access Profile, GAP, 24), BR/EDR 프로파일(25)을 포함한다.
상기 논리적 링크 제어 및 적응 프로토콜(L2CAP, 21)은 특정 프로토콜 또는 포로파일에게 데이터를 전송하기 위한 하나의 양방향 채널을 제공할 수 있다.
상기 L2CAP(21)은 블루투스 상위에서 제공하는 다양한 프로토콜, 프로파일 등을 멀티플렉싱(multiplexing)할 수 있다.
블루투스 BR/EDR의 L2CAP에서는 dynamic 채널 사용하며, protocol service multiplexer, retransmission, streaming mode를 지원하고, Segmentation 및 reassembly, per-channel flow control, error control을 제공한다.
상기 일반 속성 프로파일(GATT, 23)은 서비스들의 구성 시에 상기 속성 프로토콜(22)이 어떻게 이용되는지를 설명하는 프로토콜로서 동작 가능할 수 있다. 예를 들어, 상기 일반 속성 프로파일(23)은 ATT 속성들이 어떻게 서비스들로 함께 그룹화되는지를 규정하도록 동작 가능할 수 있고, 서비스들과 연계된 특징들을 설명하도록 동작 가능할 수 있다.
따라서, 상기 일반 속성 프로파일(23) 및 상기 속성 프로토콜(ATT, 22)은 디바이스의 상태와 서비스들을 설명하고, 특징들이 서로 어떻게 관련되며 이들이 어떻게 이용되는지를 설명하기 위하여, 특징들을 사용할 수 있다.
상기 속성 프로토콜(22) 및 상기 BR/EDR 프로파일(25)은 블루트스 BR/EDR를 이용하는 서비스 (profile)의 정의 및 이들 데이터를 주고 받기 위한 application 프로토콜을 정의하며, 상기 일반 접근 프로파일(Generic Access Profile, GAP, 24)은 디바이스 발견, 연결, 및 보안 수준을 정의한다.
상기 도 4의 (b)에 도시된 바와 같이, 블루투스 LE 프로토콜 스택은 타이밍이 중요한 무선장치 인터페이스를 처리하도록 동작 가능한 컨트롤러 스택(Controller stack, 30)과 고레벨(high level) 데이터를 처리하도록 동작 가능한 호스트 스택(Host stack, 40)을 포함한다.
먼저, 컨트롤러 스택(30)은 블루투스 무선장치를 포함할 수 있는 통신 모듈, 예를 들어, 마이크로프로세서와 같은 프로세싱 디바이스를 포함할 수 있는 프로세서 모듈을 이용하여 구현될 수 있다.
호스트 스택은 프로세서 모듈 상에서 작동되는 OS의 일부로서, 또는 OS 위의 패키지(package)의 인스턴스 생성(instantiation)으로서 구현될 수 있다.
일부 사례들에서, 컨트롤러 스택 및 호스트 스택은 프로세서 모듈 내의 동일한 프로세싱 디바이스 상에서 작동 또는 실행될 수 있다.
상기 컨트롤러 스택(30)은 물리 계층(Physical Layer, PHY, 32), 링크 레이어(Link Layer, 34) 및 호스트 컨트롤러 인터페이스(Host Controller Interface, 36)를 포함한다.
상기 물리 계층(PHY, 무선 송수신 모듈, 32)은 2.4 GHz 무선 신호를 송수신하는 계층으로 GFSK (Gaussian Frequency Shift Keying) modulation과 40 개의 RF 채널로 구성된 frequency hopping 기법을 사용한다.
블루투스 패킷을 전송하거나 수신하는 역할을 하는 상기 링크 레이어(34)는 3개의 Advertising 채널을 이용하여 Advertising, Scanning 기능을 수행한 후에 디바이스 간 연결을 생성하고, 37개 Data 채널을 통해 최대 257bytes 의 데이터 패킷을 주고 받는 기능을 제공한다.
상기 호스트 스택은 논리적 링크 제어 및 적응 프로토콜(L2CAP, 41), 보안 매니저(Security Manager, SM, 42), 속성 프로토콜(Attribute Protocol, ATT, 43), 일반 속성 프로파일(Generic Attribute Profile, GATT, 44), 일반 접근 프로파일(Generic Access Profile, 45), LE 프로파일(46)을 포함할 수 있다. 다만, 상기 호스트 스택(40)은 이것으로 한정되지는 않고 다양한 프로토콜들 및 프로파일들을 포함할 수 있다.
호스트 스택은 L2CAP을 사용하여 블루투스 상위에서 제공하는 다양한 프로토콜, 프로파일 등을 다중화(multiplexing)한다.
먼저, L2CAP(Logical Link Control and Adaptation Protocol, 41)은 특정 프로토콜 또는 프로파일에게 데이터를 전송하기 위한 하나의 양방향 채널을 제공할 수 있다.
상기 L2CAP(41)은 상위 계층 프로토콜들 사이에서 데이터를 다중화(multiplex)하고, 패키지(package)들을 분할(segment) 및 재조립(reassemble)하고, 멀티캐스트 데이터 송신을 관리하도록 동작 가능할 수 있다.
블루투스 LE 에서는 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, 42)은 디바이스를 인증하며, 키 분배(key distribution)를 제공하기 위한 프로토콜이다.
ATT(Attribute Protocol, 43)는 서버-클라이언트(Server-Client) 구조로 상대 디바이스의 데이터를 접근하기 위한 규칙을 정의한다. ATT에는 아래의 6가지의 메시지 유형(Request, Response, Command, Notification, Indication, Confirmation)이 있다.
① Request 및 Response 메시지: Request 메시지는 클라이언트 디바이스에서 서버 디바이스로 특정 정보 요청 및 전달하기 위한 메시지이며, Response 메시지는 Request 메시지에 대한 응답 메시지로서, 서버 디바이스에서 클라이언트 디바이스로 전송하는 용도로 사용할 수 있는 메시지를 말한다.
② Command 메시지: 클라이언트 디바이스에서 서버 디바이스로 주로 특정 동작의 명령을 지시하기 위해 전송하는 메시지로, 서버 디바이스는 Command 메시지에 대한 응답을 클라이언트 디바이스로 전송하지 않는다.
③ Notification 메시지: 서버 디바이스에서 클라이언트 디바이스로 이벤트 등과 같은 통지를 위해 전송하는 메시지로, 클라이언트 디바이스는 Notification 메시지에 대한 확인 메시지를 서버 디바이스로 전송하지 않는다.
④ Indication 및 Confirm 메시지: 서버 디바이스에서 클라이언트 디바이스로 이벤트 등과 같은 통지/지시를 위해 전송하는 메시지로, Notification 메시지와는 달리, 클라이언트 디바이스는 Indication 메시지에 대한 확인 메시지(Confirm message)를 서버 디바이스로 전송한다.
본 발명은 상기 속성 프로토콜(ATT, 43)을 사용하는 GATT 프로파일에서 긴 데이터 요청 시 데이터 길이에 대한 값을 전송하여 클라이언트가 데이터 길이를 명확히 알 수 있게 하며, UUID를 이용하여 서버로부터 특성(Characteristic) 값을 전송 받을 수 있다.
상기 일반 접근 프로파일(45)은 블루투스 LE 기술을 위해 새롭게 구현된 계층으로, 블루투스 LE 디바이스들 간의 통신을 위한 역할 선택, 멀티 프로파일 작동이 어떻게 일어나는지를 제어하는데 사용된다.
또한, 상기 일반 접근 프로파일(45)은 디바이스 발견, 연결 생성 및 보안 절차 부분에 주로 사용되며, 사용자에게 정보를 제공하는 방안을 정의하며, 하기와 같은 attribute의 type을 정의한다.
① Service: 데이터와 관련된 behavior의 조합으로 디바이스의 기본적인 동작을 정의
② Include: 서비스 사이의 관계를 정의
③ Characteristics: 서비스에서 사용되는 data 값
④ Behavior: UUID(Universal Unique Identifier, value type)로 정의된 컴퓨터가 읽을 수 있는 포맷
상기 LE 프로파일(46)은 GATT에 의존성을 가지는 profile 들로 주로 블루투스 LE 디바이스에 적용된다. LE 프로파일(46)은 예를 들면, Battery, Time, FindMe, Proximity, Time 등이 있을 수 있으며, GATT-based Profiles의 구체적인 내용은 하기와 같다.
① Battery: 배터리 정보 교환 방법
② Time: 시간 정보 교환 방법
③ FindMe: 거리에 따른 알람 서비스 제공
④ Proximity: 배터리 정보 교환 방법
⑤ Time: 시간 정보 교환 방법
상기 일반 속성 프로파일(GATT, 44)은 서비스들의 구성 시에 상기 속성 프로토콜(43)이 어떻게 이용되는지를 설명하는 프로토콜로서 동작 가능할 수 있다. 예를 들어, 상기 일반 속성 프로파일(44)은 ATT 속성들이 어떻게 서비스들로 함께 그룹화되는지를 규정하도록 동작 가능할 수 있고, 서비스들과 연계된 특징들을 설명하도록 동작 가능할 수 있다.
따라서, 상기 일반 속성 프로파일(44) 및 상기 속성 프로토콜(ATT, 43)은 디바이스의 상태와 서비스들을 설명하고, 특징들이 서로 어떻게 관련되며 이들이 어떻게 이용되는지를 설명하기 위하여, 특징들을 사용할 수 있다.
이하에서, 블루투스 저전력 에너지(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)
광고 디바이스는 영역 내 디바이스들로 비지향성의 브로드캐스트를 수행하기 위해 광고 절차를 수행한다.
여기서, 비지향성의 브로드캐스트는 특정 방향으로의 브로드캐스트가 아닌 전(모든) 방향으로의 브로드캐스트를 말한다.
이와 달리, 지향성 브로드 캐스트는 특정 방향으로의 브로드캐스트를 말한다. 비지향성 브로드캐스트는 광고 디바이스와 리스닝(또는 청취) 상태에 있는 디바이스(이하, 리스닝 디바이스라 한다.) 간에 연결 절차 없이 발생한다.
광고 절차는 근처의 개시 디바이스와 블루투스 연결을 확립하기 위해 사용된다.
또는, 광고 절차는 광고 채널에서 리스닝을 수행하고 있는 스캐닝 디바이스들에게 사용자(User) 데이터의 주기적인 브로드캐스트를 제공하기 위해 사용될 수 있다.
광고 절차에서 모든 광고(또는 광고 이벤트)는 광고 물리 채널을 통해 브로드캐스트된다.
광고 디바이스들은 광고 디바이스로부터 추가적인 사용자 데이터를 얻기 위해 리스닝을 수행하고 있는 리스닝 디바이스들로부터 스캔 요청을 수신할 수 있다. 광고 디바이스는 스캔 요청을 수신한 광고 물리 채널과 동일한 광고 물리 채널을 통해, 스캔 요청을 전송한 디바이스로 스캔 요청에 대한 응답을 전송한다.
광고 패킷들의 일 부분으로서 보내지는 브로드캐스트 사용자 데이터는 동적인 데이터인 반면에, 스캔 응답 데이터는 일반적으로 정적인 데이터이다.
광고 디바이스는 광고 (브로드캐스트) 물리 채널 상에서 개시 디바이스로부터 연결 요청을 수신할 수 있다. 만약, 광고 디바이스가 연결 가능한 광고 이벤트를 사용하였고, 개시 디바이스가 디바이스 필터링 절차에 의해 필터링 되지 않았다면, 광고 디바이스는 광고를 멈추고 연결 모드(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 PCTKR2017006967-appb-T000001
광고 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개의 광고 채널을 통해 광고 메시지를 전송한다(S6010).
서버는 연결 전에는 광고자(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)를 서버로 전송한다(S6020).
이를 통해, 서버와 클라이언트 간에 Link Layer(LL) 연결이 형성(establish)된다.
이후, 서버와 클라이언트는 보안 설립 절차를 수행한다.
보안 설립 절차는 보안 심플 페어링(Secure Simple Pairing)으로 해석되거나 이를 포함하여 수행될 수 있다.
즉, 보안 설립 절차는 페이즈(Phase) 1 단계 내지 페이즈 3 단계를 거쳐 수행될 수 있다.
구체적으로, 서버와 클라이언트 간에 페어링 절차(페이즈 1)를 수행한다(S6030).
페어링 절차는 클라이언트가 서버로 페어링 요청 메시지(Pairing Request message)를 전송하고, 서버가 클라이언트로 페어링 응답 메시지(Pairing Response message)를 전송한다.
페어링 절차를 통해서 장치간 인증 요건(authentication requirements)과 인풋/아웃풋 능력(I(Input)/O(Output) capabilities)과 키 사이즈(Key Size)정보를 주고 받는다. 이 정보를 통해 페이즈 2에서 어떤 키(Key) 생성 방법을 사용할지 결정하게 된다.
다음, 페이즈 2로서, 서버와 클라이언트 간에 레거시 페어링(Legacy pairing) 또는 보안 연결(Secure Connections)을 수행한다(S6040).
페이즈 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) 절차를 수행한다(S6050).
이를 통해, 서버와 클라이언트간에 보안 연결이 확립되고, 암호화된 링크를 형성하여 데이터를 송수신할 수 있게 된다.
보안 심플 페어링 (Secure Simple Pairing)
보안 심플 페어링(Secure Simple Pairing)은 사용자에게 편리한 페어링 절차를 제공하고, 패시브 도청(Passive Eavesdropping) 및 MITM(Man-in-The-Middle) 공격에 대한 보안성 강화의 목적을 위해서 수행된다.
보안 심플 페어링(Secure Simple Pairing)은 아래와 같은 4개의 Stage 로 정의된다.
- 입출력 능력 교환(IO capability exchange)
- 공개 키 교환(Public key exchange)
- 인증 스테이지 1(Authentication stage 1)
- 인증 스테이지 2(Authentication stage 2)
첫 번째로, 디바이스들은 보안 심플 페어링(Secure Simple Pairing)에 사용하기 위한 적절한 알고리즘을 결정하기 위해서 입출력 능력(IO capability)를 교환한다.
이를 위해 개시자(Initiator)는 응답자(Responder)에게 입출력 능력(IO Capability)를 요청하는 입출력 능력 요청 메시지(IO capability Request message)를 전송하고, 응답자(Responder)는 이에 대한 응답으로 입출력 능력 응답 메시지(IO capability Response message)를 전송한다.
개시자(Initiator)와 응답자(Responder)는 입출력 능력 교환(IO capability exchange) 단계를 통해서 서로의 입출력 능력을 교환한다.
입출력 능력들을 교환한 뒤, 두 디바이스들은 공개 키(Public Key)를 교환한다.
만약, 공개 키(Public Key)의 크기가 DM! 패킷(DM1 packet)의 페이로드 바디(payload body)의 길이보다 긴 경우, 여러 번에 걸친 메시지의 교환으로 공개 키(Public Key)가 교환될 수 있다.
공개 키 교환(Public Key exchange) 단계에서 두 디바이스들은 192 bit 또는 256 bit 크기의 대칭키인 DH(Diffie-Hellman) Key를 교환할 수 있다.
이후, 인증 스테이지(Authentication stage) 1단계에서 MITM 공격이 발생하였는지 여부를 확인한다.
이를 확인하기 위하여 디바이스들의 입출력 능력에 기초하여 아래 표 2와 같은 보안 심플 페어링(Secure Simple Pairing)에서는 저스트 워크(Just Work), 패스키 엔트리(Passkey Entry), 뉴메릭 컴페리즌(Numeric Comparison)의 3가지 방법이 사용된다.
Figure PCTKR2017006967-appb-T000002
- 뉴메릭 컴페리즌(Numeric Comparison): 두 디바이스(device) 모두 여섯 자리 숫자(six digit number)를 보여줄 수 있는 디스플레이 장치가 있고 “예(yes)” 또는(or) “아니오(no)”를 선택할 수 있는 입력장치가 있는 경우에 사용됨.
- 저스트 워크(Just Work): 두 디바이스 중 적어도 하나의 디바이스가 여섯 자리 숫자(six digit number)를 보여줄 수 있는 디스플레이(display) 장치가 없고 여섯 자리 숫자(six digit number)를 입력할 수 있는 입력장치가 없는 경우에 사용됨.
- 패스키 엔트리(Passkey Entry): 두 디바이스 중 한 디바이스는 여섯 자리 숫자(six digit number)를 보여 줄 수 있는 디스플레이 장치가 없는 반면 입력 장치는 있고 다른 디바이스는 여섯 자리 숫자(six digit number)를 보여 줄 수 있는 디스플레이 장치가 있는 경우에 사용됨.
- Out of Band: 원격 장치(Remote device)를 탐색하고 페어링 프로세스(pairing process)에서 사용될 암호 숫자(cryptographic number)를 교환을 지원하는 Out Of mechanism(e.g. NFC)을 활용하는 경우에 사용됨.
인증 1 스테이트(Authentication 1 State) 단계 이후 인증 스테이지 (Authentication stage) 2단계를 통해서 DHKey 확인과 링크 키(Link Key) 생성 절차를 거쳐 암호화 채널을 생성한다.
도 7 및 도 8은 본 명세서에서 제안하는 방법들이 적용될 수 있는 인증 방법의 일 예를 나타낸 도이다.
도 7의 (a)는 레거시 페어링(legacy Pairing) 의 일 예를 나타내고, (b)는 뉴메릭 컴페리즌(Numeric Comparison) 의 일 예를 나타낸다.
도 8의 (a)는 저스트 워크(Just Work)의 일 예를 나타내고, (b)는 패스키 엔트리(Passkey Entry)의 일 예를 나타낸다.
도 7의 (a)에 도시된 바와 같이, 레거시 페어링(legacy Pairing)의 경우, 마스터 디바이스의 출력부(예를 들면, Display unit 등)를 통해서 출력된 핀 코드(PIN Code)를 슬레이브 디바이스에 입력함으로써 페어링이 된다.
뉴메릭 컴페리즌(Numeric Comparison)의 경우, 도 7의 (b)에 도시된 바와 같이 마스터 디바이스와 슬레이브 디바이스에 출력된 숫자가 동일한지 여부를 확인하고, 동일하면 컨펌(confirm)을 함으로써 디바이스가 인증되게 된다.
저스트 워크(Just Work)의 경우, 화면으로 출력할 수 없는 디바이스에서 사용될 수 있는 방법으로, 도 8의 (a)에 도시된 바와 같이 마스터 디바이스에서의 연결 요청으로 슬레이브 디바이스와 연결되며, 슬레이브 디바이스는 출력부를 통해서 연결이 성공적으로 되었다는 것을 외부로 출력한다.
패스키 엔트리(Passkey Entry)의 경우, 도 8의 (b)에 도시된 바와 같이 마스터 디바이스에서 특정 Passkey가 출력되면 출력된 Passkey를 슬레이브 디바이스를 통해 입력함으로써 마스터 디바이스와 슬레이브 디바이스가 연결되게 된다.
블루투스 디바이스들은 블루투스를 이용하여 데이터를 송수신하기 위해서는 디바이스를 검색하고, 연결을 형성하여야 한다.
이때, 연결을 형성하는 과정에서 두 디바이스가 앞에서 살펴본 바와 같이 서로를 인증하고 사용 권한을 부여하는 과정이 필요하다. 이러한 인증 과정에 있어서, 앞에서 설명한 레거시 페어링(Legacy Pairing), 뉴메릭 컴패리즌(Numeric Comparison), 및 패스키 엔트리(Passkey Entry)와 같은 방법은 미리 정의된 비밀번호나 여러 번의 로그인 등으로 사용자가 불편하고, 어려운 과정을 겪게 되는 문제점이 발생한다.
또한, 링크 레이어(Link Layer)에서 인증되더라도 특정 서비스를 이용하기 위한 인증 및 권한이 부여된 것은 아니기 때문에 프로파일에서 추가적인 인증이 필요하다.
따라서, 본 발명은 이와 같은 문제점을 해결하기 위해서, 디바이스의 입출력 기능에 기초하여 사용자가 직관적으로 인식할 수 있으며, 특정 프로파일에서의 인증을 위한 방법을 제안한다.
이하 후술하는 각 도면에 관한 설명 중 흐름도를 나타내는 도면에 관한 설명에 있어서, 먼저 설명된 흐름도에 포함된 절차와 동일한 절차는, 뒤의 도면에 대한 설명에서 구체적인 설명을 생략한다. 동일 절차에 관한 자세한 설명은 앞선 도면의 설명을 참조한다.
이하에서 클라이언트(Client)는 UA 클라이언트(UA Client)로 지칭될 수 있고, 서버(Server)는 UA 서버(UA Server)로 지칭될 수 있다.
도 9는 복수의 블루투스 디바이스를 인증 및 제어하는 방식의 일 예를 나타낸다.
사용자는 복수의 블루투스 디바이스를 소유할 수 있다. 블루투스 디바이스는 웨어러블 디바이스, 스마트 디바이스 또는 외부 제어 장치(예를 들어, 리모컨(Remote Controller))에 의해 제어되는 디바이스 등을 포함한다. 블루투스 디바이스는 종류 또는 기능에 기초하여 디바이스가 디스플레이를 포함할 수 있다.
도 9는 사용자가 복수의 디바이스들에 각각 블루투스 연결을 형성하는 일 예를 나타낸다. 일 예로, 사용자는 외부 제어 장치로 제어되는 하나 이상의 블루투스 디바이스와 사용자가 지니고 있는 웨어러블 디바이스 간에 인증을 수행해야 한다. 이 경우, 사용자는 각 디바이스를 모두 인증하기 위해, 복수의 인증을 각각 수행해야 한다. 복수의 인증 절차에서 각각 다른 인증 정보가 사용될 수 있다. 예를 들어, 비밀번호를 사용하여 인증을 수행하는 경우, 사용자는 각 디바이스의 인증에 필요한 비밀번호를 모두 별도로 기억해야 한다. 또한, 외부 제어 장치에 의해 제어되는 블루투스 디바이스의 경우, 별도의 조작/제어가 필요하다.
이러한 종래의 인증 방식은 디바이스 사용이나 조작이 어려운 사람들(예를 들어 노인, 장애인 등)에게 블루투스 연결 및 사용의 불편함을 초래한다. 이런 불편함을 해결하기 위해 사용자의 편의성을 강화한 인증 방식이 요구된다. 이하에서 자세히 살펴본다.
도 10은 블루투스 저전력 에너지 기술의 사용자 인증 서비스에서 디바이스 간 인증을 위한 절차의 일 예를 나타낸다.
이하에서 디바이스는 블루투스 통신을 수행할 수 있는 디바이스를 지칭한다.
사용자 인증 서비스(User Authentication Service: UAS, 이하 편의상 'UAS'로 표현한다)는 하나의 디바이스를 사용하여 다른 디바이스들과 자동으로 인증을 수행하는 서비스이다. 예를 들어, 하나의 디바이스는 웨어러블 디바이스에 해당될 수 있고, 다른 디바이스는 노트북, 핸드폰, 태블릿, 프린터 등에 해당될 수 있다. 즉, UAS는 웨어러블(wearable) 디바이스를 착용함으로써 사용을 원하는 디바이스에 UA(User Authentication) 서버를 사용하는 사용자를 알려주는 사용자 인증 서비스이다.
UAS 절차에서 디바이스 간 인증을 위해 세 가지 절차가 수행될 수 있다. 세가지 절차는 등록 세션(registration session), 보안 세션(Secure Session), 및 보안 획득 및 삽입 세션(Secure Get and Put Session)이다.
클라이언트(10010)와 서버(10020)는 각 디바이스 간 서로의 정보를 등록하는 등록 세션 절차를 수행한다(S10010). 등록 세션 절차는 인증 방법의 통지 절차, Hash 값 생성 절차, 공개 키(Public Key) 교환 절차 및 등록 아이디(Registration ID) 생성 절차를 포함한다.
클라이언트(10010)와 서버(10020)는 암호화된 링크를 생성하기 위한 보안 세션(Secure Session) 절차를 수행한다(S10020). 클라이언트(10010)와 서버(10020)는 디바이스 간 정보를 교환하기 전, 등록 세션 절차에서 전송된 등록 아이디를 사용하여 보안 링크(Secure link)를 생성할 수 있다.
클라이언트(10010)와 서버(10020)는 보안 세션 절차에서 보안 링크가 생성된 후, 디바이스 간 토큰(token) 정보를 주고 받는 보안 획득 및 삽입 세션(Secure Get and Put Session) 절차를 수행한다(S10030).
도 11은 클라이언트와 서버가 서버의 UAS 기능을 포함하는 메시지를 송수신하는 절차를 포함하는 흐름도의 일 예를 나타낸다.
UAS는 UAS 기능 특성(UAS Feature characteristic)을 포함한다. UAS 기능 특성은 UA 클라이언트가 등록 세션 절차를 수행하기 전에 UA 서버의 기능을 알 수 있게 한다.
클라이언트는 서버로 서버의 UAS 기능 특성 정보를 요청하는 특성 판독 요청(Characteristic Read Request) 메시지를 전송한다(S11010). 이 메시지는 UAS Feature Get 메시지로 지칭될 수 있다.
서버는 UAS 기능 획득(UAS Feature Get) 메시지를 수신한 후, 그에 대한 응답으로 서버의 UAS 기능 특성 정보를 포함하는 특성 판독 응답(Characteristic Read Response) 메시지를 전송한다(S11020). 이 메시지는 UAS 기능(UAS Feature) 메시지로 지칭될 수 있다. 클라이언트는 수신된 UAS 기능 메시지에 기초하여 서버가 지원하는 기능을 결정(determine)할 수 있다.
또한, 서버는 클라이언트로 변경된 토큰에 관한 정보를 포함하는 특성 통지(Characteristic Notification) 메시지를 전송할 수 있다(S11030). 이 메시지는 토큰 변경 통지(Token Change Notify) 메시지로 지칭될 수 있다. 클라이언트는 수신된 토큰 변경 통지(Token Change Notify) 메시지에 기초하여 토큰 정보를 업데이트 할 수 있다.
서버는 인증 과정에서 에러가 발생한 경우 클라이언트로 에러 응답 메시지(Error Response message)를 전송할 수 있다(S11040).
도 12는 UAS 기능 획득 메시지 및 UAS 기능 메시지의 필드와 각 필드의 정보의 일 예를 나타낸다.
(a)는 UAS 기능 획득 메시지의 필드 및 각 필드의 정보를 나타내고, (b)는 UAS 기능 메시지의 필드 및 각 필드의 정보를 나타낸다.
도 12에 나타난 UAS 서버는 UA 서버에 해당한다.
UAS 기능 획득(UAS Feature Get) 메시지는 해당 메시지의 타입을 나타내는 메시지 타입(Message Type) 필드를 포함한다. 메시지 타입 필드는 UAS 기능 획득 (UAS Feature Get)으로 설정된다.
리콰이어먼트(Requirements)는 해당 필드가 메시지에서 필수적인지(Mandatory) 여부를 나타낸다. M은 해당 필드가 필수적(Mandatory)임을 나타낸다.
UAS 기능(UAS Feature) 메시지는 메시지 타입 필드, UAS 버전(UAS Version) 필드, 등록 ID 수(Registration Id Count) 필드, 토큰 수(Token Count) 필드, 팩터 타입 리스트(Factor Type List) 필드, UA 서버 ID(UA Server ID) 필드 및 맥스 클록 드리프트 레이트(Max Clock Drift Rate) 필드를 포함할 수 있다.
기능 플래그는 MACed Server-Issued Tokens를 지원한다(support). 기능 플래그는 UA 서버에서 생성한 토큰(Token)과 세션 키(Session Key)를 사용하여 맥(MAC) 값을 생성한다. UA 클라이언트는 동일한 세션 키를 사용하여 인증을 수행한다.
기능 플래그는 팩터 타입(Factor Type)에 의한 토큰 룩업(Token Lookup)을 지원한다. UA 클라이언트가 보안 세션에서 보안 획득(Secure Get)의 토큰 값 메시지(Token Value message)를 전송한다. 그 후 UA 서버는 보안 획득(Secure Get)의 토큰 값 응답 메시지(Token Value Response message)를 전송한다. UA 클라이언트는 토큰의 상호 일치 여부를 확인한다.
기능 플래그는 SAS 검증된 LTK(SAS verified LTK)를 지원한다. SAS(Short Authentication String)는 UA 서버의 입출력 디스플레이(I/O Display)를 이용하여 사용자에 의해 확인될 수 있다. SAS는 4자리 이상의 영문과 숫자의 조합에 해당될 수 있다.
기능 플래그는 설정 시간(Set Time)을 지원한다. 기능 플래그는 UA 클라이언트의 등록 아이디(Registration ID)마다 설정 시간을 다르게 설정함으로써 등록 세션을 수행할 수 있다.
기능 플래그는 거리 바운딩(Distance Bounding)을 지원한다. 토큰은 RSSI로 측정한 클라이언트와 서버 간의 고정 거리(fixed distance) 값을 사용하여 생성될 수 있다.
등록 ID 수(Registration ID Count)는 서버에 의해 개시되는 클라이언트 등록의 수이다. UA 서버는 지원 가능한 Reg ID 수가 최대인 경우, 등록 ID 수 정보를 사용하여 UA 클라이언트에게 에러 메시지를 보낼 수 있다.
맥스 클록 드리프트 레이트(Max Clock Drift Rate)는 UA 서버의 최대 클락 드리프트 비율(Maximum clock drift rate)에 해당한다. 클록 드리프트(Clock Drift)는 클록이 정확한 속도로 동작하지 않음으로써 발생하는 현상이다.
각 필드의 이름, 사이즈 또는 포맷은 변경될 수 있다.
도 13은 사용자 인증 서비스 프로토콜 절차의 흐름도의 일 예를 나타낸다.
먼저, 서버와 클라이언트는 등록 세션 절차를 시작하기 전 BLE 연결 상태(BLE Connection State)를 형성한다(S13010).
그 후, 클라이언트는 UA 서버로 서버의 UAS 기능 특성(UAS Feature Characteristic) 정보를 요청하고(S13020), 서버로부터 UAS 기능 특성 정보를 수신한다(S13030). 서버는 클라이언트로 변경된 토큰에 관한 정보를 포함하는 통지 메시지를 전송할 수 있다(S13060). 이 세가지 절차는 각각 도11과 관련된 설명에서 상술한 UAS 기능 획득(UAS Feature Get) 메시지 전송(S11010), UAS 기능 메시지 전송(S11020) 및 토큰 변경 통지(Token Change Notify) 메시지 전송(S11030) 절차와 동일하게 수행될 수 있다.
클라이언트는 UAS 기능 정보를 수신한 뒤, 클라이언트의 특정 절차와 관련된 기입 요청 메시지를 서버로 전송한다(S13040). 이 메시지는 UACP 특성 기입(UA Action Control Point(UACP) Characteristic Write) 메시지로 지칭될 수 있다.
UAS는 사용자 인증 동작 제어 지점 특성(User Authentication (UA) Action Control Point characteristic)를 포함한다. UA 동작 제어 지점 특성은 UA 클라이언트가 UA 서버에 의해 특정 동작을 개시(initiate)할 수 있게 한다.
서버는 사용자 인증 동작 제어 지점 특성 요청에 대한 응답으로, UACP(UA Action Control Point) 특성 정보를 포함하는 특성 지시(Characteristic Indication) 메시지를 전송한다(S13050). 이 메시지는 UACP 특성 지시(UA Action Control Point Characteristic Indication) 메시지로 지칭될 수 있다.
아래 표 3은 UACP 특성 기입 메시지 및 UACP 특성 지시 메시지의 Op Code를 나타낸다. UACP 특성 정보에 포함된 Op code에 기초하여 메시지의 종류가 결정된다.
Figure PCTKR2017006967-appb-T000003
등록 시작(Registration Start(0x00)) 메시지는 사용자 인증의 제어(control)를 요청하는 절차를 개시(initiate)한다. 등록 클라이언트 공개 키(Registration Client Public Key(0x01)) 메시지는 UA 클라이언트의 공개 키를 제공하는 절차를 시작한다. 등록 확인(Registration confirmation(0x02)) 메시지는 UA 클라이언트와 UA 서버 간의 등록 세션을 확인하는 절차를 시작한다. 등록 중단(Registration Abort(0x03)) 메시지는 등록 절차를 종료하는 절차를 시작한다. 보안 획득 토큰 값(Secure Get Token Value(0x04)) 메시지는 보안 세션에 필요한 하나의 토큰을 가져오는 절차를 시작한다. 보안 획득 모든 토큰 값(Secure Get All Token Value(0x05)) 메시지는 보안 세션에서 UA 서버에 저장된 모든 토큰을 가져오는 절차를 시작한다. 보안 추가/업데이트 토큰(Secure Add/Update Token(0x06)) 메시지는 UA 서버에서 토큰을 추가하거나 업데이트 하는 절차를 시작한다. 보안 삭제 토큰(Secure Delete Token(0x07)) 메시지는 UA 서버에서 토큰을 삭제하는 절차를 시작한다. 보안 취소 ID(Secure Unregister ID(0x08)) 메시지는 등록 취소 ID(unregister ID)를 UA 서버에 알리는 절차를 시작한다. 그 경우 등록 취소 ID와 관련된 정보는 UA 서버에서 삭제되어야 한다. 보안 설정 시간(Secure Set Time(0x09)) 메시지는 다른 사용자 ID의 타임 스탬프(timestamps)에 대한 보안 공격을 방지하는 절차를 시작한다. 보안 설정 거리 바운딩(Secure Set Distance Bounding(0x0A)) 메시지는 UA 서버와 UA 클라이언트 간에 정의된 거리를 설정하는 절차를 시작한다. 응답(Response) 메시지는 UACP 특성의 지시에 따라 UA 클라이언트로 전송된다.
도 14는 등록 세션 시작 시퀀스 흐름도의 일 예를 나타낸다.
클라이언트는 서버로 등록 세션을 개시(initiate)하기 위한 기입 요청 메시지(Write Request message)를 전송한다(S14010). 이 메시지는 시작 메시지(Start message)로 지칭될 수 있다. 시작 메시지는 Start Registration, Registration Request Number, Registration Message를 포함한다. 서버는 이에 대한 응답 메시지를 클라이언트로 전송할 수 있다(S14020).
그 후, 서버는 클라이언트로 서버 해시 커밋(Server Hash Commit)을 포함하는 통지 메시지(Notification massage)를 전송할 수 있다(S14030). 이 메시지는 서버 해시 커밋 메시지로 지칭될 수 있다.
클라이언트는 서버 해시 커밋 메시지를 수신한 뒤, 서버로 판독 요청 메시지인 Read Request For Registration Session Read/Notify 메시지를 전송한다(S14040). 서버는 이에 대한 응답으로 클라이언트에게 판독 응답 메시지(Read Response message)를 전송할 수 있다(S14050). 이 판독 응답 메시지는 서버 해시 커밋, H(KS_PUB), 유저인터렉션 타입(User Interaction Type), 유저인터렉션 데이터(User Interaction Data)를 포함한다.
유저인터렉션 타입 및 유저인터렉션 데이터에 관한 자세한 사항은 후술한다.
클라이언트는 H(KS_PUB)를 포함하는 판독 응답 메시지를 수신하고, 이후(later)의 스텝에서 확인(verification)을 위해 H(KS_PUB)를 저장한다. 또한, 클라이언트는 사용자에게 필요한(required) 인터렉션 메시지(Interaction Message)를 표시(display) 하고 사용자의 확인(confirmation)을 기다린다.
사용자가 서버 디바이스에서 사용자 인증을 위해 필요한 인터렉션(Interaction)을 완료한 경우, 서버는 클라이언트로 유저인터렉션(User Interaction)의 성공 여부를 포함하는 통지 메시지를 전송할 수 있다(S14060). 이 메시지는 유저인터렉션 완료(User Interaction Complete) 메시지로 지칭될 수 있다. 유저인터렉션(User Interaction)에 대한 자세한 사항은 후술한다.
클라이언트 유저인터렉션(User Interaction) 결과를 수신한 뒤, 클라이언트의 공개 키를 포함하는 기입 요청 메시지를 서버로 전송한다(S14070). 이 기입 요청 메시지는 클라이언트 공개 키, KCX_PUB, KCY_PUB, N_c, User Interaction Data를 포함한다. 이 메시지는 클라이언트 공개 키 메시지로 지칭될 수 있다. 서버는 기입 요청 메시지를 수신한 뒤 이후의 스텝을 위해 KCX_PUB, KCY_PUB. KS_PRIV를 사용하여 LTK를 생성하고, N_c를 저장한다. 그 후 서버는 기입 응답 메시지를 클라이언트로 전송할 수 있다(S14080).
클라이언트는 서버의 LTK 생성의 완료를 기다린다. 그 후, 클라이언트는 서버로부터 LTK 생성 완료를 통지하는 Registration Session Read/Notify 통지 메시지를 수신할 수 있다(S14090). 클라이언트는 이 메시지로부터 LTK를 획득할 수 있다.
그 후, 서버는 클라이언트로부터 판독 요청 메시지인 Read Request For Registration Session Read/Notify 메시지를 수신하고(S140100), KS_PUB를 위한 맥(MAC) 키를 생성한다.
그 후, 서버는 서버 공개 키, KSX_PUB, KSY_PUB, 등록 ID, N_s, MAC_s를 포함하는 판독 응답 메시지를 클라이언트로 전송할 수 있다(S140110). 이 메시지는 서버 공개 키 메시지로 지칭될 수 있다.
만약 SAS 확인(confirmation)이 필요하면, 서버는 사용자 확인(User Confirmation)을 위해 SAS가 서버 디바이스에 표시(display)되었음을 나타내는 메시지를 클라이언트로 전송할 수 있다(S140120). 그 후, 사용자는 UA 서버 디바이스의 디스플레이로부터 SAS를 검증(verify) 한다.
클라이언트는 SAS Confirmation, H(KS_PUB) 및 MAC_s를 검증하고, LTK 및 MAC_c를 생성한다. 클라이언트는 클라이언트 확인(Client Confirmation) 및 MAC_c를 포함하는 기입 요청 메시지를 서버로 전송한다(S140130). 이 메시지는 클라이언트 확인 메시지로 지칭될 수 있다. 클라이언트 확인 메시지는 디바이스 등록이 완료되었음을 나타낸다.
서버는 수신된 MAC_c를 검증하고, 등록 ID 및 LTK를 데이터베이스에 저장한다. 그 후, 서버는 클라이언트로 기입 응답 메시지를 전송할 수 있다(S140140). 이 기입 응답 메시지를 수신한 클라이언트는 등록 ID 및 LTK를 데이터베이스에 저장한다. 이 메시지는 클라이언트 확인 회신(Client Confirmation Reply) 메시지로 지칭될 수 있다.
상술한 절차를 통해 등록 세션 시작 시퀀스(Registration Session Start Sequence)가 완료된다. UA 클라이언트는 보안 세션을 시작할 수 있고, 자기의 토큰을 생성할 수 있다.
도 15는 도 14에 개시된 등록 세션 시작 시퀀스 흐름도를 간략히 나타낸 흐름도의 일 예를 나타낸다.
클라이언트는 서버로 인증 시작을 요청하는 시작 메시지를 전송한다(S15010). 이 절차는 상술한 도 14의 S14010 단계와 동일하게 수행될 수 있다.
서버는 클라이언트로 서버 해시 커밋(Server Hash Commit)을 포함하는 메시지를 전송한다(S15020). 이 절차는 상술한 도 14의 S14030 단계와 동일하게 수행될 수 있다.
서버는 클라이언트로 유저인터렉션 완료(User Interaction Complete)를 나타내는 메시지를 전송할 수 있다(S15030). 이 절차는 상술한 도 14의 S14060 단계와 동일하게 수행될 수 있다.
클라이언트는 서버로 클라이언트 공개 키가 포함된 메시지를 전송한다(S S15040). 이 절차는 상술한 도 14의 S14070 단계와 동일하게 수행될 수 있다.
그 후 서버는 클라이언트로 서버 공개 키가 포함된 메시지를 전송한다(S S15050). 이 절차는 상술한 도 14의 S140110 단계와 동일하게 수행될 수 있다.
클라이언트는 클라이언트 확인(Client Confirmation) 메시지를 전송한다(S S15060). 이 절차는 상술한 도 14의 S140130 단계와 동일하게 수행될 수 있다.
서버는 클라이언트 확인 메시지에 대한 응답으로 클라이언트 확인 회신(reply) 메시지를 클라이언트에게 전송한다(S15070). 이 절차는 상술한 도 14의 S140140 단계와 동일하게 수행될 수 있다.
클라이언트는 서버로 등록 세션 절차의 종료하는 메시지인 중단(Abort) 메시지를 전송할 수 있다(S15010). 또한, 중단 메시지는 등록 세션 절차에서 UAS에서 정의된 에러가 발생된 경우 전송될 수 있다. 이로 인해 등록 세션 절차가 중단될 수 있다.
각 메시지 전송 절차에 대한 자세한 사항은 상술한 도 14와 관련된 설명을 참조한다. 각 절차에 사용되는 메시지에 포함된 필드 대한 자세한 사항은 후술한다.
도 16은 시작 메시지의 필드 및 각 필드의 정보의 일 예를 나타낸다.
시작 메시지(Start message)는 등록 세션 번호(Registration Session Number) 필드, 메시지 타입(Message Type) 필드, 리저브드(Reserved) 필드 및 등록 세션 시작 플래그(Registration Session Start Flags) 필드를 포함한다. 시작 메시지는 등록 시작 메시지(Registration Start message)로 지칭될 수 있다.
도 16에 나타난 UAS 클라이언트는 UA 클라이언트에 해당한다.
메시지 타입은 등록 세션 시작(Registarion Session Start)로 설정된다.
리저브드 필드는 0으로 설정된다.
등록 세션 번호 필드는 등록 순서를 추적하고 등록 세션 메시지를 상관(correlate)시키기 위해 UA 클라이언트에 의해 제공된다. 등록 시퀀스가 등록 세션 시작 메시지에 의해 개시되면, 세션 시퀀스에 대한 후속 등록 세션 메시지는 이 등록 세션 번호를 포함할 수 있다. 등록 세션 번호 필드는 메시지를 등록 순서와 상관시키기 위해 UA 클라이언트에 의해 제공될 수 있고, 재전송 공격(replay attack)을 막기 위해 암호화 계산(cryptographic calculations)에 포함될 수 있다.
등록 세션이 진행되는 동안, 모든 메시지는 세션 번호(Session Number)를 사용할 수 있다. 또한, CMAC Key가 사용될 수도 있다.
등록 세션 시작 플래그 필드의 Register with SAS confirmed LTK는 UA 서버가 디바이스의 디스플레이를 사용하여 SAS 문자를 사용자의 확인을 통해 입증해야 하는 등록 타입(Registration Type)이다. Register without SAS confirmed는 사용자의 확인을 요구하지 않는다.
각 필드의 이름, 사이즈 또는 포맷은 변경될 수 있다.
도 17은 서버 해시 커밋 메시지의 필드 및 각 필드의 정보의 일 예를 나타낸다.
서버 해시 커밋(Server Hash Commit) 메시지는 메시지 타입 필드, 임시 등록 아이디(Temporary Registration ID) 필드, 및 등록 세션 번호 필드, H(KS_PUB) 필드, 유저인터렉션 타입(User Interaction Type) 필드 및 유저인터렉션 데이터(User Interaction Data) 필드를 포함한다.
메시지 타입 필드는 Registration Session Server Hash Commit으로 설정된다. 등록 세션 번호 필드에 관한 사항은 상술한 바와 같다.
도 17에 나타난 UAS 클라이언트는 UA 클라이언트에 해당하고, UAS 서버는 UA 서버에 해당한다.
사용자가 디바이스에 등록된 사용자가 아닌 경우, 서버는 클라이언트에게 임시 등록 아이디를 제공할 수 있다. 등록 세션 절차가 완료된 후 임시 등록 아이디는 사용자 아이디로 변경된다.
H(KS_PUB) 필드는 서버의 공개 키에 기초하여 생성된 해시(hash)이다. H(KS_PUB) 필드는 128bits 일 수 있다. 일 예로, H(KS_PUB) 필드는 아래의 수식을 사용하여 생성될 수 있다.
Figure PCTKR2017006967-appb-M000001
유저인터렉션 타입 및 유저인터렉션 데이터에 관한 자세한 사항은 후술한다.
각 필드의 이름, 사이즈 또는 포맷은 변경될 수 있다.
도 18은 클라이언트 공개 키 메시지의 필드 및 각 필드의 정보의 일 예를 나타낸다.
클라이언트 공개 키(Client Public Key) 메시지는 메시지 타입 필드, 등록 아이디 필드, 등록 세션 번호 필드, KCX_PUB 필드 및 KCY_PUB 필드, N_c 필드 및 사용자 피드백 데이터(User Feedback Data) 필드를 포함한다.
메시지 타입 필드는 Registration Session Client Public Key로 설정된다. 등록 세션 번호 필드에 대한 내용은 상술한 바와 같다. 등록 아이디 필드는 상술한 임시 등록 아이디 필드에 해당한다.
도 18에 나타난 UAS 클라이언트는 UA 클라이언트에 해당하고, UAS 서버는 UA 서버에 해당한다.
KCX_PUB 필드는 UA 클라이언트 공개 키의 X 좌표(X coordicate)에 해당한다. KCY_PUB 필드는 UA 클라이언트 공개 키의 Y 좌표(Y coordicate)에 해당한다. KCX_PUB 필드 및 KCY_PUB 필드는 32 옥텟의 사이즈에 해당하고, ECDH P-256을 기반으로 할 수 있다. KCX_PUB 및 KCY_PUB는 KC_PUB에 포함된다.
N_c 필드는 UA 클라이언트에 의해 생성된 16바이트의 nonce이다.
사용자 피드백 데이터(User Feedback Data) 필드는 UA 서버에서 요청한 유저인터렉션 타입에 대해 UA 클라이언트가 수집한 사용자의 입력 데이터이다.
각 필드의 이름, 사이즈 또는 포맷은 변경될 수 있다.
도 19는 서버 공개 키 메시지의 필드 및 각 필드의 정보의 일 예를 나타낸다.
서버 공개 키(Server Public Key) 메시지는 메시지 타입 필드, 등록 아이디 필드, 등록 세션 번호 필드, KCX_PUB 필드, KCY_PUB 필드, N_s 필드 및 MAC_s 필드를 포함한다.
메시지 타입 필드는 Registration Session Server Public Key로 설정된다.
등록 아이디 필드 및 등록 세션 번호 필드에 대한 사항은 상술한 바와 같다.
KSX_PUB 필드는 UA 서버 공개 키의 X 좌표(X coordicate)에 해당한다. KSY_PUB 필드는 UA 서버 공개 키의 Y 좌표(Y coordicate)에 해당한다. KSX_PUB 필드 및 KSY_PUB 필드는 32 옥텟 사이즈에 해당하고, ECDH P-256을 기반으로 할 수 있다. KSX_PUB 및 KSY_PUB는 KS_PUB에 포함된다.
도 19에 나타난 UAS 서버는 UA 서버에 해당한다.
N_s 필드는 UA 서버에 의해 생성된 16바이트의 nonce이다.
MAC_s 필드는 서버 공개 키 해시이다. MAC_s 필드는 의도된 UA 서버에서 키 교환이 발생하는 것을 인증하는 UA 클라이언트에 의해 사용된다. 즉, MAC_s 필드는 메시지가 전송되는 동안 변경되었는지 여부를 확인하기 위해 메시지를 다른 장치로 전송하는 것을 확인한다. 해시는 등록 아이디 정보를 포함한다.
각 필드의 이름, 사이즈 또는 포맷은 변경될 수 있다.
도 20은 클라이언트 확인 메시지와 중단 메시지의 필드 및 각 필드의 정보의 일 예를 나타낸다.
(a)는 클라이언트 확인 메시지(Client Confirmation message)의 필드 및 각 필드의 정보를 나타내고, (b)는 중단(Abort) 메시지의 필드 및 각 필드의 정보를 나타낸다.
도 20에 나타난 UAS 클라이언트는 UA 클라이언트에 해당하고, UAS 서버는 UA 서버에 해당한다.
클라이언트 확인 메시지는 메시지 타입 필드, 등록 아이디(Registration ID) 필드, 등록 세션 번호 필드 및 MAC_c 필드를 포함한다.
메시지 타입 필드는 Registration Session Client Confirmation으로 설정된다. 등록 아이디 필드, 및 등록 세션 번호 필드에 관한 사항은 상술한 바와 같다.
MAC_c 정보는 의도된 UA 클라이언트에서 키 교환이 발생하는 것을 인증하기 위해 UA 서버에 의해 사용되는 클라이언트 공개 키 해시 이다. MAC_c 필드는 메시지가 전송되는 동안 변경되었는지 여부를 확인하기 위해 메시지를 다른 장치로 전송하는 것을 확인한다. 해시는 등록 아이디 정보를 포함한다. 등록 아이디 정보는 각 디바이스의 데이터베이스에 저장된다.
중단(Abort) 메시지는 메시지 타입 필드 및 등록 아이디 필드를 포함한다. 메시지 타입 필드에 관한 사항은 상술한 바와 같다. 등록 아이디 필드는 중단된 등록 세션과 관련된 등록 아이디 정보를 포함한다.
각 필드의 이름, 사이즈 또는 포맷은 변경될 수 있다.
도 21은 사용자를 인증하는 유저인터렉션 절차를 포함하는 등록 세션 절차의 흐름도의 일 예를 나타낸다.
이하에서는, 상술한 도 10, 도 12, 도 13 및 도 14에 개시된 절차와의 차이점을 중심으로 설명한다.
서버는 등록 시작(Registration Start) 메시지를 수신한 뒤(S21030)(상술한 도 14의 S14010 단계 참조), 사용자를 식별하는 정보를 획득하고, 획득된 식별 정보를 사용하여 사용자를 인증하는 절차인 유저인터렉션(User Interaction) 절차를 수행한다(S21040). 유저인터렉션 절차는 사용자 인증 절차로도 지칭될 수 있다.
유저인터렉션(User Interaction) 이란, 디바이스를 사용하는 사용자를 인증하기 위한 절차이다. UAS는 UAS 디바이스에서 지원(support)하는 유저인터렉션 타입(User Interaction Type)을 사용할 수 있다.
유저인터렉션 타입(User Interaction Type)은 유저인터렉션(User Interaction)을 수행하는 방법 또는 식별 정보의 종류로서 디바이스에서 지원하는 기능에 기초하여 결정된다. 유저인터렉션 타입은 UA 서버에 의해 요청되어 사용자로부터 수신하는 정보의 종류와 관련된다.
서버는 서버 디바이스의 입출력 능력에 기초하여 사용자로부터 직접 사용자 정보를 입력 받을 수 있다. 예를 들어, 서버 디바이스가 지문 인식 시스템을 갖춘 경우, 사용자의 지문 정보를 수신할 수 있다.
아래의 표 4는 유저인터렉션 타입의 종류 및 각 타입에 따른 UA 서버에 입력되는 사용자 입력(User Input) 정보의 일 예를 나타낸다.
Figure PCTKR2017006967-appb-T000004
유저인터렉션 데이터(User Interaction Data)는 UA 서버에 의해 요청된 유저인터렉션 타입에 따라 사용자로부터 입력받은 데이터이다. 일 예로, 유저인터렉션 타입이 지문인 경우, 유저인터렉션 데이터는 지문 정보를 포함한다. UAS는 사용자의 생체 정보(예를 들어, 지문, 홍채 등)를 사용하여 사용자 인증을 수행함으로써 보안을 더욱 강화할 수 있다.
아래의 표 5는 유저인터렉션 타입을 사용하여 사용자를 인증하는 방법인 유저인터렉션 방식(User Interaction Method)들의 예를 나타낸다.
Figure PCTKR2017006967-appb-T000005
클라이언트 디바이스(Device A) 또는 서버 디바이스(Device B)에 패스워드가 입력될 수 있다(Method #1). 클라이언트 디바이스 또는 서버 디바이스에 홍채 정보가 입력될 수 있다(Method #2). 클라이언트 디바이스 또는 서버 디바이스에 패턴 정보가 입력될 수 있다(Method #3). 이 외에, 상기 표 4에 나타난 다른 유저인터렉션 타입을 사용하는 방식이 있을 수 있다.
서버는 유저인터렉션이 수행된 후 사용자가 서버에 등록되지 않은 새로운 사용자인 경우, 수신된 사용자 정보에 기초하여 임시 사용자 아이디(Temp User ID)를 할당한다. 서버는 임시 사용자 ID에 새로운 서버 공개 키를 할당한다. 그 뒤 서버는 유저인터렉션 완료(User Interaction Complete) 메시지를 사용하여 클라이언트에게 임시 사용자 아이디를 전송한다. 서버는 사용자가 서버에 등록된 사용자인 경우, 미리 할당되어있는 사용자 아이디(User ID)를 클라이언트에게 전송한다.
클라이언트는 새로 생성된 사용자 ID를 수신하고, 사용자가 할당되지 않은 클라이언트 공개 키를 할당한다. 그 후, 클라이언트는 클라이언트 공개 키를 포함하는 메시지를 서버로 전송한다(S21060). 수신된 사용자 ID가 미리 클라이언트에 할당되어있는 경우, 새로운 클라이언트 공개 키를 할당하지 않고 저장되어 있던 사용자 ID에 대응하는 공개 키를 서버로 전송한다.
서버는 수신된 클라이언트 공개 키를 사용하여 링크 키와 맥 값을 생성한다(S21070). 맥 값은 맥 키(MAC Key)로 지칭될 수 있다. 맥 값은 링크 키를 사용하여 획득된다.
서버는 아래의 수학식 2와 같이 AES(advanced encryption standard)-CMAC(cipher-based message authentication code) 알고리즘을 사용하여 링크 키(Link key)를 생성할 수 있다.
Figure PCTKR2017006967-appb-M000002
서버는 획득한 링크 키를 사용하여 아래의 수학식 3과 같이 AES-CMAC 알고리즘을 사용하여 암호화 키(Encryption Key)를 생성할 수 있다.
Figure PCTKR2017006967-appb-M000003
서버는 획득한 암호화 키를 사용하여 아래의 수학식 4와 같이 암호화 데이터(Encrypted Data)와 맥 값(MAC value)을 생성할 수 있다. 서버의 맥 값은 MAC_s 에 해당한다.
Figure PCTKR2017006967-appb-M000004
서버는 링크 키와 맥 값을 생성한 뒤 서버 공개 키를 포함하는 메시지를 클라이언트로 전송한다.
클라이언트는 수신된 서버 공개 키를 사용하여 링크 키와 맥 값을 생성한다(S21090).
클라이언트는 아래의 수학식 5와 같이 AES-CMAC 알고리즘을 사용하여 링크 키(Link key)를 생성할 수 있다.
Figure PCTKR2017006967-appb-M000005
클라이언트는 획득한 링크 키를 상술한 수학식 4에 적용하여 암호화 키(Encryption Key)를 생성할 수 있다.
클라이언트는 획득한 암호화 키를 사용하여 아래의 수학식 6와 같이 암호화 데이터(Encrypted Data)와 맥 값(MAC value)을 생성할 수 있다. 클라이언트의 맥 값은 MAC_c에 해당한다.
Figure PCTKR2017006967-appb-M000006
상술한 바와 같이 클라이언트와 서버는 각각 맥 값을 획득한다.
그 뒤, 클라이언트는 서버로 디바이스 등록이 완료되었다는 확인 메시지를 전송한다. 디바이스 등록이 완료된 후, 사용자의 임시 아이디는 사용자 ID로 저장된다.
도 22는 본 명세서에서 제안하는 UAS 절차의 일 예로서, 등록 세션 절차 전 인터렉션 방식을 나타내는 메시지가 전송되는 절차가 포함된 흐름도의 일 예를 나타낸다.
이하에서는, 도 10 및 도 15에 개시된 흐름도와의 차이점을 중심으로 설명한다. 참조번호를 참조하여 동일한 절차는 상술한 도면에 대한 설명을 참조한다.
클라이언트(UA Client)와 서버(UA Server)는 BLE 연결 상태(BLE Connection State)를 형성한다(S22010).
클라이언트는 서버로부터 UAS 기능 특성(UAS Feature Characteristic) 메시지를 수신(S22020)한 뒤, 서버로 UAS 절차에서 사용할 인증 방식을 포함하는 메시지를 전송할 수 있다(S22030). 이 메시지는 인터렉션 방식(Interaction Method) 메시지로 지칭될 수 있다. 그 후, 클라이언트와 서버는 등록 세션 절차를 수행한다(S22040).
클라이언트는 수신된 서버의 UAS 기능 특성에 기초하여 어떤 방식으로 인증을 수행할지를 결정할 수 있다. 그 후, 클라이언트는 사용자 인증(User Interaction) 방식 및/또는 디바이스 인증(Device Interaction) 방식을 포함하는 인터렉션 방식 메시지를 서버로 전송할 수 있다(S22030). 즉, 클라이언트가 UAS 기능 특성에 기초하여 인증 방식을 결정할 수 있다. 사용자 인증 절차는 유저인터렉션 절차로서 상술한 도21과 관련된 설명을 참조한다. 디바이스 인증 절차에 관한 자세한 사항은 후술한다.
서버는 수신된 인터렉션 방식 메시지에 포함된 인증 방식에 기초하여 클라이언트와 인증 세션 절차를 수행한다(S22060).
도 23은 본 명세서에서 제안하는, UAS 절차에서 클라이언트와 서버가 사용자의 입력을 획득할 수 있는 지점을 나타낸 흐름도의 일 예를 나타낸다.
도 23의 흐름도는 도 13에 나타난 흐름도의 각 메시지를 ATT 프로토콜(ATT protocol)을 사용하여 나타낸 것이다.
사용자는 UAS 절차에서 서버 디바이스 또는 클라이언트 디바이스에 사용자 입력(User Input)을 수행할 수 있다. 사용자 입력은 사용자가 디바이스에 패스워드 입력, 확인 버튼 클릭, 패턴 입력 등 특정한 동작을 수행하는 것 또는 그로부터 획득한 정보에 해당한다. 사용자 입력의 종류는 디바이스의 입출력 능력(Input/Output Capability)에 기초하여 결정될 수 있다. 사용자는 서버 디바이스 또는 클라이언트 디바이스 중 하나 이상의 디바이스에 사용자 입력을 수행할 수 있다.
클라이언트는 사용자로부터 등록 세션을 시작하기 위한 사용자 입력을 획득하고, 그리고 나서 등록 세션 절차의 시작을 요청하는 기입 요청 메시지를 전송함으로써 등록 세션 절차를 시작할 수 있다(S23010). 이 절차는 상술한 도 14의 S14010 단계와 동일하게 수행될 수 있다.
서버는 사용자로부터 사용자 입력을 획득하여 사용자 인증을 수행할 수 있다. 이 경우 사용자 입력은 사용자 식별 정보에 해당될 수 있다. 서버는 사용자 식별 정보를 획득하여 사용자 인증에 사용될 데이터를 생성할 수 있다. 사용자 식별 정보의 종류는 디바이스의 입출력 능력에 기초하여 결정될 수 있다. 사용자 인증 및 사용자 식별 정보에 관한 사항은 상술한 도 21과 관련된 설명을 참조한다.
클라이언트는 서버 공개 키를 포함하는 통지 메시지를 수신한다(S23050). 이 절차는 상술한 도 14의 S140110 단계와 동일하게 수행될 수 있다. 그 후, 사용자로부터 디바이스 인증을 확인(confirm)하는 사용자 입력을 획득할 수 있다. 서버는 서버 공개 키 메시지를 클라이언트로 전송한 후(S23050), 사용자로부터 디바이스 인증을 확인(confirm)하는 사용자 입력을 획득할 수 있다. 디바이스 인증 확인은 사용자가 디바이스 간 공개 키를 교환하여 생성된 결과와 사용자 입력에 기초하여 수행될 수 있다.
디바이스 인증 절차에 대한 자세한 사항은 후술한다.
도 24는 본 명세서에서 제안하는, UAS 절차에서 서버에 사용자의 입력을 획득할 수 있는 지점을 나타낸 흐름도의 일 예를 나타낸다.
도 24는 사용자가 서버 디바이스 측에서만 사용자 입력을 수행하는 경우를 나타낸다. 이 경우 사용자는 클라이언트 디바이스를 제어하지 않는다.
서버는 사용자로부터 등록 세션의 시작을 요청하는 사용자 입력을 획득할 수 있다. 그 후, 서버는 클라이언트로 등록 세션의 시작을 요청하는 통지 메시지를 전송한다(S24010). 이 통지 메시지는 스타트 등록 세션(Start Registration Session) 메시지로 지칭될 수 있다. 클라이언트는 스타트 등록 세션 메시지를 수신한 뒤 서버로 시작 메시지를 전송할 수 있다(S24020). 이 절차는 상술한 도 14의 S14010 단계와 동일하게 수행될 수 있다.
서버는 서버 해시 커밋 메시지(Server Hash Commit Message)를 클라이언트로 전송(S24030)한다. 이 절차는 상술한 도 14의 S14030 단계와 동일하게 수행될 수 있다. 그 뒤 서버는 사용자 인증을 수행하는 사용자 입력을 획득할 수 있다.
서버는 클라이언트로 서버 공개 키 메시지를 전송한 뒤(S24050) 교환된 공개 키를 사용하여 클라이언트가 획득한 데이터를 포함하는 명령(Command) 메시지를 수신할 수 있다(S24060). 이 메시지는 인증 값 메시지(Authentication Value Message)로 지칭될 수 있다. 예를 들어, 인증 값 메시지(Authentication Value Message)는 클라이언트에서 생성된 MAC_c를 포함할 수 있다. 그 후 서버는 사용자로부터 디바이스 인증을 확인(confirm)하는 사용자 입력을 획득할 수 있다.
도 25는 본 명세서에서 제안하는 디바이스 인증 절차를 포함하는 등록 세션 절차 흐름도의 일 예이다.
이하에서는, 도 21에 개시된 흐름도와의 차이점인 디바이스 인증 절차를 중심으로 검토한다.
디바이스 인증 절차는 컨펌 유저 인터렉션(Confirm User Interaction), 디바이스 인증(Device Authentication), 디바이스 인터렉션(Device Interaction), 또는 디바이스 인터렉션 인증(Device Authentication Interaction)으로 지칭될 수 있다.
디바이스 인증 절차는 서버와 클라이언트에서 각각 수행된다.
서버는 클라이언트로 서버 공개 키 메시지를 전송한 후 컨펌 유저 인터렉션(Confirm User Interaction) 절차를 수행한다(S25080). 클라이언트는 서버 공개 키 메시지를 수신하고 도 21에 관한 설명에서 상술한 방식으로 맥 값을 획득한 후 컨펌 유저인터렉션 절차를 수행한다(S25090).
맥 값에 대한 자세한 사항은 상술한 도 21을 참조한다. 디바이스 인증 절차에 대한 자세한 사항은 도 26과 관련된 설명에서 후술한다.
도 26은 본 명세서에서 제안하는 디바이스 인증 절차를 포함하는 등록 세션 절차의 흐름도의 다른 예를 나타낸다.
서버는 등록 시작 메시지를 수신하고(S26010), 유저 인터렉션 절차를 수행한다(S26020). 그 후, 서버는 클라이언트로 임시 사용자 ID를 포함하는 유저인터렉션 완료 메시지를 전송(S26030)한다. 시작 메시지 수신, 유저 인터렉션 절차 수행 및 유저 인터렉션 완료 메시지 전송 절차는 각각 상술한 도 14의 S14010, 도 21의 S21040 및 도 14의 S14060 절차와 동일하게 수행될 수 있다,
서버는 유저 인터렉션 완료 메시지를 전송한 뒤, 클라이언트로부터 클라이언트 공개 키를 포함하는 기입 요청 메시지를 수신한다(S26040). 이 기입 요청 메시지는 클라이언트 공개 키 등록(Registration Client Public Key) 메시지로 지칭될 수 있다. 이 때, 이 기입 요청 메시지는 클라이언트의 입출력 능력(I/O Capability) 정보를 포함한다. 예를 들어, 클라이언트 디바이스가 디스플레이를 포함하는 경우, 기입 요청 메시지는 클라이언트가 디스플레이 입출력 능력을 갖고 있음을 나타내는 정보를 포함한다.
그 후, 서버는 획득한 클라이언트의 공개 키를 입력 값으로 갖는 제1 알고리즘을 통해 제1 값(Value 1)을 획득한다(S26050). 예를 들어, 도 26에 도시된 바와 같이 제1 알고리즘을 f1으로 표현하는 경우, 서버가 제1 값을 획득하는 방식은 Value1=f1(Client Public Key, Server Private Key)로 표현될 수 있다.
서버는 제1 값을 획득한 뒤, 클라이언트로 서버 공개 키를 포함하는 통지 메시지를 전송한다(S26060). 이 통지 메시지는 서버 공개 키 등록(Registration Server Public Key) 메시지로 지칭될 수 있다. 이 때, 이 통지 메시지는 서버의 입출력 능력 정보를 포함한다. 예를 들어, 서버 디바이스가 LED를 포함하는 경우, 통지 메시지는 서버가 LED 출력 능력을 갖고 있음을 나타내는 정보를 포함한다.
클라이언트는 획득한 서버 공개 키를 입력 값으로 갖는 특정 알고리즘을 통해 제1 값(Value 1)을 획득한다(S26070). 클라이언트가 사용한 특정한 알고리즘은 상기 서버가 사용한 제1 알고리즘과 동일한 알고리즘에 해당한다. 예를 들어, 클라이언트가 제1 값을 획득하는 방식은 (Value1=f1(Server Public Key, Client Public Key))로 표현될 수 있다. 클라이언트는 제1 알고리즘(f1)을 통해 서버가 획득한 값과 동일한 값을 획득한다.
상술한 바와 같이, 각 디바이스는 상대 디바이스와 입출력 능력 정보를 교환함으로써 상대방 디바이스의 입출력 정보를 획득한다. 각 디바이스는 이를 이용하여 후술할 컨펌 인터렉션 절차를 수행할 수 있다. 따라서 각 디바이스는 획득한 입출력 정보에 따라 적절한 방식을 선택함으로써 인증을 수행할 수 있다.
아래의 표 6는 디바이스 인증에 사용되는 디바이스 인터렉션 타입의 종류 및 각 타입에 따른 디바이스 액션(Device Action)의 일 예를 나타낸다.
Figure PCTKR2017006967-appb-T000006
클라이언트와 서버는 각 디바이스에서 지원(support)하는 디바이스 인터렉션 타입(Device Interaction Type)을 사용하여 상술한 제1 값에 대응되는 출력을 표시(present)할 수 있다.
서버는 클라이언트의 공개 키를 사용하여 획득한 제1 값(Value 1)에 대응하는 정보를 출력부를 통해서 출력할 수 있다. 이 때, 출력 방식은 서버의 출력 능력 및 서버에서 지원하는 디바이스 인터렉션 타입 중 적어도 어느 하나에 기초하여 결정될 수 있다. 예를 들어, 서버 디바이스의 출력부가 LED이고, 디바이스 인터렉션 타입이 표 6의 LED Blinking인 경우 서버는 제1 값에 대응되는 색상의 LED를 깜빡일 수 있다.
마찬가지로, 클라이언트는 서버 공개 키를 사용하여 획득한 제1 값(Value)에 대응하는 정보를 출력부를 통해서 출력할 수 있다. 이 때, 출력 방식은 클라이언트의 출력 능력 및/또는 클라이언트에서 지원하는 디바이스 인터렉션 타입에 따라 결정될 수 있다. 예를 들어, 클라이언트 디바이스의 출력부가 디스플레이이고, 디바이스 인터렉션 타입이 표 6의 핀(PIN) 인 경우, 클라이언트는 제1 값에 대응되는"123456"을 디스플레이에 나타낼 수 있다.
서버는 클라이언트로 서버 공개 키 메시지를 전송한 후 디바이스를 인증하는 컨펌 유저인터렉션 절차를 수행한다(S26080). 컨펌 유저인터렉션 절차는 디바이스 인증 절차에 해당한다. 디바이스 인증 절차는 등록 세션 절차에서 디바이스 등록을 위해 사용자 인증 후 디바이스를 인증하는 절차이다.
컨펌 유저인터렉션 절차에서, 서버는 사용자로부터 디바이스 인증과 관련된 입력 정보를 획득한다. 입력 정보는 사용자가 서버 디바이스에 수행한 특정한 입력에 관한 정보이다. 예를 들어, 서버는 사용자가 서버 디바이스의 디스플레이에 입력한 특정 패턴을 입력 정보로 획득할 수 있다.
서버가 획득한 입력 정보는 클라이언트 디바이스에서 출력된 상술한 제1 값에 대응되는 출력에 기초하여 사용자가 서버 디바이스에 수행한 입력에 관한 정보에 해당될 수 있다. 예를 들어, 서버가 패턴 입력 능력을 갖는 경우, 사용자는 클라이언트 디바이스의 디스플레이에 나타난 패턴을 확인하고, 상기 패턴과 동일한 패턴을 서버 디바이스에 입력할 수 있다. 이 때 서버는 패턴 정보를 입력 정보로 획득한다.
서버는 획득한 입력 정보에 제2 알고리즘을 사용하여 제2 값을 획득한다. 제2 알고리즘은 상술한 제1 알고리즘과 상이한 알고리즘에 해당한다. 예를 들어, 도 26에 개시된 바와 같이, 제2 알고리즘을 적용하는 방식은 (Interaction Method(LED) <-f2(Value1))으로 표현될 수 있다.
서버는 제1 알고리즘을 사용하여 획득한 제1 값 및 제2 알고리즘을 사용하여 획득한 제2 값을 비교하여 디바이스 인증 성공 여부를 판단할 수 있다. 서버는 제1 값 및 제2 값이 일치하는 경우 인증 성공으로 판단할 수 있고, 일치하지 않는 경우 인증 실패로 판단할 수 있다.
마찬가지로, 클라이언트도 상술한 서버에서 수행된 것과 동일한 방식을 사용하여 획득한 제1 값 및 제2 값의 비교를 통해 디바이스 인증을 수행할 수 있다.
상술한 바와 같이 클라이언트 및 서버에서 각각 컨펌 유저인터렉션을 수행하여 디바이스를 인증할 수 있다.
서버 또는 클라이언트는 필요시 인증 성공 여부를 별도로 표시할 수 있고, 이 경우 표시 방식은 디바이스의 출력 능력에 기초하여 결정될 수 있다.
디바이스 인증 확인(Device Authentication Confirmation)은, 디바이스 인증이 성공했음을 확인하는 절차로서 디바이스의 종류나 입출력 능력에 기초하여 서버 또는 클라이언트에서 사용자에 의해 수행될 수 있다. 디바이스 인증 확인 절차는 디바이스 인증 절차에 포함된다. 각 디바이스는 상기 디바이스 인증을 확인하는 확인 정보를 획득할 수 있다.
서버는 제1 값에 대응하는 정보의 출력을 수행한 뒤, 사용자가 디바이스 인증을 확인하는 사용자 입력을 획득할 수 있다. 예를 들어, 사용자는 서버 및 클라이언트의 각 디바이스에 나타난 출력 결과에 기초하여 인증되었음을 확인하고 서버 디바이스의 입력부의 확인 버튼을 클릭함으로써 디바이스 인증을 완료할 수 있다. 서버는 이 경우 사용자가 확인 버튼을 클릭함으로써 발생되는 디바이스 인증 확인 정보를 획득한다. 디바이스 인증 확인과 관련된 정보의 획득 방법은 서버의 입력 능력에 기초하여 결정될 수 있다.
클라이언트는 컨펌 유저인터렉션 절차를 수행한 수, 디바이스 인증 결과를 나타내는 정보를 포함하는 기입 요청 메시지인 클라이언트 확인 메시지를 서버로 전송한다(S26100). 이 절차는 상술한 도 14의 140130 단계와 동일한 방식으로 수행될 수 있다.
서버는 클라이언트로부터 수신한 클라이언트 디바이스의 인증 성공 여부를 나타내는 기입 요청 메시지에 기초하여 서버 인증 절차를 완료할 수 있다.
아래의 표 7은 디바이스 인터렉션을 수행하는 방식들의 일 예를 나타낸다.
Figure PCTKR2017006967-appb-T000007
컨펌 유저인터렉션(Confirm User Interaction)은 디바이스 인터렉션에 해당한다. DA_value는 클라이언트가 공개 키를 사용하여 획득한 값을 나타낸다.
방법 #1(Method #1): 클라이언트는 DA_value를 사용하여 독특한 패턴을 생성하고, 생성된 패턴을 디스플레이한다. 유저는 클라이언트 디바이스(Device A)에 디스플레이된 패턴과 동일한 패턴을 서버 디바이스에 입력한다.
방법 #2(Method #2): 클라이언트는 DA_value를 사용하여 진동을 생성한다. 서버 디바이스는 진동 횟수를 디스플레이한다.
방법 #3(Method #3): 클라이언트는 DA_value를 사용하여 LED 깜빡임을 생성한다. 서버 디바이스는 깜빡이는 LED의 색을 표시한다.
상술한 방법들 외에도, 각 디바이스의 기능에 따라 다양한 방식으로 디바이스 인터렉션이 수행될 수 있다.
서버는 디바이스 인증 절차가 완료되어 디바이스가 등록된 경우, 임시 사용자 아이디를 사용자 아이디로 저장한다(S26110).
도 27은 디바이스간 최초 인증 절차의 일 예로서, 서버에서 유저인터렉션 인증 절차가 수행되고 서버 및 클라이언트가 각각 사용자의 입력을 획득하는 경우를 나타낸다.
서버 및 클라이언트는 각각 사용자 입력을 획득할 수 있다. 사용자 입력(User Input)은 사용자가 사용자 인증 또는 디바이스 인증을 위해 디바이스가 획득한 특정 정보를 나타낸다. 사용자 입력은 인증 시작을 요청하는 정보, 사용자 식별 정보 및 디바이스 인증과 관련된 정보 중 하나와 관련된다.
클라이언트는 사용자 인증 절차의 시작 또는 등록 시작(Registration Start)을 요청하는 사용자 입력을 획득한다. 예를 들어, 사용자가 인증 시작 버튼을 누르면, 클라이언트 디바이스는 인증 절차를 시작을 요청하는 메시지를 전송한다(S27010). 이 절차는 상술한 도 14의 S14010 단계와 동일하게 수행될 수 있다.
서버는 유저인터렉션 인증(User Interaction Authentication) 절차(S27020)에서 사용자 식별 정보를 사용자 입력으로 획득한다.
나머지 절차는 상술한 도 21 내지 26과 관련된 설명에 개시된 절차와 동일하게 수행될 수 있다.
도 28은 디바이스간 최초 인증 절차의 일 예로서, 클라이언트에서 유저인터렉션 인증 절차가 수행되고 서버 및 클라이언트가 각각 사용자의 입력을 획득하는 경우를 나타낸다.
사용자 인증은 각 디바이스의 입출력 능력 등에 기초하여 서버가 아닌 클라이언트에서 수행될 수도 있다.
서버는 사용자 인증 시작을 요청하는 사용자 입력을 획득하고, 서버가 관련된 사용자 입력을 획득했음을 나타내고 사용자 인증 시작을 요청하는 메시지를 클라이언트로 전송한다(S28010). 이 메시지는 사용자 인증 시작(User Authentication Start) 메시지로 지칭될 수 있다. 예를 들어, 서버 디바이스에서 인증 시작 버튼을 눌러 인증 시작을 요청할 수 있다.
클라이언트는 사용자 식별 정보를 사용자 입력으로 획득하고, 유저인터렉션 인증 절차를 수행한다(S28020). 클라이언트에서 수행되는 유저인터렉션 인증 절차는 도 21과 관련된 설명에서 상술한 서버에서 수행되는 유저인터렉션 인증 절차(S21040)와 동일한 방식으로 수행될 수 있다.
나머지 절차는 상술한 도 21 내지 26과 관련된 설명에 개시된 절차와 동일하게 수행될 수 있다.
도 29는 디바이스간 최초 인증 절차의 일 예로서, 서버에서 유저인터렉션 인증 절차가 수행되고 서버가 사용자의 입력을 획득하는 경우를 나타낸다.
등록 세션은 인증 절차 시작을 요청하는 메시지의 송수신 없이 시작될 수 있다. 또한, 사용자는 서버에서만 사용자 입력을 수행할 수 있다.
서버는 먼저 사용자 식별 정보를 사용자 입력으로 획득하고, 유저인터렉션 인증 절차를 수행한다(S29010). 이 절차는 상술한 도21의 S21040 절차와 동일하게 수행될 수 있다. 그 후, 서버는 서버에서 사용자 인증을 수행했음을 나타내는 사용자 인증 확인(User Authentication Confirmation) 메시지를 클라이언트로 전송한다(S29020).
나머지 절차는 상술한 도 21 내지 26과 관련된 설명에 개시된 절차와 동일하게 수행될 수 있다.
도 30은 디바이스간 최초 인증 절차의 일 예로서, 클라이언트에서 유저인터렉션 인증 절차가 수행되고 클라이언트가 사용자의 입력을 획득하는 경우를 나타낸다.
상술한 바와 같이, 사용자 인증은 각 디바이스의 입출력 능력 등에 기초하여 서버가 아닌 클라이언트에서 수행될 수도 있다.
클라이언트는 사용자 식별 정보를 획득하고, 유저인터렉션 인증을 수행한다(S30010). 유저인터렉션 인증 후, 클라이언트는 서버로 인증 절차의 시작을 요청하는 메시지를 전송한다(S30020). 이 절차는 상술한 도 14의 S14010 단계와 동일하게 수행될 수 있다.
나머지 절차는 상술한 도 21 내지 26과 관련된 설명에 개시된 절차와 동일하게 수행될 수 있다.
도 31은 디바이스간 최초 인증 절차 후 인증을 수행하는 일 예를 나타낸다.
클라이언트는 획득된 사용자 식별 정보를 사용함으로써 유저인터렉션 인증을 수행하고(S31010), 서버로 보안 세션에 필요한 하나의 토큰 전송을 요청하는 메시지를 전송한다(S31020). 이 메시지는 보안 토큰 획득(Secure Get Token Value) 메시지로 지칭될 수 있다.
서버는 보안 토큰 획득 메시지에 대한 응답 메시지를 클라이언트로 전송한다(S31030). 이 메시지는 보안 토큰 응답(Response to Secure Get Token Value) 메시지로 지칭될 수 있다. 상술한 절차를 통해 클라이언트와 서버 간의 인증이 완료(Authentication Complete)된다(S13040).
도 32는 디바이스간 최초 인증 절차 후 인증을 수행하는 다른 예를 나타낸다.
서버는 사용자 식별 정보를 사용자 입력으로 획득하여 유저인터렉션 인증을 수행한다(S32010). 그 후 서버는 클라이언트로 사용자가 최초 인증 후 서버를 통해 인증을 수행한 것을 나타내는 메시지를 전송한다(S32020). 이 메시지는 보안 사용자 확인(Secure User Confirmation) 메시지로 지칭될 수 있다. 상술한 절차를 통해 인증이 완료(Authentication Complete)된다(S32030).
도 33은 블루투스 인증 과정에서 사용자가 블루투스 연결을 원하는 디바이스와 사용자의 생체 정보를 이용하여 인증을 수행하는 일 예를 나타낸다.
사용자는 블루투스 통신이 가능한 웨어러블 디바이스를 착용한 상태에서 블루투스 연결을 원하는 특정 디바이스를 검색한다. 도 33에 도시된 바와 같이 웨어러블 디바이스는 Life band가 될 수 있고, 다른 디바이스는 TV, 스마트 기기 등이 될 수 있다.
사용자는 먼저 연결을 원하는 디바이스의 전원를 켜고 필요한 경우 별도의 컨트롤러를 사용하여 상기 특정 디바이스를 검색(Discovery)한다. 예를 들어, 별도의 컨트롤러는 리모컨이 될 수 있고, 이 경우 사용자는 디바이스를 검색(Discovery) 하기 위해 컨트롤러를 제어한다.
만약 양 디바이스간의 블루투스 연결이 최초 연결이 아닌 경우, 양 디바이스는 곧바로 블루투스 연결을 형성한다. 이 때 각 디바이스의 블루투스는 enabled 상태이어야 한다.
디바이스 검색 후, 양 디바이스는 인증을 위해 인증 정보를 교환한다. 인증 정보는 사용자를 식별하는 사용자 식별 정보를 사용하여 생성될 수 있다. 식별 정보의 종류는 웨어러블 디바이스의 기능에 기초하여 결정될 수 있다. 식별 정보는 사용자의 생체 정보가 될 수 있다. 예를 들어, 디바이스는 사용자의 뇌전도(EEG), 심박수(Heart Rate), 지문(Figerprint) 등의 정보를 사용하여 인증 정보를 생성하고, 이를 교환할 수 있다.
양 디바이스는 교환된 인증 정보가 동일한지 체크하고, 일치하는 경우 블루투스 연결이 형성된다. 이 경우 양 디바이스는 연결 성공을 나타내는 표시를 디스플레이할 수 있고, 상대방 디바이스로 인증 성공을 나타내는 메시지를 전송할 수 있다.
블루투스 연결은 인증 정보가 동일하지 않은 경우 형성되지 않는다. 이 경우 양 디바이스는 연결 실패를 나타내는 표시를 디스플레이하거나 상대방 디바이스로 인증 실패를 나타내는 메시지를 전송할 수 있다.
도 34는 패턴 입력을 사용하여 양 디바이스에서 인증 절차를 수행하는 방식의 일 예를 나타낸다.
사용자 A, B, C는 각각 별개의 사용자이다. 상용자 A는 관리자이다. 사용자 B는 스마트 기기를 사용하여 프린터 기기와 블루투스 연결을 형성을 하려고 한다. 사용자가 관리자가 아닌 경우, 디바이스는 블루투스 연결이 형성된 뒤 사용자가 제한된 기능만을 사용할 수 있도록 설정될 수 있다. 예를 들어, 관리자 아닌 사용자는 흑백 출력만을 사용할 수 있도록 디바이스 기능이 제한될 수 있다.
사용자 B는 먼저 자신만이 알고 있는 패턴을 사용하여 사용자 인증을 수행한다. 스마트 기기는 프린트 기기와 인증을 수행하기 위해 상기 패턴에 기반하여 사용자 B의 ID를 생성한다. 이 경우, 스마트 기기는 사용자 B가 스마트 기기에 등록되지 않은 블루투스 인증을 처음 수행하는 자인 경우 새로운 아이디를 생성하고, 등록된 사용자인 경우 미리 할당된 아이디를 사용한다.
스마트 기기와 프린트 기기에 초기 등록이 수행된다. 프린트 기기는 상술한 공개 키의 송수신 절차를 통해 교환된 키를 사용하여 특정 알고리즘(f1)을 통해 특정 값을 획득한다. 도 34에 개시된 예를 들면, 프린트 기기는 748을 특정 값으로 획득하고, 이에 대응되는 패턴을 디스플레이를 통해 출력한다.
사용자는 프린터 기기에 디스플레이된 패턴을 확인하고 동일한 패턴을 스마트 기기에 입력한다. 스마트 기기는 입력된 패턴으로부터 대응되는 값을 획득하고, 패턴으로부터 획득된 값과 키 교환으로 생성된 값이 동일하면 인증을 완료(성공)한다. 인증 완료 후 디바이스가 서로 연결된다.
도 35는 서버가 디바이스 등록을 위한 인증을 수행하는 순서도의 일 예를 나타낸다.
도 35에 개시된 순서도에서 제1 디바이스는 서버 디바이스, 제2 디바이스는 클라이언트 디바이스에 해당한다.
서버 디바이스는 클라이언트와 블루투스 LE 연결을 형성한다(S35010). 이 단계는 상술한 도 13의 S13010 단계와 동일하게 수행될 수 있다.
서버 디바이스는 사용자를 식별하기 위한 식별 정보를 획득한다(S35020).
서버 디바이스는 식별 정보에 기초하여 사용자를 인증하는 사용자 인증 절차를 수행한다(S35030). 이 절차는 상술한 도 21의 S21040 단계와 동일하게 수행될 수 있다.
서버 디바이스는 식별 정보에 대응하는 식별자가 포함된 제1 통지 메시지를 클라이언트 디바이스로 전송한다(S35040). 이 절차는 상술한 도 14의 S14060 단계와 동일하게 수행될 수 있다.
서버 디바이스는 클라이언트 디바이스로부터 제1 공개 키(클라이언트의 공개 키)를 포함하는 기입 요청 메시지를 수신한다(S35050). 이 기입 요청 메시지는 클라이언트 디바이스의 입출력 능력 정보를 포함한다. 자세한 사항은 상술한 도 26과 관련된 설명을 참조한다.
서버 디바이스는 제1 공개 키를 입력 값으로 갖는 제1 알고리즘을 사용하여 클라이언트 디바이스의 인증을 위한 제1 값을 획득한다(S35060). 자세한 사항은 상술한 도 26과 관련된 설명을 참조한다.
서버 디바이스는 클라이언트 디바이스로 제2 공개 키(서버의 공개 키)를 포함하는 통지 메시지를 전송한다(S35070). 이 통지 메시지는 서버 디바이스의 입출력 능력 정보를 포함한다. 자세한 사항은 상술한 도 26과 관련된 설명을 참조한다.
서버 디바이스는 특정 인증 방식을 사용하여 클라이언트 디바이스를 인증하기 위한 디바이스 인증 절차를 수행한다(S35080). 자세한 사항은 상술한 도 26과 관련된 설명을 참조한다.
각 단계에 관한 자세한 사항은 상술한 도면에 관한 설명을 참조한다.
도 36는 클라이언트가 디바이스 등록을 위한 인증을 수행하는 순서도의 일 예를 나타낸다.
도 36에 개시된 순서도에서 제1 디바이스는 클라이언트 디바이스, 제2 디바이스는 서버 디바이스에 해당한다.
클라이언트 디바이스는 서버 디바이스와 블루투스 LE 연결을 형성한다(S36010). 이 단계는 상술한 도 13의 S13010 단계와 동일하게 수행될 수 있다.
클라이언트 디바이스는 서버 디바이스로 인증 절차의 시작을 요청하는 기입 요청 메시지를 전송한다(S36020). 이 단계는 상술한 도 14의 S14010 단계와 동일하게 수행될 수 있다.
클라이언트 디바이스는 서버 디바이스로부터 사용자의 식별 정보에 대응되는 식별자가 포함된 통지 메시지를 수신한다(S36030). 이 단계는 상술한 도 14의 S14060 단계와 동일하게 수행될 수 있다.
클라이언트 디바이스는 서버 디바이스로 제1 공개 키(클라이언트의 공개 키)가 포함된 기입 요청 메시지를 전송한다(S36040). 이 기입 요청 메시지는 클라이언트 디바이스의 입출력 정보를 포함한다. 자세한 사항은 상술한 도 26과 관련된 설명을 참조한다.
클라이언트 디바이스는 서버 디바이스로부터 제2 공개 키(서버의 공개 키)가 포함된 통지 메시지를 수신한다(S36050). 이 통지 메시지는 서버 디바이스의 입출력 정보를 포함한다. 자세한 사항은 상술한 도 26과 관련된 설명을 참조한다. 클라이언트 디바이스는 제1 공개 키를 입력 값으로 갖는 제1 알고리즘을 사용하여 상기 서버 디바이스의 인증을 위한 제1 값을 획득한다(S36060). 자세한 사항은 상술한 도 26과 관련된 설명을 참조한다.
클라이언트 디바이스는 특정 인증 방식을 사용하여 서버 디바이스를 인증하기 위한 디바이스 인증 절차를 수행한다(S36070). 자세한 사항은 상술한 도 26과 관련된 설명을 참조한다.
클라이언트 디바이스는 서버 디바이스로 디바이스 인증 절차의 결과를 나타내는 기입 요청 메시지를 전송한다(S36080). 이 절차는 상술한 도 25의 S25100 단계와 동일하게 수행될 수 있다.
각 단계에 관한 자세한 사항은 상술한 도면에 관한 설명을 참조한다.
이상, 전술한 본 발명의 바람직한 실시예는, 예시의 목적을 위해 개시된 것으로, 당업자라면 이하 첨부된 특허청구범위에 개시된 본 발명의 기술적 사상과 그 기술적 범위 내에서, 다양한 다른 실시예들의 개량, 변경, 대체 또는 부가 등이 가능할 것이다.

Claims (20)

  1. 블루투스 LE(Low Energy)를 이용하여 제1 디바이스가 인증을 수행하는 방법에 있어서,
    제2 디바이스와 블루투스 LE 연결을 형성하는 단계;
    사용자를 식별하기 위한 식별 정보를 획득하는 단계;
    상기 식별 정보에 기초하여 상기 사용자를 인증하는 사용자 인증 절차를 수행하는 단계;
    상기 식별 정보에 대응하는 식별자가 포함된 제1 통지 메시지를 상기 제2 디바이스로 전송하는 단계;
    상기 제2 디바이스로부터 제1 공개 키를 포함하는 기입 요청 메시지를 수신하는 단계;
    상기 제1 공개 키를 입력 값으로 갖는 제1 알고리즘을 사용하여 상기 제2 디바이스의 인증을 위한 제1 값을 획득하는 단계;
    상기 제2 디바이스로 제2 공개 키를 포함하는 제2 통지 메시지를 전송하는 단계; 및
    특정 인증 방식을 사용하여 상기 제2 디바이스를 인증하기 위한 디바이스 인증 절차를 수행하는 단계를 포함하고,
    상기 특정 인증 방식은 상기 제1 디바이스의 입출력 능력에 따라 결정되는 인증 수행 방법.
  2. 제1항에 있어서,
    상기 디바이스 인증 절차를 수행하는 단계에 있어서,
    상기 특정 인증 방식을 사용하여 상기 제1 값에 대응되는 특정 정보를 출력하는 단계; 및
    상기 특정 정보의 출력에 기초하여 상기 제2 디바이스를 인증하기 위한 입력 정보를 획득하는 단계를 포함하는 인증 수행 방법.
  3. 제2항에 있어서,
    상기 디바이스 인증 절차를 수행하는 단계에 있어서,
    상기 입력 정보에 기초하여 제2 알고리즘을 통해 제2 값을 획득하는 단계; 및
    상기 제1 값 및 상기 제2 값에 기초하여 상기 제2 디바이스의 인증을 완료하는 단계를 포함하는 인증 수행 방법.
  4. 제3항에 있어서,
    상기 디바이스 인증을 완료하는 단계에 있어서,
    상기 디바이스 인증은 상기 제1 값 및 상기 제2 값의 일치 여부에 따라 인증 성공 여부가 결정되는 인증 수행 방법.
  5. 제1항에 있어서,
    상기 디바이스 인증 절차는 PIN, 패스워드, 패턴, 진동, 문장 및 LED 중 하나의 방식을 사용하는, 인증 수행 방법.
  6. 제1항에 있어서,
    상기 식별 정보는 PIN, 제스처, 패턴, 패스워드 및 상기 사용자의 생체정보 중 하나인, 인증 수행 방법.
  7. 제1항에 있어서,
    상기 기입 요청 메시지는 상기 제2 디바이스의 입출력 능력에 관련된 정보를 포함하고, 상기 제2 통지 메시지는 상기 제1 디바이스의 입출력 능력에 관련된 정보를 포함하는 인증 수행 방법.
  8. 제1항에 있어서,
    상기 제2 디바이스로부터 상기 사용자 인증 절차 또는 상기 디바이스 인증 절차의 수행 방식을 포함하는 인증 방식 결정 메시지를 수신하는 단계를 더 포함하고, 상기 수행 방식은 상기 제2 디바이스에 의해 지정되는 인증 수행 방법.
  9. 블루투스 LE(Low Energy)를 이용하여 제1 디바이스가 인증을 수행하는 방법에 있어서,
    제2 디바이스와 블루투스 LE 연결을 형성하는 단계;
    상기 제2 디바이스로 인증 절차의 시작을 요청하는 기입 요청 메시지를 전송하는 단계;
    상기 제2 디바이스로부터 사용자의 식별 정보에 대응하는 식별자가 포함된 통지 메시지를 수신하는 단계;
    상기 제2 디바이스로 제1 공개 키가 포함된 기입 요청 메시지를 전송하는 단계;
    상기 제2 디바이스로부터 제2 공개 키가 포함된 통지 메시지를 수신하는 단계;
    상기 제2 공개 키를 입력 값으로 갖는 제1 알고리즘을 사용하여 상기 제2 디바이스의 인증을 위한 제1 값을 획득하는 단계;
    특정 인증 방식을 사용하여 상기 제2 디바이스를 인증하기 위한 디바이스 인증 절차를 수행하는 단계; 및
    상기 제2 디바이스로 상기 디바이스 인증 절차의 결과를 나타내는 기입 요청 메시지를 전송하는 단계를 포함하고,
    상기 특정 인증 방식은 상기 제1 디바이스의 입출력 능력에 따라 결정되는 인증 수행 방법.
  10. 제9항에 있어서,
    상기 디바이스 인증 절차를 수행하는 단계에 있어서,
    상기 특정 인증 방식을 사용하여 상기 제1 값에 대응되는 특정 정보를 출력하는 단계; 및
    상기 특정 정보의 출력에 기초하여 상기 제2 디바이스를 인증하기 위한 입력 정보를 획득하는 단계를 포함하는 인증 수행 방법.
  11. 제10항에 있어서,
    상기 디바이스 인증 절차를 수행하는 단계에 있어서,
    상기 제1 디바이스는 상기 입력 정보에 기초하여 제2 알고리즘을 통해 제2 값을 획득하는 단계; 및
    상기 제1 값 및 상기 제2 값에 기초하여 상기 제2 디바이스의 인증을 완료하는 단계를 포함하는 인증 수행 방법.
  12. 제11항에 있어서,
    상기 디바이스 인증을 완료하는 단계에 있어서,
    상기 디바이스 인증은 상기 제1 값 및 상기 제2 값의 일치 여부에 따라 인증 성공 여부가 결정되는 인증 수행 방법.
  13. 제9항에 있어서,
    상기 디바이스 인증 절차는 PIN, 패스워드, 패턴, 진동, 문장 및 LED 중 하나의 방식을 사용하는, 인증 수행 방법.
  14. 블루투스 LE(Low Energy)를 이용하여 인증을 수행하기 위한 제1 디바이스에 있어서,
    데이터를 저장하는 메모리;
    상기 메모리를 제어하는 프로세서를 포함하되, 상기 제1 디바이스는,
    제2 디바이스와 블루투스 LE 연결을 형성하고,
    사용자를 식별하기 위한 식별 정보를 획득하고,
    상기 식별 정보에 기초하여 상기 사용자를 인증하는 사용자 인증 절차를 수행하고,
    상기 식별 정보에 대응되는 식별자가 포함된 제1 통지 메시지를 상기 제2 디바이스로 전송하고,
    상기 제2 디바이스로부터 제1 공개 키를 포함하는 기입 요청 메시지를 수신하고,
    상기 제1 공개 키를 입력 값으로 갖는 제1 알고리즘을 사용하여 상기 제2 디바이스의 인증을 위한 제1 값을 획득하고,
    상기 제2 디바이스로 제2 공개 키를 포함하는 제2 통지 메시지를 전송하고,
    특정 인증 방식을 사용하여 상기 제2 디바이스를 인증하기 위한 디바이스 인증 절차를 수행하고,
    상기 특정 인증 방식은 상기 제1 디바이스의 입출력 능력에 따라 결정되는 디바이스.
  15. 제14항에 있어서,
    상기 디바이스 인증 절차는 상기 제1 디바이스가 상기 특정 인증 방식을 사용하여 상기 제1 값에 대응되는 특정 정보를 출력하고, 상기 특정 정보의 출력에 기초하여 상기 제2 디바이스를 인증을 위한 입력 정보를 획득함으로써 수행되는 디바이스.
  16. 제15항에 있어서,
    상기 제1 디바이스는 상기 입력 정보에 기초하여 제2 알고리즘을 통해 제2 값을 획득하고, 상기 제1 값 및 상기 제2 값에 기초하여 상기 제2 디바이스의 인증을 완료하는 디바이스.
  17. 제16항에 있어서,
    상기 디바이스 인증 절차는 상기 제1 값 및 상기 제2 값의 일치 여부를 기초로 수행되는 디바이스.
  18. 제14항에 있어서,
    상기 디바이스 인증 절차는 PIN, 패스워드, 패턴, 진동, 문장 및 LED 중 하나의 방식을 사용하는 디바이스.
  19. 제14항에 있어서,
    상기 식별 정보는 PIN, 제스처, 패턴, 패스워드 및 상기 사용자의 생체정보 중 하나인 디바이스.
  20. 제14항에 있어서,
    상기 제1 디바이스는 상기 사용자가 상기 제1 디바이스의 새로운 사용자인 경우 임시 식별자를 할당하고, 상기 임시 식별자를 상기 사용자의 상기 식별자로 저장하는 디바이스.
PCT/KR2017/006967 2016-07-01 2017-06-30 블루투스 기술을 사용하는 장치의 인증 방법 및 장치 WO2018004303A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/314,378 US11012227B2 (en) 2016-07-01 2017-06-30 Authentication method and system for device using Bluetooth technology

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201662357384P 2016-07-01 2016-07-01
US62/357,384 2016-07-01
US201662426528P 2016-11-26 2016-11-26
US62/426,528 2016-11-26

Publications (1)

Publication Number Publication Date
WO2018004303A1 true WO2018004303A1 (ko) 2018-01-04

Family

ID=60786090

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2017/006967 WO2018004303A1 (ko) 2016-07-01 2017-06-30 블루투스 기술을 사용하는 장치의 인증 방법 및 장치

Country Status (2)

Country Link
US (1) US11012227B2 (ko)
WO (1) WO2018004303A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11729612B2 (en) 2018-03-08 2023-08-15 Cypress Semiconductor Corporation Secure BLE just works pairing method against man-in-the-middle attack

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107257540B (zh) * 2017-07-04 2020-05-19 飞天诚信科技股份有限公司 一种实现蓝牙设备与移动设备配对的方法及装置
US11399286B2 (en) * 2019-08-20 2022-07-26 Qualcomm Incorporated Scrambling for wireless communications
US11762965B2 (en) * 2019-09-18 2023-09-19 Walgreen Co. Customizable audio in prescription reminders
CN113840266B (zh) * 2020-06-24 2024-05-03 华为技术有限公司 蓝牙配对方法、装置、系统、电子设备和存储介质
US12260610B2 (en) * 2022-03-24 2025-03-25 Objectvideo Labs, Llc Dual descriptor data for object recognition in low light conditions
US12284203B2 (en) 2023-01-18 2025-04-22 Bank Of America Corporation Generating password complexity rules based on attack pattern analysis using hash segmentation
US20240259815A1 (en) * 2023-01-31 2024-08-01 Dell Products, Lp Method and apparatus for on-the-fly out of band temporary key derivation and assignment for pairing

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120063598A1 (en) * 2010-09-10 2012-03-15 Mi Suk Huh Bluetooth® device and method of connecting bluetooth® devices using a bluetooth® channel
US20140301552A1 (en) * 2011-10-10 2014-10-09 Lg Electronics Inc. Method for wireless local area network (wlan)-based peer to peer (p2p) communication and apparatus for same
WO2015194854A1 (ko) * 2014-06-17 2015-12-23 엘지전자(주) 블루투스 le(low energy) 기술을 이용하여 디바이스 간 커넥션을 형성하기 위한 방법 및 장치
WO2016017909A1 (ko) * 2014-07-31 2016-02-04 엘지전자(주) 블루투스 통신을 지원하는 무선 통신 시스템에서 전자기기를 제어하기 위한 방법 및 장치
WO2016080798A1 (ko) * 2014-11-20 2016-05-26 엘지전자(주) 블루투스 통신을 지원하는 무선 통신 시스템에서 디바이스들 간 페어링을 수행하기 위한 방법 및 이를 위한 장치

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6766160B1 (en) * 2000-04-11 2004-07-20 Nokia Corporation Apparatus, and associated method, for facilitating authentication of communication stations in a mobile communication system
DE60109585D1 (de) * 2001-05-08 2005-04-28 Ericsson Telefon Ab L M Sicherer Zugang zu einem entfernten Teilnehmermodul
US8775801B2 (en) * 2009-06-12 2014-07-08 Fujitsu Mobile Communications Limited Radio communication apparatus and radio communication method
CN103339974B (zh) * 2011-01-31 2016-08-31 诺基亚技术有限公司 用户识别模块供应
GB2514055B (en) * 2012-06-20 2018-07-11 Certis Cisco Security Pte Ltd Bluetooth (RTM) pairing system, method, and apparatus
DK2701124T3 (da) * 2012-08-21 2021-10-18 Bekey As Styring af en adgang til en lokalitet
US8595810B1 (en) * 2013-01-13 2013-11-26 Mourad Ben Ayed Method for automatically updating application access security
US9066197B2 (en) * 2013-01-22 2015-06-23 Nokia Corporation Method, apparatus, and computer program product for power save control for tethering connections
KR20140146954A (ko) * 2013-06-18 2014-12-29 삼성전자주식회사 서비스 제공 방법 및 이를 위한 전자 기기
SG2013076898A (en) * 2013-10-16 2015-05-28 Certis Cisco Security Pte Ltd Method and system for controlling access to wireless apparatuses
US9256881B2 (en) * 2013-11-08 2016-02-09 Vattaca, LLC Authenticating and managing item ownership and authenticity
JP2017507549A (ja) * 2013-12-30 2017-03-16 バスコ データ セキュリティー インターナショナル ゲゼルシャフト ミット ベシュレンクテル ハフツング ブルートゥースインタフェースを備える認証装置
US10181231B2 (en) * 2014-02-18 2019-01-15 Bekey A/S Controlling access to a location
LT3114884T (lt) * 2014-03-07 2020-02-10 Ubiquiti Inc. Debesų įrenginio identifikavimas ir autentifikavimas
US9332018B2 (en) * 2014-04-03 2016-05-03 Prote. Us Converged Systems Corporation Method and system for secure authentication
CN106796751B (zh) * 2014-04-18 2020-08-21 金泰克斯公司 可训练收发器和移动通信设备训练系统及方法
KR102223609B1 (ko) * 2014-05-09 2021-03-05 삼성전자주식회사 전자 기기간 콘텐트 공유 방법 및 장치
US20150332258A1 (en) * 2014-05-19 2015-11-19 Qualcomm Incorporated Identity Verification via Short-Range Wireless Communications
US9654972B2 (en) * 2014-08-18 2017-05-16 Qualcomm Incorporated Secure provisioning of an authentication credential
KR101568332B1 (ko) * 2014-11-12 2015-11-12 현대자동차주식회사 효율적인 블루투스 연결을 지원하는 차량 및 그 제어방법
KR102468365B1 (ko) * 2014-11-14 2022-11-18 삼성전자 주식회사 기기 사용을 위한 기기 등록 방법 및 장치
US9917843B2 (en) * 2015-01-07 2018-03-13 Kii, Inc. Secure data management techniques
KR20170020036A (ko) * 2015-08-13 2017-02-22 현대자동차주식회사 운전자의 생체 정보에 관한 비밀 모드가 적용된 시스템 및 그 동작 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120063598A1 (en) * 2010-09-10 2012-03-15 Mi Suk Huh Bluetooth® device and method of connecting bluetooth® devices using a bluetooth® channel
US20140301552A1 (en) * 2011-10-10 2014-10-09 Lg Electronics Inc. Method for wireless local area network (wlan)-based peer to peer (p2p) communication and apparatus for same
WO2015194854A1 (ko) * 2014-06-17 2015-12-23 엘지전자(주) 블루투스 le(low energy) 기술을 이용하여 디바이스 간 커넥션을 형성하기 위한 방법 및 장치
WO2016017909A1 (ko) * 2014-07-31 2016-02-04 엘지전자(주) 블루투스 통신을 지원하는 무선 통신 시스템에서 전자기기를 제어하기 위한 방법 및 장치
WO2016080798A1 (ko) * 2014-11-20 2016-05-26 엘지전자(주) 블루투스 통신을 지원하는 무선 통신 시스템에서 디바이스들 간 페어링을 수행하기 위한 방법 및 이를 위한 장치

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11729612B2 (en) 2018-03-08 2023-08-15 Cypress Semiconductor Corporation Secure BLE just works pairing method against man-in-the-middle attack

Also Published As

Publication number Publication date
US11012227B2 (en) 2021-05-18
US20190159030A1 (en) 2019-05-23

Similar Documents

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

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: 17820579

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: 17820579

Country of ref document: EP

Kind code of ref document: A1