TL;DR
Using a static passkey with Bluetooth Low Energy (BLE) Secure Connections is generally a very bad idea. It significantly weakens security and makes your system vulnerable to attacks like man-in-the-middle, key compromise, and replay attacks. While it might seem easier for initial setup, the risks far outweigh the convenience.
Why Static Passkeys are Problematic
BLE Secure Connections aims to provide strong authentication and encryption. It does this by using Elliptic Curve Diffie-Hellman (ECDH) key exchange to establish a shared secret. This secret is then used to derive session keys for encrypting communication.
A static passkey bypasses much of this process. Here’s why it’s risky:
- Key Compromise: If the static passkey is discovered (through reverse engineering, side-channel attacks, or simply being hardcoded in a publicly accessible place), all devices using that key are compromised.
- Man-in-the-Middle Attacks: An attacker can intercept the initial connection attempt and pretend to be both devices if they know the static passkey. They can then relay communication while decrypting and potentially modifying it.
- Replay Attacks: Attackers could record legitimate communication sessions and replay them later, gaining unauthorized access or control.
- Lack of Forward Secrecy: Session keys are derived directly from the static passkey. If the passkey is compromised at any point, past and future communications can be decrypted.
Better Alternatives
Here’s how to achieve secure BLE connections *without* resorting to static passkeys:
1. Numeric Comparison
- Pairing Process: The devices exchange a random number.
- User Confirmation: Both devices display the same number and ask the user to confirm that they match. This verifies that both devices are communicating with the correct peer.
- Key Exchange: After successful confirmation, ECDH key exchange takes place.
This is the most common and recommended approach for BLE Secure Connections.
2. Passkey Entry (Less Common)
- Pairing Process: One device generates a random passkey.
- User Input: The user enters the passkey on the other device.
- Key Exchange: After successful verification, ECDH key exchange takes place.
This method is less convenient but can be useful in scenarios where a display isn’t available.
3. Out-of-Band (OOB) Pairing
- Alternative Channel: Use another secure channel (e.g., NFC, QR code, trusted network connection) to exchange pairing information.
- Key Exchange: Once the initial information is exchanged securely, ECDH key exchange takes place.
OOB pairing provides a very strong level of security but requires additional hardware or infrastructure.
Example Code (Illustrative – Numeric Comparison)
This example shows the basic idea of numeric comparison in pseudocode. Actual implementation will depend on your BLE stack and platform.
// Device A
random_number = generate_random_number()
display_number(random_number)
await user_confirmation()
if confirmation == true:
perform_ecdh_key_exchange(random_number) // Use the random number as part of key exchange
else:
pairing_failed()
// Device B (similar process)
If You Absolutely *Must* Use a Passkey
If you have an extremely compelling reason to use a passkey, consider these mitigations:
- Unique Per-Device Passkeys: Never reuse the same passkey across multiple devices.
- Key Rotation: Regularly change the passkey.
- Secure Storage: Store the passkey securely (e.g., using a hardware security module or encrypted storage).
- Limited Lifetime: Restrict the lifetime of the pairing session.
Even with these mitigations, static passkeys are still less secure than proper Secure Connections pairing methods.
Conclusion
Avoid using static passkeys with Bluetooth LE Secure Connections whenever possible. Prioritize numeric comparison or other recommended pairing methods to ensure a robust and secure connection. The convenience of a static passkey is not worth the significant security risks it introduces.