Sponsored by Silicon Labs
Introduction
With the rise of smart devices and the Internet of Things (IoT), Bluetooth technology has become an integral part of our daily lives. However, as our reliance on these devices grows, so does the need for secure and reliable connections.
Secure pairing/bonding and authentication are crucial elements in the world of Bluetooth Low Energy (LE) devices. Ensuring these two aspects are intact can be a big challenge, primarily due to the need for manual pairing and the lack of a scalable approach to verifying the authenticity of the connections using standard LE-based security mechanisms.
However, innovation has paved the way for a method known as Certificate-Based Authentication and Pairing (CBAP), which is significantly transforming how Bluetooth LE devices are authenticated and paired.
CBAP is a method developed by Silicon Labs that leverages digital certificates' ability to authenticate devices. Digital certificates are a type of identity credential that contains a public key and other identification information. They are signed by a trusted entity, typically a Certificate Authority (CA), and can be issued for a user, a server, or a device.
In the context of Bluetooth LE, these certificates are used to verify the identity of devices and establish a secure connection. This process eliminates the need for manual pairing, which is often prone to errors and security issues. Instead of relying on the user to verify and confirm the connection, the authentication is done automatically by checking the validity of the digital certificates. This enhances connection security and provides a much more user-friendly experience.
Moreover, CBAP provides a scalable approach to authenticate devices and connections. As the number of Bluetooth LE devices continues to grow exponentially, traditional methods of authentication and pairing are neither feasible nor efficient. With CBAP, the authentication process can be easily scaled, making it a suitable solution for large networks with thousands of devices.
In this article, we will explore the principles of Certificate-Based Authentication and Pairing (CBAP), the process of creating and using digital certificates, and how this method is implemented in Bluetooth LE devices. We will also discuss some practical CBAP examples and tools provided by Silicon Labs to make this process easier to implement.
The Limitations of Standard LE Security Mechanisms
As we mentioned previously, the problem with traditional Bluetooth LE security mechanisms is their lack of scalability and reliability in verifying the authenticity of the connections.
Standard LE-based security mechanisms often require manual pairing, which is prone to errors and inefficient for large networks with numerous devices. Manual pairing involves physically accessing each device, entering a passkey, or confirming two numbers, which can be prone to human error and is not feasible for large-scale networks.
Another issue with traditional LE security mechanisms is that they often rely on secure Out-Of-Band (OOB) methods like QR codes or Near Field Communication (NFC) for pairing. While these methods provide a certain level of security, they require proximity between the devices and can be inconvenient, especially in scenarios involving multiple devices.
Furthermore, a significant concern is the lack of proof of identity and authentication in traditional LE security mechanisms. Without a reliable way to verify a device or user identity, the entire network's security can be compromised. This is a critical issue, especially in applications where the integrity and confidentiality of the data being transmitted are of the utmost importance.
In summary, while traditional LE security mechanisms provide some security level, they have several limitations that make them unsuitable for today's increasingly connected and complex environments. These limitations include:
- Lack of scalability
- Reliance on manual pairing
- Lack of reliable identity verification and authentication
To overcome these challenges, we can utilize Silicon Labs’ Certificate-Based Authentication and Pairing (CBAP) method.
CBAP Principles and Process
CBAP operates on the basis of public key cryptography, a method that involves a pair of keys—a public key and a private key—and the use of certificates. In this section, we’ll go over some concepts related to certificates and public key cryptography that are important to understand in the context of CBAP.
Public Key Cryptography
The following points describe how a public-private key pair is used for signing data and verifying the signature:
- A private key is always generated (needs to be sufficiently random)
- A public key is derived from the private key
- The private key must be stored securely (must never leave the device!)
- The public key can be openly distributed and shared with other devices
- The private key can be used to generate a signature (usually operated on a hash of the original data and using a cryptographic algorithm)
- The public key can then be used to verify the signature on the data. In this case, the original data, the public key, and the signature are needed.
Certificates
The following points describe how certificates are used in the context of CBAP:
- A digital certificate is a small, verifiable data file that contains identity credentials and a public key
- That data is then signed either with the corresponding private key (AKA self-signed certificate) or a Certificate Authority’s (CA) private signing key (AKA root or CA certificate)
- The certificate can then be used to prove the ownership of a public key
- A Certificate Authority (CA) is a party trusted by both the owner of the certificate and the party relying on the certificate to verify the ownership
- Concatenation of certificates builds what’s called “a chain of trust”
- At the root of the chain is the CA certificate (AKA root certificate)
- The CA certificate can then be used to sign another certificate
- The resulting certificate can then be used to sign another one, and so on, creating a chain of trust
- The private key is never included in the certificate, and it must be stored privately and securely. Protecting this private key is crucial!
CBAP Implementation
Let’s now dive into how CBAP is implemented in a Bluetooth LE system. Here are the necessary steps for preparing the system:
- It begins with creating a root certificate or Certificate Authority (CA) certificate. This certificate, which includes a public key, is self-signed by the CA
- Protecting and securely storing the CA's private key is crucial, preferably in a hardware security module (HSM)
- A private-public key pair is generated on the device
- The public key (only) is read out from the device (the private key must never leave the device!)
- A device certificate is created externally for the device and includes the device's public key (which was read out in the previous step)
- The device certificate is then signed by the Certificate Authority (CA)
- This signed device certificate is flashed/programmed to the device
- The certificates between the central and peripheral are sent over the Bluetooth LE connection between these two devices (which is characterized as an “Out-Of-Band (OOB)” channel in this scenario, even though it is technically still "in-band")
- The process also leverages a new CBAP service that is included in advertising (technically, the UUID is what's included in the advertising data)
Now that we understand what’s involved in preparing the system and devices let’s examine how this is implemented as part of the Bluetooth LE security process.
The Bluetooth LE Security Process
I won’t get into the nitty gritty details of security in Bluetooth LE as this has been covered in many resources around the web (links) and otherwise (in my book). Let’s instead focus on how CBAP is used within the context of the LE Security process.
As mentioned earlier, the security process defined in the Bluetooth standard requires manual interaction and lacks scalability. CBAP can be used to overcome these limitations.
Assuming all the setup steps have been done (the device stores a private key, a CA certificate, and its own CA-signed device certificate), the following steps are performed:
- Upon startup, each device verifies its own certificate using the stored CA certificate (the CA signature on the device certificate is verified using the CA’s public key, which is stored in the CA certificate)
- Two devices connect and signal to each other that they want to use the CBAP method for authentication and pairing
- The two devices exchange their certificates over the Bluetooth LE connection
- Both devices will then verify the validity of the other device’s certificate using the CA public key (stored as part of the CA certificate, which is stored on each device)
- If that verification succeeds, the peer device is considered a “potentially” trusted device; the peer device must still prove that it possesses the private key that corresponds to the device certificate to fully verify its identity
- The devices initiate the standard LE OOB pairing
- The OOB data is actually sent in-band over the Bluetooth LE connection. The pairing process ensures an authenticated connection, provided that the OOB data is exchanged without a Man-In-The-Middle (MITM)
- To ensure MITM protection, each device signs its OOB data using its own private key. This signature is exchanged along with the OOB data.
- Each device will then verify this signature using the peer’s public key, which was included in the (already-verified) device certificate previously sent by the peer.
- If the verification process checks, this proves that the OOB data comes from a trusted device and not an MITM
- The security process continues as normal (according to the standard Bluetooth LE process), and the devices now have an encrypted and authenticated connection
Here’s a diagram summarizing these steps:
CBAP Deployment
There are two main options when it comes to deploying CBAP in your own Bluetooth LE system/product:
1. You (the device manufacturer) handle everything yourself
This includes the generation of private keys on the device side, ensuring the device keys are stored securely, creating the device certificates, signing the device certificates by a CA, and storing the device certificates on the devices.
Here's a diagram that details this process:
2. Utilize Silicon Labs' Custom Part Manufacturing Service (CPMS)
If, instead, you do not want to worry about managing the process of generating keys, creating certificates, signing them, etc., then you can utilize a service from Silicon Labs called CPMS. This offloads this whole provisioning/premanufacturing stage to Silicon Labs and provides the following:
- Device certificates are provided by Silicon Labs and flashed to the ordered parts before shipping
- A private key is generated on the ordered part and never leaves the device
- A public key and X.509 certificate parameters are signed by Silicon Labs’ Certificate Authority (CA) and stored on the device
- Certificate Authority (CA) certificates are shared publicly to enable verification of device certificates
- It can be flashed to the central device along with the FW to enable verification without internet access
- CA certificate may be either:
- Self-signed Silicon Labs root certificate (root of trust)
- or Factory/Batch certificate signed by a root certificate (Silicon Labs or 3rd party)
- CPMS also offers flashing the firmware to the devices in the factory
Here's a simple diagram summarizing the process:
The combination of CBAP and CPMS provides a unique set of advantages:
- Lowers the cost – less time spent by technicians, less prone to human errors
- Prevents counterfeit or malicious devices from entering the network
- By removing the need for a display and/or input methods, it can lead to reduced size and cost of end devices
Advantages of CBAP
To recap, CBAP offers several advantages over traditional methods of authentication and pairing:
- It eliminates the need for manual interaction, making the process much more convenient and faster. This method is particularly helpful in large-scale networks involving thousands of devices, where manual authentication would be labor-intensive, error-prone, and costly $$$!
- Additionally, CBAP provides proof of origin and identity, which standard Bluetooth LE authentication methods can't guarantee. The CA certificate can be used to verify the end device’s certificate, offering an added layer of security.
Here's a table summarizing the comparison between using CBAP and using only traditional Bluetooth LE pairing mechanisms:
Conclusion
The rise of smart devices and IoT has necessitated more secure and reliable connections. CBAP, developed by Silicon Labs, addresses this need by offering a scalable and secure method for Bluetooth LE device authentication and pairing. By leveraging the power of digital certificates and public key cryptography, CBAP eliminates the need for manual pairing, enhancing security and improving user experience.
Resources
Here are some additional resources that I recommend referring to for more information about CBAP, CPMS, and digital certificates:
- Silicon Labs AN1396: Certificate-Based Bluetooth® Authentication and Pairing
- Silicon Labs AN1268: Authenticating Silicon Labs Devices Using Device Certificates
- Silicon Labs Scripts and Examples:
- Silicon Labs Custom Part Manufacturing Service (CPMS)
