Security
보안
Security is built into the core of the Bluetooth Low Energy wireless technology.
보안은 Bluetooth Low Energy 무선 기술의 핵심에 내장되어 있습니다.
Since the introduction of BLE in the Bluetooth 4.0 core specification, the secure transmission of user data has been a primary design goal, and version 4.1 builds upon the strong foundations of its predecessor and tightens those principles even further.
Bluetooth 4.0 핵심 사양에 BLE가 도입된 이후 사용자 데이터의 안전한 전송이 주요 설계 목표였으며 버전 4.1은 이전 버전의 강력한 기반을 기반으로 하며 이러한 원칙을 더욱 강화합니다.
As introduced in “Security Manager (SM)” on page 28, the enforcement of security and privacy in BLE is based on two pillars:
28페이지의 "SM (보안 관리자)"에 소개된 대로 BLE의 보안 및 개인정보 보호 강화는 두 가지 요소를 기반으로 합니다.
Security Manager (and its protocol)
보안 관리자 (및 프로토콜)
The Security Manager implements the actual cryptographic algorithms and protocol exchanges that allow two devices to securely exchange data and privately detect each other.
보안 관리자는 두 장치가 안전하게 데이터를 교환하고 서로를 개인적으로 감지할 수 있도록 하는 실제 암호화 알고리즘과 프로토콜 교환을 구현합니다.
This is typically implemented inside the protocol stack and uses the available hardware acceleration modules to perform the required operations, such as generating random numbers, encrypting data using the Advanced Encryption Standard (AES), and generating and exchanging security keys with the peer.
이는 일반적으로 프로토콜 스택 내부에 구현되며, 사용 가능한 하드웨어 가속 모듈을 사용하여 난수 생성, AES (Advanced Encryption Standard)를 사용한 데이터 암호화, 피어와의 보안 키 생성 및 교환 등 필요한 작업을 수행합니다.
GAP security aspects
GAP 보안 측면
GAP defines a set of modes and procedures related to security that allow the implementation to trust the connection to carry sensitive data and to confidently accept the identity of a peer device.
GAP는 구현 시 민감한 데이터를 전송하는 연결을 신뢰하고 피어 장치의 ID를 자신 있게 수락할 수 있도록 하는 보안 관련 모드와 절차 세트를 정의합니다.
Security procedures are mostly asymmetrical, with the central and the peripheral assuming different roles during the generation and exchange of keys and the subsequent use of them to establish a secure connection.
보안 절차는 대부분 비대칭적이며, 키를 생성하고 교환하며 이를 사용하여 안전한 연결을 설정하는 과정에서 중앙 및 주변 장치가 서로 다른 역할을 맡습니다.
Additionally, GAP further expands and specifies the usage of the tools defined in “Security Manager (SM)” on page 28 in a standard and interoperable manner.
또한 GAP는 표준 및 상호 운용 가능한 방식으로 28페이지의 "SM (Security Manager)"에 정의된 도구의 사용을 더욱 확장하고 지정합니다.
The following sections further detail the GAP security aspects that, although at times complex and even convoluted, are fundamental to the operation of a majority of BLE devices.
다음 섹션에서는 때로는 복잡하고 복잡하기는 하지만 대부분의 BLE 장치 작동에 기본이 되는 GAP 보안 측면을 자세히 설명합니다.
Address Types
어드레스 유형
As discussed in “Bluetooth Device Address” on page 19, at its lowest level, the BLE protocol stack differentiates between public and random device addresses.
19페이지의 "블루투스 장치 주소"에서 설명한 것처럼 가장 낮은 수준에서 BLE 프로토콜 스택은 공용 장치 주소와 임의 장치 주소를 구별합니다.
GAP extends the concept of random device addresses by classifying them into three different categories:
GAP는 무작위 장치 주소를 세 가지 범주로 분류하여 개념을 확장합니다:
Static addresses are typically used as a replacement for public ones whenever the manufacturer does not want or need the overhead of IEEE registration.
정적 어드레스는 일반적으로 제조업체가 IEEE 등록 오버헤드를 원하지 않거나 필요로 하지 않을 때마다 공개 주소를 대체하는 데 사용됩니다.
A static address is simply a random number that can either be generated every time the device boots up or can stay the same for the lifetime of the device.
고정 어드레스는 단순히 장치가 부팅될 때마다 생성되거나 장치 수명 동안 동일하게 유지될 수 있는 임의의 숫자입니다.
However, it cannot be changed during a power cycle of the device.
그러나 장치의 전원을 껐다 켜는 동안에는 변경할 수 없습니다.
Non-resolvable private address
확인할 수 없는 개인 주소
This type of address is not commonly used.
이러한 유형의 주소는 일반적으로 사용되지 않습니다.
Also a randomly generated number, it represents a temporary address used for a certain amount of time.
또한 무작위로 생성된 숫자로 일정 시간 동안 사용되는 임시 주소를 나타냅니다.
Resolvable private addresses form the basis of the privacy feature.
확인 가능한 개인 주소는 개인 정보 보호 기능의 기초를 형성합니다.
They are generated from an identity resolving key (IRK) and a random number, and they can be changed often (even during the lifetime of a connection) to avoid the device being identified and tracked by an unknown scanning device.
이러한 키는 IRK (ID 확인 키)와 난수에서 생성되며, 알 수 없는 스캐닝 장치에 의해 장치가 식별되어 추적되는 것을 방지하기 위해 자주 변경될 수 있습니다 (연결 기간 동안에도 변경 가능).
Only devices that possess the IRK distributed by the device using a private resolvable address can actually resolve that address, allowing them to identify the device.
확인 가능한 개인 주소를 사용하여 장치에서 배포한 IRK를 소유한 장치만 실제로 해당 주소를 확인하여 장치를 식별할 수 있습니다.
GAP also defines an encoding scheme to obtain the category from the two highest bits of the BD_ADDR 48-bit value, which can be useful in certain situations.
GAP는 또한 특정 상황에서 유용할 수 있는 BD_ADDR 48비트 값의 가장 높은 두 비트에서 범주를 얻기 위한 인코딩 체계를 정의합니다.
But to ascertain the nature of a BLE address, you need one extra bit on top of the 48-bit, because otherwise it would be impossible to know whether the BD_ADDR corresponds to a public or a random device address (public device addresses make no guarantees regarding the contents of its most significant bits).
하지만 BLE 주소의 특성을 확인하려면 48비트 위에 한 비트가 더 필요합니다. 그렇지 않으면 BD_ADDR이 공개 장치 주소인지 무작위 장치 주소인지 알 수 없기 때문입니다 (공개 장치 주소는 최상위 비트의 내용에 대해 아무런 보장을 하지 않습니다).
The usage of the word authentication and its derivatives in the BLE specification (and in GAP in particular) is rather convoluted and can lead to confusion, so this section attempts to clarify the two different meanings it might convey:
BLE 사양 (특히 GAP)에서 인증이라는 단어와 그 파생어의 사용은 다소 복잡하고 혼란을 초래할 수 있으므로 이 섹션에서는 전달될 수 있는 두 가지 다른 의미를 명확히 하려고 합니다.
Authentication as a procedure In GAP, the authentication procedure refers to enforcing security on the current connection.
절차로서의 인증 GAP에서 인증 절차는 현재 연결에 보안을 적용하는 것을 의미합니다.
This can refer to pairing (with or without bonding) or re-establishing security using a stored encryption key, as described in “Security Procedures” on page 29.
이는 29페이지의 "보안 절차"에 설명된 대로 페어링 (결합 유무에 관계없이) 또는 저장된 암호화 키를 사용하여 보안을 다시 설정하는 것을 의미할 수 있습니다.
The verb to authenticate is used in the same way (i.e., to perform the authentication procedure).
동사 '인증하다'도 같은 의미로 사용됩니다 (즉, 인증 절차를 수행하다).
As a qualifier for a pairing procedure or an existing key, authenticated means using an algorithm other than Just Works (see “Pairing Algorithms” on page 30).
페어링 절차 또는 기존 키에 대한 한정자로서 인증이란 Just Works 이외의 알고리즘을 사용하는 것을 의미합니다 (30페이지의 "페어링 알고리즘" 참조).
In this sense, it implies that MITM protection was available during the pairing procedure and key exchange, adding an additional level of trust.
이러한 의미에서 이는 페어링 절차 및 키 교환 중에 MITM 보호가 사용 가능하여 신뢰 수준이 추가되었음을 의미합니다.
Both passkey display and out-of-band (OOB) are algorithms that produce authenticated keys.
암호 키 표시와 대역 외 (OOB)는 모두 인증된 키를 생성하는 알고리즘입니다.
Conversely, an unauthenticated pairing procedure (using Just Works) can produce only unauthenticated keys.
반대로, 인증되지 않은 페어링 절차 (Just Works 사용)에서는 인증되지 않은 키만 생성할 수 있습니다.
When applied to encryption or data signing, authenticated refers to the keys used to perform those procedures.
암호화 또는 데이터 서명에 적용될 때 인증됨은 해당 절차를 수행하는 데 사용되는 키를 나타냅니다.
GAP APIs and documentation use both meanings extensively, so it is important to keep the differences in mind for the next few sections.
GAP API 및 문서는 두 가지 의미를 모두 광범위하게 사용하므로 다음 몇 섹션에서는 차이점을 염두에 두는 것이 중요합니다.
A connection is said to operate in a (single) security mode.
연결은 (단일) 보안 모드에서 작동한다고 합니다.
The use of mode in this context differs sharply from the one in previous sections.
이 맥락에서 모드 사용은 이전 섹션의 사용과 크게 다릅니다.
This defines the current security level of the connection, which at some point in time might differ from the requirements that the peers at each end want to enforce, leading to procedures to increase that security level.
이는 연결의 현재 보안 수준을 정의하는데, 어느 시점에서는 각 끝의 피어가 시행하려는 요구 사항과 다를 수 있으므로 보안 수준을 높이기 위한 절차가 필요합니다.
GAP defines two security modes, along with several security levels per mode:
GAP는 모드당 여러 보안 수준과 함께 두 가지 보안 모드를 정의합니다:
Security mode 1
보안 모드 1
This mode enforces security by means of encryption, and it contains three levels:
이 모드는 암호화를 통해 보안을 강화하며 다음 세 가지 수준을 포함합니다:
Level 1 No security (the link is not encrypted).
레벨 1 보안이 없습니다 (링크가 암호화되지 않음).
Level 2 Unauthenticated encryption.
레벨 2 인증되지 않은 암호화입니다.
Level 3 Authenticated encryption.
레벨 3 인증된 암호화입니다.
This mode enforces security by means of data signing (see “Security Manager (SM)” on page 28), and it contains two levels:
이 모드는 데이터 서명 (28페이지의 “SM (Security Manager)” 참조)을 통해 보안을 강화하며 두 가지 수준을 포함합니다:
Level 1 Unauthenticated data signing.
레벨 1 인증되지 않은 데이터 서명입니다.
Level 2 Authenticated data signing.
레벨 2 인증된 데이터 서명입니다.
Each connection starts its lifetime in security mode 1, level 1, and can later be upgraded to any of the security modes by means of encryption or data signing.
각 연결은 보안 모드 1, 레벨 1에서 수명을 시작하고 나중에 암호화 또는 데이터 서명을 통해 다른 보안 모드로 업그레이드할 수 있습니다.
It is important to know that a link can be downgraded from mode 1, level 3, to mode 1, level 2 by switching encryption keys, but encryption can never be disabled in the lower layers, making it impossible to go down from security mode 1, level 2.
암호화 키를 전환하면 모드 1, 레벨 3에서 모드 1, 레벨 2로 링크를 다운그레이드할 수 있지만, 암호화는 하위 계층에서 비활성화할 수 없으므로 보안 모드 1, 레벨 2에서 다운그레이드하는 것은 불가능합니다.
Security Modes and Procedures
보안 모드 및 절차
Along with all the modes and procedures detailed in previous sections, GAP also defines additional ones related to security establishment and enforcement.
이전 섹션에서 자세히 설명한 모든 모드 및 절차와 함께 GAP는 보안 설정 및 시행과 관련된 추가 모드 및 절차도 정의합니다.
In this section, the term mode refers back to the temporary state to which a device can switch in order to perform a procedure or to allow a procedure to be performed.
이 섹션에서 모드라는 용어는 절차를 수행하거나 절차 수행을 허용하기 위해 장치가 전환할 수 있는 임시 상태를 다시 나타냅니다.
This section briefly describes the security modes and procedures, which complement and build upon the basis set in “Security Manager (SM)” on page 28.
이 섹션에서는 28페이지의 "SM (보안 관리자)"에 설정된 기반을 보완하고 구축하는 보안 모드 및 절차에 대해 간략하게 설명합니다.
A device in this mode does not allow a bonding procedure to take place, although it can freely permit pairing procedures to execute.
이 모드의 장치는 페어링 절차의 실행을 자유롭게 허용할 수 있지만 본딩 절차의 실행을 허용하지 않습니다.
In this mode, a device cannot distribute, accept, or store keys, limiting all security level upgrades to the lifetime of the connection.
이 모드에서는 장치가 키를 배포, 수락 또는 저장할 수 없으므로 모든 보안 수준 업그레이드가 연결 수명 동안 제한됩니다.
This mode enables the device to create a bond with a peer, permanently storing security keys.
이 모드를 사용하면 장치가 피어와의 연결을 생성하여 보안 키를 영구적으로 저장할 수 있습니다.
The central can initiate the bonding procedure described in “Security Procedures” on page 29 at any time (even if the devices are already bonded, in which cases new keys would be generated and the old ones would be replaced).
중앙에서는 언제든지 29페이지의 "보안 절차"에 설명된 결합 절차를 시작할 수 있습니다 (장치가 이미 결합된 경우에도 새 키가 생성되고 이전 키가 교체됨).
However, it is relatively common practice to hold off until a GATT data access actually requires a higher security mode than the one currently in force.
그러나 GATT 데이터 액세스가 실제로 현재 시행 중인 보안 모드보다 더 높은 보안 모드를 요구할 때까지 보류하는 것이 비교적 일반적인 관행입니다.
As mentioned in “Authentication” on page 45, the authentication procedure enforces the transition to a security mode on a connection currently in a lower security mode.
45페이지의 "인증"에서 언급한 것처럼 인증 절차는 현재 낮은 보안 모드에 있는 연결에서 보안 모드로의 전환을 강제합니다.
This enforcement can come in the form of a pairing or bonding procedure or, if encryption keys are already available and sufficiently authenticated on both sides, in the form of an encryption procedure.
이러한 적용은 페어링 또는 결합 절차의 형태로 이루어질 수 있으며, 암호화 키가 이미 사용 가능하고 양쪽에서 충분히 인증된 경우 암호화 절차의 형태로 이루어질 수 있습니다.
Authorization procedure
인증 절차
Authorization in BLE and GAP refers to giving the application and, ultimately, the user the opportunity to accept or reject a particular transaction.
BLE 및 GAP의 승인은 애플리케이션과 궁극적으로 사용자에게 특정 거래를 수락하거나 거부할 수 있는 기회를 제공하는 것을 의미합니다.
This might take the shape of an internal application check if the device does not have a user interface, or if it does, it can ask the user for permission directly.
이는 장치에 사용자 인터페이스가 없는 경우 내부 애플리케이션 확인의 형태를 취할 수 있으며, 있는 경우 사용자에게 직접 권한을 요청할 수 있습니다.
Encryption procedure
암호화 절차
This procedure uses the Link Layer’s built-in encryption capabilities to start the encryption of all traffic over the current connection, as described in “Connections” on page 22 and “Security Procedures” on page 29.
이 절차는 22페이지의 "연결" 및 29페이지의 "보안 절차"에 설명된 대로 링크 계층의 내장 암호화 기능을 사용하여 현재 연결을 통해 모든 트래픽의 암호화를 시작합니다.
Although the central is the only one able to initiate an encryption procedure, the peripheral can request the central to do so by means of the security request mentioned in “Security Manager (SM)” on page 28.
중앙 장치는 암호화 절차를 시작할 수 있는 유일한 장치이지만 주변 장치는 28페이지의 "SM (보안 관리자)"에 언급된 보안 요청을 통해 중앙 장치에 그렇게 하도록 요청할 수 있습니다.
Although not strictly a mode or procedure, the privacy feature deserves a few words in the section on GAP security.
엄밀히 말하면 모드나 절차는 아니지만 개인 정보 보호 기능은 GAP 보안 섹션에서 간단히 설명할 가치가 있습니다.
Privacy was one of the aspects of the BLE specification that underwent a substantial modification between versions 4.0 and 4.1.
Privacy는 버전 4.0과 4.1 사이에서 상당한 수정을 거친 BLE 사양의 측면 중 하나였습니다.
The feature was simplified and the specification text was adapted to reflect what implementations had been using in practice for years, accommodating itself to the established status quo among currently shipping devices.
이 기능은 단순화되었으며 사양 텍스트는 수년 동안 실제로 사용되어 온 구현을 반영하여 현재 출시된 장치 중 확립된 현상 유지에 맞춰 조정되었습니다.
This revision was named Privacy 1.1 and was actually listed as a new feature in the 4.1 release, replacing the old privacy section.
이 개정판은 Privacy 1.1로 명명되었으며 실제로 4.1 릴리스의 새로운 기능으로 나열되어 이전 개인 정보 보호 섹션을 대체했습니다.
When using the privacy feature, a device periodically generates a new resolvable private address (see “Address Types” on page 44) and sets it as its own.
개인 정보 보호 기능을 사용할 때 장치는 확인 가능한 새 개인 주소 (44페이지의 "주소 유형" 참조)를 주기적으로 생성하고 이를 자체 주소로 설정합니다.
The only way for a peer to identify it is to resolve the address using an IRK, because all resolvable private addresses are temporary in nature and it makes no sense to store them permanently.
피어가 이를 식별하는 유일한 방법은 IRK를 사용하여 주소를 확인하는 것입니다. 왜냐하면 확인 가능한 모든 개인 주소는 본질적으로 일시적이고 영구적으로 저장하는 것은 의미가 없기 때문입니다.
Instead, an IRK (see “Security Keys” on page 31) previously shared and stored by both devices is used to generate the address in the device, protecting its identity and resolving it on the device trying to identify it.
대신, 이전에 두 장치에서 공유하고 저장한 IRK (31페이지의 "보안 키" 참조)를 사용하여 장치에서 주소를 생성하고 ID를 보호하며 장치에서 주소를 확인하여 식별합니다.
This feature can be used in all GAP roles concurrently and prevents malicious devices deprived of the shared IRK from identifying and tracking a particular device using its Bluetooth device address.
이 기능은 모든 GAP 역할에서 동시에 사용할 수 있으며 공유 IRK가 박탈된 악성 장치가 Bluetooth 장치 주소를 사용하여 특정 장치를 식별하고 추적하는 것을 방지합니다.
On top of all the roles, modes, and procedures, GAP also introduces two additional items that are relevant to the interests of application developers.
모든 역할, 모드 및 절차 외에도 GAP는 애플리케이션 개발자의 관심 사항과 관련된 두 가지 추가 항목을 도입합니다.
Advertising Data Format
광고 데이터 형식
So far, we have been talking about the user data that can be carried by advertising (and scan response) packets, but we have not mentioned the format in which this data must be populated.
지금까지 우리는 광고 (및 스캔 응답) 패킷을 통해 전달될 수 있는 사용자 데이터에 대해 이야기했지만 이 데이터가 채워져야 하는 형식에 대해서는 언급하지 않았습니다.
The generic container is defined in the core specification in GAP, and it simply consists of a sequence of data structures, each of which is made of length (1 byte), AD Type (Advertising Data Type, 1 byte), and the actual data (variable length).
일반 컨테이너는 GAP의 핵심 사양에 정의되어 있으며 단순히 일련의 데이터 구조로 구성되며 각 데이터 구조는 길이 (1바이트), AD 유형 (광고 데이터 유형, 1바이트)으로 구성됩니다. ) 및 실제 데이터(가변 길이)입니다.
Each structure contains a separate item of user data.
각 구조에는 별도의 사용자 데이터 항목이 포함되어 있습니다.
The complete list of allowed AD Types is available in the Core Specification Supplement (CSS, currently at version 4) at the Bluetooth SIG’s Specification Adopted Documents page.
허용되는 AD 유형의 전체 목록은 Bluetooth SIG의 사양 채택 문서 페이지에 있는 핵심 사양 보충 자료 (CSS, 현재 버전 4)에서 확인할 수 있습니다.
Table 3-3 describes the most commonly used AD Types in typical application development.
표 3-3에서는 일반적인 애플리케이션 개발에서 가장 일반적으로 사용되는 AD 유형을 설명합니다.
This list isn’t exhaustive, though, so you might want to explore AD Types further for more detailed information.
이 목록은 전체 목록이 아니므로 더 자세한 정보를 보려면 AD 유형을 더 자세히 살펴보는 것이 좋습니다.
Not all AD Types are useful in every situation, and the 31-byte advertising packet and scan response size limits how many AD Types you can include, but it’s important to understand what types of information are available and which fields are relevant in different situations.
모든 AD 유형이 모든 상황에서 유용한 것은 아니며 31바이트 광고 패킷과 스캔 응답 크기는 포함할 수 있는 AD 유형의 수를 제한하지만 어떤 유형의 정보를 사용할 수 있는지, 어떤 필드가 다양한 상황에서 관련이 있는지 이해하는 것이 중요합니다.
This section briefly describes how the service-related AD Types can be useful for a wide range of applications.
이 섹션에서는 서비스 관련 AD 유형이 다양한 애플리케이션에 어떻게 유용할 수 있는지 간략하게 설명합니다.
Services and service UUIDs are used to encapsulate data into logic groups in BLE (see Chapter 4 for more details).
서비스 및 서비스 UUID는 데이터를 BLE의 논리 그룹으로 캡슐화하는 데 사용됩니다 (자세한 내용은 4장 참조).
The Bluetooth SIG defines a number of official services, all of which have a unique UUID associated with them, and you are free to create your own custom services with their own dedicated UUID.
Bluetooth SIG는 고유한 UUID가 연결된 여러 공식 서비스를 정의하며, 전용 UUID를 사용하여 사용자 정의 서비스를 자유롭게 만들 수 있습니다.
Services are what make device interoperability possible.
서비스는 장치 상호 운용성을 가능하게 합니다.
For example, any device that implements the Battery Service must do so based on the same data contract defined by the Bluetooth SIG, using the same UUIDs and data format.
예를 들어, 배터리 서비스를 구현하는 모든 장치는 동일한 UUID 및 데이터 형식을 사용하여 Bluetooth SIG에서 정의한 동일한 데이터 계약을 기반으로 이를 수행해야 합니다.
An advertising packet can include complete or incomplete lists of service UUIDs under the Service UUID AD Type to let other devices know which services are exposed by the peripheral without having to establish a connection with it.
광고 패킷에는 서비스 UUID AD 유형 아래 서비스 UUID의 완전하거나 불완전한 목록이 포함될 수 있으므로 연결을 설정하지 않고도 주변기기에 의해 어떤 서비스가 노출되는지 다른 장치에 알릴 수 있습니다.
Connections are expensive, and limiting the occasions where connections are necessary can help extend battery life.
연결에는 비용이 많이 들므로 연결이 필요한 경우를 제한하면 배터리 수명을 연장하는 데 도움이 될 수 있습니다.
By letting the world know that the device exposes a certain set of services as a GATT server, you can more quickly determine if that device is relevant to you without connecting to every device that comes within range.
장치가 특정 서비스 세트를 GATT 서버로 노출한다는 사실을 세상에 알리면 범위 내에 있는 모든 장치에 연결하지 않고도 해당 장치가 귀하와 관련이 있는지 더 빠르게 확인할 수 있습니다.
Conversely, service solicitation allows the central receiving the advertising packets to find out which services the peripheral can access when it is acting as a GATT client.
반대로 서비스 요청을 통해 중앙에서는 광고 패킷을 수신하여 주변 장치가 GATT 클라이언트 역할을 할 때 어떤 서비스에 액세스할 수 있는지 알아낼 수 있습니다.
In certain cases, if the central is not exposing any of these services at all as a GATT server, it might not even bother to connect to it, knowing that interaction would be extremely limited.
어떤 경우에는 중앙 서버가 이러한 서비스를 GATT 서버로 전혀 노출하지 않는 경우 상호 작용이 극도로 제한된다는 것을 알면서 중앙 서버에 연결하지 않을 수도 있습니다.
While services are normally used only after a connection is established, the advertising packet includes a mechanism to offer service data right in the advertising payload: the Service Data.
서비스는 일반적으로 연결이 설정된 후에만 사용되지만 광고 패킷에는 광고 페이로드에 바로 서비스 데이터를 제공하는 메커니즘인 서비스 데이터가 포함되어 있습니다.
The key benefit of using the Service Data field is that it allows you to broadcast the data contained inside your GATT services to any number of listening devices, bypassing the need to a dedicated connection between two devices to read service data.
서비스 데이터 필드 사용의 주요 이점은 서비스 데이터를 읽기 위해 두 장치 간의 전용 연결이 필요하지 않고 GATT 서비스 내에 포함된 데이터를 원하는 수의 수신 장치에 브로드캐스팅할 수 있다는 것입니다.
Finally, the Manufacturer Specific Data AD Type is a generic catch-all field that can include an arbitrary chunk of data in your advertising payload.
마지막으로, 제조업체별 데이터 광고 유형은 광고 페이로드에 임의의 데이터 덩어리를 포함할 수 있는 일반적인 포괄 필드입니다.
For example, Apple’s iBeacon (“iBeacon” on page 132) uses this AD type to push data out to other devices, inserting a 128-bit UUID that identifies the location and two 16-bit values to distinguish individual nodes in the same family.
예를 들어 Apple의 iBeacon (132페이지의 "iBeacon")은 이 AD 유형을 사용하여 다른 장치로 데이터를 푸시하고 위치를 식별하는 128비트 UUID와 동일한 패밀리의 개별 노드를 구별하는 두 개의 16비트 값을 삽입합니다.
This field provides a lot of flexibility to product designers who want to broadcast short chunks of custom data, and you’re generally free to change to contents of the field from one advertising event to the next.
이 필드는 짧은 양의 사용자 정의 데이터를 브로드캐스트하려는 제품 디자이너에게 많은 유연성을 제공하며 일반적으로 한 광고 이벤트에서 다음 광고 이벤트로 필드의 내용을 자유롭게 변경할 수 있습니다.
Please note that the Bluetooth SIG might release further updates to the Core Specification Supplement at the Specification Adopted Documents page whenever new AD Types are available for public consumption.
Bluetooth SIG는 새로운 AD 유형이 공개적으로 사용될 때마다 사양 채택 문서 페이지에서 핵심 사양 보충에 대한 추가 업데이트를 발표할 수 있습니다.